Was die Amcache in einer DFIR-Untersuchung tatsächlich sagt

Die meisten Beiträge zur Amcache behandeln sie als saubere Aufzeichnung von "jedem Programm, das auf diesem Host gelaufen ist". Das stimmt nicht. Nach ein paar hundert Vorfällen vertraut man dieser Sicht nicht mehr und beginnt, die Hive als das zu behandeln, was sie wirklich ist: ein lautes, asynchrones Nebenprodukt des Program Compatibility Assistant bei seiner Arbeit, das im DFIR sehr nützlich ist, weil es Deinstallationen, Dateilöschungen und Registry-Manipulationen deutlich besser übersteht, als die meisten Leute erwarten.

Dieser Beitrag ist die Version des Gesprächs, das ich mit einem neuen Analysten in meinem Team führen würde. Was die Hive beweist, was nicht, und die konkreten Stellen, an denen ich Untersuchungen entgleisen sehen habe.

Wo die Hive lebt und warum das schon zählt#

C:\Windows\AppCompat\Programs\Amcache.hve auf Windows 7 SP1 und neuer. Es ist eine Registry-Hive im üblichen regf-Format, was bedeutet, dass jeder Parser, der NTUSER.DAT lesen kann, sie im Prinzip lesen kann. Forensisch interessant wird sie dadurch, dass sie von compattelrunner.exe transparent geschrieben wird, wann immer der Program Compatibility Assistant das System inventarisiert, was nach Plan passiert (Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser) und bei bestimmten Installer-/Deinstaller-Events.

Ein paar praktische Konsequenzen daraus:

• Die Hive lebt außerhalb des Benutzerprofils, ist also pro Maschine, nicht pro Benutzer. Sie können einem Eintrag aus der Hive allein kein bestimmtes Konto zuordnen.
• Die Appraiser-Task lässt sich per Gruppenrichtlinie deaktivieren, durch gewisse "Telemetrie-Remover"-Skripte und durch manche EDR-Baseline-Konfigurationen. Auf solchen Hosts kann die Hive wochenlang veraltet sein. Ich habe Untersuchungen geerbt, in denen das IR-Team die Amcache als Smoking Gun angenommen hat, bevor jemand geprüft hat, ob die Task überhaupt gelaufen ist.
• Da sie eine reguläre Hive ist, hat sie ein Transaktionslog-Paar (Amcache.hve.LOG1 / Amcache.hve.LOG2). Erfassen Sie diese immer zusammen mit der Hauptdatei. Das Nachspielen stellt Einträge wieder her, die zum Erfassungszeitpunkt in flight waren, und fördert gelegentlich Datensätze zutage, die nie in die Live-Hive gelangt sind.

Was ein Eintrag tatsächlich beweist#

Die ehrliche Antwort lautet: eine Datei war zu dem Zeitpunkt, als der Appraiser das Dateisystem durchlief, auf der Platte präsent. Mehr nicht.

Hier beginnen die häufigsten Fehler. Die Hive beweist keine Ausführung. Sie beweist Existenz zum Scanzeitpunkt. Operativ zählt diese Unterscheidung aus drei Gründen:

1. Dateien, die zwischen Appraiser-Läufen abgelegt und gelöscht werden, hinterlassen nichts. Ein Red-Team-Operator, der weiß, was er tut, kann ein Tool innerhalb eines einzigen Scan-Fensters einschleusen und entfernen. Die Amcache wird es nie erwähnen. Koppeln Sie die Hive mit Prefetch und Sysmon / Sicherheits-Ereignisprotokollen, bevor Sie "keine Hinweise auf Ausführung" behaupten.
2. Die Inventarisierung eines Installers ist nicht die Ausführung der Payload. Als Setup lief, indexierte der Appraiser alles, was es in Program Files kopiert hat. Das schließt Shellcode-Launcher und gebündelte Exfil-Tools ein, die nie aufgerufen wurden. Die Präsenz von evil.exe unter InventoryApplicationFile ist interessant, nicht belastend.
3. Auch Binärdateien von Netzwerkfreigaben tauchen auf. UNC-Pfade werden inventarisiert, wenn der Appraiser sie eingebunden sieht. Wenn ein Benutzer eine Datei aus \\fileserver\public\ doppelt angeklickt hat, kann der Eintrag aussehen wie eine lokal installierte Binärdatei. Lesen Sie den Pfad sorgfältig.

Was die Hive zuverlässig beweist, ist, dass die Datei zu einem bestimmten Zeitpunkt mit einem bestimmten SHA-1-Hash existiert hat. Das reicht zum Pivotieren, gegen Threat Intel, gegen VirusTotal, gegen andere Hosts im Bestand, selbst wenn die On-Disk-Datei längst weg ist. Das ist das nützlichste Einzelmerkmal der Amcache und der Grund, warum ich auf einem Host, bei dem ich Dateilöschung vermute, die Hive immer als Erstes abgreife.

Die Zeitstempel führen Sie in die Irre, wenn Sie sie lassen#

Es gibt mindestens fünf zeitstempelartige Felder, verstreut über die Keys, die Sie interessieren, und sie bedeuten nicht alle dasselbe. Die Namen sprechen nicht für sich, die Dokumentation ist dünn, und die Werte spiegeln je nach Windows-Build unterschiedliche Ereignisse wider.

Ein kurzer Feldführer, der über Win7, Win10 und Win11 gehalten hat:

• FileId ist kein Zeitstempel. Es ist ein mit 0000 präfixierter SHA-1-Hash. Leute fallen in Skripten ständig darüber.
• LinkDate (wo vorhanden) ist der Compile-Zeitstempel des PE-Headers. Vom Angreifer kontrolliert. Behandeln Sie es als Metadatum über die Binärdatei, nicht darüber, wann sie die Maschine berührt hat.
• Die LastWrite-Zeit des Keys auf InventoryApplicationFile\<id> ist in der Praxis der nützlichste Proxy für "Appraiser hat diese Datei bemerkt". Es ist nicht Erstellungszeit oder Ausführungszeit der Datei.
• InstallDate unter InventoryApplication ist das, was der Installer gemeldet hat. MSI-Installer füllen das meist ehrlich aus. Lose gepackte Installer und viele Malware-Dropper nicht, also verlassen Sie sich nicht darauf für Angreifer-Timelines.
• Bauen Sie eine Super-Timeline durch MFT und das USN-Journal, bevor Sie sich auf irgendein Narrativ festlegen, das allein auf Amcache-Zeitstempeln beruht. Querprüfung ist billig; im Abschlussbericht falsch zu liegen, ist es nicht.

Die Felder, die ihre Miete verdienen#

Nach ProgramId und SHA-1 ist das Feld, das ich am häufigsten anfasse, OriginalFileName unter InventoryApplicationFile. Es stammt aus dem Version-Resource des PE und ist für nachlässige Angreifer schwerer zu scrubben als LowerCaseLongPath. Ich habe es genutzt, um eine umbenannte svchost.exe, die in \AppData\Local\Temp\ abgelegt war, zurück auf ihre echte Identität (mimikatz.exe) zu binden, weil der Resource-Block nie editiert wurde.

BinaryType ist auch lesenswert: pe32_file versus pe64_file versus xbox_one_pkg_file (ja, wirklich). Mismatches zwischen BinaryType und Pfad können bei gepackten oder umgepackten Samples ein Hinweis sein.

Die Keys InventoryApplicationShortcut und InventoryDeviceContainer übersieht man leicht. Der Shortcut-Subkey erfasst von Windows betrachtete .lnk-Dateien, auch solche für Wechselmedien, manchmal das einzige verbleibende Beweismittel dafür, dass ein Benutzer eine Datei von einem USB-Stick geöffnet hat, der seither aus dem Haus gewandert ist. Kombinieren Sie diese mit dem LNK-Parser und dem Shim-Cache für die stärkste Aussage.

Anti-Forensik: was Angreifer leise tun können und was nicht#

Die Hive ist eine reguläre Registry-Datei. Jeder mit SYSTEM kann sie schreiben. In der Praxis tauchen drei Muster auf:

• Komplette Löschung. Amcache.hve ist gesperrt, solange Windows läuft, also schalten Angreifer compattelrunner und den Registry-Prozess vor dem Löschen ab oder reihen ein Pending File Rename ein. Löschen ist leicht zu erkennen, die Datei sollte auf einem gesunden Host immer da sein, aber Sie verlieren den historischen Inhalt. Hoffen Sie auf ein aktuelles Backup oder eine Schattenkopie.
• Gezielte Key-Löschung. Bestimmte Subkeys unter InventoryApplicationFile entfernen, um eine konkrete Binärdatei zu scrubben. Möglich, aber: die Operation aktualisiert den LastWrite des Eltern-Keys, und die Transaktionslogs halten den alten Datensatz möglicherweise noch. Ich habe ~30 % der "gelöschten" Einträge aus .LOG1/.LOG2 wiederhergestellt in Fällen, in denen der Angreifer diese nicht ebenfalls gelöscht hat.
• Vertrauenswürdige-Anbieter-Maskerade. Setzen der PE-Version-Resources eines abgelegten Tools, um eine Microsoft-Komponente nachzuahmen. Das überlebt in die Amcache, ändert aber den SHA-1 nicht. Hash-Lookup schlägt String-Lookup immer.

Die Kategorie, zu der kompetente Angreifer tatsächlich greifen, ist, die Compatibility-Appraiser-Task von vornherein zu deaktivieren. Auf einem Host, bei dem die Amcache für den Zeitraum von Interesse verdächtig leer ist, prüfen Sie die Task-Scheduler-Historie in Microsoft-Windows-TaskScheduler%4Operational.evtx, bevor Sie die Abwesenheit von Beweisen als Beweis der Abwesenheit nehmen.

Ein Workflow, der einer Review tatsächlich standhält#

Was ich in dieser Reihenfolge auf einem Host tue, auf dem die Amcache zählt:

1. Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 zusammen erfassen. Auf einem Live-System einen VSS-Snapshot oder ein Tool nutzen, das die Sperre korrekt handhabt. Nicht die Live-Datei mit xcopy kopieren.
2. Die Logs nachspielen. Die meisten Parser tun das automatisch; verifizieren, indem geprüft wird, ob die geborgene Hive ohne Warnungen öffnet.
3. SHA-1, OriginalFileName, LowerCaseLongPath und die LastWrite des Keys für jeden InventoryApplicationFile-Eintrag ziehen. Das ist das Arbeitsset.
4. Auf Pfade in benutzerschreibbaren Verzeichnissen filtern (\Users\*\AppData\, \Users\Public\, \ProgramData\ außerhalb bekannter Vendor-Subdirs, C:\Windows\Temp\, C:\PerfLogs\). Die meiste Angreifer-Aktivität landet dort.
5. Die Überlebenden per Hash pivotieren. Alles, was nicht von einem bekannten Anbieter signiert ist oder VirusTotal nicht bekannt ist, kommt auf die Liste zur Korroboration anderswo.
6. Korroborieren. Die stärksten Aussagen koppeln eine Amcache-Zeile mit einem Prefetch-Treffer, einem Sysmon Process Create oder einem Security 4688. Alles, was allein auf der Hive basiert, bekommt den Vorbehalt "Beleg für Dateipräsenz; Ausführung nicht korroboriert".

Diesen letzten Punkt setze ich in jedem Bericht durch.

Die Hive ohne den Browser zu verlassen lesen#

Der Parser auf dieser Seite liest Amcache.hve vollständig in Ihrem Browser, einschließlich Transaktionslog-Replay. Hive einlegen und sie gibt eine flache Tabelle der InventoryApplicationFile-Einträge mit den obigen Feldern zurück, nach LastWrite sortiert. Filtern, per Hash pivotieren, exportieren. Kein Upload, was zählt, wenn die Hive aus einer regulierten Umgebung stammt.

Weiterführende Quellen#

• Yogesh Khatris Amcache.hve in Windows 8, das ursprüngliche öffentliche Reverse Engineering. Immer noch die beste Einzelreferenz zum Feldlayout.
• Eric Zimmermans AmcacheParser, Goldstandard-Offlinetool. Das Ausgabeschema ist de facto Industriestandard.
• MITRE ATT&CK T1070.009 Clear Persistence, für den Kontext, was gut ausgestattete Angreifer mit solchen Hives tun.

Wenn Sie eine Sache mitnehmen: Hash zuerst, Pfad zweitens, Zeit drittens. Die Amcache ist am besten, wenn Sie sie als Hash-Index behandeln, der zufällig die von Windows gesehenen Dateien kennt, und am schlechtesten, wenn Sie die Zeitstempel als Ground Truth behandeln.