🧠 Analyser les connexions réseau d'un dump mémoire Windows avec Volatility 3 : détecter un C2 pas à pas

📌 Informations générales

• Catégorie : Forensics mémoire
• Niveau : Débutant
• Outils principaux : Volatility 3 (windows.netscan)
• Prérequis : Une machine Linux ou Windows avec Python 3 et Volatility 3 installés, avoir lu Première analyse d'un dump mémoire Windows avec Volatility 3 : les 5 commandes essentielles pour commencer, et l'envie d'apprendre

🧩 Introduction

Identifier un processus suspect dans un dump mémoire, c'est une chose. Comprendre ce qu'il faisait sur le réseau, c'en est une autre — et souvent plus révélatrice encore. Un malware qui ne communique pas est rare : il doit contacter son C2 pour recevoir des ordres, exfiltrer des données ou télécharger des modules supplémentaires. C'est précisément là qu'intervient le module windows.netscan.

Avant de se lancer dans l'analyse, quelques questions guident la démarche :

• Que représente chaque colonne présente dans la sortie de netscan ?
• Que signifie chacun des états TCP, et qu'est-ce que cela implique pour l'investigation ?
• Comment identifier qu'une connexion est suspecte ? Le port utilisé est-il légitime ?
• Le processus lié à cette connexion est-il celui qu'on suspecte déjà ?
• Comment conclure qu'une IP est réellement malveillante et pas un faux positif ?

Cet article fait suite à la première investigation sur le lab RedLine de CyberDefenders, en utilisant le même dump mémoire :

• RedLine Lab - CyberDefenders

Info :
Cet article fait directement suite à Première analyse d'un dump mémoire Windows avec Volatility 3 : les 5 commandes essentielles pour commencer. Le dump mémoire, le malware et les IOCs sont identiques — la lecture du premier article est recommandée pour bien suivre le raisonnement.

🔎 Phase 0 – Rappel rapide

Durant la précédente investigation sur le malware RedLine, nous avions pu identifier les éléments suivants :

• Processus suspect identifié : oneetx.exe
  • Nom inconnu du catalogue Windows
  • Emplacement illégitime : C:\Users\Tammam\AppData\Local\Temp\c3912af058\ (répertoire temporaire utilisateur — jamais un emplacement légitime pour un exécutable système)
• Processus enfant de oneetx.exe : rundll32.exe
  • Terminé au moment de la capture, donc invisible dans windows.pslist, uniquement visible via windows.psscan
  • Utilitaire Windows légitime détourné pour exécuter des fonctions exposées par des DLL
• Chargement d'une DLL suspecte via windows.ldrmodules sur oneetx.exe (PID 5480) :
  • DLL identifiée : \Windows\SysWOW64\mscoree.dll
  • Absente des trois listes maintenues par le PEB : InLoadOrderModuleList, InMemoryOrderModuleList, InInitializationOrderModuleList → trois False
• IP suspecte identifiée : 77.91.124.20 — c'est précisément ce que nous allons qualifier en détail dans cet article
• Extraction de oneetx.exe — hash SHA-256 : `8d5d5bbdccb82a10ac28e2779ba0821f12da3e1f08f03ec467ce213a6fccf38c

Warning !
En cas de téléchargement du fichier oneetx.exe, toute manipulation de celui-ci doit être réalisée dans un environnement isolé : machine virtuelle sans accès réseau vers votre machine hôte, et sans accès à Internet pour contenir l'infection. Je ne suis en aucun cas responsable de toute infection résultant d'une exécution non contrôlée, ni de toute exploitation de ce malware à des fins malveillantes.

🔎 Phase 1 – Comprendre la sortie de windows.netscan

Avant d'analyser quoi que ce soit, il est essentiel de savoir lire la sortie du module. Beaucoup de débutants lancent la commande et se retrouvent face à un tableau de colonnes dont ils ne connaissent pas la signification. Voici ce que chacune représente :

Ces colonnes répondent collectivement à des questions fondamentales : Qui communique ? Avec qui ? Sur quel port ? Depuis quand ? La connexion est-elle encore active ? Ce sont ces questions qui guident toute l'analyse réseau.

⚙️ Phase 2 – Comprendre les états TCP

L'état TCP d'une connexion indique à quelle étape du cycle de vie elle se trouve au moment de la capture mémoire. En forensics, cela permet de savoir si une communication était encore active, déjà terminée, ou en cours d'établissement.

💡 En forensics mémoire, une connexion en état CLOSED ne signifie pas qu'elle n'a pas eu lieu — au contraire, c'est la preuve qu'elle a eu lieu et s'est terminée. L'horodatage Created permet de replacer cet échange dans la timeline de l'attaque.

⚙️ Phase 3 – Identifier les connexions suspectes

On dispose désormais des outils pour lire et interpréter une sortie réseau. Place à l'application concrète.

vol -f MemoryDump.mem windows.netscan

Voici l'extrait pertinent de la sortie, filtré sur les éléments qui nous intéressent :

Offset          Proto   LocalAddr       LocalPort       ForeignAddr     ForeignPort     State   PID     Owner           Created  

[...]
0xad8189a30a20  TCPv4   192.168.190.141 53660           38.121.43.65    443             CLOSED  4628    tun2socks.exe   2023-05-21 22:00:25.000000 UTC
[...]  
0xad818c17ada0  UDPv4   0.0.0.0         52051           *               0                       4628    tun2socks.exe   2023-05-21 22:24:14.000000 UTC  
[...]
0xad818de4aa20  TCPv4   10.0.85.2       55462           77.91.124.20    80              CLOSED  5896    oneetx.exe      2023-05-21 23:01:22.000000 UTC  
0xad818df1d920  TCPv4   192.168.190.141 55433           38.121.43.65    443             CLOSED  4628    tun2socks.exe   2023-05-21 23:00:02.000000 UTC  
[...]
0xad818e4a6900  UDPv4   0.0.0.0         0       *       0                                       5480    oneetx.exe      2023-05-21 22:39:47.000000 UTC  
0xad818e4a6900  UDPv6   ::              0       *       0                                       5480    oneetx.exe      2023-05-21 22:39:47.000000 UTC  
0xad818e4a9650  UDPv4   0.0.0.0         0       *       0                                       5480    oneetx.exe      2023-05-21 22:39:47.000000 UTC  
[...]
0xad8190e59a60  UDPv4   0.0.0.0         55536   *       0                                       4628    tun2socks.exe   2023-05-21 23:00:47.000000 UTC  
0xad8190e59d80  UDPv4   0.0.0.0         56228   *       0                                       4628    tun2socks.exe   2023-05-21 23:00:38.000000 UTC  
0xad8190e5b040  UDPv4   0.0.0.0         49734   *       0                                       4628    tun2socks.exe   2023-05-21 23:00:41.000000 UTC

oneetx.exe — la connexion suspecte

Plusieurs éléments convergent vers la qualification de C2 pour la connexion associée à oneetx.exe :

• Le propriétaire : oneetx.exe — processus déjà identifié comme suspect lors de la précédente investigation.
• Le PID : 5896 — instance antérieure de oneetx.exe, terminée au moment de la capture mais dont les artefacts réseau subsistent en mémoire.
• Le port distant : 80 (HTTP). En 2023, HTTP en clair est au mieux obsolète, au pire volontairement choisi pour dissimuler du trafic dans un flux apparemment banal. Il ne transporte aucun chiffrement — tout le contenu transite en clair.
• L'état : CLOSED — la connexion est terminée, mais elle a bien eu lieu. L'horodatage 2023-05-21 23:01:22 UTC la place à environ une minute avant la capture mémoire.
• Les sockets UDP (PID 5480) : des sockets UDP ouverts sur 0.0.0.0:0 vers *:0 sans destination précise, actifs dès 22:39:47 UTC, soit plus de vingt minutes avant la connexion TCP. Cela peut indiquer une phase de reconnaissance réseau ou une tentative de communication alternative.

tun2socks.exe — la connexion légitime

À première vue, tun2socks.exe apparaît dans la même sortie et pourrait sembler suspect. Voici pourquoi il ne l'est pas, en se basant uniquement sur les données réseau :

• Le port distant : 443 (HTTPS/TLS). C'est le port standard d'une communication chiffrée sécurisée, et le comportement attendu d'un client VPN qui établit un tunnel chiffré.
• La cohérence de l'IP distante : 38.121.43.65 apparaît à plusieurs reprises dans la sortie (à 22:00:25, 23:00:02), toujours associée au même processus sur le même port. Un malware cherche généralement à communiquer discrètement ; un VPN légitime se reconnecte régulièrement au même point de sortie de manière attendue et répétitive.
• Les sockets UDP de tun2socks.exe : des sockets UDP ouverts sur des ports locaux (52051, 55536, 56228, 49734) avec des destinations * sont cohérents avec le comportement d'un tunnel VPN qui gère des flux UDP en transit. C'est une signature normale pour ce type d'outil.

La distinction fondamentale entre les deux : oneetx.exe communique en clair sur HTTP (port 80) vers une IP inconnue sans pattern de récurrence ; tun2socks.exe communique en chiffré sur HTTPS (port 443) vers une IP stable et récurrente, avec un comportement réseau cohérent pour un VPN.

⚙️ Phase 4 – Vérifier une IP suspecte

On a une IP candidate : 77.91.124.20. La qualifier comme C2 ne s'arrête pas à l'analyse mémoire — on la croise avec des sources de threat intelligence accessibles gratuitement.

VirusTotal

🔗 https://www.virustotal.com/gui/ip-address/77.91.124.20/

VirusTotal agrège les résultats de dizaines de moteurs de sécurité et de bases de threat intelligence. Pour cette IP :

• 16 moteurs sur 91 la classifient comme malveillante
• Géolocalisation : Allemagne
• ASN : 215730 — H2nexus Ltd

On y retrouve également des relations documentées avec des fichiers malveillants, dont oneetx.exe lui-même, ce qui confirme le lien entre le processus suspect et ce serveur.

whois

🔗 https://www.whois.com/whois/77.91.124.20

inetnum:    77.91.124.0 - 77.91.124.255 
descr:      H2.NEXUS Frankfurt Network 
netname:    H2NEXUS 
country:    DE 
status:     SUB-ALLOCATED PA

Le whois confirme que le bloc IP appartient à H2.NEXUS, un hébergeur situé à Francfort (Allemagne). Ce type d'hébergeur "bulletproof" — qui accepte des clients sans vérification rigoureuse — est fréquemment utilisé par des acteurs malveillants pour héberger leur infrastructure C2.

💡 Note intéressante : les dates dans le whois (created: 2024-07-11) sont postérieures à l'attaque (mai 2023). Cela indique que le bloc IP a été réalloué ou ré-enregistré après l'incident — un phénomène courant : les attaquants changent régulièrement d'infrastructure, et les hébergeurs réallouent leurs blocs. Ça n'invalide pas la corrélation, mais c'est un bon rappel que le whois reflète l'état actuel de l'enregistrement, pas forcément celui au moment de l'attaque.

AbuseIPDB

Un troisième outil complémentaire à connaître : AbuseIPDB (https://www.abuseipdb.com/), une base communautaire de signalements d'IPs malveillantes. Une IP signalée de nombreuses fois récemment par d'autres analystes renforce la qualification C2, et permet parfois d'identifier la campagne ou la famille de malware associée.

🎯 Méthodologie synthétique

Voici la checklist d'analyse que je recommande, dans l'ordre :

🧾 Conclusion

Cette analyse réseau vient clore la boucle ouverte dans l'article précédent. On savait que oneetx.exe était malveillant — on sait maintenant avec certitude qu'il a communiqué avec un C2 (77.91.124.20) via HTTP sur le port 80, confirmé par la threat intelligence publique (VirusTotal, whois).

Ce qu'il faut retenir de cette méthodologie :

• 🔑 Lire la sortie avant de l'analyser. Connaître ce que représente chaque colonne évite les erreurs d'interprétation et permet d'aller droit au but dans une investigation.
• 🔑 Un port ne suffit pas à qualifier une connexion. Le port 443 n'est pas une garantie de légitimité, tout comme le port 80 n'est pas une preuve de malveillance. C'est la cohérence globale — processus, port, IP, pattern de comportement — qui permet de conclure.
• 🔑 La threat intelligence complète l'analyse mémoire. Volatility te dit ce qui s'est passé. VirusTotal, whois et AbuseIPDB te disent avec qui. Les deux ensemble permettent de reconstituer le scénario complet.

💀 L'erreur classique du débutant :

Qualifier immédiatement une IP de C2 sur la seule base du port 80, sans croiser avec le processus associé ni valider sur les sources de threat intelligence. Le port 80 est utilisé par des milliers de services légitimes — c'est le contexte qui fait l'IOC, pas le port seul.

🛑 Bonnes pratiques d'analyse

❌ Ne pas qualifier une IP comme malveillante sur la seule base d'un port ou d'un processus pris isolément
❌ Ne pas ignorer les sockets UDP — ils révèlent parfois des comportements que les connexions TCP ne montrent pas
✅ Toujours croiser une IP suspecte sur au moins deux sources de threat intelligence (VirusTotal + AbuseIPDB ou whois)
✅ Corréler systématiquement les PID de netscan avec les processus identifiés dans pslist et psscan

📚 Références et ressources

• Documentation officielle Volatility 3 — Référence à jour des plugins et de leur syntaxe
• RedLine Lab - CyberDefenders — Le lab dont est tirée cette analyse
• VirusTotal - IP 77.91.124.20 — Rapport de threat intelligence sur l'IP C2
• AbuseIPDB — Base communautaire de signalements d'IPs malveillantes
• MITRE ATT&CK T1071.001 - Web Protocols — Utilisation de HTTP/HTTPS pour les communications C2