Penetration
Testing
Web, API, cloud and internal networks, worked in parallel by agent swarms. Every finding arrives as an exploit that already ran.
A scanner returns a list of possibilities. This returns attack paths, each with the request that triggers it and the change that closes it. A human sets the objectives, decides what each result means for your business, and signs the report.
What you are buying
An authorized attempt to compromise a defined set of systems. The question is not whether a vulnerability class is present. It is whether a path exists from where an attacker starts to something you care about.
Nothing is reported that was not exploited. If the swarm cannot demonstrate it, it does not appear. That is why the report is short next to a scanner export, and why every line in it is a change someone can make.
It is a point-in-time result, accurate to the code deployed during the window. If you ship weekly, one annual engagement is stale within a month. For testing bound to a release cadence, see Application Security Assurance.
This engagement answers
- → What is exploitable right now, and by whom
- → What an attacker reaches after the first foothold
- → Whether one tenant or role can reach another
- → Which findings to fix first, and why
It does not answer
- → Whether your SOC would notice. See Red Team Engagements
- → Whether your incident response works under pressure
- → Whether your program is heading in the right direction
- → What ships next month
What gets attacked
Most engagements combine two or more. Scope follows what an attacker would chain, not what a product category calls it.
Web applications
Authentication and session handling, access control across roles and tenants, injection into every reachable sink, and the logic underneath: pricing, entitlements, workflow state.
APIs
REST, GraphQL and WebSocket. Object and function level authorization, mass assignment, token issuance, tenant isolation, and the endpoints missing from your OpenAPI spec.
Cloud environments
AWS and Azure. IAM escalation paths, storage and snapshot exposure, secrets reachable from compute, metadata access, and whether one account reaches another. GCP case by case.
Internal networks
Assumed breach. Lateral movement, credential reuse, and whether segmentation holds once a single host is attacker-controlled.
Out of scope, stated plainly
iOS and Android clients, denial of service, and physical intrusion are all outside the practice. If that is what you need we say so on the first call instead of taking the work.
How it runs
Six steps. Steps 02 through 05 are where the window goes, and the split between them shifts with what the target turns out to be.
01
Scope and authorize
Targets, exclusions, windows, escalation contacts and stop conditions, agreed in writing. You issue a letter of authorization. We counter-sign rules of engagement. Nothing outside that document is touched.
Output: Signed rules of engagement and letter of authorization.
02
Map the surface
Subdomains, certificate transparency, exposed services, JavaScript bundles read for endpoints and keys, routes recovered from archives. Roles, tenants and trust boundaries are mapped before anything is attacked.
Output: Attack surface inventory and the role and tenant matrix.
03
Run the swarm
Agents work the mapped surface in parallel: known vulnerability classes, dependency exposure, authentication and session handling, access control across every role and tenant pair, and injection into every sink they can reach. This is the permutation work no human window has room for.
Output: Confirmed findings with the request that crosses the boundary. Candidates that could not be exploited are dropped, not appended.
04
Chain the logic
The class of flaw a scanner cannot reason about. Skipped state transitions, replayed or reordered requests, races on balance and quota, entitlement bypass, anything priced or metered. Whether a reachable state is a defect or an intended behaviour is a judgement about your business, and that call is human.
Output: Logic findings with the request sequence that produces the abuse.
05
Prove the impact
Each finding is taken to the point where impact is unambiguous: whose data was reachable, what privilege was gained, which control was bypassed. Then it stops. No production data leaves, nothing destructive runs.
Output: Proof of concept per finding: requests, responses, reproduction steps, and an exploit script where one clarifies the issue.
06
Report, debrief, retest
Criticals leave the window the day they are confirmed. The report follows within days, then a live walkthrough with the engineers who own the fix. Once fixes ship, every Critical and High is attacked again, including the obvious ways around the patch.
Output: Engagement report, debrief session, and a dated retest document with per-finding status.
What lands on your desk
One report for decision-makers, engineers, and the people responsible for assurance.
View the sample reportExecutive summary
- What was in scope and what was excluded
- Confirmed findings by severity
- What an attacker could reach, in business terms
- Remediation ordering with rationale
Technical findings
- Affected systems and business impact per finding
- CVSS v3.1 base score with the vector shown
- Numbered reproduction steps and prerequisites
- CWE and MITRE ATT&CK mapping
Remediation guidance
- Specific recommendations for each finding
- Relevant standards and research references
- Effort estimate alongside severity
- A prioritised remediation roadmap
Appendices
- Scope and rules of engagement
- Methodology, timeline and attack narrative
- Limitations, glossary and supporting appendices
- Distribution record and cryptographic attestation
Report ownership
The report is yours. It is formatted so it can go to an auditor or a redacted copy to an enterprise prospect without a second document being produced.
What we need to quote
Bring what you have. Missing items are worked out on the scoping call; nothing here is a prerequisite to talking.
- →Target list: domains, API base URLs, cloud accounts or subscriptions, network ranges.
- →Role and tenant model: how many distinct privilege levels exist, and whether tenants share infrastructure.
- →Rough size: endpoint or route count, or a link to the OpenAPI spec.
- →Environment: production, staging, or a dedicated test instance, and whether data in it is real.
- →Credentials you can issue: one account per role, ideally two per role to test horizontal access.
- →Constraints: change freezes, traffic-sensitive windows, systems that must not be touched.
- →Driver and deadline: customer security review, audit, funding diligence, or a release date.
When to buy something else
Penetration testing fits
- → No one has ever actually tried to break it
- → An enterprise buyer or auditor is asking for a report
- → You shipped something significant and want it checked
- → You want to know what is exploitable, not what is present
- → You are preparing for diligence and want to fix quietly first
Start elsewhere if
- → You want to test detection, not find bugs: Red Team Engagements
- → Your concern is someone already inside: Insider Threat Simulation
- → You need a direction rather than findings: Security Consulting
- → Your release cadence makes a point-in-time result stale
Before procurement
Model the budget yourself first
The cost calculator turns a scope description into a range you can take to finance before you talk to anyone. Bring its output to the scoping call.
Common questions about penetration testing
Still have questions about penetration testing? Book a discovery call
How to start
Send the target list, the driver, and the deadline. You get a reply with either a scoping call slot or a reason this is not the engagement you need.
Direct: hello@principlebreach.com
Sequence
- Discovery call: is this the right engagement
- Scoping call: targets, constraints, deadline
- Fixed-scope proposal and statement of work
- Mutual NDA and letter of authorization
- Testing window
- Report, debrief, remediation retest