Agent Foskett Case File • Defender XDR • Response Actions • Endpoint Investigation • KQL
Defender Detected the Threat — But the Response Action Failed
The Microsoft Defender XDR incident looked reassuring.
Threat detected. Automated response initiated.
But a process was still running on the endpoint.
“So Defender found it?” the analyst asked.
“Yes,” Agent Foskett replied.
“And stopped it?”
He opened the Action Center.
“That,” he said, “is a different question.”
Case file: Detection is not containment
A realistic, illustrative Microsoft Defender XDR investigation into response-action status, endpoint telemetry, and the evidence needed to verify containment.
The incident looked resolved
At 09:12, a Microsoft Defender for Endpoint detection flagged suspicious command-line activity on a workstation used by a finance employee. The alert was grouped into a Defender XDR incident. An automated investigation began, and an analyst saw that a response action had been requested.
By 09:20, the incident queue had quietened down. Someone assumed the endpoint was contained.
Agent Foskett asked for one thing: proof that the response action had completed successfully.
By 09:20, the incident queue had quietened down. Someone assumed the endpoint was contained.
Agent Foskett asked for one thing: proof that the response action had completed successfully.
The detail hidden in the Action Center
The team opened the Microsoft Defender portal and reviewed the incident, its linked alerts, automated investigation details, and the Action Center. The requested device isolation action was not completed. In this fictional scenario, the portal showed a failed action, while the device had temporarily stopped communicating with the service.
The exact wording and status fields shown in the portal vary by action and product experience. The investigators preserved the action ID, target device, initiation time, displayed status, error information, and screenshots or exports available to their roles.
“The button was pressed,” Agent Foskett said. “That is not the same as the door being locked.”
The exact wording and status fields shown in the portal vary by action and product experience. The investigators preserved the action ID, target device, initiation time, displayed status, error information, and screenshots or exports available to their roles.
“The button was pressed,” Agent Foskett said. “That is not the same as the door being locked.”
Detection, investigation and response are different stages
A detection alert reports suspicious behaviour. An automated investigation may collect evidence and recommend or perform remediation, depending on configuration and approval settings. A response action—such as device isolation, antivirus scan, file quarantine or process-related action—has its own execution and outcome.
An incident status, an alert status, and an action status are not interchangeable. Closing an incident or seeing an action requested does not establish that the endpoint was isolated or the threat removed. Analysts must verify the actual outcome in the relevant Defender portal views and on the device where appropriate.
An incident status, an alert status, and an action status are not interchangeable. Closing an incident or seeing an action requested does not establish that the endpoint was isolated or the threat removed. Analysts must verify the actual outcome in the relevant Defender portal views and on the device where appropriate.
First hunt: what did the endpoint execute?
The investigation started with
DeviceProcessEvents in Microsoft Defender XDR advanced hunting. This query narrows the timeline around the known device and searches for suspicious command interpreters. Adjust the device name and timeframe for your own environment. Process activity alone does not establish that a command was malicious.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
let TargetDevice = "FIN-WKS-014";
let StartTime = datetime(2026-10-13T09:00:00Z);
let EndTime = datetime(2026-10-13T10:30:00Z);
DeviceProcessEvents
| where Timestamp between (StartTime .. EndTime)
| where DeviceName =~ TargetDevice
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
AccountName, InitiatingProcessFileName, ProcessId, ReportId
| order by Timestamp ascThe endpoint went quiet at the wrong moment
The response request had been submitted shortly after the alert. Then the device lost its expected connection to the Defender service. The team checked device health, onboarding state, sensor status, network connectivity, proxy configuration and whether the device had been shut down or was simply offline.
In this scenario, the connectivity gap was consistent with the failed isolation request, but the team did not assume it was the sole cause without the action error and endpoint evidence. A device can stop sending telemetry for many reasons, and an offline endpoint may still be executing local processes.
“Silence is not containment,” Agent Foskett said. “Sometimes it is just silence.”
In this scenario, the connectivity gap was consistent with the failed isolation request, but the team did not assume it was the sole cause without the action error and endpoint evidence. A device can stop sending telemetry for many reasons, and an offline endpoint may still be executing local processes.
“Silence is not containment,” Agent Foskett said. “Sometimes it is just silence.”
Second hunt: what did Defender actually alert on?
The
AlertInfo and AlertEvidence advanced-hunting tables help reconstruct the detection and associated entities. They do not provide a complete authoritative history of Action Center response execution. For action success or failure, use the Defender portal Action Center and available action-specific records.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 11
- 12
let StartTime = datetime(2026-10-13T09:00:00Z);
let EndTime = datetime(2026-10-13T10:30:00Z);
AlertInfo
| where Timestamp between (StartTime .. EndTime)
| where ServiceSource has "Defender for Endpoint"
| project AlertId, AlertTime=Timestamp, Title, Severity, Category
| join kind=leftouter (
AlertEvidence
| project AlertId, EvidenceTime=Timestamp, DeviceName,
EntityType, EvidenceRole, FileName, RemoteIP
) on AlertId
| order by AlertTime ascWas the suspicious activity still happening?
The team checked whether the process continued after the response request and whether it created new child processes, network connections or persistence. They correlated device identifiers and timestamps, allowing for delayed ingestion and gaps in endpoint telemetry.
They also reviewed the alert’s investigation graph and available device timeline. A quiet timeline after the action request would not, by itself, prove containment; the device might simply have stopped reporting.
They also reviewed the alert’s investigation graph and available device timeline. A quiet timeline after the action request would not, by itself, prove containment; the device might simply have stopped reporting.
Third hunt: check network activity after the alert
The following
DeviceNetworkEvents query looks for observed network connections from the target endpoint after the detection. It is a useful hunting lead, not proof of exfiltration. The query only returns events collected and retained by Defender for Endpoint.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
let TargetDevice = "FIN-WKS-014";
let AlertTime = datetime(2026-10-13T09:12:00Z);
DeviceNetworkEvents
| where Timestamp between (AlertTime .. AlertTime + 90m)
| where DeviceName =~ TargetDevice
| project Timestamp, DeviceName, InitiatingProcessFileName,
InitiatingProcessCommandLine, RemoteIP, RemoteUrl,
RemotePort, ActionType
| order by Timestamp ascWhat happened to the response action?
Agent Foskett built a separate response-action register: requested, approved if required, in progress, completed or failed, based on the actual portal evidence. He recorded who initiated each action, the device, timestamps, displayed outcome, and any follow-up action.
For the isolation attempt in this scenario, the team found no reliable confirmation that the device had been isolated. The response was therefore treated as unverified and unsuccessful until an operator could validate the state.
Depending on permissions and product configuration, some actions require approval or may be unavailable for certain device states. Those are separate checks from the malware detection itself.
For the isolation attempt in this scenario, the team found no reliable confirmation that the device had been isolated. The response was therefore treated as unverified and unsuccessful until an operator could validate the state.
Depending on permissions and product configuration, some actions require approval or may be unavailable for certain device states. Those are separate checks from the malware detection itself.
Reconstructing the timeline
09:12 — Threat detectedDefender for Endpoint creates an alert for suspicious execution.
09:14 — Response requestedAn analyst or automated workflow initiates device isolation.
09:15 — Connectivity interruptedThe endpoint stops sending expected telemetry; cause not yet proven.
09:18 — Action failsThe Action Center records that the isolation attempt did not complete.
09:27 — Assumption challengedAgent Foskett checks the actual response outcome instead of trusting the incident summary.
10:05 — Containment verifiedAfter reconnecting, the team performs an approved response and confirms the resulting device state.
Containment required a second attempt
The security team escalated the failed action, confirmed the device’s current connectivity and exposure, and used an approved alternative containment procedure appropriate to the organisation’s incident response plan. When the device was reachable, they repeated or replaced the action and verified the result in the portal and through endpoint checks.
They also reviewed whether suspicious processes, persistence mechanisms or credentials remained at risk. If the host could not be reached, the team treated it as potentially uncontained and used available network, identity and physical controls rather than declaring the incident resolved.
They also reviewed whether suspicious processes, persistence mechanisms or credentials remained at risk. If the host could not be reached, the team treated it as potentially uncontained and used available network, identity and physical controls rather than declaring the incident resolved.
The operational lesson
Response engineering needs the same attention as detection engineering. Track pending, failed and timed-out actions; define escalation owners; alert on meaningful response failures; test device isolation procedures; and validate that containment occurred before closing an incident.
Where supported, configure workflows to surface response failures to the SOC. Do not assume that every Defender action exposes a queryable KQL status field in advanced hunting.
Where supported, configure workflows to surface response failures to the SOC. Do not assume that every Defender action exposes a queryable KQL status field in advanced hunting.
Investigation principle: Detection tells you what the security platform saw. Response evidence tells you what it actually did.
Final thought
“Defender detected the threat,” said the analyst.
“Good,” replied Agent Foskett. “Did the isolation succeed?”
The analyst checked the Action Center. The action had failed.
“Then we have an alert,” Agent Foskett said, “not containment.”
Detection is only the beginning. Verify the response.
The Logs Already Knew! 🔎
“Good,” replied Agent Foskett. “Did the isolation succeed?”
The analyst checked the Action Center. The action had failed.
“Then we have an alert,” Agent Foskett said, “not containment.”
Detection is only the beginning. Verify the response.
The Logs Already Knew! 🔎
Related investigations
The AI Assistant Answered a Question Nobody Should Have AskedFollow the evidence behind a suspicious Microsoft 365 Copilot response.
Someone Exported the Database — But No Download Was RecordedInvestigate data exposure through application APIs and database activity.
The Password Was Correct — But Nobody Had Typed ItExamine Entra sign-in evidence to determine what successful authentication really proves.
