How to Collect the WMI Repository for Forensics
Where the WMI repository lives and how to copy OBJECTS.DATA, INDEX.BTR and the MAPPING files safely: shadow copy, KAPE WBEM target, Velociraptor or an image.
TL;DR. Take the whole C:\Windows\System32\wbem\Repository folder — OBJECTS.DATA, INDEX.BTR, MAPPING1.MAP, MAPPING2.MAP, MAPPING3.MAP — from the same instant. On a live host the files are locked by the WMI service: read them from a shadow copy, with KAPE (WBEM target) or with Velociraptor. Never stop the WMI service to copy them.
Where the files are
| Windows version | Folder |
|---|---|
| Vista, 7, 8, 10, 11, Server 2008 and later | C:\Windows\System32\wbem\Repository\ |
| XP, Server 2003 | C:\WINDOWS\system32\wbem\Repository\FS\ |
| After an in-place upgrade | also C:\Windows.old\Windows\System32\wbem\Repository\ |
OBJECTS.DATA alone is enough to carve subscriptions. INDEX.BTR and the MAPPING files add namespaces and tell live objects from deleted ones — so collect everything.
Before you start
- Do not stop
Winmgmtand do not runwinmgmt /salvagerepositoryor/resetrepositorybefore collecting: they rewrite the repository and can destroy the deleted records you are after. - Keep the files together. An
INDEX.BTRor a MAPPING file from another moment points at the wrong pages. The structured view breaks; carving still works. - Collect early. Deleted subscriptions survive only until WMI reuses their pages; software installs and updates write to the repository.
Step 1: Open an elevated PowerShell
On the host, start Windows PowerShell with Run as administrator. A plain copy of OBJECTS.DATA fails with a sharing violation while the WMI service runs.
Step 2: Create a shadow copy and link it
In the same window, create one snapshot of C: and expose it as a folder. The snapshot freezes every repository file at the same instant:
New-Item -ItemType Directory -Force -Path C:\triage | Out-Null
$sc = Invoke-CimMethod -ClassName Win32_ShadowCopy -MethodName Create -Arguments @{ Volume = 'C:\' }
$vss = Get-CimInstance -ClassName Win32_ShadowCopy -Filter "ID='$($sc.ShadowID)'"
cmd /c mklink /d C:\triage\vss "$($vss.DeviceObject)\"
Step 3: Copy the Repository folder
robocopy /B copies in backup mode, so no file is skipped:
robocopy C:\triage\vss\Windows\System32\wbem\Repository C:\triage\Repository /E /B /R:0 /W:0 /NP /NDL
Step 4: Remove the link and the snapshot
cmd /c rmdir C:\triage\vss
$vss | Remove-CimInstance
You now have C:\triage\Repository. Hash it, and pack it if you analyse it elsewhere (tar.exe ships with Windows 10 1803 and later):
tar -a -c -f C:\triage\wmi-repository.zip -C C:\triage Repository
The same four steps are available as a single copy-paste block under How to get your data on the WMI Parser home page.
With a triage tool
KAPE has a WBEM target that copies both Repository folders (current and Windows.old) with raw disk access. It is included in the KapeTriage and !SANS_Triage compound targets, so an existing triage collection may already have it:
kape.exe --tsource C: --tdest C:\triage\kape --target WBEM
Velociraptor: collect Windows.Triage.Targets (Velociraptor Triage project) with the WBEM target from the GUI, a hunt or an offline collector. From the command line, the built-in Windows.Search.FileFinder artifact can upload the folder:
velociraptor.exe artifacts collect Windows.Search.FileFinder --args SearchFilesGlob=C:\Windows\System32\wbem\Repository\* --args Upload_File=Y --output C:\triage\wmi.zip
Both outputs can be dropped on WMI Parser as they are: it finds the repository inside the folder or ZIP, percent-encoded Velociraptor paths included.
From a disk image
Mount the image read-only (for example with Arsenal Image Mounter as E:) and copy the folder:
robocopy E:\Windows\System32\wbem\Repository C:\triage\Repository /E /R:0 /W:0 /NP /NDL
On Linux or macOS with the image mounted at /mnt/win:
mkdir -p ~/triage && cp -a /mnt/win/Windows/System32/wbem/Repository ~/triage/
In FTK Imager, browse to Windows\System32\wbem, right-click Repository, then Export Files. Look in the image's shadow copies too: an older repository can still hold a subscription that was removed since.
A quick live look (not a substitute)
To see what is active right now, ask WMI itself:
'__EventFilter','__EventConsumer','__FilterToConsumerBinding' | ForEach-Object { Get-CimInstance -Namespace root/subscription -ClassName $_ } | Format-List *
This shows live objects of one namespace only, never deleted ones, and it trusts the WMI service of a possibly compromised host. Use it for triage, then parse the collected files. The investigation checklist lists what to check next.