This will be the first in a series of write-ups detailing my experiences exploiting various HackTheBox and VulnHub systems. I will be starting with some of my earlier forays, and working my way up to more recent (and difficult) challenges. Not all of the systems I have exploited will find a place here, but I hope the ones that do will provide a comprehensive and informative resource for anyone that finds there way to my little corner of the Internet. Pre-Engagement HTB Scope and Limitations : The HTB Network is 10.10.10.0/24 (10.10.10.1-10.10.10.254) Don’t hack any machines apart from the intended ones It’s not the end of the world if you try to hack gateways and other nodes on the HTB Network (10.10.10.0/24) but if you succeed, don’t do any damage and inform them ASAP. Any form of DoS (Denial of Service) is forbidden There is no reason to use any form of DoS on any machine inside or outside of the HTB Network. Don’t try to hack other members The network is built in such a way that direct communication between two member systems is prohibited. Although there are ways to attack another member, attacking or even connecting to other member’s client is strictly prohibited. Goals: Retrieve hashes from two files on the target machine

The user.txt file can be found under /home/{username} on Linux machines and in the Desktop of the user on Windows. The root.txt file can be found under /root on Linux machines and in the Desktop of the Administrator on Windows.

Initial Enumeration

It is generally a good idea to verify your target is up and accessible. A simple ping of the target systems/network is usually sufficient:

Then we move onto more in-depth enumeration with NMAP and Nessus scans of the identified targets:

My Default NMAP Command: nmap -sC -sV -oA <out file name> <target>

-sC : Safe Script Checks Run

-sV : Version Checks Run

-oA : Write output to all available formats (.nmap, .gnmap, & .xml)

The NMAP results provide plenty of information:

Open Ports 21 Microsoft ftpd Anonymous Login Allowed 80 IIS 7.5 http-methods of note: TRACE

OS is Windows (though no solid determination as to the version)

Nessus identified a couple of vulnerabilities (MS12-073 & MS15-034), neither terribly useful for our purposes (one being likely to cause a DoS, and the other basic info disclosure) and served to confirm our NMAP results.

What we want to focus on is the Anonymous FTP Login capabilities discovered by NMAP. A few quick commands verify that we can log in anonymously and also have the ability to upload files as well.

Better yet, the uploaded files are browsable….

Further testing verifies that additional interesting (html, php, asp, etc) file types uploads are not restricted.

So, we know we have the ability to upload arbitrary files, which then can be browsed to. How do we exploit that? Well if you look closely at the NMAP results or the output of the DIR command, you will notice that there is an aspnet_client directory on the target, I wonder what that is?

“This folder is automatically created when you enable the ASP.net extension on your site.” – http://blog.arvixe.com/what-is-aspnet_client-folder/

This indicates that the ability to run ASPX files has been configured on our target and is interesting for a couple of reasons:

We have the ability to upload our own ASPX files and run them. ASPX files are run server-side, exactly where we want our payload to be executed.

Exploitation

While we have determined that an ASPX payload appears to be a promising attack vector, how do we go about exploiting that? You could dig around on-line for pre-compiled ASPX payloads. Kali also comes installed with numerous WebShells you could edit for this purpose.

However, I had heard about using a tool called MSFvenom to create your own payloads, using Metasploit payload modules and wanted to try it out.

With MSFvenom you will generally need to identify the following before building your payload:

Know what payload you wish to use windows/meterpreter/reverse_tcp was my choice for this host Know what options are required for the chosen payload Identify the file format you wish to use

Basic MSFvenom command format: msfvenom -p <PAYLOAD> [Options LHOST/LPORT etc] -f <File Format> -o <File name for output>

Now that our totallynotevil.aspx payload has been created, we need to stage our system to receive the expected reverse shell, using the Metasploit Handler module.

If we were not able to utilize Metasploit for the connection, we could setup a basic Netcat listener instead. I would recommend you become very familiar with Netcat’s capabilities as it is an incredibly versatile tool.

Now that we have a listener setup, we want to upload our payload and browse to it.

Assuming we setup everything correctly, we should catch the reverse shell.

If you are not seeing a shell, you should go back and verify all of your variables (LHOST, LPORT, etc) match in both the payload and the Metasploit Handler.

With a successfully executed a payload providing a reverse shell for the target system, I then execute a couple quick commands to get some information about the environment I now have access to.

Local Enumeration

Now that we have access to the box, I want to see if I also have any access to the first flag, a user.txt file located on the Desktop of the local non-admin user account. In this case, an account named babis.

Unsurprisingly (given the account permissions for the shell), I have no access to the directories containing the target data. That means we have to look for a method to escalate our privileges. There are many ways to enumerate a system to identify those escalation points, and I will be delving into more of them in future write-ups.

This system requires minimal enumeration and privileges can be escalated utilizing a neat Metaploit module, the Local Exploit Suggester.

This module will run checks against the local system and recommend any available modules that it believes the system may be vulnerable to. Now this list is not foolproof, and will generally still require additional review to weed out false positives, as you can see from the output in the image below:

Being able to narrow down the scope of possible exploits from several hundred to often less than a dozen, with only a single module, can save an awful lot of time.

Now this won’t always return results, and sometimes you will find that none of the results are viable options. I have found this tool to pay off on more than one occasion and with minimal time investment. This is one of those times, as when I was reviewing the output, I find a possible match on just the second reported candidate.

The KiTrap0D exploit is an old exploit, works on Windows 7 and requires x86 architecture. All matches for our target system.

Lets go ahead and load the module, supply the necessary variables and let it loose…

You may have noticed the session number is different in this screenshot. Which was a result of me having to rerun this exploit a couple times. One failure was due to my fat-fingering of a module option, and the second time the exploit appeared to have hung. Both instances required me to kill and re-establish the initial shell (totallynotevil.aspx). I am unsure of the root cause for the failure of the module, which could be attributed either to the reliability of the exploit, or the shared environment I was working from.

Either way, I got the goods…

Post Exploitation and Persistence



At this stage, if this were a real Pentest or I was working on a full lab network, I would setup some persistence so I could regain access to the machine as needed and spend much more time enumerating further to identify any potential pivot points.

Though as neither scenario applies, I simply dumped the hashes for later use (playing with hash cracking, credential reuse scenarios, etc).