Evidence of UnPAC the Hash usually appears in Active Directory and Kerberos-related logs, especially where a user authenticates with Kerberos and then a subsequent credential or ticket-related action follows. Look for unusual ticket activity, lateral movement from the same account, and hosts that should not be requesting Kerberos material. Correlate authentication, host, and directory events rather than relying on a single log source.
What logs usually prove UnPAC the Hash activity?
The strongest evidence is rarely a single event. You usually need to correlate Kerberos authentication, ticket issuance, and directory activity to see the pattern: a valid Kerberos logon, followed by suspicious ticket-related behavior from the same principal or host, then movement that should not normally occur. That is why the Kerberos Security Guide is useful context for understanding the ticket flow you are trying to reconstruct.
In practice, focus on logs that can show the full sequence. Kerberos service ticket requests, authentication events, and directory-side records are the most useful starting points because unpac the hash abuse depends on legitimate Kerberos behavior being turned into access or ticket material that should not have been exposed.
Which event patterns matter most in Active Directory?
Look for unusual combinations rather than a single indicator. A normal Kerberos login on its own is not enough; the signal comes from follow-on activity such as repeated ticket requests, access attempts from an unexpected system, or the same user context appearing across hosts in a way that suggests lateral movement. If a host that should not be participating in Kerberos material suddenly does so, that is a strong investigative lead.
Directory and host logs help you tie the user, source system, and downstream action together. That correlation is important because UnPAC the Hash often blends into otherwise ordinary authentication telemetry until you compare timing, source host, and the sequence of subsequent access.
Host telemetry can also show the operational consequence, not just the authentication step. If the same account is used to access multiple systems shortly after the Kerberos activity, especially where that account should have a narrow scope, treat that as a sign the initial credential or ticket action may have been abused rather than merely observed.
How should you investigate and validate the evidence?
Start by anchoring the timeline around the first Kerberos authentication, then compare it with ticket-related events, host logons, and directory changes. The goal is to answer three questions: who authenticated, from where, and what new access or ticket behavior followed. That sequence is more reliable than searching for one magic event ID.
Correlate across sources instead of relying on a single log type. Authentication logs show the entry point, directory records show whether the account or ticket state changed in a way that matters, and endpoint or server logs show whether the resulting access was actually used. If those three layers do not line up, the apparent signal may just be normal Kerberos traffic.
When the evidence is ambiguous, compare it against the expected behavior of the account and the host. The key investigative question is not simply whether Kerberos was used, but whether the use of Kerberos material was consistent with the system’s role, the user’s privileges, and the normal trust path for that environment.
Risk and Threat Considerations
UnPAC the Hash matters because it can turn routine Kerberos activity into a path for unauthorized access and lateral movement. The main risk is not the initial authentication event itself, but the ability to abuse the resulting ticket or credential material before defenders recognise the sequence.
Failure mechanism: Attackers or intruders blend into expected Kerberos flows, then leverage the derived access or ticket state to move laterally, request additional material, or access systems the original context should not reach.
Impact: Security teams may miss the compromise if they inspect only one log source, allowing the same account or host to be reused for broader access, persistence, or deeper directory compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1550 — Use Alternate Authentication Material | UnPAC the Hash is a credential-use technique that fits alternate authentication material abuse. |
| Recommendation — Map the activity to credential abuse and hunt for follow-on lateral movement and privilege escalation. | ||
| NIST CSF 2.0 | DE.CM-01 — Anomalies and events are monitored to find cybersecurity events | The answer depends on correlating anomalous Kerberos, directory, and host events. |
| Recommendation — Monitor for unusual Kerberos and host-event sequences that break the normal authentication pattern. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Investigating UnPAC the Hash requires correlated review of audit records across systems. |
| IA-5 — Authenticator Management | Kerberos ticket and credential material are central to the abuse path described. | |
| Recommendation — Correlate audit records across domain controllers and hosts to identify suspicious ticket activity. Review and rotate exposed authenticators, tickets, and related credential material when abuse is suspected. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The question is specifically about which logs reveal the activity. |
| Recommendation — Centralise and retain Kerberos, directory, and endpoint logs for cross-source correlation. | ||
Practitioner Guidance
What to prioritise: Build the investigation around correlation, not event hunting. If you only have one source, start with Kerberos and directory logs, then add host telemetry to confirm whether the activity translated into real access.
What to verify: Confirm whether the source host, destination host, and account all make sense together. A valid Kerberos event can still be suspicious if it is followed by access from an unexpected system or by repeated ticket-related activity that does not fit the account’s normal use.
Practitioner takeaway: The best indicator is the sequence, not the single event, so treat UnPAC the Hash as a correlation problem across authentication, directory, and host evidence.