WriteAccountRestrictions (WAR) – What is it good for?

What it is

WriteAccountRestrictions (WAR) is an Active Directory property set that includes rights to modify msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD) and UserAccountControl (UAC). The post, from unsigned-sh0rt.net, pairs the root-cause finding (already in the summary) with three reproducible attack chains and the exact commands used.

How it works

UAC is a cumulative bitwise attribute. A disabled computer account carries decimal value 4098 (4096 WORKSTATION_TRUST_ACCOUNT + 2 ACCOUNTDISABLE); subtracting 2 re-enables it. Chain for a disabled computer account with unconstrained delegation:

1. Re-enable via UAC: ldeep ldap ... change_uac "CN=..." 16781312
2. Reset its password twice (first reset, then a self-reset to regenerate valid AES keys): changepasswd.py ... -reset -newpass <pw>
3. Update the account's own DNS record to point at the attacker host (machine accounts control their own DNS record by default): dnstool.py -a modify -r <host> -d <attacker-ip>
4. Derive AES keys (aesKrbKeyGen.py) and run krbrelayx.py -aesKey ... to capture inbound TGTs when the host is coerced back.

For user objects, WAR's UAC-write grants targeted AS-REP roasting (add DONT_REQ_PREAUTH), reversible-encryption plaintext recovery (ENCRYPTED_TEXT_PWD_ALLOWED + PASSWORD_EXPIRED), and removal of the NOT_DELEGATED flag.

Preconditions / Affected

• WAR delegated at domain root (or any inherited container) to a domain-join service account — confirmed common via BloodHound Enterprise/Scentry data and traceable with BloodHound 8.0's new ACL-inheritance tracking.
• The disabled-account resurrection path requires the target also have an inbound ForceChangePassword ACE (not collected by stock BloodHound; author patched Dirk-jan's collector to parse it) and prior unconstrained delegation on the host.
• RBCD-to-SCCM path assumes default SeMachineAccountPrivilege for Authenticated Users and ms-DS-MachineAccountQuota ≥ 1, plus a known service-account-to-SQL mapping (e.g., SCCM site server holding the SA role in the site database).

What to do

• The Zerologon-chain PoC is released as SetZeroSync, which automates: zero the DC password, DCSync a domain admin via the zeroed DC, pull the DC's own password from LSA secrets using that admin hash, then restore it — a known-destructive sequence the author explicitly warns against running in production (EDR-visible, can brick the DC).
• RBCD-on-users path: add a machine account (addcomputer.py), write RBCD from it (rbcd.py -action write), request an impersonation ticket (getST.py -impersonate <target> -spn ...), then authenticate directly to the downstream service (shown against an MSSQL/SCCM database).
• Defensive steps stated: audit domain-root/broad WAR delegations and push to lowest-needed container; use a staging OU for OS deployment to stop retroactive inheritance; use a graveyard OU with inheritance disabled for retained disabled accounts.

Caveats

• UAC modification itself cannot force unconstrained delegation — that requires BUILTIN\Administrators or SeEnableDelegationPrivilege, closing off a more severe variant.
• Forcing a computer password change breaks the account's trust with its physical host (Netlogon never completes the final sync step), so this only works cleanly against accounts with no live host — BloodHound pathfinding for this is explicitly unfinished ("Soon™").
• SetZeroSync and the Zerologon chain were tested only in the author's lab, not in production.