Kerberoast telemetry does not track Kerberoast success

Security tools often collapse two questions into one: did an attack work? and did we observe it?

For Kerberoasting, this is a mistake.

We tested Kerberoast behavior against live Windows Server and Samba domain controllers while independently changing ticket encryption, credential state, audit policy, and network controls. Across three sets of measurements, the same pattern appeared: attack success and telemetry emission behaved as separate channels.

A failed Kerberoast attempt could produce the expected Windows event. Rotating the target account's password did not prevent the ticket request. And the same Kerberos activity produced fundamentally different observable signals depending on the KDC implementation and audit configuration.

This matters for both detection systems and models of cyber risk. A detector should not infer that an attack succeeded because an event appeared. A risk model should not infer that an attack was invisible because it failed.

More generally, we think security telemetry should be modeled as an output of the environment that generated it:

rather than as a deterministic consequence of attack success.

01Measuring the attack and the signal separately

Kerberoasting abuses a normal property of Kerberos.

An authenticated domain user can request a service ticket for an account associated with a Service Principal Name, or SPN. Parts of that ticket are encrypted using key material derived from the service account's credential. An attacker can take the ticket offline and attempt to recover that credential.

The important point is that several distinct things happen along the way.

1. A ticket is requested.
2. The KDC decides whether it can issue it using the requested encryption type.
3. The request may or may not succeed.
4. The operating system or KDC may emit telemetry.
5. A downstream detector may or may not recognize that telemetry.

These events are related, but they are not equivalent. We measured them independently.

Our Windows environment used the GOAD forest on Azure, including sevenkingdoms.local, north.sevenkingdoms.local, and essos.local. For a Linux KDC, we built Samba 4.21.10 from source and ran Suricata 7.0.10 on the domain controller interface.

The attacker was an ordinary low-privilege domain user requesting service tickets for accounts with SPNs.

We varied several defensive posture variables independently: supported Kerberos encryption types, credential rotation, Kerberos audit policy, and network segmentation.

The results exposed three assumptions that initially looked reasonable and turned out not to be.

02A failed roast can still fire the detection signal

We first forced service accounts into an AES-only configuration.

On Active Directory, msDS-SupportedEncryptionTypes controls which Kerberos encryption types an account supports. We changed this value from 4, corresponding to RC4-only support in our setup, to 24, enabling AES128 and AES256.

We then requested tickets for three accounts: sql_svc, jon.snow, and sansa.stark.

The requests attempted an unsupported encryption path. All three failed. The KDC returned KDC_ERR_ETYPE_NOSUPP.

This is a small experiment, but it rules out a simple and tempting model:

That relationship does not hold even in these three cases. The request failed, but the operation was still auditable.

A detection oracle that emits a signal only when the attack succeeds would therefore be wrong on every observation in this experiment.

03Rotating the service account password does not prevent the request

A second tempting assumption is that rotating the credential of the account being roasted should prevent subsequent Kerberoast activity.

That assumption is wrong. The reason is in the authentication flow.

The user requesting the service ticket authenticates as the requesting principal. The service account whose ticket is being requested does not authenticate in order for the KDC to process the request.

Changing the service account's password therefore changes its cryptographic key material. It does not remove the attacker's ability to ask the KDC for a ticket for that account.

Under our credential-rotation posture, Kerberoast activity was still detected:

Credential rotation is still important. In particular, changing a compromised credential can invalidate credential material that an attacker has already recovered.

But that is a different effect. Rotation affects what can be done with a credential. It does not make the normal TGS request mechanism disappear.

This distinction sounds obvious once stated. It is rarely obvious in detection logic. That is one reason we prefer measured intervention effects over security logic written from intuition.

04The signal itself changes across systems

The largest difference appeared when we changed the environment rather than the attack.

Consider the same high-level behavior: request a Kerberos service ticket for an AES-only SPN.

On a Windows domain controller with Audit Kerberos Service Ticket Operations enabled, Event 4769 appeared 5 of 5 times. On a Windows domain controller without that audit configuration, it appeared 0 of 5 times.

On our Samba KDC, the framing changes again. There is no Windows Event 4769. More importantly, we did not find a 4769-equivalent text log line at any Samba log level we tested.

The evidence instead appeared in different places. At the network layer, we observed Kerberos traffic including KRB_TGS_REP enc=rc4-hmac. Suricata rules 9000010 and 9000011 could operate on the wire representation. Samba's KDC authentication audit separately exposed the encryption type as arcfour-hmac-md5.

The protocol behavior was recognizable. The telemetry schema was not portable.

This portability problem also appeared quantitatively.

A detection rule shaped around the Samba environment achieved an in-sample correlation of \(\rho = 0.951\) with measured detection outcomes. Transferred to Windows, the same rule fell to \(\rho = 0.549\).

The rule had learned something real about its environment. It had not learned a portable definition of Kerberoasting.

Transfer changes the telemetry-generating process, not the underlying Kerberos concept.

05Why this distinction matters

A large fraction of cybersecurity modeling starts with a mapping that looks roughly like technique → event → detection. For Kerberoasting, a common version is Kerberoast → Event 4769.

This is useful operational shorthand. It is not a causal model.

Our measurements suggest a more precise decomposition:

The distinction becomes important whenever we try to predict security behavior under interventions.

Suppose an organization disables RC4. Attack success may change.

Suppose instead it changes Kerberos audit policy. Telemetry may change while attack success remains identical.

Suppose it migrates from one KDC implementation to another. Both the available fields and the location of evidence may change.

A model that treats "detected" as a property of the attack technique cannot represent these cases correctly. We instead want detection to be conditional on the environment:

For this experiment, useful components of \(E\) include KDC implementation, audit policy, and encryption type. Attack success has its own conditional process.

Keeping those channels separate is not only cleaner. It prevents an operational measurement from becoming a false statement about the underlying system.

06Tool behavior is part of the experiment

We encountered one additional portability failure while setting up the Samba measurements.

GetUserSPNs.py from impacket 0.12.0 did not operate correctly against our Samba 4.21 environment. We observed an IndexError during LDAP binding, and the Kerberos path under -k produced KRB_AP_ERR_INAPP_CKSUM.

We therefore drove the Samba roast using MIT Kerberos tooling instead: kinit + kvno.

This detail is mundane, but important. A failed offensive tool invocation is not necessarily evidence that the attack primitive is unavailable. It may instead be evidence that the tool's implementation assumptions do not match the target.

That is the same general problem we observed in the telemetry itself: implementation details can masquerade as properties of the underlying security behavior.

07Limitations

The results therefore should not be read as a complete taxonomy of Kerberoast telemetry. They establish a narrower point: several mappings that appear universal are not universal even across the environments we tested.

08What's next

We are extending the experiment in two directions.

First, we are adding a second Windows Kerberoast target with an independently configured audit policy, to test whether the observed Windows behavior reproduces across hosts.

Second, we are applying the same measurement approach to other Kerberos attack surfaces, beginning with AS-REP roasting and S4U delegation abuse.

The broader goal is to represent cyber behavior at the level at which interventions actually operate.

An attack can succeed without producing a particular event. An event can appear when the attack fails. And the absence of a Windows event on a different KDC does not imply the absence of evidence.