The attacker methodology is a fantastic framework for thinking about how attackers go about hacking stuff. You will use it whether you would like to or not during the OSCP process.
The methodology consists of many steps. The first of which is to figure out what you are attacking, aka enumerating ports and services. Many people approach this phase with half-heartedness, jumping on the first clue they find. Contrary to your giddy ego, you probably will not find your way into a system within the first five minutes. Maybe. But chances are slim.
In this blog post, we will discuss tools and techniques used to gather data on your targets to set up a avenue for additional recon. Another blog posts will cover other types of recon including web applications specifically.
In many situations, including with the OSCP, you will find yourself with a range of IP addresses and scopes. Not every IP in the address space is occupied. It is up to you to find out which addresses have a host listening.
Discovery should be conducted separately from port scanning to save time. Sounds counter-intuitive, doesn’t it?
Think about it this way, the fewer hosts you have to scan, the faster your additional task will complete. By identifying hosts first, we can cut down on the amount of processing done by your service detection and other enumeration tools.
Metaphor two. In warfare, if a general is attacking 50 cities, his resources will be spread thin at each city. Chances of winning will be slimmer at each battlefield. At any given time, two things are true; Everyone has a finite amount of time and resources. If instead, the general selects the most impactful city and focuses all his troops there, he will be guaranteed a win.
As a penetration tester, we must always think about creating small sets of targets by enumerating and weighing options. You are a general with your time and tools!
Nmap is my go-to tool for discovery. A simple ping sweep in many cases will do the trick. For those who are just learning the lingo, a ping sweep is where you attempt to ping a host at each IP address in a range. Those ports who respond are occupied, and those who don’t, well no one is home.
Just an FYI here. This rule of thumb isn’t always the case. Various configurations can be used which can make hosts unresponsive to ICMP traffic. This blog is focused on simple cases, so we won’t dive into that area.
$ nmap -sn [target]
This command looks simple, and it is. The ‘-sn’ is the switch for Ping Scan which disables any port scanning.
From this scan, you should now have a list of live hosts for further enumeration.
Let’s continue with the Army General metaphor. We have our sites narrowed down after discovery; now we must narrow down the exact points of our attack. Things you should be thinking about which service is most likely exploitable.
We make this determination with enumeration by filling in gaps such as version numbers, configuration details, user accounts. The more information, the better.
Service Scan - TCP
Time to figure out what your identified hosts are doing. In this phase, we are looking to see what services are actively listening. An example is a web server.
You can gather this information with a basic scan or get as froggy as you want. Here is the aforementioned basic scan.
$ nmap -Pn -p- -sV[target]
This scan treats all host as if they are online (-Pn), because they are, skipping the ping scan. The second part is a shorthand way to scan all TCP ports (-p-). Just another FYI, you can specify port ranges by using the ‘-p’ switch followed a comma-delimited list, or a range represented with the format #-#, read as some number through another number. An example of this is, ‘-p 1-1000’ or ‘-p 21,22,80,443’. An finally the ‘-sV’ means we want version information for the services detected.
Initially, we want to scan all ports possible because services can run on any port. Some of you with experience may notice I haven’t mentioned UDP ports. We also want to check these, and we will discuss that now.
Service Scan - UDP
Scanning UDP ports suck. You can’t scan them all because it will take too darn long. According to Nmap documentation, the rate is about 1 per second, which means the scan would take about 18 hours. See Nmaps page on UDP scanning.
Obviously, due to the crazy length of time, it would not make sense to scan all 65,536 ports unless you really needed to. Why not scan the most likely, most used ports instead?
Nmap has this feature built-in. Use the ‘-F’ option to scan the top 100 ports. This letter is a capital “F,” not a lowercase. Case sensitivity is a killer in the information security world so keep an eye out.
A UDP Nmap scan should look something like:
$ nmap -F -sU -sV [target]
One thing to keep in mind is that services don’t always run on expected ports. One of your tasks is to validate that the service fingerprinted is the one actually running. By validating, I mean to confirm the nmap results using additional tools and scans.
A simple but effective tool for this task is to use netcat to connect to the service and grab a banner. Although banners can be manipulated, they are more often than not correct. While there confirming services, poke around for low hanging fruit such as guessable passwords.
Your next step will be to enumerate services further. Most of this effort will be poured into web services. For information on the attacker methodology see our last post for a high level view.
1. Make sure to save your output with the various output options. Adding a “-oA” will collect the scan information in all output formats.
2. Speed up the scans using “-T” and a 4 or 5. You may miss some services, so make sure to also do a more through scan at normal speeds.
Gordon Lyon is the creator of Nmap, a Swiss army knife of a tool that many in the info sec field use daily. He as well as many other have been working to add capabilities since 1997. Thank you to the amazing team that maintains Nmap.