ShinyHunters Hacks Clop Leak Site: Claims an Unauthenticated File Upload Led to Tor Private Key Theft

1. Basic Information

• Original Title: ShinyHunters hacks Clop leak site, threatens to extort ransomware gang
• Source: BleepingComputer
• Published Date: 2026-09-19
• Updated Date: None
• Severity: High
• Severity Justification: BleepingComputer confirmed a malicious text file and a defaced page on Clop's existing onion address. The claims that an unauthenticated file upload in Grav CMS was the entry point, that the server was fully accessed, and that source code, logs, and Tor private keys were stolen come from ShinyHunters and are not independently verified.
• Original Link: ShinyHunters hacks Clop leak site, threatens to extort ransomware gang
• Related Sources: Tor Project: Onion Services Properties, Grav Documentation: Updating Grav & Plugins
• Related Entities: ShinyHunters, Clop, Grav CMS, Tor onion service

2. Quick Summary

ShinyHunters claims to have exploited an unauthenticated file upload vulnerability in Grav CMS on Clop's leak site. The publication of a malicious text file and site defacement were confirmed on the existing onion address, but the theft of server data and Tor private keys remains unverified.

3. Attack Flow

The following timeline is reported by BleepingComputer. The specific path from the unauthenticated file upload to the subsequent defacement and full access has not been independently confirmed.

Claim of Unauthenticated File Upload and Confirmed Site Defacement

1. ShinyHunters stated that they exploited an unauthenticated file upload vulnerability in Grav CMS running on Clop's Tor leak site.
2. The attackers stated they placed a small text file containing a message and a link to their own leak site. BleepingComputer confirmed that this file could be directly retrieved from Clop's existing onion address.
3. Hours later, a page displaying the ShinyHunters logo and message went live on Clop's existing onion address. BleepingComputer confirmed this defacement, but did not verify whether it was served from the original server or a separate server using stolen private keys.
4. ShinyHunters claimed to have gained full access to the server and stolen source code, Grav CMS plugins, logs under /var/log, and the Tor onion service private key. These claims have not been independently verified.
5. The attackers demanded that Clop contact them within 72 hours, indicating an intent to extort them using the allegedly stolen information.

4. Attacker Location and Execution Point

• According to ShinyHunters, the attackers accessed Clop's Tor leak site remotely and used an upload path in the public web application.
• The malicious text file and defaced page were confirmed on Clop's existing onion address. Public information alone cannot determine whether they were delivered from the original server, and the specific execution paths for code execution, privilege escalation, and private key acquisition on the server have not been published.

5. Visibility for Victims and Administrators

• Victims: Visitors see the content of Clop's leak site replaced by the ShinyHunters logo and message and can directly access the unauthorized text file.
• Administrators: Unexpected uploaded files, changes to public content, abnormal requests to Grav CMS, and changes to file ownership or modification times serve as indicators. Whether traces of private key or log reading remain depends on audit settings and the attack path.

6. Success and Failure Conditions

Success Conditions

• An upload process is reachable without authentication, allowing the attacker to save chosen content to a public area.
• Progressing to full access, as claimed by the attackers, requires code execution or file overwriting via the upload feature, or another vulnerability or misconfiguration; however, the exact path has not been published.

Failure Conditions

• The upload process validates authentication, authorization, extensions, MIME types, content, and storage destinations, and isolates the upload area so that it cannot be executed and is separated from public content.
• Identify the vulnerable Grav CMS core or plugin, vulnerable endpoints, and versions, disable the relevant path, and apply available official patches. Public information does not specify the targeted and fixed versions.

7. What Happens Upon Success

• Confirmed impacts include the publication of an attacker-supplied text file and site defacement on Clop's existing onion address.
• If ShinyHunters' claims are correct, source code, plugins, system logs, and the Tor private key are exposed. If the private key is valid, the attackers could operate the same onion address on a separate server.

8. Observable Logs

• Email: No email-based attack path has been confirmed.
• Proxy / SWG / DNS: If a Tor gateway or monitoring environment is used, correlate connection times to the target onion service with administrative actions. Standard DNS logs do not record onion addresses.
• Endpoint / EDR: Check for new file creation, replacement of public files, or unexpected shell/admin command execution by web processes on the CMS host.
• Identity / IdP: Verify logins, token issuance, and permission changes for CMS administrators or host management accounts. However, the report does not document the use of credentials.
• SaaS / Cloud: If audit logs from the hosting infrastructure, object change history, and access to secret management services are available, check before and after the defacement time.
• Network: Use web access logs to check for unauthenticated uploads, immediate retrieval of placed files, and large outbound transmissions. Data exfiltration destinations and volumes have not been published.

9. Attack Success Determination

Confirmed by Public Information

• Subsequent Compromise Confirmed (Public Content Defacement): BleepingComputer confirmed that a malicious text file could be retrieved from Clop's existing onion address and that a defaced page was displayed at that address. The path from unauthenticated file upload to defacement, full control of the original server, data theft, and Tor private key theft have not been independently verified.

Internal Determination Criteria

• Initial Execution Confirmed: Corroborate unauthorized file creation by web processes or post-upload command execution using process and audit logs.
• Data Theft or Session Compromise Confirmed: Corroborate access to source code, logs, and private keys, followed by outbound transmission or key reuse on another host.

10. Investigation Playbook

• Trigger: Start with unknown files in the public CMS area, unexpected changes to the home page, or unauthenticated upload requests.
• Initial Verification: Check modified file timestamps, owners, hashes, immediate HTTP requests, CMS and plugin versions, and web process privileges.
• Endpoint: Preserve the web root, upload area, CMS plugins, persistence settings, and process lineage.
• Authentication / Cloud: Check authentication history and tokens for CMS administrators, hosts, cloud environments, and secret management services, and revoke exposed credentials.
• Subsequent Actions: Investigate access to /var/log, source code, and Tor private keys, outbound transmission, and onion service startup on other hosts.
• Containment: Isolate the public site and stop suspicious upload paths. Rebuild hosts if integrity cannot be verified, and migrate to a new private key and onion address if Tor private key theft cannot be ruled out. Replace any management credentials suspected of exposure.
• Classification: Distinguish file placement, site defacement, code execution, privilege acquisition, data theft, and private key reuse.

11. Defense and Detection Ideas

• Single Event: Detect uploads from unauthenticated sessions, writes to the web root, and web process access to onion service private keys with high priority.
• Time-Series Correlation: Correlate upload requests, retrieval of placed files, replacement of public pages, log/private key reading, and outbound traffic.
• Hunting: Search for integrity anomalies in CMS plugins and public files, unknown files owned by web processes, and unusual access to private keys and logs.
• Log Gaps: Forward logs from Tor sites, reverse proxies, CMS, hosts, and file audits to a separate system so they are not left only on compromised hosts.
• Priority Countermeasures: Identify the exact versions of Grav CMS core/plugins and suspicious upload paths, stop unnecessary public upload features, isolate upload areas, enforce least privilege for web processes, and apply access controls to private keys. Apply official patches if identified, and execute migration procedures to a new onion address if key exposure cannot be ruled out.

12. Facts / Inference / Hypothesis

Facts

• BleepingComputer confirmed that a malicious text file could be retrieved from Clop's existing onion address and that a defaced page was displayed at that address.
• ShinyHunters stated that they used an unauthenticated file upload vulnerability in Grav CMS.
• ShinyHunters claimed to have stolen source code, plugins, logs under /var/log, and Tor private keys, but BleepingComputer did not independently verify this.

Inference

• The publication of the malicious text file and site defacement were confirmed in chronological order, but public information alone cannot determine whether the same unauthenticated upload path was used for defacement or if there were additional code execution and file overwrite paths.
• The Tor Project explains that a connection to an onion address connects to the host controlling the private key corresponding to that address. Therefore, if the private key theft claim is true, the attackers could use the same onion address even if the original host is removed, necessitating migration to a new private key and onion address.

Hypothesis

No additional hypotheses. Unconfirmed items are listed under "Unknowns and Further Investigation."

13. MITRE ATT&CK Mapping

• T1190 Exploit Public-Facing Application (Confidence: Low): ShinyHunters stated they abused an unauthenticated file upload path in Grav CMS. BleepingComputer confirmed malicious file publication and defacement on the existing onion address, but the vulnerability exploitation path is not independently verified.
• T1491.002 External Defacement (Confidence: High): Clop's external-facing Tor site was replaced with the attackers' page.
• T1552.004 Unsecured Credentials: Private Keys (Confidence: Low): The attackers claimed to have stolen the Tor onion service private key, but this is not independently verified.

14. Unknowns and Further Investigation

• Target versions of Grav CMS or plugins, vulnerable endpoints, whether a CVE has been assigned, and available official patches.
• Whether the confirmed malicious file publication and site defacement stem from the same upload path, or if additional execution paths and privileges led to site-wide defacement and full server access.
• Whether source code, logs, and Tor private keys were actually stolen, and whether the private keys are valid.
• Whether Clop rebuilt the host, patched the CMS, and migrated to a different onion address with a new private key.

15. Impact on SOCs and Organizations

Even when targets are criminal group leak sites, lessons apply to general CMS operations. In this incident, unauthorized file publication and defacement on the existing onion address were confirmed, while the initial access vector, full access, and private key theft remained unverified. Initial response should separate confirmed defacement from unverified server compromise, using evidence to investigate whether sensitive information could have been read by web processes. For onion services, rebuild the host if its integrity cannot be established; migrate to a new private key and onion address only if private-key exposure cannot be ruled out.

16. Summary by Target Audience

• SOC: Verify the timeline of unauthorized file publication and defacement, and evaluate entry vectors, code execution, and log/private key access using separate evidence.
• Administrators: Identify Grav CMS core/plugins and upload paths, disable unnecessary public features, isolate upload areas, and restrict web process access to private keys and logs.
• Users: In this case, the content of the existing onion address was defaced. If private key theft is confirmed, attackers can also use the same address, so users should check migration information provided by operators through alternative trusted channels.