Alertes SOC : 7 cas d'analyse pas-à-pas en 2026

Un SOC opérationnel en 2026 traite quotidiennement les mêmes familles d'alertes : tentatives d'accès credential (Mimikatz LSASS access), exécution PowerShell suspecte (DownloadString, encoded commands), brute force RDP, beaconing C2, lateral movement WMI ou PsExec, persistence registry Windows et accès cloud metadata depuis container. Chaque famille suit une méthodologie d'analyse standardisée : règle de détection (Sigma, KQL ou SPL) qui déclenche, pivot EDR pour le contexte process et fichier, enrichissement threat intel, mapping MITRE ATT&CK, verdict (true positive, false positive, suspect), escalade ou fermeture documentée. Cet article décortique 7 alertes SOC fréquentes avec leur règle Sigma, leur stratégie d'investigation, leurs faux positifs typiques et les critères d'escalade L1 vers L2. Les règles citées sont alignées sur le SigmaHQ public registry (3 000+ règles open source maintenues par Florian Roth et la communauté) et le framework MITRE ATT&CK Enterprise v14.

Méthodologie d'analyse standardisée

Chaque alerte traite suit un protocole en 6 étapes pour garantir cohérence et traçabilité.

Investigation totale moyenne : 15 à 35 minutes par alerte L1, 1 à 4 heures par incident L2. La discipline de documentation à chaque étape est non négociable : un dossier d'investigation incomplet bloque l'escalade et complique le post-mortem.

Alerte 1 — Mimikatz LSASS access (T1003.001)

Tactique : Credential Access. Technique : OS Credential Dumping — LSASS Memory.

Mimikatz est l'outil de credential dumping le plus utilisé en pentest et en attaque réelle depuis 2011 (Benjamin Delpy). Il extrait les hashes NTLM, les tickets Kerberos, les secrets LSA et les credentials en clair depuis le processus LSASS.exe. La détection se base sur les patterns d'accès à LSASS avec masques d'accès spécifiques.

Règle Sigma

title: Suspicious LSASS Access via Process Memory Access
id: 5ef9853e-4d0e-4a70-846f-a9ca37d876da
status: production
description: >
  Détection d'accès au processus LSASS.exe avec un GrantedAccess
  caractéristique des outils de credential dumping (Mimikatz, Pypykatz,
  Dumpert, NanoDump).
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: SOC Team Zeroday
date: 2026/04/24
logsource:
  product: windows
  category: process_access
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess:
      - '0x1010'
      - '0x1410'
      - '0x143a'
      - '0x1438'
  filter_legitimate:
    SourceImage|endswith:
      - '\MsMpEng.exe'
      - '\SenseCncProxy.exe'
      - '\smss.exe'
  condition: selection and not filter_legitimate
falsepositives:
  - Antivirus en cours de scan signature
  - EDR/agent de sécurité légitime
  - Outils administration Microsoft (PROCEXP, processhacker autorisés)
level: high
tags:
  - attack.credential_access
  - attack.t1003.001

Stratégie d'investigation

1. Identifier le processus source dans l'EDR : SourceImage, SourceProcessId, parent process tree complet.
2. Hash et signature : SHA256 du binaire source, statut de signature (signé Microsoft / signé éditeur connu / non signé).
3. Threat intel : VirusTotal sur le hash, recherche dans MISP / OpenCTI.
4. Activité concomitante : autres alertes sur le même host dans les 30 minutes précédentes et suivantes (lateral movement, persistence, exfiltration).
5. Légitimité utilisateur : compte concerné est-il un administrateur, un compte de service, un compte utilisateur standard ? Heures de connexion habituelles ?

Faux positifs typiques

• Antivirus en scan : Microsoft Defender (MsMpEng.exe), CrowdStrike Falcon (CSFalconService.exe), SentinelOne accèdent légitimement à LSASS. À whitelister par hash signé.
• Outils admin légitimes : Process Explorer (procexp.exe) signé Microsoft Sysinternals utilisé par admins.
• Vulnerability scanners : Tenable Nessus Agent, Qualys Cloud Agent.

Critères d'escalade L2

Escalade immédiate si :

• SourceImage non signé ou signature inconnue.
• SourceImage dans %TEMP%, %APPDATA%\Local\Temp, \Users\*\Downloads\.
• Hash inconnu de VirusTotal et de la baseline interne.
• Combinaison avec d'autres alertes (création de tâche planifiée, écriture registre Run, connexion sortante).
• Compte utilisateur sans privilèges admin légitimes.

Alerte 2 — Suspicious PowerShell DownloadString (T1059.001)

Tactique : Execution. Technique : Command and Scripting Interpreter — PowerShell.

Le pattern Net.WebClient ou Invoke-WebRequest suivi d'un DownloadString puis d'un Invoke-Expression (IEX) est le pattern classique de dropper PowerShell utilisé en initial access via phishing, en lateral movement et en payload staging.

Règle Sigma

title: Suspicious PowerShell Download via Net.WebClient
id: 65531a81-a694-4e31-ae04-f8ba5bc33759
description: >
  Détection PowerShell utilisant Net.WebClient.DownloadString ou
  Invoke-WebRequest combiné à IEX, pattern classique de dropper.
references:
  - https://attack.mitre.org/techniques/T1059/001/
logsource:
  product: windows
  category: process_creation
detection:
  selection_image:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_command:
    CommandLine|contains:
      - 'Net.WebClient'
      - 'DownloadString'
      - 'DownloadFile'
      - 'Invoke-WebRequest'
      - 'iwr '
      - 'wget '
      - 'curl '
    CommandLine|contains:
      - 'IEX'
      - 'Invoke-Expression'
      - '| iex'
      - 'Invoke-Command'
  condition: selection_image and selection_command
falsepositives:
  - Scripts d'administration légitimes (à whitelister par chemin et hash)
  - Outils de déploiement internes (Chocolatey, Scoop)
level: high
tags:
  - attack.execution
  - attack.t1059.001

Stratégie d'investigation

1. Décoder la command line : si encoded (Base64), décoder via [System.Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('...')).
2. URL et IP destinations : vérifier dans threat intel, vérifier date d'enregistrement du domaine (DomainTools, RiskIQ).
3. Parent process : un PowerShell lancé par Outlook.exe, winword.exe, excel.exe = très suspect (initial access via phishing).
4. Script Block Logging : si activé (Event ID 4104), lire le contenu complet du script chargé dynamiquement.
5. AMSI events : si AMSI a inspecté et catégorisé, le verdict AMSI est précieux.

Faux positifs typiques

• Chocolatey, Scoop : managers de paquets Windows utilisant DownloadString pour bootstrap.
• Scripts d'administration internes : déploiement, monitoring custom.
• Visual Studio, Az PowerShell module installer : commandes one-liner légitimes.

Critères d'escalade L2

• URL pointant vers Pastebin, GitHub raw, Discord CDN, Telegram CDN, IP brute.
• Encoded command (Base64, hex, compression).
• Parent process Office, navigateur ou tâche planifiée non identifiée.
• Combinaison avec exécution autre payload (cmd, regsvr32, mshta).

Alerte 3 — RDP brute force (T1110.001)

Tactique : Credential Access. Technique : Brute Force — Password Guessing.

L'exposition RDP sur Internet reste l'un des vecteurs d'intrusion ransomware les plus exploités en 2024-2026 (Coveware Quarterly Reports). La détection se base sur le volume d'échecs Event ID 4625 (Failed Logon) sur Windows ou tentative SSH sur Linux exposé.

Règle Sigma

title: RDP Brute Force via Multiple Failed Logon
id: 7aa7009a-28b9-4344-8c1f-159489a390df
description: >
  Détection brute force RDP basée sur volume d'événements 4625 LogonType=10
  depuis source unique en moins de 5 minutes.
references:
  - https://attack.mitre.org/techniques/T1110/001/
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
    LogonType: 10
  timeframe: 5m
  condition: selection | count() by IpAddress > 20
falsepositives:
  - Misconfiguration RDP client (utilisateur tape mauvais mot de passe)
  - Service de monitoring RDP qui teste connectivité
  - Credential expiré sur compte de service
level: high
tags:
  - attack.credential_access
  - attack.t1110.001

Stratégie d'investigation

1. Volume et tempo : combien de tentatives en combien de temps, quelle distribution (rapide brute force vs slow password spraying) ?
2. Comptes ciblés : single account (brute force ciblé) vs multiple accounts (password spraying) vs admin accounts only ?
3. Source IP : géolocalisation, threat intel, lookup AbuseIPDB, historique scans Shadowserver.
4. Statut succès : y a-t-il un Event ID 4624 (Successful Logon) du même IP source dans les 30 minutes suivantes ? Si oui, brute force réussi, escalade critique.

Faux positifs typiques

• Comptes de service expirés : pattern de tentatives répétées avec credentials obsolètes.
• Bots de monitoring : services internes testant connectivité RDP.
• Configuration RDP client : utilisateur tapant mauvais mot de passe plusieurs fois.

Critères d'escalade L2

• Volume supérieur à 100 tentatives sur même cible en 5 minutes.
• Source IP étrangère sans business justification.
• Tentatives sur compte administrateur.
• Successful logon post-brute force = incident sévérité critique, escalade L3 immédiate.

Alerte 4 — Beaconing C2 outbound (T1071)

Tactique : Command and Control. Technique : Application Layer Protocol.

Le beaconing désigne le pattern de communication régulière entre un implant compromis et son serveur C2. Détection basée sur la régularité des connexions sortantes (jitter faible, intervalle constant), même si le contenu est chiffré TLS.

Règle Sigma (KQL Microsoft Sentinel)

// Détection beaconing : connexions répétées vers même destination
// avec jitter faible sur fenêtre 1 heure
DeviceNetworkEvents
| where Timestamp > ago(1h)
| where ActionType == "ConnectionSuccess"
| where RemoteIPType == "Public"
| summarize 
    count = count(),
    intervals = make_list(Timestamp),
    avgInterval = avg(datetime_diff('second', Timestamp, prev(Timestamp))),
    stddev = stdev(datetime_diff('second', Timestamp, prev(Timestamp)))
    by DeviceName, RemoteIP, RemotePort
| where count >= 10
| where stddev < 30  // Faible variation = beaconing régulier
| where avgInterval > 30 and avgInterval < 3600  // Intervalle 30s à 1h
| project DeviceName, RemoteIP, RemotePort, count, avgInterval, stddev

Stratégie d'investigation

1. Reputation IP/domaine : VirusTotal, URLhaus, ThreatCrowd, Greynoise pour scanner activity.
2. Volume de données : faible volume + régularité = check-in pattern. Volume important + irrégularité = exfiltration.
3. Process source : qui initie la connexion ? svchost.exe, powershell.exe, navigateur, processus inconnu ?
4. TLS fingerprint : JA3/JA3S hash, comparer aux patterns C2 connus (Cobalt Strike default JA3, Sliver, Brute Ratel).
5. DNS pattern : DGA (Domain Generation Algorithm) pattern — domaines aléatoires consonants, sub-domaines longs.

Faux positifs typiques

• Logiciels avec keep-alive : agents de monitoring (Datadog, New Relic), antivirus heartbeat, télémétrie OS.
• Backups réguliers : connexions vers cloud storage à intervalles fixes.
• Updates automatiques : Microsoft Update, Adobe Update, applications avec check périodique.

Critères d'escalade L2

• Destination IP non référencée dans baseline d'entreprise.
• Tunneling DNS over HTTPS (DoH) suspect.
• JA3 fingerprint match avec C2 connu.
• Process source dans %TEMP% ou %APPDATA%.

Alerte 5 — Lateral movement WMI (T1047)

Tactique : Lateral Movement. Technique : Windows Management Instrumentation.

WMI permet l'exécution de commandes à distance sur d'autres machines avec les bons credentials. Outil natif Windows, donc privilégié par attaquants pour rester sous le radar (living off the land).

Règle Sigma

title: WMI Process Creation Lateral Movement
id: 6629d7d1-93a9-4a1e-8138-c322e6c6cca9
description: >
  Détection de création de processus distant via WMI (wmiprvse.exe parent)
  classique pattern lateral movement.
references:
  - https://attack.mitre.org/techniques/T1047/
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith: '\wmiprvse.exe'
  filter_legitimate:
    Image|endswith:
      - '\WerFault.exe'
      - '\WMIADAP.EXE'
  condition: selection and not filter_legitimate
falsepositives:
  - Scripts d'administration légitimes (SCCM, GPO, monitoring)
  - Software inventory tools
level: high
tags:
  - attack.lateral_movement
  - attack.t1047

Stratégie d'investigation

1. Source machine : qui exécute WMI vers le host cible ? Compte privilégié ? Authentication source ?
2. Commande exécutée : process créé, command line complète, fichiers manipulés.
3. Pattern Impacket : détecter l'usage d'Impacket WMIexec qui laisse une signature (output dans ADMIN$ partage).
4. Timeline : enchaînement temporel (auth → WMI → process → exfil) ?

Faux positifs typiques

• SCCM client : push de configurations via WMI.
• Outils de monitoring : agents qui collectent inventory via WMI.
• GPO scripts : exécution distribuée légitime.

Critères d'escalade L2

• Compte source non admin légitime.
• Commande créant processus comme cmd.exe, powershell.exe, regsvr32.exe.
• Combinaison avec credential dumping détecté précédemment sur source.
• Pattern Impacket WMIexec (output redirection vers ADMIN$).

Alerte 6 — Persistence Registry Run keys (T1547.001)

Tactique : Persistence. Technique : Boot or Logon Autostart Execution — Registry Run Keys / Startup Folder.

Modification des clés HKCU\Software\Microsoft\Windows\CurrentVersion\Run ou HKLM\Software\Microsoft\Windows\CurrentVersion\Run pour persistence au démarrage utilisateur ou système.

Règle Sigma

title: Suspicious Registry Run Key Modification
id: cf06f1fa-c43d-43cb-9252-f01b5ec7df8a
description: >
  Détection modification clé Registry Run par processus non administratif.
references:
  - https://attack.mitre.org/techniques/T1547/001/
logsource:
  product: windows
  category: registry_event
detection:
  selection:
    EventType: SetValue
    TargetObject|contains:
      - 'Software\Microsoft\Windows\CurrentVersion\Run'
      - 'Software\Microsoft\Windows\CurrentVersion\RunOnce'
      - 'Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run'
      - 'Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run'
  filter_legitimate:
    Image|endswith:
      - '\msiexec.exe'
      - '\OneDrive.exe'
      - '\setup.exe'
    Image|contains:
      - '\Program Files\'
      - '\Program Files (x86)\'
  condition: selection and not filter_legitimate
falsepositives:
  - Installation logicielle légitime (apps Microsoft Store, OneDrive sync)
level: medium
tags:
  - attack.persistence
  - attack.t1547.001

Stratégie d'investigation

1. Image cible de la clé Run : chemin, signature, hash, présent depuis quand ?
2. Process modificateur : process qui a écrit la clé, parent tree.
3. Valeur : la commande complète ajoutée à la clé Run.
4. Test exécution : que fait la commande au prochain logon ?

Faux positifs typiques

• OneDrive sync : modification fréquente lors des updates.
• Installations Microsoft Store : ajouts légitimes au démarrage.
• Drivers et utilitaires hardware : NVIDIA, Logitech, etc.

Critères d'escalade L2

• Image cible dans %TEMP%, %APPDATA%\Local\Temp, Public\.
• Image non signée ou signée par éditeur inconnu.
• Combinaison avec autre TTP de persistence (tâche planifiée, service Windows nouveau).

Alerte 7 — Cloud metadata access depuis container (T1552.005)

Tactique : Credential Access. Technique : Unsecured Credentials — Cloud Instance Metadata API.

Accès à l'IMDS (Instance Metadata Service) AWS (169.254.169.254), Azure (169.254.169.254) ou GCP (metadata.google.internal) depuis un container, pattern Capital One 2019. Permet l'exfiltration des credentials IAM associés à l'instance.

Règle Falco (runtime container)

- rule: Cloud Metadata Service Access from Container
  desc: >
    Détection d'accès au IMDS AWS, Azure ou GCP depuis un container,
    indicateur potentiel de credential exfiltration.
  condition: >
    container and
    (fd.sip = "169.254.169.254" or
     fd.sip = "100.100.100.200" or
     (fd.cname = "metadata.google.internal" or
      fd.cname = "metadata.azure.com"))
  output: >
    Cloud metadata access detected from container
    (user=%user.name container=%container.name image=%container.image.repository
    target=%fd.sip:%fd.sport pid=%proc.pid cmdline=%proc.cmdline)
  priority: WARNING
  tags: [container, credential_access, mitre_t1552_005]

Stratégie d'investigation

1. Container source : image, namespace Kubernetes, owner Pod, application.
2. Process : binaire qui initie la requête, command line.
3. Volume : single request (probablement légitime SDK init) vs scan complet metadata path (suspect).
4. Réponse : contenu retourné, particulièrement /latest/meta-data/iam/security-credentials/ pour AWS.
5. Activité IAM concomitante : utilisation des credentials IAM de l'instance dans CloudTrail dans les minutes suivantes.

Faux positifs typiques

• SDK cloud légitimes : aws-cli, azure-cli, gcloud SDK qui accèdent IMDS pour authentication.
• Container IAM role discovery : SDK Java/Python AWS qui résolvent le rôle au démarrage.
• Health checks : services cloud-native qui vérifient identité.

Critères d'escalade L2

• Process source non lié à un SDK cloud (curl, wget, python brut).
• Pattern de scan : énumération de plusieurs paths metadata séquentiellement.
• Combinaison avec écriture de fichier dans /tmp (potentiel exfiltration).
• IMDSv1 (sans token) au lieu d'IMDSv2 (avec token PUT obligatoire).

Patterns d'escalade L1 → L2 → L3

Critères généraux d'escalade par niveau de confidence et de criticité.

Documentation minimum pour escalade

• Alerte source : ID SIEM, règle, timestamp.
• Contexte technique : host, user, process tree, IPs source/destination, commandes exécutées, fichiers manipulés.
• Évidence : screenshots EDR, logs raw exportés, hashes, IOCs.
• Mapping ATT&CK : technique(s) identifiée(s).
• Confidence level : low / medium / high / confirmed.
• Recommandation : action proposée par L1.

Outils et stacks recommandés en 2026

Stack SOC opérationnel mature 2026, avec alternatives commerciales et open source.

Bibliothèques de règles publiques

• SigmaHQ : 3 000+ règles MITRE ATT&CK alignées.
• Splunk Security Content : règles SPL Splunk officielles.
• Microsoft Sentinel Hunting Queries : repo GitHub Microsoft.
• Elastic Detection Rules : règles Elastic Security publiques.
• Falco rules : règles runtime container officielles + community.

Points clés à retenir

• Une alerte SOC suit une méthodologie en 6 étapes : triage, pivot EDR, threat intel, mapping ATT&CK, verdict, action. 15 à 35 minutes par alerte L1 en moyenne.
• Sept familles d'alertes couvrent la majorité des incidents quotidiens : Mimikatz LSASS, PowerShell DownloadString, RDP brute force, beaconing C2, lateral movement WMI, persistence Run keys, cloud metadata access.
• Sigma est devenu standard de facto pour les règles de détection en 2026, avec 3 000+ règles publiques MITRE ATT&CK alignées via SigmaHQ.
• La discipline de documentation à chaque étape (template de ticket structuré) conditionne la rapidité d'escalade L1 → L2.
• L'EDR et le SIEM sont complémentaires : EDR pour détection runtime endpoint, SIEM pour corrélation cross-source. SOAR pour orchestrer les réponses.

Pour aller plus loin

• Container escape : techniques et défenses - contexte technique de l'alerte 7 (cloud metadata access).
• Sécurité Kubernetes : les bases - couche détection runtime cloud-native.
• Sécurité d'un VPS : checklist - hardening hôte qui réduit la surface d'attaque vue par le SOC.
• Secrets management cloud - prévention en amont des credential dumping.