PENETRATION TESTING SERVICES
We test every layer an attacker can reach.
Web, API, cloud, network, mobile and your people. Pick where an attacker would start. We test it by hand, end to end, then hand you a report you can act on.
Tested toOWASP · NIST SP 800-115 · MITRE ATT&CK · CIS · OWASP MASVS
WHAT WE TEST
Six types of penetration testing. One standard.
Every test is manual, run by a senior tester, and mapped to a recognised framework. On each card is a real flaw we typically find on that surface.
Web Application Pentest
Auth, access control and business logic, tested by hand the way attackers chain them.
Explore this service →IDOR → account takeover
Any authenticated user could read and modify other customers’ accounts.
Network Pentest
External to internal: exposed services, weak segmentation, and the path to domain admin.
Explore this service →Cloud Pentest
IAM escalation, exposed storage and leaked secrets across AWS, Azure and GCP.
Explore this service →API Pentest
BOLA, broken auth, mass assignment, and the business logic behind your endpoints.
Explore this service →Mobile App Pentest
iOS and Android, from on-device storage and pinning to the backend API.
Explore this service →Social Engineering
Phishing, pretext and BEC that measure your people, then feed straight into training.
Explore this service →Credential phishing above baseline
A targeted campaign captured credentials at a rate above the industry baseline.
EVERY ENGAGEMENT
Whatever the layer, the same standard.
The service changes with your stack. How we work never does.
Manual-first testing
Humans find the logic flaws and chained exploits scanners miss.
Only senior testers
Every engagement is run by certified offensive-security pros. No juniors.
Fix-focused reporting
Reproduction steps, CVSS and a concrete fix for every finding.
Free retest included
We re-test every fix at no extra cost, so closure is proven.
This is the floor, not the ceiling. See how we work →
PROOF OF WORK
Real findings, not scanner noise.
Five findings from real engagements, verified by hand and scored. Open any one for the full technical write-up, exactly as it reads in your penetration test report.
criticalIDOR → account takeoverWeb ApplicationCVSS 9.6
Account records were addressed by a sequential integer. Using a low-privilege test account we incremented the identifier and the API returned another customer's record, then accepted a write to it. Ownership was never checked server side.
GET /api/v2/accounts/1337 200 (our account)GET /api/v2/accounts/1338 200 (another tenant)PATCH /api/v2/accounts/1338 204 {"email":"attacker@…"}# no ownership check on the object identifierAny authenticated user could read and modify every other customer account, including changing the email on file and taking the account over outright.
Enforce object-level authorization on every request: confirm the authenticated subject owns the object before returning or mutating it. Use non-sequential identifiers as defence in depth, and add an authorization test per endpoint to CI.
criticalOver-privileged role → account compromiseCloudCVSS 9.0
A CI build role carried iam:PassRole alongside lambda:* on a wildcard resource. We passed a higher-privileged role into a function we created, invoked it, and inherited administrative permissions.
$ aws iam get-role-policy --role-name ci-build"Action": ["iam:PassRole","lambda:*"], "Resource": "*"$ aws sts get-caller-identity → assumed-role/admin# escalation chain confirmed, no alert raisedOne leaked CI credential was enough to reach administrative control of the entire account and every workload running in it.
Scope PassRole to explicit role ARNs, drop wildcard actions, and attach a permissions boundary so build identities can never grant themselves more than they already hold. Alert on sts:AssumeRole into privileged roles.
highBOLA → cross-tenant data accessAPICVSS 7.7
The tenant identifier was read from the request body instead of the verified session token. Swapping it returned records belonging to unrelated organisations.
POST /graphql { invoices(tenantId:"acme"){ total } }200 OK 412 invoices returnedtenantId -> "northwind" 200 OK 1,208 invoices# tenant scope trusted from client inputAny customer could enumerate other organisations' invoices and financial totals, a direct multi-tenant data breach.
Derive tenant scope from the verified session token only, never from client-supplied input. Add cross-tenant authorization tests to the CI suite so a regression fails the build.
highSMB relay → lateral movementNetworkCVSS 8.1
LLMNR and NBT-NS were enabled and SMB signing was not enforced. We poisoned name resolution, captured machine authentication, and relayed it to a host where the account held local administrator rights.
$ responder -I eth0 -wrf[SMB] NTLMv2 captured: SVC_BACKUP$ ntlmrelayx → SMB session on FS02 (admin)# no password was ever crackedA single unprivileged foothold on the user VLAN reached file-server administrator rights without cracking one password.
Disable LLMNR and NBT-NS, enforce SMB signing across the estate, and segment user VLANs from server networks. Where legacy hosts block signing, isolate them behind an explicit allow-list.
mediumSecrets in local storageMobile AppCVSS 5.5
On a rooted device we pulled the application sandbox. A third-party API key and a long-lived refresh token were sitting in cleartext preferences with no platform protection.
$ adb shell run-as com.example.app cat shared_prefs/auth.xml<string name="api_key">sk_live_…</string><string name="refresh_token">eyJhbGciOi…</string># no Keystore usage anywhere in the buildBrief physical access, or malware on a rooted device, was enough to lift a long-lived session token and a billable third-party key.
Store secrets in the iOS Keychain or Android Keystore, shorten refresh-token lifetime with rotation, and proxy third-party calls through your backend so the key never ships inside the client at all.
WHERE TO START
Find yourself in one of these.
Almost nobody arrives with a shopping list. They arrive with a trigger. If you are not sure which penetration test you need, find the line that sounds like your week.
A big customer just asked us for a penetration test report.
We would start withWeb Application →Security reviews target the product your customer will actually log into.
Often paired with APIWe moved everything to AWS and nobody has audited the permissions.
We would start withCloud →Most cloud incidents start with an over-privileged role, not a zero day.
Often paired with NetworkPartner systems and our mobile app all talk to the same API.
We would start withAPI →Broken object-level authorization is the top modern API risk, and scanners miss it.
Often paired with Web ApplicationWe just shipped on the App Store and Google Play.
We would start withMobile App →The build sits in every attacker's hands, and so does the backend behind it.
Often paired with APIOur SOC 2 audit is close and we have never tested the network.
We would start withNetwork →Auditors want independent technical evidence across every system in scope.
Often paired with CloudSomeone in finance nearly paid a fake invoice last month.
We would start withSocial Engineering →It measures how your team really responds, then feeds straight into training.
READY WHEN YOU ARE
Still not sure? That's what the call is for.
Tell us your stack. In 30 minutes a senior tester will tell you what to test first, and what you can safely leave for later.