Module T8 — Terrain

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 :

CritereEvenement (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.

Autres frameworks IR

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'incidentDescriptionSeverite typiqueExemples
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.

Les 4 phases du NIST Incident Response Lifecycle
Phase 1 — Preparation

Constituer l'equipe, definir les procedures, deployer les outils, former le personnel. C'est la fondation de tout le processus IR.

Phase 2 — Detection & Analyse

Identifier les indicateurs de compromission (IoC), trier les alertes, analyser la severite et la portee de l'incident.

Phase 3 — Containment, Eradication & Recovery

Isoler la menace, eliminer la cause racine, restaurer les systemes et verifier le retour a la normale.

Phase 4 — Activite post-incident

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.

ElementDescriptionPriorite
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
Jump bag / Go bag

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'IoCExemplesSource typique
ReseauIP C2, domaines DGA, user-agent suspect, beaconingFirewall, proxy, DNS logs
HoteHash de fichier malveillant, cle de registre, service suspectEDR, Sysmon, HIDS
EmailExpediteur spoof, piece jointe macro, lien phishingPasserelle mail, sandbox
ComportementalConnexion hors horaires, volume d'upload anormal, mouvement lateralSIEM, UEBA
Classification de severite
NiveauSeveriteDescriptionSLA de reponse
P1CritiqueImpact business majeur, ransomware actif, exfiltration en cours< 15 min
P2HauteCompromission confirmee, mouvement lateral detecte< 1 heure
P3MoyenneMalware isole contenu, tentative de phishing reussie sans impact< 4 heures
P4BasseScan 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)
TypeActionsObjectif
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
Preservation des preuves

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
SectionContenu
Resume executifDescription non technique pour la direction (impact business, cout estime)
TimelineChronologie detaillee de l'incident (UTC) avec les actions de l'attaquant et du CSIRT
Analyse techniqueVecteur d'attaque, TTPs, IoCs, systemes impactes, donnees compromises
Actions de remediationContainment, eradication, recovery — ce qui a ete fait
Cause racineVulnerabilite exploitee, facteur humain, defaillance de processus
RecommandationsActions correctives a court, moyen et long terme
IndicateursMetriques : MTTD, MTTR, nombre de systemes impactes
Metriques IR cles
MetriqueDefinitionObjectif
MTTDMean Time To Detect — temps moyen de detection< 24 heures
MTTRMean Time To Respond — temps moyen de reponse< 4 heures (P1)
MTTCMean Time To Contain — temps moyen de containment< 1 heure (P1)
Dwell TimeTemps 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 ChainAction de l'attaquantOpportunite de detectionAction 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 observeTechnique ATT&CKTactic
Tache planifiee suspecte dans schtasksT1053.005 — Scheduled TaskPersistence, Execution
Cle Run dans le registreT1547.001 — Registry Run KeysPersistence
Execution de mimikatz.exeT1003.001 — LSASS MemoryCredential Access
Connexion RDP depuis un serveurT1021.001 — Remote Desktop ProtocolLateral Movement
PowerShell encode en Base64T1059.001 — PowerShellExecution
Archive ZIP dans C:\Temp\ avant uploadT1074.001 — Local Data StagingCollection
DNS requests vers des domaines DGAT1568.002 — Domain Generation AlgorithmsCommand and Control
Utilisation de PsExecT1569.002 — Service ExecutionExecution, Lateral Movement
ATT&CK Navigator

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 ?

CriterePlaybookRunbook
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

  1. Triage — Analyser l'email signale : expediteur (SPF/DKIM/DMARC), headers, liens, pieces jointes
  2. Analyse du lien/PJ — Detonation en sandbox (Any.Run, Joe Sandbox), verifier VirusTotal, URLhaus
  3. Identifier les victimes — Rechercher dans les logs email qui a recu le meme message (search by subject, sender, attachment hash)
  4. Verifier les clics — Logs proxy/DNS : qui a clique sur le lien ? Qui a ouvert la piece jointe ?
  5. Containment — Bloquer le domaine/IP dans le proxy, supprimer l'email de toutes les boites, revoquer les sessions des comptes compromis
  6. Eradication — Si un payload a ete execute : isoler le poste, scanner avec EDR, reinitialiser les credentials
  7. Recovery — Restaurer l'acces des utilisateurs, confirmer que le domaine malveillant est bloque
  8. Communication — Alerter les utilisateurs de la campagne, rappeler les bons reflexes
Runbook : Rechercher les destinataires du phishing (Exchange/O365)
# 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

  1. Detection & alerte — Alerte EDR (chiffrement de masse), utilisateur signalant des fichiers inaccessibles, note de rancon detectee
  2. Containment immediat — Isoler les postes infectes du reseau (EDR network isolation), desactiver les comptes compromis, couper les partages reseau
  3. Evaluer l'ampleur — Identifier tous les systemes touches, verifier si les backups sont intacts, determiner le type de ransomware (ID Ransomware)
  4. Preserver les preuves — Capturer la RAM des machines infectees, sauvegarder la note de rancon, capturer les logs reseau
  5. Eradication — Identifier le vecteur d'entree (phishing ? RDP expose ?), scanner tous les systemes, supprimer les mecanismes de persistance
  6. Decision : payer ou ne pas payer — Impliquer la direction, le juridique, l'assurance cyber. Verifier si un decrypteur gratuit existe (NoMoreRansom.org)
  7. Recovery — Restaurer depuis les backups verifies, reinstaller les systemes compromis, retablir les services par priorite
  8. Post-incident — Rapport complet, hardening des acces RDP, MFA obligatoire, formation anti-phishing
Ne jamais eteindre un poste infecte

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

  1. Confirmer la fuite — Verifier l'alerte DLP, analyser les logs d'acces aux donnees sensibles, confirmer avec les equipes metier
  2. Identifier les donnees impactees — Type de donnees (PII, donnees bancaires, sante), volume, nombre de personnes concernees
  3. Identifier le vecteur — Acces non autorise ? Erreur de configuration ? Menace interne ? Application compromise ?
  4. Containment — Revoquer les acces, corriger la configuration, bloquer les canaux d'exfiltration
  5. Evaluation juridique — Impliquer le DPO et le service juridique, determiner les obligations de notification (RGPD : 72h pour la CNIL)
  6. Notification — Notifier la CNIL/autorite competente, notifier les personnes concernees si risque eleve
  7. Remediation — Corriger la cause racine, renforcer les controles d'acces, chiffrer les donnees sensibles

Objectif : Restaurer la disponibilite des services sous attaque

  1. Detection — Alertes de monitoring (latence, perte de paquets, saturation bande passante), signalements utilisateurs
  2. Caracteriser l'attaque — Volumetrique (UDP flood) ? Protocole (SYN flood) ? Applicative (HTTP flood, Slowloris) ?
  3. Activation des mitigations — Activer le mode "under attack" du CDN (Cloudflare, Akamai), activer le scrubbing center du FAI
  4. Filtrage — Bloquer les IP sources (si identifiables), rate limiting, geo-blocking si pertinent
  5. Scaling — Augmenter la capacite (auto-scaling cloud), distribuer la charge
  6. Communication — Page de status pour les utilisateurs, informer le support client
  7. Post-attaque — Analyser les patterns, enrichir les regles anti-DDoS, verifier si le DDoS n'etait pas une diversion
DDoS comme 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

  1. Detection — Alertes UEBA (User Entity Behavior Analytics), DLP, signalement manager, surveillance des comptes a privilege
  2. Validation discrere — Confirmer l'activite suspecte sans alerter le suspect. Impliquer les RH et le juridique des le debut
  3. Collecte de preuves — Logs d'acces, logs email, logs USB/peripheriques, historique de navigation, captures ecran (si autorise)
  4. Analyse comportementale — Comparer avec le baseline normal de l'utilisateur, identifier les anomalies (heures, volumes, systemes accedes)
  5. Decision — Avec RH et juridique : confrontation, suspension, ou surveillance continuee
  6. Containment — Revoquer les acces progressivement, desactiver le VPN, bloquer les peripheriques USB
  7. Action disciplinaire / legale — Selon la gravite : avertissement, licenciement, poursuite judiciaire
Cadre legal

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

CritereSecurite 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

MethodologieDescriptionExempleSource
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)

Le cycle iteratif du Threat Hunting
1. Hypothese

Formuler une hypothese testable basee sur la CTI, les TTPs connus, ou les anomalies observees.

2. Collecte de donnees

Identifier les sources de donnees necessaires (logs, netflow, endpoint telemetry) et les interroger.

3. Investigation

Analyser les resultats, pivoter sur les anomalies, approfondir les pistes suspectes.

4. Findings & Actions

Documenter les resultats, creer de nouvelles regles de detection, escalader si menace confirmee.

Outils de Threat Hunting

OutilTypeUsage principal
Elastic Security / ELKSIEM / Log analyticsRecherche dans les logs avec KQL, dashboards, alertes
SplunkSIEM / Log analyticsSPL pour requetes complexes, lookups, macros
VelociraptorEndpoint forensicsCollecte d'artefacts a distance, VQL, hunting sur fleet
RITANetwork analysisDetection de beaconing, DNS tunneling, long connections
Jupyter NotebooksData analysisAnalyse statistique avec Python, visualisations, reproductibilite
OSQueryEndpoint queryInterroger 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.

KQL — Identifier les connexions sortantes repetitives vers une meme destination
# 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
Elasticsearch — Analyse statistique du beaconing (intervalle entre connexions)
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.

KQL — Connexions RDP internes inhabituelles
# 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
KQL — Detection de PsExec et outils de lateral movement
# 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.

KQL — Taches planifiees suspectes (Sysmon + Security logs)
# 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\\*")
KQL — Modifications de cles de registre Run (persistance)
# 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.

KQL — Detection de compression suspecte (staging avant exfiltration)
# 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"
KQL — Uploads massifs suspects (exfiltration potentielle)
# 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
Analyse statistique pour la detection d'anomalies

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.

Contexte du scenario

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.

KQL — Consulter l'alerte EDR et les evenements correles
# 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.

KQL — Remonter l'arbre de processus du malware
# 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.

KQL — Mouvement lateral depuis le patient zero
# 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 ?

KQL — Recherche de persistance sur toutes les machines touchees
# 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.

KQL — Rechercher l'exfiltration de donnees
# 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.

Actions de containment executees
# 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 priorise
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
Timeline complete de l'attaque

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.

IR Investigation Lab — SOC MedTech SA
# Bienvenue dans le lab de reponse aux incidents
# Un ransomware a ete detecte sur le reseau de MedTech SA
# Objectif : mener l'investigation complete et contenir l'incident
# Tape 'help' pour voir les commandes disponibles
ir-analyst@soc $

Exercice 2 : Ordonne les phases NIST IR

Glisse chaque phase dans le bon ordre du processus NIST de reponse aux incidents.

Containment, Eradication & Recovery
Preparation
Post-Incident Activity
Detection & Analysis
① Phase 1
② Phase 2
③ Phase 3
④ Phase 4

Exercice 3 : Associe les artefacts aux phases de la Kill Chain

Glisse chaque artefact vers la phase Kill Chain correspondante.

Email avec piece jointe .docm
Beaconing regulier vers 45.33.12.88
Macro VBA execute PowerShell
Tache planifiee WindowsDefenderUpdate
Chiffrement de 1247 fichiers
Scan de ports 445/3389/5985
🔎 Reconnaissance
📨 Delivery
💣 Exploitation
🔧 Installation
📡 Command & Control
🎯 Actions on Objectives

✅ 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