Port 464 – kpasswd (Kerberos Set/Change Password)

Port 464 is the default port for the Kerberos Set/Change Password protocol (kpasswd) — the service a client talks to when it changes its own Kerberos password, and the one a privileged principal uses to set someone else’s without knowing the old one. It rides alongside the Key Distribution Center: every Active Directory domain controller listens on 464, and so do MIT krb5 and Heimdal KDCs running kpasswdd/kadmind. On its own, kpasswd is not a remote-code-execution service — but in a domain it’s the lever that turns “I have write rights over this account” into “I own this account’s password,” which is why it shows up in the middle of so many Active Directory attack chains.

Why It’s Open

kpasswd is a mandatory companion to Kerberos, so wherever Kerberos authentication runs on port 88 you’ll find 464 open right next to it. Active Directory exposes it on every domain controller so that domain users can change expiring passwords and administrators can reset forgotten ones. The behaviour is defined by RFC 3244 (“Microsoft Windows 2000 Kerberos Change/Set Password”), which adds the set-password operation that lets a privileged account set a target’s password directly. On UNIX realms the same port fronts MIT krb5 and Heimdal password changes. nmap fingerprints the service as kpasswd5. Because only domain controllers and KDCs normally answer on 464, an open port here — alongside LDAP on 389, LDAPS on 636, and SMB on 445 — is one of the cleaner ways to confirm you’re looking at a DC.

Common Risks

• Password reset as an attack primitive. This is the main event. If an attacker holds GenericAll, AllExtendedRights, or User-Force-Change-Password over a target — often gained after a coerced-auth relay, RBCD, or a captured ACL — they can set the victim’s password to a value they know and log in as them. kpasswd on 464 is one transport for this; SAMR over RPC/445 and LDAP over 636 reach the same primitive.
• Password spraying and credential validation. kpasswd requires a valid Kerberos exchange, so a self-change attempt validates a username/password pair without touching the login event stream the same way a normal logon would.
• Denial of service on MIT/Heimdal. Older MIT krb5 kadmind mishandles forged UDP packets on 464, letting an attacker set up a “ping-pong” loop between two kpasswd servers (CVE-2002-2443).
• Weak / legacy encryption. Realms that still accept RC4/DES make every credential attack that touches Kerberos cheaper, and reduce the effort needed to abuse older kpasswd (v1) exchanges.
• Over-broad reset rights. The riskiest configurations aren’t bugs at all — they’re accidental ForceChangePassword edges on privileged users and service accounts that nobody audited. BloodHound surfaces exactly these paths.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and confirm the domain controller

nmap -sV -p 464 <target>

nmap labels the service kpasswd5. Seeing 464 open next to 88, 389, and 445 is a strong tell that the host is a domain controller.

Change your own password (native MIT client)

kpasswd user@DOMAIN.LOCAL

The MIT kpasswd client speaks directly to port 464 and is the quickest way to prove the service is live and accepts a valid Kerberos exchange.

Change a password over kpasswd with Impacket (current password known)

impacket-changepasswd 'DOMAIN.LOCAL/user:CurrentPass'@<dc-ip> -newpass 'NewPass123!' -protocol kpasswd

changepasswd.py supports four transports — kpasswd, rpc-samr, smb-samr, and ldap; only -protocol kpasswd actually talks to port 464.

Force-reset another user’s password (delegated rights)

impacket-changepasswd 'DOMAIN.LOCAL/victim'@<dc-ip> -altuser attacker -altpass 'AttackerPass' -newpass 'NewPass123!' -reset -protocol kpasswd

-reset performs a set rather than a change: no knowledge of the victim’s current password, only reset rights on the -altuser account.

Same primitive over SAMR / LDAP (ports 445 / 636)

# Samba rpcclient — MS-SAMR over RPC (445)
rpcclient -U 'DOMAIN/attacker%AttackerPass' -c 'setuserinfo2 victim 23 NewPass123!' <dc-ip>

# net rpc — MS-SAMR over RPC (445)
net rpc password victim 'NewPass123!' -U 'DOMAIN/attacker%AttackerPass' -S <dc-ip>

# bloodyAD — binds over LDAP (636)
bloodyAD --host <dc-ip> -d DOMAIN.LOCAL -u attacker -p 'AttackerPass' set password victim 'NewPass123!'

There is no dedicated Metasploit or nmap NSE module for kpasswd itself — the Kerberos user-enumeration script krb5-enum-users runs against port 88, not 464. The password-set attacks all go through Impacket or native domain tooling. Log every account you reset and every set of working credentials so it lands in the final pentest report instead of a scratch file.

What to Look For

Known CVEs and Exploits

kpasswd has very little service-specific CVE history — the real risk on port 464 is the abuse of a legitimate feature (privileged password set), which no patch removes. The one clearly kpasswd-scoped vulnerability of note is a denial of service:

• CVE-2002-2443 — schpw.c in the kpasswd service in kadmind in MIT Kerberos 5 before 1.11.3 doesn’t validate UDP packets before replying, so a spoofed packet can trigger a communication loop between two kpasswd servers — a classic UDP “ping-pong” DoS that burns CPU and bandwidth (CVSS v2 5.0, MEDIUM; CWE-20). Fixed upstream in krb5 commit cf1a0c4.

The high-impact activity on 464 is credential abuse, not a memory-corruption exploit. The KDC-side Active Directory bugs that do lead to domain admin — Zerologon, noPac (CVE-2021-42278/42287), and MS14-068 — live on the Kerberos port 88 page, not here; they were previously mislabelled against this port and are not kpasswd vulnerabilities.

Mitigation

• Restrict 464 to domain controllers and management ranges. No client outside AD replication and admin networks needs to reach the password-change service; a DC should never expose it to the internet.
• Enforce a strong password policy and add MFA on privileged accounts. kpasswd is only as strong as the password it sets; long, complex passwords plus MFA on reset-capable and service accounts blunt takeover after a forced reset.
• Lock down reset rights (least privilege). Audit ForceChangePassword, GenericAll, and AllExtendedRights ACLs with BloodHound and remove edges that let low-privileged principals set high-value passwords.
• Monitor for anomalous password sets. Alert on Windows event 4724 (privileged account password reset) and 4723 (user-initiated change), especially bursts or resets of admin/service accounts with no matching helpdesk ticket.
• Enforce AES and disable RC4/DES across the realm so kpasswd and every adjacent Kerberos exchange run on strong crypto.
• Patch MIT krb5 / Heimdal. Stay past 1.11.3 to close CVE-2002-2443, and keep KDC packages current for the port 88 bugs.

Real-World Example

The most common way port 464 shows up in a real engagement isn’t a CVE — it’s a BloodHound path. A tester lands a low-privileged foothold, runs BloodHound, and finds a ForceChangePassword edge from a group they’re in to a service account or an IT admin. With no exploit and no cracked hash, they run net rpc password (or changepasswd.py -reset) to set that account’s password to a value they choose, authenticate as the victim, and inherit its rights — often another link closer to Domain Admin. Because the “vulnerability” is a delegated permission working exactly as designed, patching does nothing: the only fixes are pruning the ACL and watching for the 4724 reset event it generates. It’s the cleanest illustration of why kpasswd matters — 464 is where an access-control mistake becomes an authentication takeover.

FAQ

What is port 464 used for?

Port 464 carries the Kerberos Set/Change Password protocol (kpasswd). Clients use it to change their own Kerberos/Active Directory password, and privileged accounts use it to reset another user’s password without knowing the old one. Every AD domain controller and MIT/Heimdal KDC listens on it.

Is port 464 TCP or UDP?

Both. kpasswd is registered on TCP and UDP 464, and clients use either depending on the implementation and payload size. Firewall rules and scans should cover both protocols — the CVE-2002-2443 ping-pong DoS, for instance, is a UDP-only issue.

What service runs on port 464?

The Kerberos password-change service, kpasswd. nmap fingerprints it as kpasswd5. On Windows it’s part of Active Directory; on UNIX it’s fronted by MIT krb5’s kadmind/kpasswdd or by Heimdal.

Can port 464 be exploited?

Not as a memory-corruption target in the usual sense — its main abuse is legitimate functionality: an attacker with reset rights (ForceChangePassword / GenericAll) sets a victim’s password via kpasswd or SAMR and takes over the account. The one service-specific CVE is CVE-2002-2443, a UDP ping-pong denial of service on older MIT krb5.

How do I change or reset a Kerberos password on port 464?

To change your own, use the native kpasswd user@REALM client or changepasswd.py -protocol kpasswd. To reset another account (with the rights to do so), use changepasswd.py -reset, net rpc password, or rpcclient setuserinfo2. A self-change proves the port is live; a reset is only possible with delegated permissions.

How do I secure or close port 464?

You can’t close it on a domain controller — Active Directory needs kpasswd. Instead, firewall 464 to management ranges, enforce least privilege on password-reset ACLs, require strong passwords plus MFA on privileged accounts, monitor events 4724/4723, disable RC4/DES, and patch krb5.

TL;DR

• Service: kpasswd — Kerberos Set/Change Password (RFC 3244); nmap shows it as kpasswd5
• Default port: 464 TCP/UDP (companion to Kerberos on 88)
• Biggest risk: privileged password reset as an AD takeover primitive (ForceChangePassword / GenericAll) — abuse of a legitimate feature, not a patchable bug
• Service CVE: CVE-2002-2443, a UDP ping-pong DoS on MIT krb5 kadmind before 1.11.3
• Mitigation: firewall to DCs/management, least-privilege reset rights, strong passwords + MFA, monitor events 4724/4723, enforce AES, patch krb5