The Stolen Szechuan Sauce

Case 001 : The Stolen Szechuan Sauce#

Analyste : Jérémy Diaz

1. Présentation du cas#

Une recette confidentielle de sauce Szechuan a été retrouvée sur le dark web. L'objectif de cette investigation est de déterminer comment l'attaquant est entré dans le réseau, quelles machines ont été compromises, quels outils ont été employés et quelles données ont été consultées ou volées.

Les éléments fournis sont particulièrement complets :

• les images disque E01 d'un contrôleur de domaine et d'un poste Windows 10 ;
• les acquisitions mémoire des deux machines ;
• une capture réseau PCAP ;
• deux exports Autoruns ;
• les clés de registre et la base Active Directory ntds.dit.

L'analyse suit une logique simple. La capture réseau permet de reconstituer le chemin emprunté par l'attaquant. Les images disque et les exports Autoruns servent ensuite à confirmer les fichiers déposés, les mécanismes de persistance et les manipulations effectuées sur les documents sensibles.

2. Résumé de l'incident#

L'investigation confirme une compromission complète du domaine. Le 19 septembre 2020, l'adresse 194.61.24.102 a lancé une attaque par force brute contre le service RDP du contrôleur de domaine 10.42.85.10. L'attaquant a réussi à ouvrir une session avec le compte CITADEL\Administrator.

Depuis cette session, il a téléchargé coreupdater.exe, un implant Meterpreter, puis l'a installé dans C:\Windows\System32. Le malware communiquait avec le serveur de commande et contrôle 203.78.103.109 sur le port TCP 443. L'attaquant a ensuite utilisé le contrôleur de domaine comme point de rebond pour ouvrir une session RDP vers le poste 10.42.85.115.

Des documents sensibles ont été regroupés dans des archives puis exfiltrés. La recette Szechuan, les secrets de Beth et des fichiers appartenant à Morty ont été consultés. Le fichier consacré à Beth a également été remplacé et antidaté.

3. Précautions concernant les horaires#

La capture PCAP utilise l'heure UTC. Les machines virtuelles du laboratoire étaient configurées avec un décalage incorrect de UTC moins 7, alors que l'organisation se trouvait au Colorado en septembre, donc en MDT, soit UTC moins 6.

Pour éviter les confusions, les événements principaux sont présentés en UTC. L'heure locale réelle peut être obtenue en retirant six heures. Par exemple, 02:24 UTC correspond à 20:24 MDT le 18 septembre.

4. Identification des systèmes#

4.1 Quel est le système d'exploitation du serveur ?#

Le registe SOFTWARE extraite du serveur contient les informations de version de Windows. Une recherche de chaînes permet d'identifier la famille Windows Server, tandis que les versions des composants système correspondent à la branche NT 6.3, build 9600.

strings -el Files/Protected/software | grep -i -m 5 'Windows Server'

Réponse : le serveur utilise Windows Server 2012 R2 x64.

4.2 Quel est le système d'exploitation du Desktop ?#

La même recherche est réalisée dans la clé de registre SOFTWARE du poste de travail. Le nom du produit apparaît directement dans les chaînes Unicode.

strings -el 'Files/Protected Files/software' | grep -i -m 5 'Windows 10 Enterprise'

Réponse : le poste utilise Windows 10 Enterprise Evaluation x64, build 19041.

4.3 Quelle était l'heure locale du serveur ?#

L'entretien client situe l'organisation au Colorado. Au mois de septembre, ce territoire utilise l'heure avancée des Rocheuses, appelée Mountain Daylight Time.

Réponse : l'heure locale réelle était MDT, soit UTC moins 6.

5. Analyse de l'accès initial#

5.1 Y a-t-il réellement eu une compromission ?#

La réponse ne repose pas sur une seule alerte. Plusieurs événements se suivent de manière cohérente : nombreuses tentatives RDP, téléchargement d'un exécutable depuis une adresse externe, communication avec un C2, installation d'une persistance et accès à des fichiers sensibles.

tshark -r Files/case001.pcap -q -z endpoints,ip 2>/dev/null | head -15

Réponse : oui, le contrôleur de domaine et le poste de travail ont été compromis.

5.2 Quel était le vecteur d'entrée initial ?#

Je filtre les paquets SYN à destination du port RDP 3389. Plusieurs connexions successives proviennent de la même adresse externe et utilisent à chaque fois un nouveau port source. Ce comportement est caractéristique d'une attaque automatisée.

tshark -r Files/case001.pcap -Y 'tcp.flags.syn==1 && tcp.dstport==3389 && ip.src==194.61.24.102' -T fields -e frame.time_epoch -e ip.src -e ip.dst -e tcp.srcport | head

L'attaque aboutit à l'ouverture d'une session avec le compte CITADEL\Administrator autour de 02:21 UTC.

Réponse : l'accès initial provient d'une attaque par force brute contre le service RDP exposé sur Internet.

6. Identification du malware#

6.1 Un malware a-t-il été utilisé ?#

La capture réseau contient deux requêtes HTTP vers un fichier nommé coreupdater.exe. Les deux machines téléchargent le même fichier directement depuis une adresse IP, sans utiliser de nom de domaine.

tshark -r Files/case001.pcap -Y 'http.request.uri contains "coreupdater"' -T fields -e frame.time_epoch -e ip.src -e ip.dst -e http.host -e http.request.uri

Le binaire et les traces mémoire correspondent à une charge Meterpreter générée avec Metasploit.

Réponse : oui, le malware est un implant Meterpreter nommé coreupdater.exe.

6.2 Quel processus était malveillant ?#

Le processus d'origine est coreupdater.exe. Meterpreter a ensuite migré dans spoolsv.exe afin de se dissimuler dans un processus Windows légitime.

Réponse : coreupdater.exe était le processus initial, puis le code malveillant a migré dans spoolsv.exe.

6.3 Quelle adresse IP a livré le payload ?#

La colonne http.host de la capture précédente montre que le fichier est téléchargé directement depuis 194.61.24.102.

Réponse : le payload a été livré par 194.61.24.102 via HTTP.

6.4 Vers quelle adresse IP le malware communiquait-il ?#

Après le téléchargement, des communications apparaissent avec une seconde adresse externe sur le port TCP 443.

tshark -r Files/case001.pcap -Y 'ip.addr==203.78.103.109' -T fields -e frame.time_epoch -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport | head

Réponse : le malware communiquait avec 203.78.103.109:443.

6.5 Où se trouvait le malware sur le disque ?#

L'image E01 du serveur contient le binaire dans le répertoire système de Windows. L'option -o 718848 correspond au début de la partition Windows identifié avec mmls.

fls -r -p -o 718848 Files/E01-DC01/20200918_0347_CDrive.E01 2>/dev/null | grep -i 'coreupdater.exe'

Réponse : C:\Windows\System32\coreupdater.exe.

6.6 Quand le malware est-il apparu pour la première fois ?#

La première requête HTTP vers le fichier a lieu à l'epoch 1600482246.939239. La conversion en UTC donne 02:24:06 UTC. La MFT indique ensuite une création du fichier sur le disque à environ 02:24:12 UTC.

date -u -d @1600482246.939239 '+%Y-%m-%d %H:%M:%S UTC'

istat -o 718848 Files/E01-DC01/20200918_0347_CDrive.E01 87137-128-4 | head -30

Réponse : le téléchargement commence le 19 septembre 2020 à 02:24:06 UTC et le fichier apparaît sur le disque quelques secondes plus tard.

6.7 Le fichier a-t-il été déplacé ?#

Les traces du navigateur et les fichiers récents indiquent un téléchargement initial dans le dossier Downloads de l'administrateur. La copie utilisée pour l'exécution se trouve ensuite dans System32.

Réponse : oui, le fichier a été déplacé du dossier Downloads de l'administrateur vers C:\Windows\System32.

6.8 Quelles étaient les capacités du malware ?#

Meterpreter permet à un attaquant de contrôler la machine à distance, exécuter des commandes, transférer des fichiers, enregistrer les frappes, capturer l'écran, récupérer des identifiants et injecter du code dans d'autres processus. Dans ce cas, la migration vers spoolsv.exe, la manipulation de fichiers et l'exfiltration sont observées.

Réponse : contrôle distant, exécution de commandes, transfert et vol de fichiers, collecte d'identifiants, keylogging, capture d'écran et injection de processus.

6.9 Le malware est-il facilement disponible ?#

Meterpreter fait partie du framework Metasploit, librement accessible. Le binaire précis a été généré pour cette attaque, mais l'outil nécessaire à sa création est public.

Réponse : oui, Meterpreter est disponible avec Metasploit Framework.

6.10 Vérification du fichier extrait#

Le fichier peut être extrait directement depuis l'image disque, puis identifié et haché sans l'exécuter.

icat -o 718848 Files/E01-DC01/20200918_0347_CDrive.E01 87137-128-4 > /tmp/coreupdater.exe

file /tmp/coreupdater.exe && sha256sum /tmp/coreupdater.exe

Résultat : SHA-256 10f3b92002bb98467334161cf85d0b1730851f9256f83c27db125e9a0c1cfda6.

7. Mécanismes de persistance#

7.1 Une persistance a-t-elle été installée ?#

Les exports Autoruns contiennent deux entrées suspectes sur chaque machine. La première est un service Windows nommé coreupdater. La seconde est une valeur Run appelée coreupdate, qui lance PowerShell de manière cachée.

grep -i 'coreupdate' Files/autorunsc-citadel-dc01.csv | cut -c1-220

grep -i 'coreupdate' Files/autoruns-desktop-sdn1rpt.csv | cut -c1-220

Réponse : oui, une persistance a été installée sur les deux machines.

7.2 Quand la persistance a-t-elle été installée ?#

L'événement Service Control Manager 7045 situe l'installation du service sur le DC à 02:27:49 UTC. Sur le Desktop, l'installation corrigée du décalage horaire se situe vers 02:42:42 UTC.

Réponse : DC à 02:27:49 UTC et Desktop vers 02:42:42 UTC.

7.3 Où la persistance est-elle enregistrée ?#

Réponse : dans HKLM\SYSTEM\CurrentControlSet\Services\coreupdater et dans HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\coreupdate.

8. Infrastructure de l'attaquant#

8.1 Quelles adresses IP malveillantes sont impliquées ?#

Deux adresses jouent un rôle direct et distinct :

Réponse : 194.61.24.102 et 203.78.103.109.

8.2 S'agissait-il d'une infrastructure hostile connue ?#

194.61.24.102 était déjà associée à des campagnes de force brute RDP autour de la période de l'incident. 203.78.103.109 a été reliée temporairement à un domaine suspect, mais cette attribution publique a ensuite été contestée. Son rôle de C2 dans ce cas reste toutefois démontré par la capture réseau.

Réponse : oui pour l'infrastructure RDP. L'attribution historique du C2 à un groupe précis reste incertaine.

8.3 Cette infrastructure était-elle utilisée dans d'autres attaques ?#

Les renseignements historiques montrent que l'adresse ayant lancé la force brute était impliquée dans d'autres attaques RDP durant la même période.

Réponse : oui, notamment dans d'autres campagnes de force brute RDP.

9. Mouvement latéral#

9.1 L'attaquant a-t-il accédé à une autre machine ?#

Le PCAP montre une nouvelle connexion RDP, cette fois entre les deux machines internes.

tshark -r Files/case001.pcap -Y 'tcp.flags.syn==1 && tcp.dstport==3389 && ip.src==10.42.85.10 && ip.dst==10.42.85.115' -T fields -e frame.time_epoch -e ip.src -e ip.dst -e tcp.dstport

Réponse : oui, l'attaquant a accédé à DESKTOP-SDN1RPT, adresse 10.42.85.115.

9.2 Comment a-t-il procédé ?#

Depuis la session ouverte sur le contrôleur de domaine, l'attaquant a lancé une seconde session RDP vers le Desktop en réutilisant les identifiants du compte Administrator.

Réponse : mouvement latéral par RDP depuis le contrôleur de domaine avec réutilisation des identifiants.

9.3 Quand le mouvement latéral a-t-il eu lieu ?#

Le premier paquet de cette connexion apparaît à l'epoch 1600482955.285340.

date -u -d @1600482955.285340 '+%Y-%m-%d %H:%M:%S UTC'

Réponse : le 19 septembre 2020 à 02:35:55 UTC.

10. Accès et exfiltration des données#

10.1 Des données ont-elles été consultées ou volées ?#

Les traces de fichiers récents, les métadonnées NTFS et la chronologie montrent la création de deux archives. secret.zip regroupe des données du serveur, tandis que loot.zip regroupe les données récupérées sur le Desktop.

Réponse : oui, des données ont été consultées, archivées puis exfiltrées depuis les deux machines.

10.2 Quand les données ont-elles été exfiltrées ?#

secret.zip est préparé vers 02:30 UTC, exfiltré puis supprimé vers 02:31 UTC. loot.zip est créé sur le Desktop vers 02:46 UTC, puis exfiltré et supprimé vers 02:48 UTC.

Réponse : environ 02:31 UTC pour le serveur et 02:48 UTC pour le Desktop.

10.3 La sauce Szechuan a-t-elle été volée ?#

Le fichier peut être localisé et extrait depuis l'image du serveur.

fls -r -p -o 718848 Files/E01-DC01/20200918_0347_CDrive.E01 2>/dev/null | grep -i 'Szechuan Sauce.txt'

icat -o 718848 Files/E01-DC01/20200918_0347_CDrive.E01 87059-128-1

La chronologie place son inclusion dans l'archive exfiltrée vers 02:31 UTC. Les métadonnées du fichier montrent également un accès ou une modification ultérieure à 02:38:56 UTC.

Réponse : oui. L'exfiltration est estimée vers 02:31 UTC et un accès direct est prouvé à 02:38:56 UTC.

10.4 D'autres fichiers sensibles ont-ils été touchés ?#

Une recherche dans l'image révèle plusieurs traces liées à Beth, Morty et à la recette.

fls -r -p -o 718848 Files/E01-DC01/20200918_0347_CDrive.E01 2>/dev/null | grep -Ei 'Szechuan|Beth|Morty'

Le fichier SECRET_beth.txt est supprimé vers 02:34 UTC. Un nouveau fichier Beth_Secret.txt est ensuite créé avec un contenu différent. Les données de Morty sont également récupérées pendant la préparation de l'archive.

Réponse : oui. Les secrets de Beth sont manipulés entre 02:34 et 02:38 UTC, et les fichiers de Morty sont récupérés autour de 02:30 à 02:34 UTC.

10.5 Quel fichier a été antidaté ?#

Les deux familles de dates NTFS du nouveau fichier ne correspondent pas. Les dates de $STANDARD_INFORMATION ont été remplacées, tandis que $FILE_NAME conserve une date de création cohérente avec l'incident.

istat -o 718848 Files/E01-DC01/20200918_0347_CDrive.E01 87111-128-1 | head -40

Réponse : le fichier antidaté est Beth_Secret.txt.

10.6 Quel est le contenu du faux secret ?#

icat -o 718848 Files/E01-DC01/20200918_0347_CDrive.E01 87111-128-1

Réponse : Space Beth is the real Beth.

10.7 Peut-on retrouver le fichier original de Beth ?#

Les raccourcis récents et les anciennes structures NTFS conservent le nom original. Le contenu supprimé peut être récupéré à partir des traces résiduelles.

Réponse : oui. Le fichier original s'appelait SECRET_beth.txt et contenait Earth Beth is the real Beth.

11. Cartographie du réseau#

Les communications observées permettent de reconstruire le réseau suivant :

Réponse : les deux victimes appartiennent au réseau 10.42.85.0/24. Le contrôleur de domaine était directement accessible en RDP depuis Internet.

12. Dernier contact avec l'attaquant#

Le dernier paquet impliquant le C2 se trouve à la fin de la capture.

tshark -r Files/case001.pcap -Y 'ip.addr==203.78.103.109' -T fields -e frame.time_epoch -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport | tail

date -u -d @1600493931.641008 '+%Y-%m-%d %H:%M:%S UTC'

Réponse : le dernier contact présent dans la capture date du 19 septembre 2020 à 05:38:51 UTC. Le canal pouvait encore être actif après la fin de la capture.

13. Utilisateurs et mots de passe du domaine#

13.1 Quels utilisateurs se sont connectés au serveur ?#

fls -p -o 718848 Files/E01-DC01/20200918_0347_CDrive.E01 249

Réponse : le profil utilisateur humain observé sur le DC est Administrator.

13.2 Quels utilisateurs se sont connectés au Desktop ?#

fls -p -o 239616 Files/20200918_0417_DESKTOP-SDN1RPT.E01 1475

Réponse : Administrator et ricksanchez.

13.3 Quels sont les mots de passe du domaine ?#

Les empreintes NTLM peuvent être extraites hors ligne depuis ntds.dit et le registre SYSTEM.

secretsdump.py -ntds Files/Protected/ntds.dit -system Files/Protected/system LOCAL

Après un crack hors ligne, les résultats sont :

Ces identifiants sont des données sensibles et ne doivent être utilisés qu'à l'intérieur du laboratoire.

14. Recommandations#

14.1 Mesures immédiates#

Le domaine doit être considéré comme entièrement compromis puisque l'attaquant a obtenu un compte administrateur et a contrôlé le DC.

Les actions prioritaires sont les suivantes :

1. isoler immédiatement les deux machines compromises ;
2. supprimer l'exposition directe du port RDP sur Internet ;
3. bloquer les communications avec 194.61.24.102 et 203.78.103.109 ;
4. réinitialiser les mots de passe du domaine et renouveler les secrets Kerberos ;
5. reconstruire le contrôleur de domaine et le poste depuis des sources fiables ;
6. rechercher les mêmes indicateurs sur le reste du système d'information.

14.2 Amélioration principale de l'architecture#

L'administration distante ne doit plus arriver directement sur le contrôleur de domaine. Elle doit passer par un VPN protégé par MFA, puis par un bastion d'administration placé dans un segment dédié.

Le DC doit également être séparé des postes utilisateurs. Les flux RDP internes et les connexions sortantes depuis les serveurs doivent être limités aux besoins réels.

14.3 Contrôles de sécurité à mettre en place#

• MFA pour tous les accès distants et tous les comptes privilégiés ;
• mots de passe longs, uniques et protégés contre la réutilisation ;
• verrouillage ou limitation après plusieurs échecs d'authentification ;
• comptes d'administration séparés des comptes utilisateurs ;
• EDR sur les serveurs et les postes ;
• centralisation des journaux Windows et alertes sur les événements 4625, 4624 et 7045 ;
• filtrage des sorties Internet depuis les serveurs ;
• contrôle d'exécution avec AppLocker ou WDAC ;
• journalisation renforcée de PowerShell ;
• segmentation réseau et limitation des communications est-ouest.

Ces mesures correspondent notamment aux contrôles CIS relatifs à la gestion des comptes, à la configuration sécurisée, à la limitation des services réseau, au contrôle des accès et à la surveillance continue.

15. Chronologie consolidée#

16. Conclusion#

L'incident commence par une faiblesse simple mais critique : un service RDP exposé directement sur Internet et protégé par un mot de passe pouvant être découvert par force brute. Une fois connecté au contrôleur de domaine, l'attaquant dispose immédiatement d'un point d'accès privilégié vers les données et le reste du réseau.

Le téléchargement de Meterpreter lui permet de conserver le contrôle des deux machines, de se déplacer vers le Desktop et d'exfiltrer plusieurs archives. L'accès à la recette Szechuan est confirmé, tout comme la consultation des fichiers de Morty et la manipulation du secret de Beth.

Cette compromission aurait principalement pu être évitée en supprimant l'accès RDP direct au DC, en imposant un VPN avec MFA et en segmentant les systèmes d'administration. La réutilisation des identifiants et l'absence de filtrage sortant ont ensuite facilité la propagation et le maintien du canal C2.