Technical skills beginner pentesters need

Technical skills beginner pentesters need

Every week or so people ask me about how to get started in penetration testing. I love this question as it gives me the chance to help people get their start.

Sometimes I’m messaged on Reddit after contributing to getting started threads. A lot of the time it’s from people who are interested in Breaking In or have signed up for my 30 day email course (and if you haven’t you really should, it’s free).

Many of these people have different levels of skill and experience. There’s no one-size-fits-all answer. I thought I’d write about some basic technical skills beginner pentesters need to learn. Some of these things are expected. Others fall between mandatory and nice to have.

Not having all of these skills shouldn’t stop you from getting started. Genuinely having some or all of these skills to even a beginner level will stand out on your job application, in an interview and when it comes to negotiating a starting salary. Don’t be put off if you feel you’re not at the right level. I’ve added some links to tutorials to help you improve in these areas. Just bear in mind that the only way to ensure you don’t get a job interview is to make sure you don’t apply for it. So if you see a job you want, regardless of how far down the line you are, you should still go for it. You can always say that you’re developing skills in the areas below.

You need to know how to use the command line

The one thing pentesters and Trinity have in common is their love of nmap.Did you notice that even in modern hacker films, the hackers always have a little black box on the screen with text going everywhere? It’s a cliché but it’s based in reality. Hackers and penetration testers alike use the command line a lot.

Our tools are normally command line based. It’s not showing off, it’s just the most efficient way for us to do our jobs. If we were Cisco router admins we’d spend a lot of time in console prompts too.

If you want to become a penetration tester you need to be at the very least comfortable with a DOS or PowerShell prompt. The best way to develop this sort of skillset is to learn how to write DOS Batch or Powershell scripts.

At Secret Geek there’s a post on Powershell for absolute beginners. It’s a good starting point and should take you no more than a lunchtime. Powershell Pro has 14 more in-depth Powershell tutorials if you want to go further. You don’t need to be an expert, just comfortable with the command line in general. If Powershell seems a little too much, try this complete DOS tutorial instead.

You need to understand Linux at a lower level than most people

If you look at penetration testing or hacking sites and tutorials, there’s a strong tendency to use Linux. There’s two reasons I use OSX in the Breaking In videos, which is that the hardware and OS platform are known to me and stable. That’s not to say that you can’t use Windows as a base OS. Look beneath the surface though and you’ll see I’m really using OSX as a bare metal hypervisor for Linux virtual machines.

If you start with something like Ubuntu, Mint or Fedora as a main OS and try to spend some time tinkering under the hood it’ll help you become more familiar with the environment. Setting up a VM to install and break into a Linux server is a great way to learn. In fact, we do this in Breaking In.

You wouldn’t expect to be able to comfortably find and exploit file permission weaknesses if you don’t understand how Linux file permissions work, nor should you expect to be able to exploit the latest vulnerabilities comfortably and effectively without understanding how they affect a system. A basic understanding of Unix file permissions, processes, shell scripting and sockets will go a long way.

The basics of file permissions are well explained in this blog post from Your Own Linux. It doesn’t cover things like setuid and setgid, but after working through the post above you’ll be in a better position to read something a little drier like this.

How to Geek has a really good simple introduction to shell scripting. We’ll come back to this later. Beej’s guide to Unix IPC is a little bit scary for beginners, but the part on sockets is a good read and handy reference for those comfortable with Linux under the hood. As for sockets, the main thing is to understand that from a Unix perspective, sockets and files aren’t far from being the same thing. From a TCP/IP perspective, they’re completely different. Which leads me to the next point.

You need to know TCP/IP at the packet level

Any idea what this is? Breaking In readers will knowI know what you’re thinking. This seems like an awful lot of work to get to before you can even begin learning penetration testing, right? Wrong. You can still learn how to penetration test and become a penetration tester without these things, but learning all of these things will make it easier and help you understand both how and why things are done a certain way. Bad pentesters know that things are vulnerable.  Good pentesters know how things are vulnerable. Great pentesters know why things are vulnerable.

Employers will hire a bad junior tester if they have to, a good junior tester if there’s no-one better, but they’ll usually hire a potentially great junior pentester in a heartbeat. If you don’t spend time learning the basics to make yourself a great pentester, you’re stealing from your own potential salary.

Penetration testing is about finding, qualifying and documenting vulnerabilities and weaknesses. As such, you’re often required to qualify a vulnerability by exploiting it. In order to bend or break a system’s rules you have to know what they are in the first place.

TCP/IP seems really scary at first, but the basics can be learnt in a day or two. In Breaking In I encourage readers to use a packet sniffing tool called Wireshark to see what’s really going on when they send traffic to a target instead of blindly accepting documented behaviour without understanding what’s happening. In the supporting videos I walk people through decoding and analysing TCP/IP at packet level and below.

There is a way of deferring this requirement, in effect a hack. If your initial focus as a tester is going to be on something where TCP/IP networking is less relevant, such as web-based applications then the need to know TCP/IP at the packet level drops, but never quite disappears. Before you start jumping for joy, realise that you’re going to have to learn other things just as intimately instead. In this case, the OWASP Top 10.

You’ll also need to know not only how HTTP works over the wire but also you’ll need to understand the Document Object Model (DOM) and enough SQL to be able to understand how SQL injection vulnerabilities work. You can become a penetration tester without learning huge volumes of things, but you’ll struggle and it’ll be a much less rewarding career.

TCP/IP is a complicated subject. The best reference I’ve ever had comes in two books: TCP/IP Illustrated volumes 1 and 2 by W. Richard Stevens. They’re the only two books you need. Anything else will be in a coma-inducing standards document called an RFC. Don’t worry, I cover RFCs in Breaking In as well as packet-level analysis of tools and techniques in Wireshark. If you just want an overview of TCP/IP, this page has some basic information on how it all works.

Programming helps, but isn’t essential from day one.

If you write code like this, don't mention it in an interviewThere are some things that you need to get that first penetration testing job. There are others that aren’t essential but if you have them can lead to a better starting salary. Being able to program (and even better, debug) is one of those things.

At the very least being able to write a DOS batch script and a Unix shell script before you go into an interview will help you set yourself apart from other juniors. If you can’t program then you’re at risk of losing out to candidates that can, while at best you’re possibly going to lose money from that starting salary. Why? Because your prospective employer is going to need to give you time to learn these things if they’re going to get the most out of you. So don’t steal money from your own career, learn to program. It’s not hard.

Being able to program means you can write tools, automate activities and be far more efficient. Aside from basic scripting you should ideally become at least semi-comfortable with at least one programming language, and cover the basics in another.

Lots of web people like Ruby. Python is popular amongst reverse engineers. Perl is particularly popular amongst hardcore Unix users. I’ve written shockingly bad code in all of them. You don’t need to be a great programmer, but being able to program is worth it’s weight in gold, and most languages have online tutorials to get you started.

If you haven’t already, write some small tools and supporting documentation that demonstrate your security knowledge in your preferred programming language. It doesn’t matter if it’s a basic port scanner or an implementation of a tool that already exists. What’s important is that you have something to shout about on your CV or Resumé as well as provide talking points in any interview.

Even if you just set up a github account, work through some basic programming language tutorials and push the output to your github it shows that you’re keen to learn, that you are learning under your own initiative and that you’re building up basic useful skills. You don’t need to spend all your time on this. Even regular commits each month will be enough to show you’re regularly improving yourself.

You need to play to your strengths

If you’re a web application developer, start out by looking at web-application security. If your core strength is in radio, look at RF security. Big on electronics? The Internet of Things is there for you. Develop mobile apps? Then mobile security is where it’s at. Focus on the areas where you have background domain knowledge, that is to say where your knowledge and experiences lie. Then fill out your knowledge from there.

Once you’re comfortable, start looking to develop tools, scripts, material, anything relevant that you can use to demonstrate your knowledge. Then put it out online. In my 30 day career hacking course, I stress the point of having even small things you’ve done online so people can refer to them in written documentation and in conversation.

Final thoughts

If you’re missing some or all of the things above, don’t be upset. You can still work towards getting a job in penetration testing, and you don’t need to be an expert in any of these things, they’re simply technical qualities that make you a much better (and probably better paid) hire from a hiring manager and supporting interviewer’s perspective.

If you’re a really unlikeable person being technically brilliant won’t save you, and most teams are looking for people to round out specific gaps rather than someone who scores perfectly at everything. As with all aspects of any job there are more than just the technical qualities to consider. I cover this and more in my free 30 day online email course on hacking your career. If you’ve enjoyed this post, you might find the content useful, so sign up below. You can always unsubscribe at any time.

What others are reading on Raw Hex

Tagged , , , .

Steve is a full-time penetration tester and founder at Mandalorian and co-founded UK Information Security Conference 44CON in 2011. He is also the author of upcoming penetration testing guide Breaking In.