Agent Foskett Investigation • Microsoft Defender XDR • Endpoint Security • Defender Exclusions • KQL
The Defender Exclusion Was Added 12 Minutes Before the Malware Ran
Microsoft Defender was running.
The device was onboarded.
The security controls looked healthy.
Yet malware executed from a folder Defender appeared to ignore.
Agent Foskett followed the timeline backwards.
Twelve minutes before the malware ran, something had changed.
A Defender exclusion had been added.
The Missing Alert Was Part Of The Evidence
The absence of a malware detection did not prove nothing malicious happened. It raised a different question: had the security control been changed before the payload arrived?
✓ Establish when the Defender exclusion appeared
✓ Identify the process or account associated with the change
✓ Correlate the change with later file and process activity
Defender looked healthy
Nothing about the initial device state immediately explained the execution. Defender was present, the endpoint was reporting telemetry and there was no obvious reason to assume the security product had simply stopped working. The investigation needed to move from product health to configuration.
The sensor was reportingEndpoint telemetry continued to arrive, so the investigation was not dealing with a completely blind device.
The malware executedProcess evidence showed the suspicious payload ran even though defenders expected the location to be protected.
The expected detection was missingThat gap became a question to investigate rather than proof that the activity was harmless.
Start with the timeline
Agent Foskett did not begin by asking why Defender failed. He asked what changed before the execution. DeviceRegistryEvents can expose registry modifications observed on the endpoint, including activity involving Defender exclusion locations where that telemetry is available.
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has @"Windows Defender\Exclusions"
| project Timestamp, DeviceName, ActionType,
RegistryKey, RegistryValueName, RegistryValueData,
InitiatingProcessAccountName,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp ascTimestampWhen did the configuration-related registry activity occur?
ValueWhich path, process or other exclusion-related value was involved?
Initiating processWhat process context was recorded with the registry change?
Twelve minutes changed the investigation
The exclusion-related change appeared first. Twelve minutes later, the suspicious file executed from the affected location. Timing alone does not prove intent, but the sequence is too important to ignore. The analyst now has a configuration event that can be correlated with endpoint execution.
T0 — exclusion activityA Defender exclusion-related configuration change appears in endpoint telemetry.
T+12 minutes — executionA suspicious executable launches from the location now requiring closer scrutiny.
Next questionWas the exclusion legitimate administration, attacker tampering or another configuration mechanism?
Look for the command that changed Defender
An exclusion can be configured through more than one management path. If PowerShell or another command-line process was involved, DeviceProcessEvents can help identify commands associated with Defender preference changes. This query hunts for common PowerShell Defender preference cmdlets and exclusion arguments; it does not assume every result is malicious.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any
("Add-MpPreference", "Set-MpPreference")
| where ProcessCommandLine has "Exclusion"
| project Timestamp, DeviceName, AccountName,
FileName, ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp ascDo not stop at PowerShellNo matching command does not prove the exclusion was never changed; policy, management tooling and other mechanisms may require different evidence.
Read the command lineIf a matching process exists, determine exactly what preference was changed and what exclusion argument was supplied.
Follow the parentThe initiating process can help explain whether the command came from an administrator, script, management tool or suspicious process chain.
Now follow the malware
Once the suspicious path and time window are known, correlate file and process activity. Replace the example path with the actual exclusion identified during the investigation. The goal is to reconstruct what arrived, what executed and what happened next.
let SuspiciousPath = @"C:\ProgramData\UpdateCache\";
DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath startswith SuspiciousPath
| project Timestamp, DeviceName, ActionType,
FileName, FolderPath, SHA256,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp asclet SuspiciousPath = @"C:\ProgramData\UpdateCache\";
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FolderPath startswith SuspiciousPath
| project Timestamp, DeviceName, AccountName,
FileName, FolderPath, SHA256,
ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp ascThe exclusion is not automatically malicious
Defender exclusions have legitimate operational uses. Performance-sensitive workloads, approved applications and managed configurations can all create valid exceptions. The investigation therefore has to establish context before calling the change attacker tampering.
Was it approved?Check change records, endpoint management policy and administrator activity for an expected reason.
Who or what made it?Correlate the initiating process, account and management context rather than relying on the registry value alone.
What happened afterwards?The significance increases when suspicious file creation or execution follows the configuration change.
Build one evidence chain
The strongest finding comes from correlation. A configuration change by itself may be administration. Malware execution by itself may have several explanations. Put the events together and the sequence becomes much more useful to the analyst.
ConfigurationEstablish the exclusion-related change and its exact time.
ExecutionEstablish the suspicious file or process activity that followed.
AttributionUse process, account, policy and change-management evidence to determine why the exclusion existed.
Investigation findings
In this scenario, the important clue was not a Defender alert. It was the configuration change that preceded the suspicious execution. The evidence should be used to determine whether the exclusion was authorised and whether it materially enabled the later activity; the timeline alone should not be overstated.
Defender telemetry was presentThe device continued to provide evidence even though the expected malware detection was absent.
An exclusion preceded executionThe exclusion-related activity occurred twelve minutes before the suspicious process ran.
Correlation provided the leadRegistry, process and file telemetry turned a missing alert into an investigation path.
Related Agent Foskett investigations
Continue with endpoint, PowerShell and evidence-led Microsoft Defender XDR investigations.
Final thought
Defender had not necessarily gone blind. The investigation simply needed to look somewhere else. Twelve minutes before the suspicious process ran, the protection boundary had changed. Agent Foskett did what investigators should always do when an alert seems to be missing: he stopped asking only what Defender detected and started asking what happened before it had the chance. 🔎
No alert?That does not mean there is no evidence.
Configuration changed?Put the change on the timeline and establish who or what caused it.
The lesson?Investigate the control as well as the threat.
