Web · API · Network

Penetration Testing

Offensive mindset. Defensive results.

Simulated real-world attacks against your applications, APIs and infrastructure, reported as findings you can act on — not a pile of scanner output.

Attack surfaces

What we test

Web Applications

Authentication flows, session management, business logic, input validation, file uploads, and every OWASP Top 10 category.

APIs & Microservices

REST, GraphQL, gRPC endpoints tested for broken access control, injection, mass assignment, and rate-limiting gaps.

Cloud & Infrastructure

AWS, Azure, GCP misconfigurations, exposed storage, overly permissive IAM, and network segmentation testing.

Internal Networks

Lateral movement simulation, Active Directory attacks, privilege escalation, and internal service enumeration.

Authentication & SSO

OAuth flows, SAML integrations, MFA bypass attempts, password policies, and credential storage review.

Mobile Applications

Android and iOS app security: local storage, certificate pinning, API communication, and reverse engineering resistance.

Methodology

Our testing process

Every engagement runs the same five phases, aligned with the PTES and OWASP testing guides. You always know which phase we are in, what we need from you, and what lands at the end of it.

  1. 01

    Scope & Authorise

    Before a single packet is sent we agree exactly what is in scope and what is not. That means naming the hosts, domains, API endpoints and accounts we may touch, the testing window, and the things we will deliberately leave alone — payment flows in production, for instance, or a legacy box nobody can afford to reboot.

    We also fix the rules of engagement: who to call if something breaks, whether social engineering and denial-of-service are permitted (they are excluded by default), and how findings are handled if we stumble on real customer data. Written authorisation from whoever owns the systems is signed here. Without that signature the work does not start — unauthorised testing is a crime, not a technicality.

    You provide
    Asset list or domains, environment details, test accounts for each role, an emergency contact.
    We do
    Draft the rules of engagement, confirm your provider's testing policy, produce the authorisation letter.
    You get
    A signed scope document you can hand to auditors, and a fixed test window.
    Typical time
    2–3 days
  2. 02

    Reconnaissance & Mapping

    We build a picture of the attack surface as an outsider would, then go deeper than an outsider could. Passive work comes first — certificate transparency logs, DNS records, public code repositories, leaked credentials in breach dumps, job adverts that name your internal stack. None of it touches your systems.

    Then we map the application itself: every route, parameter, upload, redirect and authentication path, plus the technologies and versions behind them. This phase is what separates a real test from a scanner run — a scanner tests what it can find, and most of what matters is reachable only after you understand how the application is meant to work.

    You provide
    Nothing beyond phase one; documentation and API specs speed this up if you have them.
    We do
    Subdomain and service enumeration, technology fingerprinting, OSINT, full route and parameter mapping.
    You get
    An attack-surface map, including exposed assets you may not have known were public.
    Typical time
    1–3 days
  3. 03

    Exploitation & Chaining

    This is the hands-on phase. We attempt real exploitation of what we found: injection flaws, broken access control, authentication and session weaknesses, server-side request forgery, insecure deserialisation, file-upload paths, and the business-logic flaws that no tool detects — ordering a negative quantity, replaying a signed request, escalating from one tenant's data to another's.

    Individually low findings get chained, because that is how real intrusions work. A verbose error message plus a predictable identifier plus a missing authorisation check is three medium findings on a scanner report and a full account takeover in practice. We prove impact rather than asserting it, and we stop short of anything destructive unless you have explicitly asked for it in writing.

    You provide
    A responsive contact during the test window in case we need an account unlocked or a WAF rule relaxed.
    We do
    Manual exploitation, privilege escalation, vulnerability chaining, impact validation with evidence capture.
    You get
    Immediate notification for anything critical — you hear about it the day we find it, not in the report.
    Typical time
    5–10 days
  4. 04

    Report & Evidence

    Each finding is written up with the severity (CVSS v3.1 plus our own view of business impact, which is often the more useful number), the exact steps to reproduce it, the raw HTTP requests and responses or screenshots that prove it, and remediation guidance written for your stack rather than copied from a generic checklist.

    The report opens with an executive summary a non-technical reader can act on and closes with the technical detail a developer needs to fix the issue in an afternoon. If a finding is theoretically interesting but practically unexploitable in your environment, we say so — inflating severity to pad a report wastes your engineering time.

    You provide
    A review call slot; optionally a preferred report template or ticket format.
    We do
    Write, peer-review and rate every finding; map findings to OWASP categories and your risk register.
    You get
    The full report, an executive summary, a risk matrix, and a debrief walkthrough with your team.
    Typical time
    3–5 days
  5. 05

    Fix & Verify

    A report that nobody acts on has changed nothing. We walk your developers through each finding, answer the “but why is that exploitable here” questions properly, and help sequence the fixes so the ones that actually reduce risk go first.

    Once your team has deployed the fixes we re-test every finding and confirm each is closed — including checking that the fix did not simply move the flaw somewhere else, which is common with input validation. You receive a re-test report showing the current state, which is usually the document your customers and auditors want to see.

    You provide
    Notification when fixes are deployed, and access to the patched environment.
    We do
    Re-test every finding, verify the fix holds under variation, check for regressions introduced by the fix.
    You get
    A re-test report confirming closure — suitable for sharing with customers and auditors.
    Typical time
    2–3 days, after your fixes
Deliverables

What you receive

Executive Summary

A non-technical overview for leadership — risk posture, critical findings, and strategic recommendations in plain language.

Technical Findings

Every vulnerability rated by CVSS severity with evidence, reproduction steps, and code-level remediation for your developers.

Risk Matrix

Visual risk breakdown by severity and business impact, showing your team what to fix first.

Re-test Report

After your team applies fixes, we verify each one and provide a clean re-test report confirming closure.

FAQ

Common questions

What is penetration testing?

Penetration testing is a controlled, authorised simulation of real-world cyber attacks against your systems. A qualified tester tries to exploit vulnerabilities in your web applications, APIs, cloud infrastructure, or networks — then documents every finding with evidence and a clear fix.

How long does a penetration test take?

A typical engagement runs 1–3 weeks depending on the scope. A single web application usually takes 5–10 business days. Larger environments with multiple applications, APIs, and network segments may take longer.

Will penetration testing break my production systems?

No. Testing is performed carefully to avoid disruption. Destructive tests like denial-of-service are only run with explicit written consent and typically in staging environments. Every test window is agreed upon in advance.

What do I get at the end of a penetration test?

You receive a detailed report containing an executive summary, every finding rated by severity and business impact, evidence (screenshots, HTTP requests/responses), reproduction steps, and specific remediation guidance for your technology stack.

How is this different from a vulnerability scan?

Vulnerability scanners run automated checks and produce generic output. Penetration testing is manual, context-aware testing by a skilled practitioner who chains vulnerabilities, tests business logic, and proves real-world impact.

Ready to test your defences?

Tell us what you'd like tested. We'll scope the engagement and get back to you within 24 hours.