UAC et privilèges¶

Pourquoi UAC reste un contrôle de hardening¶

UAC cherche à empêcher qu'un utilisateur membre du groupe Administrators travaille en permanence avec un jeton d'administration complet. L'objectif est de limiter l'exposition des privilèges élevés.

Microsoft décrit ce modèle comme la base de l'Admin Approval Mode. En pratique, un administrateur interactif reçoit deux contextes d'exécution. Le poste utilise d'abord le contexte le moins privilégié.

Sur un poste où tout le monde travaille administrateur local, le code malveillant hérite plus facilement de privilèges puissants. Le passage par une demande d'élévation ajoute une rupture utile.

Comment fonctionne UAC¶

Quand un utilisateur standard ouvre une session, il reçoit un jeton standard. Toute action nécessitant des droits élevés doit présenter des identifiants.

Quand un utilisateur membre de Administrators ouvre une session, Windows crée deux jetons. Ce modèle est couramment appelé split-token.

Le premier est un jeton filtré. Les SID d'administration et plusieurs privilèges puissants sont retirés ou désactivés. Le shell interactif s'exécute en général avec ce jeton filtré.

Le second est un jeton élevé. Il n'est utilisé qu'après approbation UAC. Cette séparation évite d'exposer d'emblée le contexte administrateur complet.

Le composant qui présente l'interface de consentement est consent.exe. Sur un système Windows actuel, sa description de fichier est Interface utilisateur de consentement pour des applications administratives.

flowchart LR
    A["Ouverture de session"] --> B{"Utilisateur membre de Administrators ?"}
    B -->|Non| C["Jeton standard"]
    B -->|Oui| D["Jeton filtré + jeton élevé"]
    D --> E["Explorer.exe démarre avec le jeton filtré"]
    E --> F["Action nécessitant une élévation"]
    F --> G["AppInfo / consent.exe"]
    G -->|Refus| H["Exécution bloquée"]
    G -->|Acceptation| I["Nouveau processus avec jeton élevé"]

Les clés de registre UAC à connaître¶

Les réglages UAC principaux vivent sous : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Ils peuvent être lus localement, pilotés par GPO ou imposés par baseline.

Le paramètre le plus critique est EnableLUA. S'il vaut 0, le modèle UAC est désactivé. Le poste cesse alors d'utiliser l'Admin Approval Mode.

Microsoft recommande de laisser EnableLUA = 1. La désactivation supprime les invites UAC et fait travailler les comptes administrateurs avec leur jeton complet.

ConsentPromptBehaviorAdmin pilote le comportement des membres du groupe Administrators quand une élévation est nécessaire. ConsentPromptBehaviorUser pilote celui des utilisateurs standards.

$Path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
Get-ItemProperty -Path $Path |
  Select-Object EnableLUA,
                ConsentPromptBehaviorAdmin,
                ConsentPromptBehaviorUser,
                PromptOnSecureDesktop,
                ValidateAdminCodeSignatures

Lire correctement ConsentPromptBehaviorAdmin¶

Cette valeur décide comment Windows traite les demandes d'élévation pour un administrateur en Admin Approval Mode. Elle ne change pas les ACL ; elle change le chemin d'accès au jeton élevé.

La valeur 5 est la valeur par défaut sur les clients Windows. Elle déclenche un consentement pour les binaires non Windows. Elle est donc plus permissive que 2.

La valeur 2 demande un consentement sur le bureau sécurisé. Elle constitue le choix de hardening le plus courant côté poste utilisateur.

Lire correctement ConsentPromptBehaviorUser¶

Pour un utilisateur standard, UAC ne peut pas approuver une élévation sans identité administrative. Le système doit soit demander des credentials, soit refuser.

La valeur 0 provoque un refus automatique. Elle est utile dans des environnements très verrouillés ou quand aucune élévation interactive n'est autorisée.

La valeur 1 demande des credentials sur le bureau sécurisé. La valeur 3 demande des credentials hors bureau sécurisé. Le 1 est donc plus robuste.

Recommandation de baseline : ConsentPromptBehaviorAdmin = 2¶

La recommandation de baseline la plus fréquente consiste à exiger un consentement sur bureau sécurisé. Elle limite l'élévation silencieuse sans imposer la saisie d'un mot de passe admin.

ConsentPromptBehaviorAdmin = 2 est souvent retenu sur les postes clients. Il améliore la friction défensive tout en restant exploitable au quotidien.

Ce choix est plus strict que la valeur client par défaut 5. Il réduit les cas où un composant non Windows ou un installateur opportuniste obtient une élévation avec trop peu de friction.

Le bureau sécurisé isole l'invite de la session interactive normale. Le contenu affiché n'est alors plus dessiné dans le même bureau que les applications utilisateur.

$Path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
Set-ItemProperty -Path $Path -Name EnableLUA -Type DWord -Value 1
Set-ItemProperty -Path $Path -Name ConsentPromptBehaviorAdmin -Type DWord -Value 2
Set-ItemProperty -Path $Path -Name PromptOnSecureDesktop -Type DWord -Value 1

ValidateAdminCodeSignatures : ce que ce paramètre fait réellement¶

ValidateAdminCodeSignatures est souvent mal interprété. Il ne constitue pas un interrupteur universel contre toute auto-élévation Windows.

Sa fonction officielle est plus précise : élever uniquement les exécutables signés et validés. Il ajoute donc un contrôle de signature pour les applications interactives élevées.

La clé vit au même emplacement : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ValidateAdminCodeSignatures. Une valeur 1 active ce contrôle.

Il faut distinguer ce réglage du comportement par défaut 5. ConsentPromptBehaviorAdmin = 5 traite déjà différemment les binaires Windows et non Windows. ValidateAdminCodeSignatures renforce la confiance accordée à l'exécutable.

$Path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
Get-ItemProperty -Path $Path -Name ValidateAdminCodeSignatures

Set-ItemProperty -Path $Path `
  -Name ValidateAdminCodeSignatures `
  -Type DWord `
  -Value 1

Comptes d'administration dédiés : la vraie frontière¶

Le meilleur réglage UAC ne compense pas une mauvaise hygiène des identités. Si l'utilisateur quotidien est administrateur local, le poste reste un lieu de forte exposition des privilèges.

Microsoft recommande de réserver les privilèges élevés à des comptes administratifs distincts. L'utilisateur principal doit rester standard pour les usages courants.

Cette séparation réduit l'exposition aux attaques locales. Un malware exécuté dans la session bureautique n'obtient pas immédiatement un contexte admin persistant.

Elle réduit aussi la valeur d'un poste compromis pour les attaques de propagation. Moins il y a de comptes privilégiés qui s'y connectent, moins il y a de secrets, de jetons ou de traces d'usage à réutiliser.

Le modèle de tiers Microsoft et les approches modernes de Privileged Access Workstation vont dans ce sens. Les identités les plus sensibles doivent travailler depuis des environnements séparés.

Diagramme : de la demande d'élévation au jeton élevé¶

Le diagramme ci-dessous résume le chemin normal d'une élévation. Il montre où interviennent le jeton filtré, consent.exe et les réglages de policy.

flowchart TD
    A["Utilisateur connecté"] --> B["Shell avec jeton filtré ou standard"]
    B --> C["Application demande une élévation"]
    C --> D["AppInfo évalue manifeste, stratégie et contexte"]
    D --> E{"Type de compte ?"}
    E -->|Administrateur| F["consent.exe affiche une demande UAC"]
    E -->|Utilisateur standard| G["Demande de credentials administratifs"]
    F --> H{"ConsentPromptBehaviorAdmin"}
    G --> I{"ConsentPromptBehaviorUser"}
    H -->|Refus| J["Exécution refusée"]
    I -->|Refus ou auto-deny| J
    H -->|Acceptation| K["Création d'un nouveau processus avec jeton élevé"]
    I -->|Credentials valides| K
    K --> L["Processus élevé en High IL"]

GPO et registre : correspondances utiles¶

Pour l'exploitation, il faut savoir relier une clé de registre à son paramètre GPO. C'est ce qui permet de vérifier un poste, corriger un drift et documenter un écart.

LSAISO, VBS et isolation des secrets¶

UAC traite l'élévation interactive. Il ne protège pas à lui seul les secrets du système. Pour cela, il faut regarder du côté de VBS et de Credential Guard.

Quand Credential Guard est actif, Windows isole certains secrets du sous-système LSA dans un environnement virtualisé. Le processus LSAIso matérialise cette séparation.

Cette isolation n'est pas un composant UAC. Elle complète toutefois une même logique : réduire ce qu'un compromis local peut lire ou réutiliser.

En pratique, UAC réduit l'accès facile au jeton élevé. Credential Guard et VBS réduisent ensuite la valeur des secrets exposés en mémoire.

Pièges de déploiement¶

Le premier piège consiste à mesurer UAC au nombre de pop-ups. Un UAC silencieux n'est pas un UAC efficace. Il faut raisonner en exposition de privilèges, pas en confort apparent.

Le second piège consiste à tout résoudre avec ConsentPromptBehaviorAdmin = 0. Ce réglage peut masquer un problème applicatif, mais il crée une dette de sécurité immédiate.

Le troisième piège est organisationnel. Un poste avec une policy UAC correcte, mais utilisé quotidiennement avec un compte admin partagé, reste faible face à la compromission locale.