UAC Windows : niveaux, risques et détection

Le contrôle de compte d’utilisateur, plus connu sous son sigle anglais UAC (User Account Control), est cette fenêtre qui s’assombrit sous Windows pour demander « Voulez-vous autoriser cette application à apporter des modifications à votre appareil ? ». Beaucoup d’utilisateurs la trouvent agaçante et la désactivent. Pour un attaquant, c’est pourtant une barrière à franchir avant d’obtenir les droits d’administrateur complets. Cet article explique comment fonctionne l’UAC, ce que change chacun de ses niveaux, les risques associés, comment le durcir, et surtout comment détecter qu’il a été affaibli.

Cadre d’usage : les manipulations décrites concernent vos propres postes ou ceux que vous administrez. Modifier les paramètres de sécurité d’une machine dont vous n’êtes pas responsable, ou chercher à contourner ses protections, est interdit sans autorisation (article 323-1 du Code pénal).

Comment fonctionne l’UAC ? #

Introduit avec Windows Vista, l’UAC repose sur un principe simple : même un compte administrateur ne travaille pas en permanence avec tous ses droits. À l’ouverture de session, Windows crée deux jetons d’accès :

• un jeton restreint (standard), utilisé par défaut pour les applications ;
• un jeton complet (élevé), utilisé seulement quand une application demande explicitement des droits d’administrateur et que l’utilisateur, ou une règle, l’autorise.

C’est ce qu’on appelle le mode d’approbation administrateur (Admin Approval Mode). Une application lancée sans élévation ne peut donc pas modifier le système, écrire dans les dossiers protégés ni changer la plupart des paramètres de sécurité. L’UAC ajoute aussi :

• l’invite sur le bureau sécurisé : l’écran s’assombrit et l’invite s’exécute dans un environnement isolé, que les programmes ordinaires ne peuvent ni lire ni cliquer ;
• la virtualisation de certaines écritures d’anciennes applications ;
• la demande d’identifiants pour les comptes standard : un utilisateur sans droits doit saisir le mot de passe d’un administrateur.

À savoir : Microsoft précise que l’UAC est une fonction de défense en profondeur et non une frontière de sécurité étanche. Des techniques de contournement existent et sont documentées dans le référentiel MITRE ATT&CK (T1548.002). L’UAC réduit les risques, il ne remplace ni un compte standard au quotidien, ni un EDR.

Les niveaux de l’UAC #

Dans Windows, un curseur propose quatre niveaux. Voici leurs effets et leur traduction technique :

Ce qui change concrètement pour la sécurité #

• Niveau 1 : le plus protecteur, mais plus d’invites, ce qui peut engendrer de la lassitude et des clics réflexes.
• Niveau 2 (défaut) : bon compromis pour la majorité des postes. Il protège contre l’exécution silencieuse de programmes tiers, tout en laissant les réglages Windows courants fluides.
• Niveau 3 : l’absence de bureau sécurisé permet à un programme malveillant en cours d’exécution d'interagir avec la fenêtre d’invite (simuler un clic, la masquer ou la remplacer par un faux). On perd une protection importante pour un gain de confort minime.
• Niveau 4 : pour un compte administrateur, un programme lancé devient administrateur sans demander l’avis de personne. Un fichier piégé ouvert par erreur, un document malveillant qui exécute du code, un script téléchargé : tous obtiennent les droits complets. C’est la configuration la plus dangereuse.

Il existe un état encore pire : l'UAC désactivé (option EnableLUA à 0), qui supprime le principe des deux jetons et impose un redémarrage. Certaines applications modernes ne fonctionnent d’ailleurs plus dans cet état.

Les paramètres qui définissent le niveau #

Le curseur n’est qu’une interface. Les réglages sont stockés dans la clé de registre HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System et pilotés en entreprise par les stratégies de groupe (GPO) ou par la gestion des appareils :

Pour ConsentPromptBehaviorAdmin, la valeur 0 correspond à une élévation sans invite : c’est le niveau « Ne jamais m’avertir ». Le niveau « par défaut » utilise la valeur 5, et « Toujours m’avertir » la valeur 2.

Deux réglages méritent une attention particulière :

• LocalAccountTokenFilterPolicy à 1 désactive le filtrage UAC pour l’administration à distance des comptes locaux : un attaquant qui obtient les identifiants (ou le condensat) d’un compte administrateur local peut alors s’en servir pour agir à distance avec des droits complets, y compris latéralement d’une machine à l’autre. C’est un affaiblissement discret et souvent recherché.
• FilterAdministratorAccount : le compte Administrateur intégré n’est pas soumis à l’UAC par défaut sur certaines configurations. Désactivez ce compte ou activez le mode d’approbation.

Vérifier l’état d’un poste #

Une commande PowerShell suffit pour afficher les valeurs en place :

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' |
  Select-Object EnableLUA, ConsentPromptBehaviorAdmin, ConsentPromptBehaviorUser,
                PromptOnSecureDesktop, FilterAdministratorAccount, LocalAccountTokenFilterPolicy

Si une valeur n’apparaît pas, c’est que la clé n’est pas définie explicitement : le système utilise alors son comportement par défaut. Comparez ensuite le résultat à votre référence, par exemple celle du CIS Benchmark (voir notre article sur les CIS Benchmarks) ou de la base de référence de sécurité Microsoft.

Le détail de chaque paramètre est décrit dans la documentation Microsoft, sous les stratégies « Contrôle de compte d’utilisateur » de la section Options de sécurité.

Détecter un affaiblissement de l’UAC #

Un attaquant qui vient d’obtenir un accès veut souvent réduire les protections avant d’aller plus loin. Baisser le niveau de l’UAC en fait partie. La détection repose sur la surveillance des modifications de ces valeurs de registre.

Ce qu’il faut surveiller #

Source 1 : Sysmon #

Sysmon journalise les modifications de valeurs de registre avec l’événement 13 (RegistryEvent, Value Set). Une règle de configuration ciblée :

<RegistryEvent onmatch="include">
  <TargetObject condition="contains any">Policies\System\EnableLUA;Policies\System\ConsentPromptBehaviorAdmin;Policies\System\ConsentPromptBehaviorUser;Policies\System\PromptOnSecureDesktop;Policies\System\FilterAdministratorAccount;Policies\System\LocalAccountTokenFilterPolicy</TargetObject>
</RegistryEvent>

L’événement indique le processus qui a écrit la valeur, son utilisateur, la clé et la nouvelle valeur. Ce contexte fait toute la différence entre un changement légitime et une action malveillante.

Source 2 : audit Windows natif #

Sans Sysmon, activez l'audit des objets du registre et posez une liste de contrôle d’accès (SACL) sur la clé Policies\System. Les modifications génèrent alors l’événement 4657 (valeur de registre modifiée) dans le journal Sécurité. Cette approche est plus lourde à déployer, mais utilise uniquement les fonctions du système.

Source 3 : la solution de sécurité #

Un EDR ou un XDR (voir notre comparaison EDR, antivirus et XDR) détecte souvent ces changements nativement. Vérifiez néanmoins que la règle existe et qu’elle génère une alerte que quelqu’un traite. Les règles publiques du projet Sigma contiennent aussi plusieurs détections liées à l’UAC, utilisables comme point de départ pour votre SIEM.

Détection complémentaire : les contournements #

Au-delà du changement de niveau, surveillez les signaux d’élévation suspecte :

• Événement 4688 (création de processus) avec la ligne de commande activée : le champ Token Elevation Type distingue un processus lancé avec un jeton restreint, complet ou élevé.
• Programmes Windows qui s’élèvent automatiquement et lancent des processus enfants inhabituels (un interpréteur de commandes, un script, un outil réseau).
• Écritures dans les clés de registre utilisateur liées aux associations de fichiers ou de protocoles (HKCU\Software\Classes) juste avant l’exécution d’un programme à élévation automatique : c’est un schéma de contournement classique décrit dans MITRE ATT&CK.
• Processus enfants d’un programme d’administration ouvert par un utilisateur qui n’a aucune raison de l’utiliser.

Que faire en cas d’alerte ? #

1. Identifier l’auteur du changement : quel processus, quel compte, à quelle heure.
2. Vérifier la légitimité : est-ce une GPO, un outil de déploiement, une intervention planifiée ? Sinon, considérez-le comme un incident.
3. Isoler le poste si le contexte est suspect, en conservant les preuves (voir notre article sur les logiciels forensiques Windows).
4. Chercher ce qui s’est passé avant et après : processus lancés, comptes créés, connexions distantes, outils déposés.
5. Restaurer la valeur attendue, idéalement en réappliquant la stratégie de groupe, puis redémarrer si nécessaire.
6. Chercher la cause : comment l’attaquant a-t-il obtenu des droits suffisants pour modifier une clé de la machine ?
7. Consigner l’analyse, par exemple avec nos mémos de clôture d’alerte.

Bonnes pratiques de durcissement #

• Travaillez avec un compte standard au quotidien, avec un compte administrateur distinct pour les interventions.
• Gardez au minimum le niveau par défaut, et préférez « Toujours m’avertir » sur les postes sensibles ou d’administration.
• Ne baissez jamais l’UAC pour « faire fonctionner » un logiciel : corrigez l’application ou lancez-la avec une élévation ciblée.
• Verrouillez les paramètres par GPO ou par votre solution de gestion, pour empêcher toute modification locale non voulue.
• Utilisez des mots de passe d’administrateur locaux uniques par machine, avec une solution de rotation, pour limiter les mouvements latéraux.
• Laissez LocalAccountTokenFilterPolicy à sa valeur par défaut sauf besoin explicite et documenté.
• Surveillez les modifications des clés sensibles et alertez sur les valeurs critiques.
• Complétez l’UAC par un EDR, des mises à jour régulières et, pour les données, le chiffrement BitLocker.

Erreurs fréquentes #

• Croire que l’UAC est une protection infaillible. C’est un garde-fou, pas un rempart.
• Désactiver l’UAC par confort, parfois dans une image système déployée à toute une flotte.
• Travailler en administrateur permanent et cliquer « Oui » sans lire.
• Ignorer les événements de modification de la clé Policies\System parce qu’ils sont rares : leur rareté est justement ce qui les rend précieux.
• Ne pas distinguer un changement légitime (GPO) d’un changement local suspect.

Aide-mémoire #

• EnableLUA = 1 sur tous les postes
• ConsentPromptBehaviorAdmin différent de 0
• PromptOnSecureDesktop = 1
• LocalAccountTokenFilterPolicy non défini ou à 0
• Paramètres imposés par GPO ou par la gestion des appareils
• Sysmon (événement 13) ou audit 4657 en place sur Policies\System
• Alertes critiques sur EnableLUA et ConsentPromptBehaviorAdmin à 0
• Comptes standard au quotidien, comptes administrateurs distincts
• Procédure de réponse documentée

Points clés #

L’UAC sépare les droits standard des droits d’administrateur et oblige à un consentement avant toute élévation. Ses quatre niveaux vont d’une protection élevée (« Toujours m’avertir ») à une absence totale de barrière (« Ne jamais m’avertir »), et l’absence de bureau sécurisé ou l’élévation silencieuse offrent à un code malveillant un accès administrateur sans obstacle. Il ne s’agit pas d’une frontière étanche, mais d’une couche utile : conservez au moins le niveau par défaut, verrouillez-le par stratégie, et surveillez les modifications de ses valeurs de registre. Une baisse du niveau de l’UAC en dehors d’un changement planifié doit être traitée comme un signal d’intrusion.