noPAC

How noPAC Works

noPAC is a Kerberos abuse technique that targets the PAC validation path, where ticket integrity checks are supposed to prevent forged authentication data from being accepted. The attack matters because it turns a trusted Kerberos artifact into a vehicle for impersonation, privilege escalation, or both, depending on how the service validates the ticket and embedded privileges.

At a high level, the attacker is not trying to “break Kerberos” wholesale. Instead, they exploit a specific trust gap between ticket creation, PAC handling, and server-side validation. When that path is weak, the resulting ticket can look legitimate enough for downstream services to accept it as if it were issued for a valid user.

This makes noPAC a protocol abuse issue, not just a single bug pattern. The important concept is that Kerberos environments depend on both cryptographic ticket handling and correct PAC verification, so a failure in either can undermine the trust model even if the rest of the authentication flow appears normal.

Why PAC Validation Failures Are Dangerous

The Privilege Attribute Certificate carries authorization-relevant information, so a validation failure can affect more than authentication alone. If forged PAC data is accepted, the attacker may be able to inherit group memberships, service privileges, or other access attributes that were never legitimately granted.

That is especially dangerous in enterprise environments where Kerberos is used as a foundation for single sign-on and service-to-service access. Once a forged service ticket is trusted, the attacker can blend into normal authentication traffic and use the resulting access to move laterally, reach sensitive systems, or abuse high-value services.

The risk is amplified when organisations assume that “Kerberos equals safe” and do not separately verify how PAC checks are implemented on critical services. The weakness is often not visible at the business-logic layer, so the impact may persist until unusual access patterns or impossible privilege combinations are investigated.

How Organisations Assess Exposure and Recover

Exposure review starts with an accurate inventory of Kerberos-reliant systems, especially domain controllers, member servers, and services that accept Kerberos-authenticated requests. Organisations should also check whether sensitive services are reachable from untrusted network locations, because internet exposure and weak segmentation make exploitation and follow-on access easier.

Vendor advisories and the CISA Known Exploited Vulnerabilities catalogue are the authoritative places to confirm affected versions, fixes, and remediation status for a specific product or implementation. That matters because noPAC is about a technique, but the practical exposure still depends on the exact platform, patch level, and PAC validation behaviour in use.

When patching cannot happen immediately, compensating controls should focus on reducing trust in the affected path, limiting where Kerberos tickets can be used, and tightening monitoring around privileged authentication flows. After suspected exploitation, organisations should review privileged sessions, service access, and any accounts whose access was derived from the forged ticket path.

Detection and Post-Compromise Review

Detection is difficult if teams only look for noisy credential theft events, because noPAC can present as valid Kerberos activity. Useful signals include unusual ticket use against sensitive services, privilege combinations that do not match the user’s normal role, and access paths that appear legitimate but are inconsistent with directory data or admin workflows.

Post-patch review should assume that access obtained through forged tickets may already have been used to establish persistence or reach additional systems. That means reviewing authentication logs, service access history, and any privilege changes made during the suspected window, then rotating or reissuing credentials and secrets for accounts that could have been exposed through the compromised path.

Practitioner Guidance

What to watch for: Treat noPAC as a trust-validation problem, not only a patching problem. If a Kerberos-enabled service accepts authentication but does not robustly validate the PAC path, the environment may still be vulnerable even when normal login flows appear healthy.

Governance implication: Ownership should sit with identity, platform, and server teams together, because the control failure crosses directory services, application hosting, and service configuration. The right question is whether the organisation can prove that every critical Kerberos acceptance path is validated, monitored, and recoverable if abused.

Related resources from NHI Mgmt Group

• How do you detect noPac sAMAccountName spoofing attacks in Active Directory?
• NoPAC Vulnerability