Windows Search Database
The Windows Search index database records metadata for every file indexed on the system — file names, paths, content snippets, and properties — including files that have since been deleted. It can reveal the existence of files the attacker staged or accessed even after cleanup.
An attacker searched for documents containing keywords like "acquisition," "merger," and "board presentation" using Windows Explorer search. The search functionality uses the Windows Search index to return results quickly. Each file they searched for and the search queries themselves may be recorded. Additionally, files they staged in indexed directories appear in the database — even after deletion, the index may retain the file's metadata entry until a full reindex. This chapter shows how to extract and query the Windows Search database.
Search Database Location
Windows Search Database
═══════════════════════════════════════════════════════════════════
Primary database:
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\
Windows.edb — main index database (ESE format)
User-specific:
Older Windows versions kept per-user indexes but modern Windows
uses a single system-wide index under ProgramData.
Format: ESE (Extensible Storage Engine) database — same as SRUM
Tool: SrumECmd cannot parse Search; use libesedb or specialized tools
What's indexed (by default Windows Search configuration):
├── All files in user profile directories (%USERPROFILE%)
├── C:\Windows\system32 (metadata only)
├── Documents, Downloads, Desktop, Music, Videos, Pictures
└── Outlook/email content (if configured)
NOT indexed by default:
├── Temp directories
└── Drives other than C:
The forensic value:
Files that appeared in indexed locations are recorded in Windows.edb
even after deletion, until a reindex overwrites the entry.
The database may contain filenames, content excerpts, and metadata
for files that no longer exist on the filesystem.
Extracting the Windows Search Database
# The Windows Search database is locked while the Windows Search service runs
# Stop the service before copying, or use VSS/KAPE raw copy
# Option 1: Stop service and copy (requires admin, brief service interruption)
Stop-Service WSearch -Force
Start-Sleep -Seconds 3
Copy-Item "C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb" `
"D:\evidence\Windows.edb"
Start-Service WSearch
# Option 2: KAPE automatically handles locked files via VSS
# KAPE target: WindowsSearchDatabase
# Option 3: Use Volume Shadow Copy to access a consistent copy
# Mount the shadow copy and copy Windows.edb from thereQuerying the Search Database
"""
Query Windows Search database (Windows.edb) using libesedb.
Extracts indexed file metadata including deleted file records.
Installation: pip install libyal (or use SIFT which has libesedb pre-installed)
"""
import subprocess
import os
def extract_search_catalog(edb_path: str, output_dir: str):
"""Export Windows Search database tables to CSV using esedbexport."""
# esedbexport is part of libesedb-tools (available in SIFT)
os.makedirs(output_dir, exist_ok=True)
result = subprocess.run(
["esedbexport", "-m", "all", "-t", output_dir + "/windows_search", edb_path],
capture_output=True, text=True
)
print(result.stdout)
if result.returncode != 0:
print("Error:", result.stderr)
def search_for_keywords(catalog_path: str, keywords: list):
"""Search exported catalog for specific keywords in file paths or content."""
# The main table is typically named "SystemIndex_0A" or similar
for table_file in os.listdir(catalog_path):
if table_file.endswith(".csv"):
print(f"Searching {table_file}...")
with open(os.path.join(catalog_path, table_file), 'r',
encoding='utf-8', errors='replace') as f:
for i, line in enumerate(f):
if any(kw.lower() in line.lower() for kw in keywords):
print(f" Line {i}: {line.strip()[:200]}")
if __name__ == "__main__":
extract_search_catalog(
edb_path="D:/evidence/Windows.edb",
output_dir="D:/analysis/search_db"
)
search_for_keywords(
catalog_path="D:/analysis/search_db",
keywords=["merger", "acquisition", "board", "confidential", "staging"]
)Windows Search History (Typed Searches)
In addition to the file index, Windows records the searches users typed into the Start Menu search / Cortana / Windows Search bar.
# Windows Explorer typed search history
# Stored in registry under the user's NTUSER.DAT
# WordWheelQuery — things typed into Explorer search box
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery" 2>$null |
Select-Object -Property * -ExcludeProperty PS* |
ForEach-Object {
$_.PSObject.Properties | ForEach-Object {
[PSCustomObject]@{
Index = $_.Name
SearchTerm = if ($_.Value -is [byte[]]) {
[System.Text.Encoding]::Unicode.GetString($_.Value).TrimEnd("`0")
} else { $_.Value }
}
}
} | Sort-Object Index | Format-Table
# TypedPaths — paths typed in Explorer address bar
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths" 2>$null |
Select-Object -Property * -ExcludeProperty PS* |
ForEach-Object { $_.PSObject.Properties } |
ForEach-Object { [PSCustomObject]@{ Name=$_.Name; Path=$_.Value } } |
Format-TableIn an insider threat investigation, WordWheelQuery and TypedPaths tell you what the user was looking for — not just what they found. A user who searched for "acquisition documents," "merger target," and "board presentation" in the week before their resignation, followed by LNK files showing access to those files on a USB drive, presents a compelling evidence chain: the user specifically sought out and accessed high-value confidential material before leaving. This combination of intent (search queries) and action (file access via LNK) is exactly what legal teams need when pursuing civil litigation or referring to law enforcement.
Q & A
Q: Is the Windows Search database reliable as forensic evidence?
It's corroborating evidence, not primary evidence — treat it as supporting rather than standalone. The database records what files were indexed (existed in an indexed location) but doesn't directly prove the user opened or read those files. For action evidence (user actually opened a file), LNK files, jump lists, and browser history are stronger. The search database's primary forensic value is proving existence of files that no longer exist and reconstructing what files were accessible in a particular user's environment. It's also useful for revealing files in indexed locations that you might not have known to look for — the keyword search capability lets you discover relevant files you didn't know to ask about. Always corroborate search database findings with other artifacts before drawing conclusions.