Guided lab: forty failures, no lockouts, one success

Count attempts per account, not attempts in total.

A spray. Each account appears once per pass: forty accounts, one guess each, then a wait of about half an hour before the next pass. Brute force would be one account and many guesses.

The shape is chosen to defeat lockout. A policy of five bad attempts in thirty minutes never triggers when every account sees one attempt every thirty-three minutes. The three callers saw a warning because their own typo that morning, added to the operator's guesses, brought them close.

0x18 is the Kerberos code for a wrong password. Pre-authentication type 2 is the ordinary encrypted timestamp, so these are normal logon attempts that failed for the most ordinary reason.

Think about which machine actually checks a Kerberos password, and whether the server the operator eventually wants is involved at that stage at all.

In Kerberos the password is checked by the domain controller, when the client asks for a ticket-granting ticket. A wrong password fails there, as event 4771, before any member server has been contacted. No server ever saw a logon attempt, so no server wrote a 4625.

A failed-logon dashboard built only on 4625 from member servers is blind to the most common way passwords are guessed in a domain. The fix is to collect 4771 and 4768 from every domain controller and alert on one source address failing against many accounts.

A success looks different from a failure in the event ID as well as the code.

c.achterberg, on the third pass at 09:04:17: a 4768 with result 0x0 from the same client address that produced 120 failures. Two seconds later a service ticket for MARL-FS-02, and a second after that a network logon there.

Observed: a successful TGT request for c.achterberg from 10.59.10.218, then a type 3 logon to MARL-FS-02 from that address. Assessed, with high confidence: the operator guessed the password and used it. It is an assessment because the log cannot show who typed it. c.achterberg sitting at that workstation and logging on correctly at 09:04 would look identical, and the reason you do not believe that is the 120 failures around it, which is context, not proof.

A spray from inside means something came before the spray.

It tells you the operator already had a foothold. FIN-WS-153 was compromised before 07:58, and the spray is lateral movement, not initial access. The investigation that matters starts on that workstation, earlier that morning or before.

What the logs cannot tell you: which password was tried, which is never recorded, and whether the same guesses were made against anything that does not use your domain controllers: the VPN, the mail service, a cloud identity provider. If one password worked here, check whether c.achterberg used it anywhere else.