Aller au contenu

Analyse CTI : Opérationnaliser MITRE ATT&CK pour le Threat Hunting

1. Le moteur de traduction : du texte à la télémétrie

Section intitulée « 1. Le moteur de traduction : du texte à la télémétrie »

Une difficulté courante pour les analystes SOC juniors est de faire le pont entre un rapport de Cyber Threat Intelligence (CTI) et une requête SIEM. Si un rapport CTI indique : “L’acteur de la menace a établi sa persistance en utilisant T1053.005 (Scheduled Task)”, comment trouvez-vous réellement cela sur votre réseau ?

La clé pour opérationnaliser ATT&CK réside dans ses Sources de données (Data Sources) et ses Composants de données (Data Components). MITRE relie explicitement chaque sous-technique aux artefacts du système d’exploitation sous-jacent nécessaires pour la détecter.

  1. Identifier la technique : ex: T1543.003 - Create or Modify System Process: Windows Service.
  2. Consulter les sources de données : ATT&CK liste la télémétrie requise. Pour T1543.003, il indique Windows Registry: Registry Key Modification et Service: Service Creation.
  3. Traduire en artefacts de l’OS : l’analyste DFIR traduit “Service Creation” en journaux spécifiques. Comme documenté dans notre analyse des modifications système, cela se traduit directement par l’Événement de sécurité Windows 4697 ou l’Événement Système 7045.
  4. Construire la requête : la TTP abstraite est maintenant devenue une requête KQL ou Splunk concrète chassant EventCode=7045 en filtrant les valeurs ImagePath suspectes.

Le Threat Hunting ne consiste pas à chercher au hasard dans les journaux. C’est un processus proactif, guidé par des hypothèses. La matrice ATT&CK fournit exactement le cadre de travail requis pour générer ces hypothèses.

Une hypothèse de chasse valide doit être testable, appuyée par de la télémétrie, et focalisée sur une technique.

Hypothèse 1 : Exécution (T1059.001)

Hypothèse : “les adversaires utilisent PowerShell pour exécuter des charges utiles encodées et contourner les politiques d’exécution.” Déclencheur de chasse : interroger les journaux EDR pour l’Événement 4688 (Création de processus)powershell.exe est l’image, en filtrant les arguments de ligne de commande contenant -enc, -EncodedCommand ou ExecutionPolicy Bypass.

Hypothèse 2 : Vol d'identifiants (T1003.001)

Hypothèse : “les adversaires vident la mémoire du processus LSASS pour extraire des hashs NTLM.” Déclencheur de chasse : interroger l’Événement Sysmon 10 (ProcessAccess) en recherchant les processus non autorisés demandant des masques d’accès à privilèges élevés (ex: 0x1400 ou 0x1F0FFF) vers lsass.exe.

3. L’art du pivotement : anticiper le prochain mouvement

Section intitulée « 3. L’art du pivotement : anticiper le prochain mouvement »

La matrice ATT&CK permet aux défenseurs de jouer aux échecs, pas aux dames. Lorsqu’un Threat Hunter découvre un indicateur de compromission (IOC) isolé, il utilise la matrice pour anticiper la prochaine étape logique de l’adversaire. C’est ce qu’on appelle le pivotement de TTPs (TTP Pivoting).

Si un analyste reçoit une alerte pour une exécution de charge utile de phishing réussie (T1566.002), l’attaquant a atteint l’Accès Initial et l’Exécution.

Quelle est l’exigence immédiate suivante de l’attaquant ? La persistance.

Au lieu d’attendre une autre alerte, le Threat Hunter pivote de manière proactive pour chasser les techniques de persistance les plus courantes associées à cette famille de malware spécifique. Il scannera immédiatement l’environnement pour :

  • des modifications dans HKCU\Software\Microsoft\Windows\CurrentVersion\Run (T1547.001).
  • la création de fichiers .service ou de tâches cron anormaux (T1053.003).

En prédisant le chemin de l’adversaire à travers la matrice ATT&CK, les défenseurs peuvent intercepter une attaque avant qu’elle n’atteigne les phases d’Impact ou d’Exfiltration.

4. Ingénierie de détection (règles exploitables)

Section intitulée « 4. Ingénierie de détection (règles exploitables) »

Pour opérationnaliser le framework, les ingénieurs de détection rédigent des règles SIEM massivement balisées (taguées) avec les métadonnées ATT&CK. Cela garantit que lorsqu’une alerte se déclenche, le SOC connaît instantanément la tactique, la technique et l’objectif de l’adversaire.

sigma_psexec_lateral_movement.yaml
title: Installation du service de mouvement latéral PsExec
id: 9b8c7d6e-5f4a-3b2c-1d0e-9f8a7b6c5d4e
status: stable
description: Détecte l'installation du service PSEXESVC, un indicateur définitif de mouvement latéral via Sysinternals PsExec.
logsource:
product: windows
service: system
detection:
selection:
EventID: 7045
ServiceName: 'PSEXESVC'
ImagePath|contains: 'PSEXESVC.exe'
condition: selection
level: high
tags:
- attack.lateral_movement
- attack.execution
- attack.t1569.002

Une règle de détection mappée à une technique ATT&CK n’est que théorique jusqu’à ce qu’il soit prouvé qu’elle fonctionne en production. C’est le domaine du Purple Teaming — l’effort collaboratif entre les équipes de sécurité offensives (Red) et défensives (Blue).

Pour valider leur opérationnalisation d’ATT&CK, les organisations utilisent des frameworks d’émulation d’adversaires, le plus important étant Atomic Red Team (maintenu par Red Canary).

Atomic Red Team fournit des scripts pré-packagés et sûrs à exécuter, mappés directement sur des techniques ATT&CK spécifiques. Par exemple, pour tester si votre SOC détecte avec succès T1003.001 (Vidage mémoire LSASS), une Purple Team exécutera le test Atomic correspondant sur un poste surveillé :

Fenêtre de terminal
# Test Atomic pour T1003.001 : Vider la mémoire de LSASS.exe en utilisant Procdump
Invoke-AtomicTest T1003.001 -TestNames "Dump LSASS.exe Memory using Procdump"

Si le SIEM ne génère pas d’alerte critique balisée T1003.001 en quelques minutes, le SOC a découvert une lacune de détection. Les ingénieurs doivent alors ajuster leurs configurations Sysmon ou leurs requêtes KQL, réexécuter le test Atomic et vérifier la correction. Ce cycle de validation continu et aligné sur ATT&CK est la marque d’un programme de cybersécurité mature.