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

We haven’t found any references online that anyone uses this as an actual artifact. It isn’t covered by any map in KAPE, Velociraptor, Dissect, or (until now) SQLECmd’s 95 stock maps. So the value of this lesser known database hasn’t been covered forensically, at least from what we were able to find online. There has been some offensive research into this database, specifically for evasion techniques and reversing certain Defender components, but the contents of this database haven’t been covered.

Internally Defender calls this store MetaVault. It’s maintained by mpengine.dll, Defender’s scanning engine. Most of what gets written into it isn’t written by the engine’s native code. It’s written by Lua scripts embedded in the signature definition files (mpasbase.vdm/mpavbase.vdm). Defender’s signatures are small programs that can read and write this database as they evaluate a file or process.

The encryption

mpengine.dll checks a setting called MpSqliteCodecDisable when it opens the database. Unless that’s set to 1, it enables SQLite’s encryption hook with an empty key. That key is never actually used, it’s a decoy. The real cipher is RC4, with a fixed 256-byte key stored inside mpengine.dll.

The cryptographic implementation is also weak. RC4 resets for every page, so every page uses the exact same keystream, with no nonce and no integrity check. Page 1 still leaks bytes 16 to 23 (page size and a few other header fields) in the clear before the rest is run through RC4. The same pattern is in the WAL: frame headers are readable, only the page data is encrypted. One detail to watch for when decrypting the WAL yourself: SQLite’s checksums are computed over the encrypted bytes, not the plaintext, so decryption has to happen before SQLite validates the frames.

We tested this on two separate Windows 11 machines, both on engine build 1.1.26100.4, and recovered the same key from both. That means the key is tied to the engine build, not the individual machine. A sample from any system running that build is enough, there’s no need for the exact machine under investigation. This also means the database can likely be decrypted on an updated Windows 10 machine running the same engine build, using the same key.

The DLL isn’t even required to get the key. Unused space in a SQLite page is zero-filled, and zero XOR’d with a keystream returns the keystream itself. Combined with the known SQLite format 3 header, that’s enough to reconstruct the full 256-byte key directly from the evidence file. We verified both paths, key extracted from the DLL and key rebuilt from a blank page, and got identical results. This is also the reasoning behind the --derive-key flag in the parser: it discards the built-in key and reconstructs it from the evidence instead, so the output doesn’t depend on anything shipped with the tool.

What hasn’t been established is whether this holds across other engine builds. Only one build was tested, on two machines, so it’s unknown whether an older or newer mpengine.dll uses a different 256-byte key.

The key should not be treated as a fixed constant. Deriving it from the evidence rather than relying on a hardcoded value is what keeps the result valid regardless of engine build.

Available telemetry

Currently, we tested only on Windows 11 machines (build 26100, Defender engine 1.1.26100.4), mpengine.dll, and the signature files mpasbase.vdm and mpavbase.vdm.

When analyzing the output the parser produces, we can see it stores a lot of valuable data from a forensic standpoint, covering roughly the last two weeks.

It contains parts of Defender’s internal SQLite database, including persisted security context, file-related metadata, cloud-analysis indicators, ransomware-related tracking, and records that survived deletion or replacement.

In the following section we’ll highlight the most useful events.

AttributePersistContext

Table event which is significant in understanding Defender’s context and its “thought process.” It is the most forensically valuable table, and can help identify Tamper Protection context, PE creation/execution markers, and side-loading indicators. There are cases where it can track a file’s origin and store information on whether it was downloaded from Discord, Telegram, etc.

Context tagged NewlyCreatedZip, with the timestamp and path of a zip file right after Defender saw it get created.

Gives context about recently created zip files recorded by Defender, important for identifying staging activity, something commonly seen in many initial access tradecraft chains.

BM_IsPotentialSideLoad tags on ffmpeg.dll and pcaui.dll, both sitting in uncommon locations.

Identifies DLL files in uncommon locations, shows DLL potential side-loading indicators which could be additional investigation candidates.

NewPECreatedNoCert tags on several unsigned DLLs and an uninstaller dropped into a temp folder.

Tracks recent creation (and execution, in the ExecutedPENoCert event) of PE files without a signed certificate. This artifact can support investigations into executable creation, installer extraction, and potentially suspicious file drops.

A recovered row from the WAL (top) and the live final state (bottom), both showing MpTamperProtectionState set to off.

It can also preserve the historical Tamper Protection state. In this example, a recovered record from the WAL contains MpTamperProtectionState=off, even though the record no longer exists in the final database state. This value should be interpreted carefully, since it can’t be mapped directly to attacker activity. It just stores the last known state of MpTamperProtectionState, which could have been intentionally disabled by whoever administers the machine.

RollingQueuesValues

Additional endpoint artifacts which can store evidence of internal network configuration, process execution (PID only), recent threats, and a per-process attack scoring entry mapped to the MITRE ATT&CK framework.

Internal network information, DNS servers and domain names picked up from the host.

A process’s PID and its FILETIME-encoded start time, queued for attack scoring correlation.

Stores process IDs and start times. This can help correlate Defender activity with other process execution artifacts, though it does not contain a complete execution history.

Recent Behavior:Win32/... detections queued under RecentThreatsOnMachine.

Stores recently recorded Defender threat names, which can help identify suspicious behavior and provide leads for further investigation.

A Tech-pid queue entry resolved to ATT&CK technique T1547.001, tied to a specific PID and process start time.

Detected techniques per process, mapped to MITRE ATT&CK.

FileLowFiAsync

Contains file paths and signature-related information for files processed by Defender’s low-fidelity analysis mechanism. These records can help identify previously examined files and correlate them with other forensic artifacts.

LowFi signature hits sent for async cloud lookup, in this case against hashcat’s module DLLs.

BackupProcessInfo

Stores Microsoft Defender’s internal file and process related metadata, including executable paths, timestamps, and a NextUSN value. This value can be correlated with the NTFS USN Change Journal ($UsnJrnl), potentially helping investigators reconstruct file modifications, renames, and deletions.

Files tracked for ransomware rollback, each with its NextUSN value ready to correlate against $UsnJrnl.

FileHashes

At first, this might seem like a simple, self-explanatory table. However, it can be highly valuable because it contains a file’s SHA-256 hash and its retrieved MFT entry number. This is especially useful in situations when the original file is no longer available on the filesystem, can’t be recovered from memory, or when an attacker has deleted other forensic artifacts, like Sysmon logs or Amcache entries.

Files hashed by real-time protection, with their SHA-256 and MFT entry number retained.

MetaInventory

Contains software inventory data like version changes, modules, and CPE (Common Platform Enumeration) identifiers for matching known CVEs.

A CPE entry for a specific 7-Zip build, flagged against three known CVEs.

SQLECmd can’t decode it

SQLECmd reads the first 8 bytes of every file and only continues if they say SQLite f. In mpenginedb.db those bytes are encrypted too.

With default settings SQLECmd hunts through a folder, so the file is skipped without a word. You only see it with --debug, or when you point at the file directly, e.g.:

SQLECmd refuses to process the file once it’s pointed directly at it, logging it as “not a SQLite file.”

The tool never sees the database at all, and in a big collection nothing tells you it was missed unless you explicitly try to parse the database.

Our tooling

We wrote two ways to work with this file.

mpenginedb_parser.py

Github link: https://github.com/Protokol-7/mpenginedb_parser

This is the full parser, made in Python with only the standard library.

Usage:

python mpenginedb_parser.py -f "...\mpenginedb.db" --wal "...\mpenginedb.db~wal" -o out

The parser loading its lookup tables, hashing the evidence, and validating each WAL state in sequence.

The run finishing: every WAL state passes its integrity check, timeline events get written, manifest complete.

It hashes the evidence before and after and never writes to it. It checks the WAL the way SQLite does, rebuilds the database after every saved transaction, and carves deleted rows with a quality flag for records that were partly overwritten. Every field is decoded: times in UTC, PID and process start, MFT numbers, the swapped hash columns, ATT&CK technique names, and ASR rule names. The main output is timeline.csv, plus one CSV per table, recovered rows, a report, a log, and a SHA-256 manifest. The --derive-key flag ignores the built-in key and rebuilds it from the evidence, so you can show the result does not depend on anything shipped with the tool.

Decrypt-MpEngineDb.ps1 and an SQLECmd map

Github link: https://github.com/Protokol-7/MpEngineDb_SQLECmd

If you want to use the SQLECmd option, we created a PowerShell script that “prepares” (decodes) the database. It writes mpenginedb_decrypted.db, a normal SQLite file with the WAL already applied.

Usage:

.\Decrypt-MpEngineDb.ps1 -Path <Scans folder copy> -OutDir D:\case\mpdb
SQLECmd.exe -d D:\case\mpdb --csv D:\case\out

The script hashes the evidence, validates and applies the WAL, and writes mpenginedb_decrypted.db.

Then SQLECmd does the rest with the map Windows_MicrosoftDefender_MpEngineDb.smap. Note that you need to drop the map mentioned above into the SQLECmd Maps folder, or use the --maps flag in SQLECmd and point it at the path containing the .smap.

After the database is decrypted and the .smap file is dropped into the Maps folder, SQLECmd is ready for use:

SQLECmd.exe -f "D:\case\mpdb\mpenginedb.db" --csv "D:\case\out"
OR
SQLECmd.exe -f "D:\case\mpdb\mpenginedb.db" --csv "D:\case\out" --maps <folder with the .smap>

SQLECmd running against the decrypted copy with the map loaded, output written normally.

The map has 13 queries: attack scoring queues, path tags and ASR state, the hash cache, rollback tracking, LowFi hits, schema history, AMSI cache, blocked processes, monitored processes with command lines, ransomware detections, firewall rules, counters, and Controlled Folder Access paths. Times come out in UTC with the raw values next to them. The Python parser and the PowerShell script produce byte-identical decrypted databases. Deleted rows and per-transaction history are only available in the Python parser.

Conclusion

mpenginedb.db works like a flight recorder for Defender. It keeps the engine’s own view of what each process did, built from activity that often never turns into an alert, scored and queued internally whether or not anything ever surfaces in Protection History. Attack scoring tied to PID and process start, path tags on dropped or side-loaded files, a hash cache that survives after the original file is gone, rollback tracking that ties back into the USN Journal, none of it needs a detection to exist.

The encryption was never a real barrier. RC4 with a key reused across every page is weak on its own, and the key itself turned out to belong to the engine build rather than the machine, recoverable straight from the evidence file without ever touching mpengine.dll. That derivation doesn’t depend on having seen a given build before, so it should hold even for builds we haven’t tested, Windows 10 included.

SQLECmd walks past it without a word unless you already know to point at it directly, which is most likely why it’s gone unnoticed in casework this long.

mpenginedb_parser.py and Decrypt-MpEngineDb.ps1 plus the SQLECmd map are both linked above and produce identical decrypted output. Pick whichever fits the rest of your workflow.

This led to us parsing the Search Index database using SQLECmd from EZ-Tools (https://ericzimmerman.github.io/). Again we ran into an issue. It parsed the database but the output is unreadable since the values are hex encoded.

We decided to fix both of these issues and implement a new feature which isn’t present in any open source tool that we know of. This feature is WAL carving of the Windows.db-wal file. (SQLite’s Write-Ahead Log for Windows.db). Forensic implications are described below.

For SQLECmd we’ve created a helper script to decode the hex values returned by SQLECmd when parsing the Windows Search Index. The script also has a WorkId correlation feature (--pivot flag) you can use to generate output similar to SIDR.

All of the following tests were performed on the same 26H2 machine, only using updated versions of the same Windows.db database.

SIDR

We concluded that the SIDR repository is unmaintained and does not work on Windows versions 24H2, 25H2 and 26H2.

24H2

The output is almost non-existent:

sidr-patch

We didn’t want to create a new tool from scratch when SIDR was working as expected on previous versions. Therefore we just created a patch for SIDR; most of this codebase is unmodified upstream SIDR (base commit 5bde8e8, Apache License 2.0, © 2025 LevelBlue). We only patched it to stop crashing on Windows 11 24H2/25H2/26H2 databases and added the new --history recovery option which supports WAL carving. This is described in detail below.

Reason why SIDR fails is described in our patched SIDR github repository (sidr-patch): https://github.com/Protokol-7/sidr-patch/tree/main

The release is available at: https://github.com/Protokol-7/sidr-patch/releases/tag/v1.0.0

Demonstration of the patch on a Windows 11 26H2 machine:

Output is the same as before with SIDR. In this example, I searched for a string that’s present inside a ransomware note (.txt file). The AutoSummary (Content Preview) feature allows us to inspect content inside of the file.

WAL Carving

WAL carving applies the general carving idea to a SQLite write-ahead log: instead of asking the database engine “what’s the current value of this row,” you read the WAL file directly, byte by byte, and reconstruct every version of a row that was ever written to it, including versions the engine itself would refuse to show you, because they’re old, superseded, or part of a transaction that never finished.

The sidr_patch --history flag does three things, roughly:

• Walks the WAL independently of SQLite. Rather than opening the database normally and asking it for the current state, it parses the raw WAL file itself to find every past version of every page including ones that were later overwritten, ones from a half-finished write, and leftover fragments from before the WAL was last reset.
• Does the same for the main database file, looking at space that’s no longer actively used by anything live, pages that got replaced or freed but weren’t yet overwritten by new data.
• Compares every historical value it finds against the item’s current value. If they match, it’s discarded, not interesting. If they differ, it gets written to a report with a label explaining why it’s different: the value changed, the property disappeared, or the whole item no longer exists at all.

Forensic Value

It recovers evidence a live query can never show you. A normal scan, even a very thorough one, only ever sees the database’s current, final state. Anything superseded along the way is invisible to it by design. WAL carving is the only way to see that intermediate history at all. It can recover evidence that was never meant to be visible to anyone. A half-written transaction that got interrupted by a crash, a power loss, or a process being deliberately killed never becomes “current” under any circumstances. Carving is the only path to it.

But it’s a closing window, not a permanent record. Everything recovered this way is sitting in space that’s actively being reused by the next checkpoint, the next write, ongoing indexing activity. The longer you wait, the more of it gets overwritten. This is probabilistic evidence that degrades over time, not something you can always count on finding, which is exactly why timing matters so much in how you present a case built on it.

Use Case Scenario: Recovering a Deleted File’s Search-Index History via WAL Carving

Suppose a file was created, renamed to hide it, then deleted and the Recycle Bin emptied. The file itself is gone and may have been overwritten (suppose the MFT and Journal entries were also deleted or overwritten). Windows Search’s own database can be used as evidence here, specifically, residual property values sitting in the SQLite WAL and in freed/replaced pages of Windows.db that haven’t been overwritten yet.

Using sidr_patch --history, we managed to recover the renamed file name and other properties such as AutoSummary (Content Preview). This is the step-by-step process we used to demonstrate this scenario.

1. Creating a file Unique_WAL_Carve_test.txt.

1. Copying over the database after file creation, because a handle is currently opened and we can’t parse it live. (Note that the -shm file isn’t actually needed to perform WAL carving).

1. Using sidr_patch to parse the database (without the --history flag, just regular usage)

1. Checking the File_Report CSV for the file name.

1. Renaming the file to Renamed_WAL_Carve_Test.txt.

1. Copying the database and parsing again.

1. Renamed file appears.

1. The file was deleted (moved to Recycle Bin and deleted from there as well).

1. Copying the database and parsing again.

1. The Search Index Database (File_Report CSV output from SIDR) doesn’t contain either the old file name or the new file name.

1. Parsing with the sidr_patch --history flag this time.

1. We successfully recovered the file and its metadata, proving that it existed and even viewing its content. In this case, the original file name wasn’t recovered, only the renamed file.

Windows.db is lossy by design. A checkpoint only ever copies the latest committed version of each page into the main file, every intermediate state that existed along the way, in a sequence of commits before that checkpoint, is simply discarded from the moment it’s superseded. The WAL is the only place several categories of evidence ever exist in a form that’s recoverable at all.

Addressing SQLECmd

In this demonstration we’ll also show the usual output SQLECmd generates when parsing the Search Index database, as well as demonstrating our script which decodes the SQLECmd output and provides a pivoting feature that correlates WorkIds similar to what SIDR does. We didn’t intend to replace SIDR with this script, and generally we prefer SIDR for this, but if someone wants to use SQLECmd, our script might come in handy.

We tested this with both the newest SQLECmd version 2026.10.3 and the 2026.5.0 version. The output is the same.

We did get output, the error isn’t of note:

sqlecmd_si_decode script

Again, we recommend using the patched SIDR, but if anyone wants, they can keep using SQLECmd. This script decodes the hex values which SQLECmd outputs, and it also has a WorkId correlation feature (--pivot) to get output similar to the patched SIDR.

Github: https://github.com/Protokol-7/sqlecmd_SI_decode

General usage just for decoding:

Output is in a few tables, I wanted to search for the AutoSummary Content Preview. This was in the joined table (20261027232017764364_Windows_Joined_PropertyStore_Metadata_3985bd8a-6b2a-4ea3-ae32-5fccf14d6562_decoded.csv):

Recommended usage (pivoting with --pivot flag, also add metadata CSV with --meta): The first table we pass as an argument is the PropertyStore table which was the output of SQLECmd, then the output was defined to be saved in pivoted.csv. Then the second table was added, the PropertyStore_Metadata table (not the joined Metadata one), also outputted by SQLECmd. And the flag --pivot used to correlate WorkIds.

WorkId correlation: it groups every decoded (WorkId, Property, Value) triple by WorkId and writes one row per item, with every property that appeared anywhere in the data as a column. Run it with --pivot and you get a wide table structurally similar to SIDR’s File Report Output, but it’s not identical and we’re keeping it this way.

DB Browser for SQLite

I’d also like to address DB Browser for SQLite, a popular choice whenever sqlite databases are in play.

Browsing through DB Browser is usually a pain, and to correlate: SystemIndex_1_PropertyStore only stores numeric ColumnIds, not names; the name mapping lives in a separate table, SystemIndex_1_PropertyStore_Metadata. You need to resolve the ID first, meaning you have to write SQL queries.

SELECT ps.WorkId, ps.Value
FROM SystemIndex_1_PropertyStore ps
JOIN SystemIndex_1_PropertyStore_Metadata meta
  ON meta.Id = ps.ColumnId
WHERE meta.Name = 'System.Search.AutoSummary';

That gives you every WorkId that has a content preview, with the actual snippet text in Value.

It is possible to get output similar to SIDR, but we would rather not write SQL queries if a tool can parse it for us.

Conclusion

SIDR doesn’t work on current Windows 11 builds, and even where SQLECmd does work, its output is unreadable without a decode step of your own. We fixed both: sidr-patch gets SIDR running again on 24H2, 25H2 and 26H2, and sqlecmd_SI_decode makes SQLECmd’s hex output readable if you’d rather stick with it. On top of that, the --history flag adds something neither tool had before: WAL carving lets you recover property values, including a deleted file’s name and content preview, straight from the write-ahead log and freed pages of Windows.db, long after a normal query stops showing them. That evidence is time-sensitive since checkpoints and new writes overwrite it, so the sooner you parse with --history, the more you’ll get back.