Which exploit and which payload use?

Question

I'm learning penetration testing. I've read the Metasploit Unleashed guide on offensive-security. I've learned the Metasploit Fundamentals and the use of msfconsole.

After reconnaissance and scanning of my target, I have enough information to pass to next phase.

Some info I have is open ports with related running services, names of the services, service's versions, the operating system of the device, firewalls used, etc.)

I launched the msfconsole.

I should find the correct exploit and payload, based on the information collected to gain access. But I don't understand the way to start all of this.

Assuming that my target has 20 ports open, I want to test the vulnerability using an exploit payload that do not require user interaction. The possibilities of which exploit and payloads to use are now reduced, but are too many. Searching and testing all exploit and payloads for each ports isn't good! So, if i don't know the vulnerability of the target, how do I proceed?

I would like to be aware of what I do, and do not try without understanding. The remote exploit is only an example. I want to know the concept behind the choice of an exploit. Why I use exploit A and not B before check if A and B exploit work on the target?

Answer 1

It's great to see that you're trying to understand what exploit and payload to choose, and more importantly, WHY. That's the way to do it. This will save you lots of time in the mid/long term, and will help you become a much better pentester.

I should find the correct exploit and payload, based on the information collected to gain access. But I don't understand the way to start all of this.

Usually, the payload is the easy part. It mainly depends on what you're trying to achieve on the victim system (get a shell, install a backdoor so you can connect to it later on, DoS the service/app, etc), but also on the reduced set of options available for the particular exploit you will end up choosing.

Assuming that my target has 20 ports open, I want to test the vulnerability using an exploit payload that do not require user interaction. The possibilities of which exploit and payloads to use are now reduced, but are too many. Searching and testing all exploit and payloads for each ports isn't good! So, if i don't know the vulnerability of the target, how do I proceed?

In order to choose the right exploit, most of the time you will have to do some research. Sometimes a little bit, sometimes a lot. Of course, you want to do this process as efficiently as possible in order to save time (this seems to be your main question).

In real-life scenarios, a host will usually have only a couple ports open, maybe a few, but you will hardly ever find one with a number of open ports as large as 20. This narrows down the search quite a bit. For the couple open ports you find open, you'll want to identify the software (including version) running on each one and then try to identify potential vulnerabilities for this software (see note [ 1 ] below). If your goal is to simply get access the system, you will want to go for the "low hanging fruit" -- a popular phrase in the security community (see [ 2 ] below). This means that you will first look at the services that have better chances of being vulnerable. For example, HTTP is usually one of the first services to look at, because in general web applications are much more likely to have vulnerabilities when compared to other type of software. A MySQL/SQL server would be somewhere in the middle of the list, whereas an SSH one would usually be last (assuming it's running a recent version). But in order to make these decisions, you need to identify all services/versions first.

Sometimes the easier targets will not strictly depend on the service type itself, but how badly configured/maintained it can be. Examples are using blank, default, or easily guessed credentials, having obvious SQL injection issues, missing critical security patches, etc. Most of these apply to different kinds of software/services.

There's not much detailed theory out there about the "low hanging fruit". The practical experience you gain over the years makes a big difference. I did find a useful image at https://www.tenable.com/blog/vulnerabilities-by-common-ports-dashboard that's worth sharing:

Note how HTTP/80, HTTPS/443 and SMB/445 have the highest number of high and critical vulnerabilities, and also a big percentage (55-90%) of those are exploitable. On the other hand, even though SSH has a large number of high/critical vulnerabilities as well, only 3% of those are actually exploitable.

[ 1 ] Searching for vulnerabilities in a specific piece of software is a little science in itself. Usually, I start by simply googling about the software and version combined with the words vulnerability and/or exploit. I often find googling much quicker than using other tools, but of course I use the other tools as well: search function in MetaSploit Framework, www.exploit-db.com and its searchsploit tool included in Kali, https://www.securityfocus.com/vulnerabilities, specific software vendor website (security announcements), etc.

[ 2 ] Sometimes you will want to try to identify and exploit every single vulnerability on the target system, and not just one that will get you access. This is particularly true for some pentest engagements, since the customer wants to make their system or network as secure as they can, so it's very valuable for them to get a report listing all vulnerabilities found, the different ways they were exploited (or could potentially be exploited), remediation steps, etc. If you only include one, the customer can patch it but could still have lots of other security issues that could result in their system or network being compromised.

Answer 2

You are correct in that blindly launching exploits at a machine is not the right way to go.

Instead, you should be using all that data you collected to see if any of those things have vulnerabilities. For example, you have the service names and versions. Look up (in Metasploit or any other vulnerability database) whether that service version has a known vulnerability. That is how you narrow down your choices.