Cl0p’s Oracle campaign: an attack on the systems security teams did not run

The week

In the first days of October 2025, executives at many organizations received extortion emails from a group claiming ties to the Cl0p operation. The emails said data had been stolen from their Oracle E-Business Suite environments. Google’s threat intelligence team said the email campaign began on or before September 29.

On October 4, Oracle issued an emergency fix for CVE-2025-61882, a flaw in E-Business Suite versions 12.2.3 through 12.2.14 that allowed remote code execution without authentication. CISA added it to its Known Exploited Vulnerabilities catalog on October 6. Google and other responders later reported successful exploitation as early as August 2025, well before any patch existed. The campaign stole data and demanded payment. Nothing was encrypted.

Most coverage treated the campaign as another zero-day patching sprint. That framing misses why it worked. Cl0p did not go after the network the security team watches most closely. It went after a finance and supply-chain platform that many organizations run as a business application. The CFO’s team owns it, it is patched on the ERP calendar, and parts of it face the internet for suppliers and employees. Three separate gaps made that platform an easy target: who owns it in an emergency, how much of it is exposed, and how much data it keeps. Each gap has a different owner and a different fix.

Ownership: emergency authority nobody had agreed

In most banks, health systems and agencies, an ERP platform has a business owner, an application team and often a specialist managed-services partner. Security sees it through a vulnerability scanner and a log feed, if that. Patch windows are negotiated around month-end close, payroll runs and audit cycles. Change freezes are common and long.

That arrangement suits stability. It fails in an emergency. When Oracle shipped the fix on a Saturday, many organizations faced a governance question before a technical one: who could take a finance system down that weekend? Where the answer had been agreed in advance, remediation followed the advisory within hours. Where it had not, the decision climbed the management chain while the system stayed exposed.

The fix is a short written runbook for each business-critical application. It names who can declare an emergency change, who must be told, and what downtime the business accepts. It also covers the managed-services partner. Many ERP estates are patched by an outside firm under a service-level agreement written for routine updates. That agreement should include an emergency clause with a response time measured in hours. A tabletop exercise once a year, timed to fall near quarter-end, tests whether the authority holds under pressure.

Exposure: modules that face the internet by design

E-Business Suite modules such as iSupplier and employee self-service exist so that people outside the corporate network can reach them. That design choice is often a decade old and rarely revisited. Regulated organizations repeat the pattern in procurement portals, grant management systems, benefits self-service and hospital supply-chain tools.

An exposure review asks three plain questions. Which components must be reachable from the internet, and by whom? Can the rest sit behind a VPN, a zero-trust access proxy or an allow-list of supplier addresses? Is there a reverse proxy or web application firewall in front that can block a known exploit path while the patch is scheduled?

Many organizations found that October that they could not answer the first question quickly. Their ERP’s internet-facing footprint had never been inventoried apart from the rest of the application. External attack-surface scanning helps here, because it shows what an attacker sees rather than what the architecture diagram says. The output should be a short list of exposed endpoints, each with an owner and a justification that someone re-approves every year.

Where a module must stay public, compensating layers buy time. Requiring single sign-on with MFA in front of supplier and employee portals removes anonymous access to most application pages. Restricting administrative and servlet paths at the proxy narrows what an unauthenticated attacker can reach while a fix is tested.

Data: what an extortionist finds in an ERP

Extortion without encryption depends entirely on the value of what is taken. ERP systems hold vendor banking details, payroll records, tax identifiers, contract terms and employee personal data. In health systems and agencies they can hold much more. The data is structured and complete, so an attacker can easily prove possession. The extortion emails did exactly that, attaching genuine file listings.

Two controls matter most. The first is retention inside the application. Old supplier records, terminated employees’ payroll history and closed contracts often sit in production tables for years because nobody owns the decision to purge them. Archiving or deleting them reduces what can be stolen. It also reduces what must be analyzed after a theft.

The second control is monitoring bulk data movement out of the application tier. Ransomware controls watch for encryption and malicious binaries. A theft-only campaign will not trip them. It shows up, if at all, as unusual outbound volume from servers that normally talk to a database and a few hundred users. Egress baselines for ERP servers are cheap to build and rarely exist.

Data also drives notification. Whether an ERP theft triggers state breach laws, HIPAA, banking agency notification rules or agency reporting depends on what was in the affected tables. Working out that map in advance, with counsel, turns a weeks-long scoping exercise into a lookup.

The three gaps compound. A platform with an agreed emergency owner gets patched sooner. One with a small internet footprint offers less to reach. One that keeps less history gives an extortionist less to sell and the victim less to notify. None of this requires a new product. Each requires a decision that someone has put off, usually because the system belongs to finance and the risk belongs to security.

With hindsight

A year on, the campaign fits a pattern Cl0p had already shown with file-transfer software: exploit a widely deployed enterprise application at scale, then extort quietly. Oracle fixed a second E-Business Suite flaw, CVE-2025-61884, within days, and CISA later listed it as exploited too. Universities, companies and media organizations confirmed they were affected through the autumn, and breach notifications continued into 2026.

The reported exploitation timeline matters most in hindsight. Successful intrusions date to at least August 2025, so patching in October closed the door after many thefts had happened. For affected organizations, the hard work was forensic review and notification analysis. Organizations that already knew what their ERP held, and what faced the internet, scoped their exposure far faster. The case for treating business applications as part of the attack surface has only strengthened since.