skip to content

Your Active Directory has one host with unconstrained delegation. How does that reorder ATT&CK techniques?

level: seniorimportance: nice to knowfreq 26%

answer

  1. the commoner technique is not the bigger one
  2. one flag on one computer object
  3. the host keeps whatever authenticates to it
  4. ordering is a function of your directory

basics

~20 s

It promotes a thinly evidenced technique over a heavily evidenced one. A host trusted for unconstrained delegation caches the Kerberos ticket of whatever authenticates to it, so coercing a privileged account there reaches the directory in one step.

solid answer

~50 s

Unconstrained delegation means that host receives a forwardable Kerberos ticket for every principal that authenticates to it and keeps it in memory, so whoever controls the host inherits those identities. Make a domain controller's computer account authenticate to it and you hold a ticket that reaches the directory itself. Forced Authentication (`T1187`) combined with Pass the Ticket (`T1550.003`) is not the most heavily evidenced pair in ATT&CK's procedure examples, but in this estate it is one step to the top. Meanwhile Kerberoasting (`T1558.003`), far better evidenced, yields nothing here if the service accounts are group-managed with auto-rotated random secrets, because there is no crackable material at the end of it. Neither technique page differs between the two estates. The whole ordering came from one attribute on one computer object, which is a fact the catalogue has no field to hold.

code

text · 13 lines
text
Estate fact (no catalogue holds this):
  FS-07$   userAccountControl: TRUSTED_FOR_DELEGATION   (unconstrained)

T1558.003  Kerberoasting                      heavily evidenced
   here: service accounts are group-managed, auto-rotated random secrets
   -> offline attack has no tractable end  ->  yields nothing

T1187 Forced Authentication + T1550.003 Pass the Ticket   thinly evidenced
   here: coerce a domain controller account to authenticate to FS-07,
         take the forwardable ticket it caches
   -> directory-wide privilege in one step

ATT&CK field able to express this difference: none exists

go deeper

for a junior

Know that a technique's prominence in published reports says nothing about what it reaches in your own network, and that ATT&CK stores no per-estate value at all.

for a middle

Explain the mechanism that flips the ordering: a host trusted for unconstrained delegation caches forwardable tickets for whatever authenticates to it, so control of that host means control of those identities.

for a senior

Demonstrate the full argument in an estate you have operated: name both techniques, name the attribute that inverts them, and show that varying the delegation model moves the ordering while both catalogue pages stay unchanged.

for a principal

Be prepared to say who is accountable for keeping the estate facts that drive your ordering current, because a ranking derived from a directory snapshot silently expires the next time someone flags a new server.

## The estate fact that does the work A computer account flagged for unconstrained delegation is trusted to act as any user who authenticates to it. In practice the authenticating principal's forwardable ticket-granting ticket is handed to that host and cached there, so control of the host is control of every identity that has touched it since it last restarted. That includes identities you would never deliberately expose to a file server. The adversary's move follows directly. Rather than wait for a privileged account to arrive, make one arrive: any mechanism that induces a remote machine account to authenticate outward will do, and a domain controller's own computer account is a legitimate target for that. The ticket lands in the delegating host's memory, and from there the directory itself is reachable. Two behaviours, one flag, one step. ## The two techniques, priced in this estate **Kerberoasting** (`T1558.003`) is one of the best-evidenced techniques in the catalogue. Any authenticated principal can request a service ticket for an account that carries a service principal name, and part of that ticket is encrypted with a key derived from the account's password, so it can be attacked offline at leisure. It is cheap, quiet, and requires only a domain account. In *this* estate it produces nothing. If those service accounts are group-managed with long auto-rotated random secrets, the offline attack has no tractable end. The technique still applies, still executes, still produces exactly the artefact it is supposed to produce, and the artefact is worthless. **Forced Authentication** (`T1187`) plus **Pass the Ticket** (`T1550.003`) is thinner in the procedure examples. In this estate, because of the delegation flag, it is the shortest path from an authenticated foothold to directory-wide privilege that exists. So the correct local ordering inverts the catalogue's apparent weight of evidence, and it does so on the strength of a single boolean on a single object. ## Why no field could ever hold this Imagine trying to store it. A severity number on the `T1187` page would have to be a function of the reader's directory: which principals are trusted for delegation, what authenticates to them, whether the paths are constrained, whether the privileged accounts are marked sensitive and cannot be delegated. That is not a property of the behaviour, it is a property of *your* configuration, and it changes the day someone adds a flag to a new file server. A catalogue of behaviours cannot carry a field whose value is computed from an estate it has never seen. This generalises past delegation. Change the estate attribute and the same argument runs again with different names: which accounts hold rights they never use, which credential is shared across trust boundaries, which one legacy protocol is still enabled for one application. The ordering is a function of configuration, and configuration lives nowhere near MITRE. ## What varying the estate does to the answer Constrained delegation narrows it: the host can impersonate to *named* services only, so coercion yields access to that service rather than to everything. Resource-based constrained delegation moves the decision to the target object, so the question becomes who can write the delegation attribute on it. Mark the privileged accounts as sensitive and not delegated, or put them in a protected group, and the ticket that arrives is not forwardable, which collapses the whole path. All three of those are edits to your directory. None of them is visible from a technique page. ## What a strong answer sounds like Name both techniques with identifiers, state the estate fact that flips them, and then say the part that the leaf is really testing: the ordering was produced by reading your own directory, not by reading the catalogue. Candidates who stop at "unconstrained delegation is bad, we should remove it" have given a correct hygiene answer to a different question. The question is why the rarer behaviour outranks the commoner one here, and the answer is that rarity in someone else's published reports was never evidence about your estate in the first place.

  • Would constrained delegation instead of unconstrained change your ordering?
    Yes. Constrained delegation limits impersonation to named services, so the same coercion reaches that service rather than the directory, and the technique drops back down the list. Resource-based constrained delegation shifts it again, to whoever can write the delegation attribute on the target object. The ordering moves with the estate every time.
  • Does this argument mean ATT&CK is useless for prioritising?
    No, it means the division of labour is different from what people assume. The catalogue supplies precise shared names and accurate behaviour descriptions; you supply the ordering. Being able to say T1187 into T1550.003 rather than "the delegation thing" is exactly what lets you argue the ordering with an architect who disagrees.
  • Kerberoasting still executes successfully here. Is it a false lead?
    It is a true observation with no consequence in this estate, which is a distinction worth stating carefully. The behaviour applies and works; the material it yields is not attackable in useful time. That is an estate-specific conclusion, and it flips back the moment one service account is created outside the managed scheme.

saying these in an interview costs you the question

  • Ranks techniques by how many procedure examples they carry
  • Assumes the commoner technique is the bigger risk here
  • Thinks a technique page could carry an estate-specific score
  • Treats unconstrained delegation as only a hygiene finding
  • Cannot say what makes the roasted ticket worthless here

context