Is er een gemakkelijke manier om 4771 gebeurtenissen te onderscheiden vanuit een echt aanvalsperspectief versus iemand die een verouderde sessie heeft met een oud wachtwoord?
Als u geen logboeken van alle eindpunten ophaalt en op domeincontrollers vertrouwt, moet u 4771 en 4625 uitschakelen voor fouten, waarbij 4771 de Kerberos-gebeurtenissen zijn van de computers die bij het domein zijn aangesloten de DCs.
Het is prettig om zicht te hebben op de eindpunten zonder logboeken van alles te krijgen, maar voor deze 4771 gebeurtenissen zijn de meeste waarschuwingen die ik zie gewoon verouderde sessies en niet-beveiligingsgebeurtenissen. Ik zie geen subcode of item om van af te toetsen voor verouderd / oud wachtwoord versus echte aanval.
Antwoord
Meestal zijn deze gebeurtenissen lawaaierig in een grote gebruikersomgeving met een wachtwoordwijzigingsbeleid. Meestal gebeurt dit wanneer het wachtwoord van een account is verlopen en het is verbonden met een toepassing / service / taak die steeds opnieuw probeert in te loggen en opnieuw.
Als u een SIEM- of logboekbeheeroplossing heeft, kunt u een regel maken om 4771 gebeurtenissen te negeren, want het wachtwoord van het account is onlangs opnieuw ingesteld op 4723/4724 (bijvoorbeeld in de afgelopen 24 uur).
Reacties
- Maar als er geen ingestelde time-out is op de servers, dan negeert het negeren van 4771 gebeurtenissen van X gebruiker één, dan wordt een 4723/4724 gebeurtenis geactiveerd ' t helpt. Het zou de waarschuwingen gewoon 24 uur uitstellen. Wat ik begrijp, er zou een gedwongen verbreking moeten zijn, maar gewoon de duivel spelen ' s advocaat .
- ah dan op zoek naar code 0x18 in de gebeurtenis 4771. 0x18 i signaleert een verkeerd wachtwoord. Als je in korte tijd meer 0x18 gebruikt, kan het een aanval zijn. In dit artikel worden nog enkele te volgen gebeurtenissen uitgelegd trimarcsecurity.com/single-post/2018/05/06/…
- Zoeken naar 0x18 helpt ' me helemaal niet. 0x18 betekent een slecht wachtwoord, wat een legitieme aanval kan zijn of iemand heeft zojuist zijn wachtwoord gewijzigd, waardoor hun verouderde sessies nu een " slecht wachtwoord " zijn.
Antwoord
Uiteindelijk heb ik 4771 en 4625 evenementen opgegeven. In plaats daarvan concentreer ik me gewoon op de gebeurtenis-ID van de accountvergrendeling en voer ik vervolgens correlatieregels uit op basis van X-uitsluitingen in Y-uren om brute kracht te bepalen.
Dit is een stuk schoner geweest sinds niet alle 4771-bestanden echt accounts blokkeren en het aantal valse positieven drastisch verminderd.