Thotcon 2025

Breaking the Vault: Exploiting Flaws in Credential Management Systems

Credential vaults play a critical role in modern enterprise defense rotating high-value passwords, managing access, and logging activity. But they often assume that controlling the credential = controlling the access.

That assumption is wrong.

This post details how an attacker can persist in a network long after a vault rotates a password, by abusing Kerberos TGTs, security tokens, and live sessions that the vault never touches.

The Core Problem

Credential vaults are great at updating passwords in Active Directory or other stores. But they don’t handle what happens next such as:

• Revoke active Kerberos tickets
• Kill existing access tokens
• Terminate live sessions
• Monitor session-based persistence

So while the vault UI logs "success," the attacker is still inside.

What Actually Stays Alive

TGT (Ticket Granting Ticket)

• Issued during first login
• Default lifetime: 10 hours, renewable up to 7 days
• Used to request additional service tickets (e.g., CIFS, RDP, LDAP)
• Not revoked or invalidated when a password is rotated

Tools like klist, mimikatz, and Rubeus can list and reuse TGTs silently.

Security Access Tokens

• Created during login; contain:
  • User SID
  • Group membership
  • Privileges (e.g., local admin)
• Valid until:
  • Logoff
  • Process termination
  • System reboot
• Password rotation does not impact token validity

This means a stolen token (or running session) grants continued access even if the vault "rotated" the account.

Exploitation Flow

A typical real-world flow:

1. Attacker gains access to a vaulted account
2. Logs in → gets TGT and access token
3. Vault rotates the password
4. Attacker still has:
   • Active session (e.g., RDP, PsExec)
   • Cached token
   • TGT to request new tickets
5. Continued access with zero alerts

Even though the vault logs a clean credential rotation, the attacker’s session remains untouched.

Post-Exploitation in This Gap

Once in this gap, after the vault rotates the password but before sessions/tickets/tokens expire, the attacker is effectively operating out-of-band.

Here’s what’s possible:

• RDP persistently using the original session
• Use PsExec, WMI, or PowerShell Remoting from the same security context
• Spawn child processes using the original access token (CreateProcessWithToken)
• Reuse the Kerberos TGT to request new service tickets (CIFS, LDAP, SMB, etc.)
• Enumerate the domain, move laterally, or re-implant silently without triggering new login events

But it gets worse...

Full Account Hijack via AD Module

If the attacker has access to PowerShell module and sufficient privileges, they can:

Set-ADAccountPassword -Identity "svc_account" -NewPassword (ConvertTo-SecureString "NewP@ssw0rd!" -AsPlainText -Force)

This forcefully changes the password without using the vault interface which completely bypassing any vault tracking or rotation logic.

Result:
The attacker now fully owns the account:

• Can authenticate with the new password
• Vault still believes it has ownership
• Security controls are out of sync
• Blue team visibility is broken

This isn’t just persistence. it’s a complete hijack, executed quietly from inside a post-ex session.

Defensive Control: Logon Session Cleanup After Vault Rotation

One of the key gaps in vaulting systems is that they rotate credentials, but leave sessions alive. This creates a dangerous mismatch where:

• Vault shows “password rotated successfully”
• But attackers remain active through stolen tokens, Kerberos tickets, or live RDP/WinRM sessions

To close this gap, defenders should implement automated logon session cleanup after each password rotation.

Goal

Terminate interactive or service logon sessions for vaulted accounts immediately after password rotation, ensuring that stale access is removed.

Implementation: PowerShell Script + Scheduled Trigger

Step 1: Script — Remove-LogonSession.ps1

param (
    [string]$TargetUser
)

if (-not $TargetUser) {
    Write-Host "[-] No username provided."
    exit 1
}

# Normalize username format
$NormalizedUser = $TargetUser.ToLower()

# Get interactive sessions via `quser`
$quserOutput = quser 2>$null
if (-not $quserOutput) {
    Write-Host "[!] No interactive sessions found."
    exit 0
}

foreach ($line in $quserOutput) {
    if ($line -match "^\s*(\S+)\s+($NormalizedUser)\s+") {
        $sessionId = ($line -split '\s+')[2]
        try {
            logoff $sessionId /V
            Write-Host "[+] Terminated session ID $sessionId for $TargetUser"
        } catch {
            Write-Host "[-] Failed to terminate session $sessionId: $_"
        }
    }
}

Step 2: Configure Scheduled Task Trigger

This script should be triggered immediately after a password rotation occurs.

Trigger from Your Vault

If you use a platform like CyberArk, or HashiCorp Vault, configure a post-rotation script hook to run:

powershell.exe -ExecutionPolicy Bypass -File "C:\Scripts\Remove-LogonSession.ps1" -TargetUser "DOMAIN\\svc_account"

Summary

Password rotation ≠ access revocation.

Vaults don’t kill sessions or tokens, you have to.

Automating session cleanup closes a critical blind spot in post-exploitation defense and ensures that rotation means what it says: the end of access.