Pre-Exploitation Techniques

Blog Update:

Before jumping into Pre-exploitation techniques I thought I would just address that, yes it has been a while since I posted. I just buttoned up my master’s thesis, finished my defense, and now am back to being a somewhat sane member of society! I do plan on doing a high-level view of my thesis research because some of it was awesome! That will come mid-April. Anyhow, back to the topic at hand.
[hr]

Pre-Exploitation Enumeration:

This probably should have come before my Post-Exploitation techniques writeup but, I’m not perfect… Anyhow, let’s dig into the Pre-Exploitation and enumeration tips and tricks! Full disclosure, this is not an exhaustive list and really just a very high-level view of common and useful enumeration vectors and tools. This post is assuming you either have a VM you are testing against or are on a valid hacking platform, such as Hack The Box or RootMe.org.

[hr]

NMAP:

Before you do anything, you need to know what you are dealing with. Nmap is your best friend! Well, that and hping3 but, we’re just going to rock Nmap for now. The capabilities are endless with Nmap from simple scanning all the way to the Nmap scripting engine. This scanning engine is your OSCP buddy! For now, we’re going to focus on initial system service discovery and that means finding services and versions. My go-to nmap syntax, adopted from watching IppSec, videos is:

nmap -sC –sV -oA <file_name> <ip_addr> 

• –sC: This runs default scripts. Default scripts being this.
• -sV: Service Version Detection. It should go without saying but, different versions have different vulnerabilities and as such you need to know the version of a service to properly enumerate possible attack vectors.
• –oA: Output the results of the scan in all formats. This is a big deal! You need to be able to return to the nmap scan to review your initial scan. You can also import the XML version of the scan into Metasploit, and other common attacking platforms (i.e., not re-creating the wheel).
• <file_name>: The name you select for your results output files.
• <ip_addr>: The IP address of the machine you are scanning.

 

We have a set of services and versions! What’s next? We need to dig deeper into what we, the attacker, believed to be the lowest risk and highest reward. Risk being us crashing the system and reward is the possibility of getting a shell/information. So, we need to efficiently look for exploits based on service/version and determine the path of least resistance as well as the lowest footprint on a system.

[hr]

SearchSploit:

This is a native Kali tool that queries exploit-db.com for possible exploits based on services and their versions. It’s a great place to start your exploit search but, you should also expand it to google to get a better idea as to what you are working with. At times, I find more results just by googling than I do with SearchSploit. Let’s take a look at one of our scanned services from above, Apache 1.3.20.

We get two results but, as we can see by looking at the exploit paths, they’re for Windows and our system is a Unix (RHEL) machine. This is just to show how you can quickly move from a scan to enumerating possible attack vectors. In our case above, I didn’t see anything for OpenSSH 2.9P2 or Apache. At this point, I would go directly to the Web Server and start my enumeration using several different tools and techniques.

[hr]

Web Server Enumeration:

More times than not, I end up working on enumeration and exploitation web servers rather than some other vector. The caveat being, if there is a system service with an easy to exploit vulnerability that’s not a web server (i.e.,  Samba, OpenSSH, FTP, Telnet, etc.) I’ll go for that first. But, let’s dig into webserver enumeration tools and tips.

Our main goal when enumerating a web server is to get as much detail about the web page and server as possible. We are looking for:

• We want to know all the web pages and if there are HTTP (cleartext) pages
• Comment fields
• Admin pages
• Login pages
• System Information (WordPress version for example)
• HTML, PHP, JS comments

We also want to know if the web page is running any common frameworks or using 3rd party technologies for hosting photos, login forms, etc. Essentially, we want to know everything about this page without having to dig into each page manually. This is not going to be a tool tutorial, that would take a damn long time… This is a high-level view of great tools you should get familiar with.

Web Enumeration Tools:

• BurpSuite: (Kali Native Program) If you are not using Burpsuite, you’re wrong! I’m not going to go into extreme detail of Burpsuite functionality in this post. Eventually, I will make a large writeup on necessary tools and functions Burpsuite employes and how you can use it to do just about everything you need! For right now, you should have a Burpsuite Proxy set-up and be listening when you are doing your manual probe of the webpage. You’re looking for uncommon parameters, oddities in HTTP post/get responses/requests, etc.
• Drib or Dirbuster: (Kali Native Program) Tools that automate the searching and categorizing of web pages by using a list of common page values (i.e., admin.php, index.html, etc.). These are very powerful tools that are very dynamic and can be tailer to your searching needs. For example, if you know that a page runs primarily on PHP, you can append that to .php list of values.

 

• Nikto: (Kali Native Program) A command line based web vulnerability scanner. This scanner is going to give you insight into the web server type, version, encryption mechanisms and possible vulnerabilities you can exploit. This tool is always running in the background right after I find a web server.

• Wpscan: (Kali Native Program) A WordPress specific scanner. This is a swiss army knife of tools for WordPress site enumeration and vulnerability enumeration.

When you start getting usable data back (i.e, admin pages, login forms, comment forms, etc.) one of the first things you should do is look at the source code. Let me say that again, LOOK AT THE SOURCE CODE. You’ll be surprised what you will find in HTML comments. Hell, there’ve been times where I have found username and password pairs! You’re looking for anything that will help you in getting in. If you find a username, you have now narrowed down your overall attempts at a brute force or dictionary attack for logins. That’s huge!

---

Okay, that’s enough for now. I think a more in-depth look at singular tools is in order. Possibly looking more at pre-exploitation enumeration and recon by detailed a tool at a time might be better in the long run.