.jpeg){kind=avatar}
.jpeg){kind=avatar}
.png){kind=avatar}
Executive Summary
Introduction
On 21st March 2025, a user named rose87168 posted on BreachForums, claiming access to Oracle Cloud’s login servers and offering sensitive data including SSO & LDAP credentials, OAuth2 keys, and customer tenant information for sale. CloudSEK with the help of CloudSEK Nexus and cyber HUMINT was the first to verify the data and authenticity and informed the public and our customers. Since the alleged data could lead to widespread supply chain attacks, we also published a TLP Green report warning the community. We also informed Oracle the same day by sending a TLP RED report. We also published a free tool to check if your organisation was on the list of victims shared by the attacker.
Oracle, later on the same day, responded with a categorical denial: “There has been no breach of Oracle Cloud.”
Since we were to first to disclose the threat, we got several questions, which we have covered on
What is CloudSEK?
How were we able to Analyze and verify the authenticity in a short time?
More such questions in the FAQs Section
We believe there was a lack of judgment at the end of Oracle, and we intend to publish more details that would help the community and Oracle to investigate the incident better. At CloudSEK, we believe in transparency and evidence-based validation — not to create panic but to enable preparedness, which we have been doing for the last 10 years.
UPDATE - Please check the analysis section for updated information
Background
While the threat actor was able to share a sample list of customer details, the threat actor also provided evidence of the attack by uploading a file created on "login.us2.oraclecloud.com" and archiving the public URL, with the attacker's email within the text file.
The server, which appeared to be an SSO service, was active approximately 30 days ago. This falls in line with the threat actor’s claims that the targeted server was taken down by Oracle a few weeks before the breach.
Analysis
Information from Research
Our goal was to verify whether the endpoint in question was a legitimate Oracle Cloud production asset, and whether real customer tenants had exposure rather than just test data.
To form the conclusion, we looked up thousands of our intelligence sources to come to the following conclusions:
Evidence #1: Purpose of login.us2.oraclecloud.com
- We found a now archived public GitHub repository uploaded by oracle-quickstart ( which is Oracle’s official organisation on Github) that has mentions of “login.us2.oraclecloud.com”.
Purpose of the Script:
- OAuth2 Authentication – The script uses “client credentials grant” to authenticate API requests.
- Token Generation – It sends a POST request to this URL with client_id and secret_key (Base64 encoded).
- Authorization Header – The returned access token is then used in API requests as a Bearer token.
The script within the GitHub repo, mpapihelper.py, directly references login.us2.oraclecloud.com for OAuth2 access token generation.
The token would subsequently be used for interacting with the Oracle Cloud Marketplace API that facilitates the management of marketplace listings.
Evidence #2: Real Customer Domains Matched Attacker's List
- Multiple public GitHub repositories contain hardcoded credentials or configs pointing to login.us2.oraclecloud.com, including:
1: https://github.com/BhavaniPericherla/Selenium/blob/master/config.properties
- Domain: sbgtv.com
- Status: Present in the tenant list shared by the TA
2: https://github.com/Ejazkhan42/React-UI/blob/9f0b5e36f34c80d514b72af27e9d6973ff3fedf1/queries.js#L284
- Domain: nexinfo.com
- Status: Present in the tenant list shared by the TA
3: https://pdfslide.net/embed/v1/manual-del-portal-de-proveedor-supplier-portal-manual-del-portal-de-proveedor.html [Now Inactive]
Context: This document served as a detailed reference about a company’s supplier portal. The document instructed users to log in using the Oracle Login endpoint (ehbm.login.us2.oraclecloud.com) in question.
- Domain: nucor-jfe.com
- Status: Present in the tenant list shared by the TA
4: https://github.com/juju/go-oracle-cloud/pull/1/commits/4200f51ee63563ab07bac3c038b29d294b6c81b8
- Domain: cloudbasesolutions.com
- Status: Present in the tenant list shared by the TA
5: A document used as a “User Guide” for Oracle on rapid4cloud CDN, who are Oracle’s Gold Partner, contains the URL of OAM in the troubleshooting section.
- Domain: rapid4cloud.com
- Status: Present in the tenant list shared by the TA
Evidence #3: “login.us2.oraclecloud.com” was a production SSO setup
- OneLogin, an IAM solutions provider, has a knowledge-base article about Oracle Fusion, demonstrating how to configure OneLogin to provide SSO for Oracle Fusion using SAML.
2: Rainfocus, an Oracle Cloud deployment and migration partner, had the following file on their website.
As we can see above, the manual advises users to log on to <identity-domain>.login.us2.oraclecloud.com/fed/idp/metadata to download the Identity Provider Metadata, reinforcing the fact that <identity-domain>.login.us2.oraclecloud.com is being used in production environments.
Impact
- Mass Data Exposure: Compromise of 6M records, including sensitive authentication-related data, increases risks of unauthorized access and corporate espionage.
- Credential Compromise: Encrypted SSO and LDAP passwords, if cracked, could enable further breaches across Oracle Cloud environments.
- Extortion & Ransom Demands: Threat actor is coercing affected companies to pay for data removal, increasing financial and reputational risks.
- Supply Chain Risks: Exposure of JKS and key files may enable attackers to pivot and compromise multiple interconnected enterprise systems.
Remediation
- Immediate Credential Rotation: Change all SSO, LDAP, and associated credentials, ensuring strong password policies and MFA enforcement.
- Incident Response & Forensics: Conduct a thorough investigation to identify potential unauthorized access and mitigate further risks.
- Threat Intelligence Monitoring: Continuously track dark web and threat actor forums for discussions related to the leaked data.
FAQ
What is CloudSEK?
CloudSEK, founded in 2015, is a Cyber Intelligence company specializing in Predictive Threat Analytics, Digital Risk Protection, Attack Surface Monitoring, and Supply Chain Monitoring. We help organizations worldwide quantify and prioritize cyber threats for robust security. Our client base includes at least 10% of Fortune 500 companies who rely on our contextual intelligence.
At CloudSEK, we differentiate ourselves by focusing on IAV-based intelligence rather than traditional IOCs. Our Initial Attack Vector (IAV) Approach prevents attacks before they gain an initial foothold in networks by identifying and mitigating potential entry points. This proactive methodology helps organizations stop threats at the earliest stage of the attack chain.
More about us on Gartner Peer Insights -
How were we able to Analyze and verify the authenticity in a short time?
The above analysis only takes 2-3 minutes on CloudSEK Nexus platform. Nexus allows security professionals to ask any questions related to your assets and threats and we will scan hundreds of sources, correlate and quantify those threats for you. Have a look at CloudSEK Nexus.
Could this be a dev/test server with dummy data?
A: While some subdomains contain “-test”, the data linked to these environments involves real company domains, OAuth2 interactions, and login credentials. Furthermore, the domains match those in the threat actor’s list, which includes known Oracle customers. This makes the “test server” theory unlikely as a complete explanation.
Could the attacker have fabricated or reused this data?
A: While attackers sometimes compile data from multiple sources, the presence of recent, unindexed credentials and specific server interactions make this highly unlikely. The upload of a file to a live Oracle login endpoint further confirms unauthorized access.
Is CloudSEK releasing the full report and analysis, and will it collaborate with Oracle or others on this?
A: CloudSEK is releasing key parts of its analysis and verified evidence in a responsible, TLP-GREEN manner to inform and protect the wider community. However, the full dataset and sensitive details will not be made public to avoid further exploitation or harm. We have shared a TLP-RED report with Oracle and remain open to working with Oracle and other relevant stakeholders to support a thorough and responsible investigation into the incident.