Background and timeline
Thursday 20 March 2025
- A threat actor with the alias “rose87168” made a post on the hacking forum BreachForums, in which they claimed to have exfiltrated over 6 million records from Oracle Cloud’s SSO platform, impacting over 1,500 organizations.
- In the original post, the attacker provided sample files and listed over 140,000 tenants of the allegedly impacted companies. The threat actor claimed they had exploited a software vulnerability in the cloud provider's single-sign-on (SSO) login servers. The threat actor offered named victims the opportunity to pay to have their details removed from the leak before it was sold. They also sought collaboration from other criminals to help with decrypting and cracking the encrypted and hashed credentials.
- Following this, several parties made claims to support and deny the attacker’s claims in quick succession.
Friday 21 March 2025
- Oracle issued a statement to Bleeping Computer in which they denied the authenticity of the breach and stated that none of their customers lost any data.
- Separately, the threat actor reportedly claimed in an email exchange with Bleeping Computer to have breached Oracle’s platform over 40 days ago and requested Oracle to pay 100,000 in Monero (XMR), a privacy-focused cryptocurrency coin, for information on how they were able to do it, which Oracle allegedly refused. They also made a similar claim on social media platform, X.
- On the same day, the cyber security vendor CloudSEK published a blog post indicating that there was technical evidence to suggest that a known software vulnerability (CVE-2021-35587) affecting OpenSSO Agent component within the Access Manager of Oracle’s Fusion Middleware was likely exploited.
Monday 24 March 2025
- CloudSEK published a separate blog post in which they further examined the threat actor’s claims from a technical perspective. CloudSEK confirmed that the threat actor appeared to have successfully uploaded a file containing their ProtonMail address to a legitimate Oracle Cloud SSO endpoint on 1 March 2025, corroborating their claims.
Tuesday 25 March 2025
- The threat actor “rose87168” provided a sample of 10,000 records from the alleged breach to various security researchers. S-RM has not independently verified the dataset, but preliminary results from a number of researchers S-RM made contact with suggest that the data may be legitimate and may be from the production environments of impacted organizations.
Wednesday 26 March 2025
- Bleeping Computer reports that the threat actor provided the publication with samples of the alleged leaked data, which they verified with Oracle customers who confirmed the authenticity of the LDAP display names, email addresses and other identifying information. Bleeping Computer also reported that the attacker had shared emails with them that they claimed were from an exchange with Oracle.
Public debate over the authenticity of the breach continues. Oracle has not issued any statements following their initial denial on 21 March 2025.
Potential impact
If the authenticity of the breach is confirmed, the first point to verify will be whether the impacted data is valid and up to date, and as such, whether it poses a wider security concern. If the data is current, it could include all or a combination of the following for impacted organizations:
- Java KeyStore (JKS) files, which are used to store cryptographic keys and certificates.
- Encrypted SSO passwords, which enable Single Sign-On and allows users to access multiple applications with one set of login credentials.
- Hashed LDAP credentials, which include usernames and passwords for Active Directory authentication.
- OAuth2 keys, which are part of OAuth2 authentication framework used to authorize access to resources.
- Enterprise Manager Java Platform Security (JPS) keys, which manage access and encryption in Oracle Enterprise Manager.
All the above could potentially be used by a malicious actor targeting one of the affected companies. Where SSO and LDAP passwords are encrypted or hashed, it remains possible that attackers could attempt to decrypt or crack those credentials and then use them to enable further breaches across Oracle Cloud environments or systems where a valid user has reused the same password.
There could also be regulatory implications for affected companies depending on local data protection legislation if the breach is confirmed to include personal data.
Recommendations
As a precaution, we advise all organizations using Oracle’s Fusion Middleware, and particularly organizations listed in the data, to apply the following remediation steps:
- Credential rotation and management: Rotate credentials associated with the Oracle systems. This includes SSO and LDAP Credential Rotation credentials, Enterprise Manager JPS keys and any other relevant credentials. To reduce the risk of users selecting similar or weak passwords, implement strong password policies which include requirements for password complexity, handling and revocation, their cryptographic protection in use and at rest. Since Oracle does not natively support banned password lists, consider engaging a penetration testing team to confirm passwords are not weak or recycled. Ensure Multi Factor Authentication is enforced.
- Threat hunting: Proactively threat hunt in the available telemetry and logs for evidence of suspicious activity, such as unusual logins, suspicious IP addresses or rogue accounts.
If malicious activity is identified
- Preserve evidence (starting with short retention evidence like firewall logs)
- Trigger your incident response plan
- Engage your insurance if in place
- Seek the help of an expert cyber incident response legal firm and a technical incident response team
- Work with experts to implement a containment plan and conduct a forensic investigation across impacted devices
Contact S-RM for further information about the vulnerabilities and response steps.
Written by James Tytler and Milda Petraityte, edited by Dan Caplin