Zum Inhalt springen

Amcache-Forensik: Ausführungsbeweise finden

Die Frage, die Amcache ins Spiel bringt, ist fast immer eine Variante von "belegen Sie, dass dieses Ding auf diesem Host lief" — ein Tool, das der Angreifer gelöscht hat, eine Binärdatei, die ein EDR-Alert benannt hat, die der Analyst aber nicht auf der Platte findet, Schadsoftware, die sich nach dem Staging selbst gelöscht hat. Amcache.hve ist auf einem Windows-System der günstigste Ort, um diese Frage zu beantworten, denn der Compatibility Appraiser inventarisiert Portable Executables unabhängig davon, ob sie noch existieren, und er zeichnet das eine Feld auf, das alles andere überlebt: den SHA-1-Hash.

Dies ist der Durchlauf von Anfang bis Ende: die Hive sammeln, sie parsen, den Lärm wegschneiden, die relevanten Einträge finden, auf ihnen pivotieren und — der Teil, den die meisten Leitfäden überspringen — genau verstehen, was ein Amcache-Treffer beweist und was nicht. Wenn Sie die Artefaktreferenz statt des Workflows suchen, beginnen Sie mit der vollständigen Amcache-Referenz; diese Seite geht darum, es zur Beweissuche zu verwenden.

Was ein Amcache-Eintrag tatsächlich beweist#

Das muss zuerst sitzen, denn jede nachgelagerte Schlussfolgerung hängt davon ab.

Amcaches zentraler Key, Root\InventoryApplicationFile, enthält einen Eintrag pro PE, die der Appraiser gesehen hat. Ein Eintrag bedeutet: diese ausführbare Datei war beim Lauf des Appraisers im Dateisystem vorhanden, und hier sind ihre Metadaten. Das ist Präsenz, nicht Ausführung. In der überwältigenden Mehrheit der realen Fälle ist die Unterscheidung akademisch — die mimikatz.exe eines Angreifers in C:\ProgramData\ landete dort, um ausgeführt zu werden —, aber vor Gericht oder in einem Bericht formulieren Sie es präzise:

  • Starke Aussage, gut gestützt: die Binärdatei mit diesem SHA-1 und diesem Pfad existierte auf diesem Host zum oder vor dem Appraiser-Lauf, der diesen Eintrag geschrieben hat.
  • Schwächere Aussage, braucht Bestätigung: die Binärdatei wurde ausgeführt. Bestätigen Sie mit Prefetch, ShimCache, Sysmon Event ID 1 oder Security 4688.

Die ehrliche Rahmung — Präsenz zuerst, Ausführung durch Bestätigung — unterscheidet einen Befund, der einer Überprüfung standhält, von einem, der zerrissen wird. Siehe was Amcache aussagt für die vollständige Behandlung dieser Grenze.

Schritt 1: die Hive sammeln#

Die Datei liegt auf jeder Windows-Version ab 8 an einem festen Pfad:

C:\Windows\AppCompat\Programs\Amcache.hve
C:\Windows\AppCompat\Programs\Amcache.hve.LOG1
C:\Windows\AppCompat\Programs\Amcache.hve.LOG2

Auf einem Live-Host ist die Hive geöffnet gehalten, Sie können sie also nicht einfach mit dem Explorer kopieren. Verwenden Sie eine Raw-Handle-Kopie (KAPE, FTK Imager, RawCopy oder das Velociraptor-Artefakt) und nehmen Sie die beiden .LOG-Transaktionsprotokolle mit — sie tragen Schreibvorgänge, die noch nicht in die Hive geflusht sind, und ein guter Parser spielt sie ab. Die vollständigen Sammeloptionen stehen in Amcache.hve sammeln; die Kurzfassung lautet: alle drei Dateien kopieren, einer Hot-Kopie ohne die Logs nie trauen.

# KAPE, der Standard-Triage-Pfad
kape.exe --tsource C: --target Amcache --tdest C:\triage\

Schritt 2: mit AmcacheParser parsen#

Eric Zimmermans AmcacheParser ist das De-facto-Tool. Die wichtigen Flags:

AmcacheParser.exe -f Amcache.hve --csv .\out\ --mp -i
  • -f — die zu parsende Hive.
  • --csv — Ausgabeverzeichnis für den CSV-Satz.
  • --mp — die \Microsoft\-Pfade einschließen (nicht zur Parse-Zeit vorfiltern; später filtern, wo Sie sehen, was Sie verworfen haben).
  • -i — Einträge auch dann einschließen, wenn die Appraiser-Daten unvollständig sind.

Es spielt die Transaktionsprotokolle automatisch ab und gibt einen Satz CSVs aus — UnassociatedFileEntries.csv und AssociatedFileEntries.csv sind die beiden, in denen Sie leben. (Keine Windows-Maschine zur Hand? Legen Sie die Hive auf den Browser-Parser — er liest die Hive clientseitig über WebAssembly und lädt sie nie hoch, was auch die Regel "keine Drittanbieter-Uploads" erfüllt, die regulierte Umgebungen auferlegen.) Für die Bedeutung jeder Spalte halten Sie AmcacheParser-Ausgabespalten in einem Tab offen.

Schritt 3: die beweistragenden Felder lesen#

Pro Dateieintrag sind dies die, auf denen Sie Befunde aufbauen:

Feld Was es Ihnen gibt Beweiskraft
FileId (SHA-1) Hash der Datei. Der Pivot-Schlüssel über Hosts hinweg und in die Threat Intel. Am höchsten. Überlebt Löschung und Umbenennung.
LowerCaseLongPath Vollständiger Pfad, an dem die Binärdatei lag. Hoch. Ort ist Absicht (\Temp\, \ProgramData\ vs. \Program Files\).
Name / OriginalFileName Name auf der Platte vs. PE-interner Name. Eine Abweichung ist ein Signal. Hoch, wenn sie sich widersprechen.
Publisher / IsPeSigned Signatur-Identität. Leer/unsigniert in Benutzerpfaden ist verdächtig. Mittel.
LinkDate PE-Kompilierzeitstempel. Mittel, fälschbar.
Size Dateigröße in Bytes. Mittel, bestätigend.
KeyLastWriteTimestamp Wann der Appraiser diesen Eintrag zuletzt geschrieben hat. Mittel — eine Schranke, keine Ausführungszeit.
IsOsComponent Ob Windows die Datei als OS-Datei betrachtet. Filtersignal, kein Beweis.

Die FileId verdient besondere Aufmerksamkeit: AmcacheParser entfernt die führende 0000-Auffüllung für Sie, sodass die verbleibenden 40 Hex-Zeichen der echte SHA-1 der Datei sind — fügen Sie ihn direkt in VirusTotal ein. Die vollständige Mechanik steht in Amcache FileId erklärt und der Jagd-Workflow in SHA-1-Hashes für die Malware-Jagd.

Schritt 4: den Lärm filtern#

UnassociatedFileEntries.csv umfasst auf einer normalen Workstation Zehntausende Zeilen. Das können Sie nicht lesen. Die Filterreihenfolge, die ich jedes Mal anwende, identisch mit dem, worauf erfahrene Analysten konvergieren:

  1. OS-Infrastruktur per Pfad verwerfen. Alles unter c:\windows\winsxs\, c:\windows\servicing\, c:\program files\microsoft\.
  2. IsOsComponent = True verwerfen. Mehr OS-Lärm, den der Pfadfilter verpasst hat.
  3. Die interessanten Gegenden behalten. Pfade in \users\, \programdata\, \windows\temp\, \perflogs\ oder alles, was \appdata\ enthält. Angreifer stagen dort, wo sie schreiben können.
  4. Leere oder Unknown-Publisher behalten. Signierte Software mit echtem Publisher ist selten die erste Spur.
  5. Absteigend nach KeyLastWriteTimestamp sortieren. Bearbeiten Sie zuerst das Fenster, das Sie interessiert.

In PowerShell, gegen die geparste CSV:

Import-Csv .\out\*_UnassociatedFileEntries.csv |
  Where-Object {
    $_.IsOsComponent -ne 'True' -and
    $_.LowerCaseLongPath -notmatch '\\winsxs\\|\\servicing\\|\\program files\\microsoft\\' -and
    $_.LowerCaseLongPath -match '\\users\\|\\programdata\\|\\windows\\temp\\|\\appdata\\|\\perflogs\\'
  } |
  Sort-Object KeyLastWriteTimestamp -Descending |
  Select-Object KeyLastWriteTimestamp, LowerCaseLongPath, Name, Publisher, FileId |
  Format-Table -AutoSize

Aus zwanzigtausend Zeilen werden ein paar Dutzend. Das ist der Satz, den Sie tatsächlich lesen.

Schritt 5: ein durchgearbeitetes Beispiel — die gelöschte Binärdatei#

Hier ist das Muster, das Amcache wert macht, zuerst danach zu greifen. Der gefilterte Satz fördert eine Zeile wie diese zutage:

KeyLastWriteTimestamp: 2026-06-09 23:51:07 UTC
LowerCaseLongPath:   c:\programdata\intel\drivers\igfxsvc.exe
Name:          igfxsvc.exe
OriginalFileName:    rundll32.exe
Publisher:        (empty)
IsPeSigned:        False
FileId:          0000a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2
Size:           1264640

Drei Dinge lassen diesen Eintrag aufschreien:

  • Name/OriginalFileName-Abweichung. Die Datei nennt sich auf der Platte igfxsvc.exe, aber ihr PE-Header sagt rundll32.exe. Legitime Intel-Grafiksoftware tut das nicht. Umbenanntes System-Tooling — oder etwas, das sich als solches ausgibt.
  • Falsche Gegend. Echte Intel-Treiber liegen nicht unter c:\programdata\intel\drivers\. Dieser Pfad ist vom Angreifer gewählte Tarnung.
  • Unsigniert, kein Publisher, in einem beschreibbaren Verzeichnis. Drei schwache Signale, die sich zu einem starken summieren.

Nun ist die Binärdatei selbst von der Platte verschwunden — der Angreifer hat sie gelöscht. Sie haben trotzdem alles, was Sie brauchen:

  1. Den SHA-1 pivotieren. Nehmen Sie a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2 (die 0000 weglassen) zu VirusTotal / Ihrer Intel-Plattform. Ein Treffer benennt das Tool. Kein Treffer bedeutet: über das Amcache jedes anderen Hosts laufen lassen, um zu sehen, wo sonst genau diese Datei landete.
  2. Eine Zeitschranke setzen. KeyLastWriteTimestamp von 2026-06-09 23:51 sagt Ihnen, dass die Datei bis zu diesem Moment vorhanden war. Kombinieren Sie es mit der Zeitstempel-Referenz, damit Sie nicht überdehnen — das ist die Schreibzeit des Appraisers, nicht die Ausführungszeit.
  3. Ausführung bestätigen. Wechseln Sie zu Prefetch für IGFXSVC.EXE-<hash>.pf (Lauf-Zähler + letzte Laufzeiten), zu ShimCache und zu Sysmon EID 1 / Security 4688 für das tatsächliche Process-Create. Amcache sagt es war hier; jene sagen es lief, so oft, zu diesen Zeitpunkten.

Diese Kette — zutage fördern, pivotieren, eingrenzen, bestätigen — ist das Rückgrat von einen echten Vorfall mit Amcache untersuchen und dem Leitfaden zur Malware-Untersuchung.

Über ausführbare Dateien hinaus: Geräte- und Treiberbeweise#

Programmausführung ist die Schlagzeile, aber dieselbe Hive beantwortet zwei weitere Beweisfragen, die Analysten zu wenig nutzen:

  • Welche Hardware hat diesen Host berührt? Root\InventoryDeviceContainer und Root\InventoryDevicePnp geben die sauberste tabellarische USB-/Peripherie-Historie, die Windows offenlegt — Friendly Names, Hersteller/Modell, Verbindungsstatus. Das ist die Basis jeder USB-Exfiltrations-Triage; die vollständige Methode steht in USB- und Gerätehistorie aus Amcache. Es ist laut Suchdaten auch die Frage, mit der Leute am häufigsten zu Amcache kommen — die Paarung DeviceContainers / KeyLastWriteTimestamp.
  • Welche Treiber wurden geladen? Root\InventoryDriverBinary zeichnet Treiberbinärdateien mit eigenen Hashes auf — das Artefakt, das Sie auf BYOVD-Angriffe (Bring Your Own Vulnerable Driver) prüfen, bei denen ein signierter, aber verwundbarer Treiber abgelegt wird, um Kernel-Zugriff zu erlangen.

Die Grenzen, die Analysten überraschen#

Die it-connect-artigen Durchläufe verweilen zu Recht hier, und das werde ich auch. Ein Amcache-Befund ist nur so gut wie Ihr Bewusstsein dafür, was die Hive Ihnen nicht sagen kann.

Skripte sind unsichtbar#

.ps1, .cmd, .bat, .vbs — keines davon hat einen PE-Header, also inventarisiert der Appraiser sie nicht als Dateieinträge. Ein reiner PowerShell-Einbruch kann keine Amcache-Ausführungsspur für die schädliche Logik selbst hinterlassen (obwohl powershell.exe und alle kompilierten Tools, die er ablegt, erscheinen werden). Für Skriptausführung brauchen Sie Prefetch, ScriptBlock-Logging (EID 4104) und die Kommandozeile in 4688/Sysmon. Das ist der häufigste einzelne Grund, warum ein Analyst fälschlich "nichts lief" schließt.

OS-Komponenten werden bewusst herausgefiltert#

Mit IsOsComponent = True markierte Einträge — und viele Living-off-the-Land-Binärdateien, die mit Windows ausgeliefert werden — können fehlen oder zurückgestuft sein. Ein Angreifer, der nur certutil.exe, bitsadmin.exe, wmic.exe nutzt, hinterlässt eine dünne Amcache-Spur, gerade weil das OS-Komponenten sind. LOLBins entgehen dem Inventar auf dieselbe Weise, wie sie allem anderen entgehen.

Es ist ein Inventar, kein Protokoll#

Es gibt keinen Datensatz pro Ausführung und keinen Lauf-Zähler — das ist Prefetchs Aufgabe. Ein Amcache-Eintrag pro Datei, an Ort und Stelle aktualisiert. Wenn eine Binärdatei fünfzigmal lief, sehen Sie eine Zeile, und KeyLastWriteTimestamp spiegelt den letzten Schreibvorgang des Appraisers wider, nicht den letzten Lauf.

Die Appraiser-Verzögerung ist real#

Der Microsoft Compatibility Appraiser läuft ungefähr täglich, gedrosselt durch Leerlauf- und Energiezustand. Eine Binärdatei, die zwei Stunden vor dem Ziehen der Hive lief, ist vielleicht schlicht noch nicht inventarisiert. Das Fehlen eines Amcache-Eintrags ist nie ein Beweis, dass eine Binärdatei nicht lief — siehe warum ist mein Amcache leer und wie oft Amcache aktualisiert wird.

Zeitstempel sind Schranken, keine Ereignisse#

KeyLastWriteTimestamp ist die Schreibzeit des Appraisers. LinkDate ist ein Kompilierzeitstempel, den der Autor kontrolliert und fälschen kann. Keiner ist "die Zeit, zu der das Programm lief". Die disziplinierte Lesart steht in Amcache-Zeitstempel entschlüsselt.

Korrelation: wo Amcache ins Bild passt#

Amcache verdient seinen Platz als der schnelle erste Blick und der Überlebende der Löschung. Es ist am stärksten, wenn es trianguliert wird:

Frage Amcache Bestätigen mit
War diese Binärdatei auf dem Host? Ja — Primärquelle $MFT, $J für die Dateisystem-Timeline
Wurde sie ausgeführt? Impliziert Präsenz Prefetch, ShimCache, Sysmon 1, Security 4688
Wie oft / wann genau? Nein Prefetch (Lauf-Zähler + 8 letzte Laufzeiten)
Was ist diese Datei genau? SHA-1 — primär VirusTotal / Threat Intel
Welche Hardware war verbunden? Geräte-Keys — primär setupapi.dev.log, USBSTOR
Lief ein Skript? Nein EID 4104, 4688, Prefetch

Für die Artefakt-für-Artefakt-Vergleiche siehe Amcache vs. Prefetch, Amcache vs. ShimCache und Amcache vs. SRUM.

Der Workflow auf einem Bildschirm#

  1. Amcache.hve + beide .LOG-Dateien sammeln (Raw-Kopie).
  2. AmcacheParser.exe -f Amcache.hve --csv .\out\ --mp -i.
  3. Filtern: OS-Pfade und IsOsComponent verwerfen, beschreibbare Benutzerpfade und leere Publisher behalten, absteigend nach KeyLastWriteTimestamp sortieren.
  4. Die übrigen Zeilen auf Pfad-/Namensabweichungen und ungewöhnliche Gegenden lesen.
  5. Den SHA-1 jedes Kandidaten in die Intel und über Hosts hinweg pivotieren.
  6. Die Zeit mit KeyLastWriteTimestamp eingrenzen; sie nie die Ausführungszeit nennen.
  7. Ausführung in Prefetch / ShimCache / EVTX bestätigen.
  8. Präsenz als Tatsache, Ausführung als bestätigt formulieren — und benennen, was die Hive nicht sehen konnte.

So machen Sie aus Amcache.hve einen Beweis statt einer Vermutung.

Verwandt#

Verwandte Beiträge

← Zurück zu allen Beiträgen