Brute Force

Brute force is the most direct technique on the entire ATT&CK matrix: an attacker with no valid credentials tries to get some anyway, by attempting logon after logon until one works. There's no exploit, no vulnerability, nothing clever. It works purely on volume, against accounts protected by weak, common, or reused passwords, or against systems with no lockout policy to stop repeated attempts.

This covers a family of related approaches. Password guessing tries many passwords against one account. Password spraying flips that around, trying one or two common passwords against many accounts at once, specifically to avoid triggering a single account's lockout threshold. Credential stuffing tries username/password pairs already leaked from some other breach, betting on password reuse. All of them produce the same basic evidence: a cluster of failed authentication attempts, often followed by exactly one that succeeds.

This is usually one of the first things an attacker tries once they have a target account name or a list of them, often obtained separately through reconnaissance or a prior breach. It requires no special access and no foothold on the target system, just network reachability to whatever's doing the authenticating, a login page, an RDP or SSH listener, an API.

The tell that separates a real attack from routine failed-login noise is the pattern: real users mistype a password once, maybe twice, then either succeed or give up and reset it. An attacker's attempts are faster, more numerous, and often stop the instant one of them actually works, followed immediately by whatever the attacker came for.

Data source: Windows Security event log: repeated failed network logons (Event 4625) with sub-status and source address, plus the domain controller's credential checks (4776)

{
  "host": {
    "name": "WKSTN01"
  },
  "event": {
    "code": "4625",
    "action": "logon-failed"
  },
  "source": {
    "ip": "203.0.113.44"
  },
  "winlog": {
    "event_data": {
      "Status": "0xC000006A",
      "TargetUserName": "jdoe"
    }
  }
}

Prebuilt Elastic rule: Multiple Logon Failure Followed by Logon Success

The pattern is a shape, not a single event: a burst of 4625s from one source, targeting one or several accounts, in a short window, immediately followed by a 4624 from that same source. Neither the failures alone nor the single success alone is the signal, it's the sequence and the timing between them.

Hunting manually: filter event.code: "4625" and group by source.ip and winlog.event_data.TargetUserName over a short window (a few minutes), looking for a source with an unusually high failure count. Then check whether that same source.ip produced a 4624 shortly after, which turns a noisy-but-inconclusive failure spike into a confirmed compromise.

A single user mistyping their password a few times, or a scheduled task or service account running with an expired credential, both produce failed logons that look superficially similar to the start of a brute-force pattern.

The distinguishing signal is volume, targeting, and source: a handful of failures against one account from the user's own usual workstation is routine. A much larger burst, especially one targeting multiple different accounts from a single source, or coming from a source that account has never logged in from before, is what warrants escalation. A success immediately following the burst removes almost all ambiguity, since a genuine mistyping user does not typically follow ten failures with a success from the exact same source at the exact same moment, they usually pause, get locked out, or call the help desk first.

• MITRE ATT&CK T1110: Brute Force
• Elastic Security: Multiple Logon Failure Followed by Logon Success

2 scenarios in this catalog cover T1110. We don't name them — identifying the technique is part of what a scenario grades. Explore the dashboard →