What? No Metasploit?

Ah the old “try harder” wisdom nugget. If taken in the right context, it is a slogan to live by. Unfortunately, most people don’t take it in the right context. Nine times out of ten, this statement is thrown around by egotistical fart clouds on IRC. In that context, it’s degrading and unhelpful.

How do we hack without using Metasploit? I could say “try harder!” and end the article with a smarmy trollface gif, but instead, I’m going to share some (hopefully) useful, actionable tips. If you’re taking the OSCP certification at the moment, or you’re thinking about it, this article is for you.

The use of Metasploit and other similar tools is heavily restricted in the (in)famous OSCP exam. There’s a good reason behind this, it forces students to understand how the exploit actually works. It sucks at the time, but you end up with more knowledge, which is why you’re doing OSCP in the first place, right?

To rid ourselves of Metasploit dependency, we need alternatives and a deeper understanding of some key concepts. By the end of this article, my padawan — know the way, you will.

Know the way, you will.

What Do We Use Metasploit For?

Before we figure out how to not use Metasploit, we need to have a clear idea of what we actually use it for in the first place. In the context of the OSCP labs, this is probably how you use it most:

Finding exploits

Customising payloads

Privilege escalation

Catching reverse shells

So in order to not use Metasploit, we need alternatives for these things. Let’s dive in!

Finding Exploits

The quickest and easiest way to do this is by using the tool bundled with Kali called “searchsploit”. If you haven’t already discovered this tool, a whole new world of efficiency is about to grace your fingertips. Searchsploit simply searches the exploit-db database for the keywords you provide. It will return both the exploits which can be used in Metasploit and standalone code exploits in various languages.

The syntax is easy to remember:

searchsploit keyword1 keyword2 keyword3 ...

The output looks something like this:

Searchsploit Output

The best part? All these exploits are already stored on your Kali box. You can easily copy them to your current directory by running:

searchsploit -m [exploit database id]

For example, to copy the first exploit in the list above:

If searchsploit fails to find any juicy exploits, try Google. If Google fails, well, there’s probably not a public exploit. TRY HARDER!

Trollface.gif

Customising Payloads

If you have much experience with Metasploit, you’re probably already familiar with the concept of payloads. The payload that you set when using a Metasploit module will define what the exploit actually does on a successful exploitation attempt. Usually, you would want it to open a Meterpreter session or a reverse shell so that you can take control of the victim box.

When you choose a payload in Metasploit, it is the equivalent of manually swapping out the payload in the exploit code. So to replace Metasploit here, all we need to do is swap out the payload manually. This often means that we need to generate some shellcode. How? Read on!

Msfvenom

Msfvenom, thankfully, is allowed to be used in the exam. We can use it to generate our custom payload, which we will then put into our exploit. A word of caution — if you’re doing the OSCP exam, stick to standard reverse shell payloads not Meterpreter ones. Meterpreter is forbidden in the OSCP exam.

The basic syntax to create shellcode is as follows:

msfvenom -p [payload] -f [format] LHOST=[your ip] LPORT=[your listener port]

Once we have our shellcode, we simply copy/paste it into our exploit code to replace the current payload which is in the exploit.

For example, if we are dealing with a buffer overflow exploit which currently opens calc.exe (a common PoC amongst windows exploits), we would edit the code of that exploit, replacing the current calc.exe shellcode with the shellcode generated by msfvenom.

Here’s an example of msfvenom in action. In this instance, I’m using an unstaged TCP reverse shell, with the LHOST set to 1.2.3.4, and the LPORT set to 1234.

Staged VS Unstaged Payloads

You might not have noticed, but most payloads you will be using have a very similar twin. For example, note the subtle difference between “windows/shell_reverse_tcp” and “windows/shell/reverse_tcp”. The first one is unstaged, while the second is staged. You will see the same naming convention with many other payloads too.

What’s the difference between staged and unstaged? If you use an unstaged payload, the entire payload is sent in one hit and executed on the target machine. This means that you can catch the shell with a simple netcat listener and it will work fine. If you’re using a staged payload, you need to use a Metasploit multi handler to catch the shell (this is allowed in the exam, by the way!). If you attempt to use a netcat listener to catch the shell, the connection will be received and then die instantly. Staged payloads are a smaller initial payload which then downloads the full payload from the Metasploit handler on your local box. They’re great if you don’t have much space for the exploit. Which should you use? It’s up to you. In the temperamental world of buffer overflows, sometimes one will work while the other won’t, so it’s good to have both in your bag of tricks!

Other MSFVenom options?

There’s plenty of other options to sink your teeth into, but they’re out of the scope for this article — Here’s a little list of the most common you’ll probably use that haven’t been covered already:

-e will allow you to choose an encoder, the most common of which is x86\shikata_ga_nai. This is great for avoiding bad characters and evading AV… Although, the latter isn’t so true anymore.

-b allows you to set bad characters. The bad characters for a specific exploit are often disclosed in the public exploit code itself.

— list (that’s two dashes) will list payloads and formats, for example, if you want to see a list of all the possible payloads, run msfvenom --list payloads

Privilege Escalation

Sometimes, privilege escalation with Metasploit is as easy as 1, 2, get_system. Unfortunately, without Metasploit, it’s not usually that easy. Let me start by saying, this is a huge topic. Far too large for my humble article, but I’ll provide a little primer here and try to point you in the right direction.

Firstly — no Windows privesc tips would be complete without a reference to the legendary “FuzzySecurity Windows Privilege Escalation” article. It covers the fundamentals of manual Windows privesc very well!

Secondly — Windows exploits can be annoying to get compiled on a Linux system. If you’re trusting, you can download pre-compiled exploits from Github repositories like this one.

Thirdly — That same repository comes with a nice spreadsheet which can help you identify which exploits are the most likely to work. You can download it here.

Catching Reverse Shells

The good news is, this process doesn’t change a whole lot in OSCP. The main difference is that you can’t use Meterpreter. How can we get around this? Just use plain reverse shell payloads instead.

Last I checked, you are allowed to use exploit/multi/handler in Metasploit to catch shells. This doesn’t have much of an advantage over using a plain old netcat listener though, seeing as you can’t use Meterpreter or Metasploit’s other features anyway. The only exception is if you are using an exploit which has restrictive space for a payload, in which case, you might need to use a staged payload.

Reminder: staged payloads don’t work with netcat! You must use Metasploit’s exploit/multi/handler module.

If you decide to go the Netcat route, simply start a listener using the following syntax.

nc -nvlp [port number]

Get More Hacking Tips!

I love writing articles to help out up and coming hackers. If you want occasional emails packed with hacking information, put your email in here:

You can also ask me questions and get in touch by following me on twitter!