Anonymous self-registration mints a global-administrator token across a shared platform
Authorized external red team, PTES-aligned, with independent proof-of-concept validation. Anonymized.
Who we worked with.
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.
Anonymized. No client names, people, domains, addresses or locations are published.
The question we were asked.
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.
Assessment modules used.
Authorized external red team, PTES-aligned, with independent proof-of-concept validation.
External red team
Both corporate apex domains, all discovered subdomains, and client-owned edge addresses.
Cloud identity testing
Controlled self-registration against the shared platform's development portal, actively tested.
Business-logic & abuse cases
Exercised directly; a real-browser driver handled the platform's bot challenges.
Email & DNS hygiene
Email authentication and DNS hygiene for both apexes.
Passive vendor review
Vendor-hosted SaaS reviewed passively only; production tenant treated as presumptive risk, not re-fired.
Severity, validated.
- CriticalThe platform derived administrative privilege from values a user supplies at self-registration. An anonymous sign-up, in under thirty minutes with only a disposable email, produced a valid token asserting global-administrator scope and returned business records for dozens of tenant organizations. CVSS 9.8.
- HighPublic source maps exposed full application source; the brand domain was fully forgeable in email (no SPF, DKIM or DMARC); open recursive DNS on client-owned edge addresses; a legacy end-of-life host carried an internet-exposed database port.
What changed.
Each issue was given a narrow, owner-assigned fix. The platform flaw is the vendor's to correct; the firm's action was to escalate it as a Critical platform vulnerability, obtain a remediation date, and treat its hosted data as exposed in the interim. 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.
Escalate the platform flaw to the vendor; publish SPF, DKIM and DMARC on the brand domain.
Restrict DNS recursion fleet-wide; retire or re-platform the legacy host.
Re-test the platform escalation once the vendor ships the fix.
What the client received.
- Validated findings report, each with independent proof-of-concept
- Five scored attack chains
- Owner-assigned fix per issue (vendor vs. firm)
- Vendor escalation guidance for the platform Critical
- Post-fix re-test of the platform escalation (scheduled)
Prepared by TitanDef offensive security team
Find out what an adversary already sees.
Focused engagements run 5 to 7 business days, with a 72-hour first-findings commitment. Powered by frontier AI models; every finding validated by a senior human.