Incident Response & Threat Hunting
De la detection a la remediation, maitrise le processus complet de reponse aux incidents. Apprends a chasser proactivement les menaces avant qu'elles ne causent des dommages.
- Comprendre le cycle de vie de la reponse aux incidents (NIST SP 800-61)
- Maitriser les 4 phases : preparation, detection, containment, post-incident
- Appliquer la Cyber Kill Chain et MITRE ATT&CK a l'investigation
- Creer et utiliser des playbooks et runbooks de reponse
- Pratiquer le Threat Hunting proactif avec Elastic/KQL
- Mener une investigation complete d'une compromission ransomware
🚨 T8.1 — Introduction a la reponse aux incidents
La reponse aux incidents (Incident Response, IR) est l'ensemble des processus et procedures permettant a une organisation de detecter, analyser, contenir et remedier a des incidents de securite. C'est l'une des fonctions les plus critiques d'un SOC (Security Operations Center).
L'equipe IR, c'est l'equipe de pompiers cyber. Imagine une caserne de pompiers : ils se preparent en amont (plans d'evacuation, entrainement, materiel), ils detectent le feu (alarmes), ils interviennent pour le contenir (isoler les zones, eteindre les flammes), puis ils analysent les causes pour empecher que ca se reproduise. L'equipe IR fait exactement pareil, mais avec des incidents de cybersecurite : preparation, detection, containment, retour d'experience.
Evenement vs Incident
Il est crucial de distinguer un evenement (event) d'un incident (incident) en securite :
| Critere | Evenement (Event) | Incident (Incident) |
|---|---|---|
| Definition | Toute activite observable sur un systeme ou reseau | Evenement ayant un impact negatif sur la confidentialite, l'integrite ou la disponibilite |
| Volume | Des millions par jour | Quelques dizaines par mois (variable) |
| Exemples | Connexion utilisateur, requete DNS, scan de port | Ransomware, exfiltration de donnees, compromission de compte |
| Action | Journalisation, monitoring | Investigation, containment, remediation |
| Priorite | Faible (traitement automatise) | Haute (intervention humaine requise) |
Pourquoi la reponse aux incidents est essentielle
- Reduire le temps d'impact — Le cout moyen d'un breach augmente de 23% quand le temps de detection depasse 200 jours
- Conformite reglementaire — RGPD (72h pour notifier), PCI-DSS, HIPAA exigent un processus IR formel
- Protection de la reputation — Une reponse rapide et transparente limite les degats reputationnels
- Amelioration continue — Chaque incident traite renforce les defenses de l'organisation
- Obligation legale — En France, l'ANSSI peut exiger un rapport d'incident pour les OIV (Operateurs d'Importance Vitale)
Le framework NIST SP 800-61
Le NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide) est la reference mondiale pour la gestion d'incidents. Il definit un cycle en 4 phases que nous detaillerons dans la section suivante.
Outre le NIST, il existe d'autres frameworks :
- SANS Incident Handler's Handbook — 6 phases (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned)
- ISO 27035 — Standard international de gestion d'incidents
- FIRST (Forum of IR and Security Teams) — Standards de collaboration entre CERT/CSIRT
Le NIST et le SANS sont tres similaires ; le NIST regroupe Containment/Eradication/Recovery en une seule phase.
Types d'incidents de securite
| Type d'incident | Description | Severite typique | Exemples |
|---|---|---|---|
| Malware / Ransomware | Code malveillant execute sur un systeme | Critique | WannaCry, LockBit, Emotet |
| Phishing / Social Engineering | Manipulation humaine pour obtenir des acces | Haute | Spear phishing, BEC, vishing |
| Compromission de compte | Acces non autorise a un compte utilisateur | Haute | Credential stuffing, password spray |
| Exfiltration de donnees | Vol de donnees sensibles | Critique | Vol de base clients, propriete intellectuelle |
| DDoS | Attaque par deni de service distribue | Moyenne a Haute | Volumetric, application-layer, amplification |
| Menace interne | Action malveillante d'un employe ou prestataire | Haute a Critique | Vol de donnees, sabotage, espionnage |
| Exploitation de vulnerabilite | Exploitation d'une faille zero-day ou non corrigee | Critique | Log4Shell, ProxyLogon, MOVEit |
| Compromission supply chain | Attaque via un fournisseur ou composant tiers | Critique | SolarWinds, 3CX, Codecov |
🛠 T8.2 — Le processus NIST de gestion d'incidents (4 phases)
Le NIST SP 800-61 definit un cycle iteratif en 4 phases. Chaque incident traverse ces phases, et les lecons apprises alimentent la preparation pour les incidents futurs.
Constituer l'equipe, definir les procedures, deployer les outils, former le personnel. C'est la fondation de tout le processus IR.
Identifier les indicateurs de compromission (IoC), trier les alertes, analyser la severite et la portee de l'incident.
Isoler la menace, eliminer la cause racine, restaurer les systemes et verifier le retour a la normale.
Lecons apprises, rapport d'incident, amelioration des processus et mise a jour des defenses.
Phase 1 — Preparation
La preparation est la phase la plus importante. Un incident mal gere est souvent le resultat d'un manque de preparation. Cette phase se fait avant tout incident.
| Element | Description | Priorite |
|---|---|---|
| Equipe CSIRT | Constituer une equipe de reponse avec des roles clairs : IR Lead, Analyste Triage, Analyste Forensique, Communication | Critique |
| Outils IR | SIEM (Splunk/Elastic), EDR (CrowdStrike/SentinelOne), outils forensiques (Velociraptor, KAPE), sandbox (Any.Run) | Critique |
| Runbooks & Playbooks | Procedures documentees pour chaque type d'incident (phishing, ransomware, breach, DDoS) | Haute |
| Plan de communication | Matrice d'escalade, contacts d'urgence, templates de notification (direction, juridique, ANSSI, clients) | Haute |
| Formation & exercices | Tabletop exercises trimestriels, formation continue des analystes, simulation d'incidents | Haute |
| Baseline & inventaire | Connaitre l'etat normal du reseau, inventaire des actifs, cartographie des flux | Moyenne |
| Accords juridiques | Contrats avec des prestataires IR (retainer), accord avec le juridique sur la preservation des preuves | Moyenne |
Un analyste IR doit avoir un jump bag toujours pret contenant : laptop forensique, write blockers, cables reseau, cles USB bootables (SIFT, Kali), documentation des procedures, et contacts d'urgence imprimes.
Phase 2 — Detection & Analyse
C'est la phase ou l'on detecte qu'un incident est en cours et ou l'on determine sa nature, sa severite et sa portee.
Sources de detection
- SIEM — Correlation d'evenements, regles de detection, alertes automatisees
- EDR/XDR — Detection comportementale sur les endpoints
- IDS/IPS — Signatures reseau (Suricata, Snort)
- Utilisateurs — Signalement de phishing, comportement anormal
- Threat Intelligence — Feeds IoC, rapports de menaces
- Tiers — Notification par un partenaire, un CERT, ou les forces de l'ordre
Indicateurs de compromission (IoC)
| Type d'IoC | Exemples | Source typique |
|---|---|---|
| Reseau | IP C2, domaines DGA, user-agent suspect, beaconing | Firewall, proxy, DNS logs |
| Hote | Hash de fichier malveillant, cle de registre, service suspect | EDR, Sysmon, HIDS |
| Expediteur spoof, piece jointe macro, lien phishing | Passerelle mail, sandbox | |
| Comportemental | Connexion hors horaires, volume d'upload anormal, mouvement lateral | SIEM, UEBA |
Classification de severite
| Niveau | Severite | Description | SLA de reponse |
|---|---|---|---|
| P1 | Critique | Impact business majeur, ransomware actif, exfiltration en cours | < 15 min |
| P2 | Haute | Compromission confirmee, mouvement lateral detecte | < 1 heure |
| P3 | Moyenne | Malware isole contenu, tentative de phishing reussie sans impact | < 4 heures |
| P4 | Basse | Scan de reconnaissance, faux positif a confirmer | < 24 heures |
Phase 3 — Containment, Eradication & Recovery
Une fois l'incident confirme et analyse, il faut agir rapidement pour limiter les degats, eliminer la menace et restaurer les operations.
Containment (Confinement)
| Type | Actions | Objectif |
|---|---|---|
| Short-term | Isoler le poste du reseau, bloquer l'IP C2, desactiver le compte compromis, activer le WAF en mode blocage | Stopper la propagation immediate |
| Long-term | Segmenter le reseau, deployer des regles de detection supplementaires, appliquer les patchs critiques, renforcer les ACL | Empecher la reinfection pendant la remediation |
Avant toute action de containment, capturer les preuves forensiques : dump memoire (RAM), image disque, logs, captures reseau. Une fois la machine isolee ou eteinte, certaines preuves volatiles sont perdues a jamais.
Eradication (Elimination)
- Identifier et supprimer tous les artefacts malveillants (fichiers, cles de registre, taches planifiees, services)
- Determiner la cause racine (root cause) : quelle vulnerabilite a ete exploitee ?
- Corriger la vulnerabilite (patch, changement de configuration)
- Reinitialiser les credentials compromis (mots de passe, tokens API, certificats)
- Verifier que l'attaquant n'a pas installe d'autres mecanismes de persistance
Recovery (Restauration)
- Restaurer les systemes a partir de backups verifies (s'assurer que les backups ne sont pas infectes)
- Reinstaller les systemes compromis a partir d'images propres
- Retablir les services par ordre de priorite business
- Augmenter temporairement le monitoring sur les systemes restaures
- Valider le retour a la normale avec les equipes metier
Phase 4 — Activite post-incident
Souvent negligee, cette phase est pourtant essentielle pour l'amelioration continue de la posture de securite.
Reunion de retour d'experience (Lessons Learned)
A tenir dans les 5 jours ouvrables suivant la cloture de l'incident. Questions cles :
- Que s'est-il passe exactement ? (timeline complete)
- Quand et comment l'incident a-t-il ete detecte ?
- Les procedures IR ont-elles ete suivies ? Etaient-elles adequates ?
- Quelles actions auraient pu etre faites plus rapidement ?
- Quelles donnees supplementaires auraient aide l'investigation ?
- Quelles mesures preventives mettre en place ?
Contenu du rapport d'incident
| Section | Contenu |
|---|---|
| Resume executif | Description non technique pour la direction (impact business, cout estime) |
| Timeline | Chronologie detaillee de l'incident (UTC) avec les actions de l'attaquant et du CSIRT |
| Analyse technique | Vecteur d'attaque, TTPs, IoCs, systemes impactes, donnees compromises |
| Actions de remediation | Containment, eradication, recovery — ce qui a ete fait |
| Cause racine | Vulnerabilite exploitee, facteur humain, defaillance de processus |
| Recommandations | Actions correctives a court, moyen et long terme |
| Indicateurs | Metriques : MTTD, MTTR, nombre de systemes impactes |
Metriques IR cles
| Metrique | Definition | Objectif |
|---|---|---|
| MTTD | Mean Time To Detect — temps moyen de detection | < 24 heures |
| MTTR | Mean Time To Respond — temps moyen de reponse | < 4 heures (P1) |
| MTTC | Mean Time To Contain — temps moyen de containment | < 1 heure (P1) |
| Dwell Time | Temps passe par l'attaquant dans le SI avant detection | < 7 jours |
⚔️ T8.3 — Cyber Kill Chain et MITRE ATT&CK pour l'IR
Deux frameworks essentiels permettent de structurer l'analyse d'un incident : la Cyber Kill Chain de Lockheed Martin et le framework MITRE ATT&CK. Ensemble, ils aident a comprendre la progression d'une attaque et les TTPs (Tactics, Techniques, Procedures) de l'adversaire.
Cyber Kill Chain appliquee a l'IR
La Kill Chain decrit les 7 etapes qu'un attaquant doit parcourir pour reussir une attaque. Du point de vue IR, chaque etape represente une opportunite de detection et d'interruption.
| Phase Kill Chain | Action de l'attaquant | Opportunite de detection | Action IR |
|---|---|---|---|
| 1. Reconnaissance | OSINT, scan de ports, enumeration DNS | Logs DNS, IDS, honeypots | Enrichir les IoC, bloquer les scanners connus |
| 2. Weaponization | Creation du malware, packaging de l'exploit | Threat intelligence, partage entre CERTs | Mettre a jour les signatures, sandboxing |
| 3. Delivery | Envoi du phishing, drive-by download, USB | Passerelle email, proxy web, logs USB | Bloquer les vecteurs, alerter les utilisateurs |
| 4. Exploitation | Execution de l'exploit, macro malveillante | EDR, Sysmon (process creation), AV | Isoler le poste, capturer la memoire |
| 5. Installation | Persistence, backdoor, dropper | Sysmon (registry, scheduled tasks), HIDS | Identifier et supprimer la persistance |
| 6. Command & Control | Communication C2, beaconing, DNS tunneling | Proxy logs, DNS analytics, NDR, JA3/JA4 | Bloquer les domaines/IP C2, sinkholing |
| 7. Actions on Objectives | Exfiltration, chiffrement, destruction | DLP, UEBA, file integrity monitoring | Containment immediat, preservation des preuves |
MITRE ATT&CK pour l'investigation
ATT&CK fournit une matrice detaillee de TTPs observees chez des groupes d'attaquants reels. En IR, on l'utilise pour :
- Mapper les artefacts — Chaque artefact trouve (cle de registre, tache planifiee, outil) correspond a une technique ATT&CK specifique
- Identifier le groupe d'attaquants — Les TTPs observees permettent parfois d'attribuer l'attaque a un groupe connu (APT28, Lazarus, FIN7...)
- Evaluer la couverture — Verifier si nos outils de detection couvrent les techniques observees
- Predire les prochaines etapes — Si on detecte la phase T1059 (Command Scripting), l'attaquant cherchera probablement T1003 (Credential Dumping) ensuite
Mapping artefacts vers ATT&CK — exemples courants
| Artefact observe | Technique ATT&CK | Tactic |
|---|---|---|
Tache planifiee suspecte dans schtasks | T1053.005 — Scheduled Task | Persistence, Execution |
| Cle Run dans le registre | T1547.001 — Registry Run Keys | Persistence |
Execution de mimikatz.exe | T1003.001 — LSASS Memory | Credential Access |
| Connexion RDP depuis un serveur | T1021.001 — Remote Desktop Protocol | Lateral Movement |
| PowerShell encode en Base64 | T1059.001 — PowerShell | Execution |
Archive ZIP dans C:\Temp\ avant upload | T1074.001 — Local Data Staging | Collection |
| DNS requests vers des domaines DGA | T1568.002 — Domain Generation Algorithms | Command and Control |
| Utilisation de PsExec | T1569.002 — Service Execution | Execution, Lateral Movement |
L'outil ATT&CK Navigator (attack.mitre.org) permet de visualiser graphiquement la couverture de detection et de superposer les TTPs observees lors d'un incident. C'est un outil indispensable lors de la phase post-incident.
📖 T8.4 — Playbooks et runbooks
Les playbooks et runbooks sont des documents operationnels essentiels a toute equipe IR. Ils standardisent la reponse et evitent la panique en situation de crise.
Playbook vs Runbook : quelle difference ?
| Critere | Playbook | Runbook |
|---|---|---|
| Niveau | Strategique / tactique | Operationnel / technique |
| Contenu | Processus de decision, arbre de decision, roles et responsabilites | Commandes exactes, procedures pas-a-pas, scripts a executer |
| Public cible | IR Lead, management, equipe CSIRT | Analystes SOC L1/L2, administrateurs systeme |
| Exemple | "En cas de ransomware, evaluer l'ampleur, decider si on paie, qui notifier" | "Pour isoler un poste : executer ce script EDR, bloquer ce port, lancer cette commande" |
| Flexibilite | Adaptable selon le contexte | Procedures strictes et reproductibles |
Playbooks essentiels
Objectif : Contenir et remedier a une attaque de phishing
- Triage — Analyser l'email signale : expediteur (SPF/DKIM/DMARC), headers, liens, pieces jointes
- Analyse du lien/PJ — Detonation en sandbox (Any.Run, Joe Sandbox), verifier VirusTotal, URLhaus
- Identifier les victimes — Rechercher dans les logs email qui a recu le meme message (search by subject, sender, attachment hash)
- Verifier les clics — Logs proxy/DNS : qui a clique sur le lien ? Qui a ouvert la piece jointe ?
- Containment — Bloquer le domaine/IP dans le proxy, supprimer l'email de toutes les boites, revoquer les sessions des comptes compromis
- Eradication — Si un payload a ete execute : isoler le poste, scanner avec EDR, reinitialiser les credentials
- Recovery — Restaurer l'acces des utilisateurs, confirmer que le domaine malveillant est bloque
- Communication — Alerter les utilisateurs de la campagne, rappeler les bons reflexes
# PowerShell — Recherche dans les logs O365
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) `
-EndDate (Get-Date) `
-Operations "MailItemsAccessed" `
-FreeText "objet-du-phishing" | Export-Csv phishing-victims.csv
# KQL — Recherche Elastic (email gateway logs)
event.category: "email" AND email.subject: "Votre facture impayee" AND email.direction: "inbound"
| stats count by email.to.address
Objectif : Contenir un ransomware et minimiser l'impact business
- Detection & alerte — Alerte EDR (chiffrement de masse), utilisateur signalant des fichiers inaccessibles, note de rancon detectee
- Containment immediat — Isoler les postes infectes du reseau (EDR network isolation), desactiver les comptes compromis, couper les partages reseau
- Evaluer l'ampleur — Identifier tous les systemes touches, verifier si les backups sont intacts, determiner le type de ransomware (ID Ransomware)
- Preserver les preuves — Capturer la RAM des machines infectees, sauvegarder la note de rancon, capturer les logs reseau
- Eradication — Identifier le vecteur d'entree (phishing ? RDP expose ?), scanner tous les systemes, supprimer les mecanismes de persistance
- Decision : payer ou ne pas payer — Impliquer la direction, le juridique, l'assurance cyber. Verifier si un decrypteur gratuit existe (NoMoreRansom.org)
- Recovery — Restaurer depuis les backups verifies, reinstaller les systemes compromis, retablir les services par priorite
- Post-incident — Rapport complet, hardening des acces RDP, MFA obligatoire, formation anti-phishing
La cle de dechiffrement peut etre en memoire (RAM). Eteindre le poste la detruit. Toujours isoler du reseau plutot qu'eteindre, et capturer un dump memoire en premier.
Objectif : Identifier l'etendue de la fuite, contenir et notifier
- Confirmer la fuite — Verifier l'alerte DLP, analyser les logs d'acces aux donnees sensibles, confirmer avec les equipes metier
- Identifier les donnees impactees — Type de donnees (PII, donnees bancaires, sante), volume, nombre de personnes concernees
- Identifier le vecteur — Acces non autorise ? Erreur de configuration ? Menace interne ? Application compromise ?
- Containment — Revoquer les acces, corriger la configuration, bloquer les canaux d'exfiltration
- Evaluation juridique — Impliquer le DPO et le service juridique, determiner les obligations de notification (RGPD : 72h pour la CNIL)
- Notification — Notifier la CNIL/autorite competente, notifier les personnes concernees si risque eleve
- Remediation — Corriger la cause racine, renforcer les controles d'acces, chiffrer les donnees sensibles
Objectif : Restaurer la disponibilite des services sous attaque
- Detection — Alertes de monitoring (latence, perte de paquets, saturation bande passante), signalements utilisateurs
- Caracteriser l'attaque — Volumetrique (UDP flood) ? Protocole (SYN flood) ? Applicative (HTTP flood, Slowloris) ?
- Activation des mitigations — Activer le mode "under attack" du CDN (Cloudflare, Akamai), activer le scrubbing center du FAI
- Filtrage — Bloquer les IP sources (si identifiables), rate limiting, geo-blocking si pertinent
- Scaling — Augmenter la capacite (auto-scaling cloud), distribuer la charge
- Communication — Page de status pour les utilisateurs, informer le support client
- Post-attaque — Analyser les patterns, enrichir les regles anti-DDoS, verifier si le DDoS n'etait pas une diversion
Les attaques DDoS servent parfois de diversion pendant qu'une attaque plus serieuse (exfiltration, intrusion) est en cours. Toujours verifier les autres alertes de securite pendant un DDoS.
Objectif : Detecter, investiguer et contenir une menace interne
- Detection — Alertes UEBA (User Entity Behavior Analytics), DLP, signalement manager, surveillance des comptes a privilege
- Validation discrere — Confirmer l'activite suspecte sans alerter le suspect. Impliquer les RH et le juridique des le debut
- Collecte de preuves — Logs d'acces, logs email, logs USB/peripheriques, historique de navigation, captures ecran (si autorise)
- Analyse comportementale — Comparer avec le baseline normal de l'utilisateur, identifier les anomalies (heures, volumes, systemes accedes)
- Decision — Avec RH et juridique : confrontation, suspension, ou surveillance continuee
- Containment — Revoquer les acces progressivement, desactiver le VPN, bloquer les peripheriques USB
- Action disciplinaire / legale — Selon la gravite : avertissement, licenciement, poursuite judiciaire
En France, la surveillance des employes est encadree par le Code du travail et la CNIL. L'employe doit avoir ete informe des dispositifs de surveillance. Les preuves obtenues illegalement sont irrecevables.
🐺 T8.5 — Introduction au Threat Hunting
Le Threat Hunting (chasse aux menaces) est une approche proactive de la securite. Contrairement a la detection classique qui attend les alertes, le hunter part activement a la recherche de menaces qui ont echappe aux outils automatises.
Reactif vs Proactif
| Critere | Securite Reactive (SOC classique) | Securite Proactive (Threat Hunting) |
|---|---|---|
| Declencheur | Alerte generee par un outil | Hypothese formulee par un analyste |
| Approche | Attendre et reagir | Chercher et decouvrir |
| Couverture | Limitee aux regles/signatures existantes | Peut detecter des menaces inconnues (zero-day, TTPs nouvelles) |
| Automatisation | Forte (SIEM, SOAR) | Faible (humain + outils d'analyse) |
| Niveau d'expertise | L1/L2 SOC | L3 / Threat Hunter specialise |
| Resultat | Incidents confirmes ou faux positifs | Nouvelles detections, TTPs identifiees, amelioration des regles |
Les hypotheses de chasse
Tout hunt commence par une hypothese — une supposition testable sur la presence d'une menace. Exemples :
- "Un attaquant utilise du DNS tunneling pour exfiltrer des donnees"
- "Un malware communique avec un C2 via du beaconing HTTP regulier"
- "Un compte de service est utilise pour du mouvement lateral anormal"
- "Un mecanisme de persistance non detecte existe sur les serveurs web"
Methodologies de chasse
| Methodologie | Description | Exemple | Source |
|---|---|---|---|
| Intelligence-driven | Basee sur des rapports de Threat Intelligence, IoC partages par des CERTs | Rechercher les IoC du rapport APT29 de Mandiant dans nos logs | CTI feeds, MISP, rapports vendeurs |
| TTP-driven | Basee sur les techniques ATT&CK connues, independamment de l'acteur | Chercher toute utilisation de T1053 (Scheduled Tasks) pour la persistance | MITRE ATT&CK, experience de l'analyste |
| Data-driven (Anomaly) | Basee sur l'analyse statistique des donnees pour trouver des anomalies | Detecter les processus avec une entropie de nommage anormale (DGA) | Machine learning, analyse statistique, baselines |
La boucle de chasse (Hunting Loop)
Formuler une hypothese testable basee sur la CTI, les TTPs connus, ou les anomalies observees.
Identifier les sources de donnees necessaires (logs, netflow, endpoint telemetry) et les interroger.
Analyser les resultats, pivoter sur les anomalies, approfondir les pistes suspectes.
Documenter les resultats, creer de nouvelles regles de detection, escalader si menace confirmee.
Outils de Threat Hunting
| Outil | Type | Usage principal |
|---|---|---|
| Elastic Security / ELK | SIEM / Log analytics | Recherche dans les logs avec KQL, dashboards, alertes |
| Splunk | SIEM / Log analytics | SPL pour requetes complexes, lookups, macros |
| Velociraptor | Endpoint forensics | Collecte d'artefacts a distance, VQL, hunting sur fleet |
| RITA | Network analysis | Detection de beaconing, DNS tunneling, long connections |
| Jupyter Notebooks | Data analysis | Analyse statistique avec Python, visualisations, reproductibilite |
| OSQuery | Endpoint query | Interroger les endpoints comme une base de donnees SQL |
🔍 T8.6 — Threat Hunting en pratique avec Elastic
Passons a la pratique avec des hunts concrets utilisant KQL (Kibana Query Language) et des requetes Elasticsearch. Chaque hunt cible une TTP specifique.
Hunt 1 : Detecter le beaconing (C2 Communication)
Le beaconing est un pattern ou un malware contacte regulierement son serveur C2 a intervalles fixes. Cette regularite le distingue du trafic humain normal.
# Etape 1 : Identifier les paires source/destination avec beaucoup de connexions
event.category: "network_traffic" AND network.direction: "outbound"
| stats count, avg(event.duration), stddev(event.duration) by source.ip, destination.ip, destination.port
| where count > 50 AND stddev(event.duration) < 5000
POST /network-*/_search
{
"size": 0,
"query": {
"bool": {
"must": [
{ "term": { "network.direction": "outbound" } },
{ "range": { "@timestamp": { "gte": "now-24h" } } }
],
"must_not": [
{ "terms": { "destination.port": [80, 443, 53] } }
]
}
},
"aggs": {
"by_dest": {
"composite": {
"sources": [
{ "src": { "terms": { "field": "source.ip" } } },
{ "dst": { "terms": { "field": "destination.ip" } } }
]
},
"aggs": {
"intervals": {
"auto_date_histogram": { "field": "@timestamp", "buckets": 100 },
"aggs": {
"interval_stats": {
"stats": { "field": "event.duration" }
}
}
},
"conn_count": { "value_count": { "field": "@timestamp" } },
"regularity_filter": {
"bucket_selector": {
"buckets_path": { "count": "conn_count" },
"script": "params.count > 100"
}
}
}
}
}
}
Analyse : Un ecart-type faible (stddev) sur les intervalles de connexion indique un comportement tres regulier — typique d'un beacon C2. Le trafic humain est irregulier par nature. Un stddev < 5 secondes sur plus de 50 connexions est hautement suspect.
Hunt 2 : Detecter le mouvement lateral
Le mouvement lateral se manifeste par des connexions inhabituelles entre machines internes, notamment via RDP, SMB, WMI ou PsExec.
# Identifier les connexions RDP entre postes de travail (pas serveurs)
event.category: "authentication" AND winlog.event_id: 4624
AND winlog.logon_type: 10
AND source.ip: 192.168.*
AND NOT source.ip: (192.168.1.10 OR 192.168.1.11) # Exclure les jump servers
| stats count by source.ip, destination.ip, user.name
| where count > 3
# Sysmon Event ID 1 (Process Creation) — outils de lateral movement
event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1
AND (
process.name: ("psexec.exe" OR "psexec64.exe" OR "paexec.exe")
OR process.name: ("wmic.exe" AND process.args: "/node:")
OR (process.name: "powershell.exe" AND process.args: ("Invoke-Command" OR "Enter-PSSession"))
OR process.name: "winrs.exe"
)
Hunt 3 : Decouvrir les mecanismes de persistance
Les attaquants installent des mecanismes de persistance pour survivre aux redemarrages. Les plus courants sont les taches planifiees, les cles de registre Run, et les services Windows.
# Sysmon Event ID 1 — Creation de tache planifiee
event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1
AND process.name: "schtasks.exe"
AND process.args: ("/create" AND ("/sc" OR "/tn"))
AND NOT process.parent.executable: (
"C:\\Windows\\System32\\svchost.exe"
OR "C:\\Windows\\CCM\\*"
)
# Event ID 4698 — Tache planifiee creee (Security log)
winlog.event_id: 4698
AND NOT winlog.event_data.TaskName: ("\\Microsoft\\*" OR "\\Google\\*")
# Sysmon Event ID 13 — Registry Value Set
event.provider: "Microsoft-Windows-Sysmon" AND event.code: 13
AND registry.path: (
"*\\CurrentVersion\\Run\\*"
OR "*\\CurrentVersion\\RunOnce\\*"
OR "*\\Winlogon\\Shell*"
OR "*\\Winlogon\\Userinit*"
)
AND NOT process.executable: (
"C:\\Windows\\System32\\*"
OR "C:\\Program Files\\*"
OR "C:\\Program Files (x86)\\*"
)
Hunt 4 : Identifier le data staging (preparation d'exfiltration)
Avant d'exfiltrer des donnees, les attaquants les collectent et les compressent souvent dans un repertoire temporaire.
# Utilisation d'outils de compression dans des repertoires temporaires
event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1
AND process.name: ("7z.exe" OR "rar.exe" OR "zip.exe" OR "tar.exe" OR "winrar.exe")
AND process.args: (
"C:\\Temp\\*" OR "C:\\Users\\*\\AppData\\Local\\Temp\\*"
OR "C:\\ProgramData\\*" OR "C:\\Windows\\Temp\\*"
)
# Detection PowerShell Compress-Archive
event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1
AND process.name: "powershell.exe"
AND process.args: "Compress-Archive"
# Volumes d'upload anormaux (proxy logs)
event.category: "web" AND http.request.method: "POST"
| stats sum(http.request.bytes) as total_upload by source.ip, url.domain
| where total_upload > 104857600 # Plus de 100 MB uploade vers un meme domaine
| sort total_upload desc
Les meilleurs hunts combinent des requetes ciblees (chercher des TTPs connues) avec de l'analyse statistique (chercher des anomalies). Techniques cles :
- Z-score — Mesurer a quel point une valeur s'ecarte de la moyenne (> 3 = anomalie)
- Entropie de Shannon — Detecter les noms de domaine DGA ou les donnees chiffrees dans des canaux non chiffres
- Analyse de frequence — Identifier les patterns reguliers (beaconing) vs le trafic normal (irregulier)
- Stacking (long tail analysis) — Empiler les valeurs et chercher les outliers (1 occurrence vs 10 000)
🔎 T8.7 — Etude de cas : investigation d'une compromission ransomware
Suivons une investigation complete d'un incident ransomware, depuis l'alerte initiale jusqu'a la remediation. Chaque etape inclut les requetes et commandes utilisees par l'equipe IR.
Entreprise : MedTech SA — entreprise de 500 employes dans le domaine medical
Date : Lundi 14h32 — le SOC recoit une alerte critique
Alerte : L'EDR detecte un chiffrement de masse de fichiers sur le serveur de fichiers FS01 (192.168.10.20)
Etape 1 : Alerte initiale (SIEM) — T+0 min
L'analyste SOC L1 recoit une alerte de severite critique de l'EDR. Le SIEM correle cette alerte avec d'autres evenements suspects.
# Alerte EDR sur FS01
event.kind: "alert" AND host.name: "FS01" AND event.severity: "critical"
| sort @timestamp desc
| limit 20
# Resultat :
# 14:32:05 — ALERT: Ransomware behavior detected — mass file encryption
# process: C:\Windows\Temp\svchost_update.exe
# files_encrypted: 847 in 45 seconds
# technique: AES-256 + RSA-2048
Etape 2 : Identifier le patient zero — T+15 min
D'ou vient le ransomware ? Il faut remonter la chaine d'execution pour trouver le point d'entree initial.
# Arbre de processus — qui a lance svchost_update.exe ?
event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1
AND host.name: "FS01"
AND process.executable: "C:\\Windows\\Temp\\svchost_update.exe"
# Resultat :
# Parent process: powershell.exe -enc SQBuAHYAbwBrAGUALQBXAGUA...
# Grand-parent: cmd.exe lancé via PsExec depuis 192.168.10.55 (WS-JMARTIN)
# Remonter sur le poste source WS-JMARTIN
event.provider: "Microsoft-Windows-Sysmon" AND event.code: 1
AND host.name: "WS-JMARTIN"
AND @timestamp < "2024-01-14T14:32:00"
| sort @timestamp desc
| limit 50
# Resultat :
# 14:15:22 — WINWORD.EXE lance powershell.exe (macro malveillante)
# 14:14:08 — OUTLOOK.EXE telecharge "Facture_Janvier_2024.docm"
# --> PATIENT ZERO : WS-JMARTIN (poste de Jean Martin)
# --> VECTEUR : phishing avec piece jointe Word macro
Etape 3 : Tracer le mouvement lateral — T+30 min
L'attaquant est passe de WS-JMARTIN a FS01. Comment ? Cherchons les connexions laterales.
# Connexions sortantes depuis WS-JMARTIN (192.168.10.55)
event.category: "network_traffic" AND source.ip: "192.168.10.55"
AND destination.port: (445 OR 135 OR 5985 OR 3389)
AND @timestamp >= "2024-01-14T14:15:00" AND @timestamp <= "2024-01-14T14:32:00"
| stats count by destination.ip, destination.port
| sort count desc
# Resultat :
# 192.168.10.20 (FS01) — port 445 (SMB) — 23 connexions
# 192.168.10.10 (DC01) — port 445 (SMB) — 8 connexions
# 192.168.10.30 (DB01) — port 445 (SMB) — 5 connexions
# --> L'attaquant a scanne le reseau et accede a FS01, DC01 et DB01 via SMB
Etape 4 : Trouver la persistance — T+45 min
L'attaquant a-t-il installe des mecanismes de persistance sur les machines compromises ?
# Taches planifiees creees sur les machines compromises
winlog.event_id: 4698
AND host.name: ("WS-JMARTIN" OR "FS01" OR "DC01" OR "DB01")
AND @timestamp >= "2024-01-14T14:00:00"
# Resultat :
# FS01 — Task: "WindowsUpdate_Check" — Action: C:\Windows\Temp\svchost_update.exe
# DC01 — Task: "SystemHealthMonitor" — Action: powershell.exe -enc [base64]
# Services suspects crees
winlog.event_id: 7045
AND host.name: ("WS-JMARTIN" OR "FS01" OR "DC01" OR "DB01")
AND @timestamp >= "2024-01-14T14:00:00"
# Resultat :
# DC01 — Service: "WinDefenderUpdate" — Path: C:\ProgramData\defender_svc.exe
# --> PERSISTANCE CONFIRMEE sur FS01 et DC01
Etape 5 : Determiner l'exfiltration — T+1h
Avant de chiffrer, le ransomware moderne exfiltre souvent les donnees (double extortion). Verifions.
# Volumes d'upload inhabituels depuis les machines compromises
event.category: "web"
AND source.ip: ("192.168.10.55" OR "192.168.10.20" OR "192.168.10.10")
AND http.request.method: "POST"
AND @timestamp >= "2024-01-14T14:00:00"
| stats sum(http.request.bytes) as total_bytes by source.ip, url.domain
| where total_bytes > 10000000
| sort total_bytes desc
# Resultat :
# 192.168.10.20 (FS01) — mega-upload-cdn.xyz — 2.4 GB uploaded
# 192.168.10.10 (DC01) — file-share-srv.xyz — 340 MB uploaded
# --> EXFILTRATION CONFIRMEE : ~2.7 GB de donnees exfiltrees
# --> Double extortion : les donnees seront publiees si la rancon n'est pas payee
Etape 6 : Actions de containment — T+1h15
Maintenant que nous avons une image complete, il faut contenir l'incident.
# 1. Isoler les machines compromises via EDR
$ crowdstrike-api contain-host --hosts FS01,WS-JMARTIN,DC01,DB01
# 2. Bloquer les domaines C2 dans le proxy et le DNS
$ firewall-cli block-domain mega-upload-cdn.xyz
$ firewall-cli block-domain file-share-srv.xyz
$ dns-sinkhole add mega-upload-cdn.xyz file-share-srv.xyz
# 3. Desactiver le compte de Jean Martin et forcer un reset global
$ ad-cli disable-account jmartin
$ ad-cli force-password-reset --scope "all-users" --priority high
# 4. Bloquer les hash du malware sur tous les endpoints
$ edr-cli block-hash sha256:a1b2c3d4e5f6... --scope global
# 5. Sauvegarder les preuves forensiques avant toute action destructive
$ velociraptor collect --host FS01 --artifact Windows.KapeFiles.Targets
$ velociraptor collect --host DC01 --artifact Windows.Memory.Acquisition
Etape 7 : Plan de recovery — T+2h
Avec l'incident contenu, l'equipe prepare la restauration des services.
PLAN DE RECOVERY — Incident IR-2024-001
========================================
Priorite 1 (Immediat) :
[x] Verifier l'integrite des backups (derniere sauvegarde saine : dimanche 02:00)
[x] Confirmer que DC02 (DC de backup) n'est pas compromis
[ ] Restaurer DC01 depuis une image propre + dernier backup AD
[ ] Restaurer FS01 depuis le backup de dimanche
Priorite 2 (< 24h) :
[ ] Reinstaller WS-JMARTIN depuis image standard
[ ] Verifier et restaurer DB01 (base de donnees patients)
[ ] Deployer les nouvelles regles EDR sur tout le parc
Priorite 3 (< 72h) :
[ ] Audit complet de tous les mecanismes de persistance
[ ] Rotation de tous les credentials de service
[ ] Patch de la vulnerabilite exploitee (macro Office)
[ ] Desactiver les macros Office pour les utilisateurs standard
Notifications :
[ ] Direction generale — briefing T+3h
[ ] ANSSI — notification dans les 72h (OIV)
[ ] CNIL — si donnees patients exfiltrees (RGPD Article 33)
[ ] Assurance cyber — declarer le sinistre
14:14 — Jean Martin ouvre un email de phishing et telecharge la piece jointe
14:15 — La macro s'execute, telecharge un payload PowerShell (patient zero)
14:18 — L'attaquant obtient des credentials via Mimikatz
14:20-14:28 — Mouvement lateral vers FS01, DC01, DB01 via SMB/PsExec
14:22-14:30 — Exfiltration de 2.7 GB de donnees vers des domaines C2
14:30 — Installation de persistance (taches planifiees, services)
14:32 — Lancement du chiffrement sur FS01 (detecte par EDR)
14:32 — Alerte SOC — debut de la reponse IR
🔨 T8.8 — Lab : Terminal interactif
Exercice 1 : Simulateur d'investigation IR
Utilise le terminal ci-dessous pour mener une investigation d'incident. Tape help pour voir les commandes disponibles.
Exercice 2 : Ordonne les phases NIST IR
Glisse chaque phase dans le bon ordre du processus NIST de reponse aux incidents.
Exercice 3 : Associe les artefacts aux phases de la Kill Chain
Glisse chaque artefact vers la phase Kill Chain correspondante.
✅ T8.9 — Quiz Incident Response & Threat Hunting
Teste tes connaissances sur la reponse aux incidents et le threat hunting. 15 questions pour valider ta maitrise du module.
Points cles du Module T8
- Un incident est un evenement ayant un impact negatif sur la CIA (Confidentialite, Integrite, Disponibilite) — a distinguer d'un simple evenement
- Le NIST SP 800-61 definit 4 phases iteratives : Preparation, Detection & Analyse, Containment/Eradication/Recovery, Post-Incident
- La preparation est la phase la plus critique : equipe CSIRT, outils, playbooks, plan de communication, exercices reguliers
- La Cyber Kill Chain et MITRE ATT&CK structurent l'analyse d'incident : chaque phase est une opportunite de detection
- Les playbooks (strategiques) et runbooks (operationnels) standardisent la reponse et evitent la panique en situation de crise
- Le Threat Hunting est proactif : hypothese, collecte de donnees, investigation, findings — il detecte ce que les outils automatises manquent
- Les techniques de hunting incluent l'analyse de beaconing (stddev faible), la detection de mouvement lateral et la recherche de persistance
- Toujours preserver les preuves (RAM, disque, logs) avant les actions de containment — les preuves volatiles disparaissent a l'extinction
- La phase post-incident (lessons learned, rapport, metriques MTTD/MTTR) est essentielle pour l'amelioration continue