Comment Filigran a créé le scénario Salt Typhoon dans OpenAEV

Salt Typhoon, également connu sous les noms Earth Estries ou Ghost Emperor, est un APT connu pour ses campagnes d'espionnage prolongées et son utilisation intensive de binaires living-off-the-land (LOLBins).
Chez Filigran, nous avons reproduit leurs TTP sous forme de scénario contrôlé dans notre plateforme de simulation, OpenAEV, afin d'évaluer la détection et d'améliorer la prévention et la résilience XDR face à des comportements furtifs.
Dans cet article, nous expliquons comment nous avons recherché, conçu, nettoyé et validé ce scénario spécifique, désormais disponible sous forme de contenu pré-construit sur le XTM Hub pour tous les utilisateurs Filigran.

TL;DR

• Salt Typhoon s'appuie sur des LOLBins, la persistence et des techniques d'exfiltration discrètes.
• Filigran a traduit des TTP publics en un scénario OpenAEV sûr et non destructif.
• Les payloads sont personnalisables et mappés sur MITRE ATT&CK pour la traçabilité.
• Les tests ont été effectués dans un laboratoire isolé avec des assertions pour valider la prévention et la détection XDR et SIEM.

Comprendre Salt Typhoon

Contexte de la menace

Salt Typhoon (alias Earth Estries / Ghost Emperor / UNC2286) est un APT observé menant des intrusions de longue durée contre des cibles gouvernementales et dans les télécommunications.

Leurs campagnes montrent une reconnaissance approfondie, le recours à des outils living-off-the-land, et des phases de persistence et de collecte de données soigneusement orchestrées.

Sources et collecte de renseignements

La conception de notre scénario a débuté avec des rapports publics tels que l'analyse technique de Trend Micro et le résumé de menace de Varonis.

À partir de ces rapports, nous avons extrait des comportements récurrents : exécution à distance via wmic, utilisation d'utilitaires d'archivage pour le packaging, scripts déposés sous C:\\ProgramData, et accès ciblé aux journaux internes.

Nous avons traité ces comportements comme le signal à émuler, et non les artefacts malveillants eux-mêmes.

(Voir : Trend Micro, Varonis.)

Traduire les TTP en payloads OpenAEV

Objectif d'émulation

Nous avons cherché à reproduire les modèles de comportement de l'adversaire : exécution latérale via des outils système légitimes, placement d'artefacts dans des emplacements accessibles en écriture courants, et collecte par étapes, tout en évitant toute action destructive.

Exemple 1 : Chaîne d'exécution basée sur WMIC

Les rapports montrent que Salt Typhoon utilise wmic process call create "cmd.exe /c <script>" pour exécuter des scripts sur un hôte.

Nous avons recréé le comportement mais remplacé les actions nuisibles par des marqueurs observables et bénins :

Ce template écrit des fichiers marqueurs et des journaux au lieu d'exécuter des payloads inconnus. Il déclenche les mêmes empreintes de télémétrie (génération de processus via cmd, accès à ProgramData, lectures de fichiers) que les XDR devraient faire remonter.

Principes de conception des payloads

• Non destructif : ne jamais effectuer d'exfiltration réelle ni de modifications destructives.
• Paramétrique : utiliser des variables (#{file}, #{artifact_dir}) pour adapter les payloads à différentes images cibles.
• Bénin : les payloads doivent pouvoir être réexécutés en toute sécurité sans effets secondaires.
• Prérequis : vous pouvez avoir des prérequis de vérification et d'obtention pour faciliter la configuration et l'automatisation des payloads.
• Nettoyage : Chaque payload peut être nettoyé après son exécution pour éviter de laisser des artefacts sur les endpoints.
• Contrôle du bruit : simuler des timings réalistes et répartir les étapes sur des fenêtres temporelles.
• Nettoyage : remplacer les IP, domaines et clés par des placeholders pour les artefacts publics.

Mapping MITRE ATT&CK

Nous avons mappé chaque payload sur MITRE ATT&CK pour la traçabilité :

• T1059.001 — Command and Scripting Interpreter (cmd.exe, wmic)
• T1105 — Ingress Tool Transfer (comportements d'archivage et de transfert, simulés)
• T1078 — Valid Accounts (mimé via l'utilisation d'outils autorisés et des modèles de persistence)

Exemple 2 : Simuler le masquage et l'exécution du beacon

Dans le rapport Trend Micro, nous avons vu certains chemins et l'utilisation de fichiers cab pour dissimuler Cobalt Strike Beacon à l'intérieur :

source : https://www.trendmicro.com/en_us/research/24/k/breaking-down-earth-estries-persistent-ttps-in-prolonged-cyber-o.html

Le schéma suivant illustre la première chaîne d'attaque de Salt Typhoon basée sur les recherches de Trend Micro :

Source : https://www.trendmicro.com/en_us/research/24/k/breaking-down-earth-estries-persistent-ttps-in-prolonged-cyber-o.html

Avec ces informations, nous avons reproduit la même logique mais au lieu de dissimuler un beacon Cobalt Strike, nous avons caché notre agent OpenAEV et utilisé le même chemin :

Autres exemples

Nous avons développé d'autres payloads dans OpenAEV avec la même séquence logique :

Ici, le HOSTNAME est une variable qui peut être définie selon nos besoins. Par défaut, elle pointe vers le loopback (127.0.0.1), ce qui devrait être détecté par les EDR & SIEM.

Enchaîner tous les payloads ensemble

Nous avons créé tous les payloads étape par étape, puis les avons enchaînés.

Suivant la méthodologie Salt Typhoon, nous avons créé le diagramme suivant pour illustrer clairement notre approche, décrivant le scénario que nous mettons actuellement en œuvre dans OpenAEV.

Qu'en est-il des CVE ?

Salt Typhoon, comme de nombreux autres acteurs de menace, exploite des vulnérabilités pour obtenir l'accès initial aux victimes avant de passer aux autres étapes de son parcours d'attaque. L'acteur de menace est bien connu pour utiliser des vulnérabilités Cisco spécifiques combinées pour monter un tunnel GRE (comme un VPN IPSEC) puis accéder aux ressources internes. D'autres vulnérabilités connues utilisées incluent Proxy Shell ciblant les serveurs Microsoft Exchange.

Sur la base de cette recherche, nous avons ajouté des vérifications CVE sur OpenAEV basées sur des templates Nuclei les supportant :

Ces templates peuvent être utilisés pour vérifier les vulnérabilités sur des endpoints distants – qu'ils soient internes ou externes via notre Nuclei Injector sans agent. En cas de vulnérabilités, voici ce que nous avons observé :

Nous pouvons voir quels actifs sont vulnérables, consulter les détails d'exécution et accéder à plus d'informations sur la CVE et sa remédiation.

Tests, validation et leçons apprises

Vérification de sécurité

Tous les scénarios ont été exécutés dans un laboratoire isolé avec snapshots et segmentation VLAN.

Chaque test a utilisé des états de VM propres et a été instrumenté pour la collecte forensique.

Assertions et vérification de la télémétrie

Les scénarios OpenAEV incluent des assertions qui vérifient les artefacts attendus : actifs avec vulnérabilités (CVE), présence de fichiers marqueurs, journaux générés et événements de télémétrie EDR.

Nous avons validé les signaux EDR (création de processus, arguments de ligne de commande, I/O de fichiers, opérations d'archivage) et confirmé le mapping aux règles de détection.

Itération et ajustement

Si votre EDR ne le détecte pas, il peut être mal configuré ou pas à jour avec ces nouvelles techniques d'attaque.

Les dernières fonctionnalités IA d'OpenAEV peuvent améliorer votre posture en vous fournissant des règles de détection adaptées à votre EDR spécifique.

Pour ce faire, sélectionnez simplement pour quelle plateforme de sécurité la règle est destinée puis cliquez sur "Use Ariane" :

Sécurité et conformité

Nous avons nettoyé tous les exemples publics. Les artefacts de rapports réels (IP sensibles, échantillons de malwares exacts) n'ont pas été inclus dans les templates publics.

Conclusion

Recréer les comportements de Salt Typhoon dans OpenAEV a permis à Filigran de tester la couverture de détection pour l'exécution living-off-the-land, les placements de persistence et la collecte de données par étapes.
Points clés à retenir : émuler les comportements et non les malwares, garder les payloads sûrs et paramétriques, mapper les étapes sur MITRE ATT&CK, et valider dans un laboratoire isolé avec des assertions claires.
Ces pratiques produisent des scénarios reproductibles qui améliorent la détection EDR et la préparation des analystes.

Scénarios pré-configurés sur le XTM Hub

Si vous êtes intéressé par la simulation de cet APT pour des tests internes, vous pouvez télécharger un package de scénario gratuit, pré-configuré et nettoyé depuis le XTM Hub.
https://hub.filigran.io/app.
Profitez-en et n'hésitez pas à poser des questions à ce sujet sur notre channel communautaire Slack !