Windows Event ID 1117 — Windows Defender — Malware Remediation Action

Logged when Windows Defender takes a remediation action on a detected threat — quarantine, removal, block, or allow. Always follows Event ID 1116 (threat detected). The action outcome determines whether containment succeeded or the threat is still active.

Why It Matters

1117 answers the question 1116 leaves open: did Defender actually stop the threat? A Quarantine Succeeded means the malicious file is isolated. A Failed remediation means the malware protected itself — common with rootkits, ransomware mid-encryption, or threats that hook system processes to block deletion. 'Allowed by User' is the most concerning outcome: a user clicked Allow on the Defender prompt, overriding detection and permitting the threat to execute fully. This frequently happens when employees dismiss warnings on targeted phishing attachments or cracked software. Even a Quarantine Succeeded does not mean the threat didn't already execute — Defender detects on write or execution attempt, so process activity, network connections, and registry changes may have already occurred in the window between execution and detection.

Key Fields

Threat NameThe malware family or signature name — use this to research the threat's behavior, typical C2 infrastructure, and persistence mechanisms. Cross-reference with VirusTotal or Microsoft Threat Intelligence.

Action NameWhat Defender tried to do: Quarantine (isolate the file), Remove (delete), Block (prevent execution), or Allow (user overrode — treat as no remediation). 'Quarantine Failed' = malware resisted removal.

Action StatusSucceeded or Failed — Failed requires manual intervention. Combine with Action Name: 'Quarantine Failed' is the most dangerous combination, indicating active malware that prevented its own removal.

PathThe file path of the remediated threat — location reveals persistence mechanism: AppData = user-installed, Temp = dropper, System32 = driver/rootkit, Startup folder = run-key persistence.

Process NameThe process that triggered the detection — if it was Word, Excel, or Outlook, you have a document-based delivery (macro or exploit). If it was a browser, likely a drive-by or malicious download.

Investigation Tips

1.'Allowed by User' is an incident: the user clicked Allow on a Defender security warning, permitting the threat to execute unchecked. Identify who approved it, what process ran, and what it did in the minutes after. This is the most common reason Defender-detected threats become full compromises.
2.Failed remediations indicate active resistance: malware that blocks its own removal has typically already established persistence (service, driver, run key, scheduled task) or is actively encrypting files. Escalate immediately to endpoint isolation and manual forensic investigation.
3.Successful quarantine ≠ safe: determine exactly when the threat first appeared on the system vs. when it was detected. The gap between first execution and detection is the window of activity. Check 4688 (process creation), 5140 (network share access), and DNS logs for that window.
4.Correlate Process Name with the delivery vector: Office applications spawning unexpected child processes before 1116/1117 = macro-based delivery. Browser processes = drive-by download. LSASS or svchost = memory injection or living-off-the-land.
5.Cross-host spread: if the same Threat Name appears in 1117 events across multiple endpoints within a short window, you have active lateral spread — likely via network shares (5140), admin shares, or domain-wide script execution.

Detection Logic (KQL)

Microsoft Sentinel (KQL) — surface failed or user-overridden Defender remediations, which indicate active or partially-contained threats.

// Defender remediations that failed or were overridden by the user
Event
| where Source == "Microsoft-Windows-Windows Defender"
| where EventID == 1117
| extend ActionName = extract(@"Action Name:s*(.+?)[
]", 1, RenderedDescription)
| extend ThreatName = extract(@"Threat Name:s*(.+?)[
]", 1, RenderedDescription)
| extend ActionStatus = extract(@"Action Status:s*(.+?)[
]", 1, RenderedDescription)
| where ActionName has_any ("Allow", "fail", "Fail")
    or ActionStatus has_any ("fail", "Fail")
| project TimeGenerated, Computer, ThreatName, ActionName, ActionStatus
| sort by TimeGenerated desc

// Pair with 1116 (detection) to get full picture
Event
| where Source == "Microsoft-Windows-Windows Defender"
| where EventID in (1116, 1117)
| extend ThreatName = extract(@"Threat Name:s*(.+?)[
]", 1, RenderedDescription)
| summarize DetectionCount=countif(EventID==1116),
    RemediationCount=countif(EventID==1117)
    by ThreatName, Computer, bin(TimeGenerated, 1h)
| where DetectionCount > 0

Related Event IDs

1116Defender threat detected — the preceding detection event; always investigate 1116 and 1117 together

4688Process creation — what ran before and after the Defender action

4657Registry value modified — malware often sets persistence keys before Defender acts

7045New service installed — some malware installs a service before Defender quarantines the dropper

Full Detection Guide Available

This event ID has a full detection guide with investigation steps, remediation advice, and example log entries.

View full guide for Event ID 1117 →

See Event ID 1117 in your logs

Upload a Windows Event Log (.evtx) file — EventPeeker automatically detects windows defender — malware remediation action patterns, maps findings to MITRE ATT&CK, and generates an AI triage report.

Analyze EVTX Logs Free →

← All detection guides·Analyze EVTX Logs Free →