Einen realen Vorfall mit der Amcache untersuchen: Walkthrough

Der Host ist CORP-FS-04, ein Windows-Server-2019-Fileserver. Die Backup-Operationen starben am vergangenen Dienstag um 02:14 UTC. Der Bereitschafts-Admin fand zwei Dateifreigaben voll mit .[recovery-id]@onionmail.org.locked-Endungen und einer Ransom-Note in jedem Verzeichnis. EDR war vor zwei Wochen ausgerollt und noch nicht so konfiguriert, dass es auf Verschlüsselungsverhalten alarmierte. Die Live Response startete um 09:00 UTC, vier Stunden nach Detektion.

Das ist fiktiv, aber aus Bausteinen echter Fälle zusammengesetzt. Es geht nicht um das Ransom-Narrativ; es geht darum, was die Amcache beigetragen hat, wo sie ihre Miete verdient hat, und wo ich ehrlich sein musste, was sie nicht bewiesen hat.

Was gesammelt wurde#

KAPE-Triage, von einem Netzlaufwerk gestartet, kippte die Standard-Targets nach \\evidence\corp-fs-04\:

  • Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2
  • Der Prefetch-Ordner
  • Alle Windows-Ereignisprotokolle, einschließlich Microsoft-Windows-Sysmon%4Operational.evtx (Sysmon war vor drei Monaten ausgerollt worden, Glück gehabt)
  • $MFT, $LogFile, $UsnJrnl:$J aus dem USN-Journal
  • Die Hives Software, System, Security und Default User aus der Registry
  • VSS-Snapshots aus der Zeit vor dem Verschlüsselungsfenster

Die Amcache-Hive war das erste Artefakt, das ich öffnete, denn die Frage auf dem Tisch lautete "welches Tool hat die Dateien verschlüsselt", und die Amcache ist der billigste Ort, an dem man nach ausführbaren Dateien sucht, die nach der Verschlüsselung möglicherweise gelöscht wurden.

Erster Durchgang: parsen und filtern#

AmcacheParser:

AmcacheParser.exe -f Amcache.hve --csv .\parsed\ --mp -i

UnassociatedFileEntries.csv hatte 14.802 Zeilen. AssociatedFileEntries.csv weitere 6.991. Einundzwanzigtausend Zeilen sind zu viel zum Augenmaß-Lesen.

Filterregeln in der Reihenfolge, in der ich sie immer anwende:

  1. Alles unter c:\windows\winsxs\, c:\windows\servicing\, c:\program files\microsoft\ weglassen. Das ist OS-Rauschen.
  2. Einträge mit IsOsComponent = True weglassen. Mehr OS-Rauschen.
  3. Einträge behalten, deren LowerCaseLongPath in \users\, \programdata\, \windows\temp\, \perflogs\ liegt oder \appdata\ im Pfad enthält.
  4. Einträge behalten, bei denen Publisher leer oder Unknown ist. Signierte Software mit echtem Herausgeber ist selten der erste Lead.
  5. Absteigend nach KeyLastWrite sortieren.

Übrig: 47 Zeilen. Überschaubar.

Die drei Einträge, die hervorstachen#

Drei Zeilen im gefilterten Set waren anomal.

KeyLastWrite: 2025-05-20 01:47:33 UTC
LowerCaseLongPath: c:\programdata\health-mon\svchealth.exe
OriginalFileName: rundll32.exe
FileId: 00007a3f5b9c8e2d4a6f1b3c5e7d9f1a2b4c6e8d
Publisher: (leer)
LinkDate: 2015-08-14 03:22:11
BinaryType: pe64_file
Size: 487424
KeyLastWrite: 2025-05-20 01:47:34 UTC
LowerCaseLongPath: c:\programdata\health-mon\nx.exe
OriginalFileName: nx.exe
FileId: 0000d4e2c8a7f3b1e5d9c2a4f6e8b1d3c5a7f9e2
Publisher: (leer)
LinkDate: 2024-11-03 09:14:22
BinaryType: pe64_file
Size: 2.148.352
KeyLastWrite: 2025-05-20 01:51:12 UTC
LowerCaseLongPath: c:\windows\temp\enc.exe
OriginalFileName: enc.exe
FileId: 0000a1b2c3d4e5f6789012345678901234567890
Publisher: (leer)
LinkDate: 1970-01-01 00:00:00
BinaryType: pe64_file
Size: 3.891.200

Ein paar Dinge vorab.

OriginalFileName: rundll32.exe auf einer Datei unter c:\programdata\health-mon\svchealth.exe ist genau das Detail, für das die Amcache existiert. Der Angreifer hat die Datei wie ein Monitoring-Tool benannt, aber die PE-Version-Resource sagt immer noch rundll32.exe, was bedeutet, dass jemand eine eigene Binärdatei mit der Version-Resource einer Microsoft-Binärdatei als Startpunkt zusammengestellt hat. Allein das ist interessant.

LinkDate: 1970-01-01 auf dem dritten Eintrag ist ein Verräter. Wer auch immer enc.exe gebaut hat, hat sich entweder nicht gekümmert oder den Zeitstempel bewusst auf null gesetzt. Beides sind rote Fahnen.

Die drei KeyLastWrite-Werte liegen innerhalb von vier Minuten beieinander. Entweder lief der Compatibility Appraiser einmal in diesem Fenster und bemerkte alle drei Dateien in einem Scan, oder sie wurden zeitlich sehr nahe erzeugt und ein Appraiser-Lauf hat sie zusammen erfasst. So oder so: die drei gehören zusammen.

Der SHA-1-Pivot#

Ich strich das 0000-Präfix von jedem FileId und fragte VirusTotal:

  • 7a3f5b9c8e2d4a6f1b3c5e7d9f1a2b4c6e8d (svchealth.exe): 41 / 73 Erkennungen. Von mehreren Anbietern als RemoteUtilities getaggt. Das ist im engen Sinn keine Malware; es ist ein kommerzielles Remote-Administration-Tool, das Ransomware-Affiliates routinemäßig für Hands-on-Keyboard-Zugriff missbrauchen. Der Hash matchte einen bekannten Build.
  • d4e2c8a7f3b1e5d9c2a4f6e8b1d3c5a7f9e2 (nx.exe): 0 / 73. Unbekannt. Keine frühere Submission.
  • a1b2c3d4e5f6789012345678901234567890 (enc.exe): 64 / 73 Erkennungen. Mehrere Anbieter taggten als Ransom:Win64/Ryuk-Familien-Varianten. Der Hash matchte eine aktuelle Submission aus einer Sandbox in Osteuropa, drei Tage vor dem Vorfall.

Also: ein kommerzieller RAT, eine unbekannte Binärdatei, die detoniert werden sollte, eine bekannte Ransomware-Payload. Das sagt mir, was wahrscheinlich auf diesem Host war. Es sagt mir nichts darüber, dass etwas ausgeführt wurde.

Ausführung korroborieren#

Die Amcache sagt, diese Dateien existierten. Sie sagt nicht, dass sie liefen. Dafür muss ich woanders hin.

Erst Prefetch. Geparst mit PECmd.exe:

  • SVCHEALTH.EXE-A1B2C3D4.pf: vorhanden, letzter Lauf 2025-05-20 01:48:02 UTC, Run-Count 7. Definitiv ausgeführt. Mehrfach.
  • NX.EXE-E5F6789A.pf: vorhanden, letzter Lauf 2025-05-20 01:55:18 UTC, Run-Count 1. Einmal ausgeführt.
  • ENC.EXE-12345678.pf: nicht vorhanden.

Die dritte Datei fehlt im Prefetch. Zwei Gründe, warum das auf einem Server passieren kann: Prefetch ist auf Windows-Server-SKUs manchmal standardmäßig deaktiviert (auf diesem ist es, ich habe den Registry-Wert EnablePrefetcher geprüft, auf 0 gesetzt), oder die Datei lief weniger als die Prefetch-Schwelle (unwahrscheinlich für einen Ransomware-Encryptor auf einem Fileserver). Die Server-SKU erklärt es sauber.

Also korroboriert Prefetch die Ausführung für zwei von dreien. Für die dritte brauche ich Sysmon.

Sysmon (EventID 1 ProcessCreate) bestätigte:

  • c:\programdata\health-mon\svchealth.exe: mehrfach gespawnt, Parent services.exe (als Dienst installiert) und später cmd.exe. Erstmals gesehen 2025-05-20 01:46:51.
  • c:\programdata\health-mon\nx.exe: gespawnt 2025-05-20 01:55:14, Parent svchealth.exe, Kommandozeile enthielt -scan 10.0.0.0/24. Das ist der Lateral-Movement-/Recon-Schritt.
  • c:\windows\temp\enc.exe: gespawnt um 2025-05-20 02:13:47, Parent svchealth.exe, Kommandozeile enc.exe -p \\corp-fs-04\fileshare. Das ist der Encryptor-Aufruf. Matcht den 02:14-Vorfallszeitstempel des Backup-Fehlers.

Jetzt habe ich Ausführung für alle drei, plus die Parent-Child-Kette, plus die Kommandozeilen. Sysmon war das Artefakt, das das hier zugemacht hat.

Was die Amcache tatsächlich beigetragen hat#

Es lohnt sich, hier ehrlich zu sein, denn jedes Artefakt hat seine Rolle, und Übertreibung verwässert den Bericht.

Die Amcache trug bei:

  1. Die initiale Liste. Ohne den Amcache-Filterdurchgang hätte ich in 21.000 Einträgen ohne offensichtlichen Startpunkt geschwommen. Der Filter auf benutzerschreibbare Pfade reduzierte auf 47, die drei verdächtigen Einträge sprangen heraus.
  2. Die Hashes. Sysmon enthält in modernen Konfigurationen Prozess-Hashes, aber dieses Sysmon war älter und das Hash-Feld war für enc.exe leer. Die Amcache-FileId lieferte mir den SHA-1, den ich an VirusTotal schickte, was den Threat-Intel-Pivot freischaltete.
  3. Den Hash für enc.exe, nachdem sie gelöscht war. Der Encryptor wurde nach Abschluss der Verschlüsselung aus C:\Windows\Temp\ gelöscht (das USN-Journal zeigte das File Create um 02:13:47 und das Delete um 02:14:22). Um 09:00 UTC, als die Sammlung startete, war die Binärdatei weg. Die Amcache-Zeile mit ihrem SHA-1 war noch da. Das ist das Killer-Feature dieses Artefakts in Aktion.
  4. Der Version-Resource-Hinweis. OriginalFileName: rundll32.exe auf svchealth.exe ist genau das Detail, das in EDR-Telemetrie nicht erscheint und in Prefetch nicht erscheint. Die Amcache holte es ans Licht.

Die Amcache trug nicht bei:

  1. Beweise der Ausführung. Prefetch und Sysmon lieferten das.
  2. Die Kommandozeilen. Sysmon.
  3. Die Parent-Child-Kette. Sysmon.
  4. Die Lateral-Movement-Zielliste. Sysmon-Kommandozeile plus die 4624/4625-Events des Sicherheits-Logs von benachbarten Hosts.
  5. Den Einstiegspunkt. Zum Zeitpunkt des Berichts noch in Untersuchung; vermuteter RDP-Brute-Force basierend auf der Security-4625-Frequenz auf dem öffentlich erreichbaren Host, der nach CORP-FS-04 pivotierte.

Wenn ich nur die Amcache hätte, würde der Bericht lauten: "Drei verdächtige Binärdateien waren auf dem Host präsent". Das reicht nicht. Mit Prefetch, USN, MFT, Sysmon und dem Sicherheits-Log wird daraus: "Der Bedrohungsakteur hat einen kommerziellen RAT zur Persistenz ausgerollt, Netzwerkaufklärung durchgeführt und einen bekannten Ransomware-Encryptor der Ryuk-Familie gegen die Fileshare um 02:13:47 UTC ausgeführt". Die Amcache war tragend für die SHA-1-Zuordnung; alles andere trug das Ausführungs-Narrativ.

Der bericht-reife Satz#

Der einzige Satz, den ich aus dieser Arbeit gebaut habe und den Executives tatsächlich konsumieren:

"Am 20. Mai 2025 um 02:13:47 UTC hat der Bedrohungsakteur eine Ransomware-Binärdatei der Ryuk-Familie (SHA-1 a1b2c3d4..., trotz Post-Encryption-Löschung der Datei aus der Amcache geborgen) gegen den UNC-Pfad \\corp-fs-04\fileshare ausgeführt, vorangegangen von der Bereitstellung eines kommerziellen Remote-Access-Tools (RemoteUtilities, SHA-1 7a3f5b9c...), das als svchealth.exe unter C:\ProgramData\health-mon\ etwa 27 Minuten zuvor lief."

Dieser Satz ist verteidigbar. Jeder Hash, Pfad, jede Zeit und jeder Tool-Name darin stammt aus mindestens zwei Artefakten. Die Amcache liefert die Hashes, die das Löschen überleben; Sysmon liefert Ausführung und Kommandozeilen; Prefetch korroboriert zwei von drei Binärdateien; das USN-Journal liefert den Löschzeitstempel.

Dafür ist die Amcache da. Keine Smoking Gun. Ein verlässlicher, löschresistenter Hash-Index, der das Pivotieren ermöglicht, wenn der Rest der Beweise aktiv zerstört wurde.

Weiterführende Quellen#

Verwandte Beiträge

Zurück zu allen Beiträgen