Windows Kerberos Pre-Auth Failed (4771) (Svenska)

Finns det ett enkelt sätt att skilja 4771 händelser från ett verkligt attackperspektiv jämfört med någon som har en föråldrad session med en gammalt lösenord?

Om du inte får loggar från alla slutpunkter och förlitar dig på domänkontrollanter måste du stänga av 4771 och 4625 för fel, där 4771 är Kerberos-händelserna från domänanslutna datorer till DC: erna.

Det är trevligt att ha synlighet över slutpunkterna utan att få loggar från allt annat än för dessa 4771-händelser är de flesta av varningarna jag ser bara föråldrade sessioner och icke-säkerhetshändelser. Jag ser inte någon underkod eller föremål att stänga av för gammalt / gammalt lösenord kontra riktigt angrepp.

Svar

För det mesta är dessa händelser bullriga i en stor användarmiljö med en lösenordsändringspolicy. Oftast händer detta när ett kontos lösenord har löpt ut och det är knutet till någon applikation / tjänst / uppgift som fortsätter att försöka logga in igen och igen.

Om du har en SIEM- eller logghanteringslösning kan du skapa en regel för att ignorera 4771-händelser för kontots lösenord har nyligen återställts 4723/4724 (säg under de senaste 24 timmarna).

Kommentarer

  • Men om det inte finns någon fast tidsgräns på servrarna, ignoreras 4771 händelser från X-användare en en 4723/4724-händelse utlöses inte ' t hjälp. Det skulle bara försena varningarna i 24 timmar. Vilket jag förstår, det borde finnas en tvångsanslutning men bara spela djävulen ' s advokat .
  • ah leta sedan efter 0x18-kod i händelse 4771. 0x18 i anger ett dåligt lösenord. Om du mer 0x18 på kort tid kan det vara en attack. Några fler händelser att övervaka förklaras i den här artikeln trimarcsecurity.com/single-post/2018/05/06/…
  • Letar du efter 0x18 hjälper inte ' mig alls. 0x18 betyder dåligt lösenord som kan vara en legitim attack eller någon har precis ändrat sitt lösenord vilket gör deras inaktuella sessioner nu till ett " dåligt lösenord ".

Svar

Jag slutade ge upp 4771 och 4625 händelser. I stället fokuserar jag bara på konto-lockout-händelse-ID och gör sedan korrelationsregler baserat på X-lockout under Y-timmar för att bestämma brute force.

Detta har varit mycket renare eftersom inte alla 4771 ”s verkligen lockout-konton och det minskar drastiskt falska positiva effekter.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *