Posted on 2022-10-10 by Nathan Jarvie in Industry
Part 2 of the Sysadmin-to-Pentester series is discusses the differences between the idea and the reality of being a penetration tester. The certifications and the industry paint a picture a little different from the reality. A better understanding and more preparation towards the roles requirements will help you to decide if this is the role for you and how to ace the interviews.
You’re a hacker you say? Oh, you sweet summer child…
At the time of publishing this blog, I have been a pentester for a little over a year. During this time, I have learned that being a good pentester involves more than just hacking things. I believe having a good idea of the responsibilities and expectations that come with being a pentester ahead of time would have helped me to better prepare for the role, and possibly land an interview (or job?) earlier. While some of the courses and materials touch on these subjects lightly, they do not emphasise them nearly as much as they should for new blood.
I have broken them down into three sections:
- Testing expectations
- Interpersonal skills
- Reporting
Testing expectations - Poppin’ shells
The first thing is that pentesting courses and online training such as HackTheBox and others, along with shows like Mr. Robot, romanticise hacking and give students the impression that they will spend all their time tapping away at their terminal, getting shells and root privileges left, right, and centre because they are a hacking god. Some training providers even encourage students to believe they are in it for themselves and that asking for help is weak and if you do you suck.
The reality of the situation is very different, and it took a while for me to adjust.
While this is not true for everyone, the majority of testing I have performed has been for web applications or from an external perspective, rather than internal testing. So instead of going on site, plugging in to the network, poisoning connections, dropping kernel exploits, and getting Domain Admin like a boss, I am manipulating requests in Burp Suite and running scans from my home. Sometimes I wear pants.
While it is possible in some cases to gain a shell through externals and web apps, and I have done it, it is not common at all. As pentesting is often a requirement of the development/project management/implementation/compliance process now, it is likely that the application or service you are testing has been tested before, so the low hanging fruit has already been picked.
For example, you have a client who has to have their external environment pentested every year for compliance, but they don’t host any services. So you scan the in-scope IP addresses, you do your OSINT, you find no open ports, no working credentials, no way in within the confines of the scope. Now you have to produce a report with little or no findings. Not because you are bad at your job, but because there is nothing more to find.
This takes a while to get used to, and certainly doesn’t help the imposter syndrome. Luckily for me, and hopefully for you, your team can help you verify your tests, check whatever findings you have, and confirm you have done everything you can. Then you can contact the client, explain your findings (or lack there of), produce your report and move on to the next job.
Just a quick note on reports with little to no findings. Writing these may seem like a waste of your time but I can assure you they are not, and they will be some of the hardest reports you will have to write. A normal penetration testing report focuses on the elements that did work throughout the test (i.e. what was vulnerable and actively exploited) and generally ignores the parts that didn’t. A report with no findings is the opposite, and focuses instead on the elements that didn’t work; drawing attention to the fact that common or even advanced tactics were ineffective. This kind of report is important for clients to prove their security posture (maybe for insurance?) and have confidence in the work they are doing. It also works to compare year-on-year when new attack paths are discovered that were not previously tested (because they were unknown).
Personal Skills - You mean I have to talk to people?
While hacking can appeal to anyone, there is certainly a stereotype of us being hoodie-wearing antisocial basement dwellers that you need to contend with in the corporate world. In comes Personal skills (sometimes called soft skills).
From discussions with my peers, the personal skills of the tester are more often the ones that seem to make or break people in the industry. The InfoSec industry is heavily reputation based. We aren’t offering a unique widget that only we can sell. We are selling a service offered by many others, including some really big players, so you need to give the client something that only your team can offer.
Your reputation for being reliable and accurate is what will set you apart from competition. There is a big difference between a penetration test by a skilled professional and a run-of-the-mill “automated penetration test” (read: vulnerability scan).
Talking to clients, getting to know what they would like to achieve from their test so that you can provide the most value to them is the best way to separate yourself from the rabble.
- Are they pushing for change in the organisation?
- Is it for compliance?
- What are their expectations of the test?
- Have they been tested before? Were there any holes that need to be re-tested?
- What data would have the largest impact for the business if compromised?
These are all questions we can ask that a malicious hacker cannot, and an unskilled pentester would not. It is important to understand that we have limited time during an engagement to provide an accurate assessment. Accurately gauging testing requirements and expectations will help to improve your efficiency and most importantly, provide valuable feedback for the client. Sometimes there is a discrepancy between us and the client as to what is important or of high or critical impact, and these conversations can help to bring us all onto the same page.
Getting Domain Admin is great, but there can be more impactful things for the business than that. The test of a good pentester is not whether you can get DA on their internal environment (you probably can) but what else you can do?
- Can you see all their cameras? Can you modify the footage?
- Can you unlock doors?
- Can you read privileged data from a low priv account?
- Can you bypass access controls, like MFA, or 802.1x?
- Can you get on to their WiFi?
- Is there personally identifiable information (PII) on the network?
- Children’s information?
- Medical records?
- Do they store cardholder data?
- Is it accessible?
- Is it encrypted?
All these things can be more impactful to the client than getting Domain Admin in the right context, and more importantly, better understood by the executives who have to read the report. Getting access to cameras or PII in a school, hospital or a bank could be a huge problem. So spending the time to find out what is actually important to the client, then prioritising testing and findings around the areas with the largest impact is valuable, and more efficient for you as a tester.
While it’s valuable to go in completely blind and try to find every little thing you can, you will often not have enough time to do so, and may miss something important. Handing the client a 150-page report of every internal SSL/TLS vulnerability you can find but missing the fact there is publicly exposed PII of children, because you didn’t know it was there, is not good for anyone. Speaking of reports…
Reporting - So many reports…
As a pentester (or just about any role in InfoSec), you will need to read and write a LOT of reports.
Every company approaches report writing differently. We all do what we can to provide as much value to the client as possible. In saying that, the way we do reports at Volkis may differ from your workplace, and that’s OK. But here are the things I have learned to take into consideration when writing reports.
Our Managing Director, Matt, was explaining to us recently that there has been a shift in regards to who reads a pentest report. The reports now often get broken up and individual parts get sent to relevant people with different technical expertise. From the C-suite to the developers, anyone may see a part of your report.
As a result, when you write your report, for non-technical sections (executive summary, report body, conclusion, etc) keep it non-technical. The person reading your report may not know the difference between local user and domain administrator privileges. They won’t understand the jargon. Keep it simple, explain the problems concisely, the root causes and recommendations. Leave the technical recommendations and jargon for the attack walkthroughs or vulnerability write-ups, which are generally read by the technical team.
Secondly, use a risk matrix. Just because a Nessus scan says a reported vulnerability is critical, doesn’t mean it is. When evaluating the risk of a vulnerability, take into consideration the impact of exploitation specifically to that client. Evaluate the likelihood of exploitation given the vulnerable system’s position within the network. You will often find that during your debrief session with the client, that they will question the severity of Critical and High risk vulnerabilities, which is perfectly understandable. So if you believe something is a Critical or High risk you need to justify it, and “the scanner says so” is not a justification.
This brings me to the next point. This one may be unique to Volkis, so feel free to take what you will from it, but we believe no one find value in 150+ page reports of every single informational-level vulnerability that could possibly be found. That’s what vulnerability scanners are for. Pentesting reports should be actionable and concise. They should outline the places of weakness that a business can address in a reasonable amount of time.
During our discussions with the client we, as professionals, can determine who is going to read the report, the level of detail they want us to go into and whether they plan to get tests regularly. We focus on the highest impact vulnerabilities, and anything with quick wins, then work our way down the list as time permits, because information overload often results in nothing getting resolved. So instead of 100+ pages of information-level filler, we have shorter reports with clear vulnerability write-ups, remediation or mitigation techniques and an attack walkthrough that can be followed and actioned by the client.
Also, please remember that our role as pentesters is not to name and shame people for making poor configurations or patch management. While we are there to be impartial and provide feedback on the environment as it stands at the time of testing, feedback can and should be delivered with empathy. Developers and System Admins can get defensive and feel personally attacked when a vulnerability is found in their systems. I can tell you this with experience from both sides of this fence. When writing your report and debriefing the client, keep this in mind and try to curb your language as to not lay the blame on anyone.
Security is hard. Especially for those for which it is not their primary role.
On the next episode…
The next part of this series goes through some of the things I wish I had done to get noticed in the sea of resumes, recruiters, and employers in the cyber security space have to deal with.
Next: Part Three - How to stand out in a crowd of paper
Previous: Part One - The hard way
About the author
Nathan is certification addict, he can’t stop and it’s becoming a problem. We can’t talk to him about it directly but consider this a call for help.
If you need help with your security,
get in touch with Volkis.
Follow us on Twitter and
LinkedIn