Active Directory Hardening – Deo 5: Monitoring i detekcija – ključni Event ID-jevi

Prethodna četiri dela serije bavila su se prevencijom — kako podesiti AD tako da napad bude što teži. Peti deo prelazi na drugu stranu iste medalje: kako znati da se napad dešava, ili da se već desio. Dobra prevencija smanjuje broj vrata na koja neko može da pokuca, ali nijedna organizacija ne može da zatvori baš svaka vrata — zato monitoring i detekcija moraju da postoje kao samostalan sloj odbrane, ne kao naknadna misao.

Zašto "uključen audit log" nije isto što i monitoring

Česta zabluda je da je dovoljno uključiti audit politiku i log će "biti tu ako ikad zatreba". U praksi, domain kontroler srednje velikog okruženja generiše na hiljade, često i milione bezbednosnih događaja dnevno. Bez jasno definisanog, uskog skupa Event ID-jeva na koje se aktivno reaguje, taj log je samo trošak skladištenja — koristan tek naknadno, u forenzičkoj analizi posle incidenta, a ne za sprečavanje ili rano otkrivanje.

Druga česta zamka: neki od najvažnijih događaja jednostavno se ne generišu ako odgovarajuća napredna audit politika (Advanced Audit Policy) nije eksplicitno uključena — podrazumevana podešavanja domena često nisu dovoljna.

DCSync — napad koji ne dodiruje domain kontroler

DCSync je poseban po tome što ne zahteva nikakav pristup fajl sistemu ili memoriji domain kontrolera — napadač jednostavno iskoristi legitiman protokol za replikaciju direktorijuma (MS-DRSR) i zatraži od domain kontrolera da mu "pošalje izmene", kao da je i sam domain kontroler. Ako napadač poseduje nalog sa pravom "Replicating Directory Changes All", može na ovaj način izvući heš vrednosti lozinki bilo kog naloga u domenu — uključujući i KRBTGT nalog, čija kompromitacija otvara vrata ka Golden Ticket napadu.

Šta treba uraditi

• Uključiti Audit Directory Service Access (Success) u naprednoj audit politici — bez ovoga, Event ID 4662 se uopšte ne generiše i DCSync ostaje potpuno nevidljiv za log-baziranu detekciju
• U SIEM-u filtrirati Event ID 4662 na specifične GUID vrednosti koje označavaju replikaciona prava (Replicating Directory Changes / Replicating Directory Changes All), isključujući naloge samih domain kontrolera
• Tretirati svaki takav zahtev sa naloga koji nije domain kontroler kao kritičan alarm — legitimnih razloga za ovo praktično nema van planiranog uvođenja novog domain kontrolera
• Redovno proveravati (bar kvartalno) ko sve u domenu poseduje "Replicating Directory Changes All" pravo van same Domain Controllers grupe — ovo pravo se ponekad nehotice dodeli kroz preširoku delegaciju
• Rotirati KRBTGT lozinku redovno (uobičajena preporuka je bar svakih 180 dana), a obavezno i odmah nakon svake sumnje na DCSync ili slično kompromitovanje — rotacija se mora izvesti dvaput, sa razmakom, da bi se poništila i prethodna verzija lozinke

Forged tikete — Golden i Silver Ticket

Kad napadač jednom dobije KRBTGT heš (obično upravo preko DCSync-a), može da izradi sopstvenu, potpuno validnu Ticket Granting Ticket (TGT) kartu — takozvani Golden Ticket — koja mu daje pristup kao bilo kom korisniku u domenu, uključujući nepostojeće naloge, bez ikakve dalje interakcije sa domain kontrolerom. Silver Ticket je uža varijanta istog principa, ograničena na jedan konkretan servis, i teže se otkriva jer često uopšte ne prolazi kroz domain kontroler.

Šta treba uraditi

• Pratiti Event ID 4769 (zahtev za servisnu kartu) kod kojeg ne postoji odgovarajući prethodni Event ID 4768 (zahtev za TGT) na istom domain kontroleru — ovo je indikator da je TGT karta ubačena spolja, ne izdata legitimno
• Pratiti TGT karte čiji vek trajanja premašuje podešeni MaxTicketAge (tipično 10 sati) — forged karte se često prave sa neuobičajeno dugim ili neuobičajeno okruglim vekom trajanja
• Proveravati da li se domen i SID vrednosti u Kerberos kartama poklapaju sa stvarnim vrednostima domena — nepažljivo izrađene forged karte ponekad imaju neusklađene metapodatke
• Za Silver Ticket, pratiti na ciljnim serverima Event ID 4624 (Logon Type 3, Kerberos autentifikacija) kojem ne prethodi odgovarajući zahtev za servisnu kartu na domain kontroleru

Promene privilegovanih grupa i perzistencija

Nakon što napadač jednom uđe, sledeći korak je obično obezbeđivanje trajnog pristupa (perzistencija) — najčešće dodavanjem sopstvenog ili kompromitovanog naloga u privilegovanu grupu, ili izmenom kontrolne liste pristupa (ACL) na osetljivom objektu poput AdminSDHolder-a, čime izmena preživljava čak i standardno čišćenje članstva grupa.

Šta treba uraditi

• Pratiti Event ID 4728 i 4732 (dodavanje člana u globalnu, odnosno lokalnu privilegovanu grupu) za sve grupe iz Tier 0 opsega — Domain Admins, Enterprise Admins, Schema Admins
• Pratiti Event ID 5136 (izmena objekta u direktorijumu) filtriran na izmene nTSecurityDescriptor atributa AdminSDHolder objekta, domain root objekta i GPO kontejnera
• Postaviti oba tipa alarma (promena članstva i promena ACL-a) kao kritične, sa istim prioritetom odgovora — napadač koji izmeni ACL umesto članstva grupe upravo pokušava da izbegne standardnu proveru
• Kad se otkrije sumnjiva promena, posmatrati je na vremenskoj liniji zajedno sa eventualnim DCSync i Golden Ticket indikatorima — ove tri vrste događaja često dolaze zajedno, u istom incidentu

Praktičan pristup za manji tim

Za organizaciju koja nema dedikovan SOC ili puni SIEM, realan cilj nije da se pokrije svih nekoliko stotina mogućih Event ID-jeva, već da se izabere uzak, tačno definisan skup koji pokriva najveće rizike — DCSync, forged tikete, promene privilegovanih grupa i GPO promene. Microsoft Defender for Identity, tamo gde je dostupan, pokriva veliki deo ovih obrazaca kroz gotove detekcije, prilagođene semantici Kerberos i LDAP protokola, što znatno smanjuje potrebu da se ovakva pravila grade ručno.

Šta treba uraditi

• Ako punopravan SIEM nije realna opcija, definisati minimalan skup od desetak Event ID-jeva pokrivenih u ovom tekstu i obezbediti da se bar oni prosleđuju na centralnu lokaciju sa alarmiranjem
• Proveriti da su odgovarajuće napredne audit politike zaista uključene na svim domain kontrolerima — nedostatak jednog ključnog podešavanja (najčešće Audit Directory Service Access) čini deo detekcija potpuno nevidljivim, bez ikakvog upozorenja da nešto nedostaje
• Gde je dostupno, uvesti Defender for Identity ili sličan alat namenjen specifično AD pretnjama, umesto oslanjanja isključivo na generička SIEM pravila
• Periodično testirati da alarmi zaista rade — na primer kontrolisanim, najavljenim izvođenjem bezopasne varijante nekog obrasca u test okruženju — jer alarm koji nikad nije okinuo ne znači nužno da napada nije bilo, može značiti i da alarm ne radi

Ovim se zaokružuje osnovni ciklus AD hardening serije — od privilegovanog pristupa, preko GPO i delegacije, Kerberos rizika i same infrastrukture domain kontrolera, do monitoringa koji sve to drži pod nadzorom. Sledeći delovi serije mogu ići u dubinu na specifične teme poput AD Certificate Services (ESC1–ESC8) ranjivosti ili bezbednosti hibridnih okruženja sa Entra ID-jem, u zavisnosti od toga šta se pokaže najkorisnijim za dalje čitanje.