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

The week

In the first days of October 2025, senior executives at many organizations opened an unwelcome email. A group claiming ties to Cl0p, one of the best-known criminal extortion operations, said it had stolen data from their Oracle E-Business Suite systems and wanted to be paid for its silence. Google’s threat intelligence team said it began tracking the email campaign on September 29.

Oracle E-Business Suite is an ERP system, short for enterprise resource planning: the back office in software form, where an organization pays suppliers, runs payroll, tracks purchases and keeps its books. It is unglamorous, and in many organizations the finance department, rather than the security team, treats it as its own.

On Saturday, October 4, Oracle issued an emergency fix for a flaw catalogued as CVE-2025-61882. (A CVE number is the public tracking label the security world gives each known software weakness.) The flaw affected E-Business Suite versions 12.2.3 through 12.2.14 and allowed what specialists call remote code execution without authentication: an outsider who had never logged in could send the system a carefully crafted request over the internet and make it run the attacker’s own commands. The loading dock door, in effect, obeyed anyone who knew the right words.

On October 6, CISA, the federal Cybersecurity and Infrastructure Security Agency, added the flaw to its Known Exploited Vulnerabilities catalog, its official list of weaknesses that attackers are actually using. Federal agencies treat that list as a must-fix list, and many private organizations follow it too.

Then came the most uncomfortable detail. Google’s investigators later reported exploitation as early as August 9, 2025, weeks before any patch existed, and suspicious activity as far back as July. That makes it a “zero-day”: a weakness attackers used before the software maker had any fix to offer. By the time the patch arrived, much of the stealing had already happened.

One more detail shaped everything that followed. The campaign stole data and demanded payment. Nothing was encrypted. There were no frozen screens and no locked files, nothing that would make an outage obvious. For many victims the first sign of trouble was the extortion email itself.

On a Monday morning in a finance office, the chief financial officer forwards an odd email to the general counsel. It claims that someone has copied the company’s supplier records, payroll data and contracts, and it attaches a list of file names that look uncomfortably real. Nobody in IT saw an outage. Nothing is broken. Within hours the question in the room has moved from “is this real?” to “what exactly did they take, and who do we have to tell?”

Some version of that scene played out in many organizations in October 2025. Most coverage treated the campaign as another zero-day patching sprint: a flaw, a fix, a race to apply it. 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, and each calls for a management decision.

The vocabulary behind an ERP extortion

A few terms make this kind of event sound more mysterious than it is.

ERP. Enterprise resource planning software is the system of record for the business side of an organization. Oracle E-Business Suite is one of the longest-established examples. A single ERP installation might handle accounts payable, purchasing, general ledger, human resources, payroll and expense claims. If the organization’s money, people or suppliers are involved, the ERP probably knows about it.

Vulnerability and patch. A vulnerability is a mistake in software that lets someone make it behave in a way its designers never intended. A patch is the software maker’s correction. Applying a patch usually means stopping the system, installing the fix, testing that everything still works and bringing it back. For a finance system, that downtime has to be scheduled around payroll runs and month-end close.

Zero-day. A zero-day is a vulnerability attackers use before the vendor has released a fix, so defenders have had “zero days” to patch. In this case, Google’s investigators reported exploitation as early as August 9, 2025, and the emergency fix arrived on October 4.

Remote code execution without authentication. This is the worst category of software flaw. “Remote” means the attacker does not need to be in the building. “Code execution” means they can make the system run instructions of their choosing. “Without authentication” means they do not need a username or password. Together, those words mean anyone on the internet who could reach the vulnerable part of the system could, in effect, take control of it.

Data extortion. Classic ransomware scrambles an organization’s files and demands payment for the key to unscramble them. Data extortion skips the scrambling. The criminals copy valuable information and threaten to publish or sell it unless they are paid. That approach is harder to spot, because nothing visibly stops working. The October campaign was pure data extortion: data was stolen and payment demanded, and nothing was encrypted.

Put those pieces together and the shape of the attack is clear. A widely used back-office system had a flaw that let strangers in. Attackers used it unnoticed for weeks. Then, rather than breaking anything, they sent executives a bill.

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, an outside firm paid to run and maintain it. 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, periods when no one is allowed to touch the system, are common and long.

That arrangement suits stability. Finance teams have good reasons to fear an unplanned change during close; a broken posting routine can delay financial statements or misstate them. 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 security team wanted the system patched now. The finance team wanted to know what would break. The outside partner pointed to a contract that promised routine updates on a routine timetable. Each position was reasonable on its own terms. Together they produced delay.

The fix is a short written runbook for each business-critical application: a pre-agreed set of instructions for a specific situation, much as an airline crew has a checklist for an engine warning. For an ERP emergency it should settle a handful of points on one page:

• Who can declare an emergency change, and who is their deputy when they are on a plane.
• Who must be told, and how quickly: the CFO, the general counsel, the chief information security officer, the audit committee chair.
• What downtime the business accepts, and at what point in the financial calendar that answer changes.
• What the managed-services partner has to do, and how fast.

The last point deserves emphasis. 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. A tabletop is a rehearsal around a conference table: someone reads out a scenario (“it is Saturday morning, Oracle has just published an emergency fix, and quarter-end close starts Monday”) and the people named in the runbook talk through what they would actually do.

Take a regional bank that has done this work. Its runbook says the chief operating officer can authorize emergency downtime for the ERP, with notice to the CFO. Its managed-services contract requires the partner to begin applying a critical fix within a set number of hours of the vendor’s release, weekends included. When the Saturday advisory lands, the security team pages the COO, the COO approves a window that evening, and the partner applies the fix. By Sunday the bank is working on the harder problem of whether anything was taken before the fix existed. A bank without that runbook spends the weekend working out who may authorize the fix.

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. Suppliers log in to check purchase orders and payments; employees check pay slips from home. 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.

A building with a public reception desk is a fair comparison. Having a reception desk is fine, so long as the corridor behind it does not lead straight to the records room. Internet-facing modules are the reception desk; the rest of the ERP is the records room. A flaw like the one Oracle fixed let strangers walk past reception without signing in.

An exposure review settles three things. First, which components must be reachable from the internet, and by whom. Second, whether the rest can sit behind a VPN (a private, encrypted tunnel into the corporate network), a zero-trust access proxy (a gatekeeper that checks who you are and what device you are on before letting each request through) or an allow-list of supplier addresses. Third, whether a reverse proxy or web application firewall sits in front, a filter that inspects incoming web traffic and 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. These services probe an organization’s internet addresses from the outside, the way a burglar walks round a house checking doors and windows. 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. Single sign-on means people log in once through the organization’s central identity system; MFA, multi-factor authentication, means they also confirm a code or tap a prompt on their phone. A stranger without credentials then never reaches the application at all. Restricting administrative and servlet paths at the proxy, the technical back doors used to run and configure the application, 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.

Those listings made the emails effective. An executive reading a vague threat can reasonably wait for evidence. An executive reading a list of real file names from their own payroll system cannot.

Two controls matter most. The first is retention inside the application: how long old records are kept. 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. Whatever was shredded last year cannot be stolen this year, and does not have to be catalogued for regulators.

Retention is a business decision dressed up as a technical one. Finance, HR, legal and records management each have rules about how long certain documents must be kept, and those rules set a floor. Nobody sets a ceiling. A simple policy that says “closed supplier records are archived out of the live system after the legally required period” turns a permanent risk into a shrinking one.

The second control is monitoring bulk data movement out of the application tier. Ransomware controls watch for encryption and malicious programs. 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. An egress baseline is a record of how much data normally leaves a server and where it goes; anything far outside that pattern raises an alert. Egress baselines for ERP servers are cheap to build and rarely exist.

Data also drives notification, the legal duty to tell affected people and regulators. 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. If the general counsel already knows that the supplier tables hold bank details but no personal health data, and that the payroll tables hold Social Security numbers for employees in particular states, the first conversation after an extortion email is about deadlines, not discovery.

Where the costs land outside IT

Filing this episode under “cyber” and moving on would miss where the costs actually land.

Money. The direct costs of a theft-only incident are forensic investigators, outside counsel, notification mailings, credit monitoring for affected individuals and, sometimes, a decision about whether to pay. These costs fall well outside the IT budget, and most are driven by how much data was taken and how quickly the organization can establish what it was.

Risk and regulators. Banking agencies, health regulators and state attorneys general expect organizations to know what sensitive data they hold and to notify on time. An organization that cannot quickly say what was in its ERP will struggle to meet those expectations, whatever the attackers actually took.

Suppliers and staff. The people most exposed in an ERP theft are often not customers at all. They are suppliers whose bank details sit in the payables module and employees whose payroll records sit in HR. Both groups will want to know what happened, and both relationships are hard to repair once trust slips.

Reputation. Extortion is a pressure tactic built on embarrassment. The organizations best placed to resist it are those that can say, quickly and credibly, what was exposed and what they are doing about it.

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. No new product is required. Each fix is a decision that someone has put off, usually because the system belongs to finance and the risk belongs to security.

An organization that has absorbed the lesson

The standard here is not exotic. In an organization that has taken this episode to heart, every business-critical application, the ERP included, has a named business owner, a named security contact and a one-page emergency runbook that both have signed. Outside partners who run those applications have an emergency clause in their contracts, with response times in hours, and have taken part in at least one rehearsal. There is a current list of every part of every business application that can be reached from the internet, each item with an owner and a reason, reviewed annually, and public-facing modules sit behind single sign-on with MFA wherever suppliers and employees can tolerate it.

The same organization sets retention rules with both a minimum and a maximum, and someone checks that old records actually leave the live system. Servers that hold sensitive business data have egress baselines and alerts. Counsel holds a map of which notification rules apply to the data in each major system.

The failures are equally recognizable. The most frequent is treating the patch as the finish line. When exploitation predates the fix, patching closes the door but says nothing about who already walked through it; the investigation still has to happen. Others let the ERP calendar override the threat calendar by default, so that an emergency fix waits for the next scheduled window, or assume that because no ransomware alarm went off, nothing happened. Many keep everything forever because deleting anything feels risky, when in practice the stored data is the risk. And many leave the outside partner out of the plan, so that the firm that actually holds the keys learns of the emergency at the same time as everyone else.

Say a county government runs payroll and procurement for several departments on an older ERP. Its supplier portal has faced the internet for years because local vendors need to submit invoices. After a review, the county keeps the portal public but puts it behind single sign-on with MFA, blocks the administrative paths at its web filter, archives closed vendor records beyond the legally required period, and asks its managed-services partner to sign an emergency-response clause. Each step is inexpensive. Together they mean the next flaw in that portal reaches less, exposes less and gets fixed faster.

Finance and security must share the answers

Testing whether the organization is ready does not require knowing the internals of an ERP. A few direct questions tend to reveal the gaps.

1. If a vendor published an emergency fix for one of our business applications on a Saturday, who could approve taking it offline that weekend, and have they agreed to that in writing?
2. Does our managed-services contract oblige the partner to act on an emergency fix within hours, and have we tested that?
3. Which parts of those applications can be reached from the internet today, and who last confirmed that each one needs to be?
4. How many years of old supplier, payroll and contract records sit in the live system, and who decides when they leave?
5. If an extortion email arrived tomorrow with a list of our file names, could we say by the end of that day which notification laws applied?

The answers matter less than who gives them. If every one gets passed back and forth between finance and security, that is the gap Cl0p exploited.

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 without fanfare. The group’s method is industrial rather than personal. It finds one weakness in a product that thousands of organizations run, uses it against many of them at once, and then works through the list of victims with extortion demands. Business software that is widely installed and often internet-facing is exactly what that method needs.

The story also did not end with the first fix. Oracle fixed a second E-Business Suite flaw, CVE-2025-61884, on October 11, and CISA added it to its exploited catalog on October 20. CISA’s catalog marks both flaws as known to have been used in ransomware campaigns. One emergency fix rarely closes the matter; a product under active attack often needs several rounds of attention in quick succession, which is another argument for having emergency authority settled before the first one.

The reported exploitation timeline matters most in hindsight. Exploitation dates to at least August 9, 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: working out what had been taken and whom the law required them to tell. Organizations that already knew what their ERP held, and what faced the internet, scoped their exposure far faster.

The speed of a response is mostly set before the incident begins. Patching quickly matters, but knowing your data, your exposure and your decision-makers matters more when the attackers have had weeks of head start. The case for treating business applications as part of the attack surface, owned jointly by the business and by security rather than by whichever side happens to hold the budget, has only strengthened since.