The clearest signs are Kerberos events that indicate mismatched or incomplete PAC data. Event 38 shows a requestor mismatch, event 37 shows a ticket request without PAC_REQUESTOR, event 36 shows a ticket without a PAC, and event 35 shows a PAC without the new attributes. Those signals should be forwarded into SIEM for triage and correlation.
What PACRequestorEnforcement events are actually telling you
PACRequestorEnforcement is not a generic kerberos health signal. It is specifically useful because it surfaces inconsistencies between the ticket, the PAC, and the requestor context that should have been present if the ticket was legitimately issued. When those fields do not line up, the event becomes a strong indicator that the ticket may have been forged or altered.
The practical value is in the pattern, not any single event by itself. Event 38 points to a requestor mismatch, event 37 points to a ticket request that did not carry PAC_REQUESTOR, event 36 points to a ticket issued without a PAC, and event 35 points to a PAC missing the newer attributes that enforcement expects. Those are integrity failures in the Kerberos issuance chain, not normal noise.
Because the signal is about authentication integrity and ticket construction, it belongs in the same operational conversation as control validation and auditability. A ticket that fails PAC consistency checks should be treated as evidence that the environment is seeing either malformed issuance, legacy compatibility issues, or active abuse. That is why forwarding the events into NIST Cybersecurity Framework 2.0 aligned monitoring and NIST SP 800-53 Rev 5 Security and Privacy Controls style audit workflows is useful for correlation and triage.
How to read the four event types as a forged-ticket pattern
Event 38 is the clearest mismatch case because the requestor identity does not align with what the ticket says. Event 37 is also important because the absence of PAC_REQUESTOR suggests the ticket was built without the attribute that enforcement now expects to verify the requester. Event 36 is stronger still, since a ticket without a PAC removes one of the key structures used to validate authorization context. Event 35 is usually the most subtle, because the PAC exists but lacks the newer attributes that would let enforcement validate it cleanly.
Seen together, these events help separate isolated interoperability problems from a broader attempt to mint or replay tickets with incomplete or inconsistent metadata. That distinction matters because forged Kerberos tickets often do not fail in the same way as ordinary authentication errors. They may look plausible at first glance, then fail only when the PAC is examined against the requestor or trust chain.
A useful comparison is that the ticket may still be syntactically valid while being semantically wrong. That is what makes these events valuable for detection engineering. They expose the fact that the ticket content does not match the identity context that should have created it, which is exactly the kind of inconsistency defenders want to surface before a forged ticket is used for lateral movement.
What to correlate before you call it malicious
These events should not be interpreted in isolation. Correlate them with authentication failures, unusual ticket issuance paths, privilege escalation attempts, and any nearby indicators of credential access or delegation abuse. If the same host or account is also generating suspicious Kerberos service tickets, abnormal admin activity, or repeated failures followed by success, the case for active abuse becomes much stronger.
It also helps to distinguish rollout effects from real anomalies. A new enforcement setting can generate legitimate mismatches in mixed-version environments, especially when older systems or services do not yet populate the attributes expected by PACRequestorEnforcement. The operational question is whether the event fits a known compatibility window or whether it appears on a path that should already be fully compliant.
For broader threat mapping, these signals sit close to credential access and ticket abuse behaviours described in MITRE ATT&CK Enterprise Matrix. If the surrounding telemetry suggests ticket theft, pass-the-ticket style movement, or privilege misuse, the PAC inconsistency is not just a logging artifact, it is part of the attack narrative.
Risk and Threat Considerations
Forged or altered Kerberos tickets are dangerous because they can preserve the appearance of valid authentication while bypassing the normal trust that the PAC is meant to provide. The main risk is that an attacker can move from one compromised context to another using tickets that only fail when enforcement is active and monitoring is good.
Failure mechanism: The ticket, PAC, and requestor data no longer describe the same authentication event, so enforcement detects a structural mismatch instead of accepting the token at face value.
Impact: If those mismatches are ignored, a forged ticket can be used for unauthorized access, privilege escalation, or lateral movement before defenders recognise the abuse.
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 |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Security Continuous Monitoring | Kerberos PAC anomalies are detection signals that need continuous monitoring and correlation. |
| Recommendation — Correlate PACRequestorEnforcement events with adjacent authentication telemetry and alert on suspicious ticket patterns. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | PAC mismatch events are audit data that require review and correlation to spot forged-ticket abuse. |
| IA-5 — Authenticator Management | Kerberos tickets and PAC-related checks are part of authenticator lifecycle and integrity control. | |
| Recommendation — Review Kerberos audit events for PAC/requestor mismatches and escalate suspicious patterns for investigation. Validate Kerberos authenticator handling and flag tickets that lack expected PAC attributes. | ||
| MITRE ATT&CK | T1550 — Use Alternate Authentication Material | Forged Kerberos tickets are alternate authentication material used to evade normal logon controls. |
| Recommendation — Map PAC mismatch alerts to ticket-abuse techniques and hunt for lateral movement after suspicious issuance. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | These events must be centrally logged and correlated to be useful for forensics and detection. |
| Recommendation — Centralise Kerberos enforcement logs and alert on PAC/requestor inconsistencies. | ||
Practitioner Guidance
What to verify: Confirm whether the event appears alongside a known rollout of PAC enforcement, domain controller changes, or legacy client behaviour. If the pattern appears on systems that should already support the expected PAC fields, treat it as a higher-priority investigation rather than a compatibility issue.
What to prioritise: Focus first on the account, host, and service path that produced the mismatch, then check whether the same identity is also associated with unusual Kerberos service ticket volume, abnormal administrative access, or repeated failures followed by success. That sequence usually tells you whether you are seeing misconfiguration, opportunistic abuse, or active ticket forgery.
Practitioner takeaway: The best discriminator is not whether an event fired, but whether the event fits a controlled enforcement change or appears in a chain of suspicious authentication behaviour that suggests ticket tampering.
Related resources from NHI Mgmt Group
- How should security teams reduce the risk of forged cloud tickets in Azure AD Kerberos deployments?
- Why do stolen Kerberos tickets create such a difficult detection problem?
- What are the signs that enterprise AI monitoring is not catching security and compliance issues?
- What are the signs that phishing defenses are not catching high-risk messages effectively?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
