Enquêter sur un vrai incident avec l'Amcache : walkthrough

L'hôte est CORP-FS-04, un serveur de fichiers Windows Server 2019. Les opérations de sauvegarde sont mortes à 02:14 UTC mardi dernier. L'admin d'astreinte a trouvé deux partages bourrés d'extensions .[recovery-id]@onionmail.org.locked et une note de rançon dans chaque répertoire. L'EDR avait été déployé deux semaines avant et n'avait pas encore été configuré pour alerter sur le comportement de chiffrement. La live response a démarré à 09:00 UTC, quatre heures après la détection.

C'est fictif, mais construit à partir de morceaux de vrais dossiers. Le sujet, ce n'est pas la narration de la rançon ; le sujet, c'est ce que l'Amcache a apporté, où elle a mérité sa place, et où j'ai dû être honnête sur ce qu'elle ne prouvait pas.

Ce qui a été collecté#

Triage KAPE, lancé depuis un partage réseau, a déversé les cibles standard dans \\evidence\corp-fs-04\ :

  • Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2
  • Le dossier Prefetch
  • Tous les journaux d'événements Windows, dont Microsoft-Windows-Sysmon%4Operational.evtx (Sysmon était déployé depuis trois mois, on a eu de la chance)
  • $MFT, $LogFile, $UsnJrnl:$J depuis le journal USN
  • Les ruches Software, System, Security et Default user depuis le registre
  • Les snapshots VSS d'avant la fenêtre de chiffrement

La ruche Amcache a été le premier artefact que j'ai ouvert, parce que la question sur la table était "quel outil a chiffré les fichiers", et l'Amcache est l'endroit le moins cher pour chercher les exécutables qui ont pu être supprimés après le chiffrement.

Première passe : parser et filtrer#

AmcacheParser :

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

UnassociatedFileEntries.csv avait 14 802 lignes. AssociatedFileEntries.csv 6 991 de plus. Vingt-et-un mille lignes, c'est trop pour la lecture à l'oeil.

Règles de filtrage dans l'ordre où je les applique toujours :

  1. Virer tout sous c:\windows\winsxs\, c:\windows\servicing\, c:\program files\microsoft\. C'est du bruit OS.
  2. Virer les entrées avec IsOsComponent = True. Encore du bruit OS.
  3. Garder les entrées dont LowerCaseLongPath est dans \users\, \programdata\, \windows\temp\, \perflogs\, ou n'importe où avec \appdata\ dans le chemin.
  4. Garder les entrées dont Publisher est vide ou Unknown. Les logiciels signés avec un vrai éditeur sont rarement la première piste.
  5. Trier par KeyLastWrite décroissant.

Il restait 47 lignes. Gérable.

Les trois entrées qui ressortaient#

Trois lignes du set filtré étaient anormales.

KeyLastWrite: 2025-05-20 01:47:33 UTC
LowerCaseLongPath: c:\programdata\health-mon\svchealth.exe
OriginalFileName: rundll32.exe
FileId: 00007a3f5b9c8e2d4a6f1b3c5e7d9f1a2b4c6e8d
Publisher: (vide)
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: (vide)
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: (vide)
LinkDate: 1970-01-01 00:00:00
BinaryType: pe64_file
Size: 3 891 200

Quelques choses avant d'aller plus loin.

OriginalFileName: rundll32.exe sur un fichier à c:\programdata\health-mon\svchealth.exe, c'est exactement le genre de détail pour lequel l'Amcache existe. L'attaquant a nommé le fichier comme un outil de monitoring, mais la ressource de version PE dit toujours rundll32.exe, ce qui veut dire que quelqu'un a packagé un binaire custom en utilisant la ressource de version d'un binaire Microsoft comme point de départ. Ça seul est intéressant.

LinkDate: 1970-01-01 sur la troisième entrée, c'est un signal. Qui a construit enc.exe soit s'en fichait, soit a délibérément mis l'horodatage à zéro. Les deux sont des drapeaux.

Les trois KeyLastWrite sont à moins de quatre minutes les uns des autres. Soit le Compatibility Appraiser a tourné une fois dans cette fenêtre et a remarqué les trois fichiers dans un seul scan, soit ils ont été créés très rapprochés et une passe de l'Appraiser les a ramassés ensemble. Dans tous les cas : les trois sont liés.

Le pivot SHA-1#

J'ai retiré le préfixe 0000 de chaque FileId et interrogé VirusTotal :

  • 7a3f5b9c8e2d4a6f1b3c5e7d9f1a2b4c6e8d (svchealth.exe) : 41 / 73 détections. Étiqueté RemoteUtilities par plusieurs vendeurs. Ce n'est pas du malware au sens strict ; c'est un outil commercial d'administration à distance que les affiliés ransomware détournent couramment pour de l'accès hands-on-keyboard. Le hash matchait un build connu.
  • d4e2c8a7f3b1e5d9c2a4f6e8b1d3c5a7f9e2 (nx.exe) : 0 / 73. Inconnu. Aucune soumission antérieure.
  • a1b2c3d4e5f6789012345678901234567890 (enc.exe) : 64 / 73 détections. Plusieurs vendeurs l'étiquettent comme variantes de la famille Ransom:Win64/Ryuk. Le hash matchait une soumission récente depuis une sandbox d'Europe de l'Est, trois jours avant l'incident.

Donc : un RAT commercial, un binaire inconnu à faire détoner, une payload ransomware connue. Ça me dit ce qui était probablement sur cet hôte. Ça ne me dit pas que quoi que ce soit ait été exécuté.

Corroborer l'exécution#

L'Amcache dit que ces fichiers existaient. Elle ne dit pas qu'ils ont tourné. Pour ça, il faut aller ailleurs.

Prefetch d'abord. Parsé avec PECmd.exe :

  • SVCHEALTH.EXE-A1B2C3D4.pf : présent, dernière exécution 2025-05-20 01:48:02 UTC, run count 7. Exécuté à coup sûr. Plusieurs fois.
  • NX.EXE-E5F6789A.pf : présent, dernière exécution 2025-05-20 01:55:18 UTC, run count 1. Exécuté une fois.
  • ENC.EXE-12345678.pf : absent.

Le troisième fichier manque dans Prefetch. Deux raisons possibles sur un serveur : Prefetch est parfois désactivé par défaut sur les SKU Windows Server (sur celui-ci, c'est le cas, j'ai vérifié la valeur registre EnablePrefetcher à 0), ou le fichier a tourné moins que le seuil Prefetch (peu vraisemblable pour un encryptor de ransomware sur un serveur de fichiers). La SKU serveur explique ça proprement.

Donc Prefetch corrobore l'exécution pour deux des trois. Pour le troisième, il me faut Sysmon.

Sysmon (EventID 1 ProcessCreate) a confirmé :

  • c:\programdata\health-mon\svchealth.exe : spawné plusieurs fois, parent services.exe (installé en service) puis cmd.exe. Première vue 2025-05-20 01:46:51.
  • c:\programdata\health-mon\nx.exe : spawné 2025-05-20 01:55:14, parent svchealth.exe, ligne de commande contenant -scan 10.0.0.0/24. C'est l'étape mouvement latéral / reconnaissance.
  • c:\windows\temp\enc.exe : spawné à 2025-05-20 02:13:47, parent svchealth.exe, ligne de commande enc.exe -p \\corp-fs-04\fileshare. C'est l'invocation de l'encryptor. Coïncide avec l'horodatage 02:14 de l'incident sur l'échec de sauvegarde.

J'ai maintenant l'exécution pour les trois, plus la chaîne parent-enfant, plus les lignes de commande. Sysmon est l'artefact qui a clos ce dossier.

Ce que l'Amcache a réellement apporté#

Ça vaut la peine d'être honnête, parce que chaque artefact a un rôle et exagérer dilue le rapport.

L'Amcache a apporté :

  1. La liste initiale. Sans la passe de filtrage Amcache, j'aurais nagé dans 21 000 entrées sans point de départ évident. Le filtre chemins inscriptibles par l'utilisateur a réduit à 47, les trois entrées suspectes ont sauté aux yeux.
  2. Les hashes. Sysmon inclut les hashes de processus dans les configurations modernes, mais ce Sysmon était plus ancien et le champ hash était vide pour enc.exe. Le FileId Amcache m'a donné le SHA-1 envoyé à VirusTotal, ce qui a débloqué le pivot threat intel.
  3. Le hash pour enc.exe après sa suppression. L'encryptor a été supprimé de C:\Windows\Temp\ après la fin du chiffrement (le journal USN a montré le file create à 02:13:47 et la suppression à 02:14:22). À 09:00 UTC quand la collecte a démarré, le binaire avait disparu. La ligne Amcache, avec son SHA-1, était toujours là. C'est la killer feature de l'artefact en action.
  4. L'indice de la ressource version. OriginalFileName: rundll32.exe sur svchealth.exe, c'est le genre de détail qui n'apparaît pas dans la télémétrie EDR et pas dans Prefetch. L'Amcache l'a fait remonter.

L'Amcache n'a pas apporté :

  1. La preuve d'exécution. Prefetch et Sysmon l'ont donnée.
  2. Les lignes de commande. Sysmon.
  3. La chaîne parent-enfant. Sysmon.
  4. La liste des cibles de mouvement latéral. Ligne de commande Sysmon plus les événements 4624/4625 du log Sécurité des hôtes voisins.
  5. Le point d'entrée. Toujours en investigation au moment du rapport ; brute force RDP soupçonné sur la base de la fréquence Security 4625 sur l'hôte exposé qui a pivoté vers CORP-FS-04.

Si je n'avais que l'Amcache, le rapport dirait "trois binaires suspects étaient présents sur l'hôte". Ce n'est pas assez. Avec Prefetch, USN, MFT, Sysmon et le log Sécurité, ça devient "l'acteur a déployé un RAT commercial pour la persistance, lancé une reconnaissance réseau, et exécuté un encryptor connu de la famille Ryuk contre le partage de fichiers à 02:13:47 UTC". L'Amcache a porté l'attribution SHA-1 ; tout le reste portait la narration d'exécution.

La phrase prête pour le rapport#

L'unique phrase que j'ai bâtie à partir de ce travail, celle que les lecteurs exécutifs consomment vraiment :

"À 02:13:47 UTC le 20 mai 2025, l'acteur a exécuté un binaire de ransomware de la famille Ryuk (SHA-1 a1b2c3d4..., récupéré depuis l'Amcache malgré la suppression du fichier post-chiffrement) contre le chemin UNC \\corp-fs-04\fileshare, précédé du déploiement d'un outil commercial d'accès à distance (RemoteUtilities, SHA-1 7a3f5b9c...) tournant en tant que svchealth.exe sous C:\ProgramData\health-mon\ pendant ~27 minutes auparavant."

Cette phrase est défendable. Chaque hash, chemin, heure et nom d'outil y est sourcé depuis au moins deux artefacts. L'Amcache fournit les hashes qui survivent à la suppression ; Sysmon fournit l'exécution et les lignes de commande ; Prefetch corrobore deux des trois binaires ; le journal USN fournit l'horodatage de suppression.

C'est à ça que sert l'Amcache. Pas un smoking gun. Un index de hashes fiable, résistant à la suppression, qui permet de pivoter quand le reste des preuves a été activement détruit.

Pour aller plus loin#

Tagsamcachedfirincident-responseransomwarecase-study

Articles liés

← Retour à tous les articles