How does the process flow of a penetration test work?

A penetration test follows a detailed procedure starting with scope definition, threat modeling, vulnerability assessment, exploitation, and culminating in a detailed report.

The penetration testing process begins with the scoping phase where specific goals and boundaries are set, followed by threat modeling to identify potential vulnerabilities. Testers then proceed to assess these vulnerabilities, attempting to exploit them to understand the impact of potential security breaches. The final phase involves compiling the findings into a comprehensive report that provides an overview of the vulnerabilities discovered, their severity, and recommended mitigation strategies, thereby enabling organizations to enhance their security posture effectively.

Penetration testing

Process of a penetration test

Kickoff

In a kickoff meeting, important things are discussed with responsible people. It will be clarified what and how will be tested. All things that may have already been discussed before are confirmed and critically questioned (application functions, roles/rights, test environments, no-gos, technology, ...). Together with the customer, we lay a foundation that allows us to successfully carry out the penetration test. The customer's individual wishes are also taken into account (communication during the test, test times, VPN, ...).

Execution

We get to work. As a team, we look for security gaps and problems within the defined scope. If it's a classic black box pen test against a web application, for example, we use tools such as Nmap or Burp Suite. In the first phase we try to understand the target and its regular function. We then go through each function in a structured manner and look for security gaps, incorrect configurations and general technical problems. The exact procedure, the level of automation and the selection of tools depend in detail on the specific order. Customers often require not only a very focused technical penetration test, but also a certain red teaming component. In such a case, we use OSINT, threat intelligence and others to compromise the target application in other ways if necessary (e.g. access to source code or access data through leaks on the Internet).

Reporting

We usually create a detailed report as a PDF. The report includes a summary for the management as well as the technical part. The latter describes the scope, methodology and all findings. We ensure that the customer's technical staff can reproduce our findings. It has proven useful for us to point out current problems of a general nature within the report - this way we can quickly see whether a function could become a problem in the future and what the developers would have to do to prevent this. We want to help the customer proactively. The technically responsible person receives the report at an agreed date - usually via a secure channel.

Final meeting

In a final discussion, we clarify the customer's questions, explain our findings and ensure that the customer has really understood the impact. Each final interview is very individual and is planned accordingly.

Retesting

Optionally, we offer to check the developers’ fixes. Here we not only re-execute our initially provided payloads, but also consider potential bypasses that the developers may not have had on their radar. In this way, the applications can be strengthened again.

Contact DSecured

Get a pentest offer