Livre blanc

Méthodologie de recherche de menaces : guide pratique pour détecter les menaces avancées

La chasse proactive aux menaces permet aux équipes de sécurité de détecter les menaces avancées 11 jours plus tôt et d'économiser en moyenne 1,3 million de dollars par incident (Gartner, Prioritize Threat Hunting for the Early Detection of Stealthy Attacks, Oct 2025).

Ce guide complet vous explique comment mettre en œuvre la chasse aux menaces à l'aide de la Vectra AI , en utilisant des métadonnées optimisées par l'IA, la recherche assistée par l'IA, des requêtes prédéfinies et des workflows reproductibles afin de détecter les comportements cachés des attaquants avant qu'ils ne s'aggravent.

Dans ce guide, vous apprendrez à :

  • Apprenez à rechercher les tactiques , techniques et procédures (TTP) des attaquants pour détecter les comportements furtifs qui échappent aux alertes traditionnelles, comme les authentifications forcées, la récupération de clés DPAPI ou l'utilisation non standard de SSH.
  • Explorez les recherches basées sur la conformité qui mettent en évidence les protocoles obsolètes, les configurations non sécurisées et l'utilisation non autorisée des services d'IA avant qu'ils ne créent des risques d'audit ou de réglementation.
  • Découvrez comment rechercher des indicateurs de compromission (IOC), notamment des domaines, des adresses IP et des hachages de fichiers malveillants, afin de valider les expositions et de confirmer l'endiguement.
  • Découvrez comment les métadonnées optimisées par l'IA accélèrent les enquêtes et offrent une visibilité plus approfondie sur le réseau, les identités et cloud.
Méthodologie de recherche de menaces : guide pratique pour détecter les menaces avancées
Sélectionner la langue à télécharger
Accès
Livre blanc

Les équipes de sécurité modernes ne peuvent plus se contenter des seules alertes. Les attaquants restent actifs dans les environnements pendant des jours, voire des semaines, avant que les outils de détection ne révèlent leurs activités — et les menaces les plus sophistiquées sont spécialement conçues pour éviter de déclencher les règles automatisées. Une méthodologie structurée de recherche de menaces comble cette lacune : elle permet de passer d'un système d'alerte réactif à une enquête proactive, en partant du principe que quelque chose ne va peut-être déjà pas et en recherchant systématiquement des indices.

Ce guide explique en quoi consiste la méthodologie de recherche de menaces, comment les équipes de sécurité de premier plan organisent leurs programmes de recherche, et comment mettre en œuvre ces cadres à l'aide de la Vectra AI dans des environnements hybrides couvrant les infrastructures réseau, d'identité, cloud et SaaS.

Ce document s'adresse aux analystes SOC, aux ingénieurs en détection et aux architectes de sécurité qui mettent en place ou perfectionnent une stratégie proactive de recherche de menaces.

Qu'est-ce qu'une méthodologie de recherche de menaces ?

Une méthodologie de recherche de menaces est une approche structurée visant à rechercher de manière proactive les menaces qui n'ont pas encore déclenché d'alertes automatisées. Plutôt que d'attendre qu'une règle de détection se déclenche, les chasseurs partent du principe qu'un problème pourrait déjà exister et recherchent des indices comportementaux. Ils combinent les renseignements sur les menaces, leur connaissance des tactiques des attaquants et leur maîtrise de leur propre environnement pour mettre en évidence les activités qui ne correspondent pas aux schémas attendus.

Une méthodologie complète de recherche de menaces définit trois éléments : ce qu'il faut rechercher (l'hypothèse), comment le rechercher (la technique) et ce qu'il faut faire lorsqu'on trouve quelque chose (le processus de réponse).

Les trois méthodologies de recherche de menaces les plus couramment utilisées sont les suivantes :

Méthodologie À quoi cela s'adresse Idéal pour
Chasse au TTP Comportements et techniques des attaquants mis en correspondance avec des référentiels tels que MITRE ATT&CK Détection des menaces avancées qui échappent aux outils basés sur les signatures
Chasse axée sur la conformité Violations des politiques, configurations non sécurisées et infractions aux limites réglementaires Détecter les erreurs de configuration et les lacunes dans l'application des règles avant qu'elles ne se transforment en incidents
Chasse basée sur le CIO Éléments identifiés comme appartenant à des attaquants — domaines, adresses IP, hachages de fichiers et jetons Vérification de l'exposition à la suite d'une alerte de renseignements sur les menaces ou de la divulgation d'une violation

Cadres de détection des menaces

Un cadre de recherche de menaces fournit la structure qui guide la planification, l'exécution et la répétition des opérations de recherche. Les cadres les plus couramment utilisés s'appuient sur MITRE ATT&CK taxonomie des techniques d'attaque, organisant les opérations de recherche par tactique (ce que l'attaquant cherche à accomplir) et par technique (comment il y parvient).

Les éléments essentiels d'un cadre opérationnel de recherche de menaces sont les suivants :

  • Formulation d'hypothèses — Définissez le comportement des attaquants que vous recherchez et expliquez en quoi cela est important dans votre environnement
  • Identification des sources de données — déterminer quels flux de télémétrie contiennent le signal dont vous avez besoin (métadonnées réseau, journaux d'identité, cloud , endpoint )
  • Exécution de requêtes — effectuer des recherches structurées dans les données historiques pour trouver des correspondances
  • Analyse approfondie et enquête — lorsqu'une correspondance est détectée, approfondir l'analyse de l'entité concernée pour en cerner l'ampleur et le calendrier
  • Intégration des réponses — réutiliser les conclusions confirmées dans les règles de détection, les scénarios d'intervention ou les workflows de gestion des incidents
  • Documentation et reproductibilité — enregistrez les requêtes efficaces, consignez les résultats et programmez des recherches récurrentes

Sans cadre reproductible, la recherche de menaces reste ponctuelle et donne des résultats inégaux. Avec un tel cadre, elle devient un programme mesurable qui renforce en permanence la couverture de détection.

Bonnes pratiques en matière de recherche de menaces

Les bonnes pratiques suivantes s'inspirent de programmes SOC bien établis et mettent en évidence ce qui distingue les équipes de détection performantes de celles qui peinent à mettre ces pratiques en œuvre.

Commencez par des hypothèses très fiables. Les recherches les plus efficaces s'appuient sur des techniques d'attaque spécifiques, et non sur des recherches génériques. Avant de rédiger la moindre requête, utilisez les renseignements sur les menaces, les rapports d'incidents récents et MITRE ATT&CK identifier les techniques pertinentes pour votre secteur d'activité et votre infrastructure.

Donnez la priorité aux métadonnées réseau. Les métadonnées réseau montrent comment les systèmes communiquent entre eux, et pas seulement qu'ils l'ont fait. Endpoint décrivent des événements isolés sur une seule machine. Les données réseau révèlent comment les activités s'articulent à l'échelle de l'environnement. Les équipes qui se basent principalement sur endpoint passent à côté d'une catégorie importante de signaux liés aux mouvements latéraux, aux mécanismes de commande et de contrôle, et à l'exfiltration de données.

Effectuez des recherches sur les trois types de méthodologies. Les recherches basées sur les TTP, sur la conformité et sur les IOC mettent chacune en évidence des catégories de menaces différentes. Un programme qui n'utilise systématiquement qu'un seul type passe systématiquement à côté de ce que les deux autres sont conçus pour détecter.

Créez des bibliothèques de requêtes reproductibles. Enregistrez les requêtes efficaces. Documentez ce que chacune recherche, ce qu’elle a trouvé par le passé et dans quelles conditions elle génère des faux positifs. Une bibliothèque de requêtes qui s’enrichit est un indicateur direct de la maturité du programme.

Intégrer les résultats dans l'ingénierie de détection. Chaque résultat confirmé issu de la recherche de menaces qui n'est pas converti en règle de détection représente une occasion manquée de renforcer la sécurité. C'est la boucle entre la recherche de menaces et l'optimisation de la détection qui permet aux programmes de s'améliorer d'eux-mêmes au fil du temps.

Définissez des références comportementales avant de rechercher des anomalies. Il est impossible d'identifier de manière fiable ce qui est anormal sans avoir d'abord compris à quoi ressemble la situation normale. Consacrez du temps à la documentation de ces références avant d'espérer que la recherche d'anomalies donne des résultats fiables.

Chasses chronométrées. Les chasses structurées et limitées dans le temps, avec des objectifs clairs, donnent de meilleurs résultats que les enquêtes sans limite de temps. La plupart des chasseurs expérimentés mènent des sessions structurées de 5 à 30 minutes, puis trient leurs résultats avant de décider s’il faut passer à l’étape suivante ou changer de cap.

Méthodologie de recherche de menaces avec la plateforme Vectra AI

Vectra AI est spécialement conçue pour les enquêtes avancées sur les menaces et la recherche de menaces à grande échelle. Les analystes exploitent des métadonnées enrichies par l'IA pour mettre au jour les comportements des attaquants, suivre l'évolution de leurs activités dans le temps et établir des corrélations entre les signaux au niveau des couches d'identité, cloud et du réseau, le tout à partir d'une seule et même interface.

Domaines de couverture et flux de métadonnées

Domaine de couverture Flux de métadonnées
Réseau iSession, DNS, HTTP, SSL, X509, SMB, RDP, RADIUS, NTLM, LDAP, DHCP, SSH, DCE/RPC, Kerberos, AI-Beacon
Entra ID Connexions avec Entra ID, activité Entra ID
Microsoft 365 Activités liées à M365 et Copilot, Exchange, SharePoint
Plane de contrôle Azure Activité du plan de contrôle Azure
Plane de contrôle AWS Activité du plan de contrôle AWS

Modalités de recherche dans la plateforme Vectra AI

Technique de chasse À quoi cela s'adresse Quand l'utiliser
Chasse au TTP Comportements et procédures des attaquants répertoriés dans le cadre du modèle MITRE ATT&CK vol d'identifiants, détournement de l'authentification, déplacement latéral, contournement Proactif, continu — détection des menaces avancées qui échappent aux outils basés sur les signatures
Chasse axée sur la conformité Violations des politiques, protocoles obsolètes, configurations non sécurisées et services non autorisés Contrôles réguliers et audits préventifs — détecter les lacunes en matière de conformité avant qu'elles ne se traduisent par des incidents
Chasse basée sur le CIO Éléments identifiés comme appartenant à des attaquants — domaines malveillants, adresses IP, hachages de fichiers et jetons d'authentification Après la publication d'un avis et après un incident — vérifier si un indicateur connu était présent dans votre environnement

Méthodologie de recherche de menaces basée sur le TTP

La détection des menaces basée sur les TTP (tactiques, techniques et procédures) vise à identifier les comportements des attaquants plutôt que de s'appuyer sur des indicateurs statiques. En ciblant les tactiques, techniques et procédures spécifiques utilisées lors d'intrusions réelles, les équipes de sécurité peuvent détecter des menaces qui échappent souvent aux outils basés sur les signatures.

Ce que les recherches basées sur le TTP visent à mettre en évidence :

  • Compromission précoce avant le début du déplacement latéral
  • Techniques de vol d'identifiants ciblant Active Directory et cloud
  • Modèles d'abus d'authentification sur les contrôleurs de domaine et les fournisseurs d'identité
  • Anomalies dans l'accès Cloud indiquant une phase préparatoire à l'exfiltration
  • Techniques d'évasion utilisant des outils système légitimes (living-off-the-land)

Les neuf scénarios de détection basés sur le TTP ci-dessous correspondent à des techniques d'attaquants connues et peuvent être exécutés directement dans la plateforme Vectra AI.

Méthodologie de recherche de menaces basée sur le TTP

La détection des menaces basée sur les TTP (tactiques, techniques et procédures) vise à identifier les comportements des attaquants plutôt que de s'appuyer sur des indicateurs statiques. En ciblant les tactiques, techniques et procédures spécifiques utilisées lors d'intrusions réelles, les équipes de sécurité peuvent détecter des menaces qui échappent souvent aux outils basés sur les signatures.

Ce que les recherches basées sur le TTP visent à mettre en évidence :

  • Compromission précoce avant le début du déplacement latéral
  • Techniques de vol d'identifiants ciblant Active Directory et cloud
  • Modèles d'abus d'authentification sur les contrôleurs de domaine et les fournisseurs d'identité
  • Anomalies dans l'accès Cloud indiquant une phase préparatoire à l'exfiltration
  • Techniques d'évasion utilisant des outils système légitimes (living-off-the-land)

Les neuf scénarios de détection basés sur le TTP ci-dessous correspondent à des techniques d'attaquants connues et peuvent être exécutés directement dans la plateforme Vectra AI.

1. Récupération de la clé de sauvegarde DPAPI

Ce que cette requête trouve :

  • Tentatives de récupération des clés de sauvegarde DPAPI à partir des contrôleurs de domaine
  • Modèles d'accès suspects aux ressources du contrôleur de domaine
  • Requêtes administratives inhabituelles sur Active Directory
  • Utilisation de techniques connues pour l'extraction de clés DPAPI (Mimikatz, SharpDPAPI, DSInternals)

Logique de recherche : Vérifie les journaux DCE/RPC du réseau des 14 derniers jours à la recherche d'événements au cours desquels un système se connecte à un contrôleur de domaine via le endpoint LSARPC endpoint effectue l'opération récupérer des données privées fonctionnement.

Conséquences en matière de sécurité : le vol d'une clé de sauvegarde DPAPI permet à un pirate informatique de :

  • Décrypter tous les mots de passe et identifiants enregistrés sur le réseau
  • Élever les privilèges à l'échelle du domaine
  • Collecter des données sensibles à grande échelle
  • Assurer un contrôle durable à long terme\
SELECT
    timestamp,
    orig_hostname,
    id.orig_h AS « id_orig_h »,
    id.resp_h AS « id_resp_h »,
    resp_hostname,
    domain,
    username,
   endpoint,
    nom_d'hôte,
    opération,
    sensor_uid
FROM
    network.dce_rpc
WHERE
    id.orig_h = '10.254.50.142'
    ET LOWER(endpoint) = 'lsarpc'
    ET LOWER(opération) = 'lsarretrieveprivatedata'
    ET horodatage > date_add('day', -14, now())
ORDER BY
    timestamp DESC
LIMIT 100

2. Utilisation du fichier binaire Certutil

Ce que cette requête trouve :

  • certutil.exe utilisé pour télécharger des fichiers depuis des sites web externes
  • Contenu encodé en Base64 décodé à l'aide de certutil
  • Un volume important de requêtes HTTP provenant du Microsoft-CryptoAPI/10.0 agent utilisateur
  • Modèles de téléchargement suspects regroupés par hôte de destination

Logique de recherche : Analyse le trafic HTTP des 14 derniers jours à la recherche de requêtes contenant un agent utilisateur Microsoft-CryptoAPI/10.0, qui est généré lorsque certutil télécharge des fichiers provenant de sources externes.

Conséquences pour la sécurité : une utilisation abusive de Certutil permet aux attaquants de :

  • Diffuser malware donnant l'impression d'une activité normale du système
  • Exfiltrer des données via un fichier binaire Windows fiable
  • Exécuter des scripts obscurcis qui contournent les mécanismes de détection standard
  • S'implanter durablement ou se déplacer latéralement avant d'être repéré
SÉLECTIONNER hôte, COUNT(*) AS nombre_de_demandes
FROM network.http
WHERE user_agent = 'Microsoft-CryptoAPI/10.0' ET timestamp > date_add('day', -14, now())
GROUP BY hôte
ORDER BY nombre_de_requêtes DESC
LIMIT 50

3. Contrôleur de domaine lançant l'authentification NTLM

Ce que cette requête trouve :

  • Contrôleurs de domaine émettant des requêtes d'authentification NTLM sortantes (comportement anormal)
  • Adresses IP sources correspondant à des plages de contrôleurs de domaine connues qui tentent de s'authentifier auprès d'autres systèmes

Logique de recherche : analyse le trafic NTLM des 14 derniers jours à la recherche de requêtes dont l'adresse IP source correspond à celle d'un contrôleur de domaine.

Conséquences en matière de sécurité : le fait qu'un contrôleur de domaine lance une authentification NTLM sortante est un indicateur fort de :

  • Attaques par relais NTLM
  • Authentification forcée (PetitPotam, PrinterBug)
  • Déplacement latéral à partir d'un centre de données compromis
  • Compromission potentielle à l'échelle du domaine
SELECT id.orig_h, orig_hostname.name AS nom_hôte, COUNT(*) AS ntlm_request_count
FROM network.ntlm
WHERE (LOWER(orig_hostname.name) LIKE '%dc%' OU TRY_CAST(id.orig_h AS
IPADDRESS) BETWEEN IPADDRESS '10.254.100.0' ET ADRESSE_IP « 10.254.100.255 »)
ET horodatage > date_add('day', -14, now())
GROUP BY id.orig_h, orig_hostname.name
ORDER BY ntlm_request_count DESC
LIMIT 100

4. Authentifications forcées

Ce que cette requête trouve :

Technique Protocole Opnums ciblés
PetitPotam MS-EFSR 0, 4, 5, 6, 7, 12, 13, 15
PrinterBug MS-RPRN 65 (0x41)
ShadowCoerce MS-FSRVP 8, 9 (0x08, 0x09)
DFSCoerce MS-DFSNM 12, 13 (0x0c, 0x0d)

Logique de détection : analyse les métadonnées du trafic RPC afin d'identifier les appels vers des protocoles Windows vulnérables utilisant des numéros d'opération spécifiques correspondant à des techniques de coercition connues.

Conséquences en matière de sécurité : une authentification forcée réussie permet aux attaquants de :

  • Lancer des attaques par relais NTLM sans intervention de l'utilisateur
  • Voler les identifiants d'un compte machine disposant de privilèges au niveau du domaine
  • Lancer des attaques DCSync et créer des « Golden Tickets »
  • Prendre le contrôle total du domaine
SELECT timestamp, nom_hôte_orig, id.orig_h, id.resp_h, nom_hôte_resp, domaine,
username, endpoint, hostname, operation, sensor_uid
FROM network.dce_rpc
WHERE (
  (endpoint = 'unknown-c681d488-d850-11d0-8c52-00c04fd90f7e' ET opération
  DANS ('unknown-0', 'inconnu-4', « inconnu-5 », « inconnu-6 », « inconnu-7 », « inconnu-12 »,
  « inconnu-13 », « inconnu-15 »)) OU
  (endpoint = 'spoolss' ET opération IN
  ('RpcRemoteFindFirstPrinterChangeNotificationEx')) OU
  (endpoint = 'unknown-a8e0653c-2744-4389-a61d-7373df8b2292' ET opération
  DANS ('unknown-8', « inconnu-9 »)) OU
  (endpoint = 'netdfs' ET opération IN ('NetrDfsAddStdRoot', 'NetrDfsRemoveStdRoot'))
) ET timestamp > date_add('day', -14, now())
ORDER BY timestamp DESC
LIMIT 100

5. SSH sortant sur un port non standard

Ce que cette requête trouve :

  • Connexions SSH sortantes sur des ports autres que le port 22
  • Connexions vers des destinations externes via le protocole SSH sur les ports 2222, 443, 8080 ou d'autres ports non standard
  • Systèmes qui lancent des connexions SSH vers des destinations où l'accès SSH n'est pas prévu

Logique de recherche : analyse les métadonnées iSession afin d'identifier les connexions TCP sortantes utilisant le protocole SSH sur des ports autres que le port 22.

Conséquences pour la sécurité : l'utilisation du protocole SSH sortant sur des ports non standard est associée à :

  • Canaux de commandement et de contrôle dissimulés
  • Tunnels d'exfiltration de données contournant les règles du pare-feu
  • Accès à distance non autorisé déguisé en trafic Web légitime
  • Déplacement latéral via un tunnel SSH
SELECT timestamp, uid, id.orig_h, orig_hostname, id.resp_h, resp_hostname,
id.resp_p, proto_name, orig_ip_bytes, resp_ip_bytes, duration, conn_state, sensor_uid, service
FROM network.isession
WHERE LOWER(service) = 'ssh' ET id.resp_p != 22 ET local_resp != true ET
timestamp > date_add('day', -14, now())
ORDER BY timestamp DESC
LIMIT 100

6. Connexions depuis plusieurs pays (indicateur de déplacement impossible)

Ce que cette requête trouve :

  • Utilisateurs authentifiés depuis plusieurs pays au cours d'une période de 24 heures
  • Uniquement les check-ins accompagnés de données de localisation confirmées (les check-ins sans données de localisation sont exclus)

Logique de recherche : regroupe toutes les connexions réussies par utilisateur au cours des dernières 24 heures, compte le nombre de pays distincts par utilisateur et identifie les utilisateurs apparaissant dans plusieurs pays.

Conséquences en matière de sécurité : des connexions depuis plusieurs pays en l'espace de 24 heures indiquent une compromission probable des identifiants — il est en effet physiquement impossible pour la plupart des utilisateurs de se déplacer rapidement à l'étranger. Ce schéma est caractéristique des Usurpation de compte de « credential stuffing » et Usurpation de compte visant les identités d'entreprise.

SELECT DISTINCT(vectra.identity_principal), COUNT(DISTINCT location.country_or_region) AS NombreDePays,
MIN(timestamp) AS PremièreConnexion, MAX(timestamp) AS DernièreConnexion
FROM entra.signins._all
WHERE location.country_or_region EST N'EST PAS NULL
  ET timestamp > date_add('day', -1, now())
GROUP BY vectra.identity_principal
HAVING COUNT(DISTINCT location.country_or_region) > 1
ORDER BY Nombre de pays
LIMITE 100

7. Tentatives de connexion infructueuses par adresse IP

Ce que cette requête trouve :

  • Adresses IP ayant enregistré au moins 20 tentatives d'authentification infructueuses en l'espace de 6 heures
  • Nombre total d'échecs et nombre d'utilisateurs uniques ciblés par adresse IP
  • Heure de début et de fin de chaque panne par adresse IP

Logique de recherche : regroupe les tentatives de connexion infructueuses par adresse IP au cours des 6 dernières heures, afin d'identifier les adresses IP présentant un nombre élevé d'échecs, ce qui peut indiquer l'utilisation d'outils d'attaque automatisés.

Conséquences en matière de sécurité :

Modèle Type d'attaque probable
Nombre élevé de pannes, utilisateur unique Attaque par force brute ciblée
Nombre élevé de pannes, grand nombre d'utilisateurs uniques Attaque par force brute
Pannes sur une courte période Outil automatisé de « credential stuffing »

SELECT adresse_IP, COUNT(*) AS FailedAttempts,
  COUNT(DISTINCT vectra.identity_principal) AS UniqueUsers,
  MIN(timestamp) AS FirstFailure,
  MAX(timestamp) AS DernièreÉchec
FROM entra.signins. « Demolab-AD »
WHERE adresse_IP EST N'EST PAS NULL
  ET timestamp > date_add(heure, -6, now())
  ET status.error_code != 0
GROUP BY adresse_IP
HAVING COUNT(*) >= 20
ORDRE BY FailedAttempts
LIMIT 100

8. Accès suspect à des données en masse d'un compte de stockage

Ce que cette requête trouve :

  • Les utilisateurs ou applications effectuant au moins 100 opérations de lecture de blobs ou de fichiers en l'espace de 6 heures
  • Opérations de lecture réussies sur Azure Blob Storage et Azure File Services
  • Regroupés par identité et ressource de stockage pour faciliter l'analyse croisée

Logique de détection : analyse les journaux d'activité Azure pour identifier les opérations de lecture sur les comptes de stockage au cours des 6 dernières heures, en repérant les sources dont le nombre de lectures est égal ou supérieur au seuil d'accès en masse.

Conséquences en matière de sécurité : les opérations de lecture sur le stockage en masse indiquent :

  • Étape de préparation de l'exfiltration de données — les pirates téléchargent des fichiers en masse avant de les transférer
  • Des comptes piratés sont utilisés pour voler des données d'entreprise à grande échelle
  • Vol Cloud visant la propriété intellectuelle, les identifiants ou les dossiers clients
SELECT vectra.identity,
  resourceid,
  COUNT(*) AS AccessCount,
  COUNT(DISTINCT ResourceId) AS ComptesDeStockageUniques,
  MIN(timestamp) AS FirstAccess,
  MAX(timestamp) AS DernierAccès
FROM azurecp.operations._all
WHERE timestamp > date_add(heure, -6, now())
  ET UPPER(nom_opération) IN ('MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/BLOBS/READ',
  'MICROSOFT.STORAGE/STORAGEACCOUNTS/FILESERVICES/SHARES/FILES/READ')
  ET type de résultat = 'Success'
GROUP PAR vectra.identity, ResourceId
HAVING COUNT(*) >= 100
ORDRE BY Nombre d'accès
LIMIT 100

9. Modèles d'accès excessifs aux secrets du coffre-fort de clés

Ce que cette requête trouve :

  • Sources ayant accédé à au moins 20 secrets Key Vault en 24 heures
  • Sources ayant accès à au moins 10 identifiants uniques — ce qui indique une collecte massive d'identifiants
  • Opérations SecretGet, KeyGet et CertificateGet réussies, regroupées par identité et par adresse IP

Logique de recherche : analyse les journaux d'activité Azure pour détecter les opérations d'accès à Key Vault au cours des dernières 24 heures, en identifiant les sources qui dépassent les volumes d'accès habituels des applications.

Conséquences en matière de sécurité : un accès excessif à Key Vault est associé à des attaques de collecte d'identifiants, dans lesquelles des identités compromises sont utilisées pour voler :

  • Clés API et chaînes de connexion pour le déplacement latéral
  • Certificats utilisés pour l'usurpation d'identité
  • Secrets requis pour un accès persistant dans l'ensemble de l'environnement
SELECT calleripaddress,
  vectra.identity,
  resourceid,
  nom_de_l'opération,
  COUNT(*) AS SecretAccessCount,
  COUNT(DISTINCT resourceid) AS UniqueSecrets,
  MIN(timestamp) AS FirstAccess,
  MAX(timestamp) AS DernierAccès
FROM azurecp.operations._all
WHERE timestamp > date_add('heure', -24, now())
  ET nom_opération IN ('SecretGet', 'KeyGet', « CertificateGet »)
  ET type de résultat = 'Success'
  ET adresse_IP_de_l'appelant EST N'EST PAS NULL
GROUP BY calleripaddress, vectra.identity, resourceid, operationname
HAVING COUNT(*) >= 20 OU COUNT(DISTINCT resourceid) >= 10
ORDER BY SecretAccessCount
LIMIT 100

Méthodologie de recherche de menaces axée sur la conformité

La détection axée sur la conformité cible les violations des politiques de sécurité, des contrôles d'accès ou des limites architecturales définies par des normes réglementaires ou internes. Cette approche met en évidence les comportements à risque qui, sans être nécessairement malveillants, peuvent indiquer des erreurs de configuration, des menaces internes ou des lacunes dans l'application des règles — souvent avant même qu'ils ne donnent lieu à des constatations d'audit ou ne deviennent des vecteurs de violation.

Ce que les recherches axées sur la conformité visent à mettre en évidence :

  • Protocoles hérités toujours actifs dans l'environnement (SMBv1, services non chiffrés)
  • Tentatives de contournement des contrôles de sécurité réseau
  • Des logiciels clients non mis à jour ou obsolètes créent une surface d'attaque exploitable
  • L'adoption de services d'IA non autorisés entraîne un risque d'exposition des données

1. Utilisation de SMBv1

Ce que cette requête trouve :

  • Tous les systèmes ayant activement utilisé le protocole SMBv1 au cours des 14 derniers jours
  • Connexions client, partages de serveur et communications entre systèmes via SMBv1
  • Applications héritées, anciens systèmes Windows, périphériques NAS et logiciels tiers utilisant ce protocole obsolète

Logique de recherche : analyse l'activité SMB du réseau au cours des 14 derniers jours et répertorie les hôtes sources distincts utilisant SMBv1.

Conséquences en matière de sécurité : l'utilisation du protocole SMBv1 présente des risques à trois niveaux :

Dimension du risque Impact
Sécurité Permet des attaques par déplacement latéral — le même protocole que celui exploité par WannaCry et NotPetya via EternalBlue
Conformité La plupart des normes réglementaires (PCI-DSS, CIS Controls) exigent explicitement que SMBv1 soit désactivé
Opérationnel Le protocole SMBv1 nuit aux performances et à la fiabilité du réseau

SELECT DISTINCT id.orig_h, orig_hostname.name
FROM network.smb_mapping._all
WHERE version = 'SMBv1' ET horodatage > date_add('day', -14, now())

2. Utilisation de HTTP CONNECT sur des ports TCP peu courants

Ce que cette requête trouve :

  • Requêtes utilisant la méthode HTTP CONNECT vers des ports autres que 80, 443, 8080 ou 8443
  • Tentatives potentielles de tunneling et utilisation abusive de serveurs proxy
  • Connexions sortantes non autorisées sur des ports non standard
  • Malware d'accéder à des serveurs externes via des ports qui contournent le filtrage Web standard

Logique de recherche : analyse les journaux HTTP à la recherche de requêtes CONNECT transitant par un proxy qui n'utilisent pas le protocole HTTPS standard (port 443). L'inspection approfondie des paquets Vectra AI identifie le trafic HTTP quel que soit le numéro de port, ce qui rend cette recherche efficace même face aux techniques de contournement de port.

Conséquences en matière de sécurité : l'utilisation de la commande HTTP CONNECT sur des ports inhabituels indique :

  • Tentatives de contournement des mesures de sécurité du réseau
  • Établissement d'un canal caché
  • Exfiltration de données via des ports non standard
  • Trafic Malware déguisé en trafic Web
SELECT timestamp, id.orig_h, orig_hostname, user_agent, id.resp_h, resp_hostname,
id.resp_p, méthode, hôte, uri, code_statut
FROM network.http
WHERE is_proxied = true ET LOWER(méthode) = 'connect' ET uri NON COMME '%:443'
ET horodatage > date_add('day', -14, now())
ORDER BY timestamp DESC
LIMIT 100

3. Détection des navigateurs obsolètes

Ce que cette requête trouve :

Navigateur Modèle de détection
Internet Explorer (toutes versions) L'agent utilisateur contient %MSIE%
Firefox 3 à 6 L'agent utilisateur contient %Firefox/[3-6]%
Chrome 1 à 49 L'agent utilisateur contient %Chrome/[1-9]% ou %Chrome/[1-4][0-9]%
Safari 10-16 L'agent utilisateur correspond au modèle de version 1[0-6]

Logique de détection : identifie les chaînes « user-agent » HTTP indiquant l'utilisation de navigateurs Web obsolètes. Une utilisation persistante sur plusieurs jours met en évidence les systèmes non mis à jour et exposés à un risque accru d'exploitation.

Conséquences pour la sécurité : les navigateurs obsolètes sont souvent la cible d'attaques via :

  • Téléchargements automatiques à partir de sites web compromis ou malveillants
  • Phishing exploitant des failles connues des navigateurs
  • Contenu Web malveillant ciblant des vulnérabilités CVE répertoriées et non corrigées

L'utilisation persistante de navigateurs obsolètes est souvent le signe de lacunes plus générales endpoint et peut constituer une violation des politiques endpoint de la sécurité endpoint .

SELECT id.orig_h, orig_hostname.name AS nom_hôte, agent_utilisateur, COUNT(*) AS nombre_de_demandes
FROM network.http._all
WHERE timestamp ENTRE date_add('day', -14, now()) ET maintenant()
ET ( user_agent LIKE '%MSIE%'
OU user_agent LIKE '%Firefox/[3-6]%'
OU user_agent LIKE '%Chrome/[1-9]%'
OU user_agent LIKE '%Chrome/[1-4][0-9]%'
OU user_agent LIKE '%Version/(1[0-6](\.\d+)*)\s+Safari%' )
GROUP BY id.orig_h, orig_hostname.name, user_agent
ORDER BY nombre_de_requêtes DESC
LIMIT 100

4. Utilisation des services d'IA — interactions avec les plateformes d'IA générative

Ce que cette requête trouve :

plateforme Modèle de domaine surveillé
OpenAI / ChatGPT %openai.com, %chat.openai.com
Anthropic / Claude %anthropic.com, %claude.ai
Google Bard %bard.google.com
Microsoft Copilot %bing.com
Cohere %cohere.ai
Hugging Face %huggingface.co
Mistral %mistral.ai
DeepSeek %deepseek.com%

Logique de recherche : analyse les métadonnées DNS à la recherche de requêtes sortantes vers des domaines connus de plateformes d'IA générative, en mettant en évidence les hôtes, les volumes de requêtes et les schémas d'utilisation.

Conséquences en matière de sécurité : l'adoption non autorisée de l'IA comporte trois types de risques :

  • Exposition des données — les utilisateurs collent du code sensible, des identifiants ou des documents internes dans les champs de saisie
  • Violations de conformité — traitement non autorisé des données dans des environnements réglementés (HIPAA, RGPD, PCI-DSS)
  • « Shadow IT » — Utilisation de l'IA contournant les contrôles de sécurité et les politiques de gouvernance des données en place
SELECT requête, COUNT(DISTINCT orig_hostname.name) as nombre_d'hôtes_uniques,
COUNT(*) comme total_query_count
FROM network.dns
WHERE ( query LIKE '%openai.com'
OU requête LIKE '%chat.openai.com'
OU requête LIKE '%anthropic.com'
OU requête LIKE '%claude.ai'
OU requête LIKE '%bard.google.com'
OU requête LIKE '%bing.com'
OU requête LIKE '%cohere.ai'
OU requête LIKE '%huggingface.co'
OU requête LIKE '%mistral.ai'
OU requête LIKE '%deepseek.com%' )
ET timestamp ENTRE date_add('day', -14, now()) ET maintenant()
GROUP BY requête
ORDER BY nombre_d'hôtes_uniques DESC, total_query_count DESC
LIMIT 100

Méthodologie de recherche de menaces basée sur l'IOC

La recherche de menaces basée sur l'IOC permet de valider les vulnérabilités potentielles, de mettre au jour la réutilisation d'infrastructures par les attaquants et de détecter les menaces qui auraient pu contourner les défenses initiales. Elle s'avère particulièrement efficace pour réagir aux alertes de renseignements sur les menaces ou aux divulgations publiques concernant des campagnes en cours.

Que sont les indicateurs de compromission (IOC) ?

Les indicateurs de compromission (IOC) sont des éléments qui, replacés dans leur contexte, laissent entrevoir l'activité d'un attaquant. En général, ils ne déclenchent pas de détection à eux seuls : une enquête approfondie est nécessaire pour confirmer si une correspondance correspond bien à une véritable compromission.

Type IOC Exemples
Domaines suspects Infrastructure C2 contrôlée par les attaquants, pages phishing
Adresses IP malveillantes Infrastructure associée à malware ou à l'exfiltration de données
Hachages de fichiers Empreintes digitales malware connus
Agents utilisateurs et adresses e-mail Stratégies utilisées dans les campagnes phishing d'usurpation d'identité
Éléments d'authentification Jeton OAuth, clés API, clés de registre utilisées dans les mécanismes de persistance

Où les équipes de sécurité trouvent-elles leurs indicateurs de compromission (IOC) ?

Type de source Exemples
Rapports sur les menaces Mandiant, Volexity, avis de la CISA, Vectra Threat Research
Actualités et blogs sur la sécurité BleepingComputer, KrebsOnSecurity
Communautés de partage d'informations sur les menaces ISAC, dépôts GitHub, AlienVault OTX
Réseaux sociaux Publications sur X/Twitter par des chercheurs en cybersécurité reconnus
Plates-formes d'ingénierie de détection Règles Sigma, référentiels YARA

Processus de recherche d'IOC sur la plateforme Vectra AI

Une fois que vous disposez d'un indicateur de compromission (IOC) ou d'un ensemble d'IOC, le processus d'enquête se déroule en quatre étapes :

  1. Recherche — recherchez un nom de domaine, une adresse IP ou un hachage dans l'historique des métadonnées et des détections
  2. Pivot — identifier l'hôte ou l'utilisateur qui a interagi avec l'IOC
  3. Analyser la chronologie des événements — déterminer quand l'IOC a été observé pour la première fois et s'il est réapparu
  4. Vérifiez l'activité environnante — recherchez les comportements consécutifs, notamment l'escalade de privilèges, les mouvements latéraux ou les schémas d'accès aux données inhabituels

Conseil : même si un indicateur de compromission (IOC) est obsolète ou générique, il peut tout de même aider à mettre au jour des menaces persistantes ou à confirmer que l'incident a été maîtrisé.

Exemple de workflow : un avis de la CISA est publié, contenant des indicateurs liés à une campagne APT connue. Vous en extrayez deux domaines, une adresse IP et un hachage PowerShell. Dans la plateforme Vectra AI, vous recherchez l'un des domaines dans les métadonnées HTTP et repérez une activité datant d'il y a trois semaines. L'hôte de destination est un système financier. Vous passez à la section « Investigate » et constatez des détections associées : « Activité de script anormale » et « Mouvement latéral suspect ». Vous disposez désormais de preuves très fiables pour escalader et contenir l'incident.

1. Domaines malveillants — phishing de commande et de contrôle / phishing

Ce que cette requête trouve :

  • Sessions sortantes vers des domaines connus pour être malveillants
  • Éventuels rappels C2, activité de balisage ou interaction de l'utilisateur avec phishing

Logique de recherche : recherche les sessions réseau des 14 derniers jours pour lesquelles le domaine de destination correspond à une liste de domaines connus pour être malveillants.

Conséquences en matière de sécurité : les connexions à des domaines contrôlés par des pirates peuvent indiquer :

  • Communication C2 active ou balisage
  • Préparation du téléchargement de la charge utile
  • Interaction des utilisateurs avec phishing (fréquemment observée avec des logiciels de vol d'informations tels que LummaC2 ou des courtiers en accès initial comme Scattered Spider)
SELECT timestamp, uid, id.orig_h comme « id_orig_h », orig_hostname, id.resp_h comme « id_resp_h »,
resp_hostname, id.resp_p comme « id_resp_p », proto_name, orig_ip_bytes,
resp_ip_bytes, durée, état_connexion, uid_capteur
FROM network.isession
WHERE (resp_domain = 'baddomain1.com' OU resp_domain = 'baddomain2.com')
ET timestamp > date_add('day', -14, now())
ORDER BY timestamp DESC
LIMIT 100

2. Adresses IP malveillantes connues — réutilisation de l'infrastructure ou exfiltration

Ce que cette requête trouve :

  • Connexions vers ou en provenance d'adresses IP figurant sur la liste noire au cours des 14 derniers jours
  • Détails complets de la session, notamment l'origine, la destination, le protocole et la durée pour chaque connexion correspondante

Logique de recherche : recherche toutes les sessions réseau impliquant des adresses IP spécifiques, que ce soit en tant que source ou en tant que destination.

Conséquences en matière de sécurité : les indicateurs de compromission (IOC) basés sur les adresses IP sont souvent réutilisés dans plusieurs campagnes menées par des acteurs malveillants. Les correspondances peuvent indiquer :

  • Malware vers une infrastructure connue appartenant à un pirate
  • Une exfiltration directe de données est en cours
  • Compromission continue via une infrastructure précédemment identifiée
SELECT timestamp, uid, id.orig_h comme « id_orig_h », orig_hostname, id.resp_h comme « id_resp_h »,
resp_hostname, id.resp_p comme « id_resp_p », proto_name, orig_ip_bytes, resp_ip_bytes,
duration, conn_state, sensor_uid
FROM network.isession
WHERE (id.resp_h IN ('192.0.2.1', '192.0.2.2') OU id.orig_h IN ('192.0.2.1', '192.0.2.2'))
ET horodatage > date_add('day', -14, now())
ORDER BY timestamp DESC
LIMIT 100

3. Noms de fichiers suspects — mise en place d'une charge utile malveillante

Ce que cette requête trouve :

  • Fichiers transférés via SMB dont le nom de base dépasse 50 caractères
  • Modèles associés à malware automatisée malware et à l'obfuscation des données

Logique de recherche : analyse l'activité des fichiers SMB des 14 derniers jours, en extrayant et en répertoriant les fichiers dont le nom de base est anormalement long.

Conséquences en matière de sécurité : les noms de fichiers excessivement longs ou obscurcis indiquent :

  • malware automatisé malware ou diffusion de charges utiles via des scripts
  • Modèles de déploiement des ransomwares
  • Les outils de la campagne Loader sont en cours de mise en place en vue de leur exécution
SELECT nom, REGEXP_EXTRACT(nom, '([^\\/]+)$') AS nom_fichier_base,
LENGTH(REGEXP_EXTRACT(nom, '([^\\/]+)$')) AS longueur_base
FROM network.smb_files
WHERE LONGUEUR(REGEXP_EXTRACT(nom, '([^\\/]+)$')) > 50 ET timestamp > date_add('day', -14, now())
ORDER BY longueur_base DESC
LIMIT 50

4. Fichiers sans voyelles — malware obscurcis ou générés automatiquement

Ce que cette requête trouve :

  • Noms de fichiers SMB dont le nom de base ne contient aucune voyelle
  • Modèles associés aux noms malware générés par programmation

Logique de recherche : extrait les noms de fichiers ne contenant aucune voyelle (uniquement des consonnes ou des caractères spéciaux) parmi les activités liées aux fichiers SMB des 14 derniers jours.

Conséquences en matière de sécurité : les noms de fichiers ne contenant aucune voyelle indiquent une génération automatique — une technique de contournement couramment utilisée par malware pour échapper à la détection par signature. Si elles ne sont pas détectées, ces charges utiles prolongent la durée de présence de l'attaquant et aggravent l'impact de l'attaque.

SELECT nom, REGEXP_EXTRACT(nom, r'([^\\/]+)$') AS nom_fichier_base
FROM network.smb_files
WHERE REGEXP_LIKE(REGEXP_EXTRACT(name, r'([^\\/]+)$'), '^[^aeiouAEIOU]+$') AND
timestamp > date_add('day', -14, now())
LIMIT 50

5. Chemins d'accès suspects — déplacement latéral ou mise en place

Ce que cette requête trouve :

  • Fichiers consultés ou modifiés dans /App/Data/Roaming/ chemins
  • Opérations sur les fichiers dans les répertoires couramment utilisés par malware les outils post-exploitation comme emplacements de transit ou de persistance

Logique de recherche : analyse l'activité des fichiers SMB des 14 derniers jours pour identifier les fichiers consultés dans les chemins d'accès AppData/Roaming. La requête peut être modifiée pour surveiller tout chemin d'accès à des fichiers présentant un intérêt particulier dans votre environnement spécifique.

Conséquences en matière de sécurité : les répertoires AppData/Roaming sont spécifiquement ciblés par malware les outils d'attaquants pour les raisons suivantes :

  • Ils font l'objet d'un contrôle opérationnel moins rigoureux que les répertoires système
  • Ils sont accessibles en écriture par les comptes d'utilisateur standard sans élévation de privilèges
  • Les outils peuvent fonctionner à partir de ces emplacements indéfiniment sans déclencher les règles habituelles de surveillance de l'intégrité des fichiers
SELECT timestamp, uid, id.orig_h comme « id_orig_h », orig_hostname, id.resp_h comme « id_resp_h »,
resp_hostname, id.resp_p sous la forme « id_resp_p », version, chemin, action, nom, uid_capteur
FROM network.smb_files
WHERE chemin LIKE '%/App/Data/Roaming/%' ET timestamp > date_add('day', -14, now())
ORDER BY timestamp DESC
LIMIT 100

6. Empreinte JA3 — TOR ou clients TLS inhabituels

Ce que cette requête trouve :

  • Connexions TLS utilisant l'empreinte JA3 associée aux clients TOR
  • Systèmes exécutant des navigateurs TOR ou des applications basées sur TOR dans un environnement d'entreprise

Logique de recherche : extrait les journaux de session SSL/TLS des 14 derniers jours, en filtrant les entrées correspondant à un hachage JA3 spécifique connu pour correspondre aux clients TOR.

Conséquences en matière de sécurité : l'utilisation de TOR dans un environnement d'entreprise peut indiquer :

Type d'indicateur Signification possible
Appareils des employés Violations des règles, utilisation de logiciels d'anonymisation
Serveur ou poste de travail Malware utilisant TOR pour des communications anonymes
Cadres automatisés Outils d'attaque exploitant des implémentations TLS non standard
Tout actif Exfiltration de données via des canaux cryptés et anonymisés

Pour plus d'informations : la documentation relative à la méthodologie JA3 est disponible à l'adresse https://github.com/salesforce/ja3. Les empreintes JA3 établies par la communauté sont disponibles à l'adresse https://ja3.zone/.

SELECT timestamp, uid, id.orig_h comme « id_orig_h », orig_hostname, id.resp_h comme « id_resp_h »,
resp_hostname, id.resp_p comme « id_resp_p », server_name, client_version,
next_protocol, cipher, ja3, established, sensor_uid
FROM network.ssl
WHERE ja3 = 'e7d705a3286e19ea42f587b344ee6865' ET timestamp > date_add('day', -14, now())
ORDER BY timestamp DESC
LIMIT 100

Mettre en place une stratégie de détection des menaces reproductible avec Vectra AI

La recherche de menaces offre un maximum de valeur lorsqu'elle est mise en œuvre de manière opérationnelle, c'est-à-dire intégrée comme une pratique régulière plutôt que comme un exercice ponctuel et réactif. Les requêtes présentées dans ce guide constituent des points de départ. L'objectif est de les adapter à votre environnement, de conserver les variantes les plus efficaces et de les intégrer dans des cycles de recherche structurés.

Comment mettre en œuvre la chasse aux talents avec la plateforme Vectra AI :

  • Organisez des « chasses » de 5 minutes pour effectuer des contrôles rapides et réguliers des TTP à haut risque et vérifier la conformité
  • Utilisez les recherches enregistrées pour constituer une bibliothèque de requêtes spécifiques à un environnement
  • Utilisez la recherche assistée par l'IA pour accélérer les changements d'orientation dans vos enquêtes et obtenir des recommandations sur les prochaines étapes à suivre, formulées en langage clair
  • Proposez de nouvelles requêtes et rejoignez la communauté au sens large via le dépôt GitHub « Vectra AI Hunting »

L'expérience acquise grâce à une veille constante constitue un facteur multiplicateur lors de la gestion des incidents : les équipes qui pratiquent régulièrement la veille mènent leurs enquêtes plus rapidement, effectuent un triage plus précis et maîtrisent les menaces avant qu'elles ne s'aggravent.

Les entreprises du monde entier nous font confiance

Foire aux questions