ShinyHunters ataca a Cl0p: deface y robo de datos en el leak site de ransomware Clop

Qué acaba de pasar

El 19 de septiembre de 2026, BleepingComputer y Cybernews reportaron este viernes 19 de septiembre de 2026 que la banda de extorsión ShinyHunters se infiltró en el data leak site de Cl0p (también escrita Clop), una de las operaciones de ransomware más activas de los últimos dos años. El ataque comenzó el viernes por la noche, cuando — según el claim que ShinyHunters declaró a la prensa — la banda explotó una vulnerabilidad de subida de archivos sin autenticación en Grav CMS, el gestor de contenidos que corre detrás del portal Tor de Cl0p, y dejó un mensaje en texto plano dirigido al grupo rival. Es importante notar que ninguna fuente independiente verificó el exploit todavía: lo que está confirmado es el deface, lo que ShinyHunters afirma haber hecho después. Horas después, el sitio entero estaba defaceado con el ASCII art de Umbreon, el Pokémon que ShinyHunters usa como logotipo desde 2019.

Lo más grave no es el deface visible, que es reversible. Lo grave es lo que ShinyHunters afirma haber robado del servidor: código fuente, plugins de Grav CMS, logs del sistema en /var/log y, sobre todo, las claves privadas del servicio onion de Tor. Si esas claves son válidas — y BleepingComputer no las verificó de forma independiente — ShinyHunters podría mantener el sitio de filtraciones de Cl0p online aunque los operadores legítimos los echen del servidor. En otras palabras, el deface es la foto; el data theft es el problema real.

El vector de entrada: el claim de ShinyHunters sobre una vulnerabilidad en Grav CMS

ShinyHunters declaró a BleepingComputer que el vector inicial fue una vulnerabilidad de file upload sin autenticación en Grav CMS, suficiente para depositar un archivo de texto en el servidor del leak site. Esta afirmación es plausible pero no verificada independientemente hasta ahora. Sí es consistente con el historial incómodo de CVEs que Grav CMS arrastra en 2025 y 2026, varios de ellos explotables sin necesidad de credenciales:

CVE	Tipo	Versiones afectadas	CVSS
CVE-2026-65008	RCE (ejecución remota de código)	Grav 2.0.4 a 2.0.6	9.8 / 9.3 (v3.1/v4.0)
CVE-2026-86197	XSS almacenado para editores de página	Grav < 2.0.20	Alta
CVE histórico (1.10.7)	Escritura de YAML sin auth → ejecución PHP	Grav ≤ 1.10.7	Crítica

ShinyHunters no reveló qué CVE específico usó contra Cl0p. Pero el patrón coincide: un CMS con historial de bypass de autenticación y file upload sin filtro, expuesto en un servicio que debe permanecer accesible a víctimas anónimas vía Tor. Es exactamente el tipo de superficie que un actor con tiempo y dinero ataca cuando quiere un data leak site persistent.

Para un sysadmin que mantiene sitios web públicos, esto es un recordatorio útil: un CMS conveniente no es un CMS seguro. Si tu blog o el panel de soporte interno corre sobre Grav, WordPress, Drupal o cualquier CMS con plugins de terceros, el presupuesto de hardening no es opcional.

El mensaje en texto plano: por qué ShinyHunters subió un archivo

El primer movimiento de ShinyHunters no fue el deface; fue dejar un archivo descargable directamente desde el servidor de Cl0p con un mensaje muy específico:

THIS SITE HAS BEEN PWN3D BY SHINYHUNTERES #Skids10p – Maybe don’t try to threaten us next time.

El archivo además contenía un enlace al propio leak site de ShinyHunters. BleepingComputer descargó el archivo y confirmó que estaba servido desde la infraestructura de Cl0p. Es decir, no era un screenshot: era un archivo real plantado en el servidor. Esto importa porque descarta la teoría de un simple defacement de front-end; el atacante tenía escritura en disco, probablemente vía el endpoint vulnerable de Grav.

Varias horas después, el sitio entero fue reemplazado por una página con el ASCII art de Umbreon y la frase “rooting your systems since ’19 ;)”. La página defaceada seguía siendo servida desde la infraestructura de Cl0p en el momento de publicar el artículo original. El investigador de ciberseguridad VXDB confirmó a BleepingComputer que el arte de Umbreon es el mismo que se usó en el deface de HackForums de agosto de 2020 — otra atribución que ShinyHunters hizo en su momento.

Qué se llevaron: source code, plugins, logs y claves Tor

ShinyHunters dijo a BleepingComputer que había obtenido “full access” al servidor y que estaba terminando de descargar:

• Código fuente de los componentes del leak site.
• Plugins de Grav CMS instalados en esa instancia, incluidos los que pueden tener parches pendientes.
• Logs en /var/log, que en servidores GNU/Linux típicamente contienen autenticación SSH, eventos de Apache o nginx, syslog y, dependiendo de la configuración, journals de Tor.
• Claves privadas del servicio onion que Cl0p usa para su dirección .onion.

Sobre las claves onion, ShinyHunters fue específico:

We have their onion keys. So if they kick us out it wouldn’t matter at all because we control the private keys to host the same exact onion URL.

El modelo de confianza de Tor depende de la custodia de la clave privada del hidden service. Si un atacante copia esa clave, puede montar el mismo .onion en su propia infraestructura, manteniendo la URL y la reputación que Cl0p construyó durante años. Para un grupo de ransomware, esa reputación es el activo: si te listas en Cl0p, pagas. Si el atacante controla la URL, puede publicar filtraciones falsas, romper la credibilidad del leak site, o usarlo como cebo para nuevas víctimas.

BleepingComputer confirmó el deface y el archivo subido, pero no verificó de forma independiente el robo de logs, código fuente o claves onion. Esa verificación pendiente es importante: hasta ahora, las afirmaciones de ShinyHunters son self-reported.

El trasfondo: una pelea entre bandas de cybercrime

El ataque no es oportunista. ShinyHunters dice que es retaliación directa por amenazas que un representante de Cl0p les hizo durante una disputa que viene desde la campaña de robo de datos de Oracle E-Business Suite de octubre de 2025. En esa campaña, Cl0p explotó múltiples vulnerabilidades en servidores Oracle EBS, entre ellas la zero-day CVE-2025-61882, para robar datos de organizaciones y luego extorsionarlas. Oracle confirmó después que el exploit coincidía con un proof-of-concept que se había filtrado públicamente.

Esa filtración fue obra de un actor que se hacía llamar “Scattered Lapsus$ Hunters”, un collectifivo que incluye a ShinyHunters. ShinyHunters afirma que el exploit original era suyo y que Cl0p lo obtuvo sin autorización. La cita directa a BleepingComputer es elocuente:

During the Oracle EBS campaign they ran and stole from me last year, someone from cl0p personally messaged me and said, and I quote (translated from Russian): I have more money than you and all of your people combined, I’ll kill you soon.

BleepingComputer no verificó de forma independiente la amenaza ni el intercambio de mensajes. La historia es una self-reported por ambas partes. Pero el contexto es relevante: el ecosistema de grupos de ransomware y extorsión no es monolítico. Hay rivalidades reales, oportunismo, robo de exploits entre bandas y peleas internas que pueden terminar exponiendo infraestructura de bandas rivales a periodistas e investigadores.

Qué hacer como sysadmin si operas un sitio basado en Grav CMS

El caso sirve como ejemplo concreto de por qué “está en Tor, no me importa” es una respuesta peligrosa. Si tu organización expone cualquier servicio en Tor — para whistleblowers, soporte anónimo, leak site corporativo, o zonas de prueba — el riesgo de file upload sin autenticación y persistencia vía claves de hidden service es real. Recomendaciones operativas:

Auditar la versión de Grav y aplicar parches

Verifica qué versión tienes instalada antes de cualquier otra cosa. Las versiones 2.0.6 y anteriores a 2.0.20 son vulnerables a los CVEs mencionados arriba.

# Localiza el binario o el composer.json
find / -path /proc -prune -o -name "composer.json" -print 2>/dev/null | 
  xargs grep -l '"name": "getgrav/grav"' 2>/dev/null
# Lado admin de Grav: revisa el footer o System > Information
# La versión aparece como "Grav <X.Y.Z>"

Si la versión es anterior a 2.0.20, actualiza primero. La rama 2.0.x tiene el fix de CVE-2026-86197 desde 2.0.20 y el fix de CVE-2026-65008 desde 2.0.7. Si estás en una rama 1.x, considera seriamente migrar — el historial de CVEs críticos en esa línea es largo.

Deshabilitar la subida de archivos donde no aplique

Si tu instancia de Grav no necesita permitir que usuarios anónimos suban archivos, bloquea el endpoint a nivel de nginx o Apache antes de que llegue a PHP.

# Bloquea rutas típicas de upload en Grav
location ~* ^/(uploads|user/pages|images)/(.*).(php|phtml|phar|pl|py|jsp|asp|sh|cgi)$ {
    deny all;
    return 403;
}
# Bloquea la ejecución de PHP dentro de directorios servidos como estáticos
location ~* /uploads/.*.php$ {
    deny all;
}

Esta capa defensiva no sustituye al parche, pero reduce el blast radius si vuelve a aparecer un file upload bug.

Proteger logs y claves onion

Si corres un hidden service de Tor, las claves viven en /var/lib/tor/hidden_service/ (o el directorio que hayas configurado en torrc). Restringe permisos al máximo y rota las claves si sospechas compromiso:

# Permisos recomendados para el directorio del hidden service
sudo chown -R debian-tor:debian-tor /var/lib/tor/hidden_service/
sudo chmod 700 /var/lib/tor/hidden_service/
# Para regenerar la clave onion (cambia la URL, ojo)
sudo systemctl stop tor
sudo rm -rf /var/lib/tor/hidden_service/
sudo systemctl start tor

Aplica el mismo principio a logs: cualquier servidor expuesto debe tener logrotate agresivo y particiones separadas, no porque los logs sean lo más valioso, sino porque son el primer lugar donde un atacante mira para entender qué hiciste después de su intrusión.

Habilitar WAF y rate limiting en el front de Grav

Un WAF tipo ModSecurity con reglas OWASP CRS, o un reverse proxy tipo Cloudflare delante de tu instancia Tor (cuando aplique), corta la mayoría de los intentos de file upload masivo y de path traversal antes de que lleguen al CMS.

# Verifica reglas OWASP activas
sudo apache2ctl -M | grep -i security
sudo grep -i SecRule /etc/modsecurity/modsecurity.conf | head -5
# Reinicia para aplicar cambios
sudo systemctl reload apache2

Si operas detrás de Cloudflare, considera el modo Under Attack durante incidentes activos: añade un challenge JavaScript que filtra la mayoría de los scripts automatizados.

Por qué esta historia importa para sysadmins Linux

El titular parece lejano — bandas de ransomware peleándose en Tor no toca a quien mantiene un servidor Debian en un homelab. Pero el patrón sí toca:

1. CMS con CVEs sin parche: el mismo tipo de software que muchos sysadmins corren para blogs, wikis internas y portales de soporte.
2. File upload sin auth: el vector que ShinyHunters usó es uno de los más explotados del OWASP Top 10, año tras año.
3. Robo de claves de servicio: cualquier servidor que custodia tokens de larga duración (SSH, Tor, OAuth, claves GPG) necesita rotación como respuesta a incidente.
4. Logs como objetivo: si tu servidor es comprometido, los logs son el primer lugar donde un atacante mira. Logrotate + logs remotos (centralizados y firmados) son una capa mínima.

El resto de la historia — la pelea entre ShinyHunters y Cl0p, el PoC filtrado, las amenazas en ruso — es colorido, pero no cambia lo accionable.

Conclusión

El deface de Cl0p a manos de ShinyHunters es noticia de seguridad relevante, no sólo por el simbolismo de un grupo de ransomware siendo hackeado por otro, sino porque el vector que ShinyHunters describe — una vulnerabilidad sin autenticación en Grav CMS — es exactamente el tipo de bug que afectaría a miles de sitios web legítimos si la afirmación resulta cierta. Para los que mantenemos infraestructura en Linux, la lección operativa es: audita la versión de tu CMS, bloquea uploads no necesarios, restringe claves de servicio a permisos mínimos, y rota logs de forma agresiva. El resto es anécdota entre bandas que ya están acostumbradas a estar en las noticias.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux