CloudSEK Disputes Oracle Over Data Breach Denial with New Evidence

Oracle is caught up in a cybersecurity mess right now, with claims about a massive data breach affecting its cloud infrastructure. Last week, Hackread.com published an article based on the findings of cybersecurity firm CloudSEK revealing that a threat actor had stolen 6 million records from Oracle Cloud. The hacker, identified as “rose87168“, claimed to have compromised a key Single Sign-On (SSO) endpoint, resulting in the exfiltration of sensitive data including SSO and LDAP credentials, OAuth2 keys, and customer tenant information.

Oracle’s Firm Denial

Shortly after the story broke, Oracle issued a categorical denial, making a strong statement that “There has been no breach of Oracle Cloud.” The company maintained that the credentials published by the threat actor were not associated with Oracle Cloud and emphasized that no Oracle Cloud customers were affected. This statement directly contradicted the findings of CloudSEK, which had alerted the public and Oracle via formal reports.

CloudSEK’s Follow-Up Investigation

However, CloudSEK has doubled down on Oracle’s claims with a new follow-up analysis, presenting what it calls “conclusive evidence” of the breach. In a blog post, which the company shared with Hackread.com ahead of its publishing over the weekend, CloudSEK outlined how their researchers detected the threat actor’s activities on March 21, 2025.

According to the cybersecurity firm, they traced the attack to a compromised production SSO endpoint (login.us2.oraclecloud.com), which the hacker exploited to steal records from more than 140,000 tenants.

CloudSEK also found evidence that the threat actor had actively used the compromised domain to authenticate API requests via OAuth2 tokens, as seen in an archived public GitHub repository under Oracle’s official "oracle-quickstart" account. The endpoint was proven to be in use for production purposes, contradicting Oracle’s assertion that the credentials were unrelated to their infrastructure.

New Evidence: Real Customer Data Confirmed

One of the most noteworthy pieces of evidence involves real customer domain names that the hacker provided as samples. CloudSEK verified the domains against publicly available data and found that they were, in fact, valid Oracle Cloud customers. Some of the domain names identified include:

These domains were present in GitHub repositories and Oracle partner documentation, and CloudSEK confirmed they were not mere dummy or canary accounts. Additionally, the compromised endpoint, login.us2.oraclecloud.com, was validated as an active production SSO setup, used in real-world configurations by OneLogin and Rainfocus.

The screenshot shared by CloudSEK shows “login.us2.oraclecloud.com” was a production SSO setup

The Impact and Concerns

The impact of this breach, if proven, could be serious. The exposure of 6 million records, including encrypted SSO and LDAP passwords risks unauthorized access, espionage, and data breaches across affected systems. Additionally, the inclusion of JKS files and OAuth2 keys means attackers might gain long-term control over affected services.

CloudSEK warns that the compromised credentials could potentially be cracked and reused in a way that poses further risks to enterprise environments. The hacker is also reportedly demanding ransom payments from affected firms to delete the stolen data, amplifying both financial and reputational threats.

CloudSEK’s Stance: Evidence over Speculation

In response to Oracle’s denial, Rahul Sasi, CEO of CloudSEK, stated that the company is focused on providing transparency and evidence rather than speculation. CloudSEK has been sharing its findings through public reports and free tools to help organizations assess whether they are affected.

Additionally, Rahul recommends companies change their SSO and LDAP credentials right away and set up multi-factor authentication (MFA) to add extra protection. It’s also important to take a closer look at logs to spot any unusual activity related to the compromised endpoint. Keeping an eye on dark web forums for any signs of leaked data is a good move too. On top of that, it’s a good idea to get in touch with Oracle Security to figure out any weak spots and fix them.

Questions Are Pouring In Already

Cybersecurity experts are already questioning Oracle’s quick denial. Chad Cragle, CISO at Deepwatch, a San Francisco, Calif.-based AI+Human Cyber Resilience Platform stressed that Oracle needs to address the questions raised by CloudSEK to maintain its credibility.

CloudSEK raises a critical point. If there was no breach, how did a threat actor allegedly upload a file to the Oracle Cloud subdomain? argued Chad. This indicates unauthorized access, even if it wasn’t a full-scale compromise.”

Dismissing the incident without addressing this key detail raises more questions than answers. If Oracle wants to maintain credibility, the company must clarify how the file ended up there, whether any security gaps were exploited, and why the subdomain was taken down, he added.

Heath Renfrow, CISO and Co-founder at Fenix24 a Chattanooga, Tennessee-based cyber disaster recovery firm, expressed concerns about Oracle’s stance on the breach and the threat actor’s ability to upload files within critical infrastructure.

Regardless of Oracle’s position, the presence of a threat actor-uploaded file in the webroot of what appears to be an Oracle Cloud Infrastructure (OCI) login subdomain is deeply concerning, said Health. This detail, coupled with the public availability of sensitive data on forums, raises valid questions about the scope of compromise and whether customers with federated login configurations could be at risk.

Hackread.com has reached out to Oracle. Stay tuned for updates!




Source link