For defenders, the immediate operational point is less the cybercriminal infighting than the possibility that Clop’s public-facing leak portal has become untrustworthy. If ShinyHunters truly obtained the onion service’s identity key, it could operate a service at Clop’s existing address, potentially allowing it to impersonate Clop, alter victim communications, or publish material under the appearance of the rival gang’s established site.
That is a much more consequential claim than a routine web defacement. It is also precisely the part of the story for which no public proof has yet appeared.
A real compromise, but an unproven full takeover
According to BleepingComputer, the intrusion began on Friday, September 18, when ShinyHunters said it exploited an unauthenticated file-upload flaw in the Grav CMS installation behind Clop’s leak site. The group first placed a small text file on the server, taunting Clop and linking to ShinyHunters’ own Tor site. BleepingComputer confirmed that the file could be downloaded from the Clop infrastructure.
The site then displayed ASCII art of Umbreon, a Pokémon character long associated with ShinyHunters’ public branding, along with the phrase “rooting your systems since ’19.” Cybersecurity researcher VXDB told BleepingComputer that the artwork matches imagery used in a 2020 HackForums defacement that ShinyHunters claimed at the time.
Those observations establish a compromise of the web-facing site. They do not establish the broader claims that ShinyHunters obtained the full server, source code, /var/log contents, Grav plugins, or the secret material used to operate Clop’s onion service.
BleepingComputer explicitly distinguishes what it observed from what ShinyHunters asserted. That distinction is important in a story involving two criminal groups with an obvious incentive to inflate their leverage: a file upload and defacement demonstrate control of some part of the site; they do not, on their own, demonstrate durable administrator access or a complete data theft.
No second independent outlet had publicly confirmed the claimed server-data theft or key theft as of Saturday, September 19.
Why the alleged onion key theft changes the stakes
Tor onion addresses are not ordinary domain names. The Tor Project explains that an onion service’s address is cryptographically tied to the service’s key material; the private identity key is what allows the operator to prove control over that address. Tor’s own setup guidance is blunt: if the keys leak, another party can impersonate the onion service, leaving it compromised and unsafe to visit.
So ShinyHunters’ claim that it has Clop’s “onion keys” is technically plausible in its stated effect. If valid keys were copied from the server, moving Clop’s website to a new host would not necessarily remove the impostor’s ability to run a service at the established address. Clop would need to abandon the exposed identity, create a new onion address, and persuade its intended audience that the replacement address is legitimate.
That creates a particular problem for a ransomware operation because leak sites are not merely promotional pages. They are used to name victims, display samples of allegedly stolen data, set deadlines, and direct companies into negotiations. A hostile party controlling or convincingly mimicking the address could manipulate any of those functions.
It would also produce a messy attribution problem for threat-intelligence teams. A post published at the old address could be presented as a Clop announcement even if it had been written by ShinyHunters. Conversely, a sudden address change by Clop would not, by itself, prove the key-theft claim. It would show only that Clop no longer trusted its prior hosting or identity material.
Server logs would not automatically identify Tor visitors
One of the more dramatic assertions in the initial account is that files under /var/log could include the IP addresses of people who visited the site. That is possible in a narrow and configuration-dependent sense, but it should not be read as proof that ShinyHunters now has a list of Tor users’ real-world IP addresses.
Onion services are designed so that a website’s operator does not directly see a visitor’s public network address. A normal web-server access log for an onion site will commonly record the local Tor process, a reverse proxy, or other internal infrastructure rather than a visitor’s actual IP address. Application logs, authentication records, administrator SSH logs, misconfigured proxy headers, and external analytics could expose more useful operational metadata, but none of that has been produced publicly.
The same restraint applies to claims about “source code” and plugins. A Grav CMS instance necessarily has application files and configuration data somewhere on the host, but a copied CMS directory would say little about whether ShinyHunters took private negotiations, victim data, payment records, operational chat logs, or access to any additional Clop systems.
The important unanswered question is not whether the attackers copied files; a defacement makes that plausible. It is whether the stolen material contains credentials or key material that survives a server rebuild.
The Grav claim leaves defenders without an actionable indicator
ShinyHunters attributed its initial access to an unauthenticated upload weakness in Grav CMS. Neither it nor BleepingComputer identified a CVE, Grav version, vulnerable plugin, affected endpoint, proof of concept, or patch level. That leaves enterprise defenders with no basis to conclude that a known Grav flaw was exploited—or that the purported weakness affects installations beyond Clop’s site.
Administrators running Grav should avoid treating this as a confirmed product-wide vulnerability advisory. But it is a useful prompt to check the fundamentals that would have prevented many CMS compromises regardless of the precise bug:
- Internet-facing CMS administration functions should require authentication and should not expose upload features unnecessarily.
- Web-server accounts should have only the file-system permissions required to serve the application, not broad access to key stores, backup directories, or unrelated logs.
- Onion-service private keys should be kept outside the web root, restricted to the Tor service account, and backed up as high-value secrets.
- A compromise of the web application should trigger rotation of service keys, administrator credentials, API tokens, SSH keys, and any credentials stored in configuration files.
The last point is the practical lesson from the incident. Separating the website from the onion service identity will not eliminate every risk, but it can limit a web-shell or file-upload compromise from becoming an identity compromise.
A feud rooted in the Oracle E-Business Suite campaign
ShinyHunters told BleepingComputer that the attack was retaliation for threats made by a Clop representative during a dispute that began around Clop’s 2025 Oracle E-Business Suite campaign. That alleged threat, including the claim of violent language, has not been independently verified.
The Oracle component is better documented. Oracle’s October 2025 security alert identified CVE-2025-61882 as a remotely exploitable, unauthenticated Oracle E-Business Suite vulnerability that could lead to remote code execution. Oracle advised customers to apply its updates urgently, and the flaw was associated with the broader E-Business Suite extortion activity attributed to Clop.
BleepingComputer reported at the time that actors calling themselves Scattered Lapsus$ Hunters, including ShinyHunters, released a proof-of-concept exploit that Oracle later said matched exploit activity used in the attacks. ShinyHunters has since maintained that Clop used an exploit that originated with it. That is the group’s account of a criminal dispute, not an independently established ownership record.
The present breach does not change the remediation history for the Oracle flaw: organizations running E-Business Suite still need to verify that the October 2025 security updates and prerequisite patches were applied, then hunt for signs of prior exploitation. But it explains why the confrontation has moved from public taunts to an attack on Clop’s operational infrastructure.
Treat Clop’s old address as compromised intelligence
For companies already dealing with a Clop extortion demand, the defensible position is to assume that anything posted to the compromised leak-site address after the defacement may not reliably represent Clop. That includes purported deadlines, negotiation instructions, victim listings, data samples, payment addresses, or claims about a breach.
Security teams should preserve screenshots and Tor-browser observations with timestamps, separate confirmed Clop communications from messages appearing only on the site, and route any extortion-related decision through counsel, incident-response leadership, and law enforcement contacts. They should not act on a newly displayed cryptocurrency wallet, contact channel, or deadline without independent validation.
Clop can restore a webpage. Restoring trust in the cryptographic identity behind a potentially exposed onion address is harder, and that is the leverage ShinyHunters appears to be claiming.