UAC - User Account Control
Gebruik Trickest om maklik te bou en werkvloei te outomatiseer wat deur die wêreld se mees gevorderde gemeenskapstoestelle aangedryf word. Kry Toegang Vandag:
UAC
User Account Control (UAC) is 'n kenmerk wat 'n toestemmingprompt vir verhoogde aktiwiteite moontlik maak. Toepassings het verskillende integriteit
vlakke, en 'n program met 'n hoë vlak kan take uitvoer wat potensieel die stelsel kan kompromitteer. Wanneer UAC geaktiveer is, loop toepassings en take altyd onder die sekuriteitskonteks van 'n nie-administrateur rekening tensy 'n administrateur eksplisiet hierdie toepassings/take magtig om administrateurvlak toegang tot die stelsel te hê om te loop. Dit is 'n geriefkenmerk wat administrateurs beskerm teen onbedoelde veranderinge, maar word nie as 'n sekuriteitsgrens beskou nie.
Vir meer inligting oor integriteitsvlakke:
Integrity LevelsWanneer UAC in plek is, ontvang 'n administrateur gebruiker 2 tokens: 'n standaard gebruiker sleutel, om gereelde aksies as 'n gereelde vlak uit te voer, en een met die admin voorregte.
Hierdie bladsy bespreek hoe UAC in groot diepte werk en sluit die aanmeldproses, gebruikerservaring, en UAC argitektuur in. Administrateurs kan sekuriteitsbeleide gebruik om te configureer hoe UAC werk spesifiek vir hul organisasie op die plaaslike vlak (met behulp van secpol.msc), of geconfigureer en versprei via Groep Beleidsobjekte (GPO) in 'n Aktiewe Directory domein omgewing. Die verskillende instellings word in detail hier bespreek. Daar is 10 Groep Beleidsinstellings wat vir UAC gestel kan word. Die volgende tabel bied addisionele detail:
Groep Beleidsinstelling | Registrasie Sleutel | Standaard Instelling |
---|---|---|
FilterAdministratorToken | Gedeaktiveer | |
EnableUIADesktopToggle | Gedeaktiveer | |
ConsentPromptBehaviorAdmin | Vra om toestemming vir nie-Windows binêre | |
ConsentPromptBehaviorUser | Vra om geloofsbriewe op die veilige desktop | |
EnableInstallerDetection | Geaktiveer (standaard vir huis) Gedeaktiveer (standaard vir onderneming) | |
ValidateAdminCodeSignatures | Gedeaktiveer | |
EnableSecureUIAPaths | Geaktiveer | |
EnableLUA | Geaktiveer | |
PromptOnSecureDesktop | Geaktiveer | |
EnableVirtualization | Geaktiveer |
UAC Bypass Teorie
Sommige programme word automaties verhoog as die gebruiker behoort tot die administrateur groep. Hierdie binêre het binne hul Manifeste die autoElevate opsie met die waarde True. Die binêre moet ook onderteken wees deur Microsoft.
Dan, om te omseil die UAC (verhoog van medium integriteitsvlak na hoog) gebruik sommige aanvallers hierdie soort binêre om arbitraire kode uit te voer omdat dit vanaf 'n Hoë vlak integriteitsproses uitgevoer sal word.
Jy kan die Manifest van 'n binêre nagaan met die hulpmiddel sigcheck.exe van Sysinternals. En jy kan die integriteitsvlak van die prosesse sien met Process Explorer of Process Monitor (van Sysinternals).
Kontroleer UAC
Om te bevestig of UAC geaktiveer is, doen:
As dit 1
is, dan is UAC geaktiveer, as dit 0
is of dit nie bestaan nie, dan is UAC inaktief.
Kontroleer dan watter vlak geconfigureer is:
As
0
dan, UAC sal nie vra nie (soos deaktiveer)As
1
word die admin gevra vir gebruikersnaam en wagwoord om die binêre met hoë regte uit te voer (op Secure Desktop)As
2
(Altijd vra my) sal UAC altyd om bevestiging van die administrateur vra wanneer hy probeer om iets met hoë regte uit te voer (op Secure Desktop)As
3
soos1
maar nie noodsaaklik op Secure Desktop nieAs
4
soos2
maar nie noodsaaklik op Secure Desktop nieas
5
(standaard) sal dit die administrateur vra om te bevestig om nie-Windows binêre met hoë regte te laat loop
Dan moet jy na die waarde van LocalAccountTokenFilterPolicy
kyk
As die waarde 0
is, dan kan slegs die RID 500 gebruiker (ingeboude Administrateur) admin take sonder UAC uitvoer, en as dit 1
is, kan alle rekeninge binne die "Administrators" groep dit doen.
En, laastens kyk na die waarde van die sleutel FilterAdministratorToken
As 0
(standaard), kan die ingeboude Administrateur rekening afstandsadministrasietake doen en as 1
kan die ingeboude rekening Administrateur nie afstandsadministrasietake doen nie, tensy LocalAccountTokenFilterPolicy
op 1
gestel is.
Samevatting
As
EnableLUA=0
of nie bestaan nie, geen UAC vir enigiemandAs
EnableLua=1
enLocalAccountTokenFilterPolicy=1
, Geen UAC vir enigiemandAs
EnableLua=1
enLocalAccountTokenFilterPolicy=0
enFilterAdministratorToken=0
, Geen UAC vir RID 500 (Inggeboude Administrateur)As
EnableLua=1
enLocalAccountTokenFilterPolicy=0
enFilterAdministratorToken=1
, UAC vir almal
Al hierdie inligting kan versamel word met die metasploit module: post/windows/gather/win_privs
Jy kan ook die groepe van jou gebruiker nagaan en die integriteitsvlak kry:
UAC omseiling
Let daarop dat as jy grafiese toegang tot die slagoffer het, UAC omseiling eenvoudig is, aangesien jy net op "Ja" kan klik wanneer die UAS-prompt verskyn.
Die UAC omseiling is nodig in die volgende situasie: die UAC is geaktiveer, jou proses loop in 'n medium integriteitskonteks, en jou gebruiker behoort tot die administrateursgroep.
Dit is belangrik om te noem dat dit baie moeiliker is om die UAC te omseil as dit op die hoogste sekuriteitsvlak (Altijd) is as wanneer dit op enige van die ander vlakke (Standaard) is.
UAC gedeaktiveer
As UAC reeds gedeaktiveer is (ConsentPromptBehaviorAdmin
is 0
) kan jy 'n omgekeerde skulp met administrateursregte uitvoer (hoë integriteitsvlak) met iets soos:
UAC omseiling met token duplisering
Baie Basiese UAC "omseiling" (volledige lêerstelseltog)
As jy 'n shell het met 'n gebruiker wat binne die Administrators-groep is, kan jy die C$ gedeelde via SMB (lêerstelsel) plaaslik in 'n nuwe skyf monteer en jy sal toegang hê tot alles binne die lêerstelsel (selfs die Administrateur se tuisgids).
Dit lyk of hierdie truuk nie meer werk nie
UAC omseiling met cobalt strike
Die Cobalt Strike tegnieke sal slegs werk as UAC nie op sy maksimum sekuriteitsvlak gestel is nie
Empire en Metasploit het ook verskeie modules om die UAC te omseil.
KRBUACBypass
Dokumentasie en hulpmiddel in https://github.com/wh0amitz/KRBUACBypass
UAC omseil exploits
UACME wat 'n samestelling van verskeie UAC omseil exploits is. Let daarop dat jy UACME met visual studio of msbuild moet saamstel. Die samestelling sal verskeie uitvoerbare lêers skep (soos Source\Akagi\outout\x64\Debug\Akagi.exe
), jy moet weet watter een jy nodig het.
Jy moet versigtig wees omdat sommige omseilings ander programme kan vra wat die gebruiker sal waarsku dat iets aan die gebeur is.
UACME het die bou weergawe waaruit elke tegniek begin werk het. Jy kan soek na 'n tegniek wat jou weergawes beïnvloed:
Also, using this page you get the Windows release 1607
from the build versions.
Meer UAC omseil
Alle die tegnieke wat hier gebruik word om AUC te omseil vereis 'n volledige interaktiewe skulp met die slagoffer (n 'gewone nc.exe skulp is nie genoeg nie).
Jy kan dit kry deur 'n meterpreter sessie te gebruik. Migreer na 'n proses wat die Sessie waarde gelyk is aan 1:
(explorer.exe moet werk)
UAC Omseil met GUI
As jy toegang het tot 'n GUI kan jy net die UAC prompt aanvaar wanneer jy dit kry, jy het nie regtig 'n omseil nodig nie. So, toegang tot 'n GUI sal jou in staat stel om die UAC te omseil.
Boonop, as jy 'n GUI sessie kry wat iemand gebruik het (potensieel via RDP) is daar sommige gereedskap wat as administrateur sal loop van waar jy 'n cmd byvoorbeeld as admin direk kan uitvoer sonder om weer deur UAC gevra te word soos https://github.com/oski02/UAC-GUI-Bypass-appverif. Dit mag 'n bietjie meer stealthy wees.
Ratelige brute-force UAC omseil
As jy nie omgee om ratelig te wees nie, kan jy altyd iets soos https://github.com/Chainski/ForceAdmin loop wat vra om toestemmings te verhoog totdat die gebruiker dit aanvaar.
Jou eie omseil - Basiese UAC omseil metodologie
As jy na UACME kyk, sal jy opgemerk dat meeste UAC omseilings 'n Dll Hijacking kwesbaarheid misbruik (hoofsaaklik deur die kwaadwillige dll op C:\Windows\System32 te skryf). Lees dit om te leer hoe om 'n Dll Hijacking kwesbaarheid te vind.
Vind 'n binêre wat autoelevate (kontroleer dat wanneer dit uitgevoer word, dit in 'n hoë integriteitsvlak loop).
Met procmon vind "NAAM NIE GEVIND NIE" gebeurtenisse wat kwesbaar kan wees vir DLL Hijacking.
Jy sal waarskynlik die DLL binne sommige beskermde paaie (soos C:\Windows\System32) moet skryf waar jy nie skrywe toestemmings het nie. Jy kan dit omseil deur:
wusa.exe: Windows 7, 8 en 8.1. Dit laat jou toe om die inhoud van 'n CAB-lêer binne beskermde paaie te onttrek (omdat hierdie hulpmiddel van 'n hoë integriteitsvlak uitgevoer word).
IFileOperation: Windows 10.
Berei 'n script voor om jou DLL binne die beskermde pad te kopieer en die kwesbare en autoelevated binêre uit te voer.
Nog 'n UAC omseil tegniek
Bestaan uit om te kyk of 'n autoElevated binêre probeer om te lees van die register die naam/pad van 'n binêre of opdrag om uitgevoer te word (dit is meer interessant as die binêre hierdie inligting binne die HKCU soek).
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Last updated