El ciberataque que podría envenenar el suministro de agua de una ciudad manipulando los niveles de cloro

A mediados de abril de 2026, investigadores de Darktrace publicaron un análisis detallado de una muestra de malware que ocupa un nicho estrecho pero alarmante en el panorama de amenazas: un arma OT basada en Windows, aparentemente diseñada desde cero para sabotear la infraestructura israelí de tratamiento de agua y desalinización. El malware se identifica internamente como ZionSiphon — el nombre aparece en una función central llamada directamente desde la ruta de ejecución principal — y el hash SHA-256 de la muestra fue enviado a VirusTotal para visibilidad comunitaria.

A diferencia del ransomware de uso genérico o los infostealers que ocasionalmente se infiltran en redes industriales, ZionSiphon fue arquitectado con conocimiento específico de ingeniería de desalinización, geografía del sector hídrico israelí y protocolos de sistemas de control industrial. Su código demuestra familiaridad con las convenciones de nomenclatura del software de plantas de ósmosis inversa, el encuadre de Modbus TCP y las consecuencias físicas de manipular registros de dosificación de cloro. Este no es el trabajo de oportunistas que tropezaron con un entorno OT. Refleja una investigación deliberada sobre el dominio objetivo.

Lo que impidió que activara su carga útil al ser descubierto es un error lógico en la función de validación de país — una rutina XOR rota donde el desarrollador codificó una cadena de comparación con un método e intentó verificarla en tiempo de ejecución con uno incompatible. El resultado: el malware concluye consistentemente que no está ejecutándose en Israel e inicia la autoeliminación. Todos los demás mecanismos — persistencia, escalada de privilegios, manipulación de archivos de configuración, escritura en registros Modbus, propagación por USB — operan según lo previsto.

Nota del Analista — Darktrace / Calum Hall

“La estructura general del código probablemente indica un actor de amenaza experimentando con la manipulación OT de múltiples protocolos, persistencia dentro de redes operacionales y técnicas de propagación por medios removibles que recuerdan a campañas anteriores dirigidas a ICS. Incluso en su estado incompleto, ZionSiphon subraya una tendencia creciente en la que los actores de amenaza están experimentando cada vez más con malware orientado a OT y aplicándolo al targeting de infraestructura crítica.”

Identidad del Actor de Amenaza y Encuadre Ideológico

Antes de examinar los mecanismos técnicos, es esencial comprender el contexto político codificado directamente en el binario, porque moldea cada decisión de diseño que tomó el autor. El malware incorpora dos cadenas codificadas en Base64 que no tienen ninguna función operacional — son firmas ideológicas, el equivalente digital de pintar un manifiesto en una pared. El actor se identifica usando el alias 0xICS — una construcción deliberada que toma prestado el prefijo hexadecimal común en las comunidades de programación e ingeniería inversa, combinado con el acrónimo de Sistemas de Control Industrial. Esto sugiere un desarrollador consciente de su identidad técnica dentro del espacio de seguridad ICS.

La primera cadena se almacena bajo una variable llamada Netanyahu y su valor en Base64, SW4gc3VwcG9ydCBvZiBvdXIgYnJvdGhlcnMgaW4gSXJhbiwgUGFsZXN0aW5lLCBhbmQgWWVtZW4gYWdhaW5zdCBaaW9uaXN0IGFnZ3Jlc3Npb24uIEkgYW0gIjB4SUNTIi4=, se decodifica de forma inequívoca como una declaración de solidaridad con Irán, Palestina y Yemen enmarcada contra lo que el autor denomina agresión sionista.

La segunda cadena se almacena bajo la variable Dimona — una referencia a la ciudad israelí en el desierto del Néguev que alberga el Centro de Investigación Nuclear Shimon Peres del Néguev, el supuesto sitio de armas nucleares de Israel. La elección de este nombre como etiqueta de variable es en sí misma una señal geopolítica. Su valor en Base64, UG9pc29uaW5nIHRoZSBwb3B1bGF0aW9uIG9mIFRlbCBBdml2IGFuZCBIYWlmYQo=, se decodifica como una amenaza contra la población civil de Tel Aviv y Haifa — las dos áreas metropolitanas más grandes de Israel.

Los investigadores de Darktrace señalan que estas cadenas no realizan ninguna función en tiempo de ejecución. No se pasan a ninguna ruta de ejecución, no se usan en comparaciones y no influyen en el flujo del programa. Su presencia es puramente declarativa — el autor quería que fueran visibles para cualquiera que realizara ingeniería inversa del binario. Este comportamiento es consistente con actores adyacentes al hacktivismo que mezclan el desarrollo de capacidades operacionales con mensajes políticos públicos, un patrón que se ha observado repetidamente en el ecosistema de amenazas alineado con Irán durante los últimos años.

El contexto geopolítico más amplio refuerza esta lectura. En el mismo mes en que se analizó ZionSiphon, se documentó una campaña de rociado de contraseñas con nexo iraní dirigida a inquilinos de Microsoft 365 en los Emiratos Árabes Unidos e Israel, y el actor de amenaza iraní rastreado como MuddyWater fue observado realizando intrusiones en redes de Israel, Estados Unidos y Canadá. En marzo de 2026, una campaña separada distribuyó una versión troyanizada de la aplicación de notificación de emergencias RedAlert de Israel mediante suplantación de SMS, robando contactos y datos GPS de las víctimas. ZionSiphon se inscribe en un patrón demostrablemente activo de operaciones cibernéticas alineadas con Irán dirigidas contra infraestructura civil israelí, aunque Darktrace no ha realizado una afirmación formal de atribución estatal, y este análisis tampoco lo hace.

Arquitectura de Targeting Geográfico y Sectorial

ZionSiphon implementa el targeting en dos capas distintas, cada una funcionando como una compuerta que debe superarse antes de que se ejecute cualquier acción destructiva. La primera capa es geográfica, implementada mediante rangos de direcciones IP israelíes codificados de forma fija. La segunda capa es ambiental, implementada mediante inspección de nombres de procesos y detección de artefactos del sistema de archivos. Solo cuando ambas capas devuelven una coincidencia positiva el malware procede a la ejecución de la carga útil. Este diseño de doble compuerta refleja la conciencia de que simplemente aterrizar dentro de un rango de IP israelí es insuficiente — el atacante quería específicamente golpear infraestructura hídrica operacional, no sistemas de TI genéricos.

Capa Uno: Geofencing de IP Mediante Bloques CIDR Codificados

El inicializador de clase del malware llena una estructura de datos ipRanges con tres rangos IPv4, cada uno ofuscado mediante codificación Base64 para evitar coincidencia de patrones trivial:

// Decodificado de Base64 en el constructor estático
ipRanges[0] = "2.52.0.0 - 2.55.255.255"      // HOT TELECOM / asignaciones de ISP israelí
ipRanges[1] = "79.176.0.0 - 79.191.255.255"   // asignaciones de Bezeq International
ipRanges[2] = "212.150.0.0 - 212.150.255.255" // asignaciones de ISP israelí

Los tres bloques están asignados por la IANA a operadores de red israelíes. La función IsTargetCountry() convierte la dirección IPv4 local del host en un entero sin signo de 32 bits y realiza una comparación de rango numérico contra cada entrada. Si la IP del host cae dentro de cualquiera de los tres rangos, la compuerta geográfica teóricamente pasaría. La conversión de IP a entero es una técnica estándar — una dirección como 79.180.0.1 se convierte en 1336934401, que luego se compara aritméticamente con las representaciones enteras de los límites del rango. Esto evita la sobrecarga del análisis de cadenas y es computacionalmente eficiente para el bucle de comparación.

La decisión de codificar múltiples rangos de ISP separados en lugar de un CIDR amplio único como 2.0.0.0/8 indica conocimiento específico de la topología de internet israelí. El autor apuntó a bloques asociados con ISPs israelíes en lugar de aplicar una red de nivel de país imprecisa, que habría incluido tráfico no israelí y aumentado el riesgo de ejecución no intencionada.

Capa Dos: Fingerprinting del Entorno OT

La función IsDamDesalinationPlant() realiza la segunda capa de verificaciones de targeting utilizando dos enfoques paralelos: enumeración de procesos en vivo e inspección estática del sistema de archivos. La verificación de la lista de procesos itera a través de todos los procesos en ejecución en el host y compara sus nombres con diecinueve cadenas codificadas de forma fija. La especificidad de estas cadenas es notable — no son términos industriales genéricos sino que reflejan conocimiento de cómo los proveedores de software de tratamiento de agua nombran realmente sus componentes ejecutables:

// Nombres de procesos objetivo (selección de la lista completa)
"DesalPLC"       // Software de gestión de PLC de desalinización
"ROController"   // Interfaz del controlador de Ósmosis Inversa
"SchneiderRO"    // Gestión de OI de Schneider Electric
"ChlorineCtrl"   // Proceso de control de dosificación de cloro
"WaterPLC"       // HMI de PLC genérico de tratamiento de agua
"OsmosisPLC"     // Interfaz de PLC de proceso de ósmosis
"BrineControl"   // Gestión de descarga de salmuera
"SalinityCtrl"   // Monitoreo y control de salinidad

Las verificaciones del sistema de archivos refuerzan esto, escaneando en busca de directorios bajo C:\Program Files\ específicos de IDE Technologies — la empresa israelí que construyó las plantas desaladoras de Sorek y Ashdod — junto con la suite de gestión de desalinización de Schneider Electric. Los archivos de configuración objetivo incluyen C:\DesalConfig.ini, C:\ROConfig.ini, C:\ChlorineControl.dat y C:\SalinityControl.ini. La presencia de IDE Technologies en la lista de directorios es particularmente significativa: IDE Technologies es una subsidiaria del Grupo Delek y es directamente responsable de operar varias de las plantas desaladoras nombradas en las cadenas de targeting del malware. La inclusión de su ruta de software sugiere que el autor tenía conocimiento específico de la planta, no simplemente conciencia genérica de OT.

La lista de cadenas objetivo incrustada en el binario del malware mapea directamente a la infraestructura hídrica real de Israel. Mekorot es la empresa nacional de agua de propiedad estatal que posee y opera la red de distribución del país. Sorek (en Rishon LeZion), Hadera, Ashdod y Palmachim son cuatro de las cinco principales plantas de desalinización de agua de mar por ósmosis inversa de Israel, que en conjunto producen cientos de millones de metros cúbicos de agua potable anualmente y suministran una fracción sustancial del agua potable del país. Shafdan, ubicada cerca de Rishon LeZion, es la instalación central de recuperación de aguas residuales de Israel, que trata los efluentes del área metropolitana de Tel Aviv para reuso agrícola. Un atacante que interrumpa los sistemas de cloración de Shafdan afectaría tanto la seguridad de la descarga de aguas residuales como el suministro de agua recuperada para la agricultura. La inclusión de estos sitios específicos por parte del autor demuestra reconocimiento de la arquitectura hídrica nacional, no targeting genérico.

Cadena de Ejecución: Desde el Lanzamiento hasta la Compuerta de Carga Útil

Escalada de Privilegios Mediante Evasión de UAC con PowerShell

En la primera ejecución, el malware llama inmediatamente a RunAsAdmin(), que a su vez invoca IsElevated() — una función que recupera la identidad principal de Windows actual y consulta su membresía en el grupo local de Administradores usando las clases .NET WindowsIdentity y WindowsPrincipal. Si el proceso ya está elevado, la ejecución continúa normalmente. Si no, el malware entra en una breve espera en un mutex nombrado (para evitar instancias de ejecución concurrentes), luego lanza una nueva instancia de sí mismo a través de PowerShell:

powershell.exe Start-Process -FilePath <ruta_del_ejecutable_actual> -Verb RunAs

El parámetro -Verb RunAs activa un diálogo de elevación UAC de Windows que pide al usuario que apruebe el acceso de administrador. Esto no es una evasión de UAC en el verdadero sentido técnico — no explota una vulnerabilidad para elevar silenciosamente — sino que usa un mecanismo legítimo del sistema operativo para solicitar elevación de forma interactiva. El proceso original luego espera a que el proceso hijo elevado se complete antes de salir. Este enfoque es confiable en Windows 10 y 11 sin activar heurísticas antivirus, ya que PowerShell invocando un proceso con RunAs es un flujo de trabajo administrativo común. La contrapartida es que requiere que el usuario haga clic en un aviso de UAC, lo que limita el sigilo en sistemas con cuentas de usuario estándar que no tienen derechos administrativos en absoluto.

Persistencia: Clave de Registro Run con Suplantación de Nombre de Proceso

Con los derechos administrativos confirmados, se ejecuta la rutina de persistencia s1(). Esta función construye un stealthPath combinando la ruta de la variable de entorno LocalApplicationData con el nombre de archivo codificado svchost.exe, resultando en una ruta como C:\Users\[nombre_de_usuario]\AppData\Local\svchost.exe. La elección de svchost.exe como nombre de archivo es un camuflaje deliberado — el proceso Windows Service Host, que genuinamente se ejecuta como múltiples instancias simultáneamente en cada instalación estándar de Windows, es uno de los nombres de proceso más comúnmente ignorados durante el triaje casual.

La rutina luego verifica si el binario en ejecución actual ya se encuentra en la ruta de sigilo. Si no, se copia allí y establece los atributos del archivo a Hidden (Oculto) usando el método .NET File.SetAttributes() con la bandera FileAttributes.Hidden. Los archivos ocultos son invisibles en el Explorador de Windows con la configuración predeterminada y en muchos listados de directorios básicos. La clave de persistencia se escribe entonces:

// Entrada de persistencia en el registro
Clave:   HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Valor:  "SystemHealthCheck"
Datos:  "C:\Users\[usuario]\AppData\Local\svchost.exe"

HKCU\...\Run (registro del usuario actual) es significativo porque no requiere privilegios SYSTEM o elevados para escribir — un usuario estándar puede establecer sus propias claves Run. Esto significa que el mecanismo de persistencia funciona incluso si el paso de UAC está parcialmente restringido. El nombre de valor SystemHealthCheck se elige para mezclarse con nombres de software de monitoreo legítimo visibles en la clave Run de máquinas empresariales típicas. La combinación de un nombre de autoarranque plausible, atributo de archivo oculto y un nombre de archivo compartido con un proceso central de Windows representa una pila de sigilo de tres capas que evitaría una inspección casual.

Lógica de Validación del Objetivo y Su Falla Fatal

Después de establecer la persistencia, el malware ejecuta su secuencia de verificación de compuertas. La función de validación principal llama tanto a IsTargetCountry() como a IsDamDesalinationPlant(). IsTargetCountry() realiza la comparación de rangos de IP descrita anteriormente, pero luego hace una comparación de cadenas secundaria que es donde la lógica colapsa por completo.

En el constructor estático, cada entrada de ipRanges está asociada con una cadena complementaria decodificada "Nqvbdk", derivada del valor Base64 "TnF2YmRr". En tiempo de ejecución, IsTargetCountry() compara esta cadena almacenada con el resultado en tiempo de ejecución de llamar a EncryptDecrypt("Israel", 5). La función EncryptDecrypt es un cifrado XOR simple — itera a través de cada carácter de la cadena de entrada y hace XOR de su valor ASCII con la clave entera, luego convierte el resultado de vuelta a un carácter:

función EncryptDecrypt(texto: cadena, clave: entero) → cadena:
    resultado = []
    para ch en texto:
        resultado.append(char(ord(ch) XOR clave))
    retornar resultado.unir()

// Aplicando la función: EncryptDecrypt("Israel", 5)
// I(73) XOR 5 = 76  → 'L'
// s(115) XOR 5 = 118 → 'v'
// r(114) XOR 5 = 119 → 'w'
// a(97)  XOR 5 = 100 → 'd'
// e(101) XOR 5 = 100 → 'd'
// l(108) XOR 5 = 105 → 'i'
// Resultado: "Lvwddi"  ← NO es "Nqvbdk"

Como establece el análisis de Darktrace, ningún valor de clave XOR transformará "Israel" en "Nqvbdk". Las dos cadenas se derivan de operaciones de codificación diferentes que son mutuamente incompatibles. Analíticamente, esto sugiere uno de tres escenarios: el desarrollador generó "Nqvbdk" usando un cifrado diferente o una pasada de codificación distinta y luego reemplazó la función de codificación con la rutina XOR sin recalcular el valor de comparación almacenado; o se pretendía una versión diferente de la cadena — quizás no "Israel" sino una variante con ortografía o capitalización distintas — como entrada; o el desajuste es intencional, desplegado como una versión de prueba con el interruptor de apagado dejado activado. Los investigadores de Darktrace dejan abierta esta pregunta, señalando que el comportamiento es consistente tanto con una compilación de desarrollo como con una muestra desplegada prematuramente.

La consecuencia es absoluta: IsTargetCountry() siempre devuelve falso. El malware nunca alcanza su carga útil. En cambio, llama inmediatamente a SelfDestruct().

Autodestrucción: Antiforensics Mediante Eliminación en Cascada

La función SelfDestruct() implementa una secuencia de eliminación de evidencias en múltiples pasos. Primero, elimina el valor SystemHealthCheck de la clave de registro Run, eliminando el artefacto de persistencia. Segundo, escribe una entrada de registro en %TEMP%\target_verify.log que contiene la cadena “Target not matched. Operation restricted to IL ranges. Self-destruct initiated.” — notablemente, el propio archivo de registro se convierte en un indicador de compromiso para analistas forenses, ya que deja evidencia del intento de ejecución del malware y su lógica de targeting incluso mientras el binario se borra a sí mismo. Tercero, crea %TEMP%\delete.bat, un script por lotes que hace bucle con lógica de reintento para eliminar el ejecutable del malware (manejando el tiempo de bloqueo de archivos), y luego se elimina a sí mismo:

:reintento
del /F /Q "C:\Users\[usuario]\AppData\Local\svchost.exe"
if exist "C:\Users\[usuario]\AppData\Local\svchost.exe" goto reintento
del /F /Q "%~f0"   ; elimina delete.bat a sí mismo

El bucle de reintento es necesario porque los handles de archivos de Windows pueden impedir la eliminación inmediata de un ejecutable en ejecución o cerrado recientemente. Este patrón de autodestrucción es sofisticado en relación con el resto del malware — el desarrollador claramente pensó en el residuo forense y construyó una mitigación en la ruta de ejecución predeterminada.

La Carga Útil de Sabotaje: Envenenamiento de Archivos de Configuración y Manipulación de Registros Modbus

Fase Uno — Manipulación de Archivos de Configuración

Si la verificación de país alguna vez pasa (como lo haría en una compilación corregida), la primera acción del malware no es basada en red — es modificación directa y local del sistema de archivos a través de IncreaseChlorineLevel(). Esta función itera a través de la misma lista de archivos de configuración OT identificados durante la fase de fingerprinting del entorno. En el momento en que encuentra cualquiera de los archivos objetivo presentes, agrega el siguiente bloque de texto fijo e inmediatamente retorna sin procesar los archivos restantes en la lista:

; Bloque agregado al primer archivo de configuración OT encontrado
Chlorine_Dose=10
Chlorine_Pump=ON
Chlorine_Flow=MAX
Chlorine_Valve=OPEN
RO_Pressure=80

Las implicaciones físicas de estos valores requieren explicación. En el tratamiento de agua, el cloro se dosifica en concentraciones cuidadosamente calibradas en partes por millón — típicamente entre 0.2 y 4 mg/L en agua potable tratada. Una entrada Chlorine_Dose=10 que establece la dosificación de cloro al máximo, combinada con Chlorine_Flow=MAX y Chlorine_Valve=OPEN, instruiría a las bombas dosificadoras a inyectar cloro a su tasa máxima física. La concentración resultante en el agua que llega a los consumidores podría alcanzar niveles que superan ampliamente las directrices de la OMS de 5 mg/L para exposición aguda, causando potencialmente irritación de las membranas mucosas, dificultad respiratoria y, en concentraciones suficientemente altas, quemaduras químicas en el tracto gastrointestinal. La entrada RO_Pressure=80 apunta a la presión de las membranas de ósmosis inversa. Los sistemas típicos de OI de agua de mar operan a 55–70 bar; establecer la presión a un valor artificialmente alto arriesga la ruptura de membranas, fallas en tuberías y daños en los conjuntos de bombas de alta presión que se encuentran entre los componentes más costosos de una planta desaladora.

Si estos valores de configuración realmente serían leídos y actuados por el software de control de la planta depende de factores específicos de implementación — si los archivos .ini y .dat objetivo son sondeados activamente en tiempo de ejecución, si representan configuraciones de referencia de solo lectura o parámetros de control en vivo, y si la capa SCADA/DCS de la planta valida los rangos de entrada. El enfoque del malware asume una relación directa entre los valores de configuración del sistema de archivos y los comandos del actuador físico, que puede o no mantenerse en la arquitectura específica de cualquier planta. Esta es una advertencia importante: el potencial de daño es real pero no está garantizado solo por la escritura del archivo.

Implicación Estratégica: El Aislamiento de Red No Proporciona Defensa Contra la Fase Uno

Esta secuenciación de ataque tiene una consecuencia arquitectónica crítica que la mayoría de los defensores de ICS pasan por alto. La ruta de sabotaje principal de ZionSiphon — envenenamiento de archivos de configuración — requiere cero conectividad de red a dispositivos OT. Opera completamente dentro del sistema de archivos local de la estación de trabajo de ingeniería o el host HMI en el que aterriza. Esto significa que una planta cuya red Modbus/DNP3/S7 está completamente protegida por firewall, con air gap o segmentada, sigue siendo vulnerable a la Fase Uno si ZionSiphon llega a cualquier host Windows que ejecute software de gestión de desalinización. El ataque de red Modbus en la Fase Dos es el respaldo, no el arma principal. Un atacante que entregue exitosamente ZionSiphon a través de USB a una estación de trabajo HMI independiente sin acceso de red al piso de la planta todavía podría causar interrupción del proceso físico a través de la inyección de archivos de configuración solo — sin enviar nunca un solo paquete a un PLC.

Fase Dos — Manipulación de Registros Modbus TCP

Si no se encuentran archivos de configuración objetivo en el sistema de archivos local, el malware escala al descubrimiento y ataque de dispositivos OT basados en red a través de la función UZJctUZJctUZJct() — un nombre deliberadamente ofuscado que no proporciona ninguna pista semántica a los analistas o defensores que escanean listas de procesos o registros. Esta función deriva la subred local /24 de la IP del host, luego lanza un barrido de conexión TCP paralelo a través de las 255 direcciones de host, sondeando tres puertos de protocolo industrial simultáneamente:

Protocolo	Puerto	Firma de Validación	Código de Función Objetivo
Modbus TCP	502	byte[0] de respuesta en rango 1–255	FC03 Lectura, FC06 Escritura de Registro Único
DNP3	20000	Bytes[0,1] == 05 64	Solo marcador de posición incompleto
S7comm (Siemens)	102	Byte[0] == 03	WriteVar (0x05) — incompleto

El tiempo de espera de conexión es de 100 milisegundos por intento. Debido a que todos los sondeos se lanzan concurrentemente a través de tareas paralelas, el tiempo total de barrido en una red /24 es aproximadamente 100–300 ms en la práctica — lo suficientemente rápido para completarse antes de que la mayoría de las herramientas de monitoreo de red marquen el comportamiento sistemático como un escaneo. Cada dispositivo que responde se registra como un objeto ICSDevice que almacena su IP, puerto y etiqueta de protocolo.

Para Modbus — la ruta de ataque más desarrollada — la validación de segunda etapa envía un único byte nulo al puerto abierto y lee la respuesta. Un dispositivo Modbus válido que devuelva cualquier primer byte distinto de cero es registrado. El malware luego emite una solicitud de Lectura de Registros de Retención, la operación Modbus más común en entornos de tratamiento de agua:

; Trama de solicitud Modbus TCP Read Holding Registers
01     ; ID de unidad (dirección esclavo — frecuentemente ignorada en TCP)
03     ; Código de función: Read Holding Registers
00 00 ; Dirección de inicio: registro 0
00 0A ; Cantidad: 10 registros

El malware luego lee los diez valores de registro de 16 bits devueltos en la respuesta, analizándolos en pares. Para cada registro, aplica una heurística para determinar la relevancia: para un registro de dosis de cloro, busca valores entre 1 y 999 (rango de unidad de ingeniería razonable para un punto de ajuste de dosificación); para un registro de velocidad de turbina, busca valores superiores a 100. Cuando se encuentra un registro plausible, el malware construye un comando de Escritura de Registro Único (Código de Función Modbus 6) dirigido a ese registro:

; Modbus FC06 Write Single Register — ataque Chlorine_Dose
01     ; ID de unidad
06     ; Código de función: Write Single Register
XX XX ; Dirección de registro (identificada dinámicamente)
00 64 ; Valor: 100 decimal para Chlorine_Dose
00 00 ; Valor: 0 para todos los demás parámetros

El valor de 100 escrito en el registro de dosis de cloro es un valor de unidad de ingeniería — su consecuencia en el mundo real depende completamente del factor de escala definido en el programa del PLC. En muchos PLCs de tratamiento de agua, un valor de registro de 100 en un contexto de dosificación podría representar el 100% de la salida máxima de la bomba o un objetivo de concentración de 100 mg/L — ambos catastróficos en relación con los estándares de agua potable segura. El comportamiento de respaldo es igualmente preocupante: si ningún registro cumple los criterios heurísticos después de analizar los diez, el malware no abandona el ataque. En cambio, envía un conjunto de tramas de escritura Modbus codificadas de forma fija con direcciones de registro predeterminadas y valores, esencialmente intentando una escritura ciega a cualquier dirección que el desarrollador consideró más probable para afectar las operaciones de la planta. Este respaldo refleja conocimiento parcial del entorno objetivo combinado con la determinación de causar daño independientemente de los resultados del descubrimiento dinámico.

DNP3 y S7comm: Precisos en el Protocolo pero No Funcionales

La rama DNP3 devuelve la secuencia de bytes 05 64 0A 0C 01 02. Los primeros dos bytes, 0x05 0x64, son efectivamente el encabezado de sincronización de capa de enlace DNP3 correcto que precede a cada trama DNP3 válida. Los bytes subsiguientes tienen la forma general correcta de los primeros campos del encabezado de capa de enlace, pero la secuencia es críticamente incompleta: una trama DNP3 válida requiere dirección de destino (2 bytes), dirección de origen (2 bytes), byte de control de capa de enlace, bloques CRC (2 bytes cada uno) y una carga útil de capa de aplicación que contenga el código de función real y los datos del objeto. La secuencia de seis bytes proporcionada por ZionSiphon es insuficiente para formar cualquier solicitud de aplicación DNP3 válida y sería rechazada o ignorada por una pila de dispositivo DNP3 real.

La rama S7comm devuelve 05 00 1C 22 1E. El primer byte 0x05 corresponde al código de función WriteVar en el formato de bloque de parámetros S7 de Siemens — el equivalente S7 de una escritura de registro Modbus. Sin embargo, los bytes restantes no forman una definición de elemento válida. Un bloque de parámetros S7 WriteVar adecuado requiere como mínimo un elemento con una estructura de especificación de variable completa de 11 bytes que defina el tamaño de transporte, la longitud de datos, el número de base de datos, el código de área y la dirección de bit. El fragmento de cinco bytes tiene menos de la mitad del tamaño mínimo requerido y resultaría malformado para cualquier dispositivo S7. La evaluación de Darktrace es que estos fragmentos contienen prefijos precisos del protocolo — lo que sugiere que el autor entendía cómo se ve una iniciación S7 WriteVar adecuada — pero o bien todavía investigaba la estructura completa del marco o se quedó sin tiempo antes de completar la implementación. Ambas ramas están arquitectónicamente enmarcadas de manera idéntica a la ruta Modbus; simplemente carecen de la carga útil funcional.

“Ambas contienen prefijos precisos del protocolo, lo que indica la intención de implementar capacidades OT de múltiples protocolos — sin embargo, por razones desconocidas, estas secciones no fueron completamente implementadas o no pudieron completarse antes del despliegue.” — Calum Hall, Investigador de Contenido Técnico, Darktrace

Propagación por USB: El Puente del Air Gap

Los mecanismos de persistencia y escaneo OT abordan redes ya accesibles a través de TCP/IP. Pero los objetivos operacionalmente más significativos en el sector hídrico — las estaciones de trabajo de ingeniería directamente conectadas a PLCs y servidores SCADA en Sorek, Shafdan o Ashdod — casi con certeza están aisladas con air gap o al menos segmentadas detrás de firewalls que bloquean el acceso directo a internet. ZionSiphon aborda esto a través de un mecanismo de propagación por medios removibles que refleja directamente la técnica que hizo de Stuxnet el ciberarma definitoria de la era ICS.

La función de propagación por USB, llamada sdfsdfsfsdfsdfqw() — un nombre deliberadamente sin sentido que sugiere ya sea ofuscación anti-análisis o que el desarrollador lo trató como código desechable — enumera todas las unidades montadas usando DriveInfo.GetDrives() de .NET y filtra aquellas con DriveType.Removable. Para cada unidad removible encontrada, verifica la presencia de su propia copia usando el nombre de archivo svchost.exe. Si el archivo no está presente, copia la carga útil a la raíz de la unidad y establece tanto los atributos de archivo Hidden como System. El atributo System, además de Hidden, significa que el archivo es invisible para los comandos dir sin las banderas /A:SH y requiere enumeración explícita con conciencia de atributos para ser detectado.

El mecanismo de creación de accesos directos, CreateUSBShortcut(), luego itera a través de todos los archivos visibles en la raíz de la unidad removible — documentos, imágenes u otros datos del usuario — y para cada uno crea un archivo Windows Shell Link (.lnk). La propiedad TargetPath del archivo LNK se establece para apuntar a la carga útil oculta svchost.exe, mientras que IconLocation se establece en shell32.dll, 4 — el icono de documento genérico estándar de Windows que aparecería indistinguible de un acceso directo a documento real. El archivo original luego se oculta. El resultado: un usuario que navega la unidad USB en el Explorador de Windows ve lo que parecen ser sus archivos originales (ahora son accesos directos LNK visualmente idénticos a los originales). Al hacer clic en cualquiera de ellos se ejecuta silenciosamente la carga útil del malware a través de WScript.Shell antes de abrir opcionalmente el archivo objetivo original para evitar sospechas.

; Construcción de acceso directo WScript.Shell (pseudocódigo)
Set oShell = CreateObject("WScript.Shell")
Set oShortcut = oShell.CreateShortcut(unidad + "\\" + nombre_archivo + ".lnk")
oShortcut.TargetPath    = unidad + "\\" + "svchost.exe"   ; carga útil oculta
oShortcut.IconLocation  = "shell32.dll, 4"                ; icono de archivo genérico
oShortcut.Save()
SetAttributes(archivoOriginal, Hidden)

Esta técnica está clasificada bajo MITRE ATT&CK como T1091 — Replicación a Través de Medios Removibles. Es el mismo mecanismo fundamental utilizado por el exploit LNK de Stuxnet (CVE-2010-2568), que se propagó desde memorias USB infectadas a sistemas Siemens S7-300 con air gap en la instalación de enriquecimiento de uranio de Natanz en Irán. La implementación de ZionSiphon no explota una vulnerabilidad de Windows para la ejecución del LNK — depende de la interacción del usuario — pero la lógica estratégica es idéntica: asumir que el objetivo OT de alto valor está aislado de la red y usar medios físicos como vector de infección para el salto final.

La importancia de esta elección de diseño no puede subestimarse en el contexto de la infraestructura hídrica. Las estaciones de trabajo de ingeniería en las plantas desaladoras israelíes — los sistemas exactos que el fingerprinting de entorno de ZionSiphon está diseñado para detectar — casi con certeza no son accesibles a través de internet. Los operadores en instalaciones como Sorek o Shafdan utilizan rutinariamente memorias USB para transferir actualizaciones de software, respaldos de configuración y parches de proveedores entre sus redes de TI y el piso de planta aislado de OT. ZionSiphon está arquitectado para explotar precisamente esta práctica. Una sola memoria USB infectada, entregada a un técnico en la oficina de un contratista o llevada desde una máquina administrativa conectada a internet a una estación de trabajo OT, tiende un puente sobre el air gap por completo. Una vez en el host del lado OT, tanto los ataques de envenenamiento de configuración de Fase Uno como los ataques Modbus de Fase Dos quedan disponibles sin ningún requisito adicional de acceso de red.

Matriz de Capacidades: Qué Funciona, Qué No, y Qué Está a Una Corrección de Distancia

Capacidad	Función / Mecanismo	Estado	Notas
Escalada de privilegios	RunAsAdmin() / PowerShell RunAs	Funcional	Requiere aviso UAC; sin evasión silenciosa
Persistencia vía registro	s1() / clave HKCU Run	Funcional	svchost.exe oculto; sobrevive al reinicio
Fingerprinting de entorno OT	IsDamDesalinationPlant()	Funcional	19 nombres de proceso, 15+ rutas del sistema de archivos
Validación de país	IsTargetCountry() / comparación XOR	Rota	Desajuste XOR; siempre devuelve falso
Autodestrucción / antiforensics	SelfDestruct() / delete.bat	Funcional	Elimina clave de registro, borra el binario
Envenenamiento de config. de cloro	IncreaseChlorineLevel() (local)	Funcional (si se activa)	Agrega Chlorine_Dose=10, RO_Pressure=80
Escaneo de subred OT	UZJctUZJctUZJct()	Funcional	Barrido paralelo /24; tiempo de espera 100ms
Lectura/escritura de registros Modbus	FC03 + FC06; dinámico + respaldo	Mayormente Funcional	Heurística de descubrimiento de registros + respaldo codificado
Ejecución de comandos DNP3	Rama DNP3 de GetCommand()	Incompleto	Solo prefijo de encabezado de capa de enlace; sin trama válida
Ejecución de comandos S7comm	Rama S7 de GetCommand()	Incompleto	Stub WriteVar de 5 bytes; demasiado corto para ser válido
Propagación por USB	sdfsdfsfsdfsdfqw() + CreateUSBShortcut()	Funcional	svchost.exe oculto + engaño LNK en unidades removibles

Precedente Histórico y Contexto del Panorama de Amenazas

ZionSiphon no existe de forma aislada. La infraestructura hídrica ha sido un objetivo recurrente en la dimensión cibernética del conflicto árabe-israelí y en las operaciones vinculadas a Irán en general. En febrero de 2020, la Dirección Nacional Cibernética de Israel emitió una alerta sobre intentos de intrusión en instalaciones de tratamiento de agua; en abril de 2020, atacantes — atribuidos por varios servicios de inteligencia occidentales a Irán — comprometieron sistemas SCADA en plantas de tratamiento de agua israelíes e intentaron alterar los niveles de dosificación de cloro. El ataque fue reportado como detectado antes de que se produjera cualquier impacto en el suministro de agua. En ese incidente, el método involucró acceso remoto a sistemas HMI accesibles a través de internet sin autenticación adecuada, no un despliegue de malware personalizado — pero la intención operacional era idéntica a la carga útil de ZionSiphon: manipular el cloro para dañar a civiles.

La comparación histórica técnicamente más relevante es Stuxnet, el ciberarma de 2009–2010 ampliamente atribuido a Estados Unidos e Israel, dirigido al programa de enriquecimiento de uranio de Irán en Natanz. Stuxnet utilizó cuatro exploits separados de día cero de Windows, certificados de controladores Siemens falsificados y un puente de air gap basado en USB para llegar a los PLCs Siemens S7-315 y S7-417 con air gap que controlaban las centrífugas IR-1 de Siroua. Manipuló convertidores de frecuencia para causar la destrucción física de las centrífugas mientras proporcionaba lecturas normales falsificadas a los operadores. ZionSiphon comparte la estrategia de propagación por USB de Stuxnet y su enfoque en la manipulación directa de parámetros de procesos industriales, pero opera con una sofisticación técnica mucho menor — sin días cero, sin controladores firmados, sin falsificación de datos de sensores. Es, analíticamente, lo que parece un arma ICS en desarrollo temprano antes de que un actor de amenaza capaz la complete.

TRITON/TRISIS, descubierto en 2017 en una instalación petroquímica saudita, es otra comparación relevante. Ese malware apuntó a los Sistemas Instrumentados de Seguridad Triconex de Schneider Electric — la última capa de protección que evita que los procesos industriales causen daño físico o explosión. Al igual que ZionSiphon, combinó mecanismos de persistencia de capa TI con conocimiento de protocolo de capa OT (el protocolo propietario TriStation de Triconex). A diferencia de ZionSiphon, TRITON estaba funcionalmente completo y desplegado operacionalmente. El hilo común: actores de estado-nación o proxies de estado-nación invirtiendo en armas OT personalizadas dirigidas a entornos industriales específicos en regiones geopolíticamente disputadas.

El ataque al sistema de tratamiento de agua de Oldsmar, Florida en 2021 — donde un atacante accedió a un HMI conectado por TeamViewer y aumentó los niveles de hidróxido de sodio a 111 veces la cantidad normal antes de que un operador lo notara — demostró que los sistemas de tratamiento de agua pueden ser manipulados de forma remota y que las consecuencias físicas de la manipulación química son reales y rápidas. En ese caso, la supervisión manual detectó la manipulación en minutos. El diseño de ZionSiphon asume el procesamiento automatizado de archivos de configuración en lugar de depender del acceso remoto, lo que no necesariamente activaría la misma visibilidad del operador.

Implicaciones Operacionales y Estratégicas

La versión analizada de ZionSiphon no es actualmente capaz de ejecutar su ataque previsto. Este hecho no debe oscurecer lo que el malware revela sobre las capacidades e intenciones del actor de amenaza. Tampoco debe aplicarse la palabra “inacabado” descuidadamente — ZionSiphon no es un arma inacabada. Es un arma completamente armada con un gatillo roto. La distinción importa operacionalmente: todo lo que está aguas abajo de la compuerta de validación está completo y funcional. La manipulación de archivos de configuración funciona. El ciclo de lectura-descubrimiento-escritura de Modbus funciona. La propagación por USB y el engaño LNK funcionan. El antiforensics de autodestrucción funciona. Lo que no funciona es la única condicional que decide si disparar. La implementación de Modbus demuestra conocimiento genuino de la capa de protocolo: el autor estructuró correctamente las tramas de lectura FC03, comprendió el direccionamiento de registros, construyó lógica de descubrimiento de registros dinámico y construyó tramas de escritura FC06 válidas. El fingerprinting del entorno refleja investigación de dominio sobre proveedores específicos de tratamiento de agua israelíes y sus convenciones de nomenclatura de software. El mecanismo de autodestrucción refleja conciencia de seguridad operacional. El mecanismo de propagación por USB refleja comprensión de la arquitectura de air gap en infraestructura crítica.

La validación XOR rota es una corrección de una sola línea. Cambiar la cadena de comparación almacenada de "Nqvbdk" a la codificación XOR-5 correcta de "Israel" — que es "Lvwddi" — haría funcional la compuerta de país. En ese momento, cada mecanismo aguas abajo se activa. La manipulación de archivos de configuración se ejecutaría inmediatamente en cualquier sistema que aloje los archivos de software de tratamiento de agua objetivo. La lógica de escaneo Modbus y escritura de registros se ejecutaría contra cada dispositivo en la subred local que responda en el puerto 502. La propagación por USB se difundiría silenciosamente a cualquier medio removible insertado en el host infectado.

Las ramas incompletas de DNP3 y S7comm son una preocupación separada. DNP3 es el protocolo dominante en los sistemas SCADA de servicios de agua de América del Norte; S7comm es nativo de los PLCs Siemens utilizados en instalaciones industriales europeas y de Oriente Medio, incluida la infraestructura hídrica en Israel. Un actor que complete la capacidad multiprotocolo de ZionSiphon tendría un único malware capaz de atacar la capa de control en todo el espectro de arquitecturas de tratamiento de agua occidentales, no solo en instalaciones basadas en Modbus. El hecho de que el autor claramente entendiera cómo se ve el prefijo correcto de S7 WriteVar y comenzó a implementarlo sugiere que esta finalización es una cuestión de tiempo y esfuerzo del desarrollador, no una brecha de capacidad fundamental.

Calum Hall de Darktrace enmarca la importancia más amplia con precisión: ZionSiphon es representativo de un patrón creciente de actores de amenaza que experimentan con malware orientado a OT y lo aplican hacia infraestructura crítica — y que el monitoreo continuo, la detección rápida de anomalías y la visibilidad cruzada entre entornos de TI y OT siguen siendo esenciales para identificar amenazas en etapas tempranas antes de que evolucionen en ataques operacionalmente viables. La palabra clave es “evolucionar”. Lo que existe hoy como una muestra de desarrollo rota está a una revisión de código de convertirse en un arma funcional para el suministro de agua.