Detect it by watching for coercion followed by relayed Kerberos authentication that is used to obtain elevated access or create a privileged service. Correlate unusual service creation, local privilege escalation attempts, and authentication from the same host to another Windows system. Restrict unconstrained delegation paths and alert on unexpected Kerberos service changes.
What makes a Kerberos relay attack detectable on Windows?
The most reliable detection pattern is not a single event, but a sequence: one host triggers coercion, that same or related host then performs relayed Kerberos authentication, and the outcome is elevated access or a newly created privileged service. That combination is what separates a noisy authentication event from a real relay attempt, especially when the activity ends in service changes or local privilege escalation.
On Windows, the signal often emerges across authentication, service control, and host telemetry. A relay path can look normal in isolation because Kerberos is expected, but it becomes suspicious when the source system is also the one initiating service creation or privilege escalation immediately after coercion. Correlating those steps is more useful than hunting for any one event ID in isolation.
Detection also improves when you treat delegation and service changes as part of the same story. If a host should not be able to rely on unconstrained delegation, or if Kerberos service behavior changes unexpectedly, that is a strong indicator that the authentication path may have been abused rather than legitimately exercised.
Which Windows behaviours should you correlate?
Start with three correlated behaviours: coercion, relayed authentication, and privileged outcome. Coercion is often the first observable action, followed by Kerberos authentication that does not match the normal trust path, then an action such as local administrator gain, privileged service creation, or a system-level task being registered. The value of the correlation is that it ties identity misuse to a concrete effect on the host.
Service creation deserves special attention because relay attacks often convert authentication abuse into persistence or elevation. If a service appears soon after suspicious Kerberos activity, check whether it was created by an unexpected process, from an unusual source host, or under a context that should not be able to manage services on that system. That is often more informative than the authentication record alone.
Also watch for authentication between the same source host and another Windows system when the source should not normally initiate that pattern. In relay scenarios, the attacker is trying to convert a coerced or captured authentication exchange into access on a different target. The detector should therefore care about the path, not just the fact that Kerberos succeeded.
How should you reduce false positives and tighten coverage?
Baseline the normal Kerberos service and delegation footprint first, then alert on deviations. Environments with management tooling, software deployment systems, or tightly scripted admin workflows can produce service creation and cross-host authentication that looks unusual at first glance, so you need exception handling for known administrative paths. Without that baseline, relay detections tend to become either too noisy or too narrow.
For deeper investigation, compare the timing and origin of the authentication with the service change or privilege escalation. A legitimate admin action usually has a traceable change window and an expected management source. A relay attempt more often shows a chain that starts with coercion, then pivots into an authentication event that seems valid but is operationally out of place. The detection logic should preserve that temporal relationship.
When possible, enrich the alert with host role and delegation posture. A workstation generating server-like service activity, or a server handling Kerberos in a way that does not match its role, is more suspicious than the same event on a managed administrative host. That context helps separate attack activity from routine operations.
Risk and Threat Considerations
kerberos relay attacks matter because they turn a trusted authentication flow into an access path the defender did not intend. The risk is highest when relay can be converted into elevated access, service creation, or lateral movement before the abnormality is noticed.
Failure mechanism: An attacker coerces authentication, relays the Kerberos exchange to a different service or system, and uses the trusted result to perform privileged actions that look like valid authentication at the protocol layer.
Impact: The result can be local privilege escalation, unauthorized service creation, or a foothold that enables follow-on movement across Windows systems before standard authentication monitoring catches up.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1550 — Use Alternate Authentication Material | Covers relayed Kerberos use to gain access through trusted auth material. |
| T1021 — Remote Services | Windows relay activity often ends in remote service abuse or service creation. | |
| Recommendation — Map relayed Kerberos paths to T1550 and alert on authentication used outside the normal trust flow. Hunt for remote service abuse when Kerberos success is followed by privileged service changes. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Correlation of auth, service, and host events is central to detecting relay abuse. |
| IA-2 — Identification and Authentication (Organizational Users) | Kerberos relay abuses authenticated identity to obtain elevated access. | |
| AC-6 — Least Privilege | Restricting delegation and privileged service paths reduces relay impact. | |
| Recommendation — Correlate authentication, service creation, and host telemetry under AU-6 monitoring. Verify authenticated sessions and escalate when authentication yields unexpected privilege. Enforce least privilege on delegation paths and privileged service management. | ||
Practitioner Guidance
What to verify: Confirm that your detections join authentication telemetry with service control and host process context. A Kerberos event alone is rarely enough, but a Kerberos event followed by service creation or privilege escalation from the same host is worth immediate review.
Decision rule: If the host can reach other Windows systems and can also influence services or privileged actions, treat unexpected Kerberos success as a potential relay path until the source, destination, and resulting action are all explained.
What good looks like: You can explain every privileged Kerberos-driven service change by approved administration, known tooling, and a normal delegation path. Anything outside that pattern should be visible as a correlated chain, not as a lone authentication event.
Practitioner takeaway: The best detection for Kerberos relay on Windows is correlation-first, not event-first, because the attack becomes visible when trusted authentication is tied to an abnormal privileged outcome.
Related resources from NHI Mgmt Group
- Guide: Kerberos Security Guide
- How can organizations counter AI-driven cyber attacks?
- Why can a single SaaS app create such a large blast radius?
- Why do downgrade attacks create such high risk for fully patched Windows systems?
- Why do LLMNR poisoning attacks create such a high risk for credential theft in Windows environments?