When dealing with account lockouts that occur precisely every 5 minutes across multiple servers, we're typically looking at either a scheduled task or a service using cached credentials. The challenge intensifies when built-in auditing only reveals the lockout source servers (SERVER1 and SERVER2 in this case) without exposing the underlying process.

While ProcMon is a great starting point, we need deeper inspection for Kerberos-related activities. Here's a PowerShell snippet to monitor LSASS activity:

# Capture LSASS handles to credential objects
Get-Process lsass | ForEach-Object {
    $_.Modules | Where-Object {$_.ModuleName -like "kerberos*"} |
    Select-Object ModuleName, FileName, @{n="Process";e={$_.ProcessName}}
}

# Alternative: Use ETW tracing for Kerberos events
logman create trace "KerberosDebug" -ow -o kerberos.etl -p "Microsoft-Windows-Kerberos" 0xffffffffffffffff -ets
# Capture for 5 minutes then:
logman stop "KerberosDebug" -ets

The specific error code 0x18 translates to KDC_ERR_PREAUTH_FAILED, indicating the client couldn't prove identity during pre-authentication. Common causes include:

• Mismatched password between client cache and AD
• Incorrect AES encryption settings
• Time synchronization issues beyond normal thresholds
• Stored credentials in services or applications

Given the vpxd.exe connection, we should check vSphere's credential handling:

# Check vCenter services using domain accounts
Get-VIAccount | Where-Object {$_.Name -like "*DOMAIN*"} | Format-Table -AutoSize

# Review vSphere authentication logs
Get-LogType -Server vcenter01 | Where-Object {$_.Name -match "auth"} | Select-Object Name

Wireshark filtering for Kerberos traffic from suspect servers:

# Wireshark display filter for Kerberos AS-REQ failures
kerberos.msg_type == 10 && kerberos.error_code == 0x18

# To correlate with processes on Windows:
netstat -ano | findstr "61450"  # Port from error message

Sometimes remnants in credential manager cause issues. This PowerShell checks all credential stores:

# Enumerate all stored credentials
cmdkey /list | Where-Object {$_ -match "DOMAIN\\USER"}

# For system-wide credentials check:
$credMan = New-Object -ComObject Scripting.Signer
$credMan.Enumerate | Where-Object {$_.TargetName -like "*DOMAIN*"}

Verify domain account policies aren't conflicting with authentication attempts:

# Check account lockout and Kerberos policies
Get-ADDefaultDomainPasswordPolicy | Select-Object Lockout*

# Check specific user settings
Get-ADUser -Identity USER -Properties * | 
Select-Object msDS-User-Account-Control-Computed, PasswordLastSet

1. Isolate one suspected server at a time by temporarily disconnecting from network
2. On the DC, enable verbose Kerberos logging: Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters -Name "LogLevel" -Value 1
3. Use klist purge on all systems that might cache credentials for this account
4. Check for duplicate SPNs that might cause authentication confusion

After implementing fixes, monitor with this real-time query:

Get-WinEvent -LogName Security -FilterXPath '*[System[EventID=4771]]' -MaxEvents 10 | 
Where-Object {$_.Properties[0].Value -match "USER"} | 
Format-List *

---

When dealing with recurring account lockouts from specific servers showing Kerberos pre-authentication failures (error code 0x18), standard auditing often leaves us guessing. Here's how I approach these stealthy authentication attempts that don't show up in normal failure logs until lockout occurs.

The standard 4771 events only tell us about the final lockout, not the failed attempts leading up to it. We need deeper forensic tools:

# PowerShell to extract detailed Kerberos events
Get-WinEvent -LogName Security | 
Where-Object {$_.Id -eq 4771 -and $_.Message -like "*0x18*"} | 
Select-Object -First 10 | Format-List *

Since process monitors might miss the culprit, network packet analysis becomes crucial. Filter Wireshark for Kerberos traffic:

# Wireshark filter for Kerberos pre-auth attempts
kerberos.CNameString == "USERNAME" && kerberos.msg_type == 0x0A

The lsass.exe involvement suggests credential caching issues. Dump process memory for analysis:

procdump.exe -ma lsass.exe lsass.dmp
mimikatz # sekurlsa::minidump lsass.dmp
mimikatz # sekurlsa::tickets /export

When vCenter processes (vpxd.exe) are involved, check for:

• Stale service account credentials in vCenter
• Orphaned vSphere authentication sessions
• Java-based services using cached credentials

Enable verbose Kerberos logging on the DC:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v "LogLevel" /t REG_DWORD /d 0x1 /f

When standard tools fail, try these advanced methods:

# ETW tracing for Kerberos authentication
logman start KerberosTrace -p Microsoft-Windows-Kerberos -o kerberos.etl -ets
# Run until lockout occurs
logman stop KerberosTrace -ets

Create a PowerShell script to correlate events across servers:

$LockoutEvents = Get-WinEvent -ComputerName DC01 -FilterHashtable @{
    LogName='Security'
    ID=4740
    StartTime=(Get-Date).AddHours(-1)
}

$LockoutEvents | ForEach-Object {
    $Target = $_.Properties[0].Value
    $Source = $_.Properties[1].Value
    Write-Host "Account $Target locked out from $Source"
    
    # Get corresponding 4771 events
    $PreAuthEvents = Get-WinEvent -ComputerName DC01 -FilterHashtable @{
        LogName='Security'
        ID=4771
        StartTime=$_.TimeCreated.AddMinutes(-5)
        EndTime=$_.TimeCreated
    } | Where-Object {$_.Message -match $Target}
}

When you suspect cached credentials:

1. Terminate all existing Kerberos tickets with klist purge
2. Clear Windows credential manager entries
3. Restart the server if possible to clear any memory-resident credentials

After remediation, verify with real-time monitoring:

# Real-time event monitoring
Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4771)]]" -MaxEvents 10 -Wait