10 common mistakes aspiring/new pentesters make

At PentesterLab, we have been helping thousands of people become pentesters or better pentesters:

From that, we put together the common mistakes aspiring pentesters make.

Only reading books

Don’t get us wrong, books are great. The problem is that a lot of people focus on reading books instead of gaining real hands-on experience. You can’t read about a bug class and expect to know about it. You need to see how the server responds, what happens if you try different payloads, how to debug your payloads. This is the only way to progress and to gain real understanding of security issues.

Practice makes perfect

Read books, but use them as an introduction to something you want to learn.

Kali everything

Another very surprising misconception is that you need this kind of magic “HACKING COMPUTER” to perform pentesting/hacking. And you need to attack with your Kali system (directly or in a VM).

Kali is an extraordinaire potpourri of pentesting tools and is very handy when you get started for some tools that can be hard to install (especially Wifi drivers). However, you will probably be a lot more comfortable and efficient using your everyday OS and not jumping from your system to your “hacking VM” all the time. Especially if you are doing or learning web testing, you probably rarely need to use Kali. It’s also not always a good idea to run Kali as your main system as you will probably need to run other tools (productivity tools) that may be harder to get working on it (as opposed to a boring standard Linux distribution).

An error means it didn’t work

We get a lot of questions around payloads that didn’t work even if it did (visible thanks to our scoring system). Getting HTTP 500 errors doesn’t mean you didn’t successfully exploit the bug. Shellshock and a lot of serialisation issues are common example of bugs for which you will get code execution followed by a HTTP 500 error since the payload will trigger an unexpected behaviour.

“How can I make sure it’s not vulnerable”

When doing a blackbox test, aspiring/young pentesters always want to make sure a system is not vulnerable (“How do I know I didn’t miss something). The truth is that you can never be 100% sure that a system is not vulnerable during a blackbox test. You will just make sure you run out of test cases to check if it was.

Spending too much time learning reversing/exploit writing instead of assessing systems, mobile and web

Reversing and writing exploits are amazing things to do and you should definitely look into these two domains. However, if you want to break into infosec and score your first job, you need to be good at web (and mobile and network to a lesser extend) security. Most pentesting companies have a lot of their workload composed of web testing and this is not going to change in the next few months. Furthermore, they also have seniors people who are dying to do more research and will probably have priority on all the reversing/exploit writing jobs. So if you want to increase your likelihood of getting hired, you need to become a gun at web pentesting.

The same thing applies to Bug Bounty, only few bounties require people to do reversing, most of them are web or mobile based.

And if you want to learn web security, no better place than PentesterLab ;)

Reading a lot of security news without going in depth

This one is actually for a lot of people. When you read security news, try to go in depth on at least one subject. If you read a CVE:

  • Try to get a diff of the fix
  • Try to exploit the issue
  • Try to understand the root cause
  • See if you can find a bug bounty program running the same application or with a similar issue.

Doing that once a week goes a long way.

You can stay a passive observer or become an active learner!

The same applies to conferences! After a conference, try to pick one talk and reproduce it.

Spending too much time building the perfect lab/laptop/…

Don’t waste time getting your perfect setup with a full network and multiple ESX servers as well as the perfect laptop. Just get started. It’s always easy to procrastinate and push back on what really matters. Don’t stay in your comfort zone. Just get started, start learning/hacking even if you don’t have the perfect setup. Truth is, there is no perfect setup and your needs will evolve over time with your work and research.

Not writing code/script

Like you should expect a developer to know some security’s basics in 2018, you should expect a security engineers/pentesters to be able to write simple programs/scripts to perform basic tasks. As a tester, you need to automate stuff all the time. You need to be able to write small script:

  • Write a small TCP client without too much search
  • Parse a CSV file to extract a column without any Google search
  • Send HTTP requests based on a previous script (for example)
  • Write a decent size tool (as in more than 1k loc).
  • How to use regular expression

Not reading code

To become a better tester, you need to read code. As a (web) pentester, half of your job is to understand what the source code on the server side looks like (for the client side, you often get the code). Guess what… reading a lot of code helps tremendously with that! You will also learn what mistakes people usually make. You can also read the code of your favourite tools to get a better understanding of their inner working as well as their limitations.

Learning 20 programming languages

It’s a common mistake to try to learn too many programming languages as well. Don’t get me wrong it’s a good idea to know a lot of them and their differences (especially to write web shell and for CTF). But before doing that, you need to learn at least one language pretty well.

For example, you need to know:

  • How to disable/enable certificate verification in this language
  • Common mistakes you can make that introduces vulnerabilities
  • Good resources about this language
  • How to quickly patch some code to make something work

You should also understand (and be able to write) common programming patterns like:

  • Running code in parallel (thread/fork/…)
  • Publishing/consuming to a queue
  • TCP and UDP client and server
  • Reading data from STDIN.

Once you grasp harder concepts in one language, you will get a better understanding of common patterns and mistakes (vulnerabilities?) associated with those. This will help you find more bugs.

Finally, once you know one language well enough you can learn another one just by comparing it to the one you already know.


Hopefully, this list helped you a bit and you will avoid falling for some of these mistakes. The most important is to remember:

The only real mistake is the one from which we learn nothing — (Henri Ford or John Powell)
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.