BAM/DAM-Forensik: der komplette Leitfaden zu Windows BAM

TL;DR. BAM (Background Activity Moderator) und sein Geschwister DAM (Desktop Activity Moderator) sind Energieverwaltungstreiber von Windows, die nebenbei im SYSTEM-Hive eine benutzerbezogene Liste ausführbarer Dateien mit Zeitstempel führen. Für Ermittler heißt das: welches Konto welches Programm gestartet hat und wann zuletzt – ab Windows 10 1709. Die Einträge sind kurzlebig (etwa eine Woche), ignorieren Wechseldatenträger und Netzwerkfreigaben und enthalten weder Zähler noch Hash. Nutzen Sie BAM als präzisen, einem Benutzer zugeordneten Hinweis – und bestätigen Sie ihn dann.

BAM steht inzwischen auf jeder Checkliste zum „Nachweis der Programmausführung“, auch auf dem SANS-Poster Windows Forensic Analysis. Das Artefakt ist klein, schnell ausgewertet und verrät – anders als Prefetch oder der ShimCache – wer. Dieser Leitfaden bündelt, was über BAM tatsächlich bekannt ist, mit Quellen, und verweist auf die vertiefenden Artikel dieser Reihe.

Was BAM und DAM sind

Der Background Activity Moderator ist ein Kerneltreiber (bam.sys), mit dem Windows im Hintergrund laufende Anwendungen drosselt. Er kam mit Windows 10 Version 1709 (Fall Creators Update), wie frühe Forscher (padawan-4n6, 2018) und das Velociraptor-Artefakt Windows.Forensics.Bam dokumentieren.

Der Desktop Activity Moderator ist älter. Microsoft beschreibt ihn als Kernelmodustreiber, der Desktop-Prozesse anhält oder drosselt, wenn ein Gerät in den verbundenen Standby wechselt, und weist darauf hin, dass er auf Server-SKUs nicht vorhanden ist (Microsoft Learn). Unter Windows 10 und 11 führt er benutzerbezogene Einträge im gleichen Format wie BAM, in der Regel aber nur auf Hardware mit Modern Standby. Der eigene DAM-Artikel geht auf die Unterschiede ein.

Keiner von beiden wurde für die Forensik gebaut. Die Daten existieren, damit sich der Moderator merken kann, was er pro Benutzer gesehen hat; die Zeitstempel sind ein Nebenprodukt, das wir auslesen dürfen.

Wo die Daten liegen

Beide Dienste speichern ihren Zustand im SYSTEM-Hive (C:\Windows\System32\config\SYSTEM), mit einem Unterschlüssel pro Benutzer-SID:

Der Wechsel von bam\UserSettings zu bam\State\UserSettings ist in kacos2000s BAM-Recherche dokumentiert: Ab 1809 wird der alte Schlüssel nicht mehr aktualisiert, kann aber noch veraltete Einträge enthalten. Offline gibt es kein CurrentControlSet: Lesen Sie Select\Current, um das aktive Control Set zu ermitteln. Details, Sicherungsbefehle und die Falle mit den Transaktionsprotokollen finden Sie unter wo der BAM-Registry-Schlüssel liegt und wie man ihn sichert.

Was ein BAM-Eintrag enthält

Unter jedem SID-Schlüssel:

• Wertname – die ausführbare Datei als NT-Gerätepfad, etwa \Device\HarddiskVolume3\Windows\System32\cmd.exe, oder bei paketierten Apps (Store/MSIX) ein Paketfamilienname wie Microsoft.WindowsCalculator_8wekyb3d8bbwe.
• Wertdaten – ein REG_BINARY, dessen erste 8 Bytes ein FILETIME in UTC sind. Auf den von Maxim Suhanov untersuchten Builds sind die Daten 24 Bytes lang (BAM internals).
• Zwei Verwaltungswerte, Version und SequenceNumber, die keine Programme sind.

Die Ansicht Byte für Byte, mit einem dekodierten Beispiel, steht im Artikel zum BAM-Werteformat.

Was der Zeitstempel bedeutet

Suhanovs Reverse Engineering von bam.sys zeigt, dass der FILETIME beim Erzeugen und beim Beenden des Prozesses aktualisiert wird (Quelle). Bei einem Werkzeug, das nur Sekunden läuft, liegen beide Zeitpunkte praktisch zusammen. Bei einem Prozess, der stundenlang lief, liegt der gelesene Wert eher beim Beenden. Die meisten Tools, auch unseres, nennen die Spalte „letzte Ausführung“; lesen Sie sie als „letzte von BAM für diesen Pfad und Benutzer erfasste Aktivität“.

Warum Ermittler sich dafür interessieren

Genau diese Benutzerzuordnung macht den Unterschied. Prefetch, ShimCache und Amcache gelten systemweit; BAM verknüpft ein Binary mit einem Konto. Wenn ein Dienstkonto plötzlich PsExec64.exe in seinem Downloads-Ordner zeigt, wissen Sie, wessen Zugangsdaten Sie zurücksetzen müssen. Der Vergleich mit Prefetch, ShimCache und Amcache und der Vergleich mit UserAssist zeigen, wo welches Artefakt stärker ist.

BAM beschränkt sich auch nicht auf das, was ein Benutzer im Explorer per Doppelklick gestartet hat – das erfasst UserAssist. Schlüssel kann es auch für Dienst- und bekannte Konten geben – etwa S-1-5-18 (LocalSystem), das unser Parser als SYSTEM kennzeichnet. Der Artikel zur SID-Zuordnung erklärt, wie man diese Konten liest.

Was BAM nicht verrät

Die Grenzen sind so wichtig wie die Daten, und der Artikel zu Grenzen und Anti-Forensik behandelt jede im Detail. Kurz gefasst, nach Suhanovs Analyse:

• Nur ein Zeitstempel. Keine erste Ausführung, kein Zähler, keine Laufzeit.
• Kurze Aufbewahrung. Einträge, die älter als sieben Tage sind, werden beim Systemstart entfernt.
• Gelöschte Dateien verschwinden. Ein Eintrag kann beim Start entfernt werden, wenn seine ausführbare Datei am erfassten Pfad nicht mehr existiert.
• Ausschlüsse. Ausführbare Dateien auf Wechseldatenträgern oder Netzwerkfreigaben erhalten keine Einträge; auch Konsolenprogramme, die aus einer Kommandozeilensitzung gestartet wurden, wurden ohne Eintrag beobachtet.
• Kein Hash, keine Befehlszeile, kein Elternprozess. Identität und Kontext müssen aus Amcache, den Ereignisprotokollen oder dem EDR kommen.
• Volume-Nummern statt Laufwerksbuchstaben. HarddiskVolume3 muss mithilfe anderer Artefakte C: zugeordnet werden.

Ein Fünf-Minuten-Ablauf

1. Sichern Sie SYSTEM, SYSTEM.LOG1, SYSTEM.LOG2 und SOFTWARE mit einem Rohkopie-Werkzeug (KAPE, Velociraptor, FTK Imager). Ist der Hive „dirty“, spielen Sie die Protokolle mit Eric Zimmermans rla.exe ein (EZ-Tools).
2. Parsen – ziehen Sie die Dateien auf den BAM/DAM Parser. Er liest jedes Control Set, beide Formate und DAM, benennt SIDs über die ProfileList und läuft komplett in Ihrem Browser.
3. Eingrenzen – lassen Sie „Nur aktives Control Set“ aktiviert, filtern Sie auf das relevante Konto und sortieren Sie nach letzter Ausführung.
4. Sichten – betrachten Sie die Markierungen (vom Benutzer beschreibbarer Ordner, doppelte Dateiendung, Systemdatei am falschen Ort, Dual-Use-Werkzeug) als Hinweise, nicht als Urteile.
5. Bestätigen und exportieren – prüfen Sie wichtige Zeilen gegen Prefetch, Amcache und Ereignisprotokolle und exportieren Sie CSV oder JSON in Ihre Timeline.

Die Schritt-für-Schritt-Version mit der Begründung für jeden Filter finden Sie unter BAM und DAM analysieren. Einen fiktiven Fall von Anfang bis Ende mit den Beispieldaten der Website zeigt die Untersuchung eines Lateral-Movement-Falls.

Versionen auf einen Blick

Häufige Fragen

Was ist BAM in der Windows-Forensik?

BAM (Background Activity Moderator) ist ein Kerneldienst ab Windows 10 1709, dessen benutzerbezogene Registry-Schlüssel im SYSTEM-Hive ausführbare Dateien mit einem FILETIME-Zeitstempel auflisten. Ermittler nutzen ihn als benutzerbezogenen Nachweis einer kürzlichen Programmausführung.

Beweist BAM, dass ein Programm ausgeführt wurde?

Ein BAM-Eintrag ist ein starkes Indiz, dass die Datei unter dieser SID lief, denn bam.sys schreibt ihn beim Start und beim Beenden des Prozesses. Er liefert weder Ausführungszähler noch Befehlszeile noch Hash – bestätigen Sie ihn daher mit Prefetch, Amcache oder Ereignisprotokollen.

Wie lange bleiben BAM-Einträge erhalten?

Laut Maxim Suhanovs Reverse Engineering werden Einträge, die älter als sieben Tage sind, beim Systemstart entfernt; Einträge, deren ausführbare Datei nicht mehr existiert, können beim Start ebenfalls entfernt werden. Sichern Sie den SYSTEM-Hive so früh wie möglich.

Quellen und weiterführende Literatur

• Maxim Suhanov, BAM internals – die maßgebliche Reverse-Engineering-Referenz zu Zeitstempeln, Aufbewahrung und Ausschlüssen.
• kacos2000/Win10 – Bam – die Pfadänderung in 1809.
• Microsoft Learn, Desktop Activity Moderator und FILETIME-Struktur.
• Velociraptor Windows.Forensics.Bam – Logik der Live-Erfassung.
• SANS-Poster Windows Forensic Analysis – BAM/DAM in der Familie der Ausführungsartefakte.