Questions d'entretien DFIR (Forensics & Incident Response)

Non. L'antivirus est un signal, pas une preuve. Il manque les attaques sans fichier et en mémoire, les échantillons inédits ou obfusqués, l'abus d'outils légitimes (living-off-the-land) et les rootkits conçus pour s'y cacher. L'absence de preuve n'est pas une preuve d'absence — la vraie assurance vient de la télémétrie EDR, de l'analyse forensique de la mémoire, de l'analyse comportementale et de la chasse aux IOC. Considérer un scan antivirus propre comme la preuve d'un système propre est une erreur classique de réponse à incident.

Pas à lui seul. De nombreux systèmes maintiennent valides les sessions existantes et les jetons déjà émis après un changement de mot de passe — jetons OAuth de rafraîchissement, « mots de passe d'application », clés d'API et cookies persistants — si bien qu'un attaquant disposant d'une session active peut rester. La bonne réponse est de changer le mot de passe ET d'invalider toutes les sessions et jetons, révoquer les identifiants d'application, et auditer les appareils MFA et les paramètres de récupération. Croire qu'une réinitialisation seule éjecte l'attaquant est une erreur classique de réponse à incident.

Non. La plupart des vraies intrusions établissent une persistance (services, tâches planifiées, clés de démarrage, implants) qui survit à un redémarrage, donc l'attaquant revient simplement. Pire, éteindre efface les preuves volatiles — processus en cours, connexions réseau, malware en mémoire et clés de chiffrement — dont vous avez besoin pour cadrer l'incident. La bonne action est de confiner en isolant l'hôte tout en préservant la mémoire, puis d'enquêter. Redémarrer ou éteindre comme « solution » est un réflexe néfaste.

Une reconstitution d'incident fiable provient de la corrélation de télémétries indépendantes en une seule chronologie : journaux d'authentification, données de processus/exécution de l'EDR, horodatages MAC du système de fichiers, flux réseau et événements SIEM, afin d'ordonner les actions et de borner la portée. Un seul journal ou le dernier événement à lui seul manque la chaîne et peut être trompeur ou falsifié. Deviner à partir d'une source ou interroger l'attaquant ne sont pas des méthodes d'investigation. La corrélation entre sources indépendantes révèle l'activité complète de l'attaquant et résiste à un attaquant ayant modifié l'une d'elles.

L'intégrité probante repose sur le hachage de l'image lors de l'acquisition (par exemple SHA-256) et la vérification ultérieure du hachage pour prouver qu'elle est inaltérée, le maintien d'une chaîne de possession documentée, et l'analyse d'une copie de travail pour que l'original reste intact. Renommer le fichier ne fait rien pour l'intégrité, et le compresser pour gagner de l'espace ne prouve pas l'intégrité ni n'aide la recevabilité. Toucher à l'original risque une destruction de preuves qui peut faire écarter la preuve. Hachez, documentez la possession et travaillez sur une copie vérifiée.

Un vide dans les journaux locaux pendant un incident peut signifier des journaux effacés ou falsifiés, une étape anti-forensique courante, donc ne traitez pas l'absence de journaux comme une absence d'activité. Recoupez avec des journaux centralisés/transférés, l'EDR et les données réseau que l'attaquant n'a probablement pas pu altérer, et consignez le vide d'intégrité comme un constat. Supposer que le serveur était inactif fait confiance à des preuves que l'attaquant contrôle peut-être, traiter le vide comme une preuve que rien ne s'est passé est exactement la conclusion qu'il veut, et supprimer d'autres journaux détruit ce qui reste. Corroborez plutôt avec une télémétrie indépendante.

Les sauvegardes sont nécessaires mais non suffisantes : la reprise d'activité et la continuité d'activité sont la capacité testée à restaurer l'activité dans les objectifs convenus de temps et de point de reprise (RTO/RPO), ce qui exige un plan documenté, des dépendances cartographiées, des runbooks et des restaurations validées — pas seulement l'existence de fichiers de sauvegarde. Affirmer qu'elles sont identiques confond une copie de données avec une capacité opérationnelle. Le PRA ne se résume pas à souscrire une assurance, qui transfère la perte financière mais ne restaure pas les systèmes. Et les sauvegardes ne rendent pas un PRA inutile — des sauvegardes non testées échouent régulièrement le moment venu. La clarification : le PRA doit être exercé, pas présumé.

La persistance Linux se cache dans les chemins d'exécution planifiée et de démarrage : cron et timers/unités systemd, clés ajoutées dans authorized_keys SSH, fichiers rc du shell et scripts de profil modifiés, et binaires de service ou bibliothèques préchargées trojanisés. Examinez-les systématiquement. L'historique du navigateur et les réglages du fond d'écran ne sont pas des mécanismes de persistance, et redémarrer ne supprimera rien qui se rétablit au démarrage — cela ne fait que le relancer. Tout l'intérêt de la persistance est de survivre aux redémarrages, donc un redémarrage ne prouve rien.

Ne détonez que dans une VM jetable et isolée, avec des snapshots et un réseau contrôlé (par ex. services simulés ou egress étroitement surveillé), afin que le malware ne puisse atteindre ni la production ni Internet sans contrôle. L'antivirus de votre portable ne contiendra pas un malware actif de façon fiable. Un serveur de production met en danger de vrais systèmes. La machine d'un collègue ne fait que déplacer le danger. L'isolation et les snapshots réversibles sont le cœur d'un labo de malware sûr.

L'identification de la famille guide les décisions : à partir de la note, de l'extension et des IOC, vous pouvez signaler l'existence d'un décrypteur gratuit, les TTP typiques du groupe (y compris le vol de données pour extorsion) et le rayon d'impact probable, au profit de l'équipe IR. Reformater détruit les preuves et l'information de portée. La grammaire de la note n'est pas exploitable. Recommander de négocier est une décision métier et juridique, pas le premier geste de l'analyste. Identifiez d'abord, puis aidez l'IR.

Les malwares vérifient couramment les artefacts de VM/sandbox, les durées d'exécution courtes ou l'interaction utilisateur et restent dormants s'ils les détectent. Déguisez et durcissez la VM d'analyse, prolongez l'exécution ou passez sur bare metal, et extrayez le comportement depuis une image mémoire de l'hôte vivant. Supposer qu'il est cassé ou que l'hôte se trompe ignore un échantillon prouvé malveillant en conditions réelles. Un redémarrage ne change rien car la logique d'évasion se déclenche à chaque exécution.

Commencez par un triage statique dans un environnement isolé : calculez les empreintes, extrayez les chaînes, inspectez les en-têtes PE et les imports, et vérifiez la réputation, afin de comprendre l'échantillon avant de risquer l'exécution. L'exécuter sur votre propre poste peut vous infecter, vous et le réseau. Téléverser des échantillons clients avec des noms identifiants divulgue des données sensibles à des tiers. Le supprimer détruit la preuve et la possibilité de bâtir des détections.

Word engendrant un processus enfant juste après l'activation des macros est un schéma classique d'accès initial par document malveillant. Isolez l'hôte pour limiter la propagation, capturez les preuves volatiles, et enquêtez sur le processus engendré, son activité réseau et toute persistance. Demander à l'utilisateur de fermer le fichier ou réparer Office ne traite pas une charge utile en cours d'exécution qui a peut-être déjà tourné. Ne rien faire parce que le fichier est arrivé par e-mail est à l'envers — l'e-mail est précisément le vecteur de livraison de cette attaque. Confinez d'abord, puis enquêtez.

Un logiciel légitime exécute rarement PowerShell depuis %TEMP% via une tâche planifiée fraîchement créée — c'est une technique courante de persistance et d'exécution. Examinez la définition de la tâche, le script invoqué, le processus créateur et la chronologie, confinez l'hôte, et balayez l'environnement à la recherche du même motif. Les mises à jour ne ressemblent pas à cela, faire confiance aveuglément aux tâches planifiées ignore une TTP connue, et supprimer System32 casse le système d'exploitation sans rien faire contre la menace. Les trois premières options reflètent toutes un jugement dangereusement faible.

Les simulations répètent le côté humain et décisionnel de la RI — qui a l'autorité de déclarer un incident, comment circule la communication juridique/RP/direction, et où le manuel se brise — afin que la première fois où vous prenez ces décisions ne soit pas en pleine crise réelle. Il est bien moins coûteux de trouver les failles lors d'un exercice qu'en pleine violation. Ce n'est pas une case de conformité vide, ce n'est pas pour attribuer des blâmes sur des incidents passés, et c'est transverse, pas réservé au SOC — la direction doit s'entraîner aux décisions qu'elle seule peut prendre.

Une violation chez un fournisseur est aussi votre incident : déclencher la réponse à incident pour cadrer quelles données et intégrations ont été exposées, faire tourner tous les secrets partagés, clés API et relations de confiance SSO, évaluer vos propres obligations de notification réglementaire et tenir le fournisseur à sa divulgation. Attendre passivement le fournisseur vous fait perdre le contrôle de votre propre calendrier et de vos obligations. Une résiliation publique du contrat est un effet de manche prématuré avant même de connaître votre exposition. Supposer que vous n'êtes pas touché saute précisément l'évaluation qu'attendent les régulateurs et vos clients.

Sans journaux d'audit du plan de contrôle, vous êtes aveugle à qui a fait quoi au niveau cloud, et détection, forensique et conformité dépendent toutes de cet enregistrement. Activez CloudTrail immédiatement, à l'échelle de l'org, en livrant vers un bucket séparé, à accès contrôlé et résistant à la falsification (immuable). Dire que ça n'a pas d'importance tant que rien ne va mal ignore que vous n'auriez aucun historique le jour où ça ira mal. Attendre un incident signifie que les premières actions décisives sont déjà non journalisées et irrécupérables. Les journaux applicatifs ne capturent pas l'activité API, IAM ou console du plan de contrôle.

Des données clients publiques constituent une exposition active : remédiez d'abord à l'accès en activant Block Public Access et en corrigeant la politique du bucket et la politique IAM pour stopper la fuite en cours. Récupérez ensuite les journaux d'accès (S3 server access logs / événements de données CloudTrail) pour évaluer ce qui a réellement été atteint, puis déclenchez les processus de violation et de notification prévus par la politique. Créer un ticket pour le prochain sprint laisse des données réglementées exposées pendant des jours. Copier les données ailleurs crée une seconde copie mais laisse le bucket d'origine ouvert. Renommer ne change rien à ses permissions.

Suivez l'ordre de volatilité. La RAM, les connexions réseau actives et la table des processus disparaissent à l'arrêt ; capturez-les donc en premier, puis prenez une image forensique du disque en documentant les empreintes et une chaîne de possession ininterrompue. Un arrêt propre détruit les preuves résidentes en mémoire — y compris le malware sans fichier et les clés qui n'existent qu'en RAM. Copier-puis-supprimer altère la scène et brise l'intégrité. Lancer l'antivirus de l'entreprise modifie le système et peut mettre en quarantaine ou supprimer l'artefact même que vous devez analyser.

Le confinement prime sur la restauration prématurée : stoppez la propagation en isolant les segments touchés et en coupant le vecteur — désactivez le compte de service abusé, bloquez SMB entre segments, retirez l'hôte de staging — tout en préservant les preuves, puis éradiquez et restaurez. Restaurer dans un réseau qui chiffre encore reperd les données restaurées. Payer la rançon n'arrête pas le chiffrement en cours et comporte un risque légal et de sanctions. Couper le courant de toutes les machines détruit les preuves volatiles et peut corrompre des fichiers en cours d'écriture, compliquant une restauration propre.

Éradiquer avant de comprendre la portée laisse l'attaquant persister sur des systèmes que vous n'avez pas trouvés et simplement revenir. Chassez vite les IOC et les identifiants volés sur tout le parc, identifiez chaque hôte touché et chaque mécanisme de persistance, puis éradiquez partout d'un coup. Effacer un seul hôte est du whack-a-mole qui alerte l'attaquant tout en laissant ses autres points d'ancrage intacts. Une coupure totale d'internet d'une semaine est disproportionnée et nuit à l'entreprise. Supprimer juste le fichier malveillant ignore la persistance, le mouvement latéral et les identifiants déjà volés.

Découvrir une intrusion active est une urgence hors bande : les règles d'engagement doivent définir une procédure d'escalade, alors déclenchez-la immédiatement, préservez les preuves et évitez de contaminer un incident en cours. Continuer à tester peut interférer avec le vrai attaquant ou détruire les preuves mêmes dont les intervenants ont besoin. Tenter d'expulser l'attaquant vous-même est hors périmètre, risqué et peut l'alerter. Attendre le rapport final pourrait signifier des jours de violation continue et de perte de données.

Réduisez les faux positifs par l'ingénierie de détection, pas en vous aveuglant. Réajustez pour que les alertes ne se déclenchent que sur les motifs qui comptent — un même mot de passe testé sur de nombreux comptes (spraying), un compte attaqué de nombreuses fois (stuffing/force brute), voyage impossible — tout en gardant les événements bruts consultables sur un tableau de bord. Mesurez ensuite la précision des alertes dans le temps. Désactiver la règle supprime un signal réel, une suppression globale crée un angle mort permanent, et embaucher des gens pour trier du bruit pur ne passe pas à l'échelle et les épuise.

Validez avant d'escalader. Les VPN d'entreprise, les proxys cloud (CASB ou IP de service M365) et les opérateurs mobiles produisent régulièrement de faux « voyages impossibles » ; vérifiez donc les IP de sortie, le résultat MFA et l'appareil/user-agent avant d'agir. Verrouiller à chaque déclenchement provoque de la fatigue d'alertes et érode la confiance des utilisateurs envers le SOC. Supposer que c'est toujours un faux positif laisse passer une vraie compromission de compte. Écrire au manager est lent et n'est pas un contrôle — les journaux répondent plus vite et plus sûrement.

Supposez le mot de passe déjà compromis : forcez une réinitialisation ET invalidez les sessions et jetons actifs du compte, car un simple reset n'évince pas un attaquant qui détient déjà une session active ou un jeton de rafraîchissement. Chassez ensuite les connexions anormales, les invites MFA, les règles de boîte mail et les autorisations OAuth créées pendant la fenêtre d'exposition. Supprimer l'e-mail ou dire à l'utilisateur de changer son mot de passe « la prochaine fois » laisse le compte grand ouvert. Un scan antivirus traite le malware sur le poste, pas les identifiants volés dans le cloud.

Triez par impact et accessibilité : un dumping d'identifiants (signature mimikatz) sur un contrôleur de domaine est un événement touchant les joyaux de la couronne, pouvant mener à la compromission complète du domaine ; traitez-le en premier. Le scan de ports externe a déjà été bloqué par l'IDS, l'extension de navigateur non approuvée est de faible gravité, et un certificat TLS expiré sur une machine de test interne est informatif. La compétence SOC clé est de prioriser par rayon d'impact et probabilité d'escalade, pas par l'ancienneté ni le « bruit » de l'alerte.

Le credential stuffing rejoue des paires identifiant:mot de passe connues issues de fuites tierces, en pariant sur la réutilisation des mots de passe — taux de réussite élevé par tentative, souvent réparti sur de nombreuses IP et machines pour paraître humain. Le password spraying essaie un ou deux mots de passe courants (comme Winter2026!) sur de nombreux comptes afin de rester sous les seuils de verrouillage. Le stuffing exploite la réutilisation ; le spraying exploite les mots de passe partagés faibles. La MFA déjoue les deux.

La Cyber Kill Chain modélise une intrusion en sept étapes séquentielles : reconnaissance, militarisation, livraison, exploitation, installation, commande et contrôle (C2), et actions sur les objectifs. Les défenseurs associent des détections et des contrôles à chaque étape ; comme les étapes sont séquentielles, briser un seul maillon — bloquer l'e-mail de phishing, tuer le C2 — perturbe toute l'attaque. Cela pousse à détecter tôt plutôt qu'à la seule intrusion finale.

L'exfiltration DNS encode des données volées dans des requêtes DNS (par ex. de longs labels de sous-domaine envoyés à un serveur autoritaire contrôlé par l'attaquant), en abusant du fait que le DNS est presque toujours autorisé en sortie et souvent non surveillé. Détectez-la par des anomalies : volume de requêtes anormalement élevé vers un domaine, sous-domaines longs / à forte entropie, nombreux sous-domaines uniques par domaine parent, abus d'enregistrements TXT/NULL, et requêtes vers des domaines récemment enregistrés ou rares.

L'antivirus traditionnel compare les fichiers à des signatures de malwares connus et les bloque ou les met en quarantaine — efficace contre les menaces connues, faible contre les attaques nouvelles ou sans fichier. L'EDR enregistre en continu le comportement du poste (processus, réseau, registre, mémoire), utilise l'analyse comportementale pour détecter l'activité suspecte, et permet aux intervenants d'investiguer, de traquer et de contenir ou restaurer à distance. L'AV est de la prévention par signature ; l'EDR ajoute visibilité, détection et réponse.

Le modèle classique est PICERL : Préparation, Identification (détection), Confinement, Éradication, Restauration et Retour d'expérience. Le NIST le regroupe en : Préparation ; Détection et analyse ; Confinement, éradication et restauration ; et Activité post-incident. L'ordre compte car il faut cerner et confiner avant d'éradiquer, et l'on ne restaure qu'une fois la menace supprimée — sinon on réinfecte. C'est une boucle, pas une ligne : le retour d'expérience nourrit la préparation.

Un IOC est un artefact forensique prouvant que quelque chose de malveillant s'est déjà produit — un hash de fichier malveillant, une IP ou un domaine de C2, une clé de registre connue comme néfaste. Un IOA est un signal comportemental d'une attaque qui se déroule, indépendamment des outils précis — par ex. un document Word qui lance PowerShell, puis se connecte à Internet. Les IOC sont réactifs et faciles à contourner en changeant un hash ; les IOA capturent l'intention et survivent aux changements d'outils.

La persistance est la façon dont un malware survit aux redémarrages et aux déconnexions. Les incontournables sous Windows sont les clés Run/RunOnce du registre (HKLM et HKCU), les tâches planifiées et les services Windows, plus les dossiers de démarrage, les abonnements aux événements WMI et le détournement de DLL. On les traque avec autoruns/Sysinternals, Sysmon et les journaux d'événements — en cherchant des binaires non signés, des chemins étranges comme %AppData% et des entrées créées juste après la compromission initiale.

L'ordre de volatilité classe les preuves selon leur vitesse de disparition, pour collecter les plus fragiles en premier. Grosso modo : registres/cache CPU, puis RAM et état d'exécution (processus, connexions réseau, ARP), puis fichiers temporaires/swap, puis disque, puis journalisation et données de supervision distantes, et enfin supports d'archivage et sauvegardes. On travaille aussi sur des copies forensiques, on les hashe, et on maintient une chaîne de possession pour que la preuve reste recevable.

L'injection de processus exécute le code de l'attaquant dans l'espace mémoire d'un processus légitime pour que l'activité se fonde dans la masse et hérite de la confiance de ce processus. Les techniques classiques incluent l'injection de DLL (CreateRemoteThread + LoadLibrary), le process hollowing (lancer un processus bénin suspendu, le démapper, y écrire du code malveillant) et l'injection d'APC. Les défenseurs la détectent via les hooks d'API de l'EDR, des relations parent/enfant ou des régions mémoire anormales (RWX, mémoire exécutable non adossée à un fichier) et les événements CreateRemoteThread de Sysmon.

Un ransomware est un malware qui chiffre (et de plus en plus exfiltre) des données, puis exige un paiement. En cas actif : isoler les hôtes touchés du réseau sans les éteindre si vous pouvez préserver la mémoire, cerner l'ampleur, le patient zéro et la souche, préserver les preuves, trouver et évincer le point d'ancrage et toute porte dérobée, puis restaurer depuis des sauvegardes hors ligne réputées saines. Payer est un dernier recours et ne garantit jamais la récupération.

L'analyse statique examine un échantillon sans l'exécuter — hashes, chaînes, imports, en-têtes et désassemblage — donc elle est sûre et couvre tout, mais elle est déjouée par le packing et l'obfuscation. L'analyse dynamique détone l'échantillon dans un bac à sable isolé et observe le comportement réel — fichiers, registre, processus, réseau — ce qui perce l'obfuscation mais ne révèle que ce qui s'exécute dans cette session et peut être contourné par des malwares conscients du bac à sable. Les analystes combinent les deux.

Un honeypot est un système ou service leurre sans usage métier légitime, délibérément exposé pour attirer les attaquants. Comme rien de bénin ne devrait jamais le toucher, toute interaction est une alerte hautement fiable. Les honeypots à faible interaction émulent des services à peu de frais ; ceux à forte interaction sont de vrais systèmes qui livrent une intel plus riche mais comportent plus de risque. Les honeytokens sont la même idée appliquée à de faux identifiants, fichiers ou enregistrements. Valeur : détection précoce, peu de faux positifs et threat intelligence.

Le journal Security est primordial : 4624 connexion réussie (avec type de connexion), 4625 connexion échouée, 4634/4647 déconnexion, 4672 privilèges spéciaux attribués, 4720 compte créé, 4688 création de processus (avec ligne de commande si activée), et 4768/4769 Kerberos. Ajoutez 7045 installation de service (journal System), 4698 tâche planifiée créée, et la journalisation des blocs de script PowerShell (4104). Le type de connexion et l'audit des lignes de commande sont ce qui rend ces journaux utiles.

La continuité d'activité (BCP) est la stratégie globale visant à maintenir les fonctions métier critiques pendant et après une perturbation ; la reprise après sinistre (DRP) en est le sous-ensemble informatique qui restaure les systèmes et les données. Le RTO est le temps maximal tolérable pour rétablir une fonction ; le RPO est la perte de données maximale tolérable mesurée en temps.

L'analyse quantitative attribue des valeurs monétaires concrètes pour calculer la perte attendue ; l'analyse qualitative classe le risque sur des échelles relatives (élevé/moyen/faible) par jugement d'expert. La quantitative utilise SLE = valeur de l'actif x facteur d'exposition, ARO = occurrences attendues par an, et ALE = SLE x ARO pour exprimer la perte annuelle attendue en euros.

Parce que « supprimer » n'efface normalement pas les données. Cela enlève les métadonnées du système de fichiers (le pointeur/l'entrée de répertoire) et marque les blocs comme libres, mais les octets d'origine restent sur le disque jusqu'à ce que le système d'exploitation réutilise ces blocs pour de nouvelles données. Tant que cette réécriture n'a pas eu lieu, des outils forensiques peuvent extraire le contenu directement.

D'un point de vue purement sécurité, un faux négatif est généralement pire : il signifie qu'une vraie attaque n'a pas été détectée, donc pas de réponse, pas de confinement, et la brèche peut rester tapie sans être découverte. Mais les faux positifs ne sont pas anodins : en grand nombre, ils provoquent la fatigue d'alerte, où les analystes commencent à ignorer les alertes et manquent la vraie. La bonne réponse nomme le compromis, pas seulement un gagnant.

Un référentiel est un modèle du comportement normal d'un hôte, d'un utilisateur, d'un compte ou d'un segment réseau — quels processus s'exécutent, qui se connecte d'où et quand, les volumes de données typiques, les intervalles normaux de beaconing. Une fois la normalité connue, les anomalies (paires processus parent-enfant rares, binaires vus pour la première fois, connexions à des heures inhabituelles, exfiltration de données inhabituelle) deviennent détectables comme des écarts. L'établissement d'un référentiel est le fondement de la détection d'anomalies, mais il exige un historique propre suffisant et une gestion soigneuse des changements légitimes pour ne pas se noyer sous les faux positifs.

Le beaconing C2 est le check-in périodique qu'un implant effectue auprès de son contrôleur. Chassez-le dans la télémétrie réseau/proxy/DNS en cherchant la régularité : connexions vers une destination à intervalles quasi fixes (même avec du jitter), petites requêtes uniformes, faibles ratios données-entrantes / données-sortantes, destinations rares de longue durée, et empreintes TLS/JA3 suspectes ou user-agents étranges. Le signal est le rythme et la rareté de la destination, pas le payload — qui est généralement chiffré.

Partez des techniques que vous voulez détecter, puis remontez jusqu'à la télémétrie qui les révèle — le mappage des sources de données d'ATT&CK y aide. En pratique, les sources à plus forte valeur sont la télémétrie endpoint des processus/lignes de commande et des chargements de modules (EDR/Sysmon), les journaux d'authentification et d'identité, le DNS et les flux proxy/réseau, et les journaux du plan de contrôle cloud. Vous auditez ensuite ce que vous collectez et conservez réellement face à ce dont chaque technique a besoin, exposant les angles morts. Une technique invisible dans tout journal n'est pas encore chassable.

L'ingénierie de détection traite les détections comme un produit logiciel doté d'un cycle de vie : identifier une menace ou technique à couvrir, étudier la télémétrie et le comportement, développer la règle, la tester face à des données de vrais positifs et bénignes, la déployer (souvent par étapes), la valider par émulation d'adversaire, puis l'ajuster en continu pour les faux positifs et retirer les règles qui ne se justifient plus. Chaque étape est documentée et versionnée, et la couverture est suivie par rapport à un cadre comme ATT&CK.

Les LOLBins (living-off-the-land binaries) sont des outils système légitimes, signés et préinstallés — comme certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, powershell — que les attaquants détournent pour télécharger, exécuter ou persister tout en se fondant dans l'activité d'administration normale. Comme le binaire lui-même est de confiance, on ne peut pas détecter sur le fichier ; on détecte sur le contexte : arguments de ligne de commande anormaux, processus parents inhabituels, connexions réseau inattendues depuis ces outils, et exécution depuis des chemins étranges ou par des utilisateurs inhabituels.

La Pyramid of Pain classe les types d'indicateurs selon le coût pour un attaquant de les modifier une fois que vous détectez dessus. Les hashs sont triviaux à altérer (en bas), puis les adresses IP, les noms de domaine, les artefacts réseau/hôte, les outils, et enfin les TTP au sommet — qu'un attaquant ne peut changer qu'en réoutillant fondamentalement son comportement. Détecter aux niveaux supérieurs cause plus de « douleur » et est plus durable, donc les programmes matures investissent l'effort de détection vers les comportements et les TTP plutôt que les seuls IOC.

La chasse basée sur les TTP utilise MITRE ATT&CK comme carte : choisissez une technique pertinente pour votre modèle de menace (idéalement à faible couverture), formez une hypothèse concrète sur la façon dont elle apparaîtrait dans votre télémétrie, identifiez les sources de données qui la révèlent, interrogez-les et analysez les résultats. Une bonne chasse est délimitée, guidée par des hypothèses, liée à un comportement réel d'adversaire, reproductible, et produit un résultat durable — une nouvelle détection, une lacune de couverture documentée, ou la preuve que la technique est absente — qu'elle trouve ou non une compromission.

La chasse aux menaces est la pratique proactive, guidée par des hypothèses, qui consiste à fouiller la télémétrie pour y trouver l'activité d'un adversaire que les détections existantes ont manquée. Contrairement au tri des alertes — réactif et qui attend qu'un outil se déclenche — la chasse part d'une question (« si un attaquant faisait X, quelles preuves verrais-je ? »), la teste face aux données, et soit trouve quelque chose, soit produit une nouvelle détection. Elle suppose que la prévention et les alertes sont imparfaites et qu'un adversaire déterminé est peut-être déjà à l'intérieur.

Sigma est un format YAML ouvert et neutre vis-à-vis des éditeurs pour décrire des détections SIEM. Vous définissez une logsource (product/category, par exemple Windows process_creation), un bloc detection avec des sélections nommées de correspondances champ/valeur, et une condition qui les combine. Un convertisseur (comme sigma-cli/pySigma) traduit la règle dans le langage de requête de votre backend réel — Splunk, Sentinel, Elastic — de sorte qu'une seule règle est portable. Elle porte aussi des métadonnées : title, level, status, faux positifs et tags ATT&CK.

On classe selon ce que l'échantillon est conçu pour faire, observé à partir de son comportement et de ses capacités. Un dropper transporte et écrit une charge utile sur le disque ; un loader récupère ou injecte l'étape suivante, souvent uniquement en mémoire ; un RAT donne à un opérateur un contrôle distant interactif ; un wiper détruit les données ou les enregistrements d'amorçage sans intention de récupération ; un ransomware chiffre les fichiers et exige un paiement. Les vrais échantillons combinent souvent les rôles — un loader qui déploie un RAT — donc on décrit la chaîne de capacités plutôt que d'imposer une étiquette unique, et on associe chaque comportement aux techniques ATT&CK.

Le beaconing de commande et contrôle, c'est l'implant qui appelle périodiquement la maison pour des instructions. On le reconnaît à des rappels sortants réguliers et de faible volume à intervalle à peu près fixe — souvent avec du jitter pour éviter de paraître mécanique — vers un petit ensemble de destinations, fréquemment via HTTP/HTTPS ou DNS avec des charges utiles encodées ou chiffrées et un User-Agent ou un motif d'URI distinctif. On extrait les indicateurs statiquement en tirant domaines, IP, URI et clés des chaînes et blocs de config, et dynamiquement en détonant l'échantillon contre un réseau factice et en capturant les vrais rappels, puis on associe le comportement à ATT&CK et on alimente les IOC dans la détection.

Un laboratoire sécurisé isole le malware de tout ce qu'il pourrait endommager. Vous exécutez les échantillons dans des VM jetables sur un hyperviseur, prenez des snapshots propres pour pouvoir revenir en arrière après chaque détonation, et coupez tout accès réseau réel via un réseau host-only avec un Internet simulé (INetSim ou FakeNet) ou un segment isolé physiquement. Vous séparez la machine d'analyse d'une passerelle contrôlée, n'analysez jamais sur votre poste de travail quotidien, durcissez contre l'évasion de VM, manipulez les échantillons sous forme de zips protégés par mot de passe, et gardez l'outillage et les indicateurs hors de la VM de détonation. L'objectif est d'observer un comportement réel tout en garantissant que l'échantillon ne peut atteindre ni la production ni Internet.

Un malware conscient du sandbox vérifie s'il est observé avant de mal se comporter. Il cherche des artefacts de VM et d'hyperviseur (pilotes, préfixes MAC, clés de registre, CPUID), des outils d'analyse et débogueurs (noms de processus, IsDebuggerPresent, temporisation du pas-à-pas), et des signes d'un vrai utilisateur (peu de processus, aucun document récent, pas de mouvement de souris, faible uptime, petit disque). Il peut temporiser avec de longs sommeils ou ne se déclencher qu'à une date, une langue ou un domaine précis. Les analystes y font face en durcissant la VM pour la rendre réaliste, en neutralisant les vérifications par patch, en accélérant les sommeils, en simulant l'activité utilisateur, et en confirmant le comportement par désassemblage statique.

L'outillage statique lit l'échantillon au repos : PEStudio, CFF Explorer et pefile pour les en-têtes et imports, FLOSS et strings pour le texte embarqué, capa pour la cartographie des capacités, et Ghidra ou IDA pour le désassemblage. L'outillage dynamique l'observe s'exécuter dans une VM isolée : Procmon et Process Hacker pour l'activité hôte, Wireshark et INetSim ou FakeNet pour le réseau simulé, Regshot pour les diffs avant/après, et x64dbg pour le pas-à-pas contrôlé. Le workflow consiste à trier statiquement, détoner dynamiquement, puis revenir au désassembleur pour combler les lacunes comportementales.

Le DFIR suit un processus rigoureux : identification (confirmer et délimiter l'incident), acquisition (préserver les preuves selon l'ordre de volatilité, avec images forensiques et empreintes), analyse (chronologie, cause racine, étendue de la compromission) et reporting (constats pour des publics techniques et juridiques). La chaîne de possession documente qui a manipulé chaque artefact et quand, afin que la preuve tienne si elle arrive un jour devant un tribunal. Préserver avant de remédier.

ATT&CK est une base de connaissances des tactiques (le pourquoi), techniques (le comment) et procédures adverses réelles. Vous l'utilisez pour cartographier vos détections existantes sur la matrice, repérer les lacunes de couverture et prioriser les techniques employées par les acteurs qui ciblent réellement votre secteur. Il offre un langage commun entre CTI, ingénierie de détection et réponse à incident, transformant « sommes-nous sécurisés ? » en une carte de couverture concrète et mesurable, fondée sur le comportement adverse réel.

Le purple teaming est collaboratif plutôt qu'adversarial : le côté rouge exécute des TTP précis et convenus (souvent reliés à MITRE ATT&CK) pendant que le côté bleu observe sa télémétrie en temps réel pour confirmer si chaque technique est journalisée, alertée et détectable. On mesure la couverture de détection technique par technique, on ajuste les détections et comble les lacunes immédiatement, puis on re-teste. Le livrable est une détection améliorée et mesurable — pas une liste de qui a « gagné ».

Un bon rapport sert deux publics : un résumé exécutif qui cadre le risque métier pour la direction, et des trouvailles détaillées et reproductibles avec preuves, évaluations de risque exactes et remédiation priorisée pour l'équipe technique. Le rapport — et non l'exploit — est le livrable.

Un SDLC sécurisé intègre la sécurité à chaque phase plutôt que de la rajouter à la fin. Les exigences incluent des cas de sécurité et d'abus, la conception ajoute la modélisation des menaces, le développement utilise le codage sécurisé et le SAST plus l'analyse des dépendances, les tests ajoutent le DAST et les tests d'intrusion, et l'exploitation ajoute la surveillance, les correctifs et la réponse aux incidents — en décalant la sécurité vers la gauche.

La fatigue d'alerte est la désensibilisation qui s'installe lorsque les analystes font face à trop d'alertes peu utiles ou de faux positifs, ce qui les pousse à manquer ou à bâcler les vraies. On la combat en affinant les règles bruyantes, en priorisant par le risque, en dédupliquant et regroupant les alertes liées, en automatisant l'enrichissement répétitif avec un SOAR, et en mesurant la qualité des alertes, pas seulement leur volume.

La force brute cible un seul compte avec de nombreuses tentatives de mot de passe, on voit donc beaucoup d'échecs concentrés sur un même identifiant. Le password spray inverse la logique : un ou quelques mots de passe courants essayés sur de nombreux comptes, lentement et discrètement, de sorte que chaque compte ne voit que quelques échecs. Le signal de détection est le ratio comptes/échecs et le timing, pas le nombre brut d'échecs.

Presque tout passe par le DNS, donc les logs DNS révèlent des menaces que d'autres sources manquent : le beaconing de command-and-control (rappels réguliers vers un domaine), le tunneling et l'exfiltration DNS (gros volume de sous-domaines longs et encodés), et les domaines générés algorithmiquement (DGA). On les détecte via des motifs comme la régularité des requêtes, l'entropie, les types d'enregistrement et le volume, plutôt que par une seule résolution suspecte.

L'EDR est centré sur l'endpoint : il enregistre et répond à l'activité des processus, fichiers et réseau sur les hôtes. Le XDR étend cette corrélation à plusieurs domaines — endpoint, réseau, identité, e-mail, cloud — en une stack intégrée par un même éditeur. Le SIEM est la couche large d'agrégation de logs qui ingère des données de n'importe quelle source, y compris non liées à la sécurité, pour la détection, la recherche et la conformité.

Comprenez d'abord pourquoi la règle se déclenche autant — trouvez le motif bénin commun derrière le bruit. Écrivez ensuite l'exclusion la plus étroite possible (hôte, compte ou comportement précis), documentez la justification, et validez qu'un vrai positif se déclencherait encore. Évitez les suppressions larges qui créent discrètement des angles morts.

Le mouvement latéral, c'est un attaquant qui utilise un point d'appui pour atteindre d'autres systèmes. Les signes incluent des logons réseau inattendus (type 3) et RDP (type 10), l'accès aux partages admin comme C$ et ADMIN$, des outils d'exécution distante tels que PsExec, WMI et WinRM, des motifs de pass-the-hash, et un compte normalement local qui s'authentifie soudain sur de nombreux hôtes.

ATT&CK est une base de connaissances des tactiques et techniques adverses réelles. Dans un SOC, vous mappez chaque règle de détection aux techniques qu'elle couvre, construisez une carte de couverture (souvent avec l'ATT&CK Navigator), puis priorisez la fermeture des lacunes selon les techniques les plus pertinentes pour votre modèle de menace et celles sur lesquelles vous n'avez aucune visibilité.

Examinez l'e-mail sans cliquer : vérifiez les en-têtes et l'authentification de l'expéditeur (SPF/DKIM/DMARC), inspectez les URL et pièces jointes en sandbox ou avec des outils de réputation, puis mesurez la portée — qui d'autre l'a reçu, quelqu'un a-t-il cliqué ou saisi des identifiants. Selon les constats, remédiez en purgeant l'e-mail, en bloquant les indicateurs et en réinitialisant les identifiants exposés.

Un SIEM ingère et corrèle les logs de tout le parc pour générer des alertes — c'est votre couche de détection et de recherche. Un SOAR se situe en aval et automatise la réponse : il exécute des playbooks, enrichit les alertes via des intégrations, et gère les cas pour que les analystes passent moins de temps sur les étapes répétitives.

Confirmez que l'alerte est réelle avant d'agir : lisez ce qui s'est déclenché et pourquoi, puis enrichissez — qui est l'utilisateur, l'IP/géo/appareil source sont-ils attendus, est-ce un voyage impossible, y a-t-il eu des échecs antérieurs ? Classez en vrai ou faux positif, escaladez ou confinez si c'est réel (désactiver la session, forcer une réinitialisation MFA), et documentez tout pour que le prochain analyste puisse suivre votre raisonnement.

4624 est un logon réussi, 4625 est un logon échoué, et 4688 est une création de processus. Dans une enquête, vous utilisez 4625 pour repérer les attaques d'identifiants, 4624 (avec son type de logon et sa source) pour confirmer un accès réussi et comment il s'est produit, et 4688 pour voir ce qui a réellement été exécuté, idéalement avec l'audit de ligne de commande activé.