TP 5 - Downgrade PQC (forensic réseau SATCOM)

2h30 Acte 3 · Audit Expert Forensic réseau · Crypto · PQC · MitM

Position : Acte 3 — module forensic (amorce Acte 4). Analyse de log obligatoire, PCAP en bonus. Artefacts : ssl.log (Zeek, obligatoire) · arp.log (Zeek, obligatoire) · capture PCAP (bonus, fournie par l’enseignant).

---

1. Objectifs et contexte

🎯 Objectif métier — repérer une attaque qui ne casse rien visiblement : la liaison reste « chiffrée » et valide, mais l’attaquant a discrètement affaibli la cryptographie pour pouvoir déchiffrer plus tard.

Pourquoi ça concerne les TAAF

L’uplink satellite (SATCOM) des bases est facile à intercepter (RF en clair sur le segment radio) et les données scientifiques/classifiées ont une longue durée de vie (décennies). C’est le terrain idéal du « Harvest Now, Decrypt Later » (HNDL) : capter aujourd’hui du trafic chiffré classique, le stocker, et le déchiffrer plus tard avec un calculateur quantique. D’où l’usage de cryptographie post-quantique (PQC) sur le lien — concrètement X25519MLKEM768 (X25519 + ML-KEM-768, codepoint TLS 0x11EC).

🔴 Au fil de l’enquête

Étape Defense Evasion du jour J à 10h14 (heure locale) : l’attaquant downgrade le KEM de la liaison SATCOM. Le but n’est pas d’exfiltrer les données génétiques (cette sortie-là sera bloquée au pare-feu, temps 8) — c’est du HNDL (Harvest Now, Decrypt Later) : affaiblir le chiffrement pour que le trafic satellite intercepté aujourd’hui reste déchiffrable demain. C’est le pendant « réseau » de l’intrusion vue au TP4 (LotL Windows).

Rigueur cryptographique (à ne pas se tromper)

• On downgrade le groupe d’échange de clés (KEM), pas la signature du certificat.
• X25519MLKEM768 = hybride post-quantique (codepoint 0x11EC). x25519 = classique (0x001D).
• L’authentification (certificat RSA-2048) reste inchangée : ce n’est PAS l’axe attaqué.
• La protection anti-downgrade de TLS 1.3 ne couvre que la version, pas le choix de groupe → l’attaque est réaliste et non détectée par TLS lui-même.
• Risque réel : perte de confidentialité post-quantique (HNDL), pas une rupture immédiate.

Architecture du TP

graph LR
 subgraph "Topologie SATCOM"
 ANT[Antenne SATCOM<br/>TAAF-SATCOM-GW-PAF<br/>10.60.20.1<br/>client TLS]
 TEL[Serveur télémétrie<br/>TAAF-TELEMETRY-PAF<br/>10.60.20.10:443]
 ATT[Attaquant MitM<br/>10.60.30.66]
 end

 subgraph "Capture"
 ZEEK[Zeek monitor<br/>span port]
 SSL[/ssl.log/]
 ARP[/arp.log/]
 end

 subgraph "Investigation"
 LOKI[(Loki)]
 GRAFANA[Grafana Explore]
 PCAP[(PCAP — bonus)]
 WS[Wireshark]
 end

 ANT -.->|ARP empoisonné| ATT
 ATT -.->|relay + modif ClientHello| TEL
 ZEEK -->|capture| SSL
 ZEEK -->|capture| ARP
 SSL --> LOKI
 ARP --> LOKI
 LOKI --> GRAFANA
 PCAP --> WS

 classDef bad fill:#ff9999,stroke:#333,stroke-width:2px
 classDef good fill:#99ff99,stroke:#333,stroke-width:2px
 classDef neutral fill:#ffcc99,stroke:#333,stroke-width:2px

 class ATT bad
 class ANT,TEL,SSL,ARP good
 class ZEEK,LOKI,GRAFANA neutral

---

2. Prérequis & données

Récupérer les artefacts

Les logs du scénario sont générés puis ingérés dans Loki par la stack monitoring (Alloy) :

# Sur la VM monitoring
cd ~/monitoring
./regen-logs.sh 2026-A    # SEED=2026-A pour la cohérence promo

→ Les fichiers atterrissent dans ~/data/_scenario/generated/ :

ls -la ~/data/_scenario/generated/{ssl,arp,conn}.log
# -rw-r--r--  ssl.log    (Zeek — sessions TLS antenne ↔ télémétrie)
# -rw-r--r--  arp.log    (Zeek — trafic ARP du segment SATCOM)
# -rw-r--r--  conn.log   (Zeek — connexions, pour le contexte)

Format du ssl.log Zeek (rappel)

Format TSV (tab-separated) avec header #fields :

#fields ts  uid                 id.orig_h   id.orig_p  id.resp_h    id.resp_p  version  cipher                  curve           server_name                   resumed  established  validation_status
...111.42  Cv5tlRe5bqkj6V0Sbg  10.60.20.1  48688      10.60.20.10  443        TLSv13   TLS_AES_256_GCM_SHA384  X25519MLKEM768  telemetry.univ-taaf.internal  F        T            ok
...270.00  C3cfsATGvmuo17K8gd  10.60.20.1  48214      10.60.20.10  443        TLSv13   TLS_AES_256_GCM_SHA384  x25519          telemetry.univ-taaf.internal  F        T            ok
...486.56  CA9BMHHOKcvRFBFpdB  10.60.20.1  48682      10.60.20.10  443        TLSv13   TLS_AES_256_GCM_SHA384  X25519MLKEM768  telemetry.univ-taaf.internal  F        T            ok

→ La 2ᵉ ligne de cet extrait a un curve anormal. C’est elle qu’on cherche.

---

3. Étape 1 — Comprendre la topologie

Hôte	IP	Rôle
Antenne/modem SATCOM (TAAF-SATCOM-GW-PAF)	10.60.20.1	Client TLS, transmet la télémétrie
Serveur télémétrie (TAAF-TELEMETRY-PAF)	10.60.20.10:443	Reçoit + chiffre + stocke
Attaquant	10.60.30.66	Poste pivot interne de la zone postes, compromis pendant la phase LotL (TP4)
Zeek monitor	—	Capture sur le span port du switch

L’attaquant fait un ARP spoofing (MitM) :

• Il dit à l’antenne : “je suis le serveur télémétrie (MAC=ma_MAC)”.
• Il dit au serveur télémétrie : “je suis l’antenne (MAC=ma_MAC)”.
• Le trafic passe par lui dans les deux sens — il peut le modifier en vol.

⚠️ Point crucial : l’attaquant n’apparaît PAS dans le ssl.log. Zeek voit le TLS handshake entre les IP réelles (antenne ↔ serveur), pas le MitM. Pour le retrouver, il faut le arp.log.

---

4. Étape 2 — Détecter le downgrade dans ssl.log

4.1 — Voie A — Grafana / Loki (LogQL)

Ouvrez Grafana → Explore → datasource Loki.

{log="ssl"} | logfmt | curve!="X25519MLKEM768"

Résultat attendu : une seule ligne (au moins) avec curve=x25519 autour de 10:14:30 (heure Réunion) le jour de l’incident.

ts=...270.000000 uid=C3cfsATGvmuo17K8gd id.orig_h=10.60.20.1 id.orig_p=48214 id.resp_h=10.60.20.10 id.resp_p=443 version=TLSv13 cipher=TLS_AES_256_GCM_SHA384 curve=x25519 server_name=telemetry.univ-taaf.internal validation_status=ok

📸 Capture obligatoire #1 : Grafana Explore montrant la ligne x25519 isolée.

4.2 — Voie B — CLI directe sur le fichier brut

awk -F'\t' '$1!~/^#/ && $9!="X25519MLKEM768" {print}' \
  ~/data/_scenario/generated/ssl.log

Sortie attendue :

...270.000000  C3cfsATGvmuo17K8gd  10.60.20.1  48214  10.60.20.10  443  TLSv13  TLS_AES_256_GCM_SHA384  x25519  telemetry.univ-taaf.internal  F  T  ok

4.3 — Convertir le timestamp en heure lisible

date -u -d @VOTRE_EPOCH  # Linux
date -u -r VOTRE_EPOCH   # macOS

Fuseau horaire — le piège classique du forensic

date -u affiche l’heure UTC. Les timestamps du scénario sont calés sur l’heure de La Réunion (UTC+4) : le handshake downgradé tombe à 06:14:30 UTC, soit 10:14:30 heure locale. Notez toujours le fuseau dans une fiche forensic.

→ L’attaque a eu lieu à 10:14:30 (heure Réunion) le jour de l’incident, sur le couple 10.60.20.1 (antenne) ↔ 10.60.20.10 (télémétrie).

4.4 — Analyser la trame TLS

Champ	Valeur normale	Valeur attaquée	Lecture
version	TLSv13	TLSv13	✓ identique
cipher	TLS_AES_256_GCM_SHA384	TLS_AES_256_GCM_SHA384	✓ identique
curve	X25519MLKEM768	x25519	⚠️ downgrade KEM
validation_status	ok	ok	✓ certificat inchangé, chaîne valide

Lecture critique :

• Aucune erreur TLS — la session est valide d’un point de vue protocole.
• Le certificat n’est pas falsifié — donc pas d’alerte type “untrusted CA”.
• Seul le groupe d’échange a changé. Sans alerte sur ce champ, rien ne tombe.

---

5. Étape 3 — Identifier le MitM dans arp.log

Le ssl.log ne suffit pas à pointer l’attaquant. Il faut le arp.log pour voir l’empoisonnement.

5.1 — Format du arp.log Zeek

#fields ts  operation  src_mac            src_ip       dst_mac            dst_ip       note
...910.00  reply      50:5f:69:30:86:a7  10.60.20.1   8a:60:b3:37:22:02  10.60.20.10  normal
...910.00  reply      f1:d4:6d:d8:24:54  10.60.20.1   ff:ff:ff:ff:ff:ff  10.60.20.1   SPOOF gratuitous-arp from 10.60.30.66
...910.00  reply      f1:d4:6d:d8:24:54  10.60.20.10  ff:ff:ff:ff:ff:ff  10.60.20.10  SPOOF gratuitous-arp from 10.60.30.66

→ Les lignes marquées SPOOF sont des ARP reply gratuits (non sollicités, en broadcast) : la même MAC f1:d4:6d:d8:24:54 se prétend être à la fois l’antenne (10.60.20.1) et le serveur télémétrie (10.60.20.10). Voilà notre MitM.

5.2 — Voie A — LogQL

{log="arp"} | logfmt | note=~".*SPOOF.*"

Résultat attendu : une douzaine de lignes (le spoof est ré-annoncé toutes les ~60 s) avec src_mac=f1:d4:6d:d8:24:54 qui usurpe alternativement les deux IP du couple antenne ↔ télémétrie.

5.3 — Voie B — CLI

awk -F'\t' '$1!~/^#/ && $7~/SPOOF/' ~/data/_scenario/generated/arp.log

5.4 — Retrouver l’IP réelle de l’attaquant

Le monitor Zeek a résolu la MAC usurpatrice vers son bail légitime : la note porte l’IP réelle du pivot.

awk -F'\t' '$1!~/^#/ && $7~/SPOOF/ {print $7}' ~/data/_scenario/generated/arp.log | sort -u

Sortie attendue :

SPOOF gratuitous-arp from 10.60.30.66

→ L’attaquant est 10.60.30.66 — un poste de la zone postes (10.60.30.0/24), donc un pivot interne : cohérent avec la kill chain du TP4 (l’attaquant est déjà dans le SI au moment du downgrade). Vérifiez au passage que cette IP n’apparaît jamais dans ssl.log : le MitM est transparent pour TLS.

📸 Capture obligatoire #2 : Grafana Explore avec les lignes SPOOF du arp.log + l’IP attaquant identifiée.

---

6. Étape 4 — Reconstituer la chronologie

Tableau attendu (livrable) :

Heure (Réunion)	Source	Événement	Lecture
10:08:30	arp.log	ARP SPOOF antenne (10.60.20.1)	MitM démarre — phase 1
10:08:30	arp.log	ARP SPOOF télémétrie (10.60.20.10)	MitM démarre — phase 2
10:09:30…	arp.log	SPOOF ré-annoncé toutes les ~60 s	Le poison est entretenu
10:14:30	ssl.log	TLS 1.3 handshake, curve=x25519	Downgrade effectif

Lecture critique : l’ARP spoof précède le downgrade de ~6 minutes — c’est la fenêtre de pré-positionnement, entretenue par des annonces gratuites périodiques. Toute session entre antenne et télémétrie est interceptée tant que le spoof tient.

---

7. Étape 5 — Bonus : Analyse PCAP

7.1 — Filtrer la session downgradée

tshark -r ~/data/_scenario/generated/downgrade.pcap \
  -Y "ssl.handshake.type==1 && ssl.handshake.extension.type==51" \
  -V | less

L’extension 51 = key_share. Vous cherchez :

• Un ClientHello normal : key_share contient X25519MLKEM768.
• Un ClientHello downgradé : key_share ne contient que x25519.

7.2 — Comparer les extensions supported_groups

tshark -r downgrade.pcap \
  -Y "ssl.handshake.type==1" \
  -T fields -e tcp.stream -e ssl.handshake.extensions_supported_group

Sortie attendue (extrait) :

0    0x11ec, 0x001d, 0x0017   <- ClientHello normal (PQ + x25519 + autres)
1    0x11ec, 0x001d, 0x0017
2    0x001d, 0x0017             <- ClientHello downgradé (PQ retiré !)
3    0x11ec, 0x001d, 0x0017

→ Pour la session tcp.stream=2, l’attaquant a modifié le ClientHello en vol pour retirer 0x11EC (le groupe PQ) de supported_groups. Le serveur n’a plus le choix : il négocie 0x001D (x25519).

📸 Capture obligatoire #3 (bonus) : Wireshark montrant les deux ClientHello côte à côte, avec l’extension supported_groups mise en évidence.

---

8. Étape 6 — Detection-as-Code

Ajoutez à votre repo taaf-detections la règle Sigma :

rules/credential_access/satcom-pqc-downgrade.yml :

title: SATCOM TLS — Post-Quantum KEM Downgrade
id: 8e9f0a1b-2c3d-4e5f-6a7b-8c9d0e1f2a3b
status: stable
description: |
  Détecte une session TLS 1.3 vers le serveur de télémétrie SATCOM
  qui n'utilise PAS le groupe post-quantique X25519MLKEM768 attendu.
  Indique un downgrade KEM (T1600) probablement causé par un MitM.
references:
  - https://attack.mitre.org/techniques/T1600/
  - https://attack.mitre.org/techniques/T1557/002/
author: TAAF SOC
date: 2026/06/17
logsource:
  product: zeek
  service: ssl
detection:
  selection:
    id.resp_h: '10.60.20.10'
    id.resp_p: 443
    version: 'TLSv13'
  filter_pqc:
    curve: 'X25519MLKEM768'
  condition: selection and not filter_pqc
fields:
  - ts
  - uid
  - id.orig_h
  - id.resp_h
  - curve
  - server_name
falsepositives:
  - Client legacy qui ne supporte pas encore X25519MLKEM768 — doit être whitelisté explicitement
level: critical
tags:
  - attack.credential_access
  - attack.t1557.002
  - attack.defense_evasion
  - attack.t1600

Compilez :

cd ~/taaf-detections
./scripts/compile.sh

LogQL générée :

{job="zeek_ssl"} | logfmt | id_resp_h=`10.60.20.10` | id_resp_p=`443` | version=`TLSv13` | curve!=`X25519MLKEM768`

Et la règle complémentaire rules/credential_access/arp-spoofing.yml :

title: ARP Spoofing on SATCOM Segment
id: 9f0a1b2c-3d4e-5f6a-7b8c-9d0e1f2a3b4c
status: stable
description: |
  Détecte un ARP reply non sollicité (note SPOOF du monitor Zeek) sur le
  segment SATCOM (10.60.20.0/24). Précurseur classique d'un MitM.
references:
  - https://attack.mitre.org/techniques/T1557/002/
author: TAAF SOC
date: 2026/06/17
logsource:
  product: zeek
  service: arp
detection:
  selection:
    note|contains: 'SPOOF'
    src_ip|startswith: '10.60.20.'
  condition: selection
fields:
  - ts
  - src_mac
  - src_ip
  - dst_ip
  - note
level: high
tags:
  - attack.credential_access
  - attack.t1557.002

---

9. Étape 7 — Remédiation PQC-only

9.1 — Politique côté serveur télémétrie

Sur le serveur télémétrie (10.60.20.10), forcer PQC-only en refusant les groupes classiques :

# Exemple OpenSSL config (ssl.cnf)
[default_tls_ctx]
Groups = X25519MLKEM768            # <-- SEUL groupe accepté
# Au lieu de l'ancien :
# Groups = X25519MLKEM768:x25519:secp256r1

Conséquence : un client qui ne supporte pas X25519MLKEM768 voit son handshake échouer (handshake failure). C’est volontaire — l’absence de fallback est précisément ce qui empêche le downgrade.

Coût opérationnel : tous les clients doivent supporter PQ. Inventoriez les modems SATCOM, les versions logicielles, etc. Sur lien contraint, prévoyez une fenêtre de migration où PQC-only est appliqué après test.

9.2 — Intégrité ARP (Dynamic ARP Inspection — DAI)

Sur le switch du segment SATCOM (10.60.20.0/24), activer DAI :

! Cisco IOS exemple
ip arp inspection vlan 20
ip arp inspection validate src-mac dst-mac ip
interface range Gi0/1 - 23
  ip arp inspection trust   ! pour les ports vers les vrais hosts
interface Gi0/24
  ip arp inspection limit rate 10   ! rate-limit pour les ports user

→ Tout ARP reply qui ne correspond pas au binding DHCP snooping est droppé. Le MitM jour J aurait été tué dès la première trame SPOOF.

9.3 — Pinning du groupe côté client

Sur le modem SATCOM, si possible, pin le groupe attendu :

# Exemple config NGINX-style
ssl_ecdh_curve X25519MLKEM768;
ssl_protocols TLSv1.3;

9.4 — Lien avec l’Acte 2 (LDAP clair)

Ce TP a la même morale que le TP SSO AD↔NextCloud : la confidentialité du transport doit être imposée par défaut, pas optionnelle.

• LDAP clair (port 389) → LDAPS (port 636) → traité au TP PingCastle
• TLS 1.3 avec fallback x25519 → TLS 1.3 PQC-only → traité ici

→ Recommandation transversale pour le rapport d’audit IA : « toute transition de canal cryptographique doit refuser le fallback ».

---

10. Livrables & validation

Livrables

1. Fiche forensic (1 page) contenant :
   • Heure UTC du downgrade
   • Couple d’IP affecté (antenne + télémétrie)
   • IP réelle de l’attaquant (via arp.log)
   • uid Zeek + preuve curve=x25519
2. Explication de l’attaque : ARP spoof → suppression du key_share PQ → fallback.
3. Pourquoi TLS 1.3 ne l’a pas détecté + pourquoi le cert RSA n’est pas l’axe attaqué.
4. 2 règles Sigma (downgrade KEM + ARP spoof) dans le repo taaf-detections.
5. Plan de remédiation PQC-only + DAI + pinning.
6. (Bonus) Capture PCAP annotée des deux ClientHello.

Grille de validation

Critère	Pondération
Détection du downgrade dans ssl.log (LogQL + CLI)	15 %
Conversion timestamp epoch → UTC correcte	5 %
Identification IP attaquant via corrélation arp.log	20 %
Chronologie ARP spoof → downgrade reconstituée	15 %
Explication crypto rigoureuse (KEM vs cert, anti-downgrade TLS)	15 %
2 règles Sigma compilables et déployables	15 %
Plan de remédiation PQC-only avec coût opérationnel discuté	15 %
(Bonus) Analyse PCAP des deux ClientHello	+10 % bonus

Format de rendu : PDF nom-prenom-promo.pdf sur Moodle.

---

11. Annexe enseignant — corrigé

Réponses attendues aux questions de validation

1. Champ trahissant : curve (groupe d’échange de clés). Valeur anormale : x25519. Valeur attendue : X25519MLKEM768.

2. Heure : 10:14:30 heure Réunion, soit 06:14:30 UTC (conversion de l’epoch par date -u -d @EPOCH ; attendre la mention explicite du fuseau UTC+4 dans la fiche).

3. Couple IP : id.orig_h=10.60.20.1 (antenne SATCOM, client TLS) ↔ id.resp_h=10.60.20.10 (serveur télémétrie, port 443).

4. IP attaquant : 10.60.30.66. Pas dans ssl.log car l’attaquant est un MitM transparent — Zeek voit le handshake entre les IP réelles. À trouver dans arp.log via les lignes SPOOF (la même MAC se prétend à la fois antenne et serveur ; la note du monitor porte l’IP réelle du pivot).

5. Chronologie : ARP spoof à partir de 10:08:30 (~6 min avant le downgrade), gratuitous ARP ré-annoncé toutes les ~60 s → handshake downgradé à 10:14:30. L’ARP spoof est un pré-positionnement nécessaire pour intercepter et modifier le ClientHello.

6. Downgrade du KEM (X25519MLKEM768 → x25519), pas de la signature. Distinction critique : la signature RSA reste valide → le certificat est authentique → aucune alerte « cert untrusted ». Seul le KEM tombe, ce qui n’est pas surveillé par défaut par les outils standards.

7. Certificat RSA valide : l’attaquant ne substitue pas le cert — il le laisse passer. Il modifie uniquement les extensions du ClientHello (supported_groups, key_share). Le serveur signe son handshake avec sa vraie clé privée, la signature est vérifiable par le client → tout est « ok » du point de vue du cert.

8. TLS 1.3 anti-downgrade = version uniquement : la sentinelle DOWNGRD\x01 dans ServerHello.random empêche un attaquant de forcer TLS 1.2. Mais elle ne protège pas le choix des supported_groups ou cipher_suites. C’est un trou documenté du protocole.

9. HNDL TAAF : le segment radio SATCOM est physiquement interceptable (n’importe qui avec un récepteur peut capter). Aujourd’hui, x25519 est solide. Mais quand un calculateur quantique avec ~4000 qubits logiques existera (estimation 2030-2040 selon NIST), tout ce trafic capté pourra être déchiffré rétroactivement. Les données scientifiques TAAF (échantillons génétiques, données climatiques) ont une valeur à long terme → le risque est réel.

10. Règle LogQL : {job="zeek_ssl"} | logfmt | id_resp_h="10.60.20.10" | id_resp_p="443" | version="TLSv13" | curve!="X25519MLKEM768". Politique serveur : refuser le fallback (PQC-only). Coût opérationnel : tous les clients doivent supporter PQ (inventaire à faire), fenêtre de migration coordonnée, plan de rollback si problème.

Erreurs courantes à pénaliser

• Confondre downgrade KEM et substitution de cert → -10 % (incompréhension du protocole).
• Conclure que TLS 1.3 est cassé → -5 % (TLS 1.3 fait ce qu’il promet : protéger la version, pas tous les paramètres).
• Donner l’IP attaquant comme l’IP source du ssl.log (10.60.20.1) → -15 % (faute majeure de lecture du log — c’est la victime, pas l’attaquant).
• Pas de corrélation ssl.log ↔ arp.log → -10 % (le forensic croise les sources, ne reste pas mono-source).
• Pas de coût opérationnel discuté pour PQC-only → -5 % (manque la lucidité d’ingénieur).

Pont vers le rapport d’audit

Le findings de ce TP alimente le rapport final (tp-rapport-audit-ia) :

• Constat : la liaison SATCOM a été downgradée KEM ; HNDL probable sur le trafic satellite intercepté (distinct de l’exfiltration des données génétiques, elle bloquée au pare-feu).
• Recommandation : politique PQC-only + DAI sur segment SATCOM + supervision du champ curve dans le SIEM.
• Priorité : 🟠 (l’incident est dans le passé mais le HNDL reste, non rattrapable).

---

Mapping MITRE ATT&CK / référentiels

Élément	Référence
ARP spoofing / interception	T1557.002 (Adversary-in-the-Middle: ARP Cache Poisoning)
Affaiblissement du chiffrement	T1600 (Weaken Encryption), T1562 (Impair Defenses)
Cadre PQC	Recommandations ANSSI sur la transition post-quantique · NIST FIPS 203 (ML-KEM)
Réglementation	NIS 2 Art. 21 §2.h (politique crypto) · IGI 1337 chap. III (chiffrement)

Convergence : avec le vol DB (TP4) et la phase LotL, ce downgrade complète la kill chain. Toutes les preuves alimentent le rapport d’audit final.

---

Références

• RFC 8446 — TLS 1.3
• Draft-ietf-tls-hybrid-design — X25519MLKEM768
• NIST FIPS 203 — ML-KEM
• ANSSI — Plan PQC
• Zeek — ssl.log fields
• Dynamic ARP Inspection — Cisco