July 11, 2025
Proactive Defense: The Importance of Incident Response Planning in Cybersecurity
Actively Exploited VMware Vulnerabilities Used to Bypass Security Controls and Deploy Ransomware
March 23, 2025
CVE-2025-0927 – Canonical Ubuntu Linux Vulnerability
March 24, 2025
Actively Exploited VMware Vulnerabilities Used to Bypass Security Controls and Deploy Ransomware
March 23, 2025
CVE-2025-0927 – Canonical Ubuntu Linux Vulnerability
March 24, 2025
Listen Audio Blog
On March 21, 2025, cybersecurity firm CloudSEK’s XVigil uncovered a high-stakes cyber incident involving a threat actor known as “rose87168,” who claimed to have stolen 6 million records from Oracle Cloud’s federated Single Sign-On (SSO) and LDAP systems. The data, allegedly exfiltrated from outdated Oracle Fusion Middleware servers, includes encrypted passwords, Java Keystore (JKS) files, and enterprise manager keys. While Oracle denies any breach of its cloud infrastructure, mounting evidence and the threat actor’s extortion tactics raise urgent questions for organizations worldwide. This blog unpacks the incident, analyzes conflicting claims, and provides actionable steps to mitigate risks.
What Happened?
On March 21, 2025, threat actor “rose87168” surfaced on BreachForums, offering to sell 6 million records allegedly stolen from Oracle Cloud’s SSO and LDAP systems. The data includes:
- Encrypted SSO/LDAP passwords
- Java Keystore (JKS) files and key files
- Enterprise Manager JPS keys
The Attack Vector
The attacker claims to have exploited CVE-2021-35587, a critical vulnerability in Oracle Access Manager (part of Fusion Middleware 11G). This flaw, patched in 2021 but still unaddressed in outdated systems, allows unauthenticated attackers to hijack Oracle Access Manager via HTTP. The breach reportedly targeted the subdomain login.us2.oraclecloud.com, which hosted end-of-life Oracle Fusion Middleware 11G software last updated in 2014.
Evidence of Access
To substantiate their claims, “rose87168” shared an Internet Archive link showing a .txt file uploaded to Oracle’s login.us2.oraclecloud.com server. The file contained their ProtonMail address, suggesting at least partial access to Oracle’s infrastructure.
Oracle’s Denial vs. Threat Actor Claims
Oracle has vehemently denied a breach, stating:
“There has been no breach of Oracle Cloud. The published credentials are not for the Oracle Cloud. No Oracle Cloud customers experienced a breach or lost any data.”
However, critical questions remain:
- How did the threat actor upload a file to Oracle’s server?
The Internet Archive proof implies unauthorized access, even if limited to federated SSO systems. - Are federated SSO/LDAP systems excluded from Oracle’s denial?
Oracle’s statement focuses on “Oracle Cloud” broadly, leaving ambiguity about third-party integrations or legacy middleware.
Extortion Tactics
The attacker is extorting affected companies, demanding payment to remove their data from the leak. They’ve also offered to share decrypted credentials with anyone who assists in cracking the encrypted passwords.
Why This Matters for Your Organization
Whether or not Oracle’s core cloud was breached, the incident highlights systemic risks:
- Outdated Software as a Liability
The exploitation of CVE-2021-35587 underscores the danger of unpatched, end-of-life systems. Oracle Fusion Middleware 11G, unsupported since 2014, was a sitting duck for attackers. - Supply Chain Domino Effect
Stolen JKS files and keys could compromise third-party vendors, partners, or clients linked to Oracle Cloud environments. - Reputational and Financial Fallout
Even unverified association with the breach risks customer trust. Extortion demands add financial pressure.
Immediate Steps to Protect Your Business
Assume your data is exposed if your organization uses Oracle Cloud’s SSO/LDAP or legacy middleware. Here’s what to do:
1. Verify Oracle Cloud Usage
- Confirm if your SSO/LDAP systems integrate with login.(region).oraclecloud.com.
- Audit Oracle Fusion Middleware versions (upgrade from 11G immediately).
2. Reset and Rotate Credentials
- SSO/LDAP Passwords: Force-reset all user accounts, especially privileged ones.
- SASL/MD5 Hashes: Migrate to stronger authentication methods like SCRAM-SHA-256.
- Tenant Identifiers: Contact Oracle Support to rotate tenant-specific credentials.
3. Regenerate Certificates and Keys
- Replace SSO/SAML/OIDC certificates and JKS files tied to Oracle Cloud.
4. Monitor and Audit
- Scrutinize LDAP/SSO logs for unusual activity (e.g., unauthorized access from new IPs).
- Deploy endpoint detection (EDR) and network traffic analysis tools.
5. Engage Oracle and Law Enforcement
- Demand clarity from Oracle on federated SSO risks.
- Report extortion attempts to authorities (e.g., FBI, CISA).
6. Strengthen Access Controls
- Enforce MFA for all SSO/LDAP users.
- Adopt zero-trust policies and least-privilege access.
The Bigger Picture: Lessons Learned
- Patch Management is Non-Negotiable
CVE-2021-35587 was flagged by CISA in 2022. Delayed patching creates avoidable risks. - Legacy Systems Are a Liability
Outdated software, especially in critical infrastructure, is a magnet for attackers. - Transparency is Key
Oracle’s vague denial fuels uncertainty. Vendors must prioritize clear communication during breaches.
The Attacker’s List of Companies
The threat actor shared a sample list of domains allegedly impacted by the breach. While this list is circulating in underground forums, we have chosen not to publish or share it here due to ethical responsibilities. Disclosing affected entities without verification could cause unnecessary panic or reputational harm. Our commitment to responsible disclosure and protecting organizations outweighs the fleeting value of speculative reporting.
Conclusion
The Oracle Cloud breach controversy serves as a stark reminder: cybersecurity is a continuous battle, not a one-time fix. While Oracle disputes the breach’s scope, the threat actor’s evidence and extortion tactics demand proactive measures. Organizations must assume compromise, validate their Oracle integrations, and prioritize patch management to avoid becoming collateral damage in this high-stakes incident.