Immersion dans un cas concret : l’analyse d’un trafic suspect au cœur d’une infrastructure d’entreprise.

Lien de l’exercice : https://www.malware-traffic-analysis.net/2025/01/22/

---

Contexte

Scénario

• LAN segment range: 10.1.17[.]0/24 (10.1.17[.]0 through 10.1.17[.]255)

• Domain: bluemoontuesday[.]com

• Active Directory (AD) domain controller: 10.1.17[.]2 - WIN-GSH54QLW48D

• AD environment name: BLUEMOONTUESDAY

• LAN segment gateway: 10.1.17[.]1

• LAN segment broadcast address: 10.1.17[.]255

Questions

• What is the IP address of the infected Windows client?

• What is the mac address of the infected Windows client?

• What is the host name of the infected Windows client?

• What is the user account name from the infected Windows client?

• What is the likely domain name for the fake Google Authenticator page?

• What are the IP addresses used for C2 servers for this infection?

---

Analyse

Nous avons donc à disposition un fichier → 2025-01-22-traffic-analysis-exercise.pcap .

Dans un premier temps, j’ai choisi de me concentrer sur l’analyse des flux HTTP et DNS. Je reviendrai ensuite sur une vision plus globale afin de répondre aux différentes questions posées dans l’énoncé.

Analyse HTTP & DNS

En appliquant dans Wireshark le filtre http || dns, j’ai rapidement remarqué plusieurs FQDN suspects :

• authenticatoor[.]org (https://www.virustotal.com/gui/domain/authenticatoor.org)

• appointedtimeagriculture[.]com (https://www.virustotal.com/gui/domain/appointedtimeagriculture.com)

• google-authenticator[.]burleson-appliance[.]net (https://www.virustotal.com/gui/domain/google-authenticator.burleson-appliance.net)

Ces domaines, résolus par le DNS, semblent tous liés à des activités malveillantes.

J’ai également constaté que l’ensemble de ces requêtes provenaient de l’adresse IP 10.1.17.215, ce qui laisse penser qu’il s’agit de la machine compromise.

En poursuivant l’analyse, juste après ces résolutions DNS, on observe le comportement suivant :

En suivant le flux HTTP de la première requête, j’ai identifié la présence d’un script VBScript :

L’examen de ce script révèle plusieurs actions :

• Lancement de PowerShell dans une fenêtre minimisée (/min), rendant l’exécution invisible pour l’utilisateur.

• -NoProfile : empêche le chargement du profil utilisateur PowerShell.

• -WindowStyle Hidden : masque la fenêtre pour plus de discrétion.

• start-process 'https://azure.microsoft.com' : ouvre une page légitime (Azure) afin de détourner l’attention.

• new-object System.Net.WebClient : crée un client HTTP pour télécharger des fichiers.

• DownloadString('http://.../29842.ps1') : récupère un script PowerShell externe.

• iex (Invoke-Expression) : exécute immédiatement en mémoire le contenu téléchargé.

Même sans analyser le code du script PowerShell, ce comportement est déjà hautement suspect : il correspond typiquement à celui d’un dropper chargé de récupérer et exécuter un malware en mémoire.

Pour confirmer, j’ai donc suivi le fil en étudiant le fichier 29842.ps1, effectivement téléchargé comme l’indiquent les traces HTTP.

Analyse de 29842.ps1

Pour récupérer le script depuis Wireshark :

Fichier → Exporter Objets → HTTP

Puis chercher le nom du fichier et l’enregistrer :

En ouvrant le fichier avec Notepad, le script PowerShell apparaît faiblement obfusqué :

Après quelques nettoyages et décodages via CyberChef, j’ai pu obtenir un script lisible pour l’analyse.

Il ne reste plus qu'à décoder le Base64 :

$SerialNumber

• Le script utilise FileSystemObject pour récupérer le numéro de série du disque C:.

• Il convertit ce numéro en format hexadécimal, puis en entier (int64).

• Résultat : il obtient un identifiant unique de la machine (lié au disque dur).

C2

• L’adresse IP 5.252.153.241 est utilisée comme serveur de commande et contrôle (C2).

• L’URL devient : 5.252.153.241/[UniqueID]

While True

• Le script tourne en boucle.

• Il tente de télécharger du code depuis l’URL unique à la machine.

• Si le téléchargement échoue, il attend 5 secondes et réessaie.

• Si ça marche, il exécute directement ce qu’il reçoit avec Invoke-Expression

Résumons ce que l’on a pour l’instant :

• Le script initial agit comme un dropper, téléchargeant un premier payload.

• Le payload n°1 connecte la machine infectée au serveur C2 et attend des instructions.

• Dans le PCAP, on observe que la machine 10.1.17.215 effectue un polling toutes les 5 secondes vers l’adresse 5.252.153.241.

• La machine 10.1.17.215 est infecté

• L’adresse 5.252.153.241 est le serveur de commande et contrôle de l’attaquant

Première Instruction du C2

Pour suivre les actions du serveur C2, j’ai filtré le trafic avec l’adresse IP 5.252.153.241 :

Après de nombreuses requêtes aboutissant à des 404, j’ai identifié une première instruction : la machine infectée télécharge quatre nouveaux fichiers depuis l’API du serveur C2 :

• TeamViewer

• Teamviewer_Resource_fr

• TV

• pas.ps1

En analysant ces fichiers :

• Les deux premiers semblent être des composants légitimes de TeamViewer :

• https://www.virustotal.com/gui/file/904280f20d697d876ab90a1b74c0f22a83b859e8b0519cb411fda26f1642f53e

• https://www.virustotal.com/gui/file/9634ecaf469149379bba80a745f53d823948c41ce4e347860701cbdff6935192/

Le fichier TV, en revanche, est identifié comme une DLL malveillante, probablement injectée lorsque TeamViewer est lancé :

• https://bazaar.abuse.ch/sample/3448da03808f24568e6181011f8521c0713ea6160efd05bff20c43b091ff59f7/

À noter, cette DLL est signée par TeamViewer :

Si on regarde les deux autres fichiers, on peut voir que le certificat est différent et semble être plus légitime que le précédent :

Enfin, le script pas.ps1 suit le même schéma que le premier script 29842.ps1 :

• Même obfuscation

• Base64 décodé → script identique à 29842.ps1

Cela confirme que le serveur C2 réutilise le mécanisme de dropper initial pour maintenir la persistance et télécharger du code supplémentaire.

Deuxième Instruction du C2

En continuant d’analyse les requêtes HTTP allant et venant vers le serveur C2, on peut voir qu’il y a eu un nouveau téléchargement de code :

Un petit coup de cyberchef, et on obtient un nouveau script :

Une deuxième requête suit un modèle quasi identique, seule la partie payload encodée en Base64 diffère :

Encore une fois le script ressemble à un Dropper,

• Fonction de logging (Send-Log) :
  Envoie des informations (statut ou messages d’erreur) vers une URL distante, en construisant une requête HTTP via WebClient.DownloadString().

• Préparation d’un répertoire :
  Crée un dossier C:/ProgramData/jsLeow s’il n’existe pas.

• Déploiement d’un payload :
  Décode un contenu encodé en Base64, l’écrit dans un fichier PowerShell (skqllz.ps1) dans ce répertoire.

• Choix du bon exécutable PowerShell :
  Détermine si l’OS est 32 ou 64 bits, et sélectionne la version adaptée de powershell.exe.

• Exécution du script malveillant :
  Lance le script PowerShell décodé (skqllz.ps1) avec -ExecutionPolicy Bypass et en mode caché (-w hidden).

• Envoi de rapport :
  Informe le serveur distant du succès ou de l’échec de l’opération.

Le rapport est d’ailleurs bien envoyé vers le serveur C2 ce qui prouve que le script a bien fonctionné :

Le contenu du payload, une fois décodé, révèle un fichier plus sophistiqué et fortement obfusqué.

En passant le fichier sur VirusTotal on peut confirmer que c’est bien un fichier malveillant :

• https://www.virustotal.com/gui/file/0e7f388dd20ca9a1597e9f4fcc1f30af24ad5dc9b6c2b1e89aa3c7d17f76ceed

Réponses aux questions

Reprenons les questions :

• What is the IP address of the infected Windows client? 10.1.17.215

• What is the mac address of the infected Windows client? 00:d0:b7:26:4a:74

  • Cette information peut être retrouvée via une requête ARP émise par l’hôte :

• What is the host name of the infected Windows client? DESKTOP-L8C5GSJ

  • Le nom d’hôte est visible dans certaines requêtes réseau :

• What is the user account name from the infected Windows client? shutchenson

  • Cette information est récupérable dans les requêtes Kerberos :

• What is the likely domain name for the fake Google Authenticator page? authenticatoor[.]org

• What are the IP addresses used for C2 servers for this infection?

L’analyse a permis d’identifier plusieurs adresses :

5.252.153.241

• Cette IP a été suivie depuis le début de l’analyse et correspond au premier serveur C2.

45.125.66.32 et 45.125.66.252

• La première adresse IP est visible dans le rapport VirusTotal du dernier payload trouvé.

• Si on cherche cette IP dans la capture réseau :

• On voit qu’il y a bien eu des communications entre l’hôte infecté et le serveur derrière l’adresse IP 45.125.66.32 . On voit aussi l’adresse IP 45.125.66.252 qui correspond au même pool d’adresse IP :

L’adresse 45.125.66.252 est aussi flaggé comme malveillante sur VirusTotal (https://www.virustotal.com/gui/ip-address/45.125.66.252). J’ajoute donc ces deux serveurs à notre liste de serveur C2.