Look for unusual TGS requests to HOST or CIFS SPNs that do not match a known service endpoint, especially when the target hostname is unresolved or recently changed. You should also treat unexpected DNS updates from standard users as a strong signal that the authentication path may be under manipulation.
What Kerberos reflection looks like in Windows telemetry
kerberos reflection attempts usually stand out as authentication traffic that does not line up with a normal service path. The most useful signal is a TGS request for common service SPNs such as HOST or CIFS where the target does not look like a genuine service endpoint, or where the hostname is unresolved, newly introduced, or unexpectedly renamed. That mismatch often matters more than any single packet.
When the request pattern is legitimate, the SPN, hostname, and service relationship usually stay stable. Reflection attempts try to exploit that trust boundary by making a service ticket appear usable in a place where it should not naturally belong. In practice, that means defenders should compare the requested SPN, the hostname resolution state, and recent changes to the target object rather than relying on one indicator alone.
Standard user DNS activity can also become a clue. If ordinary users are creating or changing DNS records, especially around the same time as suspicious Kerberos activity, that can indicate the attacker is manipulating name resolution so a reflected authentication exchange lands on an endpoint of their choosing. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties detection, auditability, and configuration oversight together when authentication and naming assumptions are being abused.
Why the hostname and SPN mismatch matters
Kerberos reflection depends on confusing the expected service relationship. If a ticket is being requested for HOST or CIFS but the destination does not correspond to a live Windows service endpoint, that is a strong sign the requester is probing for a place where the ticket can be replayed or redirected. The same is true when a hostname resolves inconsistently, or resolves only after an unusual DNS change.
The key practitioner point is that the anomaly is contextual, not absolute. A single HOST or CIFS request is not enough by itself. What makes it suspicious is the combination of service class, host identity, name resolution state, and recent infrastructure change. If those pieces do not line up, treat the event as an investigation trigger rather than normal authentication noise.
Ticket requests that diverge from the normal service inventory are also a strong hunting pivot because they often precede lateral movement. MITRE ATT&CK Enterprise Matrix helps analysts place that behaviour in a broader credential access and lateral movement pattern, while NIST SP 800-207 Zero Trust Architecture reinforces the idea that trust should be evaluated per request, not assumed because a Kerberos ticket exists.
What to correlate before you call it reflection
Good detection depends on correlation, not on one log source. Validate whether the service ticket request aligns with a known server role, whether the target hostname was recently created or altered, and whether DNS activity came from a principal that should not be managing naming records. Also check whether the same host shows repeated failed or redirected authentication attempts, because reflection attacks often leave a pattern of retries.
If the environment has good asset inventory and DNS change control, you can usually separate attack activity from legitimate service onboarding quickly. If it does not, the suspicious signal gets harder to interpret, which is why inventory quality and change discipline matter as much as packet inspection. NIST Cybersecurity Framework 2.0 is helpful as a governance lens for asset visibility, detection, and response coordination, and NIST SP 800-53 Rev 5 Security and Privacy Controls supports the control side of that same problem.
A practical way to read the evidence is to ask whether the Kerberos request, the DNS state, and the service endpoint history all tell the same story. If they do not, the environment may be seeing manipulation rather than routine authentication.
Risk and Threat Considerations
Kerberos reflection is risky because it abuses trust in name resolution and service targeting, which can let an attacker reuse authentication material in a place defenders did not intend. The danger is highest when DNS can be altered by accounts that should never influence service routing, or when server names and SPNs are not tightly governed.
Failure mechanism: An attacker manipulates hostname resolution or service targeting so a Kerberos exchange is directed at a system that can accept or reflect the authentication flow in an unintended way.
Impact: Successful reflection can enable unauthorized access, lateral movement, or privilege abuse while the traffic still resembles ordinary Kerberos activity.
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, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Kerberos reflection detection depends on reviewing auth and DNS anomalies. |
| AC-6 — Least Privilege | Unexpected DNS updates by standard users indicate excessive authority on naming. | |
| Recommendation — Correlate Kerberos and DNS events to flag mismatched service targeting quickly. Restrict DNS and service-change privileges to approved administrative roles. | ||
| NIST CSF 2.0 | DE.CM-01 — Anomalies and Events are Monitored | The question is about spotting anomalous authentication behaviour in Windows. |
| Recommendation — Monitor Kerberos and DNS telemetry for service-targeting anomalies. | ||
| MITRE ATT&CK | T1550.003 — Pass the Ticket | Reflection-style abuse is part of ticket re-use and lateral movement tradecraft. |
| Recommendation — Map suspicious ticket use to credential-access and lateral-movement hunting. | ||
| NIST Zero Trust (SP 800-207) | Never trust, always verify | Reflection exploits misplaced trust in the authentication path. |
| Recommendation — Verify each service request against endpoint and name-resolution state. | ||
Practitioner Guidance
What to verify: Confirm that the destination host is a real service endpoint, the SPN is expected for that server role, and the hostname has not changed recently without an approved change record. If DNS changes originated from standard user accounts, treat that as a priority investigation item rather than a housekeeping issue.
What to prioritise: Focus first on systems where name resolution, SPN registration, and authentication logs disagree, because those are the places where reflection attempts are easiest to hide. The highest-value triage is the one that can quickly separate a misconfiguration from an active attempt to manipulate the authentication path.
Practitioner takeaway: Kerberos reflection detection is strongest when you evaluate the service ticket, the resolved host, and the DNS change trail together, because the attack depends on inconsistency across those three layers.
Related resources from NHI Mgmt Group
- What are the signs that NTLM is still too deeply embedded in a Windows environment?
- What are the signs that file access control is failing in a Windows environment?
- What are the signs that Kerberos delegation is being abused in a Windows domain?
- What are the signs that living-off-the-land detection is failing in a Windows environment?