Offensive Security · Service 01

Penetration Testing

Simulated attacks across web applications, cloud infrastructure, and internal networks. Delivered by Cyber Scheme Certified Testers. We find what attackers would find, before they do.

Request a scoping call What we test ↓

What this is

One question. Could a determined attacker do real harm?

A penetration test is a controlled, authorised simulation of a real attack against your systems. A skilled tester attempts to do what an attacker would do: find entry points, exploit weaknesses, escalate privileges, and reach what matters. Everything that flows from that, the report, the remediation guidance, the retest, is secondary to answering that single question honestly.

Our testing is delivered by Cyber Scheme Certified Testers. The Cyber Scheme is a UK government-recognised assurance standard for penetration testers, which means the people doing the work have been independently assessed as competent. Not every firm uses certified testers. We do, on every engagement.

We test manually. Automated scanners have a role in the process, but the findings that matter, the business logic flaws, the chained vulnerabilities, the misconfigurations a scanner won't recognise as significant, come from a person thinking like an attacker, not a tool running a checklist.

Scope

What we test.

Penetration testing is not one thing. The scope, methodology, and depth depend entirely on what you're protecting and what risk you're trying to understand.

01

Web application testing

OWASP Top 10 and beyond. Broken access control, injection vulnerabilities, business logic flaws, authentication bypasses, insecure direct object references, server-side issues. We test as an unauthenticated attacker, as a logged-in user, and across role boundaries. If there is a meaningful difference between what one user role can do and what another can, we find it.

Authenticated and unauthenticated Business logic testing Role boundary validation

02

Cloud infrastructure

Amazon Web Services, Microsoft Azure, and Google Cloud Platform environments. Identity and access management misconfigurations, exposed services, credentials in storage, lateral movement paths between accounts and workloads, privilege escalation opportunities, and the classic problem of internet-facing resources that should not be internet-facing.

Identity misconfigurations Lateral movement paths Exposed services and storage

03

Internal network

Active Directory and Entra ID hardening, lateral movement, credential abuse, privilege escalation from a standard user to domain administrator. This type of test models what an attacker can do after they're already inside, whether through a phished employee, a compromised supplier, or a device brought onto the network. The post-compromise path is often shorter than organisations expect.

Active Directory attack paths Credential abuse simulation Privilege escalation testing

04

External attack surface

The view from the internet. Every asset that resolves to an IP address in your name is fair game for an attacker before they've said a word to you. We map what's exposed, test what's reachable, and find the things that shouldn't be there: forgotten subdomains, staging environments, old admin panels, services running on non-standard ports.

Asset discovery and enumeration Forgotten subdomains and services External entry point testing

How it works

From scoping call to signed-off report.

i

Scoping call

We agree what's in, what's out, what success looks like. No obligation.

ii

Fixed-price proposal

Methodology, timeline, and deliverables. No hidden costs or scope creep.

iii

Active testing

Typically 5 to 15 working days. You're updated throughout.

iv

Report delivery

Within 5 working days of testing completing.

v

Walkthrough and retest

Live debrief. Free retest after remediation to verify fixes.

The deliverable

A report people can actually use.

The executive summary goes on the first page. The finding that could cause the most damage comes first in the technical section. Findings are ranked by real-world risk and exploitability, not by a generic severity score that doesn't account for your specific environment.

Each finding includes the evidence (what we found and how), the reproduction steps (so your developers can replicate it), and remediation guidance written for your stack, not copied from a generic template. If your application is built on a specific framework, the fix recommendation reflects that.

You get two audiences served by one document: the board sees the business risk clearly, the developers see what to fix and how. The debrief call walks both groups through it together.

Other services

Related capabilities

02 / Offensive Security