Overpass-the-Hash: Active Directory Attacks

How the Attack Works

Kerberos pre-authentication proves knowledge of the account's key, not of its password. The client encrypts a timestamp with its RC4 key, which is the NT hash, or with an AES key. Whoever holds either can send an AS request that the DC accepts as the user's own, and receives a genuine TGT. From then on everything is ordinary Kerberos, so controls that only restrict or watch NTLM do not see it.

Read first Password Hashes and Kerberos Keys, Kerberos Keys and Encryption Types, AS Request and Pre-Authentication

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

A foothold on srv-app-01, the web app server, holds dana's NT hash and asks dc-01 for her TGT.Step through it

srv-app-01 Foothold

dana's key

dc-01 Domain controller

dana's key
krbtgt key
srv-fin-01 key

srv-fin-01 File server

srv-fin-01 key

Step 1 of 4, Key in a New Session, on srv-app-01
Step 2 of 4, AS Request, srv-app-01 to dc-01
Step 3 of 4, Genuine TGT, dc-01 to srv-app-01
Step 4 of 4, Kerberos as dana, srv-app-01 to srv-fin-01

Step 1 of 4: Key in a New Session
On srv-app-01 Foothold
On srv-app-01 a new logon session is given dana's NT hash, or an AES key of hers, in place of a password.
Logged
- 4624 An account was successfully logged on
  On srv-app-01, in the Security log
  Logon Type 9 (NewCredentials), Network Account Name dana
  Reading Logon Events explains how to read it.
- 4648 A logon was attempted using explicit credentials
  On srv-app-01, in the Security log
  Explicit credentials for dana
  Explicit Credentials on the Source Machine explains how to read it.
What Defenders See
The Security log on srv-app-01 shows event 4624 with Logon Type 9 and Network Account Name dana. It also shows event 4648.
Step 2 of 4: AS Request
srv-app-01 Foothold to dc-01 Domain controller
Request for a TGT as dana KRB_AS_REQ Kerberos, port 88
srv-app-01 asks dc-01 for a TGT for dana, its timestamp encrypted with the RC4 key, which is her NT hash.
What Travels in This Step
- dana's name and realm cname
  dana and CORP.EXAMPLE
  In the clear Anyone who sees the traffic can read it.
- Encryption types offered etype
  Only RC4, the one type an NT hash can serve, where Windows would list AES first
  In the clear Anyone who sees the traffic can read it.
- Pre-authentication PA-ENC-TIMESTAMP
  The current time
  Encrypted with the RC4 key (dana's NT hash) Only srv-app-01 and dc-01 can open it.
Logged
- 4768 A Kerberos authentication ticket (TGT) was requested
  On dc-01, in the Security log
  Pre-Authentication EncryptionType and Session Encryption Type 0x17, Client Address ::ffff:192.0.2.25
  AS Reply: The TGT explains how to read it.
What Defenders See
The Security log on dc-01 shows event 4768 for dana from 192.0.2.25 with Pre-Authentication EncryptionType 0x17, though her Available Keys include AES.
Hooks into Kerberos AS Request
Step 3 of 4: Genuine TGT
dc-01 Domain controller to srv-app-01 Foothold
Reply with a real TGT KRB_AS_REP Kerberos, port 88
dc-01 accepts the timestamp as dana's and returns a real TGT and its session key.
What Travels in This Step
- The TGT
  dana's name and groups, as for any sign-in of hers
  Encrypted with the krbtgt AES key Only dc-01 can open it.
- srv-app-01's part
  The TGT session key and the times
  Encrypted with the RC4 key (dana's NT hash) Only srv-app-01 and dc-01 can open it.
Keys and Tickets
- srv-app-01 now holds TGT (new at this step) TGT session key (new at this step)
What Defenders See
The reply adds nothing to the Security log on dc-01 beyond the event 4768 above. Defender for Identity weighs how the request was built.
Step 4 of 4: Kerberos as dana
srv-app-01 Foothold to srv-fin-01 File server
Service ticket shown to the server KRB_AP_REQ SMB, port 445
srv-app-01 presents a service ticket for dana, got from dc-01 with that TGT, and srv-fin-01 accepts it like any Kerberos sign-in.
What Travels in This Step
- The service ticket
  dana's name and groups, for srv-fin-01
  Encrypted with srv-fin-01's AES key Only dc-01 and srv-fin-01 can open it.
- An authenticator
  dana's name and the time
  Encrypted with the service session key Only srv-app-01 and srv-fin-01 can open it.
Keys and Tickets
- srv-app-01 now holds service ticket (new at this step) service session key (new at this step)
- srv-fin-01 now holds service session key (new at this step)
What Defenders See
The Security log on srv-fin-01 shows event 4624 with Logon Type 3 and Kerberos for dana from 192.0.2.25, not from ws-017. In the Security log on dc-01, event 4769 for the ticket shows the same address.

Needs First

What the attacker must already hold for this attack to be possible.

An NT Hash or An AES KeyThe account's NT hash, used as its RC4 key, or one of its AES keys.

Comes From

Gives the Attacker

What running it hands the attacker to use next.

A TGTA genuine TGT for the account, and with it service tickets to anything it may use.
Access as Another AccountAccess as that account over Kerberos, even where NTLM is blocked.

Leads To

TGT: Pass-the-Ticket

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and Log	Written On	Look For	Switch It On
4768 `A Kerberos authentication ticket (TGT) was requested` (opens in a new tab) Security log	Domain controllers	Pre-Authentication EncryptionType 0x17 for an account whose Available Keys include AES, from a machine it does not normally use.AS Reply: The TGT explains how to read it.	Audit Kerberos Authentication Service
4624 `An account was successfully logged on` (opens in a new tab) Security log	The computer that was logged on to	On the source, Logon Type 9 with that account as Network Account Name, a session given other credentials for network use.Reading Logon Events explains how to read it.	Audit Logon
4648 `A logon was attempted using explicit credentials` (opens in a new tab) Security log	The computer the credentials were used from	On the source, explicit credentials for the account whose key was used, beside that type 9 logon.Explicit Credentials on the Source Machine explains how to read it.	Audit Logon
4769 `A Kerberos service ticket was requested` (opens in a new tab) Security log	Domain controllers	The account's service tickets asked for from the same unusual address that got its TGT.TGS Reply: The Service Ticket explains how to read it.	Audit Kerberos Service Ticket Operations

What It Looks Like

One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.

4768 A Kerberos authentication ticket (TGT) was requested

In the Security log on dc-01, 22 Oct 2026, 13:05:27 UTC

A TGT for dana asked for from srv-app-01, its timestamp encrypted with her NT hash.

The account the TGT was issued to.
As Windows writes it: Account Name dana
srv-app-01, a machine dana never signs in at, while her TGTs come from ws-017.
As Windows writes it: Client Address ::ffff:192.0.2.25
The DC accepted the timestamp, so whoever sent it held her key.
As Windows writes it: Result Code 0x0
RC4, so the timestamp was encrypted with her NT hash, not the AES key her machine would use.
As Windows writes it: Pre-Authentication EncryptionType 0x17
She has AES keys, so a Windows client of hers would have used them.
As Windows writes it: Available Keys AES-SHA1, RC4
The session key is RC4 too, because RC4 was all the request offered.
As Windows writes it: Session Encryption Type 0x17
AES for the TGT itself, sealed with the krbtgt key. Since January 2025 this field no longer shows the session key type.
As Windows writes it: Ticket Encryption Type 0x12

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

A stolen AES key makes a request that matches the user's own, so no RC4 field gives it away, only the machine it came from.
DCs without the January 2025 update show RC4 in Ticket Encryption Type instead, and lack the fields that show an account holds AES keys.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Sees It DirectlyAlertInfo

Needs Defender for Identity sensors on every DC. The forced encryption type alert learns for a month first. An alert shows the request, not how the key was stolen, so look for the theft on the source machine.

KQLDefender XDR, Advanced hunting

// Defender for Identity overpass-the-hash alerts, and its suspicious authentication alertAlertInfo| where Timestamp > ago(30d)| where Title contains "overpass-the-hash" or Title contains "over-pass-the-hash" or Title == "Suspicious authentication attempt"| project Timestamp, AlertId, Title, Severity, DetectionSource, AttackTechniques| order by Timestamp desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Protected Users group (opens in a new tab)
Add privileged accounts to Protected Users, so they cannot use RC4 in pre-authentication and their NT hash alone gets no TGT.
AES only for Kerberos (opens in a new tab)
Retire RC4 for Kerberos, so an NT hash is no longer a Kerberos key anywhere.
Credential Guard (opens in a new tab)
Turn on Credential Guard, so the keys sit outside LSASS and fewer are there to steal.
Check it on a machine: Credential Guard (LsaCfgFlags)
Tiered administration (opens in a new tab)
Keep admin keys off ordinary machines, where they could be taken.

Attacks tied to this one that its needs and gives do not already name, such as another form of it or its reverse, each with how the two connect.

Pass-the-Hash
The same stolen hash, answering NTLM directly.

How the Attack Works

How It Plays Out

Step 1 of 4: Key in a New Session

Step 2 of 4: AS Request

Step 3 of 4: Genuine TGT

Step 4 of 4: Kerberos as dana