SHA-1 dans l'Amcache : pivoter du disque au threat intel

La séquence d'octets la plus précieuse dans Amcache.hve est la valeur FileId sous InventoryApplicationFile. C'est un SHA-1 du contenu du fichier, préfixé par quatre zéros (0000) pour des raisons historiques qui n'ont plus d'importance. Retirez le préfixe et vous avez un hash que vous pouvez balancer à n'importe quel feed de threat intel de la planète.

C'est ce qui distingue l'Amcache de presque tout autre artefact Windows. Le shimcache vous donne un chemin et un horodatage. Le Prefetch vous donne un run count et un hash du chemin. La MFT vous donne des métadonnées sur le fichier à un instant donné. L'Amcache vous donne l'empreinte réelle du contenu du fichier, calculée par Windows lui-même, persistée dans une ruche de registre qui survit à la suppression du fichier.

C'est cette dernière clause qui clôt les dossiers.

Pourquoi les hashes survivent à la suppression et pas les chemins#

Quand Appraiser parcourt le système de fichiers selon son planning (Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser), il calcule le SHA-1 sur le contenu du fichier et écrit le résultat dans la ruche. Cette valeur reste là jusqu'à ce que quelqu'un supprime spécifiquement la sous-clé. Si l'opérateur dépose loader.exe, le lance et le retire, le fichier disparaît de la MFT après quelques écritures, disparaît du journal USN une fois qu'il roule, disparaît du Prefetch à la prochaine purge du cache. La ligne Amcache, avec son SHA-1, persiste indéfiniment. J'ai tiré des FileIds depuis des hôtes où le binaire original avait été supprimé six mois plus tôt.

Il y a des limites, et il faut les connaître avant d'écrire la phrase dans votre rapport :

  • Si la tâche Compatibility Appraiser était désactivée, le binaire n'a jamais été hashé. Pas de ligne, pas de FileId, pas de pivot.
  • Si l'attaquant a déposé, exécuté et supprimé le binaire à l'intérieur d'une seule fenêtre de scan Appraiser, le fichier n'a jamais été hashé. Même issue.
  • Si l'attaquant a supprimé explicitement la sous-clé sous InventoryApplicationFile, la ruche vivante n'a rien. Les journaux de transactions (Amcache.hve.LOG1 / Amcache.hve.LOG2) ont souvent encore quelque chose. Récupérez-les et rejouez.

Le hashage est SHA-1, cryptographiquement cassé pour les attaques par collision mais parfaitement adapté comme identifiant de contenu pour le DFIR. Personne ne construit de collisions chosen-prefix contre votre ruche de registre. Si quelqu'un vous dit que le SHA-1 dans l'Amcache n'est "pas digne de confiance", il confond deux modèles de menace différents.

Le pivot, de bout en bout#

Un vrai workflow sur un hôte que je soupçonne compromis :

  1. Acquérir la ruche et ses journaux. Rejouer. Parser.
  2. Sortir chaque tuple (FileId, OriginalFileName, LowerCaseLongPath, KeyLastWrite) depuis InventoryApplicationFile. C'est le set de travail, typiquement quelques milliers de lignes sur une station, des dizaines de milliers sur un serveur long-vivant.
  3. Retirer le préfixe 0000 de chaque FileId. Les 40 caractères hex restants sont un SHA-1 normal.
  4. Trier par chemin. Filtrer d'abord aux répertoires inscriptibles par l'utilisateur (\Users\*\AppData\, \ProgramData\ hors sous-dossiers vendeurs, C:\Windows\Temp\, C:\PerfLogs\, C:\$Recycle.Bin\). Tout ce qui est dans C:\Windows\System32\ venant d'un binaire Microsoft signé est rarement le point de départ d'une enquête, même si vous devriez quand même hash-checker les outliers ensuite.
  5. Soumettre les hashes survivants par lots à VirusTotal, votre sandbox interne, MalwareBazaar, l'API de réputation de votre éditeur EDR et le feed commercial auquel vous faites confiance. Les deux services publics gratuits que j'utilise le plus sont VirusTotal et MalwareBazaar d'abuse.ch ; les deux acceptent le SHA-1.
  6. Trier les réponses. Connu-malveillant va direct dans la liste d'IOC. Les chemins inconnus-mais-suspects sont avancés pour détonation en sandbox, si vous pouvez encore trouver le binaire sur un hôte pair ou dans une sauvegarde. Les binaires signés connus-bons sont notés et écartés.
  7. Tout ce qui a tapé en threat intel devient un sweep sur le reste du parc. Le FileId est l'IOC. Cherchez le même SHA-1 dans toute autre Amcache que vous pouvez obtenir.

L'étape 7 est celle que la plupart des gens sous-estiment. L'Amcache est par-hôte, mais les FileIds sont universels. Si e3b0c44... est apparu sur l'hôte patient zéro, il apparaîtra là où l'opérateur l'a déposé ensuite, et l'Amcache l'attrape souvent même quand le binaire n'est plus présent. Collecte Amcache en masse sur une entreprise (cible de collecte KAPE, hunt Velociraptor, capacité file-collection de votre EDR préféré) suivie d'une recherche par SHA-1 est un workflow qui passe à l'échelle.

Les faux positifs qui vont vous gâcher la journée#

L'outillage offensif commodity pollue les pivots basés sur hash. Deux patterns concrets à reconnaître :

Le premier, c'est l'infrastructure partagée entre red teams. PsExec est l'exemple canonique : les SHA-1 de psexec.exe et psexesvc.exe s'allument sur VirusTotal parce que chaque éditeur de détection les a étiquetés "hacktool", "outil d'admin à distance" ou similaire, mais ce sont aussi des binaires Sysinternals signés utilisés par la moitié des DSI du monde. Le hash est réellement malware-adjacent, mais le contexte hôte décide si ça compte. Même histoire pour procdump.exe, nircmd.exe, 7za.exe et la majorité du catalogue LOLBAS / GTFOBins.

Le second, c'est les loaders partagés. Les stagers beacon par défaut de Cobalt Strike, les implants Sliver sans recompilation et les runners shellcode Metasploit sont réutilisés sur des milliers d'engagements. Un hit sur un hash de beacon Cobalt Strike default-config veut dire "quelqu'un a déployé un C2 sur étagère", pas "vous faites face au même acteur que dans le rapport FireEye". Méfiance sur l'attribution depuis un hash seul.

Le workflow défensif, c'est de traiter chaque hit threat intel sur un outil commodity comme un drapeau jaune, pas rouge. Regardez le LowerCaseLongPath. Un PsExec signé sous C:\Program Files\Sysinternals\, c'est différent d'un PsExec renommé en chrome_helper.exe sous \AppData\Local\Temp\. Le hash est le même ; le contexte fait tout.

Les champs contrôlés par l'attaquant ne sont pas le hash#

LinkDate est le IMAGE_FILE_HEADER.TimeDateStamp de l'en-tête PE. C'est ce que le compilateur a estampé, donc ce que l'attaquant a dit au compilateur. Mis à 1970-01-01 dans la moitié des malwares commodity, mis à une valeur 2019 plausible dans les meilleurs échantillons, mis pour matcher un binaire Microsoft dans les polissés. Ne construisez pas de timelines dessus.

OriginalFileName et ProductName viennent de la ressource version du PE. Aussi contrôlables par l'attaquant. Moins souvent altérés que LinkDate, parce que toucher aux ressources version peut casser la signature de code et la logique d'installeur, mais j'ai vu OriginalFileName = svchost.exe sur des droppers Mimikatz en clair plus d'une fois.

FileId est calculé par l'OS après que le fichier ait atterri sur le disque. L'attaquant ne peut pas l'influencer sans réingénierer le binaire, à quel point le nouveau fichier est un fichier différent avec un hash différent, ce qui est exactement ce que vous voulez pour le tracking.

Size est vrai-côté-système-de-fichiers. Les mismatches entre Size et ce qu'une copie connue-bonne du binaire supposément-identique devrait être est un moyen bon marché de flaguer des fichiers système patchés ou trojanisés.

Hash-pivot à grande échelle, brièvement#

Si vous faites ça sur des milliers d'hôtes :

  • Collectez les ruches Amcache via Velociraptor (Windows.Forensics.Amcache), KAPE (cible Amcache) ou la file-collection de votre EDR. Les trois gèrent le verrou de fichier correctement. N'utilisez pas xcopy contre une ruche vivante.
  • Normalisez vers une seule colonne hash. Parfois les parseurs préservent le préfixe 0000, parfois ils le retirent. Choisissez une forme et imposez-la.
  • Soumettez en lot à l'endpoint /files/{hash} v3 de VirusTotal, en respectant les rate limits. Cachez les réponses. Un SHA-1 vu cette semaine n'a pas besoin d'être re-interrogé.
  • Maintenez une allowlist interne des hashes signés-Microsoft déjà triés. L'Amcache renvoie les mêmes binaires OS sur chaque hôte ; vous ne voulez pas regarder cmd.exe dix mille fois.
  • Croisez les hits avec Prefetch, Sysmon EventID 1 (ProcessCreate, inclut le hash du binaire) et la télémétrie EDR. L'Amcache dit que le fichier était là. Les autres artefacts disent ce qu'il a fait.

Le parseur de ce site est construit autour de ce workflow. Déposez la ruche, obtenez un tableau de SHA-1s et chemins, copy-paste dans le batch lookup de VirusTotal. Pas d'upload, ce qui compte quand la ruche vient d'un environnement régulé qui ne veut pas que les hashes sortent du périmètre.

Pour aller plus loin#

Tagsamcachedfirthreat-intelligencehash-pivotingmalware-analysis

Articles liés

← Retour à tous les articles