Pět cest k Domain Adminovi, které pořád fungují

Active Directory je plochá důvěryhodná struktura: kdo ovládne jeden špatně nastavený prvek, může se dostat až nahoru a odtud rozjet ransomware napříč doménou. Eskalace na Domain Admin proto nepotřebuje zero-day. Stačí kombinace nastavení, ze kterých každé zvlášť vypadá neškodně a která se v doméně vrství roky.

Následujících pět cest má společné dvě věci. Fungují z pozice běžného doménového uživatele, tedy odkudkoli po první získané identitě, a nepotřebují žádnou díru v samotném Windows. Stačí jim výchozí nebo pohodlné nastavení, které nikdo nezměnil. K té první identitě přitom nevede jen phishing: jednou z cest dovnitř je Wi-Fi jako vstup do vnitřní sítě z okolí budovy. Jestli si jich někdo ve firmě všimne, je jiná otázka. Popisujeme ji zvlášť u toho, jak se to samé chová při tiché operaci.

Kerberoasting využívá toho, že si jakýkoli přihlášený uživatel může vyžádat Kerberos servisní lístek (TGS) pro účet se SPN. Lístek je zašifrovaný hashem hesla toho servisního účtu, takže ho útočník odnese a láme offline. Proti doméně přitom neproběhne jediný pokus, který by šel zachytit.

Terčem jsou servisní účty s ručně nastaveným heslem. Rotace se u nich odkládá, protože změna hesla shodí službu, která ho používá, takže heslo zestárne a zůstane slabé. Když takový účet patří do skupiny s vysokým oprávněním, je po vylámání konec. Ještě horší je, když šifrování běží na RC4. Ten se láme výrazně rychleji než AES.

• Servisní účty převeďte na gMSA nebo jim dejte náhodné heslo o 25+ znacích, které se nedá vylámat.
• Vynuťte AES a vypněte RC4 tam, kde to prostředí unese.
• Vyndejte servisní účty z privilegovaných skupin. Servisní účet nemá co dělat v Domain Admins.
• Sledujte událost 4769 s typem šifrování 0x17 (RC4-HMAC) a neobvyklým objemem žádostí o lístky.

AS-REP roasting míří na účty, které mají vypnutou Kerberos předautentizaci. U nich dokáže kdokoli vytáhnout část odpovědi zašifrovanou heslem účtu a lámat ji offline. Princip je stejný jako u Kerberoastingu, jen k tomu není potřeba ani platný účet.

Příznak DONT_REQ_PREAUTH se objevuje u starých účtů a integrací, kde ho kdysi někdo zapnul kvůli kompatibilitě a zapomněl. Stačí jeden takový účet se slabým heslem a útočník má první identitu v doméně zadarmo.

• Projděte doménu na účty s příznakem DONT_REQ_PREAUTH a předautentizaci zapněte, kde to jde.
• Účtům, které příznak opravdu potřebují, dejte dlouhé náhodné heslo a hlídejte je.
• Auditujte událost 4768 s hodnotou Pre-Authentication Type 0, tedy přihlášení bez předautentizace.

NTLM relay nezneužívá heslo, ale samotnou autentizaci: útočník donutí oběť ověřit se vůči sobě a ověření v reálném čase přepošle na jinou službu, kde ho vydává za oběť. Když je cílem LDAP nebo webová registrace certifikátů v ADCS, dá se tím doménová identita eskalovat velmi rychle.

Vynutit ověření jde řadou triků: od podvržené SMB cesty po donucení serveru, aby se sám přihlásil. Pokud přijaté ověření nemá vynucené podepisování nebo channel binding, relay projde. Přeposláním na ADCS si útočník nechá vystavit certifikát na cizí účet a přihlásí se jako on.

• Vynuťte SMB signing a LDAP signing plus LDAP channel binding.
• Na webovém enrollmentu ADCS zapněte Extended Protection for Authentication a vypněte HTTP.
• Omezte nebo vypněte NTLM tam, kde ho už nic nepotřebuje.
• Zúžte přístup k rozhraním, přes která jde donutit autentizaci, aby je nezneužil kdokoli v síti.

ESC1 je chybně nastavená šablona certifikátu v Active Directory Certificate Services, u které smí žadatel sám určit, na koho certifikát zní, a šablona přitom umožňuje přihlašování (Client Authentication). Běžný uživatel si tak nechá vystavit certifikát znějící na doménového admina a přihlásí se jako on.

Ke zneužití stačí tři nastavení najednou: šablona s příznakem „subjekt dodá žadatel“, EKU pro přihlašování a enroll právo pro širokou skupinu uživatelů. Certifikát navíc platí měsíce, a to i po změně hesla oběti, takže je to i pohodlná perzistence.

• U šablon s Client Authentication vypněte „subjekt dodá žadatel“ (ENROLLEE_SUPPLIES_SUBJECT).
• Zapněte schválení správcem (manager approval) tam, kde žadatel subjekt určovat musí.
• Omezte enroll práva na nezbytné skupiny, ne na Domain Users.
• Zauditujte šablony a oprávnění nástrojem Certify nebo PSPKIAudit a projděte je pravidelně.

Group Policy Preferences kdysi uměly nastavit heslo přes GPO a uložit ho do XML v SYSVOL. Zašifrované bylo klíčem, který Microsoft sám zveřejnil. Číst ten adresář smí každý doménový uživatel, takže je takové heslo v praxi veřejné a dešifrovatelné během vteřin.

Aktualizace MS14-025 z května 2014 možnost rozdávat hesla přes tato rozšíření GPP odebrala, ale stará XML se zbytky atributu cpassword v SYSVOL zůstávají. Microsoft to píše rovnou v bulletinu: existující GPO update neodstraňuje. Když tam takové heslo je a pořád se používá, nebo je stejné jako u účtu s vyšším oprávněním, je to hotová cesta dál.

• Prohledejte SYSVOL na řetězec cpassword a všechna nalezená XML odstraňte.
• Změňte každé heslo, které kdy bylo přes GPP rozdané.
• Nerozdávejte hesla přes GPO; na lokální administrátorské heslo použijte Windows LAPS.
• Projděte i další místa ve SYSVOL, kde skripty a GPO mívají hesla v plaintextu: přihlašovací skripty, mapování disků.