Step 1: Defining the scope

The scoping phase lays the groundwork for the entire penetration testing operation. Before we can start the process, we need to establish what exactly we’ll be testing, why, how, and for how long. This is where we have detailed discussions and planning sessions with our clients so we’re prepared and aligned with our expectations. 

Establishing the basic parameters

First of all, we actively engage with the client to understand the requirements, expectations, and constraints. This includes: 

Choosing the right approach

Approaches to penetration testing can be categorized into three main types: black box, white box, and gray box. Each provides testers with varying levels of information access.

The gray-box approach is often considered the sweet spot. With just the right amount of knowledge about the system, penetration testers can focus their efforts efficiently. They need less time to get the know the system initially but can still devise a realistic scenario for vulnerability assessment.

Setting the rules of engagement

Once we define the testing scope and identify the right approach, it’s important to put everything in writing. This ensures that the test is conducted responsibly and safely, without exceeding the boundaries we’ve agreed upon or disrupting the client’s operations, maintaining ethical and legal compliance throughout the process.

The document typically includes the following information:

If you want to go beyond a scoped vulnerability assessment and test how your organization would hold up against a full, campaign-style attack, including detection and response — that’s what a red team engagement is designed for. Pen testing and red teaming serve different purposes — understanding the distinction helps you choose the right engagement before you scope it.

Step 2: Getting into testing

When we’ve established the full testing scope, it’s time to get to it. A penetration test consists of three parts: information gathering, scanning for potential vulnerabilities, and exploiting those vulnerabilities.

Information gathering

We dive in to learn as much as we can about the subject of our test – your system, and we do so in two phases.

Passive phase

First, we focus on publicly available information. We investigate the product, your company, and the people involved. This enables us to get to know the penetration test target and potentially reveal important information, such as additional development environments, API documentation, sensitive information on GitHub, Pastebin, and other online services.

Active phase

In the next stage, we focus on understanding the application’s architecture, the technologies in use, and the systems and services surrounding it, such as a third-party email service or a web application firewall.

Most web applications integrate other services, and we need to ensure that we don’t step outside the boundaries defined in the scope. This will be especially important in the next phase of the penetration test, scanning for vulnerabilities.

However, before pen testers can jump into using crawlers and vulnerability scanners, we have to learn how the system is used. By navigating the system as a user, we gain a deeper understanding of its functionalities and identify potential security flaws so we can prioritize our testing efforts.

Real-life story: Information gathering can reveal important security issues

Exploring the system and the information available can sometimes reveal critical weaknesses. In one of our engagements, we were looking into every known subdomain related to the main domain, knowing that they can contain forgotten or misconfigured records that can be exploited in malicious activities.

This could easily lead to a subdomain takeover attack.

The malicious actor could then organize phishing attacks, distribute malware, cause reputational damage, or bypass the organization’s security measures.

In this particular instance, we identified a subdomain pointing to an Azure cloud resource that no longer existed. Without Azure’s domain verification feature, anyone could have created a new Azure resource and linked it to the client’s subdomain. This wasn’t very hard to spot and took almost no time and resources, but we might have missed it if we hadn’t done our research thoroughly.

Vulnerability scanning

Building upon the information gathered in the previous phase, pen testers actively scan the target system or network for vulnerabilities. This phase involves using various tools and techniques to identify potential weaknesses in the target organization’s security posture. 

We combine automated scanning, which uses tools to quickly and consistently identify known vulnerabilities, and manual scanning, which relies on the expertise of penetration testers to uncover more subtle or complex issues that automated tools may overlook.

Automated scanning

We employ tools for automated scanning to identify common vulnerabilities, misconfigurations, and outdated components. This makes the testing process more efficient because once configured for the system being tested, these tools can scan with little supervision, while pen testers can focus on the manual scanning phase.

However, it is important to set up the scanners properly because we don’t want to spend hours on tests specialized for a technology that isn’t used on the target system. Penetration testers also need to make sure we stay within the test’s scope. For example, sending a large number of email messages might conflict with the provider’s acceptable use policy.

Manual scanning

In the manual scanning phase, we engage with the product, examining the business logic and human-error-induced irregularities that automated scanners may overlook. We focus on:

This is especially relevant when the app was built with AI-assisted development, where the vulnerabilities are assumptions, not bugs.

For mobile applications in particular, manual testing includes attempting to bypass runtime protections such as root detection, hook detection, and anti-debug mechanisms — as demonstrated in our hands-on breakdown of Android protection bypass techniques.

Real-life story: Unusual error messages are always worth investigating

During one of our checks, instead of getting a “no access” alert, which you would expect if something is private, we got “service unavailable.” This unusual response indicated two things. First, the supposedly private endpoint was open to the public, and second, there was a glitch preventing the system from handling our request correctly. 

The investigation uncovered that upon processing our request, the system rightly determined our key as invalid but then mistakenly revoked access for all users on the platform.

Exploiting the vulnerabilities

The search identified a list of potential issues, and now we can jump into vulnerability assessment in the exploitation phase.

The primary objective of this phase is to understand the severity of the vulnerabilities we found and their potential practical impact.

The common tasks for this phase include:

Lateral movement means moving across different systems and networks to assess how far an attacker could penetrate the organization’s infrastructure. It’s about understanding the reach and potential impact an attacker could have once they’ve gained initial access.

For example, in the famous 2020 SolarWinds cyber attack, malicious actors exploited SolarWinds’ network monitoring software, which was used by many large organizations, including the U.S. federal government. Therefore, through horizontal movement, hackers were able to penetrate the government’s systems and many others. 

The other tactic for assessing an attack’s potential impact is chaining vulnerabilities.

When we identify multiple vulnerabilities, we can try to chain them together to escalate their level of access or to breach deeper into the system.

In this part of the process, a penetration tester’s creativity is a real asset because combining the vulnerabilities in different ways can reveal all sorts of potential security threats.

However, it’s also easy to go overboard, and this is why the predefined scope is our northern star – preventing us from straying into areas that could raise legal and ethical concerns (e.g., testing a user database that is out of scope might violate GDPR).

Step 3: Report & retest

Though it appears as the last chapter, we begin writing the penetration testing report immediately after the scoping phase. The report’s initial section should cover the test’s defined scope, the objectives we aim to achieve, and the details of the test environments.

For every security vulnerability identified and exploited, we record the specific steps taken, the tools used, and the thought process behind these actions. We’ll also include any interesting findings that emerge during the testing.

This method of progressive documentation makes it easier to compile a comprehensive report. It ensures that we don’t miss any critical details and that the report effectively communicates the entirety of the penetration testing engagement.

Last step: Be proactive with security

Our penetration testing process includes a comprehensive assessment of your entire system and lays out the steps for remediation in detail. However, it’s important to remember that conducting penetration tests is a reactive approach. It identifies vulnerabilities that were already present in the system.

To improve the organization’s security practices and identify issues at an earlier stage, it’s important to be proactive. We always recommend adopting regular testing practices so you can identify and resolve any vulnerabilities before the suspiciously-looking guy in the basement can exploit them. 

It’s also important to foster a DevSecOps culture. That way, you ensure that security is not an afterthought but a fundamental part of the development lifecycle. When development, operations, and security teams work together, security becomes a shared responsibility, and your overall posture benefits from it. 

To discover the full range of our cybersecurity services, check out the dedicated page.