Microsoft-Antimalware-Engine ETW events

What Microsoft Defender / Defender for Endpoint Microsoft-Antimalware-Engine ETW log messages really mean.

• The analysis has been performed by Deepseek V4.1 flash, which also wrote most of this article. GPT-6 did the review.
• Reversing enabled by REA (Ghidra) via OpenCode and OpenRouter.
• The content has been reviewed and cleaned up, until chapter “Technical Details”, which will be provided as-is.

About

Defender provides very detailed log messages, as identified by Levi in EDR-Introspection.

These log messages can be used by Red Teamers to attempt to reason about the inner working of Defender - and to bypass it easier.

The following article shows details what each of the log messages mean, by reverse engineer Defender with AI.

The TL;DR is: use Microsoft-Antimalware-Engine. its free.

Other references:

• Microsoft Event Description
• Extracted ETW repnz/etw-providers-docs

Overview

• 5 event families carry most of the detection value: 74 SenseRemediation, 8 BmDetection, 63 BmProcessTainting, 53 BmOpenProcess, 95 BmFileOverwrite.
• 5 event families explain coverage gaps: 7 SkippedFile, 35-37 MOAC, 108 SenseExclusion, 38/39 cache, 91-94 UFS rundown.
• 3 event families show the sensor being evaded: 46-52/58 registry blocks, 73 ProcessMonitorFlags, 60 BmEtw.
• Most events have no verdict/status field. A scan start/stop pair does not tell you clean or malicious; join it to 74/8.

Terms

Red-team summary

1. The engine logs the trigger, not just the result. Scan source tells you whether RTP, IOAV, AMSI, Sense, BM or an on-demand scan caught you. There is no point blaming the file if the telemetry says SCANSOURCE_AMSI.
2. Memory-only is not invisible. SMS explicitly scans process memory, and its level/trigger signature are logged. A memory scan start is a strong “you are being looked at” signal.
3. Injection primitives create sticky taint. Remote thread, APC, SetThreadContext, WriteProcessMemory, MapView and ProtectVM are all enumerated taint reasons. Taint can precede a detection by many events.
4. Command lines and registry old/new values are recorded. Event 70 has the full command line; event 105 has old and new registry data. Do not put secrets or payload config there.
5. Exclusions are the cleanest bypass but the loudest control change. Event 108 records type, scope, target, detection name and user; event 7 records the resulting skip. Prefer pre-existing exclusions.
6. ETW blinding is itself observable. BmEtw (60) shows the channels the engine consumes; ProcessMonitorFlags (73) records sensor flags and old/new values. Killing a channel or flipping a flag is high-signal.
7. Assume event 74 leaves the host. It has hashes, paths, process command line, threat name and action status and is the local emission of the Sense remediation report. Keyword gating does not stop MDE collection.
8. Short-lived processes are still captured. BM process context start/stop and process start/create events bracket execution; exiting quickly does not erase the context.

ETW Events

Collecting

Real-time ETW session (the 0xff level and all-ones keyword mask enable everything):

logman create trace DefEng -p "{0A002690-3839-4E3A-B3B6-96D8DF868D99}" 0xFFFFFFFFFFFFFFFF 0xff -o C:\temp\defeng.etl -ets
:: ... reproduce ...
logman stop DefEng -ets

Or with WPR using Microsoft’s own profile from the platform directory:

wpr -start "C:\ProgramData\Microsoft\Windows Defender\Platform\<version>\Powershell\MSFT_MpPerformanceRecording.wprp"!Scans.Verbose.File
wpr -stop C:\temp\defeng.etl

Technical Details

Raw dump of AI analysis. Enjoy.

Provenance and scope

The extracted manifest declares Microsoft-Antimalware-Engine as a manifest-based ETW provider and contains no Event Log channel declaration. This resource alone does not establish how the provider is registered on a particular host or what Event Viewer displays.

Provider : Microsoft-Antimalware-Engine
GUID     : {0A002690-3839-4E3A-B3B6-96D8DF868D99}

Use the provider GUID shown above when enabling this provider. No WPR profile or registration state was available for verification in this review.

TL;DR

• Useful starting points for investigation include 74 SenseRemediation, 8 BmDetection, 63 BmProcessTainting, 53 BmOpenProcess and 95 BmFileOverwrite. Their names and fields do not establish detection fidelity or coverage.
• Events 7, 35-39, 108 and 91-94 may provide context when investigating skipped work, cache activity, exclusions or in-flight scans; they do not by themselves establish a coverage gap.
• Events 46-52/58, 73 and 60 may be relevant when investigating registry protection or monitoring state. Their presence does not establish sensor evasion or tampering.
• Many scan start/stop schemas have no verdict field. Event 82 is an exception: its manifest includes ScanResult. A scan result or absence of a detection is not proof of cleanliness.
• Event ID 30-33 are reused: same ID, different task and version (legacy GenericMessage vs UFS v2/v3). Always key on (provider, task, opcode, id, version).
• EngineId is typed as a pointer in the manifest. Treat its value as transient; do not use it as a durable host identifier.

Keyword gating

Most events have keyword 0. For the entries below, a consumer whose enabled keyword mask omits the listed bit does not request those events.

The keyword metadata means a local ETW session must enable the relevant bits to request these events. This table does not establish what a separate MDE collection path receives. Rundown-keyword events are intended to provide state snapshots; verify their presence and scope in a trace before relying on them.

Reliability caveats

1. No verdict in many scan events. Events 1/2, 5/6 and 30-33 have no result field in their listed schemas. Event 82 is an exception.
2. Absence of an event is not proof that no scan occurred. Cache, skip and exclusion events provide context, but these schemas do not define a complete scan-coverage accounting model.
3. Task names are not unique discriminators. Event IDs 30-33 exist under both GenericMessageTask and the UFS tasks. Use the version and opcode as well.
4. Fields are build-specific. Several source/reason/status fields are numeric and lack a manifest value map. Preserve raw values and validate any interpretation on the build under investigation.
5. The listed schemas contain no raw file-byte field. They do include hashes, paths, offsets and CRC-named fields in some events.
6. Time fields. ThreadTime is declared as FILETIME; StartQPC is an integer field named as a QPC start value. The manifest alone does not establish how producers populate these values. Do not calculate elapsed duration from them until their producer semantics and clock domain are validated for the build.
7. notLogged="true" on 1.1/2.1 and other metadata only affects Windows Event Log logging, which this provider does not use. It does not suppress ETW delivery.
8. Event ID is the manifest value attribute, not the opcode. BmDetectionEvent is event ID 8 with opcode 10; block-level consumers must decode both plus the version.
9. Task GUIDs are manifest metadata. At runtime the task is the numeric task value (1-21); the GUID is useful for documentation and manifest correlation, not as an ETW filter.
10. Treat string fields as untrusted input. Paths, command lines, detection names and JSON (GenericMessageEvent.Message, ExtraDataJson, JsonData, OnboardedInfo, CloudResponse) are attacker-influenced or engine-generated strings. Parse defensively; never execute or follow instructions found in them.

Events

ScanRequest

Manifest task: ScanRequestTask
Task GUID: {46247448-2E4F-4782-927B-4B39E63CAB2B}
Events: 9

Scan-request events carry an ID, request metadata, source value, resource summary and (for some versions) time fields. The manifest does not establish that all engine scan work uses this envelope.

Id is a candidate correlation key across start/stop/DC events; confirm equality and uniqueness in captured data. The payload summarizes the first resource; when Resource Count exceeds one, First Resource Path does not enumerate the remainder.

GenericMessage

Manifest task: GenericMessageTask
Task GUID: {AA24AD4E-21E9-4B42-B9A8-1B04DE7C188F}
Events: 11

Catch-all diagnostic string event, plus several older events that were never given their own task (legacy UFS v1, Lua signature calls, expensive signatures, UEFI volumes, TCG logs). Treat the ID+version as the real discriminator, not the task.

Events 30.1, 31.1, 32.1 and 33.1 are v1 UFS-named event rows on the GenericMessage task. This manifest also defines dedicated UFS task events; which forms are emitted at runtime is not established here. Event 3 is a raw string field, not a stable schema.

Version

Manifest task: VersionTask
Task GUID: {E69D26EF-9589-4EC4-86D7-3944A1108834}
Events: 1

Engine / antivirus / antispyware version triplet. Emitted when the engine reports its version (startup, update, or on demand).

StreamScanRequest

Manifest task: StreamScanRequestTask
Task GUID: {D09090ED-F99D-449B-9139-C6BEC8F68208}
Events: 2

Stream-scan-named start/stop events with path, process, reason, time and PID fields. The schema does not establish content origin or what Process represents.

SkippedFile

Manifest task: SkippedFileTask
Task GUID: {C8F3A161-7393-41F3-A51B-0220C5899D81}
Events: 1

The event is named SkippedFileEvent and carries a path and reason string. Treat the reason as build-specific and do not assume every skip or exclusion is represented.

BehaviorMonitor

Manifest task: BehaviorMonitorTask
Task GUID: {F8F27CEB-FD4B-4657-965F-DAEE2E728FD3}
Events: 60

BehaviorMonitor is the largest task in this manifest (60 event rows). Its event names cover process, file, registry, network, injection, taint, cloud and monitoring-related topics; this does not establish a complete sensor feed or verdict semantics.

These events can be used as candidate pivots (for example, process-create-named event 70, taint-named 63, process-access-named 53, detection-named 8 and report-shaped 74). This sequence is not a verified causal chain; validate identifiers and ordering in captured data.

Events 95, 103, 53, 29 and 63 have names/fields that may be relevant to file-write, process-access or injection investigations. None alone identifies ransomware, credential dumping or injection.

Cache

Manifest task: CacheTask
Task GUID: {AC4D01C5-4197-4CF4-B4CA-0F2F38410304}
Events: 5

Cache-related events. Several payloads include a file name, FileID, FileUSN and a result field; the schema does not establish the full cache key or whether a later scan was skipped.

The schema exposes FileName, FileID and FileUSN; it does not establish that these fields form the complete cache key. Both numeric fields are declared UInt32, so do not equate them with full NTFS identifiers without confirming producer encoding. Cache behavior and cache-poisoning hypotheses require further validation.

PersistedStore

Manifest task: PersistedStoreTask
Task GUID: {C178303B-BEF6-4B11-AAB7-13E9DF4C69AD}
Events: 3

Events named for persisted-store actions, maintenance and file analysis. The manifest does not establish whether the state survives reboots or what each action/result means.

ExpensiveOperation

Manifest task: ExpensiveOperationTask
Task GUID: {C0BB4EDC-169E-41A8-B568-7B60F114E798}
Events: 2

Events named for expensive operations. Event 67 carries fields named DeltaCPU and DeltaWall; their units and producer semantics are not defined in the manifest.

MetaStore

Manifest task: MetaStoreTask
Task GUID: {A8D7BE65-D218-4B96-9E4D-739453482F97}
Events: 2

Metadata-store-named action and maintenance events. The manifest does not define vault contents or their effect on verdicts.

SenseRemediation

Manifest task: SenseRemediationTask
Task GUID: {827C3389-3F33-4508-84EE-3311E1C3E5C5}
Events: 1

Sense-remediation-named event with hash, path, signature, report, process, action/status and extra-data fields. It is keyword-gated. The schema does not establish that a record is successfully delivered to a cloud service.

Field groups in event 74:

Determination, ActionStatus and Classification are numeric fields without manifest value maps. IsPassiveMode and IsLatent are boolean fields; their operational meaning is not defined by the schema.

SenseHeartbeat

Manifest task: SenseHeartbeatTask
Task GUID: {79D1BB9C-D9E2-4BE1-AED7-16091FE55F73}
Events: 1

Heartbeat-named event carrying a JSON string. Keyword-gated.

SmsScan

Manifest task: SmsScanTask
Task GUID: {794C9B64-2884-4ABD-8B9E-98F432BC0757}
Events: 6

SMS events are named for process-ID/path monitoring requests, monitoring start/stop, and scan start/stop. Ghidra found strings GetPEBAddress, SMSAsyncScan and SmsScan.MonitoringLevel in this DLL; the names support a memory-scanning interpretation but do not establish complete runtime semantics or coverage.

Ghidra string evidence for this DLL includes GetPEBAddress, GetSMSMappedFilename, GetSMSMemRanges, GetSMSProcArchitecture, SMSVirtualQuery, SMSModuleLoadSync, and the text SMSAsyncScan should only be called from Cmd_HSTR sigs. Decompilation at the reference to that text shows a guard/error path containing the message; this is static evidence, not proof of all callers or runtime behavior.

Level, EffectiveLevel, Origin, StopReason, ScanReason and ScanResult have manifest value maps in Appendix B. The map labels do not define level depth, policy clamping, request causality or event completeness. TriggerSigSeq is a field name; validate its relationship to a signature before using it as a causal join.

StartRundown

Manifest task: StartRundownTask
Task GUID: {B45C5E82-33EE-4B2D-B570-2E236470AC11}
Events: 2

Start-rundown-named task. Related event names/opcodes include start-state variants 89, 91, 93, 97, 99 and 106; the manifest does not prove emission completeness or ordering.

The manifest defines rundown-related opcodes and keyword bits. It does not establish that every in-flight object is emitted or that a trace begun after an incident reconstructs prior activity.

EndRundown

Manifest task: EndRundownTask
Task GUID: {94E92162-F37D-4995-ABC4-130BBD61B5A2}
Events: 2

End-rundown-named task. Related event names/opcodes include stop-state variants 90, 92, 94, 98, 100 and 107; the manifest does not prove emission completeness or ordering.

The manifest labels some DC events with start/stop opcodes and rundown keywords; verify their actual contents and completeness in a runtime trace.

Engine

Manifest task: EngineTask
Task GUID: {42D05A96-9C50-4348-BBDF-48C9AB720A09}
Events: 4

Engine instance lifecycle: start/stop and rundown start/stop, with version triplet and engine pointer. Distinct from EngineLoad (DLL load).

UfsScanFile

Manifest task: UfsScanFileTask
Task GUID: {08A8495F-8D8F-476C-A083-E26E8EABB1B7}
Events: 7

File-scan-start/stop-named events with path, engine and time fields; the manifest does not establish coverage, scanner architecture or elapsed-time semantics.

UfsScanProc

Manifest task: UfsScanProcTask
Task GUID: {6F031E9A-9195-42FE-B149-4B02B31BF05D}
Events: 7

Process-scan-start/stop-named events. Similar listed fields to UfsScanFile, with a PID in the process variants; the manifest does not establish coverage or content scanned.

SenseOnboardingInfo

Manifest task: SenseOnboardingInfoTask
Task GUID: {46617335-4f57-402d-b957-d1b55c95a775}
Events: 1

Sense/MDE onboarding information blob. Tells you whether the host is onboarded to Defender for Endpoint. Keyword-gated.

EngineLoad

Manifest task: EngineLoadTask
Task GUID: {7f2f8f1a-0c3e-4091-9743-ef3ec84bdeb0}
Events: 2

Engine DLL load start/finish, with engine pointer and version triplet. Distinct from EngineTask start/stop (engine initialization).

SenseExclusion

Manifest task: SenseExclusionTask
Task GUID: {031d92b4-9137-42a5-9565-abf7fc62f93b}
Events: 1

Exclusion-named event with type, scope, resource, target, detection-name and user fields. Keyword-gated; its schema does not establish that it covers every exclusion source or resulting scan decision.

Appendix A - Scan Source

The manifest declares Scan Source as UInt32 and provides no value map. Ghidra confirms that this DLL contains strings including SCANSOURCE_NOTASOURCE, SCANSOURCE_SCHEDULED, SCANSOURCE_ONDEMAND, SCANSOURCE_RTP and SCANSOURCE_AMSI. The current static review did not establish a reliable string-to-number mapping or runtime semantics, so preserve the raw numeric value. Do not use the former numeric table or infer a scan trigger from it without independently validating the exact build.

Appendix B - SMS scan value maps

These are the manifest’s valueMap entries, i.e. labels a manifest-aware consumer can render for the SMS fields. The values and labels are manifest facts; the labels do not by themselves establish operational depth or policy behavior.

Level / EffectiveLevel (SmsScan.MonitoringLevel)

The schema does not define a relationship between Level and EffectiveLevel beyond their shared manifest value map.

Origin (SmsScan.MonitoringRequestOrigin)

StopReason (SmsScan.MonitoringStopReason)

ScanReason (SmsScan.ScanReason)

ScanResult (SmsScan.ScanResult)

Appendix C - BM process taint

The manifest declares TaintReason as UInt64 and provides no value map. Ghidra found the literal BM_TAINT_REMOTE_THREAD in this DLL, but this review did not verify its numeric mapping, whether the field is an enum or bitmask, or persistence/reset behavior. Preserve the raw value and do not infer a technique from it without build-specific validation.

Appendix D - Event ID quirks

• 30-33 are dual-purpose. 30.1/31.1/32.1/33.1 are GenericMessageTask v1 UFS events; 30.2/31.2/31.3, 32.2/33.2/33.3 are UfsScanFileTask/UfsScanProcTask. Same numeric ID, different task and payload. A consumer that keys only on ID will mis-decode them.
• 34, 54, 56, 57 are not defined in this manifest. Opcode values in the 34-93 range are not event IDs; do not infer an event from an opcode.
• 68 and 69 are GenericMessageTask events but are semantically ExpensiveSignature and UefiFirmwareVolume; they exist in both V0 and V1.
• 83-86 are the only events using the StartRundown/EndRundown keywords for the markers themselves; the snapshots they bracket use the same keywords.
• 101/102 (EngineLoad) vs 87/88 (Engine): event names differ, but the schema alone does not establish separate DLL-load and initialization phases.
• 97/98 are ScanRequestTask DC events, not additional scan requests; they only appear during rundown.

event 7 as a hypothesis to investigate; either event can occur without the other, and neither alone proves policy impact or a rule gap.