BAM Evidence of Execution: A Lateral Movement Case

TL;DR. Fictional scenario, synthetic data. On FIN-WKS-07, BAM alone lays out a morning: alice opens a double-extension "invoice" and PowerShell 24 seconds later; an hour later the svc_backup service account — which should only run a backup agent — starts cmd.exe, drops a binary in ProgramData, runs an IP scanner from a second volume, opens RDP, runs PsExec, 7-Zip and rclone. A fake svchost.exe runs as SYSTEM from Windows\Temp. BAM gives the who, what and when; it can't give the commands, the hashes or the targets, and this article is explicit about each gap.

Everything in this article is fictional. The host, accounts, SIDs, paths and times come from the synthetic hives behind the "Try a sample" button of the BAM/DAM Parser. No real organisation, person or incident is described. You can load the same data and follow along.

The setup

A finance workstation, FIN-WKS-07, raised an alert for outbound traffic to a cloud-storage provider on 14 September 2026. The responder collected SYSTEM, SYSTEM.LOG1/LOG2 and SOFTWARE with KAPE before anyone rebooted the machine — which, as the limitations article explains, is what keeps deleted tools' BAM entries alive.

Loading the hives in the tool gives the header:

All times below are UTC, as stored in BAM. Add two hours for local Paris time.

Phase 1 — Initial access under alice

Filtering on alice and sorting by last execution:

What BAM supports: a normal start of day (Teams, Outlook, Chrome), then a program with a .pdf.exe double extension from Downloads, then PowerShell 24 seconds later, all under alice.

What BAM does not show: how the file arrived (browser download vs. mail attachment), its hash, whether PowerShell was its child, or what PowerShell ran. Remember that the time is the last recorded activity — updated at process start and exit (Suhanov) — so the "invoice" may have been started a bit earlier than 09:12:07 if it ran for a while.

Next steps on a real case: Chrome history and Zone.Identifier stream for the download source (Browser Forensics), Amcache for the SHA-1, PowerShell Operational logs (4104 script block logging, if enabled) in EVTX Parser.

Control set comparison. Turning off "Active control set only" shows ControlSet002 with only four of alice's entries — Chrome, Outlook, Excel, Notepad. That older snapshot has none of the suspicious rows, which is consistent with the activity being recent. It's a comparison point, not proof of timing.

Phase 2 — The service account wakes up

svc_backup is a backup service account. In a healthy estate its BAM key would, at most, hold the backup agent. Here:

This is the core finding, and it's the kind BAM is uniquely good at: execution attributed to a specific account. The attribution article explains why the wording should be "executed under the svc_backup account" — BAM can't tell whether a person typed the commands or a tool used the credentials.

Mapped to MITRE ATT&CK for the report:

• Advanced_IP_Scanner.exe → network service discovery (T1046).
• mstsc.exe → outbound RDP (T1021.001).
• PsExec64.exe → service execution on remote hosts (T1569.002).
• 7z.exe then rclone.exe → staging and exfiltration to cloud storage (T1567.002).

What the paths add

• \Device\HarddiskVolume7\tools\ — not the system volume (HarddiskVolume3). BAM doesn't record executables on media flagged removable (Suhanov), so this volume was presented as something else: a mounted VHD/ISO or an external disk that reports as fixed are candidates. Map it with other artifacts before writing "USB". See the value format article for device paths.
• \ProgramData\Intel\m64.exe — an unknown binary in a vendor-looking folder. BAM can't say what it is; Amcache's SHA-1 can.
• \Users\Public\rclone.exe — a world-writable folder, commonly abused for staging.

What's missing

No net.exe, whoami.exe or nltest.exe, although reconnaissance commands like these are typical in a cmd.exe session. That's expected: console programs launched from a command-line session were observed not to get BAM entries (Suhanov). The absence says nothing. Prefetch and 4688/Sysmon events are where those will show up.

Phase 3 — SYSTEM from a temp folder

Under S-1-5-18:

A svchost.exe outside System32, running as LocalSystem three minutes after svc_backup opened a shell and four minutes before m64.exe appeared. Classic masquerading (T1036). How it got SYSTEM — a service install, a scheduled task, PsExec's own service — needs 7045/4697 events and the Services key.

The combined timeline

Forty minutes between PowerShell and the service account's first shell is the obvious gap: how did the attacker get svc_backup's credentials? BAM doesn't know. Candidates to test: credentials stored in a script or config readable by alice, a credential dump (Prefetch/Amcache for dumping tools, LSASS access events), or a logon from another host (4624 type 3/10).

What went into the report

1. BAM findings, each worded as "last recorded activity under account X at T UTC", with the SID key path.
2. The explicit limits: no command lines, no hashes, no console tools, no removable/network executions, one timestamp per program.
3. Corroboration plan: Amcache (hashes of m64.exe, the invoice, rclone), Prefetch (run counts, first runs), EVTX (logons, service installs, PowerShell), SRUM (bytes sent by rclone.exe), and the BAM keys of the hosts reached by PsExec and RDP, where the same account (or SYSTEM) may have run tools too.
4. Scope: the other hosts mstsc.exe and PsExec64.exe reached get the same collection.

Try it

Open the BAM/DAM Parser, click Try a sample, and reproduce each table with the account filter, "Flagged only" and sorting. The step-by-step how-to explains each control, and the comparison with Prefetch, ShimCache and Amcache shows what each corroborating artifact would add.