Tips for an Information Security Analyst/Pentester career - Ep. 74 - Experience-based tips 101

I recently started a document where I'm storing all the lessons I'm learning out of experience from being a professional penetration tester and from dealing with larger and more complex engagements.

These notes mostly include technical considerations but also some behavioral tips on how to deal with problems you might face with your clients.

I thought these notes could help some of you understand what real-world penetration testing and hacking is all about and how to troubleshoot issues. 

Of course, I'm not sharing any confidential information or details whatsoever about my clients, but these lessons can be valuable regardless, even if you don't know all their related details.


EXPERIENCE-BASED TIPS

a) Faster Nmap scans for large or very large networks (especially when having time constraints):

1.     Avoid using -A: The -A switch causes Nmap to use --traceroute, which slows down scans, causing them to loop, so it should be avoided when time is an issue. The difference is quite dramatic. When this issue was pointed out to me, I could scan a /16 network in a few hours, whereas Nmap was hanging for days with the -A switch. On the other hand, this way you get a less thorough recon on the operating system version running on live hosts.

         Reference: https://nmap.org/book/man-misc-options.html.

2.     Use -O for OS fingerprinting: I'd recommend performing a separate scan for this purpose.

3.     Use -T5: T5 (insane) is the fastest timing parameter you can set up on Nmap and makes a big difference when time is an issue, but it can lead to missed ports, so use it cum grano salis. I normally use -T4, but definitely recommend using -T5 when short of time.

4.     Use the --open switch: This switch causes Nmap to display open ports only, which can allow for a much clearer picture of what's running on the target network. I recommend this option for Metasploit integration. If you want to scan for Eternal Blue, for example, you want to have only hosts having port 445 TCP open, and not those for which said port is closed or filtered, as well. If port 445 is not open, you're wasting your time because the exploit won't work.

5.     Use --top-ports switch: Nmap normally scans for the first 1000 ports, so scanning a very large network can require a lot of time. Especially when time is a constraint, the --top-ports option can speed up scans. I believe --top-ports 100 or --top-ports 10 to be good solutions but, for huge networks, you can also use something like --top-ports 5. The latter option, though, doesn't scan for port 3389 tcp (RDP), which is very important. You could also create your own customized list of ports with -p and a comma-separated range of ports (e.g. -p 21,22,23,25,80,443,3389).

Quick and dirty scan command for large subnets: 

 

With added OS fingerprinting:

b) Pentesting engagement tips:

1.     Always run the screenshot command from your Meterpreter session, when shelling a computer, to see what's running on it. 

    I could get a shell on two computers over the course of a pentest. Out of curiosity, I decided to run the screenshot command from my two open Meterpreter sessions, and I saw something that freaked me out. 

    These outdated systems handled the security cameras for two different bank branches. Sadly, my exploit had crashed the software handling said cameras, which wasn't responding anymore. I had no idea about that, and there was no such information in the scope or in the rules of engagement (ROE). I'd never thought someone would handle such important systems through an extremely vulnerable configuration of that kind, but that's what I had there. I'd never know about that, though, hadn't I run the screenshot command, so from now on I'm gonna always run it after getting a shell on the target system.

Disclaimer: This image has nothing to do with the above-described pen testing engagement. I'm not mentioning any details here that could lead to identify the client or their systems. I care for my clients and for my professional reputation.

Should some bad guys rob those two bank branches, it would've been on me. I was freaking out, but I knew I had to do something about it asap, which brings me to the following lesson learned.

2.     When something breaks over a pentest, as a consequence of the exploits you used to gain access or not, ALWAYS tell the client and try to fix it and bring it back up. ALWAYS OWN IT! Don't be sloppy and leave the client up a creek without a paddle. They'll appreciate your concerns and you'll show like a professional who cares about their clients' security all the way around, and not simply like a childish irresponsible red teamer. Don't hesitate going through the rabbit hole to gain clarity about it. I could find the correct file path to the executable that had crashed by downloading the Application event log, so I killed its crashed instance, restarted it and brought the surveillance system back up for both computers, getting a huge weigh off my chest. I wouldn't be able to sleep at night, otherwise. Our contact in the company was pleasantly surprised to find out hackers can fix things, too, other than breaking them. Well, that's how I do it. I've been on the other end, so I know how bad such a situation can be.  I knew some poor guy would have to make an overnight trip there to fix the issue, hadn't I done anything, and it didn't feel right to me.  

The purpose of a pentest is to help the client's business and that's always in my mind. I didn't want to screw them up that way. However, I felt I was doing my duty, on the other hand. If I didn't hack in those systems, showing how vulnerable they were, some bad guys could've crashed them and performed a quite easy robbery.

3.     Always run EyeWitness to screenshot the servers, so you can have a bombproof documentation on what's running on the client's network, which can be used to reaffirm your position in case they push back on something. 

     Clients may sometimes live in denial. In one case, a client pushed back when we told them they had outdated Windows server versions. Nmap results can be questionable and discussed, but you can't argue against a screenshot displaying what's actually running on a specific system. That can't be faked.

Wrap-up

Experience is invaluable in the penetration testing industry, for very good reasons.
If you never worked in this role before, you can't know what it's like dealing with very large networks with a humongous number of clients running the most diverse services you can imagine.

There's no substitute for that.

No virtualization software can replicate the complexity of such networks, their related problems and their one-of-a-kind implementations.

That's why I'm trying to maximize my professional experience and grow faster by reflecting on lessons learned, so I won't repeat the same mistakes over and over again.


This is very hard to do when you're busy with a bunch of projects, reports, debrief calls, you name it, but it's very important for you to grow professionally.

I often regret making certain decisions and making certain mistakes, but I'm trying to learn lessons from all this.


The lesson learned about the -A switch in Nmap, for example, was pretty painful but now I'm not repeating that mistake anymore.


That's how you grow, by learning from your failures.

You need to fail and to be allowed failing.

My company has my back on this, and I'm very thankful, but I also know they wouldn't be so happy if I repeatedly messed up with the same things. 

So, fail but learn from your mistakes and try improving one baby step at a time.

One baby step at a time every day makes for a giant leap in the long run.