Case study 03 · External · Cloud · Multi-tenant

    Anonymous self-registration mints a global-administrator token across a shared platform

    An IT services firm that runs its client operations as one tenant on a shared, multi-tenant cloud platform it does not own. The same platform is used by many other firms.

    Client profile

    An IT services firm that runs its client operations as one tenant on a shared, multi-tenant cloud platform it does not own. The same platform is used by many other firms.

    Challenge

    When the application that runs your operations is a shared platform, a flaw in how it decides who is an administrator is not just your problem. The assessment tested whether an outsider could escalate on that platform, and how far the reach extended.

    Scope

    • Both corporate apex domains, all discovered subdomains, and client-owned edge addresses
    • The shared platform's development portal, actively tested
    • Email authentication and DNS hygiene for both apexes
    • Vendor-hosted SaaS reviewed passively only; production platform tenant treated as presumptive risk, not re-fired

    Authorized external red team, PTES-aligned, with independent proof-of-concept validation.

    ApproachAI-accelerated, human-validated

    A black-box external engagement on TitanDef's pipeline, powered by frontier models and aligned to PTES. Cloud identity behaviour was tested with controlled self-registration against the development portal, business-logic and abuse cases were exercised directly, and a real-browser driver handled the platform's bot challenges. Every finding was validated with an independent proof-of-concept and human-reviewed; a mass-assignment hypothesis that needed an authorized test account was recorded as deferred rather than claimed.

    Key findingsby severity

    21 validated findings

    Critical 1High 4Medium 9Low 2Info 5

    Critical

    • The platform derived administrative privilege from values a user supplies at self-registration, values the server never checked against a real tenant or role. An anonymous sign-up, in under thirty minutes with only a disposable email, produced a cryptographically valid token asserting global-administrator scope and returned real business records for dozens of tenant organizations across the shared platform. Rated CVSS 9.8.

    High

    • Public source maps exposed full application source; the firm's own brand domain was fully forgeable in email (no SPF, DKIM or DMARC); open recursive DNS on client-owned edge addresses; and a legacy end-of-life host carried an internet-exposed database port.

    Five scored attack chains were produced, the top rated 91 of 100. The platform escalation is the priority because the flaw sits in shared infrastructure and its reach extends to the vendor's entire customer base.

    Outcomefixed / retested

    Each issue was given a narrow, owner-assigned fix. The platform flaw is the vendor's to correct (stop deriving authorization from client-writable attributes; resolve tenant and role server-side from the immutable identity), with the firm's action being to escalate it as a Critical platform vulnerability, obtain a remediation date, treat its hosted data as exposed in the interim, and re-test once the fix ships. The email fix is a five-minute DNS change the firm controls directly. A post-fix re-test was scheduled, not yet executed at report time.

    1. Immediate

      Escalate the platform flaw to the vendor; publish SPF, DKIM and DMARC on the brand domain.

    2. 30 days

      Restrict DNS recursion fleet-wide; retire or re-platform the legacy host.

    3. Post-fix

      Re-test the platform escalation once the vendor ships the fix.

    Engage

    Find out what an adversary already sees.

    Focused engagements of 5 to 7 business days, with first findings in 72 hours. Powered by frontier models; every finding validated by a senior human.

    Scope a pen test →