Zakaj dobim Domain Admina pri vsakem penetracijskem testu

Ljudje me sprašujejo, zakaj je penetracijski test vreden stroška, ko "že imamo EDR in požarno pregrado." Nato jim pokažem, kako dobim dostop Domain Admin v njihovem okolju, običajno v nekaj urah.

Resnica, ki vam je varnostni ponudniki ne bodo povedali: izdelki ne popravijo napačnih konfiguracij. Lahko imate najboljši EDR, na trgu, ampak če imajo vaši storitveni računi šibka gesla in privilegije Domain Admin, bom to izkoristil. Noben alarm ne bo sprožen, ker uporabljam legitimne protokole na način, kot so namenjeni.

Za priporočene nastavitve podpisovanja in upravljanje storitvenih računov glejte Microsoftovo dokumentacijo. Microsoft: SMB signing; Microsoft: secure group managed service accounts.

Moja standardna napadalna pot

Tukaj je, kako izgleda tipičen dan, ko začnem interni penetracijski test:

Ura 1: Priključim se v omrežje in poženem Responder. V nekaj minutah zajemam NTLMv2 zgoščene vrednosti iz naprav, ki iščejo omrežne vire. Večino časa je SMB-podpisovanje onemogočeno, tako da lahko te neposredno preusmerim.

Ura 2: Medtem ko teče Responder, pregledam domeno s standardnim uporabniškim računom (pogosto iz kompromitirane delovne postaje ali poverilnic iz zajetih zgoščenih vrednosti). Najdem storitvene račune s SPN-ji in zahtevam njihove Kerberos vozovnice.

Ura 3: Razbijam gesla storitvenih računov. "SqlService2019!" razbijem v manj kot minuti. Storitveni račun ima pravice Domain Admin, ker je "aplikacija potrebovala povišane privilegije."

Ura 4: Sem Domain Admin. Projekt se je šele začel.

Kaj gre narobe

Tukaj ne gre za sofisticirano hekanje. Gre za osnovno higieno, ki se jo ignorira:

• Brez SMB-podpisovanja = preusmerjam poverilnice prosto
• Šibka gesla storitvenih računov = Kerberoasting deluje
• Preveč privilegirani računi = ena kompromitacija vodi v popolno kompromitacijo
• Brez segmentacije omrežja = moj dostop iz ene delovne postaje mi omogoča dostop do vseh sistemov
• Brez večnivojskega administratorskega modela = Domain Admini se prijavljajo na delovne postaje

Problem z beleženjem

Ko prosim podjetja, naj mi pokažejo svoje varnostne dnevnike AD, običajno dobim prazen pogled. Beležijo dogodke krmilnika domene na lokalno shrambo, ki se napolni vsakih nekaj dni. Nihče jih ne pregleduje.

Tudi ko je beleženje konfigurirano:

• Ne spremljajo Kerberoastinga (dogodek 4769 z RC4)
• Ne alarmirajo na poskuse NTLM relay
• Ne sledijo operacijam DCSync
• Ne opazujejo sumljive uporabe storitvenih računov

Lahko delujem dneve brez sprožanja enega samega alarma, ker nihče ni konfiguriral alarmov za napade, ki jih dejansko izvajam.

Kaj bi morali storiti

Preden najamete penetracijskega testerja, popravite očitne težave:

1. Omogočite SMB in LDAP-podpisovanje povsod
2. Uporabljajte Group Managed Service Accounts (gMSA)
3. Poženite BloodHound proti svoji lastni domeni
4. Uvedite večnivojski administratorski model
5. Konfigurirajte pravilno beleženje in ga dejansko spremljajte
6. Onemogočite NTLM, kjer je mogoče

Nato najemite penetracijskega testerja. Ne za potrditev, da je vaše omrežje varno, ampak da najdete težave, ki ostanejo po tem, ko ste popravili osnovne pomanjkljivosti.

Rajši bi našel manj težav, ker ste naredili osnove, kot pa vam dal 200-stransko poročilo polno istih problemov, ki jih ima vsako podjetje. Ta poročila vas ne naredijo bolj varne. Samo vas seznanijo s problemi, za katere bi morali že vedeti.

Povezano branje: Napadalna veriga v Active Directory; Dnevniški zapisi za odzivanje na incidente: kaj potrebujemo za preiskavo.