Hacking the Success Code: 6 Habits Every Penetration Tester Must Have

Hacking the Success Code: 6 Habits Every Penetration Tester Must Have
Photo by Ruthson Zimmerman / Unsplash

After have working professionally in cyber security as a penetration tester for half a decade (hacking scene for 10+), I feel I have learned a few things on how to improve your skill set, way of working and communicating with customers. I have also had the opportunity to work with some great people in cyber security from which I have learned considerably from.

In this article, I will present six habits which I believe represent a strong penetration tester. Let's dive in!

1. Continuous Learning

Cybersecurity is constantly evolving to adapt to new threats and vulnerabilities, requiring ongoing updates in technology, practices, and skills. Techniques for identifying vulnerabilities in everything from web to mobile are improving and shared with the world. As a result, new vulnerabilities are found, and some are rediscovered.

To thrive as a penetration tester, keeping up to date with the latest vulnerabilities and techniques is crucial. Reading a book from 2014 about browser security and vulnerabilities is great as a foundation to stand on, but as new security controls are introduced, new attack methodologies are needed.

In the Web world, James Kettle has produced great research over the years. Every web penetration tester should follow his research and learn how to apply the techniques from his work.

But how should you learn? Where should you learn? I recommend the Burp Academy for juniors as well as for seniors. Another great source is X. I recommend creating a list of people to follow, who write about the topic you are interested in. This is a great way to consume information directly from people. Finally, subscribe to newsletters about cyber security. There are some fantastic newsletters out there that consolidate the latest information in a nice email for you to study. Some newsletters that I follow:

However, reading isn't everything, you also need to practice what you learn, which is easier said than done. If you are working e.g. as a consultant and you get an assignment to test a web app, make sure you try out new techniques you have learned. Otherwise, bug bounty targets could be another method of practicing what you learn.

Learning and practicing is not enough though, you need to document what you learn. Maintaining a personal knowledge database is crucial for evolving your skill and expertise. The things you should be documenting are payloads you have had success with, bypasses, commands, testing methodologies, gotchas for specific software and so on. Try to keep your notes short, concise and to the point. Make use of tags if your editor supports it, I recommend Obsidian which has support for tags and much more. Below you'll find a screenshot of my notes regarding cyber security. The list is quite long, but the screenshot would have taken up too much space if I included everything.

Outline of my personal knowledge database

2. Methodical Approach

When performing a security test, be it for a web app or internal network, having a plan is going to improve the test significantly. By not having a plan, the test becomes very sporadic, vague and simply unstructured. As a result, vulnerabilities might go under the radar and the customer will get a false sense of security. Even worse, if the customer gets hacked because of a vulnerability you missed, how will that impact your relationship with the customer?

Having a plan requires the penetration tester to understand the environment being tested (assuming a white box approach). To understand the environment, the tester will need to ask the customer questions, map functionality found in the application or perhaps read some code. From this process, a testing guide should emerge. Based on the functionality or services found in the environment, specific test cases can be performed. For example, if a site contains a file upload, the tester should know to look for ways to upload e.g. a web shell (a backdoor). By mapping the environment before performing any attacks, it becomes easier to identify possible attack paths and decide where to spend time on. Once the test is nearing its end, you'll have a nice list of all your test cases based on the identified functionality. This improves your chances considerably to figure out if you have missed anything.

By not documenting a plan of execution, the test turns into an opportunistic testing methodology where the penetration tester jumps around too much and misses the bigger picture. I recommend writing down either physically or digitally, all the test cases you would like to perform, and if they worked or not.

There exists superb resources that can help structuring your methodology. One great resource is OWASP ASVS. I use this myself to double check that I have not missed anything. The way I use it is to simply go over the table of contents and make sure I have covered relevant areas. Sometimes I go into the details for each section to make sure I have tested a function properly. I believe this is a superior way of working compared to a sporadic and opportunistic process. But keep in mind, the ASVS is not a complete checklist, there exists vulnerabilities and techniques not documented in the ASVS. That is why it is important to write your own notes which you can reference when needed.

3. Tool Mastery

To work efficiently, you need to master your tools and your process for searching and identifying vulnerabilities. Simply running Burp active scan with default settings might find some issues, but the scanner is going to use checks that do not apply to your environment, thereby using unnecessary CPU and bandwidth. Same applies to running off-the shelf "hacking" tools from Github. If you have a vague idea of what a tool is doing, you are most likely wasting your time and your customer's time.

To be a proficient hacker, you need to understand the problem you are facing, and how your tool will (or might) solve it. For example, if you are testing a web application and you know it's running Go in the backend and Svelte in the frontend, there's no point in running Burp active scan with Java deserialization payloads. You would need to configure a custom scan where you only select relevant checks. Same applies if you are running a red team or similar, and you need to perform a network scan. Perhaps running default nmap settings is not the best idea. Again, you would configure nmap to suit the environment you are working in.

Mastering tools and techniques takes time and patience. I recommend fiddling around in the settings and with the various command line options. Try everything. There's also books on e.g. nmap and I have also seen courses on Burp Suite Pro made by expert Bug Bounty hunters. Try to identify your knowledge gaps in a tool, then try to fill it.

4. Soft Skills

Technical skill is not everything for becoming a successful penetration tester. Finding vulnerabilities and exploiting them is one component, another one is the ability to communicate the impact, risk and result to a customer. Ineffective communication can lead to incorrect assessments of vulnerability impact and misinterpretation of results. It's imperative to be able to convey why a vulnerability is a vulnerability. The customer most likely has no understanding of the subject, that's why they hired you.

Not only does a penetration tester need to describe security findings accurately and comprehensively, before the test even begins the customer needs to be briefed on what to expect and what type of test cases will be performed. This helps the customer understand what's going to happen during the test.

After a test has been performed, there's often a follow up meeting where the testers will describe their findings and corresponding impact. Being able to convey security vulnerabilities in terms that the customer can understand is imperative. For example, consider the following description of a CSRF vulnerability:

CSRF is a situation where a user's session is exploited by a third-party website to perform unauthorized actions. It happens because the web application does not properly validate the origin of the incoming requests.

While technically true, the description assumes the listener has some understanding about the subject. Let's look at an improved version:

Cross-Site Request Forgery (CSRF) is a security vulnerability where an attacker manipulates a user into performing actions they didn't intend to on a web application where they're authenticated. This occurs without the user's knowledge, exploiting the trust that the application has in the user's browser.

In my view, this is a much better explanation of the issue compared to the previous one. This example clearly states "[...] attacker manipulates a user [...] they didn't intend to [...]" and "This occurs without the user's knowledge [...]". I believe this description provides better insight and is easier to understand.

5. Risk Assessment

Being able to assess risk and impact for a given vulnerability is vital for the customer to create a strategy for mitigating reported vulnerabilities. Without assessing risk and impact, the mitigation strategy may be ineffective, leading the customer to waste time on less critical vulnerabilities.

For example, imagine two vulnerabilities have been discovered in a web application used for financial transactions:

  1. Remote Code Execution (RCE): This vulnerability is found in an admin panel that is secured behind multiple layers of authentication, authorization, and application-level permissions.
  2. Cross-Site Scripting (XSS): This vulnerability exists on the login page and can be exploited without any authentication. Furthermore, the session cookie doesn't have HttpOnly set.

On the surface, an RCE might sound more alarming than an XSS because it allows an attacker to execute arbitrary code on the server. However, let's assess the risk and impact:

RCE

  • Risk: High, in isolation, protected by layers of security
  • Impact: Server compromise
  • Access Constraints: Needs admin-level authentication, subject to authorization checks, and hidden behind application permissions.
  • Priority: Important but less urgent due to limited exposure.

XSS

  • Risk: Critical, publicly accessible
  • Impact: Data theft, session hijacking
  • Access Constraints: None; exploitable without authentication.
  • Priority: Urgent due to high likelihood of exploitation.

By assessing the risk and impact of each vulnerability, you guide your customer in allocating resources effectively. High-risk vulnerabilities with severe impacts should be prioritized, while lower-risk issues can be addressed later. This ensures that the most critical vulnerabilities are mitigated first, providing the most value for the time and effort invested.

The previous example included technical factors to determine risk and impact, but there can be other factors as well, such as cost. Additional factors can be factored in together with the customer.

6. Ethics

Before starting a test, both the customer and the penetration testers must agree on the scope of the test. Deviating from the defined scope can have severe consequences, imagine if the testers start attacking a vendor used by the customer? How will the vendor react? What happens if the testers bring down online services managed by the vendor? These details need to be established and understood by both parties.

Ideally, the customer will provide domain names and IP addresses. The testers can then perform recon and filter out any third-party services, before starting any attacks.

Another important part is confidentiality. Don't inform anyone about the results of the test, except for the customer. As a matter of fact, don't tell anyone you are working with a specific customer, unless the customer has agreed to disclose. This is probably obvious, and most likely covered by the contract, but confidentiality is key in cyber security.

Conclusion

To conclude, by mastering the following areas:

  • Continuous Learning
  • Methodical Approach
  • Tool Mastery
  • Soft Skills
  • Risk Assessment
  • Ethics

You will become a successful penetration tester. Each area overlaps or naturally leads into another area. For example, by continuously learning you will eventually start mastering your tool set. By mastering your tool set, you will start developing a methodical approach, which leads to assessing risk and impact. Soft skills and ethics are meta skills that you just need to practice.

It's important to not to rush anything and remember it's a journey, not a sprint.

Additional Resources

Here are some great resources to help you on the way to becoming a successful penetration tester: