UAC - User Account Control
Last updated
Last updated
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Usa Trickest per costruire e automatizzare flussi di lavoro alimentati dagli strumenti comunitari più avanzati al mondo. Accedi oggi:
Il Controllo Account Utente (UAC) è una funzionalità che abilita un messaggio di consenso per attività elevate. Le applicazioni hanno diversi livelli di integrità, e un programma con un alto livello può eseguire compiti che potrebbero compromettere il sistema. Quando l'UAC è abilitato, le applicazioni e i compiti vengono sempre eseguiti sotto il contesto di sicurezza di un account non amministratore a meno che un amministratore non autorizzi esplicitamente queste applicazioni/compiti ad avere accesso di livello amministratore al sistema per essere eseguiti. È una funzionalità di comodità che protegge gli amministratori da modifiche non intenzionali ma non è considerata un confine di sicurezza.
Per ulteriori informazioni sui livelli di integrità:
Integrity LevelsQuando l'UAC è attivo, a un utente amministratore vengono forniti 2 token: una chiave per utente standard, per eseguire azioni regolari a livello normale, e una con i privilegi di amministratore.
Questa pagina discute come funziona l'UAC in grande dettaglio e include il processo di accesso, l'esperienza utente e l'architettura UAC. Gli amministratori possono utilizzare le politiche di sicurezza per configurare come funziona l'UAC specifico per la loro organizzazione a livello locale (utilizzando secpol.msc), o configurato e distribuito tramite Oggetti Criteri di Gruppo (GPO) in un ambiente di dominio Active Directory. Le varie impostazioni sono discusse in dettaglio qui. Ci sono 10 impostazioni di Criteri di Gruppo che possono essere impostate per l'UAC. La seguente tabella fornisce ulteriori dettagli:
| Impostazione Criteri di Gruppo | Chiave di Registro | Impostazione Predefinita |
|---|---|---|
FilterAdministratorToken | Disabilitato | |
EnableUIADesktopToggle | Disabilitato | |
ConsentPromptBehaviorAdmin | Richiedi consenso per binari non Windows | |
ConsentPromptBehaviorUser | Richiedi credenziali sul desktop sicuro | |
EnableInstallerDetection | Abilitato (predefinito per home) Disabilitato (predefinito per enterprise) | |
ValidateAdminCodeSignatures | Disabilitato | |
EnableSecureUIAPaths | Abilitato | |
EnableLUA | Abilitato | |
PromptOnSecureDesktop | Abilitato | |
EnableVirtualization | Abilitato |
Alcuni programmi sono autoelevati automaticamente se l'utente appartiene al gruppo amministratore. Questi binari hanno all'interno dei loro Manifesti l'opzione autoElevate con valore True. Il binario deve essere firmato da Microsoft anche.
Quindi, per bypassare l'UAC (elevare da livello di integrità medio a alto) alcuni attaccanti usano questo tipo di binari per eseguire codice arbitrario perché verrà eseguito da un processo di alta integrità.
Puoi controllare il Manifesto di un binario utilizzando lo strumento sigcheck.exe di Sysinternals. E puoi vedere il livello di integrità dei processi utilizzando Process Explorer o Process Monitor (di Sysinternals).
Per confermare se l'UAC è abilitato, fai:
Se è 1 allora UAC è attivato, se è 0 o non esiste, allora UAC è disattivato.
Poi, controlla quale livello è configurato:
Se 0 allora, UAC non chiederà (come disabilitato)
Se 1 l'amministratore è richiesto di fornire nome utente e password per eseguire il binario con diritti elevati (su Secure Desktop)
Se 2 (Sempre notificami) UAC chiederà sempre conferma all'amministratore quando tenta di eseguire qualcosa con privilegi elevati (su Secure Desktop)
Se 3 come 1 ma non necessariamente su Secure Desktop
Se 4 come 2 ma non necessariamente su Secure Desktop
se 5(predefinito) chiederà all'amministratore di confermare l'esecuzione di binari non Windows con privilegi elevati
Poi, devi dare un'occhiata al valore di LocalAccountTokenFilterPolicy
Se il valore è 0, allora, solo l'utente RID 500 (Amministratore integrato) è in grado di eseguire compiti di amministrazione senza UAC, e se è 1, tutti gli account all'interno del gruppo "Administrators" possono farlo.
E, infine, dai un'occhiata al valore della chiave FilterAdministratorToken
Se 0(predefinito), l'account Amministratore integrato può eseguire compiti di amministrazione remota e se 1 l'account Amministratore integrato non può eseguire compiti di amministrazione remota, a meno che LocalAccountTokenFilterPolicy sia impostato su 1.
Se EnableLUA=0 o non esiste, nessun UAC per nessuno
Se EnableLua=1 e LocalAccountTokenFilterPolicy=1, Nessun UAC per nessuno
Se EnableLua=1 e LocalAccountTokenFilterPolicy=0 e FilterAdministratorToken=0, Nessun UAC per RID 500 (Amministratore integrato)
Se EnableLua=1 e LocalAccountTokenFilterPolicy=0 e FilterAdministratorToken=1, UAC per tutti
Tutte queste informazioni possono essere raccolte utilizzando il modulo metasploit: post/windows/gather/win_privs
Puoi anche controllare i gruppi del tuo utente e ottenere il livello di integrità:
Nota che se hai accesso grafico alla vittima, il bypass UAC è semplice poiché puoi semplicemente cliccare su "Sì" quando appare il prompt UAC
Il bypass UAC è necessario nella seguente situazione: l'UAC è attivato, il tuo processo sta girando in un contesto di integrità medio e il tuo utente appartiene al gruppo degli amministratori.
È importante menzionare che è molto più difficile bypassare l'UAC se è al livello di sicurezza più alto (Sempre) rispetto a quando è in uno degli altri livelli (Predefinito).
Se l'UAC è già disabilitato (ConsentPromptBehaviorAdmin è 0) puoi eseguire una reverse shell con privilegi di amministratore (livello di integrità alto) utilizzando qualcosa come:
Se hai una shell con un utente che è all'interno del gruppo Amministratori puoi montare il C$ condiviso tramite SMB (file system) localmente in un nuovo disco e avrai accesso a tutto all'interno del file system (anche alla cartella home dell'Amministratore).
Sembra che questo trucco non funzioni più
Le tecniche di Cobalt Strike funzioneranno solo se UAC non è impostato al massimo livello di sicurezza.
Empire e Metasploit hanno anche diversi moduli per bypassare il UAC.
Documentazione e strumento in https://github.com/wh0amitz/KRBUACBypass
UACME che è una compilazione di diversi sfruttamenti del bypass UAC. Nota che dovrai compilare UACME utilizzando visual studio o msbuild. La compilazione creerà diversi eseguibili (come Source\Akagi\outout\x64\Debug\Akagi.exe), dovrai sapere quale ti serve.
Dovresti fare attenzione perché alcuni bypass potrebbero richiedere altri programmi che avviseranno l'utente che sta accadendo qualcosa.
UACME ha la versione di build da cui ogni tecnica ha iniziato a funzionare. Puoi cercare una tecnica che influisce sulle tue versioni:
Also, using this page you get the Windows release 1607 from the build versions.
Tutte le tecniche utilizzate qui per bypassare AUC richiedono una shell interattiva completa con la vittima (una comune shell nc.exe non è sufficiente).
Puoi ottenerlo utilizzando una sessione meterpreter. Migra a un processo che ha il valore Session uguale a 1:
(explorer.exe dovrebbe funzionare)
Se hai accesso a una GUI puoi semplicemente accettare il prompt UAC quando lo ricevi, non hai davvero bisogno di un bypass. Quindi, ottenere accesso a una GUI ti permetterà di bypassare l'UAC.
Inoltre, se ottieni una sessione GUI che qualcuno stava utilizzando (potenzialmente tramite RDP) ci sono alcuni strumenti che verranno eseguiti come amministratore da dove potresti eseguire un cmd ad esempio come admin direttamente senza essere nuovamente sollecitato da UAC come https://github.com/oski02/UAC-GUI-Bypass-appverif. Questo potrebbe essere un po' più furtivo.
Se non ti importa di essere rumoroso, potresti sempre eseguire qualcosa come https://github.com/Chainski/ForceAdmin che chiede di elevare i permessi fino a quando l'utente non lo accetta.
Se dai un'occhiata a UACME noterai che la maggior parte dei bypass UAC sfrutta una vulnerabilità di Dll Hijacking (principalmente scrivendo il dll malevolo su C:\Windows\System32). Leggi questo per imparare come trovare una vulnerabilità di Dll Hijacking.
Trova un binario che si autoelevi (controlla che quando viene eseguito funzioni a un livello di integrità elevato).
Con procmon trova eventi "NAME NOT FOUND" che possono essere vulnerabili a DLL Hijacking.
Probabilmente dovrai scrivere il DLL all'interno di alcuni percorsi protetti (come C:\Windows\System32) dove non hai permessi di scrittura. Puoi bypassare questo utilizzando:
wusa.exe: Windows 7, 8 e 8.1. Permette di estrarre il contenuto di un file CAB all'interno di percorsi protetti (perché questo strumento viene eseguito da un livello di integrità elevato).
IFileOperation: Windows 10.
Prepara uno script per copiare il tuo DLL all'interno del percorso protetto ed eseguire il binario vulnerabile e autoelevato.
Consiste nel controllare se un binario autoElevato cerca di leggere dal registro il nome/percorso di un binario o comando da eseguire (questo è più interessante se il binario cerca queste informazioni all'interno di HKCU).
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
