Testing for Kerberos unconstrained delegation abuse in Active Directory

Kerberos unconstrained delegation is one of those Active Directory configurations that can sit quietly for years and still create a disproportionate amount of risk. It is often introduced to make a legacy application work, then left in place because nobody wants to disturb a fragile dependency. From a defender’s point of view, that makes it worth testing carefully. The goal is not to exploit anything, but to understand whether an attacker who compromises a delegated host could use that trust to reach other users’ service tickets and move further into the domain.

For UK SMEs, the practical question is simple: do we know where unconstrained delegation exists, do we know which systems depend on it, and can we detect abuse if it happens? If the answer to any of those is unclear, you have a useful testing opportunity. This is especially relevant where identity infrastructure is shared across business-critical services, because the impact of a single misconfigured server can extend well beyond the original host.

What unconstrained delegation is and why it matters

Kerberos is the authentication protocol used by Active Directory to let a user prove their identity to a service without sending a password to that service. In a delegated scenario, one service is allowed to act on behalf of a user when it needs to call another service. That is common in multi-tier applications, where a front-end web server needs to access a back-end database or file share using the user’s identity.

With unconstrained delegation, the delegated server is trusted to receive and cache Kerberos tickets for users who authenticate to it. That is the key risk. If an attacker gains administrative control of that server, they may be able to extract those cached tickets and impersonate users to other services. In practical terms, a single compromised host can become a stepping stone to broader domain access, especially if privileged users ever authenticate to it.

This is why unconstrained delegation is usually treated as a high-value attack path in identity assessments. It is not the same as a vulnerability in the cryptographic protocol itself. The issue is the trust model and the operational reality that delegated servers are often older, less monitored, and connected to sensitive internal systems. If you already use attack path analysis tools such as BloodHound, this is exactly the kind of relationship they are good at surfacing. For a broader view of how to structure this kind of work, see our article on security regression testing and abuse case testing.

How unconstrained delegation differs from constrained and resource-based delegation

It helps to separate the three main delegation models before testing. Unconstrained delegation is the broadest trust relationship. Constrained delegation limits the services a host can delegate to, which reduces the blast radius. Resource-based constrained delegation shifts control to the target resource, allowing it to decide which principals may delegate to it. That model is generally easier to reason about in modern environments because the trust is explicit and narrower.

The practical security implication is that unconstrained delegation gives the delegated host far more power than most teams realise. If the host is compromised, the attacker is not limited to a single downstream service. They may be able to use cached tickets for any user who authenticated to the host, subject to the usual Kerberos constraints and the attacker’s level of access. By contrast, constrained delegation narrows the scope, and resource-based constrained delegation gives administrators a cleaner way to manage trust on the resource side.

In Active Directory, the flag often associated with unconstrained delegation is TRUSTED_FOR_DELEGATION. You may also see related service account configuration and SPN placement influence how delegation behaves. The important point for testing is not just whether the flag exists, but whether the account or computer object is actually reachable, monitored, and necessary. A dormant configuration on a decommissioned server is still a risk, but a live application server used by privileged staff is a much more urgent one.

Common places to find unconstrained delegation in enterprise environments

In practice, unconstrained delegation is most often found on computer accounts rather than user accounts, although service accounts can also be involved depending on the application design. Legacy application servers, print servers, file servers, and older middleware are common candidates. These systems may have been configured years ago to support double-hop authentication or integrated Windows authentication, and the original design decision may no longer be documented.

It is also common to find delegation on systems that sit close to administrative workflows. For example, a server used for remote administration, reporting, or line-of-business integration may receive authentication from users with elevated rights. That is exactly the sort of place where cached tickets become dangerous. If a privileged account authenticates to a delegated host, the value of that host increases immediately.

When you are scoping a test, look for systems that are both trusted and busy. A rarely used server with unconstrained delegation is still worth fixing, but a server that handles regular authentication from staff, support teams, or domain admins should be prioritised. If you are already mapping identity attack paths, our article on enumerating Active Directory attack paths with BloodHound and SharpHound is a useful companion piece.

How to assess whether your environment is exposed

The first step is a directory review. In PowerShell, the Active Directory module can be used to identify computer objects with the delegation flag set. A simple starting point is to query for the relevant userAccountControl value and review the results with the owning teams. You are not looking for proof of exploitation here, only for the presence of the trust relationship and whether it is still justified.

Get-ADComputer -Filter * -Properties userAccountControl | Where-Object { $_.userAccountControl -band 0x80000 } | Select-Object Name, DNSHostName, userAccountControl

That bitmask corresponds to unconstrained delegation. You may also want to review service accounts and any objects with service principal names, because those often sit behind applications that depend on Kerberos. In larger estates, it is worth exporting the results into a spreadsheet or a case management system so you can track ownership, business justification, and remediation status.

BloodHound and SharpHound are useful because they show delegation as part of the wider attack graph. SharpHound collects directory data, and BloodHound lets you visualise relationships such as session paths, local admin rights, and delegation edges. For this topic, the value is in seeing whether a delegated host has sessions from privileged users or is otherwise positioned to become a pivot point. If you want a broader explanation of how to use these tools for identity risk analysis, our article on credential attack simulation using BloodHound covers the general workflow.

When reviewing the output, pay attention to three things: whether the host is still required, whether privileged users log on to it, and whether there is any compensating control such as strong endpoint protection, restricted admin access, or network segmentation. A delegated server that is isolated, tightly managed, and never used by privileged accounts is still not ideal, but it is a very different risk from a shared application server with broad access.

What to look for in logs and telemetry

Detection for unconstrained delegation abuse is usually indirect. You are rarely going to see a neat event that says “delegation abused”. Instead, you build confidence by correlating Kerberos activity, endpoint telemetry, and domain controller logs. On domain controllers, Kerberos service ticket activity is especially important. Event ID 4769 can help you understand which service tickets are being requested, from which systems, and at what rate. Sudden changes in ticket patterns, unusual service names, or requests that do not match normal application behaviour are all worth investigating.

On the delegated host itself, look for signs that an attacker is accessing LSASS, dumping memory, or using administrative tools to inspect cached credentials. Sysmon can help here if you have it deployed with sensible tuning. Process creation events, handle access, and suspicious use of built-in utilities can all support a detection story. Endpoint detection and response telemetry is also useful because it can show whether the host is being used interactively in a way that does not fit the normal service profile.

At the SIEM layer, the best results usually come from combining identity and endpoint context. For example, if a delegated server suddenly receives a logon from a privileged account outside its normal maintenance window, and shortly afterwards you see unusual Kerberos ticket activity or suspicious process creation, that is a stronger signal than any single event on its own. This is the same principle we use in other detection work, including detecting Golden Ticket and Silver Ticket attacks in Kerberos logs.

It is also worth checking whether your log retention is long enough to support investigation. If you only keep a few days of authentication data, you may miss the sequence that shows how a delegated host was used. For identity-heavy environments, retaining enough telemetry to reconstruct a timeline is often more valuable than trying to log everything at maximum verbosity.

How to validate detection coverage safely

Safe validation means testing the control, not reproducing a real attack chain in production. The cleanest approach is to use a lab or an approved change window with a clearly defined scope, a rollback plan, and named owners for the systems involved. If you need to verify whether your detections fire when a delegated host behaves unusually, you can do that with benign administrative actions and controlled account use rather than attempting any exploit-style activity.

A practical test plan might include the following steps. First, confirm the delegated host and the accounts that are allowed to authenticate to it. Second, generate normal authentication traffic and record the baseline in your SIEM. Third, perform a controlled logon with a test account and confirm that the expected Kerberos events appear. Fourth, use your EDR or Sysmon telemetry to confirm that the host activity is visible. Fifth, check whether your alerting logic distinguishes between normal service behaviour and suspicious access patterns.

Map the test to MITRE ATT&CK so the results are meaningful to both technical teams and management. The relevant techniques will usually sit around Kerberos delegation abuse, credential access, and lateral movement. The exact mapping depends on the behaviour you are validating, but the important thing is to record the observed telemetry, the detection gap, and the business impact if that gap were exploited. If you are building a repeatable programme, our article on mapping detections and controls to MITRE ATT&CK is a good reference point.

How to reduce or remove the risk

The best outcome is usually to remove unconstrained delegation altogether. Start with the hosts that are easiest to change and the ones that have the highest exposure. If a server no longer needs delegation, disable it and validate the application before and after the change. If the application does need delegation, move it to constrained delegation or resource-based constrained delegation where possible.

Where removal is not immediately possible, reduce the blast radius. Limit who can log on to the delegated host, restrict local administrator access, and ensure privileged users do not use it for routine work. Segment the host so that it cannot freely reach unrelated internal systems. Strengthen monitoring around the host and the accounts that authenticate to it. These compensating controls do not make the risk disappear, but they can materially reduce the chance that a compromise becomes a domain-wide incident.

It is also worth reviewing whether the host is running on an operating system or application stack that is already difficult to support. Legacy systems often keep old delegation settings because nobody wants to break them. In those cases, the right answer may be a planned replacement rather than a series of temporary exceptions. That is a business decision as much as a technical one, because the cost of maintaining a risky dependency can exceed the cost of modernising it.

Operational considerations for UK SMEs

For smaller organisations, the main challenge is usually ownership. Identity, infrastructure, and detection engineering are often split across a small team or even handled by the same people. That means testing unconstrained delegation should be treated as a coordinated exercise, not a one-off scan. You need someone who understands the directory, someone who can interpret application dependencies, and someone who can confirm whether the telemetry is actually being collected.

There is also a practical trade-off between legacy support and attack surface reduction. Some UK SMEs run line-of-business systems that were designed long before modern identity hardening became normal. In those environments, the objective is not perfection. It is to understand which exceptions are truly required, which can be retired, and which need compensating controls until they can be replaced. That is a sensible approach for organisations that need to keep services running while improving security in stages.

If you are already using a broader security testing programme, this topic fits well into a regular abuse-case review. It sits alongside other identity and privilege tests, and it benefits from the same discipline around scope, evidence, and remediation tracking. A useful way to frame it is to ask whether the current configuration still matches the business need, and if not, how quickly it can be changed without creating operational instability.

A practical testing checklist

Before the test, confirm the scope, the change window, and the systems that may be affected. Identify the delegated hosts, the service owners, the domain administrators or infrastructure owners who need to be informed, and the logging sources you expect to review. Make sure you have a rollback plan if a configuration change is part of the test.

During the test, capture the directory attributes, the BloodHound graph output, the relevant Kerberos events, and any endpoint telemetry that shows host activity. Keep notes on what was expected, what was observed, and whether the detection logic behaved as intended. If an alert fired, record whether it was actionable or noisy. If nothing fired, record the exact gap so it can be addressed.

After the test, update the remediation tracker with ownership, priority, and target dates. If unconstrained delegation is still required, document the business justification and the compensating controls. If it can be removed, validate the application after the change and confirm that the telemetry still gives you enough visibility. This is where good evidence handling matters, because the value of the test is not just the finding itself, but the ability to show what was checked and what changed as a result.

Testing for Kerberos unconstrained delegation abuse in Active Directory is ultimately about reducing hidden trust. The configuration is easy to overlook, but it can create a serious identity risk if it sits on a host that privileged users touch. A focused, defensive assessment will tell you where the exposure is, whether your detections are good enough, and what can be removed without disrupting the business. If you would like help turning that into a practical testing plan, speak to a consultant.

Frequently asked questions

What is unconstrained delegation in Active Directory?

It is a Kerberos delegation model where a trusted host can receive and cache user service tickets, which can create a significant risk if that host is compromised.

How do you detect unconstrained delegation abuse without creating disruption?

Use a controlled test plan in a lab or approved change window, then look for directory flags, Kerberos ticket activity, and endpoint telemetry that shows unusual access to the delegated host.