Tips for an Information Security Analyst/Pentester career - Ep. 88 - New Pentester? Less CTFs, More Ninja.

I've recently turned 3 years in my pentesting role and, over this time, I've trained new guys approaching the industry, every now and then.

Over time, I realized most beginners share a common mindset that can create issues when dealing with their first real-world engagements.

BACKGROUND

When newcomers attempt to break into the pentesting industry, the main obstacle they face is their lack of experience.

Experience is often a hard requirement as an entry barrier because real-world targets are much more complex and hardened, and way more prone to crash.

So, aspiring pentesters try to make up for their lack of experience by engaging in training platforms like Hack The Box (HTB), TryHackMe (THM), Offensive Security Proving Grounds (PG), and a bunch of other ones, you name it.

This is a good approach because:

1. It shows real motivation
2. Some vulnerable machines might allow to learn techniques that can be applied (to a certain extent) to real-world targets.

Some employers are open to invest on a beginner, if they think he/she can bring something unique to the table.

Also, being active in training platforms is sometimes considered as a plus that helps a candidate stand out, and might be a factor in hiring decisions.

This is awesome, and I firmly believe we need to give junior pentesters a fair chance.

I wouldn't be here talking about this topic if someone hadn't taken a chance on me.

Such a big CTF-oriented mindset, though, can cause some problems in the long run when working with real-world targets.

When moving to a real pentesting career,  you need to unlearn CTFs and become much more of a ninja.

After a while, you realize real-world targets are way more hardened and 99% of the scenarios you're used to are unrealistic. In other words, training platforms should resemble as closely as possible, but not replicate, real targets, the same way a practice exam doesn't necessarily contain the same questions you'll find in the real exam. They should prepare testers but not necessarily be considered as realistic scenarios. Other than CTFs, other paths like software development, programming or system administration can  be a real plus when migrating to pentesting. The time spent writing code on Python will pay off when you don’t have anything but Python. If you ever built a network, the knowledge of protocols coming from it might be the key to entering the network. If you ever held a sysadmin job, it might just be the knowledge you need to understand priv esc better. The more diverse your background and the technologies you deal with over your career, the better pentester you'll become. Even a project that might seem at first unrelated to security might come in handy at a later time.

ISSUES

1. Too much focus on tools
2. Jumping to conclusions overlooking recon
3. Using loud and potentially disruptive techniques
4. Overlooking the importance of documenting your work as you go

1. Too much focus on tools:

When you solve machines on platforms like HTB,  you're mostly focused on the best tools to get the job done (Recon? Nmap. Exploitation? Metasploit, etc.).

This causes new pentesters to be too focused on specific tools, so much that they get lost if they can't use them in the specific testing context. What if you don't have Nmap installed in a pentesting jumpbox, and don't have the needed permissions to install it? How would you go about it? You need to get the job done and deliver regardless.  That's when you need to learn how to live off the land, i.e. use the tools available on the testing machine. For *nix systems, you can use Python (if available) for port scanning. If Python isn't available either, you can use /dev/tcp, which is a native functionality, for the same purpose. Another solution can be using a SOCKS proxy. However, a SOCKS proxy can’t help you when you’re doing ICMP based attacks.

For Windows, you can use both Python (if available) or PowerShell (native).

Pentesters, and especially red teamers, need to learn how to perform their jobs without relying on specific tools. For example, you don't necessarily need Burp to grab a webserver header. You can use the developer tools in your browser, netcat, telnet and curl for this purpose.

Knowing common tools is a good thing but a hacker doesn't DEPEND on them. In real-world penetration tests, time is a factor and you're more often prone/forced to use off the shelf tools to complete the project within the allotted number of hours you got assigned. However, you also have to try alternative solutions when they don't work, or can't be used.

In red teaming engagements, you need to be as stealthier as possible, so installing new tools is not an option, cause you don't want to generate a revealing audit trail. Also, you want to generate as less noise as possible, so Nmap, for example, might not be the best tool for the job, because IPSs and SIEMs can recognize the traffic they generate.

2. Jumping to conclusions overlooking recon

In a pentest, even for repeat customers, recon is hands-down the most important stage.

If done correctly, it shows the tester what is running across the network and what vulnerabilities could be leveraged to get access.

If done poorly, it will lead to missed opportunities and no added value to the client.

 

A famous quote excerpted from ancient book Art of War, by Chinese general Sun-Tzu, goes:

"If you know the enemy and know yourself, you need not fear the results of a hundred battles".

 

 Most organizations don't know the enemy, nor themselves. Knowing the enemy can require a remarkable effort in terms of financial and non-financial resources (security consultants, honeypots, etc.) that not all organizations can afford, but knowing yourself should be imperative. If an organization doesn't know its vulnerabilities and its internal problems that could lead to a breach, it's already lost the battle, because no one will see the enemy coming.

Regardless of the operating system, for each in-scope hosts, a pentester should recon and enumerate all services and ports as more thoroughly as possible. Once you determined which services are running on the open ports discovered through the recon activity (Nmap), you're gonna need to run Nmap scripts to dig deeper and highlight potential exploit avenues, analyze the webpage source code, enumerate web directories through Burp, gobuster or dirsearch, run nikto and Nessus for vulnerability scans, and in general dig as deeper as possible.

Only after the enumeration is completed, it is now time to move to the validation/exploitation stage.

You can't exploit what you're not sure about.

A common error new pentesters make is to think a pentest is like a CTF, because they're used to completing a series of goals in a very limited time, so they think they need to rush the whole thing.

The most typical example of a CTF-like scenario (at least IMHO) is the OSCP exam, where you need to hack 5 machines in 23.45 hours.

This is totally unrealistic. I normally test machines for 1-2 weeks or longer (depending on the scope width) before wrapping up a project.

Due to their CTF-based mindset and to their strong desire to get a shell, junior pentesters may rush the recon stage and jump straight ahead to exploitation, without thoroughly enumerating the services running on the specific host(s). Needless to say, this is a recipe for disaster.

And, yeah, I've been there myself.

Projects deadlines are designed to give testers enough time to complete all needed stages. Overlooking recon leads to missed opportunities and to wrong assumptions. You need to understand what the discovery scans output shows, before even thinking of moving to exploitation.

You can't jump to conclusions without looking at what you have before you. In other words, ENUMERATE, ENUMERATE, ENUMERATE!

PENTESTING REAL-WORLD TARGETS AND ROOTING HTB (or alike platforms, such as PG, etc.) PURPOSEFULLY VULNERABLE MACHINES ARE TWO TOTALLY DIFFERENT ANIMALS.

Techniques working right away on a HTB machine often don't work the same way, or don't work at all, with real-world targets, because most organizations are very consistent in patching potential exploits.

This doesn't mean you shouldn't be practicing on those platforms, though. Research skills are paramount to grow in an industry where you're mostly required to keep training on your own, and no hand holding is expected, as things constantly change every second. I sometimes learned techniques from them (e.g. exploiting an unauthenticated Redis server) I could use in real-world engagements.

However, even when that happened, the specific scenario I was up with wasn't 100% like HTB, cause the real-world misconfiguration wasn't as severe. I was unable to retrieve SSH private keys, for example, but I could enumerate users, obtain configuration information, etc.

3. Using loud and potentially disruptive techniques

YOU NEED TO BE ACCOUNTABLE FOR YOUR TRAFFIC. It is vital to understand the implications of running Nmap with a specific set of options, and the risks it could cause. In fact, the more Nmap advanced options are used, the higher the traffic the scan will generate. This can determine two orders of problems:

1. When certain conditions are met, it can cause remote servers or fragile software components to crash
2. It can create a revealing audit trail, defeating the purpose for a red teaming engagement.
   

In fact, beginner pentesters are so eager to get a shell that sometimes don't consider the possible implications of their activity, and might end up crashing servers, getting blocked or blacklisted by defensive tools like IPSs, fail2ban, WAFs, you name it.

They're not used to account for this, because normally no such thing is in place for a purposefully vulnerable HTB, PG, or Vulnhub machine, for example.

In real-world, instead, if you attempt an XSS or a SQLi attack and the target has a Web Application Firewall in place, your attack will be stopped and your IP might also be banned, temporarily or permanently.

Sure, you can use a VPN, but you left a log behind. For red teaming, that's not exactly what you want. You always leave a log behind regardless of what you do, but you created a much more suspicious audit trail than you'd do otherwise.

Some specific Nmap options create a lot of noise and generate a great deal of traffic, which, in some cases, might lead to crash a server.

This is the last thing you want. No reverts are available for real-world targets. When you crash a server, someone will have to fix it. Additionally, you might end up taking down critical infrastructure, such as a VPN or an Exchange server. The last thing you want is getting a customer mad, because its employees can't log on to their VPN, or to a domain controller, to get their jobs done.

The more options you enable in an Nmap scan, the more traffic you can generate. In fact, if you add more aggressive options to the scan, like -A (which includes traceroute), you might even create enough traffic to crash a remote server, given certain conditions.

Therefore, while with training platforms you can attempt any type of brute forcing attacks and use any type of payload, no matter how noisy it is (meterpreter, unobfuscated malware, etc.) without worrying too much about it, you can't do this in real-world engagements, unless duly authorized.

THROWING RANDOM PAYLOADS AT A TARGET HOPING TO GET A SHELL IS NOT GONNA WORK, OTHER THAN OUT OF MERE LUCK. 

You need to make sure to research the right exploit (if any is available) for the specific vulnerable version working on the affected host(s), and you also need to make sure the exploit does what you want. In other terms, you need to read through the exploit code, understand what it really does and whether is what you need in your specific case, before even running it against a specific target.

Using a hands-on example, if your target runs Apache 2.4.29 and you found an exploit for Apache 2.4.28, that's not gonna work.

Then, you also need to pay attention to the type of vulnerability leveraged by the exploit.

If you want to obtain remote code execution and the exploit you're looking at refers to a denial of service vulnerability, that's not what you need.

I was like that. A long time ago, I was working on a Vulnhub machine with a friend and he made me notice that, though the exploit I had found was referring to remote code execution, some comments were mentioning a denial of service vulnerability.

I hadn't even looked at the code. I was like, okay it matches the software version, so it's a winner. WRONG!

A very good example of what might happen if you don't look through exploit code can be found here: https://isc.sans.edu/forums/diary/When+is+a+0day+not+a+0day+Fake+OpenSSh+exploit+again/8185/

Of course, for red teaming engagements, this is an egregious no-no.

4. Overlooking the importance of documenting your work as you go

Documentation is paramount to writing a good report, so a pentester should document each step and each findings as the testing goes.

Being systematic in taking good notes and screenshots along the way is critical, especially for internal pentests.

Things might change at a later time over testing, or (for internal engagements) it might not be possible to document things later on, cause you're no longer allowed access to the internal network after wrapping up testing.

For example, I found some FTP servers were exposed externally, which is never a good thing.

I had taken a screenshot of that at the specific moment in time when I discovered them. Later on, over the report writing stage, I tried to connect back to those server, but they had been taken down.

Without a screenshot, a report doesn't effectively show the impact of a finding. Hadn't I documented the vulnerability back in the day, while testing, I wouldn't be able to do it at a later time, when I needed that screenshot for the report.

Wrap-up

The sooner new pentesters can unlearn the CTF-like mindset developed by using HTB, THM, PG or other practice platforms, the sooner they can progress in their career.

So, the recipe is: less CTF, more ninja.

Crushing CTFs doesn't make you a hacker, and you shouldn't be assuming to be such, but it can be a first step in that direction.

Thanks for your attention.