SQL Server: evidence for access and response decisions
A database decision needs to identify who depends on the service and which evidence supports the change. We propose a workflow connecting access, operations and retesting.
Leer en portuguésIn this article
- A current report with a defined observation period
- Turn exposure into a question that can be checked
- Connect permissions to the tasks that justify them
- Prepare a response decision another team can review
- Close the task through its observed result
- Frequently asked questions
- Related reading
- Sources and references
By Pentesty
A current report with a defined observation period
Fortinet's research, published November 12, 2026, describes a campaign observed in early October. The report links weak passwords on exposed SQL Server instances to delivery of a miner and a Gh0st RAT variant. Analysis of that variant was static because its control server was unavailable.
For a business using this database, we propose starting with the relationship between instance, service and owner. Choose a concrete operation, such as looking up orders or completing a financial close. Identify who can authorize an intervention, who administers the environment and who can confirm that the operation still works after the change.
Turn exposure into a question that can be checked
Create a record containing the address authorized for assessment, environment, purpose, accountable team and known dependencies. Define which origins need access and ask the network owner for the corresponding evidence. A difference between the stated need and the observed result should become a question with an owner and deadline, accompanied by the scope still awaiting examination.
The proposed test needs to use origins approved in advance and an agreed observation window. Record time, application, origin, destination instance, account used and the result of an authorized read query. Include scheduled execution when it follows a different path from interactive access. Validate these connections after the adjustment and ask the operation owner to confirm the expected result.
Connect permissions to the tasks that justify them
Microsoft's documentation states that xp_cmdshell is disabled on new installations and generally recommends leaving it disabled. When a legacy application requires it, the guidance is to enable it only for the necessary task.
In the proposed assessment, request a list of enabled logins and permissions the administrator considers necessary. Each exception should identify the task, account used, account owner, approver and expected end time. Request an authorized example demonstrating the need. Record the configuration found, the agreed decision and the retest result. A dependency without an owner remains open for a decision, with its impact described.
Prepare a response decision another team can review
If the team finds suspicious activity, propose a timeline referencing the available records. Identify the originating system, time coverage and collector for each item of evidence. Keep observation, interpretation and unanswered questions distinct. Avoid copying customer content into the tracking sheet; retain originals in an authorized repository and refer to their identifiers instead.
Before an intervention, agree who preserves the records, who decides on availability and who monitors the selected operation. Document the reason for restricting access or referring the environment for investigation. When information remains insufficient, record which evidence is missing and who can supply it. This allows the assessment to resume without reconstructing scattered conversations.
Close the task through its observed result
Define criteria before retesting: intended access works, the examined condition has been addressed and exceptions have a recorded decision. The service owner should confirm the business operation, while the technical team records the environment actually tested. Preserve date, configuration, sample and limitations alongside approval, so the basis for closure can be reviewed later.
A subsequent review should be able to locate evidence without depending on the person who performed the test. The analysis of exposure-based triage helps organize priority and decision making. Include the next review point and changes that will require reassessment when handing over responsibility for the service.
Frequently asked questions
Where should we start with an incomplete inventory?
Choose a known business operation and identify the instance serving it, its administrator and business owner. Explicitly record dependencies that still need confirmation before expanding the assessment sample to additional services.
Which evidence helps review an access exception?
Connect the necessary origin, authorized task, account involved, approver and deadline. Add the test result and a reference to the record that allows another person to check and assess that conclusion.
How should we distinguish investigation and retesting?
During investigation, record questions about the observed activity and available evidence. During retesting, check the defined criteria for the approved change and document the outcome within the sample that was actually examined.
What should accompany the decision to close a task?
Retain scope, environment, times, evidence references and acceptance by the owner. Identify limitations, remaining exceptions and the person responsible for the next decision, together with an agreed point for reviewing the result.
Sources and references
Original Pentesty analysis, published November 12, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.