El 19 de septiembre de 2026, BleepingComputer documentó que ShinyHunters comprometió y modificó el sitio de filtraciones en Tor operado por Clop, uno de los grupos asociados históricamente con campañas de ransomware y extorsión.
BleepingComputer verificó directamente dos elementos: la presencia de un archivo introducido en la infraestructura y el posterior defacement del sitio. Reuters informó posteriormente sobre el incidente y señaló que especialistas consultados consideraron auténtico el enfrentamiento entre ambos grupos.
La profundidad del compromiso, sin embargo, permanece parcialmente sin confirmar.
ShinyHunters afirma haber obtenido código fuente, plugins de Grav CMS, registros del sistema y las claves privadas utilizadas por el servicio onion. BleepingComputer indicó expresamente que no pudo verificar independientemente esas afirmaciones.
El episodio resulta relevante para la defensa por una razón que va más allá de la disputa entre dos actores criminales: demuestra que la infraestructura utilizada para sostener operaciones de extorsión también constituye una superficie de ataque.
La seguridad operacional del adversario puede convertirse en una fuente de exposición para el propio ecosistema criminal.
Lo que está confirmado y lo que todavía no
1 sitio Tor asociado a Clop fue modificado y mostró contenido atribuido a ShinyHunters. BleepingComputer verificó directamente el defacement.
1 archivo introducido en la infraestructura pudo ser descargado directamente desde el sitio, según la verificación realizada por BleepingComputer.
72 horas fue el plazo que ShinyHunters afirmó que entregaría a Clop para establecer contacto en el contexto de su amenaza de extorsión. Esta cifra corresponde a una declaración del actor.
La evidencia disponible permite confirmar una alteración efectiva de la infraestructura web. No permite, por sí sola, concluir que ShinyHunters haya obtenido control completo del servidor o de toda la infraestructura de Clop.
Matriz de confianza

BleepingComputer establece explícitamente esta separación: confirmó el archivo y el defacement, pero no el supuesto robo de logs, código fuente o claves privadas.
Del archivo cargado al control visible del sitio
Según BleepingComputer, el incidente comenzó durante la noche del viernes 18 de septiembre.
ShinyHunters afirmó haber encontrado una vulnerabilidad de carga de archivos sin autenticación en Grav CMS, tecnología utilizada en el sitio. El grupo habría utilizado esa condición para introducir inicialmente un pequeño archivo de texto.
BleepingComputer pudo descargar directamente ese archivo desde la infraestructura de Clop, proporcionando evidencia de que contenido no autorizado había sido introducido en el servidor. Horas después, el contenido completo del sitio fue sustituido por una página asociada a ShinyHunters.
La secuencia observada puede representarse así:

El último punto requiere una distinción fundamental.
Modificar un sitio demuestra capacidad suficiente para alterar el contenido presentado al visitante. No demuestra automáticamente acceso root, extracción de registros internos o posesión de material criptográfico.

El punto crítico: las claves del servicio onion
Una de las afirmaciones con mayores implicancias técnicas es la supuesta obtención de las claves privadas utilizadas por el servicio onion de Clop.
ShinyHunters aseguró a BleepingComputer que poseía esas claves y afirmó que podría utilizar la misma dirección onion incluso si perdiera el acceso actual a la infraestructura comprometida.
«SIN CONFIRMAR«
No existe en las fuentes revisadas evidencia pública suficiente que permita confirmar que esas claves fueron efectivamente extraídas.
La distinción importa.
Un defacement puede representar el compromiso de una aplicación, una cuenta administrativa o determinados componentes del servidor. La extracción de claves privadas implicaría una exposición distinta, con consecuencias sobre la capacidad de controlar la identidad criptográfica asociada al servicio.
Por eso, ambas condiciones no deben tratarse como equivalentes hasta disponer de evidencia adicional.
Cuando la infraestructura criminal también se convierte en superficie de ataque
La infraestructura de extorsión no funciona únicamente como un espacio de publicación.
Puede sostener comunicaciones, operaciones, registros técnicos, identidades, configuraciones, herramientas y otros elementos necesarios para mantener una campaña.
Cuando esa infraestructura es comprometida, el riesgo cambia de dirección.
El actor que normalmente utiliza información robada para ejercer presión puede convertirse en el propietario de información susceptible de ser utilizada contra él.
Ese cambio aparece explícitamente en este incidente: ShinyHunters declaró que pretende utilizar la información supuestamente obtenida para extorsionar a Clop. BleepingComputer reportó la declaración, mientras que Reuters documentó posteriormente la continuidad pública de la disputa.

Una disputa que se remonta a una campaña anterior
ShinyHunters sostiene que el conflicto está relacionado con la campaña de explotación de Oracle E-Business Suite atribuida a Clop durante 2025.
BleepingComputer informó que la disputa se habría intensificado después de aquella campaña. Reuters también recogió la versión de ShinyHunters, pero señaló que no pudo establecer de manera independiente la veracidad de su relato sobre el origen del conflicto.
Por tanto, esta motivación debe mantenerse como una afirmación del actor y no como una causalidad demostrada.
Lo que sí puede verificarse independientemente es la existencia y gravedad de CVE-2025-61882.
Oracle documentó la vulnerabilidad en E-Business Suite como explotable remotamente sin autenticación, con posibilidad de ejecución remota de código y una puntuación CVSS 3.1 de 9,8.
La existencia de esa vulnerabilidad y su explotación histórica no demuestra por sí misma las acusaciones actuales entre ambos grupos.

Grav CMS y el posible punto de entrada
ShinyHunters afirmó haber aprovechado una vulnerabilidad de carga de archivos sin autenticación en Grav CMS, tecnología utilizada en el sitio de Clop.
Según BleepingComputer, el grupo habría utilizado esta condición para introducir inicialmente un pequeño archivo de texto en el servidor.
El medio pudo comprobar posteriormente que dicho archivo estaba alojado en la infraestructura y podía descargarse directamente desde el sitio.
Grav CMS ha publicado distintos avisos de seguridad relacionados con vulnerabilidades capaces de permitir escritura de archivos, divulgación de información o ejecución de código bajo determinadas condiciones.
Hasta ahora, las fuentes disponibles no permiten determinar qué vulnerabilidad específica habría sido utilizada en este incidente.
Por esta razón, asociar una CVE concreta al compromiso sería prematuro.
El vector de acceso se mantiene como una posible explotación de una condición de carga de archivos no autenticada en Grav CMS, basada en la declaración de ShinyHunters.
Anatomía del incidente
La secuencia conocida comienza durante la noche del 18 de septiembre de 2026, cuando ShinyHunters asegura haber aprovechado una condición de seguridad en Grav CMS.
Entre el 18 y 19 de septiembre, BleepingComputer comprobó que un archivo introducido por el grupo podía descargarse directamente desde la infraestructura de Clop.
Horas después, el sitio Tor fue modificado y comenzó a mostrar contenido asociado a ShinyHunters, confirmando que los atacantes habían conseguido alterar el contenido servido por la infraestructura.
Posteriormente, ShinyHunters aseguró haber alcanzado un nivel de acceso mucho mayor, incluyendo código fuente, plugins, registros del sistema y las claves privadas utilizadas por el servicio onion. El alcance técnico de estas afirmaciones todavía no ha sido verificado independientemente.
El 19 de septiembre, ShinyHunters también declaró su intención de utilizar la información supuestamente obtenida para extorsionar a Clop y anunció un plazo de 72 horas para establecer contacto.
Para el 21 de septiembre, Reuters había documentado públicamente la disputa entre ambos grupos.
La cronología permite separar con claridad lo observado directamente de aquello que todavía depende de las declaraciones de ShinyHunters.
El compromiso y modificación del sitio están documentados. La profundidad alcanzada dentro de la infraestructura continúa siendo el principal punto por determinar.
La extorsión continúa: Clop responde y ShinyHunters eleva las exigencias
El enfrentamiento continuó después de la toma y modificación del sitio de filtraciones.
El 21 de septiembre, Clop consiguió publicar nuevamente un mensaje desde su dirección onion solicitando establecer contacto con ShinyHunters. En la comunicación, el grupo indicó que había intentado comunicarse y pidió retomar el contacto mediante una plataforma utilizada anteriormente. Hackread observó directamente esta modificación del sitio.
La respuesta de ShinyHunters mantuvo la dinámica de extorsión y rechazó establecer comunicación bajo las condiciones propuestas por Clop.
El grupo afirmó que había transcurrido otro periodo de 24 horas y anunció nuevas exigencias. Entre ellas incluyó que cualquier eventual pago fuera realizado en Bitcoin vinculado públicamente con actividades anteriores de Clop, buscando que la transacción pudiera utilizarse también como demostración pública de control sobre el grupo.
Esta escalada coincide con información publicada por The Record, que documentó que ShinyHunters había planteado una demanda económica de ocho cifras y advertido que sus exigencias aumentarían cada 24 horas mientras Clop no respondiera.
La nueva comunicación también contiene insultos, referencias a otros actores criminales y afirmaciones sobre exploits zero-day. Estos elementos forman parte del mensaje atribuido a ShinyHunters, pero no aportan evidencia técnica adicional sobre la profundidad del compromiso original.
La actualización sí permite establecer algo relevante para el seguimiento del incidente: el compromiso inicial evolucionó hacia una negociación pública de extorsión en la que ShinyHunters continúa utilizando el control alcanzado sobre la infraestructura y la exposición pública como mecanismos de presión.


Qué revela este incidente para la defensa
La relevancia del caso no se limita al enfrentamiento entre dos grupos criminales.
El punto estratégico es que la infraestructura que sostiene una operación también acumula riesgo.
Servidores web, CMS, credenciales administrativas, claves privadas, registros y herramientas internas pueden transformarse en objetivos cuando adquieren suficiente valor para un tercero.
Para una organización legítima ocurre algo similar.
Un sistema aparentemente secundario puede convertirse en una ruta hacia activos de mayor importancia si contiene credenciales, secretos, configuraciones o relaciones de confianza.
Esto significa que la prioridad defensiva no debería determinarse únicamente por la función visible de un activo.
También debería considerar una segunda pregunta:
¿Qué puede alcanzar un adversario después de comprometerlo?

Señales de exposición que una organización debería observar

Recomendaciones para usuarios
El incidente se concentra en infraestructura utilizada por actores criminales y, hasta el momento, las fuentes revisadas no documentan una afectación directa a usuarios finales derivada específicamente de este compromiso.

Aun así, la posible pérdida de control de infraestructura utilizada por grupos de extorsión puede abrir oportunidades para fraude o suplantación.

Evita interactuar con sitios de filtraciones o enlaces difundidos por actores criminales. La infraestructura puede cambiar de operador o utilizarse para distribuir contenido malicioso.

Desconfía de mensajes que utilicen este incidente para solicitar pagos, credenciales o descargas. La notoriedad del caso puede convertirse en un pretexto para fraude.

No descargues supuestas filtraciones. Además de las implicancias legales y de privacidad, los archivos pueden contener malware.

Verifica las comunicaciones relacionadas con incidentes mediante canales oficiales. No tomes decisiones basándote exclusivamente en mensajes publicados en infraestructura controlada por atacantes.

Reporta intentos de suplantación. Esto permite identificar campañas que intenten aprovechar el contexto del incidente
Recomendaciones para empresas



Reflexión CronUp
El incidente permite observar una dinámica que puede quedar oculta cuando el análisis se concentra únicamente en vulnerabilidades individuales.
Un activo adquiere valor para el adversario no solo por lo que contiene, sino también por aquello a lo que puede conducir.
La modificación visible de un sitio puede representar el alcance completo de un incidente o ser solamente la manifestación externa de un compromiso mayor. Determinar la diferencia requiere evidencia.
Ese mismo principio puede trasladarse a la superficie de ataque empresarial.
Desde la perspectiva de ATRc®, anticiparse no significa únicamente identificar vulnerabilidades. Significa reconocer condiciones de exposición, comprender las rutas que podrían construirse a partir de ellas y reducir oportunidades antes de que puedan adquirir utilidad operacional para un adversario.
El caso también deja una consideración relevante para CTI: una declaración realizada por un atacante no se convierte automáticamente en evidencia porque sea técnicamente plausible.
En este incidente está documentado que el sitio fue comprometido y modificado.
ShinyHunters asegura haber llegado considerablemente más lejos.
Determinar la profundidad real de ese acceso será lo que permita establecer el alcance definitivo del incidente.
Fuentes principales

© 2026 CronUp Ciberseguridad. Todos los derechos reservados. Este contenido está protegido por la Ley Nº 17.336. Se permite su uso informativo citando la fuente y enlazando el artículo original. Su reproducción o uso sin atribución constituye infracción.




