Situatie
Client nou preluat, un producător local cu ~120 de utilizatori. Domeniul Active Directory rula din 2013, migrat de două ori (2008 R2 → 2016 → 2019), trecut prin trei administratori diferiți și zero audituri. Genul de AD despre care toată lumea spune “merge, nu-l atinge”. Exact tipul de infrastructură care merge… până în ziua în care nu mai merge, și atunci merge foarte prost.
M-au chemat pentru altceva — o migrare de file server — dar prima întrebare pe care o pun mereu la un client nou e: “când ați făcut ultimul audit de securitate pe AD?”. Răspunsul, ca de obicei: tăcere, apoi “păi… nu prea”. Am cerut o oră să rulez un scan rapid înainte să atingem orice. Ora aia a devenit proiectul lunii.
Ideea de fond: într-un AD vechi, riscul real nu e că cineva sparge o parolă. Riscul e că, prin acumulare de configurări proaste peste ani, un cont oarecare de utilizator poate ajunge Domain Admin în trei pași pe care nimeni nu i-a plănuit vreodată. Nu vezi asta uitându-te manual în ADUC. Vezi asta doar cu unelte care mapează relațiile.
Solutie
Am pornit cu PingCastle, pentru că îți dă o poză de ansamblu în cinci minute, fără agent, fără instalare, rulat de pe un simplu domain user. Nu ai nevoie de drepturi de admin ca să faci un health-check — și asta e chiar ideea îngrijorătoare: orice utilizator din domeniu poate citi enorm de multă structură.
# Rulat de pe o stație în domeniu, cont standard PingCastle.exe --healthcheck --server contoso.local # Rezultat: un raport HTML + un scor de risc (0 = perfect, 100 = dezastru)
Scorul lor pe patru categorii (Stale Objects, Privileged Accounts, Trusts, Anomalies) a ieșit 85. Peste 50 deja e considerat problematic. Ce a sărit imediat în ochi din raport:
- 34 de conturi cu parola setată "never expires" - 11 conturi de utilizator inactive de peste 2 ani, încă active - krbtgt password: ultima schimbare acum 9 ani (!) - 6 conturi de serviciu cu SPN și parole slabe (Kerberoasting risk) - LAPS: neinstalat (parole local admin identice pe ~90 stații) - 4 membri "uitați" în Domain Admins, dintre care 2 foști angajați
Fiecare linie de aici e o poveste. Dar cea care m-a oprit din tastat a fost krbtgt neschimbat de 9 ani. Contul krbtgt semnează toate tichetele Kerberos din domeniu. Dacă cineva a exfiltrat vreodată hash-ul lui în ultimii 9 ani — printr-un incident pe care nimeni nu l-a observat — poate fabrica Golden Tickets valabile la nesfârșit. Nu ai cum să știi retroactiv. Singura reacție corectă e să-l schimbi (de două ori, cu pauză între rotații).
PingCastle îți spune ce e stricat. Ca să înțeleg cât de exploatabil e, am trecut la BloodHound. Am rulat colectorul SharpHound tot de pe un cont standard de domeniu, în afara orelor de program ca să nu încarc DC-urile:
# Colectare (cont standard, non-privilegiat) SharpHound.exe -c All --zipfilename contoso_audit # Import în BloodHound Community Edition, apoi # rulezi query-urile pre-definite din tab-ul Analysis
Aici lucrurile s-au complicat frumos. Query-ul “Shortest Path to Domain Admins” a scos un traseu la care nimeni nu s-ar fi gândit uitându-se manual: un cont de utilizator din Helpdesk avea, printr-un grup imbricat moștenit dintr-o migrare veche, drept GenericWrite asupra unui grup care avea WriteDacl pe un cont de serviciu, care la rândul lui era membru într-un grup cu drepturi de reset de parolă pe un cont din Domain Admins.
Cu alte cuvinte: orice om de la helpdesk putea deveni Domain Admin în patru pași, folosind doar unelte legitime, fără să spargă nicio parolă și fără să declanșeze niciun antivirus. Traseul ăsta exista de ani de zile. Era invizibil în orice inspecție manuală, pentru că fiecare permisiune în parte părea rezonabilă. Doar lanțul complet era catastrofal.
Planul de remediere l-am făcut pe priorități, nu pe “reparăm tot deodată” — asta e cea mai bună cale să spargi producția:
Prioritate 1 (aceeași zi): - Rotație krbtgt x2 (cu 12h pauză între ele) - Scos cei 2 foști angajați din Domain Admins - Dezactivat conturile inactive > 2 ani Prioritate 2 (aceeași săptămână): - Rupt lanțul GenericWrite/WriteDacl din BloodHound - LAPS deployat pe toate stațiile - Conturi de serviciu: parole lungi (25+ caractere) sau gMSA Prioritate 3 (luna următoare): - Tiering model (Tier 0 / 1 / 2) pentru conturi admin - Politică de review trimestrial cu PingCastle
Rotația krbtgt a fost singura operațiune care m-a făcut să transpir puțin — o rotație greșită (ambele schimbări prea aproape una de alta) poate invalida tichete active și pica autentificări în tot domeniul. Am folosit scriptul oficial Microsoft Reset-KrbtgtKeyInteractive și am lăsat 12 ore între rotații ca să apuce toate DC-urile să replice. Zero downtime pentru utilizatori.
La reluarea PingCastle după două săptămâni, scorul a coborât de la 85 la 28. Nu zero — tiering model-ul complet e proiect de câteva luni — dar am eliminat toate căile de escaladare “instant” spre Domain Admins.
Cel mai valoros lucru pe care l-am învățat din auditul ăsta: un AD nesecurizat nu arată nesigur. Arată perfect normal. Merge. Utilizatorii se loghează, GPO-urile se aplică, nimic nu scârțâie. Riscul stă în relații acumulate în timp, nu în erori vizibile. De asta unelte ca BloodHound sunt indispensabile — ele văd graful, nu doar obiectele.
Trei lucruri pe care le recomand oricui are un domeniu mai vechi de trei ani: (1) rulează PingCastle măcar o dată — durează cinci minute și e gratis pentru un scan; dacă scorul e peste 50, ai treabă; (2) rulează BloodHound cu un cont standard, nu de admin — vrei să vezi ce vede un atacator care compromite un simplu laptop de la contabilitate; (3) verifică data ultimei schimbări a parolei krbtgt chiar acum, înainte să închizi articolul ăsta.
Și cea mai importantă lecție operațională: nu remedia tot deodată. Un audit AD scoate la iveală 40-50 de probleme și tentația e să le rezolvi într-un weekend eroic. Așa pici producția. Prioritizează pe impact (căi spre Domain Admins mai întâi), testează fiecare schimbare, documentează. Securitatea AD e o disciplină continuă, nu un proiect cu dată de final.
Leave A Comment?