Chapitre 2.3 Quiz - Analyse forensique reseau et analyse des journaux

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

Question 1

Lors d'un incident, vous decouvrez que la premiere alerte IDS s'est declenchee a 14:32:15 UTC. En examinant les donnees NetFlow, vous trouvez un transfert sortant de 4,2 Mo depuis l'hote compromis vers une IP externe a 14:47:12 UTC. Mais le fichier Zeek http.log montre une requete HTTP initiale vers une URL de distribution de malware a 14:15:01 UTC, soit 17 minutes avant l'alerte IDS. Que signifie cet ecart dans la chronologie, et quelle est la signification forensique ?

Reveler la reponse et l'explication

Reponse : L'ecart de 17 minutes indique que l'alerte IDS ne s'est pas declenchee lors de la compromission initiale - elle s'est declenchee plus tard, probablement sur un comportement secondaire (par ex. pattern de balise C2, signature connue dans le trafic de l'implant). Le vecteur d'infection initial etait deja complet avant la detection.

Signification forensique :

Le temps de presence commence a 14:15:01, pas a 14:32:15. Le vrai temps de presence est 17 minutes plus long que ce que l'alerte IDS suggere. Cela compte pour l'evaluation de la portee - qu'a fait l'attaquant pendant ces 17 minutes ?
La signature IDS a rate le telechargement initial. C'est une lacune de detection. Le telechargement du malware n'a declenche aucune alerte, ce qui suggere que le payload etait obscurci, livre via HTTPS (payload chiffre), ou qu'il n'existait pas de signature correspondante.
La portee de l'investigation s'elargit. Toutes les actions que l'attaquant a entreprises entre 14:15:01 et 14:32:15 - collecte d'identifiants, enumeration de l'hote, mecanismes de persistance - doivent etre reconstruites depuis des sources non-IDS (Zeek conn.log, journaux proxy, journaux d'endpoint).

Reconstruction de l'ecart :

# Extraire tous les evenements Zeek depuis l'hote compromis entre 14:15 et 14:32
cat conn.log dns.log http.log \
  | zeek-cut ts id.orig_h id.resp_h \
  | awk '$1 >= 1700057701 && $1 <= 1700058735 && $2 == "192.168.1.55"' \
  | sort -k1

C'est pourquoi la correlation de journaux multi-sources est obligatoire - les horodatages des alertes IDS ne sont pas le debut de l'histoire. Dans ce cas, le journal proxy a fourni le vrai T0. (T1566.001, T1071.001)

Question 2

Vous analysez le fichier Zeek conn.log et remarquez que l'hote 192.168.4.12 a etabli 847 connexions vers 203.0.113.77:443 au cours des 12 dernieres heures, avec un intervalle moyen de 60,3 secondes et un coefficient de variation de 0,04. Qu'est-ce que cela indique, et quelles mesures d'investigation de suivi prendriez-vous ?

Reveler la reponse et l'explication

Reponse : Un CV de 0,04 est extremement faible - periodicite quasi parfaite. La navigation humaine produit des intervalles avec un CV > 1,0 ; les minuteries logicielles automatisees produisent un CV approchant 0,0. Il s'agit d'une signature de balise forte, coherente avec un enregistrement d'implant C2 (T1071.001).

L'intervalle de 60 secondes est le temps de sommeil de balise Cobalt Strike par defaut. Combine avec le port 443, il s'agit d'un indicateur Cobalt Strike a haute confiance.

Etapes d'investigation de suivi :

Verifier le certificat TLS pour la destination :

cat ssl.log \
  | zeek-cut ts id.orig_h id.resp_h server_name subject issuer validation_status ja3 \
  | awk '$2 == "192.168.4.12" && $3 == "203.0.113.77"'
# Rechercher : auto-signe, SNI non correspondant, validite courte, JA3 correspondant au profil CS connu

Verifier JA3 avec le renseignement sur les menaces :

# JA3 Cobalt Strike par defaut connu : 51c64c77e60f3980eea90869b68c58a8
# CS avec des profils malleables specifiques sera different
cat ssl.log | zeek-cut ja3 | sort | uniq -c | sort -rn

Verifier le telechargement du dropper initial avant le debut de la balise :

# Qu'a telecharge 192.168.4.12 dans l'heure avant le debut de la balise ?
cat http.log \
  | zeek-cut ts id.orig_h method host uri resp_body_len \
  | awk '$2 == "192.168.4.12" && $6 > 50000'

Verifier les mouvements lateraux depuis cet hote :

# 192.168.4.12 a-t-il etabli des connexions SMB (445) ou WinRM (5985) vers d'autres hotes internes ?
cat conn.log \
  | zeek-cut ts id.orig_h id.resp_h id.resp_p orig_bytes \
  | awk '$2 == "192.168.4.12" && ($4 == "445" || $4 == "5985") && $3 ~ /^192\.168/'

Calculer l'asymetrie en octets : Les sessions C2 Cobalt Strike montrent typiquement de petits telechargements (commandes) et des reponses variables. Tres peu d'octets orig_bytes avec des resp_bytes moderes par session est coherent.
Isoler l'hote et declencer la reponse aux incidents. Ne pas bloquer immediatement le canal C2 - surveiller pendant une periode controlee pour comprendre l'etendue complete de la compromission avant de couper le canal (couper le C2 supprime la visibilite sur les actions de l'attaquant).

Question 3

Un analyste exporte le journal des evenements de securite Windows et trouve des evenements 4624 (LogonType 3) depuis WKSTN-047 s'authentifiant vers 14 hotes internes differents en 4 minutes a 02h17, en utilisant le compte corp\svcbackup. Aucun evenement 4768 (Kerberos TGT) n'existe pour ce compte dans la meme fenetre, mais des evenements 4776 (validation d'identification NTLM) sont presents. Quelle technique d'attaque cela represente-t-il ? Quels identifiants MITRE ATT&CK s'appliquent, et quelles entrees de journal chercheriez-vous pour confirmer ?

Reveler la reponse et l'explication

Reponse : Il s'agit de Pass-the-Hash (PtH) - T1550.002. L'attaquant a extrait le hachage NTLM de corp\svcbackup depuis la memoire (probablement via Mimikatz/extraction lsass) et le rejoue directement pour l'authentification reseau.

Pourquoi l'absence de 4768 est l'indicateur cle :

Kerberos (le chemin d'authentification Windows normal) necessite la demande d'un TGT (4768) avant tout acces aux ressources
L'authentification NTLM (4776) n'utilise pas Kerberos - c'est un challenge-reponse utilisant directement le hachage du mot de passe
Une ouverture de session reseau reussie (4624 Type 3) utilisant NTLM (4776) sans 4768 prealable depuis le meme compte = le hachage du compte a ete utilise sans le mot de passe en clair

Identifiants ATT&CK :

T1003.001 - Extraction d'identifiants OS : Memoire LSASS (comment le hachage a ete obtenu)
T1550.002 - Utilisation de materiaux d'authentification alternatifs : Pass the Hash (la technique ici)
T1021.002 - Services distants : Partages SMB/Windows Admin (la methode de mouvement lateral)

Requetes de confirmation :

# Trouver les evenements 4776 pour svcbackup sans 4768 correspondant
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4776; StartTime=(Get-Date).AddHours(-1)} |
  Where-Object { $_.Properties[1].Value -eq 'svcbackup' } |
  Select-Object TimeCreated, @{N='Compte';E={$_.Properties[1].Value}},
                             @{N='Poste';E={$_.Properties[2].Value}},
                             @{N='CodeErreur';E={$_.Properties[3].Value}}

# Trouver les evenements 4624 Type 3 pour svcbackup
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object { $_.Properties[5].Value -eq 'svcbackup' -and $_.Properties[8].Value -eq 3 } |
  Select-Object TimeCreated, @{N='IPSrc';E={$_.Properties[18].Value}}

# Confirmer l'absence de TGT Kerberos emis pour svcbackup au meme moment
# Les evenements 4768 apparaissent dans le journal de securite du controleur de domaine
Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4768} |
  Where-Object { $_.Properties[0].Value -eq 'svcbackup' } |
  Where-Object { $_.TimeCreated -gt '02:10' -and $_.TimeCreated -lt '02:25' }
# Si retourne vide alors que 4776+4624 existent : PtH confirme

Supplementaire : le hachage a-t-il ete extrait anterieurement ? Rechercher l'Evenement 10 dans Sysmon (processus ayant accede a lsass.exe) sur WKSTN-047 dans l'heure avant 02:17. Rechercher egalement les processus suspects crees via Sysmon Evenement 1 (creation de processus) - Mimikatz, procdump, ou des chargeurs personnalises.

Question 4

Vous elaborez une strategie de retention et de collecte pour un environnement a 5 Gbps soutenu (reseau universitaire). Le budget permet environ 20 To de stockage forensique dedie. Une capture de paquets complete soutenue a 5 Gbps remplirait ce stockage en environ 4 a 5 heures. Quelle architecture de collecte concevriez-vous, et quels compromis en matiere de fidelite des preuves acceptez-vous ?

Reveler la reponse et l'explication

Reponse : La capture de paquets complete a 5 Gbps soutenu represente environ 400-500 Go/heure apres compression LZ4. 20 To = ~40-50 heures de capture complete - utile pour les incidents actifs, pas pour les investigations historiques.

Architecture en niveaux recommandee :

Niveau 1 - FPC selective (retention courte, ciblee) :

- Capturer uniquement des segments specifiques : DMZ, VLAN serveur, sous-reseaux cadres
- Appliquer des filtres BPF pour exclure le trafic consommateur en masse (streaming video, mises a jour OS)
- Reduction estimee : 60-70% du trafic elimine
- Stockage a ~40% du debit ligne : ~160-200 Go/h -> 20 To ~ 4 jours sur les segments cibles

# Capturer uniquement le trafic vers/depuis les VLANs serveur et la DMZ
tcpdump -i eth0 -s 0 -w /data/fpc/capture-%Y%m%d%H%M.pcap \
  -G 3600 -C 5000 -W 96 \           # 96 fichiers x 5 Go = 480 Go = 4 jours a 5 Go/h
  "net 10.0.1.0/24 or net 10.0.2.0/24 or net 172.16.0.0/24"

Niveau 2 - Couverture complete Zeek (retention moyenne) :

- Executer Zeek sur toutes les interfaces au debit ligne complet
- Tous les journaux de protocole (conn, dns, http, ssl, files, smtp)
- Volume estime : 2-4 Go/h a 5 Gbps -> 20 To = 200-400 jours
- Contient la semantique couche applicative, les hachages de fichiers, les empreintes TLS
- Couvre 80% des questions d'investigation

Niveau 3 - NetFlow (longue retention, tout le trafic) :

- Echantillonner 1:100 ou exporter les flux complets depuis le routeur/commutateur
- 50-100 Mo/h -> 20 To = 2 000+ jours
- Visibilite au niveau de la session sans payload - detecte les mouvements lateraux, les volumes d'exfiltration

Repartition du stockage (exemple 20 To) :

Niveau	Allocation	Retention
FPC (ciblee)	5 To	~25 jours (segments cibles uniquement)
Journaux Zeek	10 To	~100-200 jours
NetFlow	3 To	~1 000+ jours
SIEM/auth/journaux DNS	2 To	~365 jours

Compromis de fidelite des preuves acceptes :

La FPC des segments non cibles est perdue - le carving de fichiers et la reconstruction de session ne sont pas disponibles pour ces hotes
Les attaques utilisant exclusivement des segments non cibles peuvent ne pas disposer de preuves FPC
Zeek et NetFlow comblent le manque avec une fidelite plus faible - on peut confirmer qu'une connexion a eu lieu et quelle quantite de donnees a ete transferee, mais pas quel etait le payload

Pour les environnements de conformite (PCI-DSS, HIPAA) : s'assurer que les segments reseau titulaires de cartes/PHI figurent dans le niveau cible FPC. L'exfiltration d'un seul enregistrement doit etre reconstructible - "nous avions des donnees de flux montrant 500 Ko quittant le segment" est insuffisant si la specificite forensique est requise par votre SLA de reponse aux incidents.

Question 1​

Question 2​

Question 3​

Question 4​

Question 1

Question 2

Question 3

Question 4