INTELLIGENCE
ZERO|TOLERANCE
Intelligence Advisory
zerotolerance.me
CRITICAL

Oracle Cloud SSO Breach 634 UAE Entities Compromised in Global Attack

Mar 1, 2025 · 634 UAE entities

Publication Date
2025-03-01
Category
Supply Chain
Author
K. Ellabban
Organization
Zero|Tolerance Security Research

Oracle Cloud SSO Breach: 634 UAE Entities Compromised in Global Attack

Oracle's own production SSO infrastructure was running a three-year-old unpatched vulnerability. A threat actor exploited it to compromise authentication systems for 140,000 tenants globally - including 634 UAE government agencies and private sector organizations. Oracle publicly denied the breach while privately briefing affected customers.

Executive Summary

KEY FACTS

  • WhatOracle Cloud SSO breach via CVE-2021-35587 exposed 6M credentials globally.
  • Who634 UAE government agencies and private sector organizations.
  • Data ExposedSSO/LDAP passwords, cryptographic keys, and federation metadata.
  • OutcomeUAE Cybersecurity Council activated emergency defenses; Oracle denied breach.
Incident Overview

WHAT HAPPENED

The attack exploited CVE-2021-35587, a critical unauthenticated remote code execution vulnerability in Oracle Access Manager - a component of Oracle Fusion Middleware that manages authentication and single sign-on for Oracle Cloud tenants. The vulnerability, disclosed in January 2022 with a CVSS score of 9.8, allowed an unauthenticated attacker to achieve complete takeover of the Oracle Access Manager instance via HTTP. A patch had been available for more than three years. Oracle's own production SSO infrastructure was running the vulnerable version as recently as February 2025.

The threat actor, operating under the alias "rose87168," exploited the vulnerability to access Oracle Cloud's identity management backend serving over 140,000 tenants worldwide. The actor exfiltrated approximately 6 million records including Java KeyStore (JKS) cryptographic key files, encrypted SSO and LDAP passwords, Enterprise Manager JPS keys, and SAML federation metadata. The exfiltrated data represented the authentication backbone of every affected Oracle Cloud tenant - the keys, passwords, and trust configurations that govern who can access what.

CloudSEK identified the breach in March 2025 when rose87168 began advertising the data for sale. The actor initially demanded over $20 million from Oracle directly. Oracle refused payment. The actor then pivoted to selling the data on criminal marketplaces. Oracle's public response was denial - the company stated publicly that no breach had occurred while simultaneously conducting private briefings with affected customers.

The UAE Cybersecurity Council activated emergency defense protocols after confirming that 634 UAE entities - approximately 30% government agencies, 7% financial sector, and the remainder spanning education, technology, aviation, and healthcare - were among the compromised tenants.

Impact Assessment

WHAT WAS EXPOSED

  • Java KeyStore (JKS) files containing cryptographic certificates and private keys
  • Encrypted SSO passwords for Oracle Cloud tenant administrators and users
  • Encrypted LDAP passwords used for directory service authentication
  • Enterprise Manager JPS keys enabling administrative access
  • Identity federation metadata including SAML configuration and trust relationships
  • Tenant organization names, administrator email addresses, and account identifiers

The vulnerability CVE-2021-35587 carries a CVSS score of 9.8 (Critical) and had a patch available since January 2022. However, Oracle's own production SSO infrastructure was running a vulnerable version as recently as February 2025--more than three years after the patch was released. The 634 UAE entities span government agencies (~30%), financial sector (~7%), education, technology, aviation, and healthcare. The threat actor rose87168 initially demanded over $20 million from Oracle; when refused, pivoted to selling data on criminal marketplaces.

Compliance Impact

REGULATORY ANALYSIS

The breach presents a structurally distinct challenge because the compromised party is a third-party cloud provider. Under the UAE PDPL, Oracle operates as a data processor. Oracle's failure to patch a critical vulnerability for three years represents a clear breach of processor obligations. Oracle's initial public denial created a compliance crisis for UAE entities, as the 72-hour notification window requires awareness of the breach.

The UAE Cybersecurity Council activated emergency defense protocols, demonstrating the intersection between data protection and national cybersecurity governance. Extraterritorial enforcement against Oracle remains challenging.

Assessment

ZERO|TOLERANCE Advisory

Oracle left a CVSS 9.8 vulnerability unpatched on its own production SSO infrastructure for more than three years. The patch existed. The exploit was public. The result was 6 million compromised authentication records across 140,000 tenants, including 634 UAE government agencies and private sector organizations. This is not a sophisticated nation-state operation. This is a known vulnerability with a known patch that the vendor responsible for the platform failed to apply to its own systems.

Every control below addresses a specific failure in the chain that led from an unpatched system to a national-scale credential compromise.

The root cause is a three-year patching failure on a CVSS 9.8 vulnerability in internet-facing authentication infrastructure. Vulnerability management programs must enforce maximum patching timelines based on severity - 72 hours for critical vulnerabilities in internet-facing systems, with no exceptions for the vendor's own infrastructure. Automated vulnerability scanning using tools such as Qualys, Tenable, or Rapid7 must continuously assess externally accessible attack surfaces. CVE-2021-35587 had public proof-of-concept exploit code available.

The difference between an organization that patches a critical CVE in 72 hours and one that leaves it unpatched for three years is not resources or complexity - it is whether anyone is accountable for the patching timeline.

The exfiltrated data included encrypted SSO and LDAP passwords, JKS cryptographic key files, and SAML federation metadata. For every affected UAE entity, these credentials represent live access to cloud environments if decrypted or replayed. Immediate response requires forced rotation of all SSO and LDAP credentials associated with Oracle Cloud tenants, revocation and reissuance of all cryptographic certificates stored in compromised JKS files, and regeneration of SAML federation trust relationships.

Credential rotation must be accompanied by audit log review to identify any unauthorized access that occurred using the compromised material between the time of exfiltration and the time of rotation. The window of exposure - potentially months - means that any access during that period must be treated as potentially compromised.

Oracle's public denial while privately briefing customers created a structural compliance crisis for every affected UAE entity. Under the UAE PDPL, the 72-hour breach notification clock starts when the data controller becomes aware of the breach. If Oracle, as the data processor, denies the breach publicly while briefing customers privately, the customer must decide whether private intelligence from a vendor that is publicly denying the incident constitutes sufficient awareness to trigger notification obligations.

Cloud service agreements must include contractual breach notification requirements with specific timelines, defined notification channels, and financial penalties for delayed or misleading disclosure. Organizations dependent on third-party cloud providers must maintain independent security monitoring - including dark web intelligence feeds from services such as Recorded Future, Flashpoint, or CloudSEK - rather than relying solely on vendor self-reporting.

The 634 UAE entities span critical sectors including government, finance, aviation, and healthcare. The compromised SAML federation metadata and JKS key files could enable attackers to forge authentication tokens and impersonate legitimate users across federated systems.

Implementing certificate pinning for SAML trust relationships, deploying hardware-bound credential storage using HSMs for cryptographic keys, and enforcing phishing-resistant MFA (FIDO2) as a secondary authentication layer independent of the compromised SSO infrastructure would have ensured that even a total compromise of Oracle's identity platform could not cascade into unauthorized access across downstream UAE systems. The lesson is architectural: critical authentication infrastructure must be designed so that compromise of a single vendor does not grant access to everything.

References

SOURCES

CloudSEK Threat Intelligence Report, The National (UAE), BleepingComputer, The Register, CISA/AHA Joint Advisory, UAE Federal Decree-Law No. 45 of 2021, NIST NVD CVE-2021-35587