Er der en nem måde at skelne 4771 begivenheder fra et rigtigt angrebsperspektiv i forhold til nogen, der har en forældet session med en gammel adgangskode?
Hvis du ikke får logfiler fra alle slutpunkter og stoler på domænecontrollere, skal du slå nøglen til 4771 og 4625 for fejl, hvor 4771 er Kerberos-begivenhederne fra domænet, der er tilsluttet computere til DCerne.
Det er rart at have synlighed over slutpunkterne uden at få logfiler fra alt, men for disse 4771 begivenheder er de fleste af de alarmer, jeg ser, bare uaktuelle sessioner og ikke-sikkerhedsbegivenheder. Jeg kan ikke se nogen underkode eller genstande, der skal nøgles til for gammel / gammel adgangskode vs. rigtigt angreb.
Svar
Det meste af tiden er disse hændelser støjende i et stort brugermiljø med en politik til ændring af adgangskode. Det meste af tiden sker dette, når en kontos adgangskode er udløbet, og den er bundet til en applikation / tjeneste / opgave, som fortsætter med at prøve login igen og igen.
Hvis du har en SIEM- eller loghåndteringsløsning, kan du oprette en regel for at ignorere 4771 begivenheder for kontoens adgangskode blev for nylig nulstillet 4723/4724 (siger i de sidste 24 timer).
Kommentarer
- Men hvis der ikke er nogen indstillet timeout på serverne, vil ignorering af 4771 begivenheder fra X-bruger en en 4723/4724 begivenhed udløses ville ikke være ' t hjælp. Det ville bare forsinke alarmerne i 24 timer. Som jeg forstår, skal der være en tvungen afbrydelse, men bare spille djævel ' s advokat .
- ah så se efter 0x18-kode i tilfælde 4771. 0x18 i angiver en dårlig adgangskode. Hvis du har mere 0x18 på kort tid, kan det være et angreb. Nogle flere begivenheder, der skal overvåges, forklares i denne artikel trimarcsecurity.com/single-post/2018/05/06/…
- På udkig efter 0x18 hjælper ' mig ikke. 0x18 betyder dårlig adgangskode, som kan være et legitimt angreb, eller nogen har lige ændret deres adgangskode, hvilket gør deres forældede sessioner nu til en " dårlig adgangskode ".
Svar
Jeg endte med at opgive 4771 og 4625 begivenheder. I stedet fokuserer jeg bare på konto-lockout-hændelses-idet og udfører derefter korrelationsregler baseret på X-lockouts i Y-timer for at bestemme brute force.
Dette har været meget renere, da ikke alle 4771erne virkelig lockout-konti, og det reduceres drastisk med falske positive.