T1550.002

Use Alternate Authentication Material: Pass the Hash

Windows

What it is

In many Windows environments, a password never has to be typed to authenticate: the system can authenticate using the password's hash directly, a mechanism built into how Windows network authentication has historically worked. This is what makes pass the hash possible.

An attacker who has obtained a valid password hash, without ever knowing the actual password, can use that hash to authenticate to other systems exactly as if they had the real credential. The password itself is never needed at any point.

How adversaries use it

Having harvested a password hash from one compromised host, typically through credential dumping, an attacker presents that hash directly to another system's authentication process. If the account has access there, the attacker is in, without ever cracking or even knowing the underlying password.

This is a favorite lateral movement technique precisely because it skips the hardest part of a real credential-theft attack: guessing or cracking a password. A single reused local administrator hash across many machines, a common configuration mistake, can let one initial compromise cascade across an entire fleet.

Detect it in Elastic

Data source: Windows authentication event logs (logon events) on the target system

Key fields

The canonical signal is a network logon (a specific Windows logon type used for authentication across the network) using NTLM specifically, rather than Kerberos, especially from an account and source pairing that doesn't match how that account normally authenticates. Key fields: the logon type, the authentication package used, the source and target accounts and hosts, and the logon's success or failure.

One general, portable principle worth stating plainly: in a well-run modern Active Directory environment, Kerberos handles the overwhelming majority of everyday network authentication. NTLM usage, especially at any real volume, is often a strong anomaly signal on its own, not because NTLM never has a legitimate purpose, but because it's supposed to be rare rather than routine.

Example event

{
  "host": {
    "name": "example-target"
  },
  "user": {
    "name": "svc_backup"
  },
  "event": {
    "action": "logged-in",
    "category": "authentication"
  },
  "source": {
    "ip": "10.0.0.101"
  },
  "winlog": {
    "logon": {
      "type": "Network"
    },
    "event_data": {
      "AuthenticationPackageName": "NTLM"
    }
  }
}

Prebuilt Elastic rule: Potential Pass-the-Hash (PtH) Attempt

Hunt guidance

Filter authentication events for network logons using NTLM, then compare against each account's own established pattern rather than a blanket rule, since some environments have a small number of systems that legitimately still require it. An account authenticating this way for the first time, especially one that normally uses Kerberos exclusively, is the signal worth chasing.

Correlate with source: a logon type consistent with pass the hash (no interactive session, no supporting evidence of a typed password) from a host the account doesn't normally use is a stronger combined signal than the authentication package alone.

Ruling out legitimate activity

A handful of legitimate scenarios still rely on NTLM: certain older applications, some scheduled automation, and specific interoperability cases. Environments vary, so a rule that fires on any NTLM use at all can be noisy in an unmodernized network.

The distinguishing signal is the account and host pairing against its own established baseline. A known legacy service account authenticating via NTLM to the one system it's always used is routine; the same authentication package suddenly appearing on an account or host pair that has never used it before is not.

References

Practice it

1 scenario in this catalog covers T1550.002. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →