Breaking in before others do
Automated scanners catch the low-hanging fruit. A manual penetration test goes after the things scanners miss — the business logic flaws, the chained vulnerabilities, the subtle authentication bypasses that only show up when a human is actually thinking about how to abuse the system.
I apply offensive hacking techniques in manual and semi-automated attacks against web applications, backend APIs, and mobile apps. To discover blind and super-blind vulnerabilities, I enhance the tests with timing and DNS-based (out-of-band) side-channels to gather findings that may surface deeper within backend systems.
Before the actual test, we’ll have a scoping call to align on the pentest scope, backend systems, exclusions, reporting format, and timeframe. This scoping ensures I spend my time on the parts that matter most to your business.
During the main part of the penetration test, I 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
Beyond checking individual categories, I also look at how these areas interact. A minor information disclosure combined with a weak session token can sometimes be chained into something far more serious than either issue alone. That kind of contextual thinking is where manual testing really earns its keep compared to automated scans.
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.
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. If you want to go a step further, I can also perform a whitebox analysis where I review the actual source code alongside the runtime testing. This is especially useful for security-critical components like authentication flows, cryptographic implementations, or access control logic, where certain vulnerability classes are much easier to spot (or to rule out) by reading the code directly. It’s not a full code audit in the traditional sense, but a targeted review of the areas where source-level visibility adds real value to the pentest findings.
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.
This service also supports technical security requirements commonly referenced in modern cybersecurity regulations.
Pentest + threat modeling bundle
Combine your penetration test with an Attack Tree Quickstart for a comprehensive view of your application’s security — from strategic attack paths to hands-on vulnerability validation. The attack tree maps the threat landscape and security controls at architecture level, while the pentest validates real-world exploitability at implementation level. Both perspectives together give you a complete picture.
Ask about special bundle pricing when booking both together.