Entre finales de 2025 e inicios de 2026, periodo marcado por tensiones geopolíticas en el Caribe, identificamos artefactos de una campaña de borrado destructivo contra los sectores energético y de servicios públicos de Venezuela, alojados en un repositorio público desde mediados de diciembre.
La fase destructiva del ataque inicia con la ejecución de dos scripts batch, que preparan el entorno para ejecutar el payload final. Estos scripts coordinan el inicio de la operación en toda la red, desactivan mecanismos de defensas e interrumpen operaciones del sistema antes de desofuscar y ejecutar un wiper desconocido, al que hemos denominado Lotus Wiper. Este elimina los mecanismos de recuperación, sobrescribe el contenido de las unidades físicas y borra archivos de forma sistemática en los volúmenes afectados, lo que deja al sistema en un estado irrecuperable.
Esta publicación ofrece un análisis exhaustivo de cada artefacto identificado, incluidas sus capacidades, comportamiento y el impacto observado en los sistemas afectados. El análisis también incorpora observaciones contextuales relevantes para contribuir a una comprensión más completa de la situación operacional de la amenaza. Basándonos en estos hallazgos, proporcionamos recomendaciones para mejorar la cobertura de detección y la respuesta ante incidentes.
¿Es un ransomware? No, es un wiper
Como parte de nuestras labores diarias de threat hunting y análisis de malware, descubrimos un nuevo wiper de archivos subido a una plataforma pública desde una computadora en Venezuela, junto con otros artefactos asociados. Este wiper elimina datos y archivos de forma agresiva, imposibilitando su recuperación.
A diferencia del ransomware, la muestra carece de instrucciones de pago o mecanismos de extorsión, lo que descarta el lucro como motivación. Sin embargo, sí existen indicadores claros de que el malware fue utilizado en un ataque altamente dirigido hacia una empresa del sector de servicios públicos y energía. El análisis de los metadatos de la plataforma pública revela que la subida del wiper a la plataforma, coincidió con el aumento de reportes públicos de actividad maliciosa contra el mismo sector y región. Por ello, concluimos que este wiper es altamente dirigido, no tiene fines financieros y busca la destrucción total de los datos de los equipos afectados.
Los BAT de la etapa inicial
Dado que el archivo subido a la plataforma pública contenía todos los artefactos utilizados en el ataque del wiper, pudimos reconstruir su cadena de ejecución. El primer artefacto desplegado es el script OhSyncNow.bat, que inicia una cadena de acciones que culminan en la ejecución del payload final, responsable de la destrucción de datos en el sistema.
El script intenta primero utilizar C:\lotus como directorio local y si no está disponible, recurre a %SystemDrive%\lotus. Luego, intenta deshabilitar y detener el servicio Interactive Services Detection (UI0Detect), un proceso del sistema de Windows que alerta a los usuarios cuando un servicio en segundo plano, que se ejecuta en la Sesión 0, intenta mostrar una interfaz gráfica o un cuadro de diálogo interactivo. Es probable que el malware realice esta acción para prevenir la aparición de advertencias visibles que puedan exponer la actividad maliciosa.
Microsoft eliminó el servicio UI0Detect a partir de Windows 10 versión 1803 y ya no está presente en las versiones modernas de Windows. Como resultado, los intentos de deshabilitar este servicio solo serían relevantes en sistemas antiguos, lo que sugiere que el script malicioso fue diseñado para operar en entornos legacy donde el servicio aún está presente.
Luego, el script verifica la presencia del recurso compartido NETLOGON e intenta acceder a un archivo remoto (un XML utilizado como indicador o flag llamado OHSync.xml) alojado en una ruta de red del dominio. El script incluye el nombre de la organización objetivo hardcodeado en una variable para construir la ruta. Si el archivo remoto existe, el script verifica la presencia del archivo XML en el directorio local que se había definido previamente. Si el archivo local también existe, ejecuta un segundo script batch llamado notesreg.bat desde el directorio local. Lo más probable es que la verificación local solo intente determinar si el equipo es parte de un dominio de Active Directory. Si no encuentra el archivo remoto, el script se cierra. En los casos en que NETLOGON no está disponible, el script introduce un retraso aleatorio de hasta unos 20 minutos antes de volver a intentar la verificación remota.
Esta lógica funciona como un disparador basado en red, ya que la presencia del archivo XML remoto actúa como señal para iniciar la ejecución en los sistemas del dominio. Este es un enfoque típico de backdoors que dependen de recursos externos para controlar su activación.
Una vez ejecutado notesreg.bat, el script comprueba la existencia de un archivo XML que actúa como marcado de ejecución previa. Si el archivo existe, el script se autodestruye y elimina los artefactos maliciosos que forman parte de la cadena de ataque, lo que indica que está diseñado para una única ejecución.
Si el archivo de marcado de ejecución previa no existe, el script comienza con las actividades disruptivas. Primero, enumera las cuentas de usuario locales (excluyendo nombres específicos, como los del departamento de TI de la empresa víctima), les asigna una contraseña aleatoria y las desactiva.
|
1 |
net user %%a %randomPassword% /times:friday,01:00-02:00 /active:no |
A continuación, restringe el acceso al dispositivo mediante las siguientes acciones:
- Deshabilita los inicios de sesión guardados en caché (lo que impide el inicio de sesión sin conexión de red) al modificar el valor del registro CachedLogonsCount mediante el comando reg add:
1reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount /t REG_SZ /d 0 /f - Cierra las sesiones activas:
12345for /f "tokens=2,3 delims= " %%a in ('qwinsta') DO (echo %%a|findstr /xr "[1-9][0-9]* 0" >nul && (logoff %%a)) - Desactiva las interfaces de red para aislar el sistema y bloquear la comunicación externa mediante netsh:
123for /f "tokens=3*" %%a in ('netsh interface show interface') DO (netsh interface set interface "%%b" DISABLE)
A continuación, ejecuta su actividad destructiva principal:
- Enumera todas las unidades lógicas del sistema y ejecuta el comando diskpart clean all para borrar los volúmenes. La operación “clean all” sobrescribe el disco completo con ceros, eliminando todas las particiones y destruyendo la totalidad de los datos almacenados:
12345for /f "tokens=*" %%V in ('wmic logicaldisk get Caption /value ^| find "Caption="') do (for /f "tokens=2 delims==" %%D in ("%%V") do (start cmd /K "(echo select volume=%%D & echo clean all) | diskpart")) - Crea un directorio de trabajo donde copia algunos binarios de Windows (utilidades de línea de comandos) y las DLL necesarias para que se ejecute el implante final.
- Replica carpetas de forma recursiva para sobrescribir el contenido existente o eliminarlo con robocopy:
12345FOR /D %%TargetFolder IN ("%SYSTEMDRIVE%\*") DO (if /I NOT "%%TargetFolder"=="%SYSTEMDRIVE%\%MalwareFolder%" (start %SYSTEMDRIVE%\%MalwareFolder%\robocopy.exe %SYSTEMDRIVE%\%MalwareFolder%\%SourceMirrorFolder% "%%TargetFolder" /MIR /B /r:0 /w:0 >> nul 2>&1)) - Antes de avanzar a la etapa final, calcula el espacio libre disponible y crea un archivo que llena casi toda la unidad, para agotar la capacidad de almacenamiento mediante fsutil:
12345for /f "tokens=1* delims=:" %%a in ('fsutil volume diskfree %SYSTEMDRIVE%') DO (SET "FreeDiskBytes=%%b"SET "FreeDiskBytes=!FreeDiskBytes:,=!")%SYSTEMDRIVE%\%MalwareFolder%\fsutil.exe file createnew "%SYSTEMDRIVE%\DiskFillerFile" %FreeDiskBytes%
Por último, el script ejecuta un binario malicioso llamado nstats.exe, que se hace pasar por un ejecutable legítimo asociado con la plataforma HCL Domino (antes Lotus Domino) en Windows. Para la ejecución, el script pasa como argumento otros dos binarios maliciosos adicionales, nevent.exe y ndesign.exe, nombrados también como componentes de HCL Domino. Uno de los archivos contiene el payload final que será desofuscado para la obtención y ejecución de Lotus Wiper.
Esto sugiere un acceso previo del atacante, dado que los ejecutables requirieron posicionamiento anticipado en los hosts comprometidos, lo que refuerza la actividad de backdoor previamente observada.
Implante final: Lotus Wiper
El descifrado y la ejecución del wiper en el “entorno preparado” constituyen el último paso de la secuencia de infección iniciada por los archivos batch. El script, como mencionamos en la sección anterior, ejecuta el binario nstats.exe con dos argumentos: nevent.exe y ndesign.exe. El primer argumento hace referencia a un archivo con cifrado XOR; cuyo contenido será descifrado y almacenado en el segundo archivo. Por tanto, la única función de nstats.exe es obtener el wiper, previamente cifrado para evadir la detección, y ejecutarlo.
La ejecución del wiper, al que denominamos “Lotus Wiper”, es el último paso del ataque. Este habilita todos los privilegios de su token actual para acceder a funciones administrativas (aprovechando derechos elevados preexistentes), elimina los puntos de restauración y borra cada unidad física sobrescribiendo sus sectores con ceros. Después, limpia los números de secuencia de actualización (USN) de los registros de volúmenes y, por último, escanea todos los volúmenes para localizar y eliminar archivos.
Los puntos de restauración son instantáneas del sistema capturadas tras modificaciones críticas en la configuración de Windows. Estos puntos de restauración permiten que el usuario recupere el sistema si un cambio crítico lo vuelve inestable o inoperable. Para impedir que las víctimas utilicen estos puntos de restauración, Lotus Wiper invoca la API de Restauración del Sistema cargando dinámicamente la DLL srclient.dll (requisito documentado por MSDN) y obtiene las direcciones de las funciones SRSetRestorePoint y SRRemoveRestorePoint. Al llamar a SRSetRestorePoint, Lotus Wiper puede establecer un punto de restauración de tipo MODIFY_SETTINGS y obtener el número de secuencia del punto de restauración actual. Con ese número de secuencia, puede retroceder y llamar a SRRemoveRestorePoint para eliminar de forma progresiva todos los puntos de restauración del sistema.
Después de la eliminación de los puntos de restauración, el wiper examina todas las unidades físicas y, para cada una de ellas, “llena con ceros” todo su contenido. El proceso se lleva a cabo de la siguiente manera: se abre una unidad física y se envía el código IOCTL IOCTL_DISK_GET_DRIVE_GEOMETRY_EX mediante DeviceIoControl para obtener el tipo, el número de cilindros, las pistas por cilindro, los sectores por pista, los bytes por sector y el tamaño del dispositivo. El wiper utiliza esta información para escribir ceros y llenar cada uno de los sectores del disco.
El borrado forzoso de todas las unidades físicas se ejecuta al inicio y al final del wiper; tras cada ciclo de sobrescritura, el malware reitera la eliminación de los puntos de restauración. En el intento final de borrar las unidades, envía el código IOCTL IOCTL_DISK_UPDATE_PROPERTIES para que el sistema sea notificado sobre los cambios en el disco.
Entre las oleadas de borrado de unidades físicas, Lotus Wiper hace uso de FindFirstVolumeW y, de forma subsecuente, FindNextVolumeW, para obtener cada uno de los volúmenes montados y los envía a un nuevo thread que realiza dos acciones de borrado: la eliminación de todos los archivos del sistema y la limpieza del diario de cambios del volumen.
El procedimiento que se ejecuta en ese thread elimina cualquier USN relacionado con un archivo determinado, y se realiza antes y después de la eliminación de ese archivo. La eliminación (que se aplica solo a archivos, no a directorios) se lleva a cabo mediante el código IOCTL FSCTL_SET_ZERO_DATA para llenar la región del archivo con ceros. Luego, el malware renombra el archivo con un nombre hexadecimal aleatorio para ocultar el original y lo elimina mediante DeleteFileW. Si por algún motivo la eliminación no funciona (por ejemplo, el archivo está en uso), el wiper llama a MoveFileExW para mover el archivo a un destino NULL y así eliminarlo. Durante esta invocación, emplea un indicador para diferir la eliminación hasta el reinicio del sistema operativo, evadiendo así bloqueos o restricciones sobre los archivos.
Medidas de seguridad y recomendaciones
Recomendamos que las empresas y las organizaciones gubernamentales auditen los permisos y la actividad de archivos en los recursos compartidos del dominio, y vigilen NETLOGON para detectar cambios no autorizados en los archivos. Como se detalló en la cadena de ataque, es posible usar recursos compartidos como disparadores para coordinar la ejecución entre hosts.
Tanto la mayoría de las acciones disruptivas que se realizaron durante este ataque, como la ejecución en sí misma del wiper, requirieron privilegios elevados. En campañas similares, los atacantes suelen comprometer cuentas con privilegios bajos y luego elevar sus permisos para obtener el nivel de acceso necesario para realizar las actividades destructivas. Aunque la información disponible no nos permite asegurar de forma directa que el ataque del wiper haya empleado escalación de privilegios, su monitoreo sigue siendo crucial.
La extracción de credenciales o escalación de privilegios se puede detectar al buscar indicios de abuso de tokens y recolección de credenciales de los registros de seguridad.
También recomendamos monitorear el uso anómalo de herramientas nativas del sistema, en particular aquellas relacionadas con la copia masiva, destrucción de archivos y manipulación de discos. Para evadir la detección, los actores de amenaza suelen recurrir a la táctica “Living off the Land”, explotando herramientas nativas del sistema como se evidenció en este ataque. Entre ellas, podemos nombrar fsutil, robocopy y diskpart.
Por último, es importante recordar que proteger el almacenamiento y realizar pruebas para garantizar que los sistemas y datos críticos puedan restaurarse con rapidez en caso de actividad destructiva ayudará a asegurar la accesibilidad de los respaldos.
Conclusión
Los ataques con wipers figuran entre las amenazas más devastadoras, ya que su objetivo es la destrucción permanente de datos y no el robo o la extorsión. Un wiper se limita a borrar o sobrescribir datos para que los sistemas no puedan arrancar y la recuperación sea imposible, a diferencia del ransomware, que cifra los datos para exigir dinero. Ataques con wipers precedentes, como NotPetya (2017) y HermeticWiper (2022), demostraron un impacto devastador en redes corporativas y de infraestructura crítica.
Los scripts batch revelan un detalle importante sobre la presencia de los atacantes de Lotus Wiper en el entorno atacado: la existencia de funcionalidades dirigidas a versiones antiguas de Windows sugiere que los atacantes conocían el entorno y habían comprometido el dominio mucho antes del despliegue. El wiper fue compilado a finales de septiembre de 2025 y la muestra fue subida a una plataforma pública a mediados de diciembre de ese año, sin evidencia de su uso en otros ataques previos. Si el timestamp de compilación del archivo ejecutable no fue alterada, esto sugiere que el atacante pudo haberse estado preparando durante meses.
Detección por parte de Kaspersky
Los productos de Kaspersky detectan los archivos maliciosos analizados como HEUR:Trojan.BAT.Agent.gen, HEUR:Trojan.BAT.LotusWiper.gen y HEUR:Trojan.Win32.LotusWiper.gen.
Kaspersky Endpoint Detection and Response Expert detecta el comportamiento de las actividades maliciosas descritas en cada etapa. Esta sección detalla los escenarios de detección posibles.
La consulta del estado y la detención del servicio del sistema UI0Detect activan múltiples reglas en Kaspersky EDR Expert. Estas reglas también están disponibles en Threat Intelligence Portal:
- La regla system_service_discovery_via_standard_windows_utilities se activa al consultar el estado del servicio UI0Detect mediante la utilidad integrada sc.exe;
- Un intento de detener el servicio mediante los comandos sc stop “UI0Detect” y sc config “UI0Detect” start= disabled activa la regla service_stop_or_disable_via_standard_windows_utilities.
La modificación y desactivación iterativa de cuentas de usuario se correlaciona con el evento 4724 de Windows, lo que activa la regla change_password_for_built_in_user_account.
La desactivación de interfaces de red activa la regla network_interface_disable_via_netsh, diseñada para monitorear el bloqueo de conectividad mediante la utilidad netsh.exe:
El respaldo de utilidades del sistema, como cmd.exe, en la carpeta del malware activa múltiples reglas.
- La regla drop_interpreter_to_unusual_location si se crean intérpretes de línea de comandos en rutas atípicas, donde su presencia no es habitual. En nuestro caso, se trata de C:\lotus\cmd.exe;
- La regla create_file_named_like_system_tool_in_wrong_place opera con un principio similar, pero monitorea un conjunto más amplio de programas.
El flujo de ejecución dinámica de las muestras de Lotus Wiper se puede obtener en Kaspersky Threat Intelligence Portal mediante la herramienta Threat Analysis:
Esta herramienta genera una representación gráfica del comportamiento de la muestra, basándose en un conjunto específico de reglas, integrado en las soluciones de sandbox de Kaspersky. La descripción de estas reglas estará disponible en Threat Intelligence Portal en el cuarto trimestre de 2026.
IoC de referencia
La información adicional sobre Lotus Wiper, incluidos los indicadores de compromiso, se encuentra disponible para los clientes del servicio Kaspersky Intelligence Reporting. Si tiene interés, póngase en contacto con crimewareintel@kaspersky.com.
0b83ce69d16f5ecd00f4642deb3c5895
c6d0f67db6a7dbf1f9394d98c1e13670
b41d0cd22d5b3e3bdb795f81421a11cb










Lotus Wiper: una nueva amenaza para el sector energético y de servicios públicos