How to mitigate Active Directory attacks that use the KrbRelayUp toolset

Those of you with on-premises Active Directory (AD) need to be aware of a new way to abuse Kerberos in your network. KrbRelayUp is a bundle of tools that streamlines the use of some features in Rubeus, KrbRelay, SCMUACBypass, PowerMad/SharpMad, Whisker, and ADCSPwn. Attackers use the toolset to impersonate an administrator via resource-based constrained delegation and execute code on a device’s system account.

Pure Azure AD environments are safe from this attack, but hybrid AD networks with both on-premises AD and Azure AD will be at risk. If an attacker compromises an Azure virtual machine that is synchronized with on-premises active directory, the attacker will gain system privileges on the virtual machine and be able to make more advances inside the network.

Microsoft recommends you take the following actions:

Step 1: Block the attacker from using the first step of the attack sequence

While Microsoft uses the phrase, “organizations should consider” making certain settings, I’d use much stronger wording. I recommend your organization makes the following changes: Set the ms-DS-MachineAccountQuota attribute to “0”. This setting allows non-administrator users that are in the authenticated users group to add up to 10 workstations to the network. In this era of autopilot and other installation methodologies, users should not be adding workstations to the domain.

Instruct your AD administrators to use ASDI Edit MMC snap in (adsiedit.msc) and connect to the Domain Naming Context. Look for the value of “DC=” and your domain. Right-click on “Properties” and look for the value of ms-DS-MachineAccountQuota. You will see it at a value of “10”. Set the value to “0”.

Alternatively, you can set the value with Windows PowerShell. First, use Get-ADObject cmdlet to check the value:

Get-ADObject -Identity ((Get-ADDomain).distinguishedname) `

             -Properties ms-DS-MachineAccountQuota

The results should show you at what value the network is set.

Use the Set-ADomain command to set the value:

Set-ADDomain -Identity              -Replace @{"ms-DS-MachineAccountQuota"="0"}

Setting this at “0” stops the non-administrators from adding new devices to the domain and ensures that attackers can’t start with this and must use a harder technique to gain network access.

Step 2: Enable LDAP channel binding and LDAP signing

KB4520412 documents the next steps that have been recommended as a best practice for quite some time. Included in the March 10, 2020, updates are new events related to LDAP channel binding.

First enable additional logging to ensure that you can adjust LDAP and not have side effects. By now you should have the March 10, 2020, Windows updates installed on your domain controller. Next, enable LDAP events diagnostic logging to “2” or higher.

Add the following registry key to the domain to enable logging:

Reg Add HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

Look in the domain controller’s event viewer and in the “Applications and Services” logging and then under “Directory Service”. Review for LDAP signing and channel binding token events.

LDAP signing events include:

• Event 2886: The security of these domain controllers can be significantly improved by configuring the server to enforce validation of LDAP signing.
• Event 2887: The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing.
• Event 2888: The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing.
• Event 2889: The security of these domain controllers can be improved by configuring them to reject simple LDAP bind requests and other bind requests that do not include LDAP signing.

Channel Binding Token events include:

• Event 3039: The following client performed an LDAP bind over SSL/TLS and failed the LDAP channel binding token (CBT) validation.
• Event 3040: During the previous 24-hour period, unprotected LDAP binds were performed.
• Event 3041: The security of this directory server can be significantly improved by configuring the server to enforce validation of LDAP channel binding tokens.

Note that the update doesn’t enforce the settings. You need to make the changes to enforce LDAP signing as noted in ADV19023, but you’ll also want to review the following guidance:

• KB4520412: 2020 LDAP channel binding and LDAP signing requirement for Windows
• KB4034879: LDAP channel binding
• KB935834: LDAP signing
• KB4546509: Frequently asked questions about changes to Lightweight Directory Access Protocol

Once you enforce LDAP signing, Microsoft anticipates that you’ll have issues with LDAP clients that do not enable or support signing not connecting, and LDAP simple binds over non-TLS connections not working if LDAP signing is required. Microsoft also anticipates that when LDAP channel binding is enforced, LDAP clients that connect over SSL/TLS but do not provide CBT will fail if the server requires CBT. SSL/TLS connections that are terminated by an intermediate server that in turn issues a new connection to an Active Directory domain controller, will fail. Support for channel binding might be less common on third-party operating systems and applications than it is for LDAP signing.

As Microsoft notes, no changes will be made to your domain controller; you have to make the necessary changes.

Microsoft Defender for Identity and KrbRelayUp

If you have Microsoft Defender for Identity, it detects activity from the first steps of the KrbRelayUp attack sequence by monitoring behavior as seen by the domain controller. It first reviews for suspicious Kerberos delegation attempts by a newly created computer and then it reviews for suspicious edits of the resource-based constrained delegation attribute by a machine account.

Tracking down the number of LDAP client applications you have and their possible impact may take time, so change the logging and start reviewing what impact making this change will have on your network. Leaving this at the defaults could expose your domain to unnecessary attacks.