![[FCO]FreeCoursesOnline](https://onehack.us/uploads/default/original/3X/b/4/b4d2fc8468becec1e9976784dba394e5a378ec81.jpg){kind=small}
Hackers Pentesters who are new and aspiring to be good one often make few very common mistakes, here I am sharing them so they may take a note of these.
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 a 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 with 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 be 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 serialization issues are a common example of bugs for which you will get code execution followed by a HTTP 500 error since the payload will trigger an unexpected behavior .
“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 extent) 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 a 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 a 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 favorite 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.
Conclusion
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)
Source: ethicalhackx