Grenzen von BAM und Anti-Forensik: was BAM übersieht

TL;DR. BAM ist präzise, aber vergesslich und wählerisch. Veröffentlichtes Reverse Engineering zeigt, dass es Einträge älter als sieben Tage beim Start entfernt, Einträge verschwundener Dateien löscht und keine Einträge für Wechseldatenträger, Netzwerkfreigaben und (beobachtet) aus der Kommandozeile gestartete Konsolenprogramme anlegt. Es speichert einen Zeitstempel, keinen Hash, keinen Zähler. Angreifer bekommen den Großteil dieser Tarnung geschenkt; gezielte Manipulation ist möglich, hinterlässt aber Ungereimtheiten, nach denen man suchen kann.

Jedes Artefakt hat seine Schwächen; problematisch wird es erst, wenn der Bericht sie verschweigt. Das ist die Liste, die wir neben jeden BAM-Befund legen. Zum Hintergrund: der komplette BAM/DAM-Leitfaden. Die meisten Aussagen zum Verhalten stammen aus Maxim Suhanovs BAM internals, basierend auf den Windows-10-Builds 18363 und 19592 – testen Sie auf dem Build Ihres Beweismittels erneut, wenn eine Schlussfolgerung davon abhängt.

Eingebaute blinde Flecken

Sieben Tage Aufbewahrung

Suhanov stellte fest, dass Einträge älter als sieben Tage beim Systemstart entfernt werden, und fand eine Lebensdauer-Einstellung UserSettingsLifetimeMs, deren Standardwert sieben Tagen entspricht. Einträge, deren Moderationsstatus der Benutzer geändert hat, unterliegen dieser altersbasierten Entfernung nicht (Quelle).

Folgen:

• Ein Host, der mehr als eine Woche nach der Aktivität neu gestartet wurde, hat den Eintrag wahrscheinlich verloren.
• Ein Host, der nicht neu gestartet wurde, kann Einträge älter als eine Woche enthalten, weil die Bereinigung beim Start erfolgt.
• Für ältere Aktivität parsen Sie SYSTEM-Hives aus Volumeschattenkopien – jede ist ein BAM-Stand zum Kopierzeitpunkt (VSS-Überblick). Unser Tool nimmt mehrere SYSTEM-Hives gleichzeitig an und behält die Quelldatei in jeder Zeile.

Gelöschte oder verschobene Dateien

„BAM-Einträge können entfernt werden, wenn eine ausführbare Datei von ihrem ursprünglichen Ort entfernt wird“, und Suhanov beobachtete, wie der Eintrag nach einem Neustart verschwand (Quelle). Die klassische Angreifer-Gewohnheit – Tool ausführen, Tool löschen – tilgt die BAM-Spur also beim nächsten Start. Bis dahin bleibt der Eintrag. Ein starkes Argument dafür, SYSTEM zu sichern, bevor jemand den Rechner neu startet.

Wechseldatenträger und Netzwerkfreigaben

Suhanov fand, dass bam.sys für ausführbare Dateien auf als entfernt oder wechselbar gekennzeichneten Geräten keine Einträge anlegt („für ausführbare Dateien auf Wechseldatenträgern und/oder Netzwerkfreigaben werden keine BAM-Einträge erstellt“). Tools, die von einem USB-Stick oder aus \\server\share\tool.exe laufen, erscheinen nicht.

Eine offene Frage, die wir nirgends öffentlich getestet gesehen haben: externe Laufwerke, die sich gegenüber Windows als feste statt als Wechseldatenträger ausgeben. Hängt Ihr Fall davon ab, reproduzieren Sie es mit derselben Hardware.

Für solche Ausführungen sehen Sie stattdessen in Prefetch, Amcache, LNK-Dateien und Jump Lists nach dem Zugriff, und in USB-Geräteartefakten nach dem Laufwerk.

Aus der Kommandozeile gestartete Konsolenprogramme

Suhanov beobachtete, dass „Konsolenanwendungen keine BAM-Einträge erhalten, wenn sie aus der Kommandozeilensitzung gestartet werden“, und hielt fest, dass die Ursache nicht geklärt wurde. Praktisch heißt das: whoami.exe, net.exe oder ein Konsolen-Angriffswerkzeug, das aus cmd.exe gestartet wurde, können fehlen, obwohl cmd.exe selbst erscheint. Werten Sie das Fehlen eines Konsolen-Tools als nicht aussagekräftig.

Ein Zeitstempel, kein Kontext

• Keine erste Ausführung, kein Zähler, keine Laufzeit.
• Die Zeit wird beim Erzeugen und beim Beenden des Prozesses aktualisiert (Quelle); bei lange laufenden Programmen kann sie also das Beenden widerspiegeln.
• Kein Hash, keine Dateigröße, kein Signierer, keine Befehlszeile, kein Elternprozess.
• Pfade nutzen Volume-Gerätenamen statt Laufwerksbuchstaben (siehe Werteformat).

Lücken durch die Sicherung

• Dirty Hive. Jüngste Schreibvorgänge können in SYSTEM.LOG1/LOG2 liegen. Spielen Sie sie ein, bevor Sie auf einen fehlenden Eintrag schließen (wo der Schlüssel liegt).
• Falsches Control Set. Wer ControlSet002 statt des in Select\Current genannten liest, bekommt einen älteren Stand.
• Nur der alte Schlüssel. Ab 1809 liegen die aktuellen Daten in State\UserSettings; ein Tool, das nur bam\UserSettings liest, sieht einen eingefrorenen Stand (Versionen).

Gezielte Anti-Forensik

BAM-Werte sind gewöhnliche Registry-Daten. Ein Angreifer mit ausreichenden Rechten kann sie ändern (MITRE ATT&CK T1112, Modify Registry; T1070, Indicator Removal). Realistische Optionen, nach steigendem Aufwand:

Welche Rechte zum Schreiben in diese Schlüssel auf aktuellen Builds nötig sind, haben wir nicht getestet; prüfen Sie die Berechtigungen des Schlüssels auf einem Referenzsystem, statt anzunehmen, dass nur SYSTEM oder jeder Administrator sie ändern kann (Sicherheit von Registry-Schlüsseln).

Manipulation erkennen

1. Schlüsselzeit vs. Werte. Der letzte Schreibzugriff jedes SID-Schlüssels sollte nahe an seinem jüngsten Wert liegen. Ein Schlüssel, der lange nach allen verbliebenen Werten geschrieben wurde, bedeutet, dass sich darunter später etwas geändert hat – möglicherweise eine Löschung. Unser Parser zeigt die Schlüsselzeit im Detailbereich und exportiert sie (SidKeyLastWriteUtc).
2. Control Sets und Stände vergleichen. Ein Eintrag, der im SYSTEM-Hive einer Volumeschattenkopie vorhanden ist, im aktuellen aber fehlt, obwohl die Datei noch existiert und weniger als eine Woche vergangen ist, verdient eine Notiz.
3. Konsistenz über Artefakte hinweg. Ein Tool in Prefetch oder Amcache, aber nicht in BAM, ohne dass einer der natürlichen Gründe oben greift, ist eine Spur, keine Schlussfolgerung.
4. Registry-Telemetrie. Die Sysmon-Ereignisse 12 bis 14 erfassen – wenn konfiguriert – Erstellen/Löschen von Registry-Objekten, gesetzte Werte und Umbenennungen (Sysmon); werten Sie sie mit EVTX Parser aus. Die meisten Umgebungen überwachen den BAM-Schlüssel nicht gezielt, das Fehlen von Ereignissen beweist also wenig.
5. Transaktionsprotokolle. Eine Löschung kurz vor der Sicherung kann beim Vergleich des Hives vor und nach dem Einspielen der Protokolle noch sichtbar sein.

Einen BAM-Befund formulieren

• Vorhanden: „Ein BAM-Eintrag unter der SID X zeigt Pfad mit einer zuletzt erfassten Aktivität um T UTC.“
• Fehlend: „Für Pfad wurde kein BAM-Eintrag gefunden. BAM erfasst keine ausführbaren Dateien auf Wechseldatenträgern oder Netzwerkfreigaben, entfernt Einträge älter als sieben Tage beim Start und löscht Einträge für vor einem Neustart gelöschte Dateien; das Fehlen belegt daher nicht, dass das Programm nicht ausgeführt wurde.“

Bestätigen Sie anschließend mit der Vergleichsmatrix und parsen Sie den Hive mit dem BAM/DAM Parser, der vor Dirty Hives und alten Formaten warnt, damit die Lücken von Anfang an sichtbar sind.

Häufige Fragen

Warum fehlt in BAM ein Programm, von dem ich weiß, dass es lief?

Häufige Gründe: Es lief von einem Wechseldatenträger oder einer Netzwerkfreigabe, es war ein aus der Kommandozeile gestartetes Konsolenprogramm, sein Eintrag wurde nach sieben Tagen beim Start bereinigt, die ausführbare Datei wurde gelöscht und der Host neu gestartet, oder die jüngsten Schreibvorgänge liegen noch in SYSTEM.LOG1/LOG2.

Kann ein Angreifer BAM-Einträge ändern oder löschen?

Ja – mit ausreichenden Rechten sind die Werte gewöhnliche Registry-Daten. Löschungen oder Änderungen können Spuren hinterlassen: ein letzter Schreibzugriff auf den SID-Schlüssel nach allen Werten, Abweichungen zu Prefetch oder Amcache sowie Registry-Überwachungs- oder Sysmon-Ereignisse, sofern aktiviert.