Technology & SaaS

Your exposure ships to every customer you serve

From one exposed credential to a customer's data, across app and cloud.

Web App Pentest and Cloud Pentest both ship today, so a run works the surface this week's deploy created rather than the one documented last quarter.

Book a demo
See the platform
Definition

What is multi-tenant isolation testing?

Multi-tenant isolation testing is an authorised attack on the boundary between one customer's data and another's inside shared SaaS infrastructure. An operator authenticates as one tenant and works the object identifiers, token claims, tenant headers, shared storage, and control-plane roles that separate it from the next, then proves whether that separation holds.

The run follows the release

Start an operation from the REST API, remote MCP, or a GitLab mention, so a route that shipped on Tuesday gets worked on Tuesday instead of at the next audit.

One tenant, aimed at the next

Authenticated as a test tenant you authorise, the run works object identifiers, token claims, tenant headers and shared storage against another — the boundary your customers assume holds.

A key in your app is a role in your cloud

Takes a credential the app run recovered, maps what it can assume, and crosses accounts until it reaches a data store or runs out of permission.

Evidence a customer security review can read

Every action carries the command that ran, the result it returned and the time it ran, with findings that fired twice kept apart from the ones named as not proven.

Lapsus$ / Scattered Spider — one help-desk reset or one SSO tenant becomes access to every downstream customer.

One help-desk reset, then your SSO carries it downstream

Cracken runs the help-desk call, then shows how far the account it produces travels.

  1. 1Recon
    Attacker

    Maps your org, finds the vendor and the admin with privileged access.

    With Cracken

    Domain Recon builds the same map from outside: names, hosts, ports, exposed services, written to the Cybergraph.

  2. 2Initial access
    Attacker

    A help-desk call resets an MFA token.

    With Cracken

    Social Engineering runs the help-desk pretext, and the run carries the account it produces forward.

  3. 3Escalation
    Attacker

    A dumped credential becomes domain admin.

    With Cracken

    AD Pentest works the credential paths and proves which ones still reach domain admin.

  4. 4Identity takeover
    Attacker

    Registers a rogue identity provider and impersonates anyone.

    With Cracken

    Establishes which directory roles could add a federated domain, and stops at proving the permission exists.

  5. 5Supply-chain reach
    Attacker

    One tenant, every downstream customer.

    With Cracken

    Stops at your boundary — names which of your systems the path reaches, never a customer's tenant.

One run

From a route this deploy added to a role that reads customer data

One release of a multi-tenant application, two tenant identities inside it, and the cloud accounts behind it.

Written from the execution plan of the playbooks that run today — Domain Recon, Web App Pentest, Network Pentest, Cloud Pentest, AD Pentest. A run covers the target you authorise, under the policy you set.

  1. 01
    What ran

    Map the surface this deploy changed — hosts, routes, parameters, forms, API endpoints, auth boundaries — with nmap, whatweb, gobuster and nuclei, writing each one to the Cybergraph.

    Reconnaissance
    What it established

    The routes and parameters in scope, including the ones no documentation lists.

  2. 02
    What ran

    Authenticate as one tenant and aim at another: object identifiers, token claims, tenant headers. One sub-operation per surface per attack class, running in parallel.

    Broken object-level authorisation
    What it established

    Whether one customer's session reaches another customer's records.

  3. 03
    What ran

    Hunt exposed keys and metadata endpoints on the same surface, then map IAM permissions, roles and trust relationships from whatever the run obtains.

    Credential and metadata exposure
    What it established

    What a credential recovered from your own app can do inside your cloud account.

  4. 04
    What ran

    Assume the roles the policies permit, cross between accounts, subscriptions and projects, and reach the data stores behind them.

    Role assumption and cross-account movement
    What it established

    Whether the dev account reaches production — run against the live account, not scored against a benchmark.

  5. 05
    What ran

    A separate operation re-fires every candidate in fresh context and captures the signal, or kills the candidate and records why. Each action carries the command that ran and the time it ran.

    Reproduction
    What it established

    Findings that fired twice, a named list of what could not be proven, and a timeline to line up against CloudTrail.

What this did not prove: The help-desk pretext in the chain above belongs to the Social Engineering playbook, a separate run. This run starts from the surface and the credentials you scope, not from a person — so it proves what that credential reaches once it exists, not that anyone would hand it over.

Ask for the exploit. Get the exploit.

Mainstream models decline offensive-security work as a class. Cracken's model has refusal removed for the cybersecurity domain only: 100% to 7%, with explicit-content refusal held at 100%.

?

Weaponise the CVE in your staging build

Ask for the working exploit and get the working exploit, then a second operation re-fires it in fresh context to prove it was not a fluke.

Ride the key you leaked to yourself

A credential recovered from your own app becomes role assumption, cross-account movement and a named data store — requested in plain language, not coaxed.

Work the directory

Kerberoasting, delegation abuse and the path to DCSync against the test domain you authorise: commands and output, not a summary of the risk.

Your deploys outpace your red team. Give them a run that repeats every time the build changes.
Questions

What the run covers, and where it deliberately stops

Our surface changes with every deploy. What does a run actually cover?

A Cracken run covers the scope you fix before it starts: the hosts, routes, accounts and projects you name, minus the exclusions you name, up to an intrusiveness ceiling you set. Reconnaissance rediscovers the surface on every run, so a route yesterday's deploy added gets worked today, and an undocumented API found mid-run reopens reconnaissance on itself.

Will it test the boundary between our customers?

Yes. The Web App Pentest playbook dispatches one sub-operation per surface per attack class, and the tenant boundary is worked as broken object-level authorisation, auth bypass and API logic — authenticated as one tenant, aimed at another tenant's identifiers. You supply the authorised test tenants; tenants you exclude are never in play.

We are the vendor. Why does our own exposure become our customers' problem?

Because a compromise of a software vendor is now handled as a compromise of everyone downstream. On 15 October 2025 CISA issued Emergency Directive ED 26-01 after "A nation-state affiliated cyber threat actor has compromised F5's systems and exfiltrated files, which included a portion of its BIG-IP source code and vulnerability information", calling the actor an imminent threat to federal networks using F5 devices and software, and ordering every federal civilian agency to inventory, harden and patch. Your product sits in someone's environment the same way. — Emergency Directive ED 26-01: Mitigate Vulnerabilities in F5 Devices (Cybersecurity and Infrastructure Security Agency (CISA), 2025-10-15)

Does it run against production, or only staging?

It runs where you authorise it to run. The accounts, subscriptions and projects in scope, the exclusions and the intrusiveness ceiling are fixed before the first API call, and any action above the ceiling waits for a human. You can approve every action or let the operation run start to finish.

Which parts of an attack does Cracken not run?

Domain Recon, Web App Pentest, Network Pentest, Cloud Pentest, AD Pentest and Social Engineering all run against the scope you authorise. What a run does not do is set by that scope, not by the tool: it stops at your boundary, names which of your systems a path reaches rather than a customer's tenant, and holds any action above the intrusiveness ceiling for a human.

Does Cracken fix what it finds?

No. Cracken validates exposure and stops there. Every finding arrives with the command that ran, the result it returned and the artifact it produced, and anything it could not reproduce is reported as not proven, by name. Remediation, incident response and control tuning stay with your engineers.

If you run the operation

See the engine underneath this.

Tentacles, the Cybergraph, the approval gate every action passes through, and the operation ledger that records what ran. Technology & SaaS is one playbook on top of that engine.

If you own the risk

Start from the exposure, not the technique.

One playbook answers one question. The case for validating exposure at all — why a scanner score is not a finding, and what changes when something proves the path instead of ranking it — is the argument this page assumes.

Use cases

Playbooks for Technology & SaaS

See all use cases

See the path from one credential to a customer's record.

Point Cracken at a staging environment and scope the run.

Book a demo