Oracle’s SaaS Breach Cover-Up Exposed: Evidence Contradicts Denials

Oracle faces mounting scrutiny after cybersecurity researchers uncovered evidence of a breach in its SaaS infrastructure, contradicting the company’s public denials. The incident, first reported by Kevin Beaumont on DoublePulsar, involves leaked internal data, customer credentials, and attempts by Oracle to suppress evidence¹. This article examines the technical details, Oracle’s response, and actionable steps for affected organizations.

Summary for CISOs

A threat actor accessed Oracle’s SaaS systems, exfiltrating configuration files, LDAP credentials, and internal meeting recordings. Oracle denied the breach by narrowly defining “Oracle Cloud” while ignoring compromised legacy systems rebranded as “Oracle Classic.” Researchers confirmed the breach via Archive.org-hosted evidence and third-party validation².

Impact: Exposure of customer emails, encrypted passwords, and internal system details.
Oracle’s Response: Semantic denials (“no breach of Oracle Cloud”) and takedown requests for evidence.
Evidence: Leaked 2-hour internal meeting recording, write access to login.us2.oraclecloud.com.
Recommendations: Rotate all Oracle SaaS credentials, audit logs for SSO anomalies, demand clarity from Oracle.

Technical Details of the Breach

The attacker, using the alias “rose87168,” demonstrated access to Oracle’s infrastructure by uploading a file to login.us2.oraclecloud.com, a server managed by Oracle¹. Archive.org preserved this evidence until Oracle requested its removal. Researchers retrieved a second archived copy confirming the breach³.

Key findings include:

Data Type	Source	Verification
LDAP configurations	Leaked files	CloudSEK, SOCRadar⁴
Internal meeting recording	YouTube (since removed)	Transcripts discuss password vaults¹
Customer emails	Hudson Rock	Matched with affected organizations⁵

Oracle’s Contradictory Statements

Oracle told BleepingComputer, “There has been no breach of Oracle Cloud,” but researchers note the compromised systems fall under “Oracle Classic,” a rebranded legacy service still part of Oracle’s cloud offerings¹. This semantic distinction allowed Oracle to technically avoid admitting fault while customers remained at risk.

Critics, including Beaumont, argue Oracle violated its own Incident Response Policy by failing to notify impacted customers promptly⁶. Dark Reading reported that delays in disclosure prevented organizations from resetting credentials proactively⁴.

Actionable Steps for Defense

Organizations using Oracle SaaS or Oracle Classic services should:

Rotate all credentials, including SSO and API keys.
Search logs for unusual access patterns (e.g., off-hours SSO attempts).
Request a detailed impact assessment from Oracle, specifying whether their systems were affected.

For detection, monitor for:

# Sample Splunk query for anomalous Oracle SaaS logins
index=oracle_logs sourcetype=saas_login 
  | stats count by user, client_ip 
  | where count > threshold

Conclusion

The Oracle breach highlights the risks of opaque incident response practices. While the company’s narrow denials may limit legal exposure, they erode trust and delay mitigation. Independent verification by researchers remains critical when vendors withhold transparency.