Breaking in Before Others Do
In an individual penetration test I will apply offensive hacking techniques in manual and semi-automated attacks against a web application, backend API, or mobile app. In order to discover blind and super-blind vulnerabilities, I enhance the tests with timing and DNS-based side-channels to gather more finding, possibly deeper within backend systems.
Prior to the penetration test a scoping call will be organized, where we can discuss questions regarding the pentest scope, backend systems, exclusions, reporting, and timeframe.
During the main part of the penetration test, I will execute manual and semi-automated attacks against the target system. This approach checks for many aspects including:
- Vulnerabilities in client and server parts of the application
- Vulnerabilities in critical business functions, like payment etc.
- Vulnerabilities in authentication and authorization
- Vulnerabilities in exposed and consumed communication interfaces
- Vulnerabilities in session or token management
- Vulnerabilities in exposed components and dependencies
- Vulnerabilities in error handling
Detailed Reporting
The resulting report of the found security issues includes detailed descriptions of the findings (along with all evidence collected) and mitigation advice to remediate each issue and tips to further harden your application. To better distribute the individual findings towards the relevant parties, I categorize all findings by function (business, architecture, development, operations) to which the finding applies.
After sending the report an on-site or remote debriefing meeting will be arranged to further discuss the report and any potential questions along with the team members assigned to remediate the findings.
This process can optionally be followed by a second check of remediated findings, which leads to an updated report.
Example Pentest Report
In order to get some idea of how such a report looks like, here are some results of a fictitious example application (click to enlarge the images):
Of course all pentest reports include detailed evidence for each finding, like screenshots, steps to reproduce, etc. to ease the re-testing after remediation.
Prerequisites
This kind of security check can be executed with no or minimal prior knowledge of the underlying software system (blackbox) remote or on-site. Optionally in a graybox variant some information about the architecture is given upfront.
While also possible to check live production systems, most pentests are executed against test environments, as then more offensive and riskier attacks can be attempted without disturbing the production system.
All checks and tests can be executed remotely as well as on-site at your office location. As prerequisites the following input is required to start the penetration test:
- Access to the application (URLs, client access, etc. depending on the type of application)
- Minimum of two different application users (with different data, i.e. different customers/tenants)
- If the application has file uploads requiring special formats: Valid sample files
- If the application is a service without a user interface (i.e. REST microservice): Documentation or sample requests
In order to get the best possible results, optional (read-only) access to backoffice systems processing data from the frontend system under test can be arranged. That way I can also check if some attack payloads trigger in backoffice systems as 2nd-order attacks.