10 Things I Learnt in My First Year as a Penetration Tester

Hello from the New Year! If you celebrate, I trust you had a fantastic Christmas break. If not, hopefully at least a wonderful few days off with friends and family. It has been a while since I put a post up, between working long hours and attempting to maintain a work-life balance, and also getting my backside kicked by APTLabs from Hack the Box, I haven't had the time nor inspiration. But alas, amongst the copious "New Year New Me" dribble that seems to be everywhere, I shall also be participating in making some changes. One of those changes is blogging at least once a month, whether it's to reinforce something I have been working on, or just to reflect on a period in life. Don't worry - It will always be hacking-related and not about my inability to improve my 5k time!

So to kick the New Year off, I thought a reflection of my first year as a penetration tester/security consultant would be a cool way to return. I've realised recently it's really important to give yourself perspective sometimes: Where was I twelve months ago and how have I improved? Sometimes we walk a path with peaks and troughs and fail to take a look back over what we have accomplished. I say twelve months, but it's been closer to fifteen. Sorry. Anyway, enough babbling, let's dive into my brain.

"Comparison is the thief of joy." - Someone smart once upon a time.

Standard CYA disclaimer: This post is comprised of my personal views and in no way reflects the views of my employer.

1. I am making progress, even when it does not feel like I am

Wow, that sounds like an affirmation. In a way, I guess it is. Before I started my job, I was a student with all the time in the world. I would smash out all my assignments as soon as I got them and get them submitted and then was left with X amount of free days to just hack. Course after course, video after video, it was a good 7-8 hours a day of labs and learning. Naturally, when you're doing this, you feel a sense of accomplishment as you have tangible achievements you are reaching, such as the completion of a course, the passing of a certification, and the development of a new tool. When I started my role, this all slowed down. Not because I wasn't looking to improve myself, but because client work comes first, and in an attempt to avoid burnout I'd skip the planned evening hacking session from time to time and maintain other relationships and work on side hustles. The client work sometimes felt like I was regurgitating all my existing knowledge into my next test without getting that recognition that I had accomplished something new. When I feel like I'm not learning, I feel like I am falling behind. Our industry moves so fast and it's imperative to keep up a reasonable pace. But had I truly not made progress? Of course not. I learnt the required time for specific scope sizes, to handle clients, to create professional and succinct reports, and to debrief findings to both technical and non-technical audiences... Along the way, I was learning how to approach different web technologies, evade SOCs, and set up infrastructure outside of a lab environment. I will stop there, as many of these will be touched on later.

The point is, that you are making progress when you don't feel like you are. Never be afraid to look back, give yourself a pat on the back, and put your feet up sometimes.

"Don't let perfect be the enemy of good." - Also someone very smart.

2. CTFs are not useless, but they are missing valuable components...

I have observed two teams in this debate. One side believes gamification has negative effects on the industry, leading to people trying to "gamify" clients as though they are a boss level to be conquered without fully comprehending the underlying fundamentals. The second side believes that the necessary skills can be learned as you go, and that technical prowess and knowledge of exploitation will pull them through interviews until they get that first role.

Newsflash, neither team is correct, because what works for one person won't work for another. I can guarantee that my addiction to doing Hack the Box machines and consequently Pro Labs helped me find some awesome findings on all manner of tests, which consequently improves my client's security posture and also encourages repeat business, which is far easier to obtain than new business. However, I have a couple of large caveats that I think are fundamental across both viewpoints.

One major point is that you have to understand what is happening behind the scenes. It's great that CTFs teach you how to perform a blind SQL injection or cool deserialization chain, but if you don't understand why it's happening, you cannot hope to help your clients either. And trust me, they will ask the questions you don't expect! Another aspect is your approach. Most CTFs have a reset button. Knock it over? Who cares! I'll spin up a new instance. Do that on a production database? Well, you won't have a happy client. Up against a Web Application Firewall? Better learn to find open ports and modify your testing approach accordingly so you still hit your assessment timeframes.

These little intricacies are often unspoken in a lab environment, and it's actively encouraged, with the "First Blood" style of competition that lots of labs/platforms suggest, to hammer it as hard as you can, as quickly as you can. Be mindful that this isn't going to work in the real world, and it may be beneficial to start approaching Hack the Box labs the same way you would approach a client's infrastructure.

3. Networking is far harder in real life

Back on the CTF style of conversation, let's chat about networking. I don't mean putting all my clout on LinkedIn, I mean the network style of networking. You know, TCP and UDP and all that jazz. When you want to do a practice box or set up a home lab for hacking, you simply configure your network adapters or connect to a pre-configured VPN and voila, you can hit what you need to start! In the real world, it's not as easy.

Want a shell on a web application you have remote code execution on? Better learn to set up a secure endpoint to catch it.

Want to set up an entire phishing infrastructure? Better learn how all the pieces fit together and are publicly accessible securely.  

Want to try and capture a NetNTLMv2 hash from an SSRF you've discovered? Better learn how to set up that SMB server externally and securely.

There's so much more to think about doing it in real life, and even more to consider when you know it must be secure and in no way present an autogenic risk to the client. My advice? Start spinning your home labs up in the cloud. Azure, AWS, GCP, do it all in there. Catch your shells on public boxes when you're practicing hacking, and set up your security groups and networking rules to protect yourself. Set up a phishing campaign and target yourself.

You will not regret this process, as it was a huge mental block for me trying to transfer all my previous "lab/CTF" knowledge to real-world assets and networks.

4. Don't be afraid to ask for help

Maybe it's the imposter syndrome, but I often felt when starting it was hard to ask for help. Fear of getting found out perhaps, not knowing something I should have done? Who knows. All I have realised now is that asking for help is not a weakness but a strength. Putting aside the fear, and allowing myself to be uncomfortable has been somewhat liberating. I can't know it all, and it's perfectly fine to be stronger in some areas than others.

"Comfort is the enemy of progress." - One of my good friends.

5. Persistence is your friend

Many times I've been testing an application or network for multiple days and come up short. Maybe they've been regularly tested, hardened by extremely talented security guys, and been through every process under the sun to try and ensure maximum resilience. But if you persist, and I mean truly persist... Often, you will be rewarded. I like to approach an assessment with the mindset that there is always a big issue to find, it's just about rummaging through the noise for that needle in the haystack.

I have learnt to never assume a target is secure because of any pre-conceptions I originally had about them. I treat every test as a blank slate, remove any thoughts of finding nothing at all, and persistently dig until something gives. And most of the time, something does indeed give.

However, if it doesn't, I am also trying to learn not to be disheartened. I perform time-based assessments, and the primary caveat that comes with that is I do not have infinite time as a threat actor does. But I will always stay curious and think outside the box, and that mindset has served me well.

6. Clients, their developers, and security teams are friends

Maintaining a strong relationship with clients and related parties has a multitude of benefits. Not only does it assist in the testing process, as both parties feel more inclined to ask questions and truly dig into the remediations, but it also helps to build a long-lasting connection that hopefully encourages them to return when they need more testing done. When they do, I know their infrastructure, maybe their code base, their applications, and all of these things improve the next test. I have also often found that this leads to the best remediation results, which at the end of the day, is what we are all doing testing for in the first place.

Keeping the bad guys out!

7. Get intimate with that infrastructure!

You may think that sounds weird. There's probably a better word for it but it's how I like to approach each test. I need to get to know how it works, how it all flows together, what affects what and how that can be influenced. You can follow methodology checklists all you like, but until you fully get up close and personal with whatever you're testing, until you truly understand how the jigsaw fits together, you can't hope to find the most dangerous issues.

I think this relates mostly to applications, but of course, it can be extended to networks. The best findings I have had are when I started to visualise the application holistically, rather than diving for whatever was interesting on the initial click-a-roo. However, it can be applied to all manner of testing and this was one of the major clicking points for me over the past year!

8. Time management is important

I don't mean whether you turn up for work on time, although I would urge you to do that anyway 😉 I mean managing your testing time is crucial. As I alluded to earlier, the majority of testers are running time-based assessments. A scoping document can only take you so far in predicting what you will need in days or hours to achieve your goal of a comprehensive assessment of your target. The ability to plan and manage the assessment timeframe is key.

This has led to me automating repetitive tasks to be more efficient, saving code snippets that I seem to use on frequently occurring technologies, and always having something running in the background (provided the infrastructure can handle it). The big curve, I suppose, was going from testing two or three machines in a CTF environment to then having to parse 500+ external IP addresses. This results in having to learn to prioritise information, such as where to focus your time and energy first. Tools such as EyeWitness greatly speed up the analysis of web pages in such situations to separate the wheat from the chaff.

9. Your technical wizardry is only half the puzzle

I don't think this was necessarily something I didn't know before starting my job as a tester, but it sure has been compounded in the past year. The bottom line is that the majority of clients do not care about how cool the exploit chain to leak all their customers was. All they care about is:

• How the heckers did you do it?
• What the heckers does it mean for me?!
• How the heckers can I fix it?!

Whenever I'm writing a report, these are three points that need to be conveyed without any waffle, and definitely without the excitement and adrenaline that flies around my body during the testing. Writing a solid report is just as valuable as being a strong technical tester in my opinion. There's no point in being a technical whizz but not being able to convey what you have found, and there's no point in being able to write fantastic reports if you have no findings to report on.

The PNPT and similar certs from TCM Security are probably the best for teaching this aspect of testing, as they focus on making a report that would mirror what you'd present in the real world, rather than the step-by-step exploitation guide that is needed during the Offsec exams.

Note: Both of these organizations and training/certification providers do have their own merits and I really like both, but I highlight TCM here specifically as the example reports they provide are some of the nicest I have seen in training materials.

10. Keeping relatively detailed notes is imperative

Closing this list out on an obvious one, but keeping detailed notes, grabbing screenshots of everything, and ensuring your logs have enough space (burp defaults to a tiny log size) is crucial. You never know when you, or the client, is going to need that extra bit of information!

Concluding Thoughts

And there we have it, you made it to the end. Congratulations! I hope the dribs and drabs from my brain gave you some inspiration, and maybe you can take a step back and look at what you achieved last year. It doesn't matter if it was your first year of testing or your tenth year of testing. Hell, it doesn't matter if you're a pilot or a binman. Look back over your past twelve months and hopefully you find at least ten things you have learnt or improved upon. Then go put your feet up and revel in your personal successes!

If you were expecting technical things I'd learnt in the first year of testing, bad luck. Those secrets stay safe with me! So what's next? Well, I'm glad you asked. It's time to deep dive into my CRTO2 (which has been gathering dust), spin up a load of cloud-based CTFs to allow my team to root me, and maybe, just maybe, hit up some revision for CCT-(INF/APP).

Until next time, folks! 🏄‍♂️