BAM Limitations and Anti-Forensics: What BAM Misses

TL;DR. BAM is precise but forgetful and selective. Published reverse engineering shows it drops entries older than seven days at boot, removes entries whose executable is gone, and doesn't create entries for removable media, network shares or (observed) console programs launched from a command line. It keeps one timestamp, no hash, no count. Attackers get most of that evasion for free; deliberate tampering is possible but leaves inconsistencies you can look for.

Every artifact has a failure mode; the problem is only when the report doesn't mention it. This is the list we keep next to BAM findings. Background: the BAM/DAM forensics guide. Most behavioural statements below come from Maxim Suhanov's BAM internals, based on Windows 10 builds 18363 and 19592 — re-test on your evidence's build when a conclusion depends on them.

Built-in blind spots

Seven-day retention

Suhanov found that entries older than seven days are removed during boot, and located a lifetime setting, UserSettingsLifetimeMs, whose default corresponds to seven days. Entries whose moderation state was changed by the user are not subject to that age-based removal (source).

Consequences:

• A host that rebooted after the activity and more than a week later has likely lost the entry.
• A host that has not rebooted can hold entries older than a week, because pruning happens at boot.
• For older activity, parse SYSTEM hives from Volume Shadow Copies — each is a BAM snapshot at copy time (VSS overview). Our tool accepts several SYSTEM hives at once and keeps the source file on every row.

Deleted or moved executables

"BAM entries can be removed if an executable is removed from its original location", and Suhanov observed the entry disappear after a reboot (source). So the classic attacker habit — run a tool, delete it — wipes the BAM trace at the next boot. Until then the entry remains. That's a strong argument for collecting SYSTEM before anyone reboots the machine.

Removable media and network shares

Suhanov found that bam.sys refuses to create entries for executables on devices flagged as remote or removable ("BAM entries aren't created for executables on removable media and/or network shares"). Tools run from a USB stick or \\server\share\tool.exe won't appear.

An open question we haven't seen tested publicly: external drives that present themselves to Windows as fixed disks rather than removable media. If your case depends on it, reproduce it with the same hardware.

For those executions, look instead at Prefetch, Amcache, LNK files and Jump Lists for the access, and USB device artifacts for the drive.

Console programs started from a command line

Suhanov observed that "console applications don't get their BAM entries if they are launched from the command line session", and noted the cause wasn't identified. In practice, this means whoami.exe, net.exe or a console attack tool started from cmd.exe may be missing even though cmd.exe itself appears. Treat any absence of a console tool as uninformative.

One timestamp, no context

• No first execution, no run count, no duration.
• The time is updated at process creation and termination (source), so for long-running programs it may reflect the exit.
• No hash, file size, signer, command line or parent process.
• Paths use volume device names, not drive letters (see value format).

Acquisition-induced gaps

• Dirty hive. Recent writes can sit in SYSTEM.LOG1/LOG2. Replay them before concluding an entry is absent (where the key lives).
• Wrong control set. Reading ControlSet002 instead of the one in Select\Current gives you an older state.
• Legacy key only. On 1809+ the current data is in State\UserSettings; a tool reading only bam\UserSettings sees a frozen snapshot (versions).

Deliberate anti-forensics

BAM values are ordinary registry data. An attacker with enough privileges can modify them (MITRE ATT&CK T1112, Modify Registry; T1070, Indicator Removal). Realistic options, in increasing order of effort:

We haven't tested which privilege level is needed to write to these keys on current builds; check the key's permissions on a reference system rather than assuming only SYSTEM or any administrator can change them (registry key security).

Detecting tampering

1. Key last-write vs values. Each SID key's last-write time should be close to its newest value. A key written well after every remaining value means something under it changed later — possibly a deletion. Our parser shows the key time in the detail panel and exports it (SidKeyLastWriteUtc).
2. Compare control sets and snapshots. An entry present in a Volume Shadow Copy's SYSTEM hive but missing in the live one, while its executable still exists and less than a week has passed, is worth a note.
3. Cross-artifact consistency. A tool in Prefetch or Amcache but not in BAM, with none of the natural reasons above applying, is a lead, not a conclusion.
4. Registry telemetry. Sysmon event IDs 12–14 record registry object creation/deletion, value sets and renames when configured (Sysmon); parse them with EVTX Parser. Most estates don't monitor the BAM key specifically, so absence of events proves little.
5. Transaction logs. A deletion that happened just before acquisition may still be visible when comparing the hive before and after log replay.

How to word a BAM finding

• Presence: "A BAM record under SID X shows path with a last recorded activity of T UTC."
• Absence: "No BAM record was found for path. BAM does not record executables on removable media or network shares, prunes entries older than seven days at boot, and removes entries for executables deleted before a reboot; the absence is therefore not evidence that the program did not run."

Then corroborate with the comparison matrix, and parse the hive with the BAM/DAM Parser, which warns about dirty hives and legacy layouts so the gaps are visible up front.

Frequently asked questions

Why is a program I know ran missing from BAM?

Common reasons: it ran from removable media or a network share, it was a console program started from a command line, its entry was pruned at boot after seven days, its executable was deleted and the host rebooted, or the latest writes are still in SYSTEM.LOG1/LOG2.

Can an attacker edit or delete BAM entries?

Yes, with sufficient privileges the values are ordinary registry data. Deletion or edits can leave traces: SID key last-write times newer than every value, gaps compared with Prefetch or Amcache, and registry auditing or Sysmon events if they were enabled.