On this post
- Information Gathering
- Low-Privilege Shell
Helpline is a retired vulnerable VM from Hack The Box.
Let’s start with a
masscan probe to establish the open ports in the host.
# masscan -e tun0 -p1-65535,U:1-65535 10.10.10.132 --rate=1000 Starting masscan 1.0.4 (http://bit.ly/14GZzcT) at 2019-05-14 08:47:18 GMT -- forced options: -sS -Pn -n --randomize-hosts -v --send-eth Initiating SYN Stealth Scan Scanning 1 hosts [131070 ports/host] Discovered open port 5985/tcp on 10.10.10.132 Discovered open port 49667/tcp on 10.10.10.132 Discovered open port 135/tcp on 10.10.10.132 Discovered open port 8080/tcp on 10.10.10.132
Quite the standard ports associated with a Windows machine. Now, let’s do one better with
nmap scanning the discovered ports to establish the services.
Interesting. Basically, we only have WinRM and
http services to explore. Let’s start with the
http service. Here’s how it looks like.
ManageEngine ServiceDesk Plus 9.3
This version of ServiceDesk Plus is susceptible to CVE-2019-10008, which allows session hijacking and privilege escalation from guest to administrator. And I have just the perfect exploit (EDB-ID 46659) for it.
Set the cookies in my browser (with the Cookie Manager Firefox add-on) as suggested and then navigate to the site.
Bam. I’m the
Now that I’m the
administrator, it’s best to create another account with the same privileges because setting cookies in the browser can be quite a pain in the ass.
To do that, go to the Admin->Users->Technicians page (strange that an Administrator is also considered a Technician
ManageEngine ServiceDesk Plus Custom Triggers
Surprise, surprise. ServiceDesk Plus (or SDP) has super powers—the software is able to execute remote commands with custom triggers, i.e. Execute Script, upon meeting certain criteria in newly created requests or incidents. SDP is even so kind to give you an example.
Go to Admin->Helpdesk Customizer->Custom Triggers
The plan is to create a trigger to transfer a copy of
nc.exe to the machine, and another to execute
nc.exe as a reverse shell back to me.
You can see from above that I’m using the PowerShell
Invoke-WebRequest cmdlet to download
nc.exe from my attacking machine and saving it to
C:\Windows\tracing\nc.exe. I have a SimpleHTTPServer set up on my attacking machine to host
nc.exe. For the life of me, I have no clue why
C:\Windows\tracing is world-writable but it works toward our advantage. The next trigger is to run the reverse shell. Both triggers will be activated when the subject of the new request starts with “avengers” “endgame” respectively.
Now, let’s go to the Requests page to create our “Avengers: Endgame” requests.
Creating the “avengers” request
Nothing fancy. Create a new request with subject “avengers” and set the priority to High. Once created, the download will begin.
Similarly, create another new request with subject “endgame” and set the priority to High and wait for your reverse shell.
Boom. And this is not the only surprise.
It’s pretty easy to find
root.txt should be at the usual location.
Time to claim it.
What the hell is going on? I’m
SYSTEM yo??!! Turns out that both files are encrypted.
Only specific accounts are able to decrypt the files. I need credentials…
Saving SAM, SECURITY and SYSTEM Hives
One way to retrieve credentials is to dump them out of the holy trinity of registry hives: SAM, SECURITY AND SYSTEM, with Impacket’s
Saving them is not the issue. You can easily do that with
reg save hklm\sam for example. The issue is where to save them so that I can download them to my attacking machine.
Our SDP is a web application and the web server serves static resources like images, right?
All we have to do is to find where the file is located and we can save our hives over there.
E:\>dir /s /b default-logo.png dir /s /b default-logo.png E:\ManageEngine\ServiceDesk\applications\extracted\AdventNetServiceDesk.eear\AdventNetServiceDeskWC.ear\AdventNetServiceDesk.war\images\default-logo.png
Bingo. And since I’m
SYSTEM, saving the hives shouldn’t be a problem.
Once that’s done, we can download the files to my attacking machine.
# wget http://10.10.10.132:8080/images/sam # wget http://10.10.10.132:8080/images/security # wget http://10.10.10.132:8080/images/system
It’s dumping time!
What do we do with the hashes. Well, we can always crack them.
zachary’s password is cracked. Perhaps a more efficient way is to pass-the-hash to a tool like FreeRDP. Before we do that, we need to disable Windows Defender and turn on Remote Desktop Services with PowerShell to give ourselves more options.
Disable Windows Defender Real-time Protection
PS> Set-MpPreference -DisableRealtimeMonitoring $true
Enable Remote Desktop Services
Enable Remote Desktop
PS> Set-ItemProperty -Path 'HKLM:\\System\\CurrentControlSet\\Control\\Terminal Server'-name "fDenyTSConnections" -Value 0
Allow incoming RDP on firewall
PS> Set-NetFirewallRule -Name RemoteDesktop-UserMode-In-TCP -Enabled true
Enable secure RDP authentication
PS> Set-ItemProperty -Path 'HKLM:\\System\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp' -name "UserAuthentication" -Value 1
Hijacking Remote Desktop Services
During my enumeration, I noticed that
leo is logged on to the physical console, probably through automatic logon.
And since I’m
SYSTEM, I can make use of
tscon.exe to hijack that session into my own. How do I do that? I can pass the
administrator’s NTLM hash to FreeRDP instead of a password. That will create an RDP session and with
tscon.exe, I can hand over
leo’s session over to the newly created session.
A RDP session is created, albeit access is denied. Do not click “OK”.
Turn over to the Windows shell.
You can see the newly created RDP session. Now issue the
tscon.exe command like so:
C:\> tscon 1 /dest:rdp-tcp#2
The FreeRDP X window that’s already open will switch to Leo’s session and there’s another encrypted file on Leo’s desktop.
Damn. It’s suppose to unlock! Anyways, we have
SYSTEM privileges remember? One of the oldest tricks in the book is to replace
What’s going on?
You can see that the creator has removed
SYSTEM’s full control permissions. Here’s an ugly hack. Take ownership of the file, grant
Everyone full control to
magnify.exe and then delete it.
Clicking the Magnifier pops up a beautiful
SYSTEM shell in the RDP session.
What’s so special with this shell? This shell opens Windows yo~
leo is able to login automatically without entering password. Here, I open up the Registry Editor and navigate to
HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon to check out his password. With that, simply add
leo to the Remote Desktop Users group and I can unlock the screen without changing anything.
Something’s strange is going on. Even
leo has limited permissions over
That’s why even
leo can’t decrypt
Well, that’s an easy fix. Although
leo lacks the permission to decrypt the file, he’s still the file owner after all. As such, we can still grant
leo full control over the file.
Now, we should be able to decrypt
Here’s how it looks like.
Turns out that this is the Data Protection API blob (displayed as a hexstring) for the
administrator’s password. We can decrypt the blob with the masterkey using
mimikatz dpapi module. And to get to the masterkey, follow the
mimikatz howto on decrypting EFS files. Once it’s decrypted, the
administrator’s password is revealed.
Armed with this password, we can decrypt
root.txt. Similar to
admin-pass.xml, we have to give ourselves full control over the file to be able to decrypt.
For the first time, getting
user.txt feels harder than
root.txt due to the lack of hints. Well, there’s a extremely subtle hint with the user
This sure is a strange group. I think the creator is telling us to look into Windows Events.
The only place I could think of where events contain password strings is the Security event, particularly the Process Creation tasks. Let’s filter the events.
Then look for the string
There you go. Armed with
tolu’s password, we can decrypt