UnPAC the Hash

What UnPAC the Hash Does

UnPAC the Hash is a Kerberos abuse technique that turns a successful logon into a source of usable credential material. It matters because the attacker is not cracking Kerberos from scratch, they are extracting value from the authentication flow itself.

The practical danger is that the technique can convert one authenticated foothold into material that helps with impersonation, access expansion, or movement to other systems. In Kerberos-heavy environments, that makes post-authentication compromise more valuable to an attacker than a simple password guess or one-off ticket theft.

Why This Technique Is Dangerous

Kerberos is designed to let users and services prove identity without repeatedly sending passwords, so anything that lets an attacker recover reusable secret material from that process is especially useful. Once an adversary can derive credentials from a Privilege Attribute Certificate, they may be able to extend access beyond the original session and reuse the material in other parts of the environment.

This is why ticket handling, authentication hardening, and privileged account protection matter even after initial sign-in succeeds. Techniques in the same family as ticket abuse often become more dangerous when environments still rely on legacy encryption choices, weak delegation controls, or broad trust relationships between services.

Kerberos Security Guide is the natural starting point for understanding how ticket-based attacks, PAC validation, delegation, and KRBTGT hygiene fit together.

How Organisations Expose Themselves

Exposure usually starts with broad Kerberos reach, insufficient monitoring, and assumptions that “successful authentication” means the identity is now safe. If an attacker already has code execution or a useful foothold, the remaining question is often whether they can extract ticket-derived material before detection or containment.

Asset inventory and authentication path mapping matter here because the technique is only useful where Kerberos is actively in play and where the attacker can reach a ticket-bearing context. Internet-exposed systems, overprivileged accounts, and service relationships that are too permissive increase the chances that recovered material can be reused for lateral movement.

Defenders should also review vendor guidance for Kerberos hardening, because operational details such as encryption policy, delegation settings, and logging visibility change how practical the abuse path is in a real environment.

Detection and Response After Abuse

Detection is strongest when defenders look for a sequence, not just a single event. A suspicious Kerberos logon followed by unusual ticket use, abnormal service access, or unexpected credential material being reused elsewhere can indicate that the initial authentication was converted into later abuse.

After suspected exploitation, responders should review authentication logs, service access patterns, and any signs that the attacker used the recovered material to pivot. If the abuse touched privileged accounts or long-lived trust relationships, the response may need to include credential rotation, ticket hygiene review, and broader compromise assessment rather than only blocking the original source host.

Post-incident review should also ask whether the environment allowed the attacker to turn one successful authentication into reusable access. If that is possible, the problem is not limited to one host, it is a trust and credential-handling weakness that can recur.

Good verification sources for this work include the vendor advisory for the affected Kerberos behavior and the CISA Known Exploited Vulnerabilities Catalog, where applicable, for authoritative exploitation tracking and remediation context.

Practitioner Guidance

What to watch for: Treat UnPAC the Hash as a post-authentication abuse problem, not just a password problem. The control focus should be on reducing the value of any single Kerberos session and on limiting how far recovered material can travel if an endpoint or privileged context is already compromised.

Governance implication: Kerberos hardening, privileged account hygiene, and ticket-related detection should be owned as part of identity and endpoint security, not left as an ad hoc server-team task. That ownership becomes especially important where legacy Kerberos settings are still needed for compatibility.

Related resources from NHI Mgmt Group

• Why do unsalted password hashes remain risky even when the hash function is strong?
• How should security teams handle password migration when a CIAM vendor will not disclose hash details?
• What breaks when password hash portability is missing during CIAM offboarding?
• Who is accountable when a CIAM vendor makes migration dependent on hidden hash details?