Windows Search Index Investigation: A Worked Example

TL;DR. Fictional scenario, built on the synthetic sample that ships with the tool. On workstation FIN-WKS-07, the Windows 11 search index alone gives the outline of an intrusion by the svc_backup account: a tool archive downloaded, a binary staged in C:\ProgramData\Intel, a credentials file written and then deleted (its text survives in System.Search.AutoSummary), a payroll spreadsheet copied from a file share to a removable drive, rclone.exe dropped in Users\Public, and a visit to a cloud storage site. The most recent steps are only in Windows.db-wal. Each finding is a lead to confirm with other artefacts, and the write-up below shows which ones.

Everything here is invented. The company, hosts, accounts, file names, timestamps and credentials come from the demo databases generated for the site's "Try a sample" button. No real incident or data is described. You can load the same data yourself with Try a sample (Windows 11) on the Windows Search Index Parser and follow along.

The situation

The finance team's IT contact reports that svc_backup, a service account that should never log on interactively, appears in the list of recently signed-in users on FIN-WKS-07. The machine is isolated on 14 September 2026 in the afternoon. You get a KAPE collection including the WindowsIndexSearch target. Event logs are being processed by a colleague. You start with the search index because it is fast and it is one of the few artefacts that can hold file content.

Step 1: load and check completeness

Dropping the collection ZIP shows Windows.db, Windows.db-wal and Windows-gather.db paired from the same folder. No warning about a missing WAL or gather database. Good: we have the current state and the gather cross-check. The counters show a small index: this is a demo. A real workstation would show tens of thousands of items, which is exactly why filtering matters.

Timestamps are UTC throughout (the stored FILETIMEs are UTC; I keep the display in UTC for the report).

Step 2: flagged items first

Flagged only, sorted by created time (excerpt; the "recently indexed" flag, set on most of these, is left out for readability):

Plus a gather-table-only record: m64.exe under C:\Users\svc_backup\AppData\Local\Temp\7zS4A2.tmp, with no properties left in the store.

Step 3: reading each item

The profile

C:\Users\svc_backup created at 09:58:41. A profile folder for a service account on a workstation means an interactive or RDP logon created it. Corroborate: logon events (4624 with logon type 10 or 2) in the event logs around 09:58.

The tool archive and the temporary extraction

tools.zip, 4,812,331 bytes, owner FIN-WKS-07\svc_backup, created 10:05:31, indexed at 10:05:58. At 10:06:38 the Start menu shortcut 7-Zip File Manager.lnk shows a new access time. At 10:06:55 the gather table knows an m64.exe in a 7zS…tmp folder under the account's Temp. Its properties are gone from the store: that is the gather table only pattern of a temporary file that was cleaned up. Reading: the archive was opened with 7-Zip and m64.exe extracted, first to a temporary location. Corroborate: Jump Lists for 7-Zip and the USN journal for the temp folder.

The staged binary

C:\ProgramData\Intel\m64.exe, 1,359,872 bytes, created 10:07:14. ProgramData\Intel is a classic "looks legitimate" staging path; a folder named after a hardware vendor with a lone executable in it is worth the look. The item is changed in WAL: the checkpointed database has an access time of 10:07:14, the WAL a new access time of 10:51:02 and a new gather time of 10:51:30. It was touched again 45 minutes later. The index does not prove execution. Corroborate: Prefetch, Amcache, ShimCache.

The deleted credentials file

C:\ProgramData\Intel\creds.txt, 214 bytes, created 10:09:48, modified 10:14:02, indexed 10:14:30. It is not in the gather table, and the gather record for the Intel folder shows a last-modified time of 10:55:04. On disk, the file is gone. Its content snippet is still in the property store:

FIN-SQL01 sa / Winter2026! | FILESRV01 CORP\svc_backup / Bkp#2026-fin | mega: fin-backup

Three sets of credentials: the SQL server's sa account, the service account's own domain password, and what looks like a cloud storage account name. In a real report I would quote it in a restricted annex and trigger credential resets. This is the value described in evidence of deleted files in the Windows Search index: content of a file that no longer exists, without any carving. Corroborate: the Recycle Bin (was it deleted through Explorer?), the USN journal (delete record for creds.txt near 10:55), and authentication logs on FIN-SQL01 and FILESRV01.

The payroll file, twice

\\FILESRV01\Finance\Payroll\Payroll_2026.xlsx: a network path owned by CORP\payroll-admins, 188,406 bytes, last modified 12 September at 16:02, accessed 14 September at 10:32:15, indexed 10:33:01. Snippet: the column headers of a payroll table. The share was indexed on this workstation, so the index records the access time as it saw it.

Then E:\exfil\finance_2026\Payroll_2026.xlsx: other drive, same size, same modification time (12 September 16:02, preserved by the copy), created at 10:40:12, owner FIN-WKS-07\svc_backup. Only in WAL: this record exists only in the latest transactions, not in the checkpointed database. Without Windows.db-wal you would not see it. See Windows.db forensics: SQLite and the WAL. Reading: copy of the payroll file to a removable drive at about 10:40. Corroborate: USB device history in the registry and event logs, LNK files pointing to E:\.

rclone and the cloud site

C:\Users\Public\rclone.exe, 58,720,256 bytes, created 10:45:03, accessed 10:47:12, only in WAL. Rclone is a legitimate sync tool widely abused for exfiltration. A web history item indexed at 10:46:52 points to https://mega.nz/start, accessed 10:46:30, with a user SID ending in -1013 in its iehistory:// URL. Corroborate: map the SID to an account with the SAM / ProfileList hives, check browser artefacts, look for rclone.conf and network or proxy logs.

Step 4: the timeline

Every line is an indexing observation, not an execution or user action by itself. The confidence column is what I would defend in front of a reviewer before corroboration.

What the index could not tell us

• Whether m64.exe or rclone.exe ran. Execution artefacts are needed.
• What rclone uploaded. Network, proxy and cloud logs, or rclone.conf.
• Anything outside indexed locations. A tool run from a non-indexed folder would be invisible here.
• Anything after 10:51. The last gather time in the index is the edge of its visibility.

Takeaways

• Collect the WAL and the gather database: three of the key findings depend on them.
• Sort flagged items by time first; open details second.
• Treat content snippets as evidence of content at indexing time and protect them like the data they contain.
• Write each finding as "the index records…" and list the corroborating artefact next to it.

Related articles

• How to open Windows.edb and Windows.db step by step
• Windows Search index properties explained
• Anti-forensics against the Windows Search index