Security teams detect S4U2self abuse by looking for Kerberos service ticket requests made through constrained delegation paths that do not match normal application behaviour. Investigate unusual service accounts, sudden access to many user identities, and requests from hosts that do not normally perform delegation. Confirm which accounts are trusted for delegation and review whether the requesting service should be able to act on behalf of users.
How S4U2self abuse shows up in Kerberos telemetry
s4u2self abuse usually stands out as a protocol transition pattern that does not fit the normal job of the service account involved. Look for ticket requests that let one service request a service ticket for a user identity without the usual interactive logon path, especially when the account rarely delegates in the first place.
The strongest signal is mismatch: the account, host, and request volume do not line up with the application’s normal behaviour. A single host suddenly generating tickets for many users, or a service account appearing in Kerberos flows it has not used before, is often more useful than any one isolated event.
In practice, the detection question is whether the delegated request is plausible for that service. If the service is not meant to act on behalf of users, or the destination service and source host do not match the known application path, treat the event as suspicious and correlate it with nearby authentication and access activity.
What to confirm before treating it as abuse
First confirm whether the account is actually trusted for delegation and whether constrained delegation is expected for that workload. That check separates legitimate protocol transition from abuse of a correctly configured delegation path. Review the service account, the host that issued the request, and the target service to see whether the path is consistent with design.
Then compare the request pattern with the application’s normal identity behaviour. If the service usually acts for a small, stable user set and suddenly begins requesting tickets for many identities, the change in scope matters. The same is true when a system that normally never delegates starts doing so after a configuration change, credential theft, or other intrusion event.
For defenders, the most valuable confirmation is administrative context, not just packet or event detail. Knowing which accounts are marked trusted for delegation, which back-end services they may reach, and which hosts are allowed to initiate those flows gives you the baseline needed to decide whether the request is expected or abusive.
When the issue is delegation abuse, the normal response is to validate the trust path, not to assume every ticket request is malicious. That distinction avoids noisy investigations while still surfacing the cases where an attacker has turned a legitimate Kerberos feature into an impersonation path.
Detection logic that helps separate normal delegation from misuse
Build detection around behavioural deltas rather than a single signature. Kerberos Delegation Security Guide is useful here because the same delegation concepts that enable legitimate protocol transition also define what suspicious S4U2self activity looks like when it is abused.
Focus on the combination of source host, service account, and user population. An unusual source system issuing S4U2self requests, a service account that has not historically delegated, or a sudden increase in distinct user impersonations are all stronger indicators than ticket volume alone.
Correlate Kerberos events with directory changes, new service configuration, and lateral movement indicators. S4U2self abuse often becomes visible only when the delegation request is viewed alongside the broader host and account behaviour around it. That is where you can tell a legitimate service flow from an attacker using the service to mint tickets for access it should never have.
Risk and Threat Considerations
S4U2self abuse matters because it turns a trusted service identity into a proxy for user impersonation. If the attacker controls that service account or the host it runs on, they may be able to request tickets that look operationally valid while expanding access far beyond the service’s intended role.
Failure mechanism: A delegated Kerberos path is abused to request service tickets on behalf of users the service should not be able to impersonate, often after compromise of the service account or its host.
Impact: The attacker may gain broader access, move laterally through services that trust the delegated identity, and hide activity inside normal-looking Kerberos traffic.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1550.002 — Use Alternate Authentication Material: Pass the Ticket | Covers Kerberos ticket abuse and delegated access paths used for impersonation. |
| Recommendation — Map ticket misuse patterns to ATT&CK and hunt for delegated access abuse in Kerberos telemetry. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Applies to reviewing and limiting who can delegate and act on behalf of users. |
| Recommendation — Review delegated access paths and revoke unnecessary delegation rights. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Relevant because service-account credentials and ticketing paths must be controlled and monitored. |
| AC-6 — Least Privilege | Directly supports limiting which services may impersonate users or access back-end systems. | |
| Recommendation — Manage service credentials and detect abnormal authentication patterns for delegated services. Restrict delegation and impersonation paths to the minimum required set of services. | ||
Practitioner Guidance
What to verify: Confirm the exact delegation scope for the service account, the host that generated the request, and the back-end service that accepted it. If any of those three do not match the known application design, escalate the event.
Decision rule: If the service has no clear business need to impersonate users, treat any new S4U2self activity as high priority. If delegation is expected, focus on whether the user set, host, or request rate changed in a way that suggests compromise rather than normal growth.
Practitioner takeaway: The key judgement is whether the Kerberos path is merely permitted or actually justified. Abuse detection becomes much stronger when teams anchor alerts to expected delegation behaviour, not just the presence of ticket requests.