Source: Tada Images via Shutterstock
Oracle this week steadfastly continued to deny an alleged breach of its Oracle Cloud environment even as some security researchers doubled down on their analysis suggesting otherwise.
The conflicting narratives could create a perplexing situation for Oracle customers, creating uncertainty about whether to take urgent security measures or trust the company's assurances that no breach occurred.
Claims and Counterclaims
On March 21, threat intelligence firm CloudSEK reported that a threat actor known as "rose87168" was attempting to sell approximately 6 million records linked to 140,000 tenants, allegedly obtained from Oracle Cloud Infrastructure's (OCI) login servers. The data, CloudSEK said, included single sign-on (SSO) and LDAP credentials and customer tenant information, which usually is data tied to a specific customer's environment (tenant), like their user accounts, settings, and stored content.
In its report, CloudSEK said its interactions with rose87168 and its own incident analysis suggested the threat actor likely exploited an undisclosed vulnerability in Oracle's cloud environment to gain initial access. However, the hacker has claimed to have exploited a critical Oracle fusion middleware vulnerability, tracked as CVE-2021-35587, to breach the cloud environment.
Related:GPS Spoofing Attacks Spike in Middle East, Southeast Asia
Oracle flatly denied any breach had occurred and maintained that the credentials the threat actor had published in a cybercrime forum were not for Oracle Cloud. The company insisted that no Oracle Cloud customers had experienced a breach or lost any data. It's a stance that the company maintained mid-day Friday, March 28, even as CloudSEK and others challenged that claim with more data that supported the hackers claim.
In response to a third email request for a response to these claims, Oracle spokeswoman Julia Allyn Fishel on Friday reiterated the company's earlier denial of the breach. "There has been no breach of Oracle Cloud (OCI)," Fishel said via email. "The published credentials are not for OCI. No OCI customers experienced a breach or lost any data.”
Conclusive Proof?
Meanwhile, CloudSEK updated their original analysis on March 25 after obtaining what they said was a 10,000-line sample of stolen data from the hacker.That sample alone contained data that appeared to be associated with more than 1,500 organizations, indicating a significant breach, CloudSEK reported. The manner in which the data was formatted — for example {tenant}-dev,{tenant}-test, and{tenant} — strongly suggested the hacker had obtained access to production environments in Oracle's cloud. "The volume and structure of the leaked information make it extremely difficult to fabricate, reinforcing the credibility of the breach," CloudSEK wrote.
Related:Multiple Groups Exploit NTLM Flaw in Microsoft Windows
In comments to Dark Reading, Shashank Shekhar of CloudSEK says his company validated some of the data with customers and there's little doubt the breach happened. "Data revealed encrypted passwords, LDAP configurations, emails, and other information stored on the affected server," he says.
Oracle's ongoing denial of the incident increases the risk that affected organizations won't change their passwords, leaving them vulnerable to future supply chain attacks, he warns. "If you are an active customer, you should rotate passwords immediately, starting from the tenantadmin," Shekar recommends.
Researchers at SOCRadar reached a similar conclusion after obtaining and analyzing a 10,000-record sample of the supposedly stolen data from the hacker. Ensar Seker, CISO at SOCRadar, says the sample alone is not enough to substantiate the hacker's claim of having obtained 6 million records. However, the data in the sample set is detailed enough and credible enough to merit serious attention.
"We believe the data appears consistent with legitimate Oracle Cloud user information," Seker says. "The presence of user credentials, roles, and other metadata typically found in enterprise cloud environments supports the plausibility of the breach."
Related:Wave of Wine-Inspired Phishing Attacks Targets EU Diplomats
Additionally, Seker perceives Oracle's lack of acknowledgement as heightening risks for affected organizations. "Without formal notification or context, organizations are left to independently validate their exposure — often without sufficient internal visibility," Seker cautions. "This creates a reactive environment where companies might overlook subtle Indicators of Attack (IOAs), such as unexpected authentication attempts or irregular access patterns."
If Oracle is aware of any indicators tied to this incident — even without confirming a breach — the company should ideally be providing guidance or metadata patterns that customers can use to validate potential exposure, Seker says. This could include login timestamps, user agent anomalies, or IP ranges linked to suspicious access.
A Perplexing Reticence
Why hasn't Oracle responded publicly since its original denial of the incident?
Ekrem Celik, cybersecurity researcher at Black Kite, speculates that there may be several reasons. One is that the breach may have occurred inlegacy or peripheral systems — such as login endpoints — rather than Oracle Cloud's core infrastructure. This would allow Oracle to technically argue that its main cloud environment wasn't compromised, Celik argues.
Another explanation could belegal and reputational risk management. "Confirming a breach could carry major regulatory and customer trust implications," he says. "Additionally, Oracle may believe that the leaked data isfabricated or sourced from non-production environments, and therefore not representative of a real security incident."
Like others, Celik says Oracle's lack of transparency puts customers in a difficult position. "It createsuncertainty, delays timely remediation efforts such as credential resets or access audits, andundermines trustin Oracle as a third-party provider," he says. "TPRM teams are left to operate in the dark, potentially exposing themselves to further risk."
Incidents like this show that in modern technology supply chains, risks don't just come from technical vulnerabilities. "They also come fromhow quickly and clearly vendors respond during a security event. When there's a lack of information or delayed communication, it becomes harder for others in the ecosystem to react in time, which can lead towider, downstream risks," Seker says.
