Start by enumerating the machine
nmap -sC -sV -A -Pn 10.10.180.242
The scan has given us some valuable information.
Ports 80 (HTTP) and 3389 (RDP) are open
Server is Windows Server 2012 with IIS 8.5
ROBOTS.TXT disallows 6 directories:
Start Burp so that the traffic generated during our glance at the web page is captured. Next, lets open the web page by visiting the IP Address in the browser (since its running on port 80, no need to append a port). The first thing we want to do is navigate to the robots.txt file and visit the area disallowed by the file. This is so we can increase our visual footprint, as well open up additional attack paths.
We get a 403. Likely because we are not logged in
This area gives us a search function. This would be good for testing SQLi, XSS, directory traversal and command injection. Lets note it and move on
/search.aspx gives us the same thing as the previous area
This is just a standard 404 error page
Both /archive and /archive.aspx serve up what appears to be an archive of previous posts/blog messages
Lets add a few more things to our sitemap in burp. While looking at the last few pages we noticed there are other links scattered throughout the site. There is also a hamburger menu that gives us access to other pages. Lets navigate through all of these, noting all user inputs and parameters along the way. Ensure that you are only hitting pages that are in scope (i.e. only pages that start with your targets IP). Also, check out the source code and visit any links you may find in there that aren’t immediately obvious to regular users.
Throughout our adventure, we noticed several inputs, logins, password reset forms, and the name/version of the blog application.
Lets start with the login form. We could try a few common usernames to see if we can elicit different responses in which to build a brute force attack off of. But could there be an easier way to get usernames? Looks like theres a password reset function. Lets explore that. First I’ll handjam a few random characters and see what kind of response ill get.
Hmmmm…. This looks promising. Before we try automating, let’s try a few usernames that we constantly run across on a normal basis. Root, user, admin, administrator, etc. You know, common stuff.
Well, well, well. This could be valid. Using the information that we’ve gathered so far, we can likely build an effective username harvest in Burp Intruder. Lets capture a request, send it to intruder, and configure the attack.
Attack Type: Sniper
Payload: Simple list, Seclists “top-usernames-shortlist”
Grep — Match: User not found
Request Engine Settings: Threads — 1, Throttle — Fixed at 3000 (we are throttling because not doing so isn’t resulting in responses we are expected. So we will slow down the number of requests to ensure the requests are fully processing)
Once completed, only one username didn’t have the User Not Found error. Funny enough, ti’s the same username we identified earlier on our quick glance at the password reset function
So lets attack the login form with burp intruder with our new username! You can set up the attack similarly to how we did the last attack. Just change the Grep Match to the error message from the login form, “Login failed”, as well as changing the payload to be your passlist of choice. I will be using the seclists list “10-million-password-list-top-10000.txt”
Attacking the webform returned a single entry that didn’t contain “Login Failed”. That’s our password!
Now that we have both the username and password, we can log into the admin panel. While in the site, we can see that we have administrative rights to the site. That’s great, but we’re not here to deface. We want to compromise the underlying infrastructure. Clicking the “About” link brings us to a page which confirms the applications version number that we found earlier. Now, we COULD play with user inputs to try to gain access to the infrastructure, but before we do that lets see if there’s an exploit available for this application. Luckily, there is.
Now, we will download the exploit and modify the code to include our IP and a port we will use for connect back.
Also according to the exploit writer, we must rename this file to PostView.ascx. Next we will upload the file by selecting the edit function for the admins post, then uploading the file.
After saving, we will set up a netcat listener and then visit the root URL and append “?theme=../../App_Data/files” to it. This should trigger the exploit.
Excellent!Now we are going to attempt to enumerate the machine using WinPEAS. First, we need to get it onto the target machine. To do this, navigate to the folder containing the winPEAS exe and spin up an http server.
Now on the target machine, navigate to a folder that you know you have permissions to, and download the file. In this case, ill use C:\Windows\temp
And then we run winPEAS. In the first set of results, it looks as though we already found some admin credentials stored due to autologon
Lets note this credential and continue reading our results.
Looks like we have a service that we have access to modify! Trying to navigate around in our current form is a bit clunky. So lets try to switch to meterpreter. First, create a payload, then set up a web server to serve up that payload
Then set up a handler to catch the incoming session
Great. Now lets get our payload onto the target and run it
Excellent. Now lets use “getsystem” and……
Well crap. That wasn’t quite what we wanted. Looks like we should re-train our focus on that service we found earlier. Now we know that WService.exe isn’t the file we’re looking to modify. But inside that directory is an “Events” folder with a log file 20198415519.INI_LOG.txt. If we cat that file, we see that there’s a file names “Message.exe”. Lets use that as our launching point.
Lets take the payload we created earlier, delete the old Message.exe, replace it with our payload and wait….
And 30 seconds later…..
Success! Now we can read and submit the rest of the flags