BAM/DAM Forensics: The Complete Guide to Windows BAM

TL;DR. BAM (Background Activity Moderator) and its sibling DAM (Desktop Activity Moderator) are Windows power-management drivers that happen to keep a per-user list of executables with a timestamp in the SYSTEM hive. For an investigator that means one thing: which account ran which program, and roughly when it last did, on Windows 10 1709 and later. The entries are short-lived (about a week), skip removable and network paths, and hold no run count or hash. Use BAM as a precise, user-attributed pointer, then corroborate.

BAM has become a standard line on every "evidence of execution" checklist, including the SANS Windows Forensic Analysis poster. It is small, fast to parse and — unlike Prefetch or ShimCache — it tells you who. This guide collects what is actually known about it, with sources, and links to the deeper articles in this series.

What BAM and DAM are

The Background Activity Moderator is a kernel driver (bam.sys) that Windows uses to throttle applications running in the background. It appeared with Windows 10 version 1709, the Fall Creators Update, as documented by early researchers (padawan-4n6, 2018) and by the Velociraptor Windows.Forensics.Bam artifact.

The Desktop Activity Moderator is older. Microsoft documents it as a kernel-mode driver that suspends or throttles desktop processes when a device enters connected standby, and notes that it is not present on server SKUs (Microsoft Learn). On Windows 10 and 11 it keeps per-user records in the same format as BAM, but typically only on Modern Standby hardware. The dedicated DAM article goes into the differences.

Neither was built for forensics. The data exists so that the moderator can remember what it has seen per user; the timestamps are a by-product we get to read.

Where the data lives

Both services store their state in the SYSTEM hive (C:\Windows\System32\config\SYSTEM), one subkey per user SID:

The move from bam\UserSettings to bam\State\UserSettings is documented in kacos2000's BAM research, which notes that from 1809 the old key stops being updated but may still hold stale entries. Offline, there is no CurrentControlSet: read Select\Current to find which control set was live. Full detail, acquisition commands and the transaction-log trap are in where the BAM registry key is and how to collect it.

What a BAM entry contains

Under each SID key:

• Value name — the executable, written as an NT device path such as \Device\HarddiskVolume3\Windows\System32\cmd.exe, or, for packaged (Store/MSIX) apps, a package family name such as Microsoft.WindowsCalculator_8wekyb3d8bbwe.
• Value data — a REG_BINARY whose first 8 bytes are a FILETIME in UTC. On the builds Maxim Suhanov examined, the data is 24 bytes long (BAM internals).
• Two bookkeeping values, Version and SequenceNumber, which are not programs.

The byte-level view, with a worked example, is in the BAM value format article.

What the timestamp means

Suhanov's reverse engineering of bam.sys found that the FILETIME is updated when a process is created and when it terminates (source). For a short-lived tool the two moments are seconds apart. For a process that ran for hours, the value you read may be closer to when it exited. Most tools, including ours, label the column "last execution"; read it as "last activity recorded by BAM for this path and user".

Why investigators care

That user attribution is the big differentiator. Prefetch, ShimCache and Amcache are system-wide; BAM ties a binary to an account. When a service account suddenly shows PsExec64.exe in its Downloads folder, you know whose credentials to reset. The comparison with Prefetch, ShimCache and Amcache and the comparison with UserAssist cover where each artifact is stronger.

BAM is also not limited to what a user double-clicked in Explorer, which is what UserAssist tracks. Keys can exist for service and well-known accounts too — S-1-5-18 (LocalSystem), for example, which our parser labels as SYSTEM. The SID attribution article explains how to read those accounts.

What BAM does not tell you

The limits are as important as the data, and the limitations and anti-forensics article covers each in depth. In short, based on Suhanov's analysis:

• One timestamp only. No first run, no run count, no duration.
• Short retention. Entries older than seven days are removed during boot.
• Deleted executables disappear. An entry can be removed at boot when its executable no longer exists at the recorded path.
• Exclusions. Executables on removable media or network shares do not get entries; console programs launched from a command-line session were also observed without entries.
• No hash, no command line, no parent process. Identity and context have to come from Amcache, event logs or EDR.
• Volume numbers, not drive letters. HarddiskVolume3 must be mapped to C: using other artifacts.

A five-minute workflow

1. Collect SYSTEM, SYSTEM.LOG1, SYSTEM.LOG2 and SOFTWARE with a raw-copy tool (KAPE, Velociraptor, FTK Imager). If the hive is dirty, replay the logs with Eric Zimmerman's rla.exe (EZ tools).
2. Parse — drop the files onto the BAM/DAM Parser. It reads every control set, both layouts and DAM, names SIDs from ProfileList, and runs entirely in your browser.
3. Scope — keep "Active control set only" on, filter to the account you care about, sort by last execution.
4. Triage — look at the flags (user-writable folder, double extension, system binary out of place, dual-use tool) as pointers, not verdicts.
5. Corroborate and export — confirm key rows with Prefetch, Amcache and event logs, then export CSV or JSON into your timeline.

The step-by-step version, with the reasoning behind each filter, is in how to analyze BAM and DAM. A fictional end-to-end case using the site's sample data is in the lateral-movement investigation walkthrough.

Versions at a glance

Frequently asked questions

What is BAM in Windows forensics?

BAM (Background Activity Moderator) is a Windows 10 1709+ kernel service whose per-user registry keys in the SYSTEM hive list executables with a FILETIME timestamp. Investigators use it as per-user evidence of recent program execution.

Does BAM prove a program was executed?

A BAM entry is strong evidence that the executable ran under that SID, because bam.sys writes it on process creation and termination. It does not give a run count, a command line or a hash, so corroborate with Prefetch, Amcache or event logs.

How long do BAM entries last?

According to Maxim Suhanov's reverse engineering, entries older than seven days are removed at boot, and entries whose executable no longer exists can be removed at boot too. Acquire the SYSTEM hive early.

Sources and further reading

• Maxim Suhanov, BAM internals — the primary reverse-engineering reference for timestamps, retention and exclusions.
• kacos2000/Win10 — Bam — the 1809 path change.
• Microsoft Learn, Desktop Activity Moderator and FILETIME structure.
• Velociraptor Windows.Forensics.Bam — live collection logic.
• SANS Windows Forensic Analysis poster — BAM/DAM in the wider execution-artifact family.