What is Brute Force Attack?

Every variant keeps asking a login page whether a password is right. What changes is where the guesses come from and how they are spread across accounts, and that is what decides which pattern you look for in the logs.

Types of brute force attacks

MITRE ATT&CK v20 files all of it under T1110 Brute Force, in the Credential Access tactic, with four sub-techniques: password guessing (.001), password cracking (.002), password spraying (.003) and credential stuffing (.004).

The split that matters to a SOC is online versus offline. Online guessing hits a live service (RDP, SSH, a VPN portal, Outlook on the web, an Entra ID sign-in) and every miss is written to a log you can collect. Offline cracking runs against hashes the attacker already stole, from a copy of NTDS.dit or a dump of LSASS memory, with hashcat or John the Ripper on their own hardware. No lockout applies and you see nothing until the cracked password gets used. To catch cracking, hunt for the hash theft that comes before it.

One wrong password, three different logs

Where a failed guess gets recorded depends on which protocol checked it. Take a wrong password for the domain user j.ortega:

Lockout changes the codes again. Once the account crosses its threshold, 4625 carries Status 0xC0000234 (account locked out), the domain controller writes 4740 with the Caller Computer Name the failures came from, and Entra ID returns 50053. Microsoft uses that one code for two different things: an account locked after too many bad passwords, and a sign-in blocked because the IP address has a record of malicious activity. A username that does not exist in Active Directory never reaches 4771 at all; the domain controller logs it as 4768 with result code 0x6.

No single code is an alert. Microsoft tells you to expect some 50126 errors because people mistype passwords, and its 4625 guidance flags 0xC0000064 as a possible sign of user enumeration "especially if you get several of these events in a row". The signal is in the ratios: failures per account, accounts per source, the share of usernames that do not exist, and whether a run of failures ends in a success. Keep the lockout threshold in mind as well. Windows security baselines suggest 10 invalid attempts, so eight or nine failures per account per window is exactly where a careful attacker parks.

A real campaign: the GRU's Kubernetes cluster

In July 2021 NSA, CISA, the FBI and the UK's NCSC published a joint advisory on GRU military unit 26165 (85th GTsSS, which vendors track as APT28, Fancy Bear or Strontium). From mid-2019 through early 2021 the unit used a Kubernetes cluster to run distributed brute force and password spraying against hundreds of government and private organizations. Much of it was aimed at organizations on Microsoft Office 365, but the cluster also hit on-premises mail servers over HTTP(S), IMAP(S), POP3 and NTLM, and routed its attempts through Tor and commercial VPN services. Valid credentials were then paired with two Exchange vulnerabilities, CVE-2020-0688 and CVE-2020-17144, which require an authenticated user, for remote code execution.

Microsoft had reported on the same actor's tooling in September 2020, in a post the advisory cites. In brute-force mode a targeted account typically saw over 300 authentication attempts per hour for several hours or days. In spray mode it saw about four per hour for days or weeks, nearly every attempt from a different IP, drawn from a pool of roughly 1,100 addresses, most of them Tor.

The advisory itself warns that the indicators can be changed easily, so blocking its list of node IPs was never going to be the control. And a rule that counts failures per source IP misses spray mode entirely, because each IP sends a single attempt. Count per account and per user agent too: the advisory lists truncated User-Agent strings, such as one ending in Chrome/70., as detection opportunities.

A simulated case

Simulated example generated by SOCSimulator Research. Users, hosts, IP addresses and times are invented; event IDs, field names and codes are Microsoft's.

TimeGenerated  Log             Account          Source IP        Code
03:10:04       4625 on TS01    administrator    203.0.113.77     SubStatus 0xc000006a
03:10:05       4625 on TS01    admin            203.0.113.77     SubStatus 0xc0000064
03:10:07       4625 on TS01    backup           203.0.113.77     SubStatus 0xc0000064
03:10:08       4625 on TS01    administrator    203.0.113.77     SubStatus 0xc000006a
               ... 212 more 4625 rows from 203.0.113.77 by 03:24
03:12:40       SigninLogs      j.ortega@...     203.0.113.77     ResultType 50126
03:12:58       SigninLogs      m.silva@...      203.0.113.77     ResultType 50126
03:13:15       SigninLogs      a.keane@...      203.0.113.77     ResultType 50126
               ... 38 more 50126 rows, one per user, by 03:29
03:31:22       SigninLogs      m.silva@...      203.0.113.77     ResultType 0

Read the reasons before the counts. Half of the 4625 rows say 0xc0000064: the tool is trying names that do not exist here (admin, backup), so this is a generic wordlist aimed at an exposed RDP host, not someone who knows your directory. The Entra ID rows are different. They try 41 real users once each from the same address, which is spraying, and that is the half that worked: m.silva signs in with ResultType 0 from the same IP 18 minutes after her single failure. Treat it as a compromised account. Revoke her sessions, reset the password, check AuthenticationRequirement on the success to see whether MFA was ever asked for (see MFA), and close RDP on TS01 to the internet. The brute force investigation playbook walks the full triage.

Detecting it with KQL

The first query puts the three logs into one shape and scores each source address over the last hour.

// Failed password checks from 4625, 4771 and Entra ID, scored per source IP
let window = 1h;
let ntlm = SecurityEvent
| where TimeGenerated > ago(window) and EventID == 4625
| extend Reason = case(SubStatus =~ "0xc000006a", "bad password",
                       SubStatus =~ "0xc0000064", "no such user",
                       Status =~ "0xc0000234", "locked out", "other")
| project TimeGenerated, Log = "4625", User = tolower(TargetUserName), IP = IpAddress, Reason;
let kerberos = SecurityEvent
| where TimeGenerated > ago(window) and EventID == 4771 and Status =~ "0x18"
| project TimeGenerated, Log = "4771", User = tolower(TargetUserName),
    IP = replace_string(IpAddress, "::ffff:", ""), Reason = "bad password";
let entra = SigninLogs
| where TimeGenerated > ago(window) and ResultType in ("50126", "50053")
| project TimeGenerated, Log = "Entra", User = tolower(tostring(split(UserPrincipalName, "@")[0])),
    IP = IPAddress, Reason = iff(ResultType == "50126", "bad password", "locked or IP blocked");
union ntlm, kerberos, entra
| summarize Attempts = count(), Accounts = dcount(User), Logs = make_set(Log),
    Reasons = make_set(Reason), First = min(TimeGenerated), Last = max(TimeGenerated) by IP
| extend PerAccount = round(1.0 * Attempts / Accounts, 1)
| where Attempts >= 20
| order by Attempts desc

A high PerAccount with one to three accounts is classic guessing against a target. A PerAccount near 1 across dozens of accounts is spraying. "no such user" dominating Reasons points to a generic list or stuffing. The second query checks what decides severity, whether any source that failed at volume also got in.

// Sources with 10+ Entra ID password failures in the last hour that also signed in
let window = 1h;
let noisy = SigninLogs
| where TimeGenerated > ago(window) and ResultType == "50126"
| summarize Failures = count(), Accounts = dcount(UserPrincipalName),
    FirstFail = min(TimeGenerated) by IPAddress
| where Failures >= 10;
SigninLogs
| where TimeGenerated > ago(window) and ResultType == "0"
| join kind=inner noisy on IPAddress
| where TimeGenerated > FirstFail
| project TimeGenerated, UserPrincipalName, IPAddress, Failures, Accounts,
    AuthenticationRequirement, AppDisplayName

Both queries follow Microsoft's documented SecurityEvent and SigninLogs schemas (EventID is an integer; Status, SubStatus and ResultType are strings) and have not been run against a live workspace by SOCSimulator. Set the thresholds from your own baseline: a VPN concentrator or a shared NAT address can produce 20 honest failures in an hour.

Prevention

The joint advisory's mitigations line up with what the logs show:

• MFA with strong factors. A guessed password stops being enough on its own.
• Lockout and time-outs that grow with each failure. They slow guessing down to the point where it stops paying. Microsoft notes that a threshold of 10 cuts help-desk calls but does not prevent a denial-of-service attack, where someone locks accounts out on purpose.
• Banned-password checks at password change, so Summer2026! never gets set.
• No legacy protocols that cannot do MFA. The GRU cluster guessed over IMAP(S) and POP3 as well as HTTPS, and the advisory says to disable protocols that use weak authentication or do not support MFA.
• Deny Tor and commercial VPN exits to mail portals and remote access where that traffic is not normal for your users.