Defender Internals - AI Assisted EDR Introspection

We dissect Defender’s behaviour monitoring by watching what it does during a live process injection and reverse engineer it with Ghidra-MCP and GPT 5.5.

What This Is About

When process injection is performed, Defender scans the injector’s memory. Here’s how that decision gets made internally.

I record the typical process injection Alloc/Write/Protect/CreateThread ETW telemetry and catch Defender’s ETW event opening our injector process for a memory scan. From there, we can reverse every frame in the callstack and trace the decision straight into mpengine.dll.

I use Ghidra-MCP on mpengine.dll to reverse Defender’s internals, covering the architecture, key data structures, and the decision path behind what we observed.

The goal is to walk away with a concrete mental model of Defender’s EDR pipeline. One you can actually use when building evasion tools. In this case, bypassing Defenders process injection detections is left as an exercise to the reader.

Last Updated: 18.07.2026

Considerations

• Defender only, no MDE
• Raw LLM analysis and more details can be found in the DefRev GitHub repo.
• ETW recordings by RedEdr
• Detonation with Detonator Agent
• All function and data structure names are unofficial — invented by the agent. No PDB was used. Names are only consistent within this article.
• This blog is part hand-written, part LLM output (reviewed, and trimmed).
• Large tables and references to Defender internals are mostly LLM-generated.
• I use GPT 5.5 via OpenCode & CodeNomad via GHCP subscription.
• We work with recording ETW events rededr-redtest.json

Final Architecture Overview

Defender works like this:

• It receives ETW events
• The ETW events are translated into Defender internal BmBehaviorPayload
• EtwEventNotification, of type INotification are generated, containing reference to BmBehaviorPayload
• Send INotification to a per-process queue
• Workers get the INotifications from the queue and act upon it (e.g. memory scan for image loads)

   ┌───────┐ becomes  ┌───────────────────┐                             
   │  ETW  ├─────────►│ BmBehaviorPayload │                             
   └───────┘          └───────────────────┘                             
                                 ▲                                      
                                 │has                                   
                      ┌──────────┴───────────┐  is   ┌────────────────┐ 
                      │ EtwEventNotification ├──────►│  INotification │ 
                      └──────────────────────┘       └────────────────┘ 

Note: The queue is per-process (ProcessContext). The actual work is kicked off with an async NotificationItem.

INotification objects are processed by worker threads. Defender does different things depending on their type and content. In our case, it kicked off the ScanProcess subsystem:

                                    ScanProcess                                    
┌─────────┐ INotification ┌──────────────────────────────────┐                     
│ Queue   ├──────────────►│  0x6   ClassifyImageModuleEvent  │                     
└─────────┘               │  0x5   ProcessScanCleanupChecks  │     ┌──────────────┐
                          │  0x4   CheckProcessHollowing     ├────►│ OpenProcess  │
                          └──────────────────────────────────┘     └──────────────┘

Some INotfication classes:

• ProcessNotification
• FileNotification
• InternalNotification
• EtwNotification
• RegistryNotifcation

Additionally BM_MetaStore is used to cache scan verdicts (suspicious, friendly) for processes, which is used heavily for performance:

          Input                Data Structures             Output

                             ┌──────────────────┐                                  
         ┌────────┐          │                  │      ┌──────────────┐            
         │  ETW   │          │  ProcessContext  │      │ OpenProcess  │            
         └───┬────┘          │                  │      └──────▲───────┘            
             │               └────────┬─────────┘             │                    
    ┌────────▼──────────┐             │               ┌───────┴────────┐           
    │ BmBheaviorPaylaod │             │               │  Process Scan  │           
    └────────┬──────────┘      ┌──────┴───────┐       └───────▲────────┘           
             │           Query │              │ Query         │                    
             │            ────►│ BM_MetaStore │◄───           │                    
      ┌──────▼────────┐        │              │        ┌──────┴───────┐            
      │ INotification │        └──────────────┘        │  Dispatcher  │            
      └──────┬────────┘                                └──────▲───────┘            
             │               ┌──────────────────┐             │                    
             └──────────────►│      queue       ├─────────────┘                    
                             └──────────────────┘                                  

The Experiment: Process Injection

We’re going to analyze a process injection. It follows the usual Alloc/Write/Protect/CreateThread sequence:

1. VirtualAlloc()
2. WriteProcessMemory()
3. Sleep 5 seconds
4. VirtualProtectEx() -> RWX
5. Sleep 5 seconds
6. CreateRemoteThread()

Execution:

PS C:\Users\hacker\Desktop\b> .\redtest3.exe 2
==============================================
Red Team Test Tool - APC & Process Injection
==============================================

2026-06-29 07:56:30.968 UTC [+] Shellcode initialized at 0x000002406AC84C70 (size: 102400 bytes)

=== TEST 2: Process Spawn with Shellcode Allocation ===

2026-06-29 07:56:30.968 UTC [Main] Spawning child process (notepad.exe)...
2026-06-29 07:56:31.046 UTC [Main] Process created - PID: 4868, TID: 3744
2026-06-29 07:56:31.046 UTC [Main] Allocated 102400 bytes at 0x00000221E3A70000 in target process
2026-06-29 07:56:31.046 UTC [Main] Wrote 102400 bytes of shellcode to target process
2026-06-29 07:56:31.046 UTC Wait 5 seconds before changing memory protections...

2026-06-29 07:56:36.064 UTC [Main] Changed memory protection to PAGE_EXECUTE_READ
2026-06-29 07:56:36.064 UTC [Main] Shellcode address: 0x00000221E3A70000
2026-06-29 07:56:36.064 UTC Wait 5 seconds before executing shellcode in the target process...

2026-06-29 07:56:41.077 UTC [Main] Creating remote thread to execute shellcode...
2026-06-29 07:56:41.077 UTC [Main] Remote thread created successfully (TID: 3568)
2026-06-29 07:56:41.078 UTC [Main] Resuming child process...
2026-06-29 07:56:41.078 UTC [Main] Waiting for remote thread to complete...
2026-06-29 07:56:41.109 UTC [Main] Process is running. Waiting a second before terminating...

2026-06-29 07:56:42.415 UTC [Main] Terminating child process...
2026-06-29 07:56:42.515 UTC [Main] Test 2 done

Or in short:

Process Start:        07:56:30.953
VirtualAlloc:         07:56:31.046
VirtualProtectEx():   07:56:36.064  # +5s
CreateRemoteThread(): 07:56:41.077  # +5s

Looking at the ETW events generated by Defender, we can see its behaviour:

1. injector: VirtualAlloc()
2. injector: WriteProcessMemory()
3. injector: Sleep 5 seconds
4. injector: VirtualProtectEx()
5. MsMpEng.exe: Memory-scans injector
6. injector: Sleep 5 seconds
7. injector: CreateRemoteThread()
8. MsMpEng.exe: Opens injector, but no memory scan performed

Defender reaction for VirtualAlloc() / VirtualProtectEx(RWX):

Defender reaction for CreateRemoteProcessThread():

mpengine.dll has the following base address:

name: mpengine.dll base: 0x7ffeefb40000 size: 0x11f1000

Recording of all ETW events: rededr-redtest.json

ETW Recording analysis

First step: feed the full ETW trace to Claude Opus 4.6 and ask it to map out the timeline. Claude correlates the injector’s and Defender’s actions from raw ETW events with surprising accuracy.

Prompt:

The following json are ETW recordings of a projecess injector “redtest3.exe”, and windows defender “msmpeng.exe”. Defender does an openprocess, and we see with ETW-TI that it reads memory regions of the injector. Upon which activities of the injector does defender react (remote alloc, create remote thread etc.), and which parts of the injector does it memory scan? [rededr-redtest.json]

rededr-redtest.json

Injector Activity Timeline

1. Process Creation (redtest3.exe spawns notepad.exe)

• Event #96: ProcessStartStart — notepad.exe (PID 4868) created by redtest3.exe (PID 3620)
• Event #97: Initial thread (TID 3744) created in notepad.exe

2. Remote Memory Allocation (VirtualAllocEx — RWX)

• Event #75: KERNEL_THREATINT_TASK_ALLOCVM — redtest3.exe allocates 102,400 bytes with RWX protection at address 0x221E3A70000 in notepad.exe (PID 4868)
  • Stack trace shows: redtest3.exe:.text → KERNELBASE.dll (VirtualAllocEx) → ntdll.dll

3. Memory Protection Change (RWX → R-X)

• Event #157: KERNEL_THREATINT_TASK_PROTECTVM — redtest3.exe changes the 102,400-byte region from RWX → R-X (PAGE_EXECUTE_READ) in notepad.exe
  • This is the VirtualProtectEx call after writing shellcode

4. Remote Thread Creation

• Event #158: ThreadStartStart — new thread (TID 3568) created in notepad.exe (PID 4868) with startaddr = 0x221E3A70000 (the allocated shellcode address)
  • Stack trace confirms it was created by redtest3.exe via CreateRemoteThread

Defender’s Reactions

Reaction to Process Creation (immediate — Events #42-#51)

Defender immediately opens redtest3.exe’s process with various access rights:

• Event #42: OpenProcess with desiredaccess=1536 (triggered from mpengine.dll scan path via mprtp.dll)
• Event #43: OpenProcess with desiredaccess=4096 (PROCESS_QUERY_INFORMATION)
• Events #48-49: More OpenProcess calls with desiredaccess=4096
• Event #51: OpenProcess with desiredaccess=5136 (PROCESS_QUERY_INFO + PROCESS_VM_READ)

Reaction to Remote Alloc/Write — Full Memory Scan (Events #99-#156)

After the VirtualAllocEx, Defender performs an extensive memory scan of redtest3.exe itself:

What Defender reads (PEB/TEB introspection):

• Events #71-#74: Initial reads of the process’s TEB/PEB structures (8-byte and 136-byte reads from the thread environment block and ntdll data)

What Defender reads (loaded module enumeration via PEB_LDR_DATA):

• Events #99-#135: ~35 consecutive KERNEL_THREATINT_TASK_READVM reads of 312 bytes each from heap region 0x240xxxx — this is Defender walking the PEB_LDR_DATA linked list, reading each LDR_DATA_TABLE_ENTRY to enumerate all loaded DLLs in redtest3.exe

What Defender reads (redtest3.exe’s PE image — the actual malware scan):

• Events #136-#156: Defender reads the entire redtest3.exe PE image in 4KB pages:
  • PE headers at base 0x7FF6B4D40000 (264 bytes, then 280 bytes for DOS/PE/Optional headers)
  • ~15 sequential 4KB reads covering the .text section (code), import tables, and data sections
  • This is the signature/heuristic scan of the injector’s code

Reaction to Remote Thread Creation (Events #159-#161)

• Event #159: OpenProcess desiredaccess=4096 — Defender re-inspects redtest3.exe after the CreateRemoteThread
• Event #160: OpenProcess desiredaccess=5136 — deeper inspection with VM_READ rights
• Event #161: OpenProcess desiredaccess=4096 via sechost.dll path — likely an ETW-based detection callback

Summary Table

Key insight: Defender’s heaviest reaction is to the remote RWX allocation + write. It doesn’t scan the target (notepad.exe) memory here — it scans the injector itself (redtest3.exe’s PE image and loaded modules), presumably to match it against behavioral signatures and determine if the process performing injection is malicious.

Defender’s VirtualAlloc() Reaction

Let’s dig into the MsMpEng.exe callstack for the THREATINT_TASK_ALLOCVM event. This is Defender responding to VirtualAllocEx / VirtualProtectEx:

Details of the callstack of Defender’s ETW event opening our process with VM_READ permissions:

etw_process: MsMpEng.exe
etw_provider_name: Microsoft-Windows-Kernel-Audit-API-Calls
event: PspLogAuditOpenProcessEvent
type: etw
desiredaccess: 0x1410
etw_pid: 0x4ec
etw_tid: 0xd0c
etw_time: 2026-06-29 07:56:31.032 UTC
id: 0x62
returncode: 0x0
targetprocessid: 0xe24
trace_id: 0x29
callstack:
  addr: 0x7fff078112c4 addr_info ntdll.dll idx: 0x0
  addr: 0x7fff04dd246e addr_info KERNELBASE.dll idx: 0x1
  addr: 0x7ffeefc783ce addr_info mpengine.dll idx: 0x2
  addr: 0x7ffeefc781c7 addr_info mpengine.dll idx: 0x3
  addr: 0x7ffeefdd33d7 addr_info mpengine.dll idx: 0x4
  addr: 0x7ffeefdd3010 addr_info mpengine.dll idx: 0x5
  addr: 0x7ffeefc66c8e addr_info mpengine.dll idx: 0x6
  addr: 0x7ffeefc65ae0 addr_info mpengine.dll idx: 0x7
  addr: 0x7ffeefc65911 addr_info mpengine.dll idx: 0x8
  addr: 0x7ffeefc6512c addr_info mpengine.dll idx: 0x9
  addr: 0x7ffeefc64fd6 addr_info mpengine.dll idx: 0xa
  addr: 0x7ffeefc648d5 addr_info mpengine.dll idx: 0xb
  addr: 0x7ffeefc64694 addr_info mpengine.dll idx: 0xc
  addr: 0x7ffef042f698 addr_info mpengine.dll idx: 0xd
  addr: 0x7ffef042f583 addr_info mpengine.dll idx: 0xe
  addr: 0x7fff077d28ea addr_info ntdll.dll idx: 0xf
  addr: 0x7fff077a5eb6 addr_info ntdll.dll idx: 0x10
  addr: 0x7fff05b6259d addr_info KERNEL32.DLL idx: 0x11
  addr: 0x7fff077caf78 addr_info ntdll.dll idx: 0x12

The consumed signal is Threat-Intelligence memory-protection telemetry, normalized into BM_Etw_CodeInjection/protectvm, which then drives BM taint propagation and a core-engine process-memory scan.

From ETW to Process Scan

So what does Defender actually do between receiving the ETW event and opening our process for a memory scan?

Consumption flow:

Subsystems

Walking through the subsystems Defender brings to bear on a single injection event:

High-Level Diagram

The whole chain from injector actions to the memory scan, with function names.

Injector
  VirtualAlloc
  WriteProcessMemory
  VirtualProtectEx -> RWX
        |
        v
Kernel Threat-Intelligence ETW
  KERNEL_THREATINT_* memory/protect telemetry
        |
        v
Defender ETW/BM parser
  BmEtw_HandleProtectVmCodeInjectionEvent
  reads PID/create-time + base/size/protection fields
        |
        v
Internal BM normalization
  BmEtw_EmitBehaviorEvent
  event id: 0x402e
  name: BM_Etw_CodeInjection
  subtype: protectvm
        |
        v
BM behavior dispatcher
  BmBehaviorCallbackThunk
  BmDispatchBehaviorEvent
  BmHandleEtwCodeInjectionEvent
        |
        v
Process graph / taint logic
  PropagateInjectionTaintToTargetProcess
  ShouldSuppressAsrForTaintedProcess
  ShouldSuppressAsrForFriendlyOrAlreadyTaintedProcess
        |
        +--> Friendly/session check
        |      BmRunFriendlyTrustCheckWithSessionContext
        |      ProcessIdToSessionId(source_pid)
        |      OpenProcess(0x1000)
        |      -> Kernel-Audit event 0x98
        |
        v
Reinspection request
  MarkProcessTaintedAndNotify
  Bm_ReinspectTrackedProcess
        |
        v
Scan queue / worker
  ThreatAnalysisWorkerThread
  ProcessSingleWorkItem
  ScanItemWaitAndDispatch
  ProcessScanQueue
        |
        v
Resource scan pipeline
  DispatchResmgrScanRequest
  RunScanRequestStateMachine
  ExecuteDirectedResourceScan
  DispatchResourceUriScan
  RunProcessResourceScanWithTelemetry
  OrchestrateProcessMemoryScan
        |
        v
Core engine command path
  BridgeProcessScanToEngineCommand
  Engine_ScanCommandHandler
  RunUfsScanFileCommandWithContext
  ExecuteUfsScanFileCommand
  ParseAndDispatchScanUri
        |
        v
Process memory scanner
  OpenAndInspectProcessMemoryImage
  OpenProcess(0x418)
  GetProcessTimes
  Query image memory info
  VirtualQueryEx
  Read MZ/PE headers and sections
  scan memory-backed process image
        |
        v
Scan result / verdict
  returned through scan pipeline
  updates BM/RTP state

So the normalized ETW event is eventually consumed as an INotification-style object, specifically an EtwEvent notification (tag 0x26). But the internal BM event (BM_Etw_CodeInjection / protectvm) is not itself the INotification; it is the decoded behavior payload carried inside the EtwEvent notification.

High-Level Function Table

Detailed description of imporant Defender functions involved in the ETW-to-memoryscan.

Memory Scan/Read Details

Analyzing the stacktrace of a READ_VM ETW event. Here Defender really reads parts of the injectors process memory.

How It Fits:

Earlier:
VirtualProtectEx -> RWX
  -> Threat-Intelligence telemetry
  -> Defender emits BM_Etw_CodeInjection / protectvm
  -> BM taints/schedules process reinspection
  -> Defender OpenProcess(0x418)

Now:
OpenAndInspectProcessMemoryImage
  -> ReadProcessImageBaseAddressWrapper
  -> READVM 8 bytes from injector
  -> QueryProcessImageMemoryInfo
  -> VirtualQueryEx
  -> read MZ/PE headers and sections
  -> process-memory/image scan

The responsible scan owner remains OpenAndInspectProcessMemoryImage; ReadProcessImageBaseAddressWrapper is just the low-level read primitive used by that scanner.

Scanned bytes:

As there is no information about the source process memory regions, we cannot infer much more.

Process Memory Scan Details

What does Defender exactly scan for?

The effective process memory scan path is:

ExecuteProcessMemoryScan
  -> EnumerateAndScanProcessMemoryRegions    ("find unbacked executable region")
  -> UpdateAndScanProcessMemoryRegionMap
  -> QueueOrScanProcessMemoryRegion
  -> FlushQueuedProcessMemoryScanRanges

What they do:

The important logic in EnumerateAndScanProcessMemoryRegions:

GetSystemInfo()
for address from min_app_address to max_app_address:
    VirtualQueryEx(process, address, mbi)

    if mbi.State == MEM_COMMIT:
        skip PAGE_NOACCESS
        skip guard/no-cache/write-combine-like modifier pages
        optionally require executable-ish protection depending on scan flags

        if mbi.Type == MEM_IMAGE:
            count image region
            if protection is PAGE_EXECUTE_READWRITE or PAGE_READWRITE:
                scan/queue it directly
            else:
                check mapped image path interest
                if interesting, scan/queue it

        else:
            MEM_PRIVATE / MEM_MAPPED:
                build region descriptor
                scan/queue it

The non-image branch is the “unbacked” part:

if mbi.Type != MEM_IMAGE:
    local descriptor type = MEM_PRIVATE or MEM_MAPPED
    QueueOrScanProcessMemoryRegion(...)

The actual “find suspicious/unbacked memory regions” behavior is not centered in OpenAndInspectProcessMemoryImage. That function is image-oriented. The VAD-style scanner is centered in ExecuteProcessMemoryScan and especially EnumerateAndScanProcessMemoryRegions / UpdateAndScanProcessMemoryRegionMap.

The path relationship is likely:

BM_Etw_CodeInjection/protectvm
  -> reinspection
  -> processmemoryscan resource
  -> ExecuteProcessMemoryScan
  -> VirtualQueryEx full VA walk
  -> MEM_PRIVATE / MEM_MAPPED / interesting MEM_IMAGE regions
  -> ReadProcessMemory chunks
  -> scan callback / engine verdict

OpenAndInspectProcessMemoryImage answers “what is this process image and can I build a scanable PE view?”
EnumerateAndScanProcessMemoryRegions answers “what committed regions in this process should be memory-scanned?”

CreateThread() Reaction

Now let’s look at the last three Defender ETW events - the ones triggered by CreateRemoteThread:

The CreateRemoteThread reaction shown here looks like BM/HIPS correlation and process inspection, not a confirmed memory scan of the injector/source. The 0x1410 open means Defender requested PROCESS_VM_READ capability, but without subsequent VM-read or scanner-stack events it does not look like the source was actually scanned. A prior VirtualProtectEx verdict/cache is a plausible reason for no second scan.

Your initial trigger is the remote thread creation telemetry:

source process: redtest3.exe / pid 0xe24
target process: processid 0x1304
target thread: threadid 0xdf0
start address: 0x221e3a70000
win32 start address: 0x221e3a70000

Defender/BM sees this as a relationship event:

source process created or started a thread in target process
thread start address is inside the target process address space
prior telemetry may include alloc/protect/write events
behavior becomes RemoteThreadCreate / CodeInjection relationship

Earlier events in your sequence matter:

VirtualAllocEx / remote allocation -> allocvmremote style telemetry
WriteProcessMemory -> write/cross-process memory relationship
VirtualProtectEx -> protectvm telemetry with base, size, new protection
CreateRemoteThread -> remotethread telemetry with target thread/start address

VirtualProtectEx is often the stronger scan trigger because it provides the exact remote region and protection transition. CreateRemoteThread often acts as correlation/finalization: “this previously suspicious executable region is now being executed.”

For your source-process opens:

0x1000 at 07:56:41.082 -> query-only open of source pid 0xe24
0x1410 at 07:56:41.132 -> read-capable open of source pid 0xe24
0x1000 at 07:56:43.128 -> delayed query-only open, stack includes sechost.dll

My interpretation:

The shown source-process opens do not prove a source memory scan.
The 0x1000 opens cannot read memory.
The 0x1410 open can read memory, but the stack pattern looks like BM inspection/correlation, not the EMS memory scan path.

The lack of READ_VM events is therefore most likely because the source process was not actually memory-scanned at remote-thread time. The BM path explicitly checks Bm_MetaStoreLookupVerdictByProcessKey. If the source or target already has a verdict from the earlier VirtualProtectEx or code-injection telemetry, the later CreateRemoteThread event may only update relationships/taint/monitoring and skip redundant scanning.

Detection Data Structures

 ┌───────┐ becomes  ┌───────────────────┐                               
 │  ETW  ├─────────►│ BmBehaviorPayload │                               
 └───────┘          └───────────────────┘                               
                               ▲                                        
                               │has                                     
                    ┌──────────┴───────────┐  is   ┌────────────────┐   
                    │ EtwEventNotification ├──────►│  INotification │   
                    └──────────────────────┘       └────────────────┘   

Simplified mental model:

Detailed model:

ETW to INotification to Scan

[1] EtwRawEventRecord
    Raw Windows ETW event
    Provider: Microsoft-Windows-Threat-Intelligence
    Example: memory protect / RWX transition
        |
        | decoded using
        v
[2] EtwSchemaInfo
    TDH/formatter metadata
        |
        v
[3] EtwDecodedFieldSet
    source pid/create-time
    target pid/create-time
    vmbaseaddress
    vmregionsize
    protectionmask = RWX
    lastprotectionmask
        |
        | normalized by Defender ETW converter
        v
[4] BmBehaviorPayload
    bm_event_id = 0x402e
    bm_event_name = BM_Etw_CodeInjection
    subtype = protectvm
    process identity = PersistentProcessId
    extra fields = VM/protection fields
        |
        | wrapped for notification submission
        v
[5] BmNotificationEnvelope
    temporary submission descriptor
        |
        | notification manager creates/routes
        v
[6] EtwEventNotification : INotification
    notification tag = 0x26
    payload = BmBehaviorPayload
        |
        | inserted into target/source process queue
        v
[7] ProcessNotificationQueueEntry
    stored in BmProcessContext queue
        |
        | worker consumes queue
        v
[8] BmBehaviorDispatchView
    reads payload from EtwEventNotification
    switches on bm_event_id 0x402e
        |
        v
[9] BM code injection handler
    BmHandleEtwCodeInjectionEvent
    PropagateInjectionTaintToTargetProcess
        |
        v
[10] ProcessMemoryScanResource
    process:// or \\.\proc\ scan target
        |
        v
[11] OpenAndInspectProcessMemoryImage
    OpenProcess(0x418)
    VirtualQueryEx
    read PE/image memory
    scan process memory

INotification Data Structure

INotification is not a simple flat payload struct. It is a polymorphic, ref-counted interface. The common “fields” are mostly exposed through virtual methods; concrete payload fields live in derived classes:

• ProcessNotification
• InternalNotification
• FileNotification, RegistryNotification
• EtwNotification, and others

For the ETW path, the final object reaching QueueBmNotification is an INotification subclass.

Since INotification is Defender’s core action unit, here’s a breakdown of each subtype.

INotification: Base

INotification: Process

INotification: Internal

INotification: Etw

INotification: File

INotification: Registry

INotification: RemoteThreadCreate

INotification: Network

INotification: Desktop

Notification Tags

Top level INotification notification tags:

The Verdict Cache: BM_MetaStore

BM_MetaStore is Defender BM’s global correlation object. Its core job: maintain a process-context map and a verdict cache that the rest of BM queries constantly.

The verdict API is used aggressively as a suppression gate before:

• process creation tracking
• ETW dispatch
• remote-thread reporting
• injection taint propagation
• full process evaluation

It contains:

• live process-context maps and verdict caches
• routing from BM/ETW events back into per-process state
• typed durable MetaVault records backed by SQLite
• all indexed by ProcessContext

                         ┌──────────────────┐                                  
     ┌────────┐          │                  │      ┌──────────────┐            
     │  ETW   │          │  ProcessContext  │      │ OpenProcess  │            
     └───┬────┘          │                  │      └──────▲───────┘            
         │               └────────┬─────────┘             │                    
┌────────▼──────────┐             │               ┌───────┴────────┐           
│ Event Translation │             │               │  Process Scan  │           
└────────┬──────────┘      ┌──────┴───────┐       └───────▲────────┘           
         │           Query │              │ Query         │                    
         │            ────►│ BM_MetaStore │◄───           │                    
  ┌──────▼────────┐        │              │        ┌──────┴───────┐            
  │ INotification │        └──────────────┘        │  Dispatcher  │            
  └──────┬────────┘                                └──────▲───────┘            
         │               ┌──────────────────┐             │                    
         └──────────────►│      queue       ├─────────────┘                    
                         └──────────────────┘                                  

Live Correlation

The metastore facade supports correlation between newly observed events and existing live process state.

Examples:

• process ID plus creation time is resolved into a ProcessContext,
• events are routed to the right process context,
• process image paths are resolved/cached,
• process verdicts are reused across ETW/module/process events,
• remote-thread and injection events query target-process state before reporting.

Verdict / Suppression Cache

It can check:

• live ProcessContext verdict state,
• in-memory verdict cache,
• resolved image path verdict,
• persisted or computed friendly/excluded state.

Callers use the returned flags to suppress or modify behavior reporting.

Example behavior:

• A target process known as friendly/excluded can suppress remote-thread/code-injection behavior.
• A cached verdict avoids expensive path, signature, or metadata checks.
• If no cache hit exists, the path may be resolved and a fresh verdict may be inserted into cache.

Core Interface

Important Offsets

• BmController + 0x08: object refcount used by Bm_GetMetaStore.
• BmController + 0x68: live tracked process-context map.
• BmController + 0x70: durable/query MetaStore object used by correlated-record lookup.
• BmController + 0x90: ETW/metastore sink dispatch state.
• BmController + 0x98: lock around durable MetaStore query path.
• BmController + 0x2c8: critical section for in-memory verdict cache.
• BmController + 0x2f8..0x350: verdict cache map plus eviction/ring state.
• ProcessContext + 0x198/+0x1a0: process key stored on context.
• ProcessContext + 0xb28: cached process verdict/suppression flags.

Verdict Cache Semantics Bm_MetaStoreLookupVerdict has three observed modes:

outFlags observed meaning:

• 0x2: friendly/excluded/suppress bit. This is the bit returned by Bm_MetaStoreLookupVerdictByProcessKey.
• 0x4: secondary cached action/suppression bit used by Bm_EvaluateProcess; exact product label is still unresolved.
• Other bits are not confidently labelled from the current xrefs.

Example usage:

• Bm_EvaluateProcess calls LookupVerdict(ms, bmContext+0x10, &flags, 0, imagePath). If flags & 0x2 or flags & 0x4, it takes an early action/suppression path instead of normal full evaluation.
• ProcessContextMap_FindOrCreateContext calls mode 1; if flags & 0x2 and the caller does not allow excluded contexts, it refuses to create the process context and returns 0x80004004.
• ReportRemoteThreadInjectionBehavior calls mode 2 for the target process. If flags & 0x2, it suppresses the remote-thread/injection behavior report.
• BmEtw_DispatchEventRecord resolves PID to process key and calls Bm_MetaStoreLookupVerdictByProcessKey; if true, the ETW event is dropped before family-specific dispatch.
• ProcessContextPushNotification checks ProcessContext + 0xb28; if the excluded bit is set, normal notifications are skipped as "Excluded".

MetaVault Sqlite DB

The durable layer is a separate MetaStore::...::MetaStore object constructed by MetaStore_Construct and initialized by MetaStore_InitializeSQLiteVaults.

RTTI and strings show typed record classes. These are logical vaults/tables over the SQLite backend.

Representative tables/schema strings observed:

• SQLiteGlobals
• BmProcessInfo
• BmHipsRuleInfo
• BmFileInfo
• BmFileActions
• BmFileStartupActions
• ProcessBlockHistory
• FileHashes
• AmsiFileCache
• AttributeCounts
• AttributePersistContext
• AtomicCounters
• RollingQueuesTables
• RollingQueuesValues
• NetworkIpFirewallRules
• NetworkIpFirewallRulesOutgoing
• AnomalyInfo
• AnomalyTables
• RansomwareDetections
• BackupProcessInfo
• FolderGuardPaths
• DynSigRevisions
• SdnEx

SQLite Database

Yes — it is file-backed SQLite.

The DB path is constructed as:

<Defender engine/base directory>\mpenginedb.db

This file acts as the primary ledger for Microsoft Defender’s local operations. It is a SQLite database that primarily handles:

• Protection History: It logs actions taken by Defender, such as blocking an app via Controlled Folder Access or flagging Potentially Unwanted Applications (PUAs).
• Scan Caching: It stores identifiers and checksums of previously scanned files so Defender doesn’t have to scan the exact same safe files repeatedly, saving system resources.

C:\ProgramData\Microsoft\Windows Defender\Scans\mpenginedb.db:

drwxr-xr-x 2 root root     4096 Jul  6 16:12 BackupStore
drwxr-xr-x 2 root root     4096 Jul  6 16:12 CleanFileTelemetry
-rwxr-xr-x 1 root root  2117664 Jul  6 16:12 DefenderEcsCache.bin64
drwxr-xr-x 2 root root     4096 Jul  6 16:12 FilesStash
drwxr-xr-x 7 root root     4096 Jul  6 16:12 History
-rwxr-xr-x 1 root root 35767028 Jul  6 16:12 mpcache-3A136A7CCAA76D4ABC462E0EF513DFB3C597DF80.bin
-rwxr-xr-x 1 root root  1449336 Jul  6 16:12 mpcache-3A136A7CCAA76D4ABC462E0EF513DFB3C597DF80.bin.01
...
-rwxr-xr-x 1 root root      120 Jul  6 16:12 MpDiag.bin
-rwxr-xr-x 1 root root   512000 Jul  6 16:22 mpenginedb.db
-rwxr-xr-x 1 root root    24192 Jul  6 16:12 MsMpEngCP.exe
-rwxr-xr-x 1 root root    55200 Jul  6 16:12 MsMpEngSvc.dll
drwxr-xr-x 3 root root     4096 Jul  6 16:12 RtSigs

Schema:

CREATE TABLE SQLiteGlobals(ID INTEGER PRIMARY KEY NOT NULL, Version INTEGER NOT NULL, Current BOOLEAN NOT NULL, LastUpdated TEXT NULL);
CREATE TABLE AttributePersistContext(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, FilePath NVARCHAR NULL, Context NVARCHAR NULL, InsertTime INTEGER NULL, ExpireTime INTEGER NULL);
CREATE TABLE BackupProcessInfo(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, FilePath NVARCHAR NULL, FirstStartTime INTEGER NULL, NextUSN INTEGER NULL, AutomaticRemovalPolicy INTEGER NULL, ImpactedCBPNameSpaces NVARCHAR NULL, InstanceTimeStamp INTEGER NULL);
CREATE TABLE BmFileActions(ID INTEGER PRIMARY KEY NOT NULL, FileInfoId INTEGER NOT NULL, ThreatRecordId INTEGER, Action INTEGER);
CREATE TABLE BmFileInfo(ID INTEGER PRIMARY KEY NOT NULL, NormalizedPathHash INTEGER, DosPathHash INTEGER, StructVersion INTEGER NOT NULL, NormalizedPath NVARCHAR NOT NULL, DosPath NVARCHAR NOT NULL, Wow64Context BLOB, MetaContext BLOB, IsFromWeb TINYINT DEFAULT 0, IsExecutable TINYINT DEFAULT 0);
CREATE TABLE BmFileStartupActions(ID INTEGER PRIMARY KEY NOT NULL, FilePathHash INTEGER NULL, FilePath NVARCHAR NULL, ActionFlags INTEGER NULL, ProcessStartCount INTEGER NULL, FdrFlags INTEGER NULL, FdrThreatRecordId INTEGER NULL, EvaluatorThreatRecordId INTEGER NULL, TrustedInstallerThreatRecordId INTEGER NULL, LFRThreatRecordId INTEGER NULL);
CREATE TABLE BmHipsRuleInfo(ID INTEGER PRIMARY KEY NOT NULL, ProcessInfoId INTEGER NOT NULL, RuleAction INTEGER NOT NULL, RuleId BLOB, IsAudit INTEGER NOT NULL DEFAULT 0, IsInherited INTEGER NOT NULL DEFAULT 0, State INTEGER NULL);
CREATE TABLE BmProcessInfo(ID INTEGER PRIMARY KEY NOT NULL, PPIDHash INTEGER NOT NULL, ProcessStartTime INTEGER NOT NULL, PID INTEGER NOT NULL, StructVersion INTEGER, ImageFileName NVARCHAR, MonitoringFlags_Flags INTEGER NOT NULL, MonitoringFlags_VmHardenType INTEGER NOT NULL, MonitoringFlags_ExemptVmHardenedTypes INTEGER NOT NULL, CommandLineArgs NVARCHAR, HipsInjectionId BLOB, FolderGuardId BLOB, Flags INTEGER, LsassReadMemId BLOB, MonitoringFlags_Flags2Low INTEGER, MonitoringFlags_Flags2High INTEGER);
CREATE TABLE DynSigRevisions(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, SdnRevision INTEGER NULL, EsuRevision INTEGER NULL, BFRevision INTEGER NULL, EntCertRevision INTEGER NULL, TamperRevision INTEGER NULL, AGBlobRevision INTEGER NULL, BFFileAllowRevision INTEGER NULL, BFFileBlockRevision INTEGER NULL, BFCertAllowRevision INTEGER NULL, BFCertBlockRevision INTEGER NULL);
CREATE TABLE Engine(ID INTEGER PRIMARY KEY NOT NULL, EngineVersion VARCHAR(20) NULL, SigVersion VARCHAR(20) NULL);
CREATE TABLE FileLowFiAsync(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, FileName NVARCHAR NULL, SigSeq INTEGER NULL, SigSha BLOB NULL, SigIsSync BOOLEAN NULL, InstanceTimeStamp INTEGER NULL);
CREATE TABLE FolderGuardPaths(ID INTEGER PRIMARY KEY NOT NULL, UserIdHash INTEGER NOT NULL, UserId NVARCHAR, GUID BLOB, Path NVARCHAR);
CREATE TABLE ProcessBlockHistory(ID INTEGER PRIMARY KEY NOT NULL, ProcessPath TEXT NOT NULL, TimeStamp INTEGER NOT NULL, TargetPath TEXT, RuleId BLOB, IsAudit BOOLEAN NOT NULL DEFAULT 0, Action INTEGER NOT NULL, ProcessTaintReason INTEGER NOT NULL DEFAULT 0, ProcessIntegrity INTEGER NOT NULL);
CREATE TABLE RansomwareDetections(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, DetectionGuid NVARCHAR NULL, LkgTS INTEGER NULL, NextUSN INTEGER NULL, DetectionTS INTEGER NULL, ProvisionalRemedComplTS INTEGER NULL, RemedComplTS INTEGER NULL, ImpactedCBPNameSpaces NVARCHAR NULL, InstanceTimeStamp INTEGER NULL);
CREATE TABLE SdnEx(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, CurrentCount INTEGER NULL);
CREATE TABLE SystemFileCache(ID INTEGER PRIMARY KEY NOT NULL, InfectedFileSHAHash INTEGER NULL, InfectedFileSHA NVARCHAR NULL, ProcFileIDSystemFileHash INTEGER NULL, ProcFileId BLOB NULL, SystemFilePath NVARCHAR NULL, CleanFileSha NVARCHAR NULL, CleanFileShaHash INTEGER NULL, InstanceTimeStamp INTEGER NULL);
CREATE TABLE SystemRegistryCache(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, FileIDHash INTEGER NULL, RegPath NVARCHAR NULL, RegOperation INTEGER NULL, NewRegType INTEGER NULL, OldRegType INTEGER NULL, OldRegData BLOB NULL, NewRegData BLOB NULL, InstanceTimeStamp INTEGER NULL);
CREATE TABLE ValueMapArray(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, RecordType INTEGER NULL, ValueMapArrayBlob BLOB NULL, InstanceTimeStamp INTEGER NULL);
CREATE TABLE FileHashes(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, VSN INTEGER NULL, FileID INTEGER NULL, USN INTEGER NULL, InstanceTimeStamp INTEGER NULL, SHA1 BLOB NULL, MD5 BLOB NULL, SHA256 BLOB NULL, LSHASH BLOB NULL, LSHASHS BLOB NULL, CTPH BLOB NULL, PartialCRC1 UNSIGNED INT NULL, PartialCRC2 UNSIGNED INT NULL, PartialCRC3 UNSIGNED INT NULL, KCRC1 UNSIGNED INT NULL, KCRC2 UNSIGNED INT NULL, KCRC3 UNSIGNED INT NULL, KCRC3n UNSIGNED INT NULL);
CREATE TABLE AmsiFileCache(ID INTEGER PRIMARY KEY NOT NULL, PersistId VARCHAR NOT NULL,PersistIdBlob BLOB NOT NULL,ExpirationDate TEXT NOT NULL);
CREATE TABLE AttributeCounts(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, Name NVARCHAR NULL, Count INTEGER NULL, InsertTime INTEGER NULL, ExpireTime INTEGER NULL);
CREATE TABLE NetworkIpFirewallRules(ID INTEGER PRIMARY KEY NOT NULL, Key VARCHAR NOT NULL, FirewallRuleName VARCHAR NOT NULL, ExpiryTime INTEGER NOT NULL);
CREATE TABLE AtomicCounters(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, Name NVARCHAR NULL, Count INTEGER NULL, InsertTime INTEGER NULL, ExpireTime INTEGER NULL, UpdateTime INTEGER NULL, ScalarFactor INTEGER NULL, LinearFactor INTEGER NULL, DecayInterval INTEGER NULL, HighCount INTEGER NULL, LastDecayTime INTEGER NULL, Namespace NVARCHAR DEFAULT '');
CREATE TABLE RollingQueuesValues(ID INTEGER PRIMARY KEY NOT NULL, EntryTable NVARCHAR NULL, EntryKey NVARCHAR NULL, EntryValue NVARCHAR NULL, InsertTime INTEGER NULL, ExpireTime INTEGER NULL);
CREATE TABLE RollingQueuesTables(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, Name NVARCHAR NULL, Capacity INTEGER NULL, TimeToLive INTEGER NULL, Mode INTEGER NULL, Namespace NVARCHAR DEFAULT '');
CREATE TABLE NetworkIpFirewallRulesOutgoing(ID INTEGER PRIMARY KEY NOT NULL, Key VARCHAR NOT NULL, FirewallRuleName VARCHAR NOT NULL, ExpiryTime INTEGER NOT NULL);
CREATE TABLE DnRevisions(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, Revision INTEGER NULL);
CREATE TABLE AnomalyInfo(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, UnbiasedTime INTEGER NULL);
CREATE TABLE AnomalyTables(ID INTEGER PRIMARY KEY NOT NULL, Key INTEGER NULL, TableKey INTEGER NULL, TableName TEXT NULL, UnbiasedTableAge INTEGER NULL, KeyName TEXT NULL, FirstSeen INTEGER NULL, LastSeen INTEGER NULL, UnbiasedTime INTEGER NULL, Value REAL NULL, Order_ INTEGER NULL);
CREATE TABLE sqlite_stat1(tbl,idx,stat);