On March 21, 2025, the cloud threat intelligence firm CloudSEK published research detailing a forum post from a threat actor using the alias rose87168, advertising six million records allegedly extracted from Oracle Cloud's Single Sign-On and LDAP systems and claiming impact across roughly 140,000 tenant environments. The actor uploaded sample files to a public bucket as proof, asked Oracle for 200 million dollars in Monero, and began contacting Oracle customers directly to offer data-removal services. Oracle initially denied any compromise of Oracle Cloud Infrastructure, then on April 2, 2025 privately notified some customers of a security incident affecting what Oracle later characterised as a deprecated environment. By April 7 Oracle had acknowledged that two obsolete servers unrelated to the current OCI plane had been accessed and that usernames were exposed, though Oracle disputed the usability of any passwords. For defenders, the case is the classic legacy-endpoint problem: a forgotten authentication surface that nobody rotates and nobody monitors.
Who is rose87168 and how did they get in?
rose87168 is a previously unknown alias that surfaced on the BreachForums underground in January 2025. The actor is not attributed to any state programme; researchers at CloudSEK, Hudson Rock, and Sygnia treat the operator as a financially motivated extortionist with reasonable cloud knowledge but no signs of sophisticated tradecraft. The reported access path was an Oracle Cloud Classic SSO endpoint that, per CloudSEK's analysis, was running an Oracle Fusion Middleware build last updated in 2014. The exposed asset is widely linked to CVE-2021-35587, an unauthenticated remote code execution in Oracle Access Manager that has been in CISA's Known Exploited Vulnerabilities catalogue since 2022. The endpoint sat in a deprecated Oracle Cloud Classic region — what Oracle now describes as legacy infrastructure separate from the modern OCI tenancy model.
What did the attackers actually access?
The sample files published by rose87168 included Java Keystore files, encrypted SSO passwords, key files, and Enterprise Manager JPS keys. Multiple security firms — Sygnia, Arctic Wolf, ACA Global — confirmed that some of the customer-identifying material in the samples matched real Oracle tenant references. Oracle's customer notification confirmed usernames were exposed from the affected servers and stated that password material on those servers was hashed and salted in a way Oracle did not consider trivially crackable. Independent researchers disputed that assessment in cases where the hashing algorithms predated modern KDF guidance. The pragmatic position for tenants: assume any credential or key material associated with Oracle Cloud Classic SSO is burned.
How long were they inside?
Public reporting indicates rose87168 has been operating against the endpoint since at least January 2025, roughly two months before the BreachForums advertisement. CloudSEK noted the affected endpoint had not received a feature update since 2014 and had been reachable on the public internet during a February 17, 2025 Wayback Machine snapshot. The exact compromise timeline remains contested — Oracle has not published an authoritative dwell-time figure, and the deprecated nature of the environment makes log-driven reconstruction difficult.
What did existing controls miss?
Three failures stand out. First, deprecated does not mean offline. The Oracle Cloud Classic SSO surface was decommissioned for new business but kept reachable for tenants who had not migrated, and the underlying Fusion Middleware build was effectively unmaintained. Second, CISA KEV coverage gaps inside the vendor: CVE-2021-35587 had been on the KEV catalogue for years, but the vulnerability scanner monitoring the legacy plane apparently did not. Third, downstream tenant blast radius was invisible until rose87168's public extortion: Oracle customers who had moved to modern OCI were unsure whether the legacy SSO had retained any reference data — federation metadata, JKS bundles, or stored API keys — that could pivot back into a live tenancy.
# Tenant-side rotation checklist for Oracle Cloud Classic exposure
# Run for any environment that ever federated with Oracle Cloud Classic SSO
# 1. Rotate identity domain admin secrets
oci iam user update-user-state --user-id "$USER" --blocked true
oci iam auth-token create --user-id "$USER" \
--description "post-rose87168 rotation $(date -I)"
# 2. Revoke legacy SAML federation trust
oci iam identity-provider list \
--compartment-id "$TENANCY_OCID" \
--query "data[?\"protocol\"=='SAML2']" \
-o table
# Delete any federation pointed at Oracle Cloud Classic IDCS
# 3. Inventory JKS keystores embedded in apps
find /opt /var/oracle -name "*.jks" -mtime +730 \
-exec sha256sum {} \;
# 4. Force-rotate API signing keys for every service principal
oci iam api-key list --user-id "$USER" \
--query "data[].\"key-id\"" -o tsv | \
xargs -I {} oci iam api-key delete --key-id {} --user-id "$USER"
What should defenders do now?
Six steps. First, treat any credential, key, or federation trust ever associated with Oracle Cloud Classic as compromised. Rotate signing keys, JKS keystores, SAML certificates, and any API key issued before April 2025. Second, inventory federation: any active SAML or OIDC trust pointing at a deprecated Oracle Cloud Classic IDCS should be deleted, not merely disabled. Third, audit your own legacy-cloud footprint generally — many enterprises have AWS classic accounts, Azure Classic resource manager artefacts, and GCP App Engine first-generation services that nobody has tested for a patch in three years. Fourth, subscribe to CISA KEV automation that maps every CVE to your asset graph and alerts when an endpoint listed in KEV is reachable from the internet. Fifth, exercise legal and contractual notification: Oracle's customer notification was private, slow, and disputed; your SaaS contracts should specify written 72-hour preliminary notifications with material updates. Sixth, communicate clearly with auditors that a vendor's legacy environment is in scope for your SOC 2 and ISO 27001 supplier-management controls.
What regulatory and contractual follow-on has the case triggered?
Two threads are noteworthy. First, CISA published guidance on April 16, 2025 reminding agencies and operators of critical infrastructure to inventory legacy cloud-identity dependencies and rotate any credential associated with deprecated Oracle environments. The guidance also formalised that legacy cloud planes fall within the operator's risk-management responsibility regardless of marketing terminology around "deprecated" or "Classic". Second, several US class-action complaints filed through April and May 2025 alleged that Oracle's customer-notification delay between the alleged compromise window and the April 2 customer notice violated state breach-notification statutes including those in California, Maine, and Texas. Oracle has disputed both the characterisation of the compromise and the timing claims. For tenants, the practical takeaway is that contractual breach-notification language frequently leaves room for hyperscaler vendors to delay until they have a fully characterised incident, while regulator-facing notification deadlines do not. Procurement teams across enterprise Oracle customers have started inserting more aggressive 72-hour preliminary-notification clauses and per-day liquidated-damages language for notification delay.
How Safeguard Helps
Safeguard inventories every cloud-identity dependency a tenant ships with — JKS keystores, SAML metadata, OIDC federation trusts, and API-signing keys — and cross-references them against CISA KEV, vendor advisories, and breach-disclosure feeds, so a rose87168-class incident surfaces every credential needing rotation within minutes. Griffin AI reachability analysis flags federation trusts that point at deprecated identity planes versus modern tenancies, and surfaces internet-exposed admin endpoints across multi-cloud estates. TPRM workflows score Oracle, Microsoft, AWS, and GCP against your contractual breach-notification SLAs and continuously track which legacy planes vendors have not formally decommissioned. Policy gates block new deployments that embed credentials tied to a known-bad federation source, and ingest the running list of rose87168 IOCs so that responders see one prioritised remediation queue rather than four spreadsheets and a chase across business units.