Simuler et capturer le trafic réseau

La plupart des malwares (logiciels malveillants) ne servent à rien seuls. Ils ont besoin de récupérer une seconde étape, de recevoir des commandes ou d’envoyer des données volées, et la première chose que font de nombreux échantillons après leur démarrage est de chercher leur serveur. Cela fait du réseau le canal le plus révélateur que vous puissiez observer — et le plus dangereux à mal gérer. L’objectif de cette leçon est une contradiction qu’il faut construire : l’échantillon doit croire qu’il est en ligne, et rien de ce qu’il envoie ne doit atteindre le vrai Internet.

Construire un laboratoire d’analyse sûr a déjà installé INetSim sur la machine auxiliaire REMnux et FakeNet-NG dans la VM Windows, et a prouvé que le vrai Internet est inaccessible. Surveillance comportementale en est le pendant côté hôte — cette leçon suppose que vous exécutez les deux moitiés dans la même routine de détonation, la capture de paquets étant lancée à l’étape Enregistrement.

Ce qu’un simulateur doit imiter

Un échantillon qui cherche à joindre son serveur traverse trois couches. Chacune doit recevoir une réponse, sinon la conversation s’arrête avant de vous avoir montré quoi que ce soit d’intéressant.

Un échec à n’importe quelle couche est aussi une donnée. Un échantillon qui ne reçoit aucune réponse DNS peut essayer une liste de domaines de repli, révélant davantage d’infrastructure. Un autre qui reçoit une réponse HTTP absurde peut planter, se mettre en sommeil ou se rabattre sur un autre protocole. Enregistrer ces réactions fait partie du travail.

Redirection DNS

Le contrôle le plus simple est le résolveur : pointez le DNS de la VM d’analyse vers un serveur qui répond à chaque nom avec l’adresse de vos faux services. Le dns_default_ip d’INetSim et l’écouteur DNS intégré de FakeNet-NG font exactement cela.

Deux pièges méritent d’être connus. D’abord, un résolveur qui répond à tout est lui-même détectable : certains échantillons résolvent un nom aléatoire ou connu pour ne pas exister, et s’arrêtent s’il se résout. L’exemple le plus connu est WannaCry, dont le « kill switch » stoppait le ver quand un domaine non enregistré répondait. Si une exécution est étrangement silencieuse, recommencez avec le simulateur configuré pour renvoyer NXDOMAIN pour les noms inconnus. Ensuite, les échantillons qui se connectent à des adresses IP codées en dur n’interrogent jamais le DNS. Dans la configuration à deux VM, faites de REMnux la passerelle par défaut et redirigez chaque connexion entrante vers ses écouteurs locaux :

# On REMnux: accept connections for any destination IP arriving on the lab interface
sudo iptables -t nat -A PREROUTING -i ens33 -p tcp -j REDIRECT
sudo iptables -t nat -A PREROUTING -i ens33 -p udp -j REDIRECT

REDIRECT conserve le port de destination d’origine, si bien que l’écouteur HTTP d’INetSim sur le port 80 répond toujours au trafic destiné à 203.0.113.7:80. Remplacez ens33 par le nom de votre interface de labo. FakeNet-NG gère le même cas à l’intérieur de Windows sans rien de tout cela : son diverter (aiguilleur) intercepte les paquets sortants quelle que soit la destination et les remet à un écouteur local, ou à un écouteur par défaut pour les ports qu’il ne connaît pas.

Faux HTTP et HTTPS

INetSim sert de faux fichiers choisis selon l’extension — une requête se terminant par .exe reçoit un petit exécutable inoffensif, .jpg une image de remplacement — et journalise chaque requête. FakeNet-NG fait de même et peut être configuré avec des réponses personnalisées pour des hôtes ou des chemins précis, ce qui vous permet de fournir à un échantillon la réponse qu’il attend une fois son protocole rétro-conçu.

Le trafic chiffré est là où la simulation devient difficile :

Quand l’interception échoue, le texte clair existe toujours dans le processus juste avant d’être chiffré. Tracer les appels d’API et les appels système montre comment hooker les fonctions d’envoi, et Dumper la mémoire et extraire les charges utiles comment extraire la configuration et les clés d’un échantillon en cours d’exécution.

Mettre en place les simulateurs

INetSim sur REMnux (en partant de la configuration de la leçon sur le labo) :

1. Dans /etc/inetsim/inetsim.conf, laissez service_bind_address et dns_default_ip réglés sur l’adresse de REMnux dans le labo, et activez les services nécessaires avec des lignes start_service (dns, http, https, smtp, ftp, irc sont typiques).
2. Passez en revue les entrées http_fakefile pour que les extensions courantes renvoient un fichier bénin, et définissez http_default_fakefile pour tout le reste.
3. Ajoutez les redirections iptables ci-dessus si vous voulez capter les IP codées en dur.
4. Lancez sudo inetsim et conservez son rapport par session ainsi que /var/log/inetsim/service.log : ils listent chaque requête avec un horodatage.

FakeNet-NG dans la VM Windows (sessions à une seule VM) :

1. Ouvrez une invite élevée et lancez fakenet. La configuration par défaut détourne tout le trafic, démarre des écouteurs DNS, HTTP, HTTPS, SMTP et bruts, et journalise dans la console.
2. Ajoutez les outils d’analyse qui communiquent sur le réseau à la liste noire de processus du fichier de configuration, pour que leur trafic ne pollue pas le journal.
3. Conservez la capture de paquets que FakeNet-NG écrit dans son répertoire de travail, et copiez son journal de console dans vos notes avant de restaurer.

Attention : FakeNet-NG s’exécute dans la même VM que l’échantillon. Un échantillon qui cherche son processus, son pilote ou la redirection de son propre trafic peut le voir. INetSim sur une VM séparée est invisible pour l’invité, c’est pourquoi la configuration à deux VM est celle par défaut dans ce cours.

Capturer le trafic

L’endroit où vous capturez compte autant que la manière. Une capture hors de la VM d’analyse — sur l’interface de labo de REMnux, ou sur le réseau virtuel de l’hôte — est invisible pour l’échantillon et enregistre tout, y compris le trafic des processus dans lesquels l’échantillon s’est injecté. Une capture dans l’invité (Wireshark sous Windows, le pcap propre à FakeNet-NG) est pratique mais constitue un outil de plus que l’échantillon peut détecter.

Sur REMnux, lancez la capture avant l’échantillon et faites tourner les fichiers pour qu’une longue exécution ne puisse pas remplir le disque :

# Full packets, new file every 100 MB, keep at most 20 files
sudo tcpdump -i ens33 -s 0 -C 100 -W 20 -w /cases/run1.pcap

Le dumpcap de Wireshark fait de même avec -b filesize: et -b files:. Ouvrez le résultat dans Wireshark sur REMnux, ou copiez-le à l’extérieur par le même canal que vos autres artefacts.

Lire une capture

Commencez large, puis resserrez. Statistics → Conversations et Endpoints montrent qui a parlé à qui et en quelle quantité ; Protocol Hierarchy montre quels types de trafic existent. Parcourez ensuite les couches avec des filtres d’affichage :

tshark transforme ces mêmes filtres en colonnes scriptables :

tshark -r run1.pcap -Y 'dns.flags.response == 0' -T fields -e frame.time_relative -e dns.qry.name
tshark -r run1.pcap -Y http.request -T fields -e http.host -e http.request.uri -e http.user_agent
tshark -r run1.pcap -Y 'tls.handshake.type == 1' -T fields -e tls.handshake.extensions_server_name

User-agents et en-têtes

Les auteurs de malware écrivent leurs propres clients HTTP ou réutilisent une bibliothèque, et les deux laissent des marques. Un user-agent codé en dur qui se fait passer pour un vieux navigateur, une faute d’orthographe, un en-tête Accept absent alors que tout vrai navigateur l’envoie, un ordre d’en-têtes inhabituel, ou la chaîne par défaut d’une bibliothèque (Python-urllib/3.x, Go-http-client/1.1) sont autant de signes distinctifs. Suivez une requête entière avec Follow → TCP Stream et lisez-la comme le ferait le serveur.

Intervalles de beacon

Un implant qui n’a rien à faire se signale quand même, généralement selon un minuteur avec un peu de gigue aléatoire (jitter). Tracez les heures de connexion, ou calculez les écarts entre requêtes successives vers le même hôte : 60 secondes régulières à dix pour cent près, c’est un beacon, pas une personne qui navigue. Rappelez-vous que les sandbox (bacs à sable) qui raccourcissent les pauses faussent cette chronologie, et que certains échantillons la mesurent (détection de l’accélération du sommeil).

Empreintes TLS : JA3 et JA4

Quand le contenu est chiffré, la poignée de main reste visible. Le Client Hello liste la version de TLS, les suites de chiffrement, les extensions et les groupes pris en charge que propose le client, et cette liste dépend de la bibliothèque TLS et de la façon dont le programme l’a configurée. JA3 hache ces champs en un MD5 ; JA4 produit une empreinte lisible et triée, comme t13d1711..._..._..., dont la première partie encode le protocole, la version de TLS, la présence du SNI, le nombre de suites, le nombre d’extensions et l’ALPN. Les versions récentes de Wireshark calculent les deux comme champs du Client Hello.

Traitez-les comme des preuves d’appoint. Une empreinte identifie une pile TLS et sa configuration, pas un programme : toute application construite sur la même bibliothèque avec les réglages par défaut a la même apparence. Un JA4 est solide lorsqu’il est rare dans votre réseau et associé à d’autres signaux — le SNI, la destination, la chronologie.

Des observations aux IOC réseau

Une règle prime sur tout le reste de ce tableau : dans un labo simulé, les adresses IP que vous capturez sont les vôtres. INetSim a répondu à chaque requête DNS avec l’adresse de REMnux, donc l’« IP du C2 » dans votre pcap est 10.0.0.1. Les vraies adresses viennent de la configuration de l’échantillon, des chaînes, ou des enregistrements de DNS passif et de renseignement sur les menaces — jamais de votre faux résolveur. La leçon prévue Écrire des signatures réseau transforme les lignes durables de ce tableau en règles Suricata et Snort.

OPSEC : pourquoi l’échantillon reste hors ligne

Il est tentant de « le laisser se connecter, juste pour voir » ce que le serveur envoie. Ne le faites pas, et n’allez pas non plus vous-même sur l’infrastructure de l’attaquant — pas de navigation vers l’URL du C2, pas de curl dessus, pas de scan de ports, depuis aucun réseau qui vous appartient ou appartient à votre employeur.

• Vous alertez l’opérateur. Les attaquants surveillent leurs serveurs. Une connexion depuis la plage d’IP d’un éditeur de sécurité ou d’une entreprise, à une heure inhabituelle, depuis une machine qui ne se comporte jamais comme une victime, leur apprend que leur outil a été découvert.
• Vous devenez une victime. Un C2 actif peut pousser une seconde étape, une charge utile de rançongiciel ou des instructions de propagation. Votre labo héberge alors une véritable intrusion.
• Vous attaquez quelqu’un d’autre. Les serveurs C2 sont souvent des machines tierces compromises. Les sonder peut enfreindre la loi et les politiques internes, et perturber une enquête déjà en cours.
• Vous révélez votre identité. Votre IP, votre résolveur, votre empreinte TLS et votre user-agent sont tous visibles de l’autre côté.

Les sources passives — DNS passif, Certificate Transparency, rapports publics de sandbox, vos propres journaux de proxy — répondent à la plupart des questions sans contact. Quand une interaction en direct est réellement nécessaire, c’est une décision d’équipe, mise en œuvre depuis une infrastructure dédiée et approuvée, pas un raccourci d’analyste.

Lab : capturer et disséquer un beacon simulé

Ce lab s’exécute entièrement sur votre propre machine via l’interface de bouclage (loopback), sans aucun échantillon. Un minuscule faux serveur joue le rôle d’INetSim ; un client Python inoffensif joue celui d’un implant qui se signale selon un minuteur. Les sorties ci-dessous proviennent d’une machine macOS ; sous Linux, capturez sur lo au lieu de lo0.

1. Créez un répertoire de travail et un environnement virtuel avec dpkt :

   mkdir m6a && cd m6a
   python3 -m venv .venv
   .venv/bin/pip install dpkt

2. Écrivez le faux serveur. Il répond à n’importe quel chemin avec la même page et journalise une ligne JSON par requête :

   # fake_http.py - answer every HTTP request with a canned body and log it
   import http.server, json, sys, time
   
   BODY = b"<html><body>lab fake server</body></html>\n"
   LOG = open(sys.argv[2] if len(sys.argv) > 2 else "requests.jsonl", "a")
   
   class AnyPath(http.server.BaseHTTPRequestHandler):
       def _answer(self):
           length = int(self.headers.get("Content-Length") or 0)
           body = self.rfile.read(length) if length else b""
           LOG.write(json.dumps({
               "ts": round(time.time(), 3),
               "src": f"{self.client_address[0]}:{self.client_address[1]}",
               "method": self.command, "path": self.path,
               "host": self.headers.get("Host"),
               "user_agent": self.headers.get("User-Agent"),
               "body_len": len(body),
           }) + "\n")
           LOG.flush()
           self.send_response(200)
           self.send_header("Content-Type", "text/html")
           self.send_header("Content-Length", str(len(BODY)))
           self.end_headers()
           self.wfile.write(BODY)
   
       do_GET = do_POST = do_HEAD = _answer
   
       def log_message(self, fmt, *args):
           pass
   
   port = int(sys.argv[1]) if len(sys.argv) > 1 else 8080
   print(f"fake HTTP listening on 127.0.0.1:{port}", flush=True)
   http.server.ThreadingHTTPServer(("127.0.0.1", port), AnyPath).serve_forever()

3. Écrivez le beacon. Il envoie six requêtes avec un user-agent fixe, espacées d’environ cinq secondes avec dix pour cent de gigue. L’en-tête Host tient lieu du domaine qu’un faux résolveur aurait fait pointer vers votre serveur :

   # beacon.py - a harmless client that "checks in" like a simple implant
   import random, time, urllib.request
   
   URL = "http://127.0.0.1:8080/api/v1/checkin?id=LAB-0001"
   UA = "LabAgent/1.0"
   HOST = "updates.example.net"
   COUNT, INTERVAL, JITTER = 6, 5.0, 0.10
   
   for i in range(COUNT):
       req = urllib.request.Request(URL, headers={"User-Agent": UA, "Host": HOST})
       with urllib.request.urlopen(req, timeout=3) as resp:
           print(f"beacon {i + 1}/{COUNT}: HTTP {resp.status}, {len(resp.read())} bytes", flush=True)
       if i < COUNT - 1:
           time.sleep(INTERVAL * random.uniform(1 - JITTER, 1 + JITTER))

4. Démarrez le serveur et la capture, puis lancez le beacon. Capturer sur lo0 nécessite l’autorisation d’ouvrir les périphériques BPF (sous macOS, l’appartenance au groupe access_bpf que configure l’installeur de Wireshark ; sinon sudo). Si vous ne pouvez pas capturer, le journal JSON du serveur vous permet quand même de faire les étapes 6 et 7.

   .venv/bin/python fake_http.py 8080 requests.jsonl &
   tcpdump -i lo0 -s 0 -w beacon.pcap 'tcp port 8080' &
   .venv/bin/python beacon.py
   kill %2 %1

   beacon 1/6: HTTP 200, 42 bytes
   ...
   beacon 6/6: HTTP 200, 42 bytes
   76 packets captured

5. Regardez une requête telle que le réseau l’a vue. tcpdump -r beacon.pcap -nn montre six connexions TCP courtes vers le port 8080 ; la charge utile de la première requête est :

   GET /api/v1/checkin?id=LAB-0001 HTTP/1.1
   Accept-Encoding: identity
   User-Agent: LabAgent/1.0
   Host: updates.example.net
   Connection: close

   Remarquez les deux en-têtes que vous n’avez pas écrits. Accept-Encoding: identity et Connection: close, dans cet ordre, sont des valeurs par défaut d’urllib en Python — exactement le genre d’empreinte de bibliothèque qui survit quand un auteur change le user-agent.

6. Extrayez les IOC avec Python. Ce script analyse la capture avec dpkt (les captures de bouclage macOS utilisent le type de lien loopback BSD), conserve les requêtes HTTP et mesure les écarts entre elles :

   # extract_iocs.py - pull HTTP request IOCs and beacon timing out of a pcap
   import collections, statistics, sys
   import dpkt
   
   def packets(path):
       with open(path, "rb") as fh:
           for ts, buf in dpkt.pcap.Reader(fh):
               ip = dpkt.loopback.Loopback(buf).data
               if isinstance(ip, (dpkt.ip.IP, dpkt.ip6.IP6)) and isinstance(ip.data, dpkt.tcp.TCP):
                   yield ts, ip.data
   
   requests = []
   for ts, tcp in packets(sys.argv[1]):
       if tcp.dport != 8080 or not tcp.data:
           continue
       try:
           req = dpkt.http.Request(tcp.data)
       except (dpkt.dpkt.NeedData, dpkt.dpkt.UnpackError):
           continue
       requests.append((ts, req.method, req.headers.get("host"), req.uri,
                        req.headers.get("user-agent")))
   
   print(f"{len(requests)} HTTP requests\n")
   for ts, method, host, uri, ua in requests:
       print(f"{ts:.3f}  {method} http://{host}{uri}  UA={ua!r}")
   
   print("\nDistinct (host, path, user-agent):")
   for key, n in collections.Counter((h, u, a) for _, _, h, u, a in requests).items():
       print(f"  {n} x {key}")
   
   gaps = [b[0] - a[0] for a, b in zip(requests, requests[1:])]
   if gaps:
       print("\nInter-request gaps (s):", " ".join(f"{g:.2f}" for g in gaps))
       mean = statistics.mean(gaps)
       cv = statistics.pstdev(gaps) / mean * 100
       print(f"mean {mean:.2f} s, stdev {statistics.pstdev(gaps):.2f} s (variation {cv:.0f}% of mean)")

   .venv/bin/python extract_iocs.py beacon.pcap

   6 HTTP requests
   
   1790694614.524  GET http://updates.example.net/api/v1/checkin?id=LAB-0001  UA='LabAgent/1.0'
   1790694619.565  GET http://updates.example.net/api/v1/checkin?id=LAB-0001  UA='LabAgent/1.0'
   ...
   1790694639.749  GET http://updates.example.net/api/v1/checkin?id=LAB-0001  UA='LabAgent/1.0'
   
   Distinct (host, path, user-agent):
     6 x ('updates.example.net', '/api/v1/checkin?id=LAB-0001', 'LabAgent/1.0')
   
   Inter-request gaps (s): 5.04 5.39 4.80 5.11 4.88
   mean 5.05 s, stdev 0.20 s (variation 4% of mean)

   Vos écarts seront différents — la gigue est aléatoire — mais la moyenne doit se situer près de cinq secondes. Le fichier requests.jsonl côté serveur contient le même hôte, le même chemin et le même user-agent avec ses propres horodatages, une vérification croisée utile.

7. Vérifiez avec tshark si Wireshark est installé :

   tshark -r beacon.pcap -Y http.request -T fields -e frame.time_relative -e http.host -e http.request.uri -e http.user_agent

   0.000208000	updates.example.net	/api/v1/checkin?id=LAB-0001	LabAgent/1.0
   5.041049000	updates.example.net	/api/v1/checkin?id=LAB-0001	LabAgent/1.0
   ...
   25.225550000	updates.example.net	/api/v1/checkin?id=LAB-0001	LabAgent/1.0

8. Facultatif : voyez ce que cache le chiffrement. Démarrez un serveur TLS jetable avec un certificat auto-signé (openssl s_server -accept 127.0.0.1:8443 -www avec une clé et un certificat issus de openssl req -x509), capturez le port 8443, et connectez-vous une fois avec curl -k -A "LabAgent/1.0" et une fois avec un client Python ssl envoyant le même user-agent, tous deux avec le nom de serveur updates.example.net. Extrayez ensuite les champs du Client Hello :

   tshark -r tls.pcap -Y 'tls.handshake.type == 1' -T fields \
     -e tls.handshake.extensions_server_name -e tls.handshake.ja3 -e tls.handshake.ja4

   Sur la machine utilisée pour cette leçon (curl 8.7.1 sous macOS, et Python lié à OpenSSL 3.6) :

   updates.example.net	375c6162a492dfbf2795909110ce8424	t13d4907h2_0d8feac7bc37_7395dae3b2f3
   updates.example.net	f21f8e6cf70d5980ecfe9fa2e0ef401c	t13d171100_ab0a1bf427ad_8e6e362c5eac

   Le user-agent n’apparaît nulle part dans la capture — il a voyagé dans la session chiffrée — mais le SNI est en clair, et les deux clients ont des empreintes différentes : 49 suites proposées et ALPN HTTP/2 pour curl, 17 suites et pas d’ALPN pour Python.

Questions : Lesquels des IOC de l’étape 6 correspondraient encore si l’auteur ne changeait que le user-agent ? Que contiendrait la colonne des adresses IP de votre tableau d’IOC si ce beacon s’était exécuté dans le labo à deux VM avec INetSim, et pourquoi ne devez-vous pas la publier ? À l’étape 8, quels champs un capteur réseau verrait-il encore, et pourquoi un JA4 seul est-il une preuve faible que deux connexions proviennent du même malware ? Comment distingueriez-vous ce beacon d’un vérificateur de mises à jour légitime qui interroge lui aussi selon un minuteur ?

À retenir

• Un simulateur doit répondre à trois couches — DNS, transport et application — et chaque échec ou repli que montre l’échantillon est une preuve supplémentaire.
• Redirigez le DNS pour les domaines, et routez ou détournez le trafic pour les IP codées en dur ; INetSim sur une VM séparée est invisible pour l’échantillon, FakeNet-NG est pratique mais détectable.
• L’interception TLS ne fonctionne que si l’échantillon fait confiance à votre certificat ; pour un certificat épinglé ou une cryptographie maison, lisez plutôt le texte clair dans le processus.
• Capturez depuis l’extérieur de la VM d’analyse, puis lisez requêtes DNS, requêtes HTTP, en-têtes, écarts entre beacons et empreintes du Client Hello.
• Les adresses IP d’une capture simulée sont celles du simulateur ; la vraie infrastructure provient de la configuration et des sources passives.
• Ne laissez jamais un échantillon, ni vous-même, contacter la véritable infrastructure d’un attaquant depuis un réseau qui vous appartient.