UAC - User Account Control
Last updated
Last updated
Utilisez Trickest pour construire et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde. Accédez dès aujourd'hui :
User Account Control (UAC) est une fonctionnalité qui permet une demande de consentement pour les activités élevées. Les applications ont différents niveaux d'intégrité, et un programme avec un niveau élevé peut effectuer des tâches qui pourraient compromettre le système. Lorsque UAC est activé, les applications et les tâches s'exécutent toujours sous le contexte de sécurité d'un compte non administrateur, sauf si un administrateur autorise explicitement ces applications/tâches à avoir un accès de niveau administrateur au système pour s'exécuter. Il s'agit d'une fonctionnalité de commodité qui protège les administrateurs contre les modifications non intentionnelles mais qui n'est pas considérée comme une limite de sécurité.
Pour plus d'informations sur les niveaux d'intégrité :
Integrity LevelsLorsque UAC est en place, un utilisateur administrateur se voit attribuer 2 jetons : une clé d'utilisateur standard, pour effectuer des actions régulières au niveau standard, et une avec les privilèges administratifs.
Cette page discute en profondeur du fonctionnement de UAC et inclut le processus de connexion, l'expérience utilisateur et l'architecture de UAC. Les administrateurs peuvent utiliser des stratégies de sécurité pour configurer le fonctionnement de UAC spécifique à leur organisation au niveau local (en utilisant secpol.msc), ou configuré et déployé via des objets de stratégie de groupe (GPO) dans un environnement de domaine Active Directory. Les différents paramètres sont discutés en détail ici. Il existe 10 paramètres de stratégie de groupe qui peuvent être définis pour UAC. Le tableau suivant fournit des détails supplémentaires :
| Paramètre de stratégie de groupe | Clé de Registre | Paramètre par défaut |
|---|---|---|
FilterAdministratorToken | Désactivé | |
EnableUIADesktopToggle | Désactivé | |
ConsentPromptBehaviorAdmin | Demande de consentement pour les binaires non-Windows | |
ConsentPromptBehaviorUser | Demande d'informations sur le bureau sécurisé | |
EnableInstallerDetection | Activé (par défaut pour la maison) Désactivé (par défaut pour l'entreprise) | |
ValidateAdminCodeSignatures | Désactivé | |
EnableSecureUIAPaths | Activé | |
EnableLUA | Activé | |
PromptOnSecureDesktop | Activé | |
EnableVirtualization | Activé | |
### Théorie de contournement de l'UAC |
Certains programmes sont automatiquement élevés si l'utilisateur appartient au groupe administrateur. Ces binaires ont à l'intérieur de leurs Manifestes l'option autoElevate avec la valeur True. Le binaire doit également être signé par Microsoft.
Ainsi, pour contourner l'UAC (passer du niveau d'intégrité moyen au niveau élevé), certains attaquants utilisent ce type de binaires pour exécuter du code arbitraire car il sera exécuté à partir d'un processus de niveau d'intégrité élevé.
Vous pouvez vérifier le Manifeste d'un binaire en utilisant l'outil sigcheck.exe de Sysinternals. Et vous pouvez voir le niveau d'intégrité des processus en utilisant Process Explorer ou Process Monitor (de Sysinternals).
Pour confirmer si l'UAC est activé, faites :
Si c'est 1 alors UAC est activé, si c'est 0 ou s'il n'existe pas, alors UAC est inactif.
Ensuite, vérifiez quel niveau est configuré :
Si 0, alors, UAC ne demandera pas (comme désactivé)
Si 1, l'administrateur doit entrer son nom d'utilisateur et mot de passe pour exécuter le binaire avec des droits élevés (sur le Bureau sécurisé)
Si 2 (Toujours me notifier), UAC demandera toujours confirmation à l'administrateur lorsqu'il essaie d'exécuter quelque chose avec des privilèges élevés (sur le Bureau sécurisé)
Si 3 comme 1 mais pas nécessaire sur le Bureau sécurisé
Si 4 comme 2 mais pas nécessaire sur le Bureau sécurisé
Si 5 (par défaut), il demandera à l'administrateur de confirmer l'exécution des binaires non Windows avec des privilèges élevés
Ensuite, vous devez vérifier la valeur de LocalAccountTokenFilterPolicy
Si la valeur est 0, alors, seul l'utilisateur RID 500 (Administrateur intégré) peut effectuer des tâches d'administration sans UAC, et si elle est 1, tous les comptes du groupe "Administrateurs" peuvent le faire.
Enfin, vérifiez la valeur de la clé FilterAdministratorToken
Si 0 (par défaut), le compte Administrateur intégré peut effectuer des tâches d'administration à distance et si 1, le compte intégré Administrateur ne peut pas effectuer des tâches d'administration à distance, sauf si LocalAccountTokenFilterPolicy est défini sur 1.
Si EnableLUA=0 ou n'existe pas, aucun UAC pour personne
Si EnableLua=1 et LocalAccountTokenFilterPolicy=1, aucun UAC pour personne
Si EnableLua=1 et LocalAccountTokenFilterPolicy=0 et FilterAdministratorToken=0, aucun UAC pour RID 500 (Administrateur intégré)
Si EnableLua=1 et LocalAccountTokenFilterPolicy=0 et FilterAdministratorToken=1, UAC pour tout le monde
Toutes ces informations peuvent être obtenues en utilisant le module metasploit: post/windows/gather/win_privs
Vous pouvez également vérifier les groupes de votre utilisateur et obtenir le niveau d'intégrité:
Notez que si vous avez un accès graphique à la victime, le contournement de l'UAC est simple car vous pouvez simplement cliquer sur "Oui" lorsque la fenêtre de l'UAC apparaît.
Le contournement de l'UAC est nécessaire dans la situation suivante : l'UAC est activé, votre processus s'exécute dans un contexte d'intégrité moyenne et votre utilisateur appartient au groupe des administrateurs.
Il est important de mentionner qu'il est beaucoup plus difficile de contourner l'UAC s'il est au niveau de sécurité le plus élevé (Toujours) que s'il est à l'un des autres niveaux (Par défaut).
Si l'UAC est déjà désactivé (ConsentPromptBehaviorAdmin est 0), vous pouvez exécuter un shell inversé avec des privilèges d'administrateur (niveau d'intégrité élevé) en utilisant quelque chose comme :
Si vous avez un shell avec un utilisateur qui est dans le groupe Administrateurs, vous pouvez monter le partage C$ via SMB (système de fichiers) localement sur un nouveau disque et vous aurez accès à tout à l'intérieur du système de fichiers (même le dossier personnel de l'administrateur).
Il semble que cette astuce ne fonctionne plus
Les techniques de Cobalt Strike ne fonctionneront que si l'UAC n'est pas réglé à son niveau de sécurité maximal
Empire et Metasploit ont également plusieurs modules pour contourner le UAC.
Documentation et outil disponible sur https://github.com/wh0amitz/KRBUACBypass
UACME qui est une compilation de plusieurs exploits de contournement de l'UAC. Notez que vous devrez compiler UACME en utilisant Visual Studio ou MSBuild. La compilation créera plusieurs exécutables (comme Source\Akagi\outout\x64\Debug\Akagi.exe), vous devrez savoir lequel vous avez besoin.
Vous devriez être prudent car certains contournements peuvent déclencher d'autres programmes qui alerteront l'utilisateur qu'il se passe quelque chose.
UACME indique la version de build à partir de laquelle chaque technique a commencé à fonctionner. Vous pouvez rechercher une technique affectant vos versions :
Toutes les techniques utilisées ici pour contourner l'UAC nécessitent un shell interactif complet avec la victime (un shell nc.exe classique n'est pas suffisant).
Vous pouvez obtenir une session meterpreter. Migrez vers un processus dont la valeur Session est égale à 1 :
(explorer.exe devrait fonctionner)
Si vous avez accès à une GUI, vous pouvez simplement accepter la demande UAC lorsque vous la recevez, vous n'avez pas vraiment besoin d'un contournement. Ainsi, l'accès à une GUI vous permettra de contourner l'UAC.
De plus, si vous obtenez une session GUI qu'une personne utilisait (potentiellement via RDP), il y a certains outils qui s'exécuteront en tant qu'administrateur à partir desquels vous pourriez exécuter une cmd par exemple en tant qu'administrateur directement sans être à nouveau sollicité par l'UAC comme https://github.com/oski02/UAC-GUI-Bypass-appverif. Cela pourrait être un peu plus furtif.
Si vous ne vous souciez pas d'être bruyant, vous pourriez toujours exécuter quelque chose comme https://github.com/Chainski/ForceAdmin qui demande d'élever les permissions jusqu'à ce que l'utilisateur l'accepte.
Si vous jetez un œil à UACME, vous remarquerez que la plupart des contournements de l'UAC exploitent une vulnérabilité de détournement de DLL (principalement en écrivant la DLL malveillante sur C:\Windows\System32). Lisez ceci pour apprendre à trouver une vulnérabilité de détournement de DLL.
Trouvez un binaire qui s'autoélève (vérifiez que lorsqu'il est exécuté, il s'exécute à un niveau d'intégrité élevé).
Avec procmon, trouvez les événements "NOM NON TROUVÉ" qui peuvent être vulnérables au détournement de DLL.
Vous devrez probablement écrire la DLL à l'intérieur de certains chemins protégés (comme C:\Windows\System32) où vous n'avez pas les autorisations d'écriture. Vous pouvez contourner cela en utilisant :
wusa.exe : Windows 7, 8 et 8.1. Il permet d'extraire le contenu d'un fichier CAB à l'intérieur de chemins protégés (car cet outil est exécuté à partir d'un niveau d'intégrité élevé).
IFileOperation : Windows 10.
Préparez un script pour copier votre DLL à l'intérieur du chemin protégé et exécuter le binaire vulnérable et autoélevé.
Consiste à surveiller si un binaire autoélevé tente de lire du registre le nom/chemin d'un binaire ou commande à exécuter (ceci est plus intéressant si le binaire recherche ces informations à l'intérieur du HKCU).
Utilisez Trickest pour construire et automatiser des workflows alimentés par les outils communautaires les plus avancés au monde. Accédez dès aujourd'hui :
