Zloraba Kerberosa: napadi, ki jih omogoca vasa infrastruktura Kerberos

Kerberos omogoča avtentikacijo v Active Directory. Gesla storitvenih računov, nastavitve delegacije in dostop do ključev za podpisovanje vstopnic vplivajo na možnosti zlorabe. Prispevek obravnava Kerberoasting, zlorabo delegacije in ponarejanje vstopnic ter kontrole in možnosti zaznavanja, ki jih lahko preverijo skrbniki.

Razumevanje teh napadnih poti z obrambne perspektive je bistveno. Če veste, kaj iščem, ko ciljam vašo infrastrukturo Kerberos, lahko ta vrata zaprete, preden pridem.

MITRE opisuje Kerberoasting, Microsoft pa zaščito storitvenih računov z gMSA. MITRE ATT&CK: Kerberoasting (T1558.003); Microsoft: secure group managed service accounts.

Kerberoasting: najzanesljivejši napad na AD

Kerberoasting ostaja moja najuspešnejša napadalna tehnika. Vsak avtenticiran uporabnik domene lahko zahteva storitveno vozovnico Kerberos (TGS) za katerikoli račun, ki ima registrirano ime storitve (SPN). Vstopnica je šifrirana z zgoščeno vrednostjo gesla storitvenega računa. To vozovnico vzamem brez povezave in jo razbijem s hashcat ali John the Ripper. Brez omrežnega prometa, brez alarmov, brez interakcije s ciljno storitvijo.

Razlog, da to tako zanesljivo deluje, je, da imajo storitveni računi skoraj vedno šibka, statična gesla. Po mojih izkušnjah se več kot 80% gesel storitvenih računov, ki jih izvlečem prek Kerberoastinga, razbije v eni uri. Mnoga se razbijejo v sekundah. Geslo "SqlService2020!" ni karikatura -- je resnično geslo, ki sem ga razbil na več projektih.

Kar naredi Kerberoasting uničujoč, ni samo obnovitev gesla. Ampak to, da so storitveni računi skoraj vedno preveč privilegirani. Imajo pravice Domain Admin, ker se je nekdo odločil, da aplikacija "potrebuje" povišani dostop, ali ker je dokumentacija prodajalca rekla, da je treba podeliti polna dovoljenja. Ko razbijem eno geslo storitvenega računa, imam pogosto ključe do celotne domene.

Obramba pred Kerberoastingom

Pomemben ukrep proti Kerberoastingu so Group Managed Service Accounts (gMSA). gMSA ima 240-bajtno naključno generirano geslo, ki se samodejno rotira vsakih 30 dni. Storitvene vozovnice gMSA je še vedno mogoče zahtevati, vendar dolgo naključno geslo praktično onemogoča ugibanje gesla brez povezave. Vsaka storitev, ki podpira gMSA, bi morala biti takoj prenesena.

Za storitve, ki ne morejo uporabljati gMSA, uveljavite gesla z vsaj 25 znaki in visoko entropijo. Ne uporabljajte človeško berljivih gesel za storitvene račune. Generirajte naključne nize in jih shranjujte v trezor za upravljanje privilegiranega dostopa. Rotirajte jih vsaj vsako četrtletje.

Na strani zaznavanja spremljajte dogodek ID 4769 na svojih krmilnikih domene. Iščite specifično zahteve za vozovnice z uporabo šifriranja RC4 (tip šifriranja 0x17). Sodobna okolja Windows bi morala uporabljati šifriranje AES. Porast zahtev za vozovnice RC4, zlasti iz enega samega vira, je močen indikator aktivnosti Kerberoastinga. Konfigurirajte svoj SIEM za alarm na ta vzorec.

AS-REP Roasting: bratranec Kerberoastinga

AS-REP Roasting cilja račune, ki imajo onemogočeno predavtentikacijo Kerberos. Ko je predavtentikacija onemogočena, lahko zahtevam AS-REP za račun brez podajanja kakršnihkoli poverilnic, odgovor pa vsebuje podatke, šifrirane z zgoščeno vrednostjo gesla uporabnika. Razbijem jih brez povezave enako kot pri Kerberoastingu.

Ta nastavitev je včasih onemogočena za združljivost s starejšimi aplikacijami ali starejšimi odjemalci. Popravek je neposreden: revidirajte vse račune v svoji domeni za zastavico "Do not require Kerberos preauthentication" in jo odstranite, kjerkoli je mogoče. Redno poganjajte to poizvedbo PowerShell: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True}. Vsak račun na tem seznamu je ranljiv.

Napadi z delegacijo: neomejena, omejena in RBCD

Delegacija Kerberos je ena izmed najbolj napačno razumljenih in najnevarnejših funkcij v Active Directory. Storitvi omogoča, da se predstavlja kot uporabnik pri dostopu do drugih storitev. Obstajajo trije tipi in vsi ustvarjajo priložnosti za napade, ko so napačno konfigurirani.

Neomejena delegacija je najnevarnejša. Ko se uporabnik avtenticira pri strežniku z neomejeno delegacijo, se njegova celotna vozovnica TGT shrani v pomnilnik na tem strežniku. Če kompromitiram ta strežnik, lahko izvlečem vsak TGT in se predstavljam kot vsak uporabnik, ki se je avtenticiral pri njem -- vključno z Domain Admini. Lahko tudi uporabim PrinterBug za prisiljevanje krmilnika domene, da se avtenticira pri mojem kompromitiranem strežniku, pri čemer zajamem TGT računa naprave DC-ja in izvedem napad DCSync.

Omejena delegacija omejuje, do katerih storitev je mogoče dostopati, a še vedno ima potencial za zlorabo. Če kompromitiram račun z nastavljeno omejeno delegacijo, lahko uporabim S4U2Self in S4U2Proxy za pridobitev storitvenih vozovnic za dovoljene ciljne storitve kot katerikoli uporabnik, vključno z Domain Admini.

Delegacija omejena na osnovi virov (RBCD) je najnovejša oblika in tista, ki jo najpogosteje zlorabljam med napadi NTLM relay. Če lahko spremenim atribut msDS-AllowedToActOnBehalfOfOtherIdentity na objektu računalnika, ga lahko konfiguriram, da zaupa računu naprave, ki ga nadziram, in se predstavljam kot katerikoli uporabnik pri tem računalniku.

Utrjevanje delegacije Kerberos

Začnite z revizijo vseh konfiguracij delegacije v svoji domeni. Uporabite BloodHound ali naslednje ukaze PowerShell za identifikacijo računov z omogočeno delegacijo. Za neomejeno delegacijo: Get-ADComputer -Filter {TrustedForDelegation -eq $True}. Za omejeno delegacijo: Get-ADComputer -Filter {msDS-AllowedToDelegateTo -like '*'}. Preglejte vsak rezultat in določite, ali je delegacija resnično potrebna.

Za račune, ki resnično potrebujejo delegacijo, uporabljajte omejeno delegacijo z onemogočenim prehodom protokolov, kadarkoli je mogoče. Dodajte vse privilegirane račune v varnostno skupino Protected Users, ki preprečuje predpomnjenje njihovih TGT-jev na delegiranih strežnikih. Označite vse občutljive račune z zastavico "Account is sensitive and cannot be delegated".

Spremljajte dogodek ID 4768 za zahteve TGT in dogodek ID 4769 za zahteve storitvenih vozovnic, povezane z delegacijo. Opazujte operacije S4U2Self in S4U2Proxy iz nepričakovanih virov. Ti dogodki se beležijo na krmilnikih domene in bi morali biti posredovani v vas SIEM za korelacijo.

Zlate in srebrne vozovnice: trajni dostop po kompromitaciji

Ko ima napadalec dostop Domain Admin in izvleče zgoščeno vrednost KRBTGT prek DCSync, lahko ponareja zlate vozovnice -- TGT-je, ki so veljavni za kateregakoli uporabnika, vključno z neobstoječimi računi, s katerimkoli članstvom v skupinah. Zlata vozovnica je veljavna za celotno življenjsko dobo gesla KRBTGT, ki v mnogih okoljih ni bilo nikoli spremenjeno.

Obramba je dvakratna zaporedna rotacija gesla KRBTGT, ki razveljavi vse obstoječe TGT-je. To bi moralo biti del vašega načrta odziva na incidente in bi moralo biti izvedeno proaktivno po rednem urniku. Microsoft priporoča rotacijo vsakih 180 dni. Uporabite uradni skript za ponastavitev KRBTGT in najprej testirajte v laboratorijskem okolju.

Redno poganjajte PingCastle ali Purple Knight za oceno konfiguracije Kerberos. Ti orodji identificirata račune s SPN-ji, ki so ranljivi za Kerberoasting, napačne konfiguracije delegacije in zastarela gesla KRBTGT. Njune ugotovitve obravnavajte kot kontrolni seznam za utrjevanje Kerberosa in jih sistematično obdelajte.

Povezano branje: LAPS, gMSA in večnivojska administracija: trije stebri obrambe AD; Tehnike napadov na Active Directory, ki jih uporabljam najpogosteje.