Questions d'entretien SOC Analyst

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.

Non. Le fichier de test EICAR est une chaîne ASCII délibérément inoffensive de 68 octets que tous les éditeurs d'antivirus s'accordent à détecter, afin de vérifier en toute sécurité la détection et les alertes sans manipuler de vrai malware. Une détection signifie que votre antivirus fonctionne — pas que vous êtes infecté. Ce n'est pas un virus et il ne fait rien s'il est exécuté. Confondre une détection de test EICAR avec une vraie infection est un piège classique en début de carrière.

En grande partie non. Le nom d'hôte de destination est envoyé en clair dans l'extension SNI du ClientHello de TLS, et votre requête DNS le révèle généralement aussi, de sorte qu'un FAI ou un réseau peut voir QUEL site vous visitez même en HTTPS — il ne peut simplement pas lire le chemin ni le contenu. Le ClientHello chiffré (ECH) et le DNS-over-HTTPS peuvent combler cette faille, mais ils ne sont pas universels. « HTTPS cache tout » est l'idée fausse.

Non. Une MAC est attribuée par le fabricant (OUI plus identifiant de l'appareil) et « gravée », mais pratiquement chaque système d'exploitation permet de la remplacer en logiciel (macchanger, ip link set address). Les adresses MAC sont donc usurpables et ne doivent pas servir à l'authentification — le filtrage MAC est faible, et les téléphones randomisent désormais leur MAC par confidentialité. « Permanente et unique » est l'idée fausse.

Non. La MFA élève fortement la barre, mais les facteurs OTP et push sont hameçonnables : les kits d'adversaire au milieu (ex. Evilginx) relaient la connexion et le code en temps réel, et la fatigue MFA / le push-bombing poussent l'utilisateur à approuver. Les codes capturés sont réutilisables dans leur courte fenêtre. L'erreur est « MFA = inhameçonnable » ; c'est le type de facteur qui compte. La MFA résistante au phishing — les passkeys FIDO2/WebAuthn liés à l'origine du site — est ce qui déjoue réellement cela.

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.

Question piège : il n'existe pas de port unique pour traceroute. Le traceroute Unix classique envoie des datagrammes UDP vers des ports élevés et improbables à partir de 33434 environ, avec un TTL croissant ; le tracert de Windows utilise plutôt ICMP Echo. Il fonctionne en lisant les messages ICMP Time Exceeded que renvoient les routeurs à l'expiration du TTL, et non en visant un port réservé. Et ICMP lui-même n'a aucun port.

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.

Urgence, autorité et contournement de la vérification sont une pression d'ingénierie sociale de manuel visant un compte à forte valeur. L'agent doit suivre le processus de vérification d'identité défini avant toute réinitialisation, et escalader s'il ne peut pas être satisfait. Réinitialiser à la demande, utiliser une « question de sécurité » devinable comme la couleur préférée, ou envoyer le nouveau mot de passe par e-mail à l'appelant remettent tous le contrôle du compte du dirigeant à un attaquant.

LSASS stocke des identifiants et secrets en cache, donc un processus inattendu lisant sa mémoire est la signature d'un vol d'identifiants (par exemple un dump de type mimikatz). Triez le processus fautif et son parent, isolez l'hôte pour stopper le mouvement latéral, et renouvelez les identifiants susceptibles d'avoir été capturés — y compris les comptes privilégiés et de service. Cela n'a rien à voir avec le rendu graphique ou l'espace disque, et l'ignorer comme normal peut mener à une compromission de tout le domaine. Les distracteurs d'apparence anodine sont précisément la façon dont les analystes ratent une intrusion active.

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.

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.

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.

Des requêtes TXT à fort volume et forte entropie, ou de longs sous-domaines vers un seul domaine, sont une signature classique de tunneling DNS / C2-exfiltration : des données sont passées en douce dans le DNS pour échapper au filtrage de sortie. Capturez un échantillon de requêtes pour analyse, sinkholez ou bloquez le domaine pour couper le canal, et pivotez vers l'hôte pour trouver le processus responsable. L'écarter comme du cache normal ou un site lent laisse passer une exfiltration en cours. Redémarrer le serveur DNS ne fait rien contre le poste compromis et perturbe juste la résolution de noms.

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.

L'IA aide le SOC en triant et dédupliquant les alertes, en résumant les incidents, en enrichissant le contexte, en rédigeant des détections et en accélérant l'intégration des analystes — réduisant la fatigue et le temps de présence. Les risques : conclusions hallucinées ou fausses avec assurance, biais d'automatisation où les analystes cessent de vérifier, prompt injection via des données de logs ou d'alertes contrôlées par l'attaquant, fuite de données sensibles vers des modèles tiers, et adversaires utilisant les mêmes outils. Gardez un humain dans la boucle, vérifiez les sorties et isolez les entrées non fiables.

Le traitement non sécurisé des sorties consiste à faire confiance à ce que le modèle renvoie et à le transmettre à un système en aval sans validation ni encodage. Comme la sortie du modèle est influençable par l'attaquant, l'afficher en HTML brut cause du XSS, l'envoyer à un récupérateur d'URL cause du SSRF, et la passer à un shell ou une requête SQL cause une command ou SQL injection. La solution est de traiter la sortie du modèle exactement comme une entrée utilisateur non fiable : encodage de sortie sensible au contexte, allowlisting, assainissement et paramétrage avant qu'elle n'atteigne un sink.

Un jailbreak vise l'alignement de sécurité du modèle : il pousse le modèle à produire du contenu que le fournisseur a cherché à interdire, comme des instructions nuisibles. La prompt injection vise la hiérarchie d'instructions de l'application : elle écrase le system prompt du développeur ou détourne le comportement du modèle dans une application, souvent via des données non fiables. Les jailbreaks attaquent le modèle ; la prompt injection attaque le système environnant. Ils se recoupent, mais l'objectif et la frontière de confiance franchie diffèrent.

Le NIST AI Risk Management Framework (AI RMF 1.0) est un cadre volontaire et fondé sur le risque pour gouverner une IA digne de confiance tout au long de son cycle de vie. Son cœur est constitué de quatre fonctions : Govern (culture, politique, responsabilité — et elle traverse les autres), Map (contexte et identification des risques), Measure (évaluer et suivre les risques) et Manage (prioriser et répondre). Il définit aussi des caractéristiques de fiabilité — valide et fiable, sûr, sécurisé et résilient, responsable et transparent, explicable, respectueux de la vie privée et équitable. Il complète des listes techniques comme l'OWASP LLM Top 10 au niveau du programme.

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.

Sous Windows, les hashes des comptes locaux (NTLM) résident dans la ruche SAM sous C:\Windows\System32\config\SAM, protégée tant que l'OS tourne ; les identifiants vivants se trouvent dans la mémoire de LSASS, et les hashes de domaine sont dans NTDS.dit sur un contrôleur de domaine. Sous Linux, les hashes sont dans /etc/shadow (lisible uniquement par root), tandis que /etc/passwd contient les métadonnées de compte. Les attaquants les volent pour casser les mots de passe hors ligne ou faire du pass-the-hash.

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.

SPF publie quelles IP peuvent envoyer du courrier pour un domaine. DKIM ajoute une signature cryptographique pour que le destinataire puisse vérifier que le message n'a pas été altéré et provient bien du domaine. DMARC relie les résultats SPF/DKIM à l'en-tête From: visible via l'« alignement », dit aux destinataires quoi faire en cas d'échec (none/quarantine/reject) et envoie des rapports. SPF et DKIM seuls ne protègent pas le From que voit l'utilisateur — c'est DMARC qui l'impose.

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.

CloudTrail enregistre chaque appel API dans le compte — qui a fait quoi, quand, d'où — vous donnant la piste d'audit faisant autorité pour les investigations et la conformité. GuardDuty est un service géré de détection des menaces qui analyse CloudTrail, les flux VPC et les journaux DNS pour faire remonter des découvertes comme l'exfiltration d'identifiants ou le minage de cryptomonnaie. CloudTrail est la source de vérité que vous devez protéger ; GuardDuty transforme cette télémétrie en alertes exploitables.

Les security groups sont des pare-feux à état attachés aux instances/ENI : ils n'ont que des règles d'autorisation, et le trafic de retour d'un flux autorisé est automatiquement permis. Les network ACL sont des filtres sans état à la frontière du sous-réseau : ils ont des règles ordonnées d'autorisation et de refus, et vous devez autoriser explicitement le trafic de retour sur les ports éphémères. Les security groups sont le contrôle principal ; les NACL ajoutent des garde-fous grossiers au niveau du sous-réseau, comme bloquer une plage d'IP.

RSA est un algorithme asymétrique utilisé pour chiffrer des données ou créer des signatures numériques à l'aide d'une paire de clés. Diffie-Hellman est un protocole d'accord de clé qui permet à deux parties de dériver un secret partagé sur un canal public sans jamais le transmettre. Ils résolvent des problèmes différents : RSA prouve l'identité et peut encapsuler des clés ; DH négocie une clé de session — et sa variante éphémère assure la confidentialité persistante.

Kerberos repose sur un centre de distribution de clés (KDC) de confiance. Le client s'authentifie une fois auprès du serveur d'authentification et obtient un ticket d'octroi de tickets (TGT) chiffré avec la clé du KDC. Pour atteindre un service, il présente le TGT au service d'octroi de tickets et reçoit un ticket de service chiffré avec la clé de ce service. Le service le déchiffre et lui fait confiance. Les mots de passe ne traversent jamais le réseau, et les tickets ont une durée limitée.

La confidentialité persistante parfaite (PFS) signifie que chaque session dérive une clé unique d'un échange de clés éphémère jeté ensuite. Si un attaquant vole plus tard la clé privée à long terme du serveur, il ne peut toujours pas déchiffrer le trafic capturé précédemment, car cette clé n'a jamais servi à dériver les clés de session. Cela s'obtient avec un Diffie-Hellman éphémère (DHE/ECDHE).

Le client construit une chaîne du certificat serveur (feuille) en remontant par une ou plusieurs autorités de certification intermédiaires jusqu'à une autorité racine de son magasin de confiance. Il vérifie la signature de chaque certificat avec la clé publique de l'émetteur suivant, contrôle les dates de validité, la correspondance du nom/nom d'hôte, l'usage de la clé et la révocation (CRL/OCSP). La confiance se termine à une racine auto-signée pré-approuvée ; la chaîne n'est valide que si chaque maillon est correct.

Le client et le serveur se mettent d'accord sur un secret partagé en un seul aller-retour grâce au Diffie-Hellman éphémère (ECDHE). Le ClientHello transporte les groupes pris en charge et un key share ; le serveur répond avec son key share et son certificat, les deux parties dérivent les mêmes clés, et les données applicatives circulent immédiatement, avec la confidentialité persistante par défaut.

Un IDS (système de détection d'intrusion) surveille le trafic et lève des alertes mais ne bloque pas — il est généralement hors bande. Un IPS (système de prévention d'intrusion) se place en ligne dans le chemin du trafic et peut activement rejeter ou bloquer le trafic malveillant. L'IPS prévient, mais un faux positif peut casser du trafic légitime.

L'hameçonnage est une ingénierie sociale qui pousse les gens à révéler des identifiants, envoyer de l'argent ou exécuter un malware, généralement via de faux e-mails ou sites. La défense est en couches : filtrage et authentification des e-mails (SPF/DKIM/DMARC), MFA pour limiter les dégâts d'identifiants volés, formation de sensibilisation, et un moyen simple de signaler les messages suspects.

TCP est orienté connexion et fiable : il utilise une poignée de main en trois temps, garantit une livraison ordonnée et retransmet les paquets perdus. UDP est sans connexion et rapide, sans garantie de livraison, d'ordre ni de congestion. On utilise TCP pour l'exactitude (web, e-mail, transfert de fichiers) et UDP pour le trafic sensible à la vitesse (DNS, VoIP, streaming, jeux).

Un zero-day est une vulnérabilité que l'éditeur ne connaît pas encore (ou n'a pas corrigée), de sorte que les défenseurs ont eu « zéro jour » pour la corriger. Comme aucun correctif n'existe, la défense repose sur des contrôles en couches, la détection comportementale, la segmentation, le moindre privilège et une réponse rapide aux incidents plutôt que sur une signature.

Ni l'un ni l'autre. ARP est un protocole de couche 2 (couche liaison) encapsulé directement dans une trame Ethernet, et non dans un paquet IP. Comme il ne circule jamais sur IP, il ne peut utiliser ni TCP ni UDP, qui sont des transports de couche 4 nécessitant IP en dessous. Le rôle d'ARP est de résoudre une adresse IP connue en l'adresse MAC correspondante sur le même segment de réseau local.

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.

L'encodage transforme les données dans un autre format pour la compatibilité et est entièrement réversible par quiconque sans clé (par ex. Base64, encodage d'URL) : il n'offre aucune confidentialité. Le chiffrement n'est réversible qu'avec une clé et c'est lui qui assure la confidentialité. Le hachage est une fonction à sens unique : on ne peut pas retrouver l'entrée à partir de la sortie, ce qui le rend adapté aux contrôles d'intégrité et au stockage des mots de passe (avec un sel et une KDF lente).

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.

Non. Le cadenas signifie que le transport est chiffré et que le certificat est valide pour ce domaine : il ne dit rien sur l'honnêteté de l'opérateur ni sur le caractère malveillant du contenu. Des certificats gratuits et automatisés font que les sites d'hameçonnage et de logiciels malveillants ont presque toujours un cadenas parfaitement valide. HTTPS protège le canal, pas la destination.

HTTPS n'est pas un protocole à part entière : c'est du HTTP ordinaire circulant dans un tunnel TLS chiffré. SSL est l'ancien nom : SSL 2.0/3.0 sont les prédécesseurs obsolètes et non sécurisés de TLS, qui les a remplacés (TLS 1.0 à 1.3). Quand les gens disent « certificat SSL » ou « SSL », ils désignent presque toujours en réalité TLS.

Question piège : ping n'utilise aucun port. Il s'exécute sur ICMP, un protocole de couche 3 qui repose directement sur IP. Les ports n'existent que dans les protocoles de couche 4 comme TCP et UDP, donc ICMP (et donc ping) n'en a aucun. ICMP utilise à la place des champs de type et de code, par ex. Echo Request type 8 et Echo Reply type 0.

Trois. Le client envoie un SYN, le serveur répond par un SYN-ACK combiné (un seul paquet qui à la fois accuse réception du SYN du client et envoie le propre SYN du serveur), et le client termine par un ACK. L'astuce est que SYN-ACK est un seul paquet, pas deux, donc le total est de trois — exactement ce que désigne « en trois temps ».

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.

L'UEBA (User and Entity Behaviour Analytics) construit des référentiels comportementaux pour les utilisateurs et les entités (hôtes, comptes de service, appareils) et utilise des statistiques ou l'apprentissage automatique pour scorer les écarts comme du risque. Elle excelle face aux menaces sans signature nette : identifiants compromis, abus interne et déplacement latéral — p. ex. un utilisateur accédant soudain à des systèmes qu'il ne touche jamais, à des heures inhabituelles, ou déplaçant des volumes de données anormaux. Elle complète la détection basée sur des règles plutôt que de la remplacer, et nécessite un ajustement pour éviter les faux positifs dus aux changements de comportement légitimes.

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.

L'empaquetage compresse ou chiffre la vraie charge utile et y préfixe un stub qui la dépaquette en mémoire à l'exécution ; l'obfuscation transforme le code ou les données pour résister à la lecture et aux signatures. On détecte l'empaquetage à une entropie de section élevée proche de 8,0, une table d'imports minuscule ou réduite au stub, des noms de section inhabituels ou inscriptibles-exécutables comme UPX0, un point d'entrée hors de .text, une grande taille virtuelle face à une petite taille brute, et des détecteurs comme Detect It Easy ou PEiD. Aucun de ces signaux n'est concluant seul, donc les analystes en pèsent plusieurs ensemble et confirment en observant le dépaquetage à l'exécution.

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.

Une règle YARA comporte un bloc meta, une section strings (motifs texte, hexa ou regex, avec jokers et sauts) et une condition qui combine ces correspondances par une logique booléenne et de comptage. Une règle efficace s'appuie sur un élément durable et distinctif — un stub de code unique, un nom de mutex, un marqueur de configuration ou une combinaison d'imports inhabituelle — plutôt que sur des valeurs qu'un attaquant change trivialement comme un seul hash ou une chaîne générique. On équilibre la spécificité face aux faux positifs, on teste contre un corpus propre, et on documente la règle pour que d'autres lui fassent confiance et la maintiennent.

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é ».

SSH utilise TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS le 53 (UDP et TCP), RDP TCP 3389 et SMB TCP 445. Connaître les ports réservés permet de lire la sortie d'un scan, d'écrire des règles de pare-feu et de trier les alertes rapidement — un service sur son port attendu plutôt qu'inattendu est un signal immédiat.

Un résolveur stub demande un nom à un résolveur récursif. S'il n'est pas en cache, le résolveur récursif parcourt la hiérarchie : il interroge un serveur racine (qui pointe vers le TLD), le serveur TLD (qui pointe vers les serveurs autoritaires du domaine) et enfin le serveur autoritaire, qui détient l'enregistrement réel. La réponse est mise en cache en chemin selon son TTL. Le DNS utilise le port 53 — UDP pour la plupart des requêtes, TCP pour les volumineuses.

Traceroute découvre les routeurs entre vous et une destination en exploitant le champ TTL. Il envoie des paquets avec TTL=1, puis 2, puis 3, et ainsi de suite. Chaque routeur décrémente le TTL ; quand le TTL atteint zéro, ce routeur rejette le paquet et renvoie un message ICMP Time Exceeded, révélant son adresse. En augmentant le TTL, traceroute cartographie chaque saut dans l'ordre jusqu'à atteindre la destination.

Le modèle OSI divise le réseau en sept couches, chacune ajoutant une responsabilité : Physique (bits sur le câble), Liaison de données (trames et adressage MAC), Réseau (routage IP), Transport (TCP/UDP, ports, fiabilité), Session (gestion des connexions), Présentation (encodage, chiffrement, compression) et Application (protocoles comme HTTP). Chaque couche encapsule celle au-dessus à mesure que les données descendent la pile.

Un sous-réseau est une subdivision logique d'un réseau IP. Le masque de sous-réseau marque quels bits d'une adresse IP forment la partie réseau et quels bits forment la partie hôte — par exemple, /24 (255.255.255.0) signifie que les 24 premiers bits identifient le réseau et les 8 derniers les hôtes. Le découpage contrôle comment le trafic est routé et permet de segmenter un réseau en domaines de diffusion plus petits.

TCP ouvre une connexion en trois étapes. Le client envoie un SYN avec un numéro de séquence initial, le serveur répond par un SYN-ACK (accusant réception du numéro du client et envoyant le sien), et le client renvoie un ACK. Après cet échange, les deux parties se sont accordées sur les numéros de séquence de départ et la connexion est établie pour une livraison fiable et ordonnée des octets.

TCP est orienté connexion : il fait une poignée de main, numérote les octets, retransmet les pertes et contrôle la congestion, offrant une livraison fiable et ordonnée au prix de la latence et du surcoût. UDP est sans connexion et fonctionne en mode envoyer-et-oublier — pas de poignée de main, pas de retransmission, pas d'ordonnancement. Utilisez TCP quand l'exactitude compte (web, e-mail, transfert de fichiers) et UDP quand la vitesse prime sur la perfection (DNS, VoIP, jeux, vidéo).

Le modèle TCP/IP a quatre couches — Liaison, Internet, Transport et Application — et décrit le fonctionnement réel d'Internet. OSI en a sept. Elles correspondent étroitement : la couche Application de TCP/IP absorbe les couches Application, Présentation et Session d'OSI ; sa couche Liaison combine les couches Physique et Liaison de données d'OSI. OSI est la meilleure référence pour l'enseignement et le dépannage ; TCP/IP est la suite de protocoles réellement mise en œuvre.

Un VLAN (réseau local virtuel) partitionne logiquement un commutateur physique en domaines de diffusion de couche 2 distincts, de sorte que des appareils sur des VLAN différents ne peuvent pas se joindre directement, même sur le même matériel. Il est étiqueté par un marqueur 802.1Q sur les liens de trunk. La valeur de sécurité est la segmentation : isoler le trafic des utilisateurs, des serveurs, des invités et de l'IoT limite la portée des diffusions et le mouvement latéral, le trafic inter-VLAN étant forcé de passer par un routeur ou un pare-feu où la politique est appliquée.

Un VPN crée un tunnel chiffré au niveau réseau/OS, de sorte que tout le trafic d'un appareil y est routé et protégé de bout en bout — utilisé pour l'accès distant sécurisé. Un proxy opère au niveau applicatif, relayant le trafic d'applications ou de protocoles spécifiques sans nécessairement le chiffrer. Les grandes différences sont la portée (tout l'appareil vs par application) et le fait qu'un VPN chiffre par conception alors que de nombreux proxys ne le font pas.

Le chiffrement symétrique utilise une seule clé partagée pour chiffrer et déchiffrer : c'est rapide, mais la clé doit être partagée de façon sûre. Le chiffrement asymétrique utilise une paire de clés publique/privée, ce qui résout la distribution des clés mais lentement. Les vrais systèmes utilisent la cryptographie asymétrique pour échanger une clé de session symétrique, puis le chiffrement symétrique rapide pour les données en masse.

Une PKI est le système de CA, de certificats et de politiques qui lie les clés publiques aux identités. Pour valider un certificat de serveur, un client construit une chaîne jusqu'à une racine de confiance, vérifie chaque signature, contrôle les dates de validité et le nom d'hôte, confirme l'usage de la clé, et vérifie la révocation via CRL ou OCSP.

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é.