Wednesday, October 15, 2025
HomeCybersecurityGoogle: Clop Accessed “Significant Amount” of Data in Oracle EBS Explo

Google: Clop Accessed “Significant Amount” of Data in Oracle EBS Explo

The Clop ransomware group likely began targeting Oracle E-Business Suite (EBS) instances as early as August 9, successfully exfiltrating a “significant amount” of data new insights from Google Threat Intelligence Group (GTIG) and Mandiant have revealed.

An individual or group of people claiming to be working with the Clop ransomware was observed sending extortion emails to executives at several organizations since September 29.

Google noted that the extortion campaign followed months of intrusion activity by the threat actor and exploitation of the zero-day CVE-2025-61882 began before patches were available.

Similarities and Overlap with Clop Activities

GTIG analysis, published on October 9, highlighted several indicators that Clop, also tracked as FIN11, was behind the extortion campaign.

The contact addresses listed in the extortion emails sent to executives, support@pubstorm.com and support@pubstorm.net, have been listed on the Clop data leak site (DLS) since at least May 2025.

To substantiate their claims, the threat actor has provided legitimate file listings from victim EBS environments to multiple organizations with data dating back to mid-August 2025.

“To date, GTIG has not observed victims from this campaign on the Clop DLS. This is consistent with past campaigns involving the Clop brand, where actors have typically waited several weeks before posting victim data,” the researchers noted.

In addition, the majority of the alleged victims of the Oracle EBS campaign appear to be associated with data theft extortion incidents stemming from the exploitation of managed file transfer (MFT) systems. Such exploits are frequently attributed to Clop and suspected Clop threat clusters.

Post exploitation tooling used in the campaign also shows “logical similarities” to malware used in another suspected Clop campaign.

This includes the use of the in-memory Java-based loader GOLDVEIN.JAVA that fetches a second-stage payload.

This approach has similarities with the suspected Clop exploitation of the Cleo MFT vulnerability in late 2024, which involved the deployment of the GOLDVEIN downloader and GOLDTOMB backdoor.

“However, we have also observed evidence that Clop ransomware, and the Clop DLS has not been exclusively used by FIN11, precluding our ability to attribute based only on this factor,” GTIG added.

How the Oracle EBS Campaign Unfolded

The campaign followed months of intrusion activity targeting EBS customer environments, dating as far back as July 10, 2025.

While GTIG was unable to confirm the exact nature of this initial activity, it said it’s plausible that this was an early attempt at exploitation of Oracle EBS servers.

After Oracle released a Critical Patch Update in July 2025, which addressed nine flaws affecting EBS, Mandiant observed more likely exploitation attempts. GTIG said it cannot confirm if both sets of activity were conducted by the same threat actor.

Oracle warned customers on October 2 that hackers were exploiting unpatched vulnerabilities that were addressed in the July Critical Patch Update.

Threat actors then began exploiting the zero-day CVE-2025-61882 against Oracle EBS customers as early as August 9, 2025, weeks before a patch was made available.

CVE-2025-61882 is an unauthenticated remote code execution (RCE) flaw impacting Oracle EBS versions 12.2.3-12.2.14. An emergency patch for the flaw was released by Oracle on October 4.

GTIG assessed that Oracle EBS servers updated through the patch are likely no longer vulnerable to known exploitation chains.

Security Recommendations for Oracle EBS Customers

GTIG set out a number of actions for organizations to tackle the threats to their Oracle EBS environments.

  • Prioritize the application of Oracle EBS patches released on October 4
  • Hunt for malicious templates, as the threat actor stores payloads directly in the EBS database
  • Block all non-essential outbound traffic from EBS servers to the internet, as this can disrupt the attack chain even if a server is compromised
  • Monitor and analyze network logs for indicators of compromise
  • Use memory forensics of Java processes associated with the EBS application to reveal malicious code or artifacts not present on disk

Image credit: Stefan_Sutka / Shutterstock.com

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments