How Do Hacking Challenges and Certifications Differ From An Actual Hacking Job?

There are four locks, one of them is RED! And it’s not even locked. Obvious security flaw here.

Since writing my last article “How To Get Your First Job As a Hacker” I’ve had a bunch of people reach out to me on Twitter with various questions about their career path into penetration testing. Most of them go something like this:

I have some experience in programming and I’ve been attempting recently and I think I want to be a penetration tester! How does an actual penetration testing job differ from these challenge sites and what can I expect day to day in that role?

It’s a great question — and one that I remember asking myself! Let’s dive in to some answers.


Not the most exciting part of an engagement, still important!

If your hacking experience is based on challenges alone, there’s a good chance you haven’t bothered to report anything. Hacking challenges are fun, just owning the box and getting the flag is enough! As a penetration tester, reporting is a large part of the job, and is just as important as the actual hacking. If you’re working for a security consultancy, there’s a good chance they will have strict guidelines about the reports they send to their clients, and you will be the one writing them. It is important that you are able to write and communicate with the client accurately, and professionally.


Other than a few rules, you can usually pretty much do whatever you want in a challenge environment. Hack everything! Run exploits that risk crashing machines, run over-ambitious port scans, be noisy! In a pentest scenario, you will likely not have such freedoms.

In my experience, most companies are eager to know about vulnerabilities in specific applications or segments of their infrastructure, but they often aren’t comfortable letting a hacker loose on others (fair enough!). That’s why every engagement will have a clearly defined scope. They may provide a list of applications, services, IP addresses or domains. They may also lay out exactly what you are (and are not) allowed to do during the engagement.

As a penetration tester, it is important to take the customer’s well being into consideration while attacking them. For example, if you find an SQL injection on a production system, don’t drop all their tables. Testing their account lockout policy? Do it on a test account, not one of their staff!


In a hacking challenge — there is always a major vulnerability, if it’s a CTF style challenge like, then there will always be a way to gain root level remote code execution. When you’re dealing with real life systems, fortunately, this isn’t always the case. This fundamental difference requires a deep shift in mindset.

I’m sure you have read somewhere before that you should go for the “low-hanging fruit” first. In other words, identify the weakest link in the target’s infrastructure, and attack that. In the real world, this is extremely useful advice. It is also exactly what a cyber adversary would do. When you are in a network full of challenge boxes, this is not necessarily useful advice. You can usually just pick any box to start with, and attack it until you get root.


Information security is not a nerdy thing that some skids do after school, it’s a multi-billion dollar industry. Companies are taking information security very seriously, governments are spending a lot of money actively attacking each other.

As a penetration tester, you will find yourself dealing with businesses and government entities with serious responsibilities to protect their data and infrastructure. It is important that you think of your role in terms of business impact. Sometimes, gaining a database dump of user data is a far more serious vulnerability than gaining root on their web server (although, the two tend to go hand-in-hand). This also means that communication is important.


Often, the people you work with will not be security experts. There’s a good chance they are an IT manager of some sort, or the owner of a business. For this reason, it is important that you learn to communicate your findings in non-technical terms. If you’re dealing with a non-technical contact, rather than saying “after gaining access to your web server using shell shock I moved laterally to your MSSQL server where I was able to dump creds”, it might suffice to say “I was able to access your customer information”. A breach of customer information is a threat they can understand!


In a hacking challenge environment, there are likely to be some old, unpatched systems that are vulnerable to easy, one-hit exploits. They are designed to be easily breakable. In real-life networks, this rarely happens. Your attack vectors are more likely to be misconfigurations, weak passwords, coding errors, etc.

Get in touch!

So far, my favourite part of writing blog posts is that I’ve met a bunch of new friends. Since I have been more public about my career in cyber and immersed myself in the community, I have been overwhelmed by amazing people who make it up. Feel free to get in touch with me on Twitter or in the comments below!

Bye for now!


Pentester | Hubby | Musician

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store