It’s been a while since I last posted, I’ve been busy with personal things, but I want to retake sharing things I know about Active Directory exploitation.

We’ll continue adding misconfigurations to our Active Directory environment, to further explore ACL exploitation paths.

We’ll add a new domain user, max.power in my case.

Additionally, I added a new host into the domain, making sure I’m using the max.power account for this action.

Since the newly created user is the one that added the new host to the domain, SOPORTE01, the account gets certain privileges over the machine object properties, even when it’s not a local administrator.

However, since we added the host through the Windows interface, the Domain Controller assigned a random highly complex password to the machine account, which is why we’re going to assume the compromise of the max.power user, where we’ll add a new host through the command line, where we’ll know the password for the machine account, where we’ll exploit an RBCD attack (Resource Based Constrained Delegation) from the new computer towards SOPORTE01 and then, from SOPORTE01 towards TECNOLOGIA01.

Additionally, for simplicity sake, we’ll add full control privileges to max.power over the SOPORTE01 host.

RBCD attack configuration.

We access the ADSI interface again on the DC, looking for the group Computers, right clicking in TECNOLOGIA01 and accessing the properties option.

We get the list of domain objects that have any level of privilege over this specific object.

We click on add and we’ll see the search box seen before, however, we need to perform an extra step here, where we’ll click on Object Types.

Inside the new window, we enable the Computers option and then click OK.

By default, machine accounts are not considered to grant privileges, but since we modified this behavior, we can write the hostname for one of the new hosts we created SOPORTE01 and click on Check Names.

The computer object was identified and we give it Full control privilege over the TECNOLOGIA01 object.

We’ll add the same privileges to the max.power user over the SOPORTE01 object.

Targeted Kerberoasting attack configuration.

Back in the ADSI interface, we’ll find the jsec user and modify it’s properties, giving it write privileges over the max.power user.

Confirming the privilege, we’re set for the targeted kerberoasting attack.

Sharphound usage from a non domain joined host

It’s possible to execute enumeration tools from within non domain joined hosts through legitimate windows binaries. This can be pretty useful during internal pentests/red team exercises where we have a single VPN connection or access to a single ethernet port and internal hosts are well protected (Well configured antivirus, EDR, AMSI enabled, unsigned binaries cannot be executed, restricted access to CMD, Powershell, rundll, etc.)

For this, we created a new windows host, EXTERNO01, which will not be added to the domain.

We download Sharphound from the following link:

https://github.com/BloodHoundAD/SharpHound/releases/download/v1.1.0/SharpHound-v1.1.0.zip

To be able to execute the binary, we can setup the DNS servers on our windows host, pointing towards the Domain Controllers.

We confirm the correct resolution of the jsec.local domain and the ATENCION01 host.

If we try to run the binary without any parameters, we’ll get an error stating we can’t connect to LDAP because of a credential related error.

Since we’re running the command from a non domain joined windows host using a local account, the credentials used to authenticate to the domain controller are the local ones, which are not valid in the jsec.local domain.

We can define credential objects as it was shown on the previous post to run Sharphound, but I prefer to spawn a new command line shell under a new user context, so I don’t have to reuse or create multiple credential objects to switch between users, so I use runas to spawn these new shells.

In this case, I use the runas binary to run a process as a different user, /netonly indicates that the network communication will use the defined user profile, /user defines the user to use and at the end you specify which process you want to run with these credentials.

It’s important to note that the user password must be introduced manually, but it won’t be validated before spawning the shell, so we need to make sure we use the correct password, otherwise our commands will fail because the authentication information sent by the terminal is wrong.

The new CMD window has a specific title (running as jsec.local\max.power), indicating that all the commands we execute will use this user’s context.

If we run Sharphound again from within this new console, we get a successful authentication attempt and obtain the required information.

Now we can analyze the generated files through Bloodhound

Using the Find shortest paths to Domain Admins query, we get the following result:

Some paths were already explored, but we find two new ones

The first indicates that the max.power user has GenericWrite privileges over the jsec user, confirming the possibility to execute a Targeted Kerberoast attack.

The second case indicates that the SOPORTE01 host has GenericAll privileges over the TECNOLOGIA01 host, allowing for a Resource Based Constrained Delegation attack.

However, we need to have the SOPORTE01 host’s machine account password or NTLM hash to be able to execute the RCBD attack, so by analyzing its Explicit Object Controllers, we find that max.power has GenericAll privileges over the host, so if we control the max.power user, we can perform both attacks.

EXPLOITATION – RBCD

Since max.power has complete control over the SOPORTE01 host, we can modify the msDS-AllowedToActOnBehalfOfOtherIdentity property.

According to Windows documentation.

“This attribute is used for access checks to determine if a requester has permission to act on behalf of other identities on services running as this account.”

Ref: https://docs.microsoft.com/en-us/windows/win32/adschema/a-msds-allowedtoactonbehalfofotheridentity

For the sake of simplicity, we will define this property as the ability of a domain host to interact with it on behalf of another host, this interaction includes requesting Kerberos access tickets.

So, I can modify the property of the SOPORTE01 host, indicating that another host has the privileges to request Kerberos tickets on behalf of SOPORTE01.

For this case, we will create a new computer in the internal domain through the command line, since by default, in a standard Active Directory installation, any registered user can add up to 10 computers to the internal domain (MS-DS-Machine-Account-Quota ownership of the users).

Exploitation through Kali Linux

Using the impacket suite, the max.power user can create a new domain joined computer called jsecrbcd.

Now, since max.power has GenericAll privileges over SOPORTE01, we’ll modify its properties indicating that our new host, jsecrbcd, can impersonate users through S4U2Proxy on SOPORTE01.

Because of the privileges the user has, the attack was successful, indicating that the machine account jsecrbcd$ can be used to forge Kerberos tickets.

We’ll use the machine account to forge a kerberos ticket, impersonating the Administrator domain user, which is why it’s important to know the machine account password.

We export the ticket and validate it.

This way, we can get a valid kerberos session as a domain admin, but only on the SOPORTE01 host.

The first step of the exploitation chain is done, and we have the NTLM hash for the SOPORTE01 host, so now we can exploit the second RCBD attack path on the TECNOLOGIA01 host and obtain domain admin privileges.

To confirm that the obtained NTLM hash is valid, we successfully authenticate to the domain controller with the machine account.

Its a machine account, so it has low privileges over the domain, however, since its also considered a domain user, it can also add up to 10 hosts to the domain.

We use the machine account SOPORTE01$ to create another machine jsecrbcd2.

We execute the RBCD attack using the SOPORTE01$ account towards the TECNOLOGIA01 host since the first has write privileges over the second.

The delegation permissions were added correctly, so the newly created machine account jsecrbcd2 can now impersonate users on the TECNOLOGIA01 host.

We forge the kerberos ticket impersonating the domain administrator on the TECNOLOGIA01 host.

The ticket is valid and we get administrative privileges over the TECNOLOGIA01 host.

This way, we obtain the NTLM hash for the machine account that belongs to the Domain Admins group, giving us control over the internal domain.

We can use the NTLM hash to DCSYNC using the machine account TECNOLOGIA01$.

TARGETED KERBEROASTING EXPLOITATION PATH.

The exploitation path is the following one.

Since we assumed the max.power user compromise, we can use it to create an SPN ticket for the jsec user and try to crack its password.

We can use a python script that automates the whole procedure called targetedkerberoast.py
https://github.com/ShutdownRepo/targetedKerberoast

The success of the attack depends on the password set for the jsec user.

Once we execute the tool, we can see in the verbosity messages that the SPN ticket was added successfully and the respective hash, after it prints it, the ticket is automatically deleted.

Since the password is pretty common, we get the credential almost immediately.

Validating the credential on the domain controller, we confirm the administrative access.

Although this type of attacks are not so common in real environments, there are very specific cases where they can be viable, I recently had two projects in which it was possible to exploit these points to access certain servers considered critical, an important point to consider is that the security configuration of a domain becomes of equal importance to the security patches installed and controls implemented.