What breaks when Kerberos services do not enforce signing or CBT?

Why This Matters for Security Teams

When a Kerberos-backed service does not enforce signing or channel binding token protection, the protocol may still issue a valid ticket, but the endpoint no longer proves that the ticket was presented on the intended channel. That gap turns relaying into a practical impersonation path, especially where DNS manipulation, proxying, or on-path interception is possible. NIST guidance on authentication controls in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that authentication is not just about accepting credentials, but about binding them to the right session and enforcing verification at the service boundary.

This is not a theoretical edge case. Attack chains against identity systems often succeed because services trust the ticket too much and the transport too little. The same governance pattern shows up in broader identity failures documented by NHI Management Group, including the Ultimate Guide to NHIs, where identity sprawl and weak lifecycle control create a wide attack surface. In practice, many security teams encounter relay abuse only after lateral movement or service impersonation has already started, rather than through intentional hardening reviews.

How It Works in Practice

Kerberos depends on the service proving that it received a ticket over a trusted exchange. Service signing helps protect message integrity, while CBT binds the authentication exchange to the underlying TLS channel so a captured or relayed ticket is harder to reuse elsewhere. If neither is enforced, an attacker can position themselves between the client and service, induce authentication, and forward the ticket to the target without needing to crack Kerberos cryptography.

That matters most where the service accepts integrated authentication from browsers, Windows endpoints, reverse proxies, or middleware that silently negotiates Kerberos. The service may believe the client is legitimate because the ticket is valid, even though the exchange was relayed. This is why endpoint enforcement matters more than protocol familiarity.

• Require Kerberos signing where the service supports it, so messages cannot be altered in transit.
• Enforce CBT on TLS-protected endpoints so the ticket is tied to the specific channel.
• Prefer hardened service configurations over “it works” defaults in IIS, web apps, and middleware.
• Validate DNS, proxy, and SPN design so clients are not tricked into authenticating to an attacker-controlled listener.

NHI Management Group’s ASP.NET machine keys RCE attack shows how weak trust boundaries in application identity can turn one authentication weakness into broader compromise, and the Schneider Electric credentials breach underscores the operational cost when identity controls fail to constrain misuse. These controls tend to break down when legacy services, load balancers, or custom clients cannot negotiate CBT consistently because the endpoint stack was never designed for channel-aware authentication.

Common Variations and Edge Cases

Tighter Kerberos enforcement often increases compatibility work, requiring organisations to balance resistance to relay attacks against legacy application stability. That tradeoff is real, especially in mixed Windows, Linux, and proxy-heavy environments where not every component supports signing or CBT cleanly.

Current guidance suggests treating “Kerberos works” as insufficient unless the service is explicitly protected against relay. In some environments, administrators discover that a service accepts Kerberos only through a load balancer or TLS terminator that strips the channel context needed for CBT. In others, HTTP-to-backend delegation or constrained delegation can create confusing trust paths that make the real exposure harder to see. Best practice is evolving, but the direction is consistent: bind authentication to the transport, not just the ticket.

Where full enforcement is not yet possible, teams should scope compensating controls around high-value services, reduce exposed listeners, and prioritize patching or redesigning endpoints that accept integrated authentication. The Gladinet Hard-Coded Keys RCE Exploitation case is a reminder that weak identity assumptions at the application layer often become full compromise when transport and trust boundaries are loose.

Related resources from NHI Mgmt Group

• What breaks when low-privilege Windows accounts can write files through RPC services?
• What breaks when users reuse passwords across multiple services?
• What breaks when security teams prioritise CVEs one by one?
• What breaks when stored XSS reaches a privileged browser session?