Skip to content
Sign In
Learn

T1110.001

Password Guessing

What it is

Password guessing is brute force aimed at a single account. An attacker who knows an account name tries password after password against it, from lists of common choices, seasonal patterns and words tied to the organization, until one works or the account locks. It is a sub-technique of Brute Force.

It is the opposite shape to password spraying: deep rather than wide. A spray tries one password across many accounts to stay under each account's lockout threshold; guessing tries many passwords against one account, so it succeeds only where that account has a weak password and lockout is off, set high, or resets faster than the attacker guesses. Each attempt is an ordinary sign-in request that the system answers, so no single attempt looks wrong. The signal is how many there are, against which account, and what happens next.

How adversaries use it

The attacker needs only an account name and something that answers sign-in requests: a remote desktop or SSH service, a file share, a VPN or webmail portal, or a domain controller reached from a host they already control. Account names are easy to learn, and the most valuable ones, such as built-in administrator accounts and service accounts, are often the easiest.

Tools make the attempts automatically and stop at the first success. A careful attacker paces them to stay under the lockout policy, which stretches the failures over minutes or hours instead of seconds, or rotates the source address so the attempts look unrelated. Whatever the pace, the run ends the same way: the failures stop, and the account signs in.

Detect it in Elastic

Data source: Windows Security event log: failed logons (Event 4625) against one account, the logon that follows (4624) and account lockouts (4740), plus the domain controller's credential checks (4776 and 4771). On Linux, the system authentication log.

Key fields

event.code: 4625 for each failed logon, 4624 for a successful one, 4740 when an account locks out user.name: the account being tried, also kept as winlog.event_data.TargetUserName user.target.name: on a 4740, the account that locked out source.ip: where the attempts came from winlog.event_data.SubStatus: why a logon failed; 0xc000006a is a wrong password for an account that exists, 0xc0000064 an account that does not winlog.logon.type: how the account tried to sign in host.name, @timestamp

Example event

{
  "host": {
    "name": "ws-529.corp.example"
  },
  "user": {
    "name": "m.castell"
  },
  "event": {
    "code": "4625",
    "action": "logon-failed"
  },
  "source": {
    "ip": "203.0.113.44"
  },
  "winlog": {
    "event_data": {
      "Status": "0xc000006d",
      "SubStatus": "0xc000006a"
    }
  },
  "@timestamp": "2026-06-16T08:41:27.115Z"
}

Prebuilt Elastic rule: Multiple Logon Failure Followed by Logon Success

Hunt guidance

Password guessing concentrates on one account, so group by the account first. Filter failed logons with event.code: "4625", count them per user.name over short windows, and look for one account collecting far more failures than any other, most of them wrong-password failures (winlog.event_data.SubStatus: "0xc000006a") rather than unknown-account ones. Then look at where they came from: one source address, or a handful, is the usual picture.

The finding is what follows the run. Look for a 4624 for the same account soon after the last failure, and compare its source.ip with the failures'. A run that ends in lockouts (4740) and no success is an attempt; a run that ends in a success means the password was found. On domain controllers the same shape appears in 4776 and 4771 events for domain accounts, and on Linux as repeated failed SSH password logins for one user followed by an accepted one.

The prebuilt rule named on this page needs the failures and the success to come from one source address within seconds of each other, so guessing that is paced out or spread across addresses will not trigger it; for that, this hunt is the detection.

Ruling out legitimate activity

Failed logons against one account are common and mostly benign: a user who mistypes a password, a phone or mapped drive still holding an old password after a change, or a service or automated job still running with an expired credential. These come from devices or servers the account normally uses, tend to repeat steadily rather than in a burst, and rarely end in a success from a new source.

Check the source first: is it a device or server that account normally uses? Then the failure reasons and the timing. Steady failures over days point to a stale credential; a fast run of wrong-password failures from a source the account has never used, ending in a success, does not.

Telemetry needed

The log events that help detect this technique, from the Telemetry reference: which log source to collect, which event in it, and how to enable each one.

References

Practice it

1 scenario in this catalog covers T1110.001. We don't name it, because identifying the technique is part of what a scenario grades. Explore the Range →