Why do Kerberoasting and ticket-forgery attacks remain effective in Active Directory?

Why these attacks work in Active Directory

Kerberoasting and ticket-forgery stay effective because active directory was built to trust Kerberos tickets, and many environments still let service accounts carry durable privilege. If an attacker can request a service ticket, crack the underlying secret offline, or forge a ticket with the right trust characteristics, they can often turn directory trust into access without touching a password prompt or an endpoint control.

The weakness is not Kerberos itself, but the combination of predictable service-account exposure, long-lived credentials, and broad entitlements. A service principal name makes an account easy to target; a weak or reused secret makes it feasible to recover; and excessive permissions make the resulting compromise worthwhile. NHIMG’s Service Account Security Guide and Active Directory and Entra ID Hardening Guide both reinforce the same practical point: once service identities are overexposed, the directory becomes an attack surface rather than a control plane.

Ticket-forgery variants are effective for the same structural reason. If an attacker reaches the right secret material or trust anchor, forged tickets can be accepted as valid inside the realm, especially where delegation, legacy protocol settings, or weak tier separation preserve broad trust relationships. That is why these attacks often move from one compromised service identity to higher-value accounts, rather than stopping at the first account that was cracked.

Where the compromise path usually starts

The most common entry condition is a service account that was never treated as a high-value identity. In practice, those accounts often have long passwords, no effective rotation, shared ownership, and permissions that are wider than the application truly needs. A kerberoastable account is not automatically compromised, but it becomes attractive because its secret can be attacked offline and at scale, outside the directory’s normal lockout or detection loops.

Forged-ticket attacks depend on a different but related assumption: that once issued or constructed, a ticket will continue to be trusted by downstream services. If the trust boundary is too generous, or if the account and service topology is poorly segmented, the forged ticket can open paths that the environment intended to keep separate. The problem becomes more severe when service accounts are reused across environments, domains, or applications, because one recovered secret can then represent more than one trust relationship.

NHIMG’s Identity Threat Detection and Response (ITDR) Guide is useful here because it frames the attack as an identity event, not just a malware event. The detection challenge is to spot unusual ticket requests, abnormal service-account usage, and privilege movement that still looks “valid” from the directory’s perspective.

Why defenders still miss it at scale

These attacks remain effective because many controls focus on authentication success, not on whether the identity behind the ticket should have existed in that form. Kerberoasting is especially hard to stop with perimeter-style monitoring because the attacker is abusing a legitimate protocol flow. Ticket forgery is harder still when detection is based on whether the ticket can be parsed, rather than whether the account, realm, age, or trust path makes sense.

At scale, the real issue is inventory and ownership. If teams cannot answer which service accounts exist, what they authenticate to, whether they still need domain-level rights, and who owns their lifecycle, then weak tickets and stale trust persist long after an application change. NHIMG’s NHI Lifecycle Management Guide is relevant because the same lifecycle failures that create orphaned non-human identities also keep service-account exposure alive in Active Directory.

That is also why these attacks often survive repeated hardening cycles. Teams rotate some passwords, patch some servers, and add logging, but leave the underlying trust model intact: overprivileged service accounts, broad delegation, legacy encryption settings, and incomplete segmentation. When the trust graph is still dense, one credential or ticket can still become a broad access path.

Risk and Threat Considerations

These attacks matter because compromise is frequently quiet and structurally hard to contain. The adversary is not necessarily breaking the directory; they are using it as intended, then amplifying the privilege attached to a service identity or forged ticket.

Failure mechanism: Weak or reusable service-account secrets, durable trust, and excessive privilege let an attacker recover credentials offline or present a ticket that downstream systems accept as legitimate.

Impact: The result can be lateral movement, privilege escalation, domain persistence, and access to systems that were never directly exposed to the original compromise.

Practitioner Guidance

What to prioritise: Treat any service account with a service principal name, elevated rights, or cross-system reach as a privileged identity. If the account can authenticate to production services and is not tightly bounded, it deserves lifecycle review before you focus on endpoint hardening.

What to verify: Confirm that service accounts have unique ownership, documented purpose, rotation discipline, and the minimum set of permissions needed for the application. If a ticket can be requested for an account that no team can clearly justify, that is already a governance failure.

Common mistake: Reducing the issue to “Kerberos is insecure” or “use stronger passwords.” The real control problem is over-trust: long-lived secrets, stale accounts, reuse across environments, and delegated rights that outlive the application design.

Practitioner takeaway: The most effective defence is not to chase the ticket after it exists, but to shrink the number of identities that can be turned into a durable trust path in the first place.

Related resources from NHI Mgmt Group

• Why does Kerberoasting remain effective in mature Active Directory environments?
• How should security teams reduce the risk of Golden Ticket attacks in Active Directory?
• Why do Golden Ticket attacks create such broad identity risk in Active Directory environments?
• How can organizations counter AI-driven cyber attacks?