Securite et permissions¶

Ce que vous allez apprendre¶

• Comment les permissions du registre fonctionnent (DACL, SACL, heritage)
• Comment lire et modifier les permissions via Regedit et PowerShell
• La redirection WoW64 pour les applications 32 bits sur systemes 64 bits
• La virtualisation UAC et ses effets surprenants

Exemple concret d'abord¶

Regardons les permissions d'une cle du registre avec PowerShell :

$acl = Get-Acl "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
$acl.Access | Format-Table IdentityReference, RegistryRights, AccessControlType -AutoSize

IdentityReference              RegistryRights AccessControlType
------------------              -------------- -----------------
BUILTIN\Users                        ReadKey             Allow
BUILTIN\Administrators              FullControl             Allow
NT AUTHORITY\SYSTEM                 FullControl             Allow

Les utilisateurs peuvent lire, mais seuls les administrateurs et le systeme ont le controle total. C'est le modele de securite du registre en action.

Le modele de securite¶

Chaque cle du registre possede un descripteur de securite (security descriptor). C'est exactement le meme systeme que pour les fichiers NTFS.

Un descripteur contient 4 elements :

graph TD
    SD["Descripteur de securite"]
    SD --> O["Proprietaire<br/><small>Qui possede la cle</small>"]
    SD --> G["Groupe principal<br/><small>Rarement utilise</small>"]
    SD --> DACL["DACL<br/><small>Qui peut faire quoi</small>"]
    SD --> SACL["SACL<br/><small>Quels acces sont audites</small>"]

DPAPI et chiffrement des secrets du registre¶

Le contrôle d'accès ne suffit pas toujours. Quand Windows doit stocker des secrets sensibles dans le registre, il s'appuie aussi sur DPAPI (Data Protection API).

DPAPI chiffre des blobs de données en s'appuyant sur une clé dérivée :

• du mot de passe utilisateur pour les secrets liés à HKCU
• de la clé machine pour les secrets liés à HKLM

L'idée est simple : même si une application peut stocker une donnée dans le registre, elle ne la laisse pas forcément en clair. Le registre devient alors un conteneur de blobs chiffrés, et non de secrets lisibles directement.

Les LSA Secrets en pratique¶

Les LSA Secrets sont stockés sous HKLM\SECURITY\Policy\Secrets. Ils servent notamment à conserver :

• des mots de passe de comptes de service
• des secrets machine utilisés par Windows
• certains identifiants VPN ou mécanismes d'auto-logon

Cette zone n'est pas seulement protégée par une ACL stricte. Elle est aussi réservée au contexte SYSTEM, ce qui explique pourquoi même un administrateur local ne peut pas simplement l'ouvrir dans Regedit ou avec PowerShell.

# Attempting to read LSA Secrets as admin — will fail
try {
    Get-ChildItem "HKLM:\SECURITY\Policy\Secrets" -ErrorAction Stop
} catch {
    Write-Warning "Access denied — SECURITY hive requires SYSTEM privileges: $_"
}

WARNING: Access denied — SECURITY hive requires SYSTEM privileges: ...

Permissions detaillees¶

Permissions individuelles¶

Permissions groupees (ce que vous voyez dans Regedit)¶

Gerer les permissions¶

Via Regedit (graphique)¶

1. Clic droit sur une cle > Autorisations
2. Selectionnez un utilisateur ou groupe
3. Cochez les permissions souhaitees (Lecture, Controle total)
4. Pour des controles plus fins : cliquez sur Avance (heritage, audit, permissions individuelles)

Via PowerShell (scriptable)¶

Lire les permissions :

$acl = Get-Acl "HKLM:\SOFTWARE\MonApp"
$acl.Access | Format-Table IdentityReference, RegistryRights, AccessControlType

IdentityReference              RegistryRights AccessControlType
------------------              -------------- -----------------
BUILTIN\Administrators              FullControl             Allow
NT AUTHORITY\SYSTEM                 FullControl             Allow

Ajouter une permission :

$acl = Get-Acl "HKLM:\SOFTWARE\MonApp"

# Create a rule: Users can read the key
$rule = New-Object System.Security.AccessControl.RegistryAccessRule(
    "BUILTIN\Users",          # Who
    "ReadKey",                # What
    "ContainerInherit,ObjectInherit",  # Inherited by subkeys
    "None",                   # No propagation flags
    "Allow"                   # Allow or Deny
)

$acl.AddAccessRule($rule)
Set-Acl "HKLM:\SOFTWARE\MonApp" $acl

Aucune sortie si la commande reussit. Un message d'erreur apparait en cas de probleme (acces refuse, cle introuvable).

Prendre possession d'une cle :

$acl = Get-Acl "HKLM:\SOFTWARE\CleProtegee"
$admin = [System.Security.Principal.NTAccount]"BUILTIN\Administrators"
$acl.SetOwner($admin)
Set-Acl "HKLM:\SOFTWARE\CleProtegee" $acl

Aucune sortie si la commande reussit. Un message d'erreur apparait si le privilege SeTakeOwnershipPrivilege n'est pas disponible.

Via SubInACL (outil Microsoft)¶

rem Display permissions
subinacl /keyreg "HKEY_LOCAL_MACHINE\SOFTWARE\MonApp" /display

rem Grant read access to Users
subinacl /keyreg "HKEY_LOCAL_MACHINE\SOFTWARE\MonApp" /grant=Utilisateurs=r

HKEY_LOCAL_MACHINE\SOFTWARE\MonApp : new ace for Utilisateurs
HKEY_LOCAL_MACHINE\SOFTWARE\MonApp : 1 change(s)
Elapsed Time: 00 00:00:00
Done: 1, Modified 1, Failed 0, Syntax errors 0

Heritage des permissions¶

Par defaut, les sous-cles heritent des permissions de leur cle parente. C'est comme un dossier dont les fichiers heritent des permissions.

graph TD
    A["HKLM\SOFTWARE\MonApp<br/><small>Admins = Full Control<br/>Users = Read</small>"]
    A -->|"heritage"| B["Config<br/><small>herite des permissions parentes</small>"]
    A -->|"heritage"| C["Data<br/><small>herite des permissions parentes</small>"]
    C -->|"heritage bloque"| D["Secrets<br/><small>permissions explicites uniquement<br/>Admins = Full Control</small>"]
    style D fill:#c44,stroke:#333,color:#fff

Trois comportements possibles :

Redirection du registre (WoW64)¶

Sur un systeme 64 bits, Windows isole les applications 32 bits grace a une redirection transparente.

Comment ca marche¶

Quand une application 32 bits demande a acceder a une cle, Windows la redirige silencieusement :

Certaines cles sont partagees et ne sont pas redirigees (la meme cle est vue par les processus 32 et 64 bits) :

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
• HKLM\SOFTWARE\Classes (partiellement)

Forcer l'acces a une vue specifique¶

En code C, vous pouvez contourner la redirection :

// Force 64-bit view from a 32-bit process
RegOpenKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\MonApp",
             0, KEY_READ | KEY_WOW64_64KEY, &hKey);

// Force 32-bit view from a 64-bit process
RegOpenKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\MonApp",
             0, KEY_READ | KEY_WOW64_32KEY, &hKey);

En PowerShell, specifiez la vue :

# Open the 32-bit view from a 64-bit process
$key = [Microsoft.Win32.RegistryKey]::OpenBaseKey(
    [Microsoft.Win32.RegistryHive]::LocalMachine,
    [Microsoft.Win32.RegistryView]::Registry32
)
$subkey = $key.OpenSubKey("SOFTWARE\MonApp")

Virtualisation du registre (UAC)¶

C'est l'un des comportements les plus surprenants du registre.

Quand une application non elevee (sans droits admin) tente d'ecrire dans HKLM\SOFTWARE, au lieu de recevoir une erreur "Acces refuse", Windows redirige silencieusement l'ecriture vers :

HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\...

Conditions de la virtualisation¶

Comment detecter la virtualisation¶

Gestionnaire des taches > onglet Details > clic droit sur l'en-tete > 
Selectionner des colonnes > cocher "Virtualisation UAC"

Cela affiche une colonne indiquant si chaque processus est virtualise.

Persistance et vecteurs d'attaque courants¶

Le registre est une cible de premier plan pour les attaquants qui cherchent une persistance. Une simple valeur ajoutée au bon endroit peut suffire à relancer un malware à chaque boot, à chaque logon, voire à détourner l'exécution d'un binaire légitime.

Les mécanismes suivants font partie du minimum à connaître pour tout audit de sécurité Windows :

Run keys¶

Les clés Run et RunOnce sont les plus banales, donc les plus souvent vérifiées. Elles permettent de lancer un programme automatiquement à l'ouverture de session ou au prochain démarrage.

Leur force pour un attaquant est leur simplicité :

• une simple valeur REG_SZ suffit
• la persistance peut être limitée à l'utilisateur courant (HKCU) ou étendue à toute la machine (HKLM)
• beaucoup d'environnements tolèrent encore des entrées légitimes dans ces emplacements, ce qui masque le bruit

# Audit Run keys — compare against a known-good baseline
$runKeys = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
    "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run",
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
)
foreach ($key in $runKeys) {
    Write-Host "`n=== $key ===" -ForegroundColor Cyan
    Get-ItemProperty $key -ErrorAction SilentlyContinue |
        Select-Object * -ExcludeProperty PS* |
        Format-List
}

IFEO Hijacking¶

La clé Image File Execution Options (IFEO) est légitime : elle sert au débogage ou à certains mécanismes de compatibilité. Mais si une sous-clé contient une valeur Debugger, Windows peut lancer un autre programme à la place du binaire cible.

Pour un attaquant, c'est une technique redoutable :

• elle détourne un exécutable de confiance
• elle peut casser les outils de sécurité ou les utilitaires d'administration
• elle est souvent oubliée lors des contrôles de routine

# Detect suspicious IFEO entries (should have no Debugger value on production systems)
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" |
    Where-Object { $_.GetValue("Debugger") -ne $null } |
    Select-Object Name, @{N="Debugger";E={$_.GetValue("Debugger")}}

(aucune sortie — aucun Debugger défini)

Winlogon¶

La clé Winlogon contrôle une partie du chemin critique d'ouverture de session. Deux valeurs doivent être surveillées en priorité :

• Userinit, qui initialise la session utilisateur
• Shell, qui définit l'interface lancée après authentification

Une déviation minime suffit pour obtenir une persistance très fiable, exécutée très tôt dans la session.

# Verify Winlogon integrity — Userinit and Shell must not be altered
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" |
    Select-Object Userinit, Shell

Userinit : C:\Windows\system32\userinit.exe,
Shell    : explorer.exe