Hello All,
In this post we will discuss on how to perform Resource-Based Constrained Delegation (RBCD) attack from an Linux machine as an attacker machine. RBCD attacks is already been explained in detailed by Will Schroeder, Elad Shamir & Dirk-jan Mollema in their blog posts.
What is Resource-Based Constrained Delegation (RBCD) ?
In Windows Server 2012 Microsoft introduced a new type of delegation wherein the Service Administrators or Owner of the resources are allowed to configure which accounts are trusted to delegate to them. As per the Microsoft Docs this can also be configured across the domains.
This also shifts the decision of whether a server should trust the source of a delegated identity from the delegating-from domain administrator to the resource owner.
Access is controlled by the security descriptor on the target resource instead of an list of SPN records. The security descriptor are stored in msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the target resource that is like a series of binary bytes.
RBCD Abuse Scenario
This scenario used in one of our Upcoming Lab - Blue Team Lab. In Active Directory environment every domain joined machine has an associated machine/computer account that usually ends with $ sign. Machine accounts also have a password associated that is changed by default every 30 days (Note - Machine account password policy can be changed). So let's assume that we have a valid domain account that can be used to query the active directory. While enumerating the domain we found that the current machine account has GenericWrite access on another machine in the environment.
Access / Permissions needed to perform the attack
1. Control over an object which has SPN configured (ideally admin access to a domain joined machine) or ability to add a new machine account to the domain.
2. Write permission over the target computer.
Steps to perform RBCD attack
You might be wondering that if we have already gain access to the windows machine then why do we need to perform the attack from Linux machine. We could directly use Rubeus toolkit to perform RBCD attack. It is because that we wanted to explore the option of performing RBCD attack using Linux machine and understand how the Impacket toolkit be used.
To Perform RBCD attack from Linux machine we will be using scripts from the Impacket toolkit and a modified version of the rbcd-attack script which was initially developed by an0n. The rbcd-attack script currently didn't support the use of LM:NT hash. So we modified the script and added support for Password or LM:NT and modified it to use NTLM authentication instead of Simple.
Note:- I wrote this post a few months ago. Meanwhile, an0n also update the rbcd-attack script.
The script can be found on the github repo.
Step 1: We need to first add/create a dummy computer in the domain. To add/create a dummy computer in the domain we will use addcomputer.py script from Impacket toolkit (Note - By default any domain user can add upto 10 computer accounts in the domain. To read more about MachineAccountQuota (MAQ) read the blog post from Kevin Robertson).
Step 2: We need to add the security descriptor to the newly created computer account to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the target computer. To do this we will use our modified script of rbcd-attack.
Step 3: Now we need to get the impersonated service ticket of the domain admin user. We will use getST.py script from Impacket toolkit to request the service ticket from the domain admin user.
Step 4: Once we fetch the impersonated service ticket it will be stored with the domain username and contain the extension .ccache in the current directory. eg:- administrator.ccache. Now we need to set the path of administrator.ccache to KRB5CCNAME variable. This variable holds the Kerberos ticket which can be used to perform kerberos related operations.
Step 5: Now as we have the kerberos ticket of the domain admin user we can use impacket-secretsdump from Impacket toolkit to dump the credentials from the machine.
Detection
To detect the Resource-Based Constrained Delegation Attack & Credentials Extraction using impacket-secretsdump tool from Impacket toolkit we need to enable few logs on the Domain Controller before emulating the attack. In our Lab we have already enabled those logs. But you can follow the below mentioned steps to enable the logs in your environment.
Set the System Access Control List (SACL) permissions to monitor any modification to msDS-AllowedToActOnBehalfOfOtherIdentity attribute. We will use the PowerShell code to set the SACL value on all the Computer Objects in the Domain Environment to monitor for any modification on any attributes of the Computer Objects.
# Import Active Directory Module
Import-Module ActiveDirectory
# Get the DistinguishedName of each computer in the Active Directory
$Computers = Get-ADComputer -Filter * -Properties DistinguishedName
$AD = 'AD';
foreach($Computer in $Computers)
{
$objDN = $Computer.DistinguishedName
$Path = $AD + ':\' + $objDN;
$SamAccountName = 'Everyone';
$sid = New-Object System.Security.Principal.NTAccount($SamAccountName);
# Get the Current ACL
$ACL = Get-Acl -Path $Path;
# Set the SACL rule for WriteProperty
$ACE = New-Object System.DirectoryServices.ActiveDirectoryAuditRule($sid,[System.DirectoryServices.ActiveDirectoryRights]::WriteProperty,1)
# Add the SACL to the current ACL
$ACL.AddAuditRule($ACE)
# Set the ACL
Set-Acl $Path $ACL
}Once we run the above PowerShell script we need to enable event logs that will generate events when any Computer Object attributes are modified.
To Capture the Directory Service Change Events we need to enable the "Audit Directory Service Changes" logs. Follow the below steps to enable the Logs.
1) Login to Domain Controller
2) Open Group Policy Management Console
3) Expand the Domain Object
4) Expand the Group Policy Objects
5) Right click on the Default Domain Policy and click on Edit (The policy that is applied to all the domain computers. It may differ in your environment)
6) Follow the below path to enable Audit Logon events.
Computer Configuration --> Windows Settings --> Security Settings --> Advanced Audit Policy Configuration --> Audit Policies --> DS Access --> Audit Directory Service Changes
7) Select "Configure the following audit events:", "Success" & "Failure" Checkbox
We also need to enable logs that will help us to detect the usage of getST.py script from Impacket toolkit to request the service ticket & impacket-secretsdump from Impacket toolkit to dump the credentials.
To Capture the Kerberos Service Ticket request Events we need to enable the "Audit Kerberos Service Ticket Operations" logs. Follow the below steps to enable the Logs.
1) Login to Domain Controller
2) Open Group Policy Management Console
3) Expand the Domain Object
4) Expand the Group Policy Objects
5) Right click on the Default Domain Policy and click on Edit (The policy that is applied to all the domain computers. It may differ in your environment)
6) Follow the below path to enable Audit Logon events.
Computer Configuration --> Windows Settings --> Security Settings --> Advanced Audit Policy Configuration --> Audit Policies --> Account Logon --> Audit Kerberos Service Ticket Operations
7) Select "Configure the following audit events:", "Success" & "Failure" Checkbox
To Capture the File Share Events we need to enable the "Audit Detailed File Share" logs. Follow the below steps to enable the Logs.
1) Login to Domain Controller
2) Open Group Policy Management Console
3) Expand the Domain Object
4) Expand the Group Policy Objects
5) Right click on the Default Domain Policy and click on Edit (The policy that is applied to all the domain computers. It may differ in your environment)
6) Follow the below path to enable Audit Logon events.
Computer Configuration --> Windows Settings --> Security Settings --> Advanced Audit Policy Configuration --> Audit Policies --> Object Access --> Audit Detailed File Share
7) Select "Configure the following audit events:", "Success" & "Failure" Checkbox
In our lab we are using HELK setup to parse and query the logs and winlogbeat to push the logs from the individual systems to the HELK instance.
Detect Resource-Based Constrained Delegation
While performing Resource-Based Constrained Delegation there are 2 Important Events that are generated.
1) Creation of new computer account (Note: If the attacker already owns a computer and has privileges to extract the credentials then the attacker can use the same computer to abuse RBCD. There is no need to create a new computer account.)
2) msDS-AllowedToActOnBehalfOfOtherIdentity attribute modification.
Now, let's run the below query to detect new computer account creation event.
event_id : 4741 and log_name : "Security"
Now, let's run the below query to detect msDS-AllowedToActOnBehalfOfOtherIdentity attribute modification event.
event_id : 5136 and log_name : "Security" and dsobject_attribute_name : "msds-allowedtoactonbehalfofotheridentity"
Now, let's run the below query to detect kerberos service ticket request.
event_id : 4769 and log_name : "Security" and user_name : "rbcd$@oil.crude.corp"
Detect the usage of impacket-secretsdump credential extraction tool
Let's run the below query to detect the usage of impacket-secretsdump from Impacket toolkit.
event_id : 5145 and log_name : "Security" and share_relative_target_name : ("winreg" or "system32" or "svcctl")
Mitigation
There are several way to mitigate or reduce the attack surface.
1. Add the privilege accounts(Domain Admins, Enterprise Admins, Schema Admins etc) to Protected Users group.
2. All the privilege accounts should be set as Account is sensitive and cannot be delegated
References
Feel free to provide me the feedback on twitter @chiragsavla94
Thanks for reading the post.
Special thanks to all my friends who help / supported / motivated me for writing blogs. 🙏
Posted by:
Chirag Savla
Senior Security Researcher at AlteredSecurity
Also published at 3xpl01tc0d3r.