Use Alternate Authentication Material

Alternate authentication material never appears first. Credential access has to happen before it, whether that is LSASS dumping (T1003) for hashes, Kerberos ticket theft or forgery (T1558) for tickets, or token theft against a browser or cloud session. What T1550 buys the attacker is reach: a single compromised endpoint's credentials, replayed correctly, become access to every system that account can touch, which is why it sits at the hinge between initial compromise and full lateral movement (T1021, T1078).

MITRE's own procedure examples put this in concrete threat-actor terms. Wizard Spider, the ransomware operator behind Ryuk and Conti, used the Invoke-SMBExec PowerShell cmdlet with stolen password hashes to move laterally before detonation. APT41 used Mimikatz to enable lateral movement via captured hashes, and APT29 has run Kerberos ticket attacks (pass the ticket) to move through compromised environments. The Night Dragon campaign used dedicated pass-the-hash tooling to obtain authenticated access across a victim network. None of these needed a cracked password at any point.

Not every KeyLength-0 NTLM logon or LogonType 9 session is an attack. Backup software, some monitoring agents, and legacy applications authenticate over NTLM without an interactive session preceding them, and they will show the same zero key length. Administrators legitimately use runas /netonly to run tools under alternate credentials without a full interactive logon, which produces a LogonType 9 seclogo event that looks identical to overpass-the-hash on paper.

The separation is context, not the raw event. Build an allow-list of the service accounts, backup jobs, and known runas /netonly workflows in your environment, then treat KeyLength-0 NTLM and seclogo NewCredentials logons from anything outside that list as high priority, especially when the source process is PowerShell, cmd.exe, or an unsigned binary rather than a known admin tool. A hash-replay logon that lands on multiple hosts within minutes, or that follows a credential-dumping alert on the same source, is the combination that separates a real pass-the-hash chain from routine backup traffic.

When this fires, first check whether the account and source process match a documented backup job or a legitimate runas /netonly workflow. If they do not, look at scope: how many hosts has this account authenticated to in the last hour, and does the pattern fan out the way lateral-movement tooling does rather than the way a human clicks through systems. Pull the source workstation's recent history for a credential-dumping alert (LSASS access, Mimikatz-pattern process activity) in the window before the suspicious logon, since pass-the-hash almost never happens without a theft event immediately upstream.

A confirmed hash or ticket replay from an unexplained source is a lateral-movement event in progress, not a maintenance false positive, and it should be escalated on that basis. Reset the credentials involved (the password change invalidates a stolen hash; a Kerberos ticket needs the krbtgt or account secret rotated, which is a bigger operation, so scope that decision to your IR lead). Isolate the source and destination hosts rather than only one of them, since the attacker's next hop is likely already staged, and preserve both for forensics instead of reimaging immediately, because the process that performed the replay is your best lead on how the original material was stolen.