Chapitre 2.4 Quiz - Analyse du trafic chiffre et inspection TLS

Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.

Question 1

Un chasseur de menaces remarque des connexions TLS sortantes regulieres depuis 192.168.5.44 vers une IP cloud toutes les 60 secondes. Le volume en octets par session est d'environ 1-2 Ko. Le ratio de gigue sur 120 sessions est de 0,025. Quelle est l'explication la plus probable, et quel champ du journal Zeek examineriez-vous en premier pour confirmer ?

Reveler la reponse

Reponse : Balise C2 (C2 beaconing)

Explication : La combinaison d'un intervalle regulier (60s), d'un faible volume en octets (enregistrement sans tache) et d'un ratio de gigue extremement bas (0,025 - timing quasi-machine) est la signature classique d'une balise C2. Le trafic genere par l'humain a des ratios de gigue superieurs a 0,5 ; les balises de logiciels malveillants sont souvent inferieures a 0,1.

Premier journal Zeek a examiner : conn.log - en particulier les champs ts (horodatage), id.orig_h, id.resp_h, duration, orig_bytes et resp_bytes. Triez par horodatage pour la paire source/destination et calculez les delais d'inter-arrivee.

cat conn.log | zeek-cut ts id.orig_h id.resp_h orig_bytes resp_bytes | \\
  awk '$2 == "192.168.5.44"' | sort -k1 | \\
  awk 'prev != "" { print $1 - prev, $0 } { prev=$1 }'

Suivi : Verifiez le hachage JA3 de ces sessions dans ssl.log et consultez les bases de donnees JA3 connus malveillants (flux ET JA3, abuse.ch). Verifiez egalement dans dns.log la resolution de l'IP de destination - les domaines generes par DGA ou enregistres recemment sont de forts indicateurs C2.

MITRE ATT&CK : T1071.001 (Protocole de couche application : protocoles Web), T1573.002 (Canal chiffre)

Question 2

Vous effectuez une inspection TLS sur un proxy d'entreprise. Un poste de travail envoie un ClientHello avec SNI=allowed-cdn.cloudflare.com, mais apres dechiffrement, vous observez que l'en-tete HTTP Host indique c2.malware-domain.ru. Quelle est cette technique d'attaque, et quel est le controle le plus fiable au niveau reseau pour l'empecher ?

Reveler la reponse

Reponse : Domain Fronting (MITRE ATT&CK T1090.004)

Explication : Le domain fronting abuse de la separation architecturale entre le routage TLS (SNI) et le routage HTTP (en-tete Host) sur l'infrastructure CDN. Le CDN accepte la connexion TLS basee sur le SNI (pointant vers un domaine legitime qu'il heberge), puis achemine la requete HTTP en fonction de l'en-tete Host (pointant vers l'origine de l'attaquant). Du point de vue du pare-feu, l'IP de destination appartient a Cloudflare et le SNI semble legitime.

Controles les plus fiables :

Inspection TLS - seul controle efficace qui expose la discordance entre l'en-tete Host et le SNI. Sans dechiffrement, vous ne voyez que le SNI.
Regle de correlation SNI/Host (apres dechiffrement) : alerter quand le SNI ne correspond pas a l'en-tete HTTP Host. A implementer dans un addon mitmproxy ou une regle Suricata.
Attenuation au niveau CDN - Cloudflare, Fastly et AWS CloudFront ont desactive le domain fronting pour la plupart des offres, mais cela reste possible sur certains CDN.

# Addon mitmproxy pour la detection
def request(self, flow):
    sni = flow.client_conn.tls_extensions.get("server_name","")
    host = flow.request.headers.get("host","")
    if sni and host and sni.lower() not in host.lower():
        # Bloquer ou alerter
        flow.response = mitmproxy.http.Response.make(
            403, b"Domain fronting bloque", {"Content-Type": "text/plain"})

Note defensive : Le filtrage au niveau DNS peut partiellement attenuer cela en bloquant le type d'enregistrement DNS HTTPS, ce qui empeche la recuperation de la cle ECH - mais ne previent pas le domain fronting basique.

Question 3

Vous disposez d'un PCAP d'une session TLS 1.2 ou le serveur a utilise le chiffrement ECDHE-RSA-AES256-GCM-SHA384. Vous avez la cle privee RSA du serveur. Pouvez-vous dechiffrer la session ? Expliquez pourquoi ou pourquoi pas, et quel artefact vous serait necessaire a la place.

Reveler la reponse

Reponse : Non - car ECDHE fournit la confidentialite de transmission parfaite (Perfect Forward Secrecy).

Explication : Dans les suites de chiffrement commencant par ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), la cle de session est derivee de materiel de cle DH ephemere genere a nouveau pour chaque session. La cle privee RSA du serveur n'est utilisee que pour authentifier l'echange de cles DH (signer la cle publique DH ephemere du serveur), pas pour chiffrer le secret pre-maitre. Par consequent :

Posseder la cle privee RSA du serveur ne revele rien sur la cle de session
Meme en capturant la poignee de main, le secret pre-maitre n'a jamais ete transmis chiffre sous la cle RSA - il a ete calcule independamment par les deux parties a partir de l'echange DH
Compromettre la cle RSA apres la session ne sert a rien ; les cles DH ephemeres ont ete supprimees apres la poignee de main

Ce dont vous avez besoin a la place :

Sortie SSLKEYLOGFILE du client ou du serveur au moment de la session - enregistre le secret maitre specifique a la session
Forensique memoire de l'endpoint - extraction de la cle de session depuis l'espace memoire du processus pendant la session

# Confirmer la suite de chiffrement dans la capture
tshark -r capture.pcap \\
  -Y 'tls.handshake.type == 2' \\
  -T fields -e tls.handshake.ciphersuite

# 0xC030 = TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - PFS - cle privee inutile

# Si vous disposiez du SSLKEYLOGFILE :
tshark -r capture.pcap \\
  -o "tls.keylog_file:/tmp/session_keys.log" \\
  -Y http -T fields -e http.request.uri

Contexte MITRE ATT&CK : La confidentialite de transmission parfaite (T1573.002) est explicitement privilegiee par les acteurs sophistiques precisement parce qu'elle empeche le dechiffrement retrospectif meme si le serveur est ulterivement compromise.

Question 4

Une regle Suricata se declenche sur un hachage JA3 correspondant a un profil par defaut connu de Cobalt Strike. L'analyste SOC rejette l'alerte comme un faux positif parce que le domaine de destination dispose d'un certificat Let's Encrypt valide et se resout vers un CDN majeur. Pourquoi l'analyste pourrait-il avoir tort, et quels trois points de donnees supplementaires devraient etre collectes avant de fermer l'alerte ?

Reveler la reponse

Reponse : L'analyste confond la legitimite du certificat avec la legitimite du trafic.

Explication : Un certificat Let's Encrypt valide prouve uniquement que le proprietaire du domaine a complete un challenge DNS ou HTTP au moment de l'emission - il ne dit rien sur le but du serveur. Let's Encrypt est gratuit, automatise, et emet des certificats pour des infrastructures malveillantes en permanence. L'hebergement CDN est egalement neutre - les attaquants utilisent couramment AWS CloudFront, Azure CDN et Cloudflare pour heberger l'infrastructure C2, gagnant ainsi une couverture de reputation et une distribution geographique.

La correspondance JA3 est une preuve de la configuration de la bibliotheque TLS du client correspondant a un profil connu malveillant. Cela est independant de ce qu'est le serveur.

Trois points de donnees supplementaires a collecter :

Modele de balise - Interroger conn.log pour l'historique des connexions de l'IP source vers cette destination. Intervalle regulier + faible gigue + petit volume en octets = balise.
```
cat conn.log | zeek-cut ts id.orig_h id.resp_h orig_bytes | \\
  awk '$2 == "ALERT_SRC_IP" && $3 == "ALERT_DST_IP"' | sort -k1
```
Processus responsable de la connexion - Correlater l'horodatage de l'alerte avec la telemetrie EDR/endpoint. Quel processus a ouvert la connexion TLS ? cmd.exe, powershell.exe ou svchost.exe effectuant des connexions TLS est tres suspect.
Empreinte JARM du serveur - Analyser activement l'empreinte de la pile TLS du serveur de destination et la comparer aux hachages JARM connus des Team Servers Cobalt Strike. Un CDN servant du contenu legitime n'aura pas un JARM de CS Team Server.
```
python3 jarm.py destination-domain.com -p 443
# Comparer la sortie avec : 2ad2ad0002ad2ad00042d42d000000ad9bf51cc3f5a1e29eecb81d0c7b06eb
```

MITRE ATT&CK : T1071.001, T1090.004, T1583.004 (Acquerir de l'infrastructure : Serveur)

Fin du Quiz 2.4 - Analyse du trafic chiffre et inspection TLS