Introduction

Active Directory (AD) password management has always been a critical attack surface for red teamers and penetration testers. The ability to forcibly reset a domain user’s password — without knowing the original — can be a gamechanger during lateral movement or privilege escalation phases of an engagement.

The Impacket toolkit, a cornerstone of modern offensive security, introduced a dedicated utility called impacket-changepasswd. This tool provides a unified, flexible interface for changing or resetting Active Directory account passwords through multiple authentication methods and protocols.

Table of Contents

• Introduction
• Lab Setup
• Configuring Reset Password ACE
• ForceChangePassword (FCP)
• Forced Password Reset (Account Takeover)
• Credential Validation (NetExec)
• Pass-the-Hash Password Reset
• Default Protocol (DCE/RPC)
• SMB-SAMR Protocol
• RPC-SAMR Protocol
• LDAP Protocol
• Kpasswd (Kerberos)
• NT Hash Password Set (-newhashes)
• AES Key Authentication (-aesKey)
• Kerberos TGT Cache (-k)
• Detection & Defense
• Conclusion

This article dives deep into the full spectrum of impacket-changepasswd capabilities, covering the lab setup, all supported authentication modes, multi-protocol support, hash-based password changes, and Kerberos-based resets — with real command outputs from a live lab environment

Lab Setup

To begin with, in this lab setup, we will create two users’ hulk and natasha , and will assign natasha user “Reset Password” rights for hulk User. To clarify, here’s how the lab environment will be set up:

Two domain users are created via an elevated command prompt on the Domain Controller:

net user hulk Password@1 /add /domain
net user natasha Password@1 /add /domain

Configuring ACE: Granting ‘Reset Password’ Permission

The key to the ForceChangePassword (FCP) attack is that natasha must have the Reset Password ACE granted on hulk’s AD object. This is configured via Active Directory Users and Computers (dsa.msc):

• Open dsa.msc and navigate to the hulk user object
• Right-click hulk > Properties > Security tab
• Click Add and enter natasha
• Select natasha (IGNITE\natasha) in the list
• Check Allow > Reset password > Apply > OK

What is ForceChangePassword?

The Reset Password permission (DS-Force-Change-Password extended right) in Active Directory allows a principal to forcibly reset another user’s password without needing to know the current password. This is commonly abused in post-exploitation scenarios when AD ACL misconfigurations are discovered.

Forced Password Reset (Account Takeover)

This command abuses the ForceChangePassword privilege — a Windows ACL right that allows a user to reset another user’s password without knowing the current one. Here, user natasha (who has this right over hulk) is used as the alternate authenticator (-altuser/-altpass) to forcibly reset hulk’s password to NewPass123

impacket-changepasswd 'ignite.local/hulk@192.168.1.11' -altuser natasha -altpass Password@1 -newpass 'NewPass123' -reset

Key Points:

• The attacker does NOT know Hulk’s original password
• Instead, they authenticate as another user: natasha
• Natasha has sufficient privileges (Reset Password rights) over Hulk

Action Performed:

• Password of hulk is forcibly changed to: NewPass123
• This is done using the -reset flag, which bypasses the need for the old password

Result:

• Password reset is successful
• Hulk’s account is now effectively taken over

Credential Validation via NetExec (nxc)

This uses NetExec (nxc) to verify the newly set credentials against LDAP on the domain controller (192.168.1.11). The [+] result confirms the password was successfully changed and is now valid.

nxc ldap 192.168.1.11 -u hulk -p NewPass123

Password Reset via Pass-the-Hash

Instead of supplying natasha’s plaintext password, the attacker uses her NTLM hash (:64FBAE31CC352FC26AF97CBDEF151E03) directly. The colon prefix (:hash) is the standard Impacket format for passing the NT hash portion. This is classic Pass-the-Hash — authenticating without ever cracking the password.

impacket-changepasswd 'ignite.local/hulk@192.168.1.11' -altuser natasha -althash :64FBAE31CC352FC26AF97CBDEF151E03 -newpass Ignite@987 -reset

Default Protocol (DCE/RPC)

here the administrator is changing their own password. The attacker already knows the administrator’s current password (Ignite@987) — likely obtained through a prior attack in this chain (e.g., credential dumping or escalation via hulk) — and is now rotating it to Ignite@123.

impacket-changepasswd ignite.local/administrator:Ignite@987@192.168.1.11 -newpass Ignite@123

Protocol: SMB-SAMR

The attacker is again changing the Domain Administrator’s password (this time from Ignite@123 → Ignite@9876), but now explicitly forces the MS-SAMR over SMB transport protocol.

smb-samr vs Default Behavior

smb-samr is actually the default protocol in impacket-changepasswd when no -protocol flag is given. So why specify it explicitly? It’s likely being demonstrated for educational/operational clarity, or to ensure the correct transport is used in an environment where the default might be overridden

impacket-changepasswd 'ignite.local/administrator:Ignite@123@192.168.1.11' -newpass Ignite@9876 -protocol smb-samr

Protocol: RPC-SAMR

The administrator’s password is changed from Ignite@9876 → Admin@1234 using MS-SAMR over MS-RPC (TCP/135 + dynamic ports) instead of the SMB named pipe.

Why This Works Despite Documented Limitations

The Impacket documentation notes that rpc-samr cannot use hSamrSetInformationUser to reset passwords (forced change without knowing the current one). However, this is a self-change — the administrator authenticates with the current password and calls SamrUnicodeChangePasswordUser2, which works over RPC-TCP since it doesn’t require a pre-opened user handle. That’s why it succeeds here.

impacket-changepasswd 'ignite.local/administrator:Ignite@9876@192.168.1.11' -newpass Admin@1234 -protocol rpc-samr

Protocol: LDAP

Password is changed from Admin@1234 → Password@1234 using LDAP Extended Operation (RFC 3062) directly over port 389

impacket-changepasswd 'ignite.local/administrator:Admin@1234@192.168.1.11' -newpass Password@1234 -protocol ldap

This is unique to the LDAP protocol — it operates directly on the AD directory object and confirms the exact DN of the modified entry. The smb-samr and rpc-samr protocols operate through SAMR RPC calls and don’t return DN information

Protocol: Kpasswd

This changes the administrator’s password from Password@1234 → Ignite@12345 using the Kerberos kpasswd protocol (RFC 3244). Unlike all previous protocols, this one operates exclusively over UDP/TCP port 464 — the dedicated Kerberos password change port on every Domain Controller.

impacket-changepasswd 'ignite.local/administrator:Password@1234@192.168.1.11' -newpass Ignite@12345 -protocol kpasswd

Setting Password via NT Hash (-newhashes)

Rather than supplying a new plaintext password, impacket-changepasswd supports directly setting a new NT hash — extremely useful for maintaining stealthy access or establishing a backdoor hash without touching a plaintext password in logs.

impacket-changepasswd ignite.local/administrator:Ignite@12345@192.168.1.11 -newhashes DA2B50494B7EC063A673F151CA68A2D0

Why This Is Exceptionally Dangerous

Under the hood, this calls SamrSetInformationUser / SamrChangePasswordUser with raw hash values, bypassing all password complexity checks and policy validation. You can set a hash that corresponds to any password — even one that wouldn’t meet the domain’s length or complexity requirements — because no plaintext is ever submitted for validation

Using AES Key (-aesKey)

This technique is known as Pass-the-Key (PtK) — a Kerberos variant of Pass-the-Hash that uses the raw AES pre-authentication key, making it stealthier since it generates valid Kerberos tickets rather than NTLM authentication events.

If the administrator’s AES-128 or AES-256 key is known (e.g., extracted from the NTDS.dit or via dcsync), it can be used directly:

impacket-changepasswd 'ignite.local/administrator@DC.ignite.local' -k -aesKey eae5c8006cd744446115d2eab39d9f8f -newpass Ignite@123 -dc-ip 192.168.1.11 -protocol ldap -reset

Using Kerberos TGT Cache (-k without -aesKey)

When a valid TGT already exists in a ccache file (obtained via getTGT, rubeus, or similar tools), the -k flag will use it directly:

The -k flag tells Impacket to use Kerberos — and since KRB5CCNAME is set, it automatically picks up the TGT from the ccache file without needing any password, hash, or AES key. No -aesKey or -hashes flag is needed at all.

export KRB5CCNAME=administrator.ccache

impacket-changepasswd 'ignite.local/administrator@dc.ignite.local' -k -newpass NewPassword123! -dc-ip 192.168.1.11 -protocol ldap -reset

Detection & Defense

Windows Event Log Detection

Defenders should monitor for the following Windows Security Event IDs:

• Event ID 4723 — An attempt was made to change an account’s password (user-initiated)
• Event ID 4724 — An attempt was made to reset an account’s password (admin or delegated reset)
• Event ID 4738 — A user account was changed (password change confirmed)
• Event ID 4771 — Kerberos pre-authentication failed (post-FCP AES key invalidity)
• Event ID 5136 — A directory service object was modified (ACE changes)

Defensive Recommendations

• Audit AD ACLs regularly: Tools like BloodHound, ADACLScanner, or PingCastle can identify over-permissive Reset Password ACEs
• Implement Tiered Administration Model: Separate high-privilege accounts and limit which accounts can reset passwords on sensitive objects
• Enable Protected Users Security Group: Members are forced to use Kerberos with AES encryption, and NTLM is blocked for these accounts
• Monitor SAMR traffic: Alert on unusual DCE/RPC or SMB SAMR calls to the domain controller, especially from workstations
• Deploy Credential Guard: Prevents NT hash extraction from LSASS memory on modern Windows systems
• LDAP Signing and Channel Binding: Enforcing LDAP signing prevents relay attacks that could be used as a stepping stone

Conclusion

impacket-changepasswd is a powerful and flexible tool that consolidates multiple AD password manipulation techniques into a single, well-structured interface. For red teamers, it provides an efficient means to exploit ForceChangePassword ACE misconfigurations, leverage pass-the-hash in delegated resets, operate across five distinct protocols, and maintain stealthy access via hash injection.

The progression from plaintext password authentication to NT hash-based pass-the-hash, then to AES key and TGT cache-based Kerberos operations, represents a comprehensive toolkit for nearly any engagement scenario — regardless of whether NTLM is blocked, whether the attacker has plaintext credentials, or whether they’re operating from a harvested credential store.

For defenders, the key takeaways are: audit your AD ACLs aggressively, monitor Event IDs 4723, 4724, and 4738 closely, enforce NTLM restrictions where possible, and deploy solutions like BloodHound or Microsoft Defender for Identity to detect anomalous password reset chains before they result in domain compromise.

Author: Kinjal Patel is seasoned penetration tester and technical content writer. Contact at LinkedIn