Pentest Red Team Active Directory Attacks

[dEEpEst]

Active Directory​

What is Active Directory?

Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. It is included in most Windows Server Operating Systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. However, Active Directory became an umbrella title for a broad range of directory-related services.

A server running the Active Directory Domain Service (AD DS) role is called a domain controller. It authenticates and authorizes all users and computers in a Windows domain type network. Assigning and enforcing security policies for all computers and installing or updating software. For example, when a user logs into a computer that is part of a Windows domain, Active Directory checks the submitted password and determines whether the user is a system administrator or normal user. Also it allows management and storage of information, provides authentication mechanisms, and establishes a framework to deploy other related services. Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft's version of Kerberos and DNS.

 

[dEEpEst]

Lightweight Directory Access Protocol​

The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an internet Protocol network.

A common use of LDAP is to provide a central place to store usernames and passwords. This allows many different applications and services to connect to the LDAP server to validate users.

 

[dEEpEst]

Kerberos​

Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Kerberos uses UDP port 88 by default.

Description

The client authenticates itself to the Authentication Server (AS) which forwards the username to a key distribution center (KDC). The KDC issues a ticket granting ticket (TGT), which is time stamped and encrypts it using the ticket-granting service's (TGS) secret key and returns the encrypted result to the user's workstation. This is done infrequently, typically at user logon; the TGT expires at some point although it may be transparently renew by the user's session manager while they are logged in.

When the client needs to communicate with a service on another node (a "principal", in Kerberos parlance), the client sends the TGT to the TGS, which usually shares the same host as the KDC. The service must have already been registered with the TGS with a Service Principal Name (SPN). The client uses the SPN to request access to this service. After verifying that the TGT is valid and that the user is permitted to access the requested service, the TGS issues ticket and session keys to the client. The client sends the ticket to the service server (SS) along with its service request.

 

[dEEpEst]

Forest, Tress and Domains​

The Active directory framework that holds the objects can be viewed at several levels. The forest, and domain are the logical divisions an Active Directory network.

Within a deployment, objects are grouped into domains. The object for a single domain is stored in a single database (which can be replicated). Domains are identified by their DNS name structure, the namespace.

A domain is defined as a logical group of network objects (computers, users, devices) that share the same Active Directory database.

A tree is a collection of one or more domains and domain trees in a contiguous namespace and is linked in a transitive trust hierarchy.

At the top of the structure is the forest. A forest is a collection of trees that share a common global catalog, directory schema, logical structure, and directory configuration. The forest represents the security boundary within which users, groups, and other objects are accessible.

 

[dEEpEst]

Active Directory Attacks​

In this section I will work and go through some of the well-known AD Attack techniques that are commonly known or available in the environment.

 

[dEEpEst]

Kerberoasting​

You have an SPN service/user the attack works because by default any domain user can request a Ticket to these user's/services the Kerberos grant's a ticket, this ticket is later stored in memory and you can grab this ticket, save it offline and crack the hash file to gain clear-text credentials.

Tim Medin presented at DerbyCon 2014 a tool called Kerberoast which cracks Kerberoast TGS tickets, He determined that possession of a TGS service ticket encrypted with the RC4 provides the opportunity to take the ticket to a password cracking computer (or cloud system) and attempt to crack the service account's password. How does this work? Since the TGS Kerberos ticket is encrypted with the RC4 encryption, that means the service account's password hash is used to encrypt the ticket. The cracking system loops through converts to NTLM, and attempts to open the TGS ticket. If the TGS ticket is opened, we know the clear text password and the NTLM password for the account.

In Summary

Kerberoasting abuses traits of the Kerberos protocol to harvest password hashes for Active Directory user accounts with serviceprincipalName (SPN) values (i.e. service accounts). A user is allowed to request a ticket-granting service (TGS) ticket for any SPN, and parts of the TGS may be encrypted with the RC4 using the password hash of the service account assigned the requested SPN as the key.

An adversary who can extract the TGS ticket from memory, or capture them by sniffing network traffic, can extract the service account's password hash and attempt an offline brute force attack to obtain the plaintext password.

Attack

The setup for this attack can be viewed

This link is hidden for visitors. Please Log in or register now.

Now will use a few methods to search for any Kerberoastable Users. This can be done with any domain user this attack is abused since any domain user can request a ticket for an SPN account we verify our domain account

I will use Rubeus to locate Kerberoastable user's an OPSEC tactic to consider is using the /stats parameter this will only search for Kerberoastable Users on the current domain without requesting a Ticket to the DC.

Rubeus kerberoast /stats

We can Enumerate the specific users of the Domain that are available for Kerberoast, the following command will enumerate users with a Service Principal Name.

SharpView.exe Get-DomainUser -SPN

Now we can request the ticket from the users and choose the format-specific for our cracking tool which this preference would be hashcat

Rubeus kerberoast /domainominionCyber.local /user:jnovoa /nowrap

Now with this available, we can crack the password offline utilizing hashcat, once sent to our cracking rig we can use wordlists to attack this hash and try cracking it with this one we managed to get the password by utilizing the RockYou wordlist with a ruleset.

hashcat.exe -m 13100 -a 0 hashes wordlist

 

[dEEpEst]

Unconstrained Delegation​

When a user accesses a server with unconstrained delegation enabled, the user sends their TGT to the server. The server can then impersonate the user by using their user's TGT to authenticate to other services in the network.

But what is delegation? Delegation is a feature in Active Directory that allows a user or a computer to impersonate another account. Microsoft had to provide a simple mechanism to support scenarios where a user authenticates to a Web Server via Kerberos and needs to update records on a back-end database server on behalf of the user. This is typically referred to as the "Kerberos double-hop issue" and requires delegation.

What the risk?

Once you turn on unconstrained delegation to a computer, any time an account connects to that computer for any reason, their ticket (TGT) is stored in memory so it can be used later by the computer for impersonation. Let's say you enable this option on a computer you have administrative access to and then get a Domain Admin user to access the computer over the Common Internet File System (CIFS) by accessing a shared folder. Without unconstrained delegation on, only the ticket-granting server (TGS) would be stored in memory on your compromised machine. This ticket gives access only to the CIFS service on your machine so you can't use it to move laterally. However, with unconstrained delegation enabled, when the privileged user connects to your machine, their TGT will be stored in memory, which can be replayed to move laterally and compromise a domain controller.

TL;DR

As we mentioned before what is the risk to having Unconstrained Delegation, is that anytime an account connects to the compromised computer for any reason, their ticket (TGT)is stored in memory so it can be used later by the computer for impersonation.

Attack

First to setup this attack path this needs to be done from the DC, we right click on the PC name and "Trust this computer for delegation to any service (Kerberos only)" option checked.

Now it's time to search for the machine that has the Unconstrained Delegation available for it. We find this with utilizing PowerView

Get-NetComputer -Unconstrained

Now let's say our goal is to reach Desktop-Alpha and we have no permissions to access the machine.

Administrator Privileges from here

Now we will need to elevate our privileges on the host machine to start capturing tickets once that is done we have to wait for a user that has access to Desktop-Alpha and we can use the ticket to access the target machine (For the sake of Demo I will have a user access a folder on Desktop-Charlie)

We run Rubeus in monitor mode, I used an interval of 10 seconds after this I managed to capture the ticket.

Successfully done this I will save the ticket then pass it onto my current session.

Rubeus ptt /ticket:<TICKET BASE64>

Then we try and list the C$ share on the machine and we are successful

We are aware this user is a Local Administrator to the Machine so we can also grab a shell. Will create a process for this and inject our ticket to this PID so we are allowed to do Network Actions

Rubeus createnetonly /program:C:\Windows\System32\cmd.exe

Then we will inject the ticket in the newly created process take a note in the LUID

Rubeus ptt /luid:0x302756 /ticket:<TICKET BASE64>

Now Impersonate the Process

With this we can use PSEXEC to gain a Shell on the remote machine

And we get a new Grunt on the Target Machine as SYSTEM (PSEXEC does this since it’s a service and these run with the highest privileges)

whoami, hostname

Now that we understand unconstrained delegation this is not the only user we can impersonate on this machine I used this sample since the user was a LOCAL Administrator on the target machine, usually when using this attack we are trying to impersonate Domain Admins but the truth is we can use any user that helps us reach our goal.

 

[dEEpEst]

Constrained Delegation​

Constrained Delegation is a way to limit exactly what services a particular machine/account can access while impersonating other users. The "service" specified is a service principal name that the account is allowed to access while impersonating other users. PowerView can help in locating these attributes, the field of interest is the msds-allowedtodelegateto, but there's also a modification to the accounts' userAccountControl property. Essentially, if a computer/user object has a userAccountControl value containing TRUSTED_TO_AUTH_FOR_DELEGATION then anyone who compromises that account can impersonate any user to the SPNs set in the msds-allowedtodelegateto. Benjamin Delpy metioned that SeEnableDelegationPrivilege being required to actually modify the parameters.

What's the Risk?

If you are able to compromise a user account with SPNs set under msds-allowedtodelegateto can pretend to be any user they want to the target service SPN. For the HOST SPN this allows complete remote takeover. For MSSQL SPN this would allow DBA rights. A CIFS SPN would allow complete remote file access. A HTTP SPN this would likely allow for the takeover of the remote web-service, and LDAP allows for DCSync. HTTP/SQSL service accounts, even if they aren't elevated admin on the target, can possibly be abused with Rotten potato to elevate right to SYSTEM.

Attack

First let us start using PowerView in the below screenshot you may see that the user jwick is allowed to delegate or in other words impersonate any user and authenticate to a file system.

We liked to focus onto the section for msds-allowedtodelegateto

Now let us dump some tickets and find the correct one for the station we are trying to access .Let's now request a delegation TGT for the user jwick

Rubeus tgtdeleg

From here we will use the s4u attack from Rubeus to impersonate a user that has administrator access to the machine Desktop-Delta and continue from there, we want to change the service to CIFS to allow us to list the directories:

Rubeus s4u /ticket:<Ticket from TGTDELEG> /domain:dominioncyber.local /impersonateuser:jwinchester /msdsspn:http/desktop-delta.dominioncyber.local /dc:dominioncyberdc.dominioncyber.local /ptt /altservice:cifs

REMOVE THE DOMAIN FROM THE MSDSSPN, CAREFUL SOMETIMES THE MSDSSPN SECTION WILL ALSO BE ENCAPSULATED IN DOUBLE QUOTES (" ")

Above once we receive the "Ticket successfully imported!" message we can copy the 2nd ticket from the output for later compromise if needed "Remember these are time based"

From here we can create a process using Rubeus, inject the ticket to that process and allow us network actions.

Administrator Privileges from here this is only needed to perform netowrk actions

Rubeus createnetonly /program:C:\Windows\System32\cmd.exe

We save this information and now ptt onto the LUID and then impersonate the process

Now impersonate the process

And for some strange reason I would receive something like this

So I did some research and found that ired.team had the same issues and requested the ticket in a different way by removing the DOMAIN from the msdsspn section

<strong>/impersonateuser:jwinchester /msdsspn:cifs/DESKTOP-DELTA /ptt </strong>

[Removed some sections of the original command]

By doing that change I managed to enumerate the shares as I am aware jwick is an Administrator on station Delta.

 

[dEEpEst]

DCSync​

The concept of DCSync is that it impersonates a Domain Controller to request all the hashes of the users in the domain. Yes. This means as long as you have permissions, you do not need to run any commands on the Domain Controller the need to compromise the DC is not necessary as this one is usually quite difficult

For this to work, it is important to have proper permissions to pull hashes from a Domain Controller. Generally limited to the Domain Admins, Enterprise Admins, Domain Controller Groups, and anyone with the Replicating Changes permissions set to Allow (i.e. Replicating Changes All/Replicating Directory Changes), DCSync will allow your user to perform this attack with the use of mimikatz.

What's the risk?

Well if a user can impersonate a Domain Controller and request for all the domain user's passwords, that is enough risk.

Attack

We can enumerate a user with these permission with powerview by using the Get-ObjectACL CMDLET

Get-ObjectAcl -Identity "dc=dominioncyber,dc=local" -ResolveGUIDs | ? {$_.SecurityIdentifier -match "S-1-5-21-1827981533-2463545078-1305764163-1120"}

Above, when locating these 2 objects DCSync is allowed for the user. This is as simple as running DCSync <username> on Covenant and grabbing the hashes for the krbtgt user.

It also has a sample on what command is being executed when utilizing mimikatz

And we can do this for any user of our choosing in the entire Domain

Jwick

Understanding this technique and exploiting is valuable as this can provide persistence with the highest privileges on the Domain and can be also used to initiate other techniques such as Golden/Silver Tickets.

 

[dEEpEst]

Golden Tickets​

The KRBTGT Account, every Active Directory Domain Controller is responsible for handling Kerberos Ticket requests, which are used to authenticate users and grant them access to computers and applications. The KRBTGT account is used to encrypt and sign all Kerberos tickets within a domain, and a domain controllers use the account password to decrypt Kerberos tickets for validation. This account password never changes, and the account name is the same in every domain, so it's a well-known target for attackers.

What's the risk?

Once an attacker compromises the KRBTGT account they can create forged Kerberos tickets (TGTs) which can be used to request TGS tickets for any service on any computer in the domain. But remember the hardest part of this attack is you need Administrator Access to the DC (Domain Controller), these attacks are hard to detect because they are valid TGTs.

For Demo purposes we have the KRBTGT Hash and a Shell with the user Mgarcia, if we enumerate the DC Directory we don't have access.

Now let us use the binary form of mimikatz as there is no way that I am familiar with that this technique will work straight from Covenant I move to a local CMD (you can also use RDP if available and probably PSRemoting), we will first need the SID of the User and the KRBTGT hash

We will copy everything but the last 4 digits as they identify the user and we want to replace that with a 500 SID user. In our previous attack DCSync we grabbed the KRBTGT hash so we can skip this, as the user had DCSync permissions it was easy to grab without compromising the DC.

And now we will use the command for mimikatz to grab and pass the ticket onto our current session.

Once we execute the command successfully, we can enumerate the C Drive from the DC.

As you can see now with the KRBTGT Account's NTLM Hash we can forge ticket to any user or create our own and give them the highest privileges on the Domain, this is a great method for persistence

 

[dEEpEst]

Skeleton Keys​

The Skeleton Key malware "patches" the security system enabling a new master password to be accepted for any domain user, including admins.

This enables the attacker to logon as any user they want with the master password (skeleton key) configured in the malware.

"Joe User" logs in using his usual password with no changes to his account. The attacker can log in as Joe using the skeleton key password and it is seen as a valid logon.

Attack

In order to perpetrate this attack, the attacker must have Domain Admin rights. This attack must be performed on each and every domain controller for complete compromise, but even targeting a single domain controller can be effective. Rebooting a domain controller will remove this malware and it will have to be redeployed by the attacker.

To start the attack we can simply use mimkatz as it has this technique available a few command lines and we can reach our goal

Now we can access anywhere on our Domain with the default password "mimikatz" and we can authenticate utilizing any of the Domain Admins available in the Domain.

This will work for any user not just Domain Admins, this is a Master Password for everyone.

We do have to take in consideration that this technique will stop working when the DC is rebooted, as this will patch the "lsass.exe" in memory and once rebooted this will stop.

 

[dEEpEst]

Active Directory Certificate Services​

AD CS is Microsoft PKI implementation that integrates with existing Active Directory forests, and provides everything from encrypting file systems to digital signatures, to user authentication. While AD CS is not installed by default it is widely deployed.

Attackers con request or renew certificates for users and computers, providing the same persistence approach as other techniques.

The certutil binary is a command line tool which can be used to quickly discover if there is a certificate authority on the domain.

We can verify the server has been identified as adcs.dominioncyber.local

I'll proceed with utilizing ntlmrelay from impacket suite we can capture the authentication of the Domain Controller machine Account and relay it to the Certification Authority Server

ntlmrelay -t

This link is hidden for visitors. Please Log in or register now.

-smb2support --adcs --template DomainController

We can force authentication via PetitPotam this will make an API call (EfsRpcOpenFileRaw) that will trigger the machine account to authenticate to another system

We can see a successful attack since we can monitor that the Certificate was captured, when passing credentials onto Petitpotam we notice the authentication was successful

Here the tool mentioning it has been successful

The certificate will be generated in Base64 format

Moving back to the Windows Workstation we can utilize Rubeus to pass the Ticket

Successfully passing the ticket can be verified by using the klist command on the cmd

We can DCSync the Domain with these permissions

 

[dEEpEst]

NTLMRelay​

To achieve code execution the user or machine needs to be in the Administrator Group and/or have permissions to write on a share, in this example we have the user mwinchester on Desktop-Alpha moving to Desktop-Bravo since the user compromised was mwinchester but has no Administrator privileges on the current box, so we can relay the authentication and gain code execution on the target machine, the setup is simple.

Will start by running ntlmrelay targeting the machine we want to authenticate and enabling SMB2Support if necessary

The user needs to authenticate to our relaying machine, in this example the Linux Box. We have various methods to relay authentication but, in this case, will just force it by trying to browse a fake share on the Linux box, (various methods to control this authentication exists an example would be to Taint a Share and Force Authentication), from the Windows machine we can verify our user

The user is not an Administrator on the Box. The user tries to browse the Linux Machine

Our attacking machine will successfully relay the authentication to Desktop-Bravo and gain code execution

We can tell from here that a user was authenticating to the Linux machine, and we relayed that to our targeted box.

 

[dEEpEst]

AS-REP Roasting​

AS-REP Roasting is an attack against Kerberos for user accounts that do not require preauthentication. This is explained in pretty thorough detail in HarmJ0y's post. Pre-Authentication is the first step in Kerberos authentication and is designed to prevent brute-force password guessing attacks.

During preauthentication, a user will enter their password which will be used to encrypt a timestamp, and then the domain controller will attempt to decrypt it and validate that the right password was used and that it is not replaying previous requests. From there the TGT will be issued for the user to use for future authentication. If preauthentication is disabled, an attacker could request authentication data for any user and the DC would return an encrypted TGT that can be brute-forced offline.

What's the risk?

If we can enumerate accounts in a Windows domain that do not require Kerberos preauthentication, we can now easily request a piece of encrypted information for the accounts and crack the material offline, gaining clear text credentials.

Attack

Rubeus allows us to simplify this attack by using the asreproast parameter on the tool, this will find all users with the vulnerability and request a ticket

We can see our user John Constantine has this preauth now we can copy this ticket and move it onto our cracking tool (hashcat) and grab some cleartext credentials.

Be wary that a 23 needs to be added onto our hash as Rubeus does not do this for us

$krb5asrep$<strong>23</strong>$[email protected]

After a moment with hashcat and adding some rules we can take a look that our word-list successfully cracked the password.