Tips for an Information Security Analyst/Pentester career - Ep. 86 - Experience-based tips 101 (no. 3)

I've been working as a pentester for almost two years by now, dealing with increasingly complex situation and technical challenges, especially as to internal engagements.

I think it's important to take the time to have a look at what I learned from this journey so far, and share these lessons with newbies out there approaching this industry for the first time. I hope these few considerations can help you guys avoid or minimize some major mistakes we all did when approaching your first pentests.

Before I get into them, though, I believe having a company that allows you to fail to a certain extent and has your back when things go south is very important.

I admit I got lucky, under this point of view.

a) PASSIVE RECON-GET YOUR SCOPE RIGHT: you were given a scope and you're eager to jump into action, so you're ready to fire up your Nmap and go. I know, I've been there myself, but not so fast yet.

Before scanning specific IP addresses, make sure they actually belong to the client. Run passive recon with shodan, censys, dnslytics, netcraft and other tools (as a shameless plug, I also use my script for this). If the in-scope hosts have web ports, check their SSL certificates through the above-mentioned tools and make sure they're referred to the client. In other words, if you're pentesting ACME LLC, make sure the SSL certificate for the hosts you're scanning is directly registered to ACME LLC, or it can be associated with it another way, indirectly. I sadly had to learn this lesson the hard way.

ONLY WHEN YOU'VE PROVEN OWNERSHIP, YOU CAN START ACTIVE RECON. If you don't follow this rule, you could end up scanning addresses you're not authorized to scan, which can cause you and your company legal issues. ACCOUNT FOR THE CHANCE THE CLIENT MIGHT MAKE MISTAKES WHEN GIVING YOU THE SCOPE.

You might think, "Well, they gave us the scope, it's their computers, so how can it be wrong?". Sometimes, even the client can make mistakes, such as typos or wrong CIDRs. If this happens, and you don't catch it right away, you might end up scanning a series of IP addresses that doesn't absolutely belong. That's why double-checking ownership is important. If you see a specific IP address doesn't belong to ACME, LLC (in our example), but to a completely different organization (say American Wheels, Corp.), that's a red flag and means something's wrong with your scope, unless the two organizations are somehow connected (e.g. the latter organization's brand belongs to the former, or vice versa), or they merged.

As a hands-on example, one IP address we were given for a pentest had a typo and it wrongly resulted to be located in France. The client didn't have offices in that country and so we noticed it right away but, if this wasn't the case, that could've opened a whole can of worms for us. So you need to get your scope right in the first place. Additionally, sometimes organizations use IP addresses belonging to an ISP which manages a large network space, splitting it among different organizations, so it's important to make sure of what the client's specific network range is. A useful tip to solve this problem is to use Nmap for reverse DNS resolution. Running Nmap with the -sL switch allows to resolve an IP address to its hostname or DNS name, which can be useful to double check if it belongs to the client's organization.

b) MAKE SURE TO THROTTLE DOWN YOUR SCANS: Nessus, Burp and Nmap scans can sometimes cause sensitive network devices to crash. You might want to throttle down your scans, especially when dealing with healthcare clients, as they can have sensitive medical devices connected to the internet in their network.

Nessus is a major culprit because it can generate a real high traffic volume. 

I recommend to check the options located in the Nessus Advanced  tab. Under the Settings and Performance sections, you should enable the options that are shown as disabled (as they're disabled by default). This allows for scans to be less invasive and to generate a lower amount of traffic. As for Nmap, you want to avoid using the -A parameter or running potentially intrusive scripts that might cause a denial of service. As for Burp, going to Dashboard/Settings (the gear icon), you can lower the amount of requests per seconds generated and add a time delay between each single request. Burp is a massive RAM hog, so I always do that.

c) GET CLARITY ABOUT WHAT IS ALLOWED AND WHAT IS NOT AS TO YOUR EXPLOITATION: 

Are you allowed to run an exploit at all and, if so, can you run it right away or do you have to alert the client and then wait for approval? If you were supposed to get approval before running an exploit and then you crash a server because of that, the client might not be particularly happy about it.

d) INFORM YOUR CLIENT RIGHT AWAY WHEN A CRITICAL FINDING IS VALIDATED:

I sometimes happen to get a shell on one or more machines, and also to dump and crack password hashes, or anyway I'm able to validate another type of critical finding (such as SQLi). Especially when the finding is referred to the client's external network and can be easily exploited through a browser over the Internet, you need to inform the client right away about that, because some bad guys could be leveraging the same vulnerability on that very moment, and your mission is to stop them, before they exfiltrate proprietary information. Refer to the ROE for the specific person(s) to contact under this scenario, but you'd normally have this information down way before the pentest got even started.

Wrap-up

Penetration testing isn't for the faint of heart, it requires hard work and attention to detail. The possibility for you to majorly screw up a pentest is always round the corner, and that's why I check myself thousands of times and I'm always paranoid and on my toes when I work on a project.

Experience is such an entry barrier to this industry, and there's a very good reason for it. In fact, there are too many opportunities for newbies to mess up and cause major troubles when they start out in this industry, due to its complexity and the learning curve you need to face. If you don't have any prior experience doing this, you simply don't know and might think you're doing a good job when you're not even covering your bases. Sadly, there's only one way to learn: fail and fail fast. I played in my virtual lab for four years before being a professional pentester, but that barely prepared me for 10% of what I had to do. 

I mostly had to learn on the job and figure things out on my own. I was very lucky with my supervisors and my company culture, as I was always supported and often was given the right tip at the right time to solve a challenge and score a vulnerability.

There's not a lot of hand-holding in this industry, and that's why I believe OSCP is pretty realistic under this point of view, even though I don't think the exam machines you get always reflect real-world scenarios. However, they're a very good indicator of what an actual pentest really looks like most of the times, in terms of the steps you follow and of the structured procedure you need to have down for you to do a good job.

One recommendation is not to overthink this, though. You'd be surprised to know how many Windows 2000, Windows Server 2003 and Windows XP machines I spotted over my engagements.

Additionally, you'll never be 100% ready for anything in your life, so just do it, but be aware of the challenges you'll get. 

I hope these few humble tips can help you guys approach this industry more effectively.

Good luck and ad maiora.