How do you detect Rubeus Kerberos attacks on Windows?

What Rubeus leaves behind on a Windows host

Rubeus is noisy in ways defenders can use. The tool’s kerberos abuse tends to show up as bursts of ticket activity that do not match the normal behaviour of the user, service, or workstation, especially when an attacker is enumerating SPNs, requesting tickets at scale, or moving from initial access into lateral movement. The key is to compare the Kerberos pattern with the host context, not just look for a single event.

On the domain controller side, watch for service ticket and ticket-granting ticket patterns that spike unusually fast, repeat from an unexpected source, or target accounts that do not usually consume Kerberos in that way. On the endpoint side, pair that with process creation, command-line telemetry, and memory-related signals, because Rubeus is often launched directly or used to generate artefacts in memory rather than through normal user workflows. For deeper Kerberos context, the Kerberos Security Guide covers the ticket abuse patterns, delegation issues, and common detection cues that matter here.

Rubeus is not only about ticket requests. It can also be used to abuse delegation, harvest or replay Kerberos material, and create authentication flows that look technically valid but are operationally inconsistent with the endpoint, account, or time window. That is why detections should look for mismatches between identity, host role, and authentication sequence rather than relying on one event ID or one signature.

Which telemetry matters most for detection

DC logs are the starting point, but they are not enough on their own. Correlate them with endpoint telemetry so you can see whether the Kerberos activity came from an expected login path or from a suspicious process chain. If ticket requests are paired with abnormal command-line execution, remote service creation, or memory access that resembles in-memory Kerberos tooling, the likelihood of malicious use rises sharply.

Authentication failures are especially important when they appear alongside later success. A cluster of failed requests followed by a sudden burst of valid ticket use can indicate probing, password spraying against a target account, or repeated attempts to reach a specific service. A second useful pattern is delegation misuse, where the account or host suddenly performs Kerberos actions that do not fit its normal authorisation boundary. That is the point at which ticket abuse becomes more than noise and starts to look like a live attack path.

Endpoint visibility also helps separate operator error from compromise. A legitimate admin may generate ticket activity, but they usually do not pair it with suspicious binary execution, odd parent-child process chains, or service creation tied to a standard user workstation. For adversary tradecraft around credential and ticket abuse, MITRE ATT&CK Enterprise Matrix is a useful way to map what you are seeing to credential access, lateral movement, and privilege escalation behaviour.

How to separate suspicious Kerberos noise from real abuse

The practical test is whether the activity is explainable by the host and account’s normal role. A jump server, admin workstation, or service host may generate more Kerberos traffic than a standard endpoint, but it should still do so in a consistent pattern. When the same account starts requesting tickets from a new source, at a new rate, or for a new set of services, that deviation matters more than the raw volume.

Also look for signs that the attacker is trying to blend in. Kerberos abuse often succeeds because the resulting traffic is protocol-valid, so the detection problem is behavioural. That means baselining normal service ticket cadence, spotting unusual encryption or delegation behaviour where you can, and correlating the identity involved with the asset that generated the request. If you have to choose, prioritise the source-account-destination relationship over a single indicator.

When the pattern points to broader identity abuse, compare it with your directory and access review data. The same investigation should tell you whether the account has excessive privilege, whether the service principal is overused, and whether the host should have been able to request those tickets at all. For defenders who want to formalise that review, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a solid reference for audit, access, and monitoring control expectations.

Risk and Threat Considerations

Kerberos abuse is risky because it often turns valid authentication into a stealth path for lateral movement. Once an attacker can obtain or replay tickets, the compromise can spread quickly across services without triggering the same controls that would catch direct password theft.

Failure mechanism: The attacker abuses normal Kerberos flows to request, reuse, or delegate tickets from a host or account that should not be behaving that way, which allows malicious access to look legitimate at the protocol layer.

Impact: You can lose trust in authentication logs, miss the early stages of lateral movement, and allow the attacker to reach additional systems using identities that still appear valid.

Practitioner Guidance

What to prioritise: Start with the accounts and hosts that can create the most downstream access, especially admin workstations, service accounts, and systems that touch multiple domains or tiers. Those are the places where ticket abuse is most likely to create material blast radius.

What to verify: Confirm whether the Kerberos pattern matches a known admin task, scheduled service, or application dependency. If it does not, treat the source account and source host as suspect until you can explain the sequence end to end.

Common mistake: Teams often alert on a single suspicious ticket event and stop there. The stronger signal is the sequence, repeated requests, abnormal source, process evidence, and any later use of the same identity for access that should not have been possible.

Practitioner takeaway: Detecting Rubeus is mostly about correlation, Kerberos telemetry becomes actionable when you can tie ticket behaviour to an unexpected host process, an unusual identity path, and a plausible lateral-movement objective.

Related resources from NHI Mgmt Group

• How do you detect Kerberos relay attacks such as KrbRelayUp on Windows?
• How do you detect NTLM brute force attacks on Windows domains?
• How do you detect pass-the-hash attacks on Windows?
• How can organizations counter AI-driven cyber attacks?