Lo esencial
El 22 de julio de 2026, CISA, el FBI, la EPA y otros socios del Gobierno de EE. UU. actualizaron la alerta conjunta AA26-097A, publicada originalmente en abril de 2026. El mensaje central no cambia: hay actores afiliados a Irán manipulando controladores lógicos programables (PLC, los pequeños ordenadores industriales que gobiernan bombas, válvulas y líneas de producción) expuestos a Internet en sectores de agua, energía y administración. Lo nuevo es que la actividad alcanza a más fabricantes y que las agencias publican indicadores y guía de detección frescos. Para un responsable de OT en Europa no es una noticia lejana: la misma exposición existe aquí, y NIS2 ya la convierte en un problema de cumplimiento.
La parte incómoda del aviso no es la sofisticación, sino lo contrario. Según recogen el comunicado de CISA reproducido por GlobalSecurity y ExecutiveGov, los atacantes no necesitaron un día cero ni una vulnerabilidad nueva. Encontraron PLCs accesibles directamente desde Internet, con credenciales por defecto o inexistentes, y actuaron. El texto íntegro de la alerta está disponible en el aviso del IC3. Es la definición de riesgo evitable.
Y el objetivo es especialmente peligroso. La actividad descrita en la alerta incluye intentar descargar ficheros de proyecto maliciosos y manipular los datos que se muestran en las interfaces hombre-máquina (HMI) y en los paneles SCADA (los sistemas de supervisión, control y adquisición de datos). Es decir, atacar la imagen de la realidad que ve el operador: la sala de control cree que el proceso va bien mientras deja de ir bien. De ahí las interrupciones operativas y las pérdidas económicas que la alerta atribuye a algunas víctimas.
Qué dice exactamente la actualización
La alerta AA26-097A se publicó en abril de 2026 y advertía de actividad iraní contra dispositivos de tecnología operativa (OT) conectados a Internet. La revisión del 22 de julio introduce cuatro cambios, según el comunicado oficial y su reproducción en GlobalSecurity: guía nueva para detectar cambios maliciosos en los módulos de código reutilizables que se usan dentro de los programas de PLC de Rockwell Automation; mitigaciones adicionales; indicadores de compromiso renovados; y una ampliación del alcance de fabricantes observados.
Esa ampliación es la parte que obliga a reabrir el análisis. La versión de abril apuntaba sobre todo a Rockwell Automation. La actualización añade que también se ha observado ataque a PLCs de Schneider Electric y Siemens, y no descarta otros fabricantes. Conviene subrayar algo para no leer mal el aviso: que aparezca el nombre de un fabricante no significa que su equipo tenga un fallo. El problema no está en el producto, sino en cómo se despliega —expuesto a Internet y con autenticación débil—, y así lo enmarcan las propias agencias al insistir en restringir el acceso directo desde Internet.
La anatomía, en el plano conceptual
Sin entrar en nada replicable, el patrón es comprensible en tres pasos. Primero, descubrimiento: el escaneo masivo de Internet localiza dispositivos OT accesibles —PLCs, HMIs, módems celulares instalados para un proyecto temporal y nunca retirados, estaciones de ingeniería con doble salida de red—. Segundo, acceso: cuando esos dispositivos tienen credenciales por defecto o no piden autenticación, no hace falta más. Tercero, manipulación: descarga de ficheros de proyecto alterados y cambios en lo que muestran HMI y SCADA.
El detalle técnico que más importa para la defensa es el de los módulos de código reutilizables. En plataformas como las de Rockwell, la lógica de control se organiza en instrucciones y bloques reutilizables que se invocan desde varios programas. Un cambio introducido ahí se propaga a todo lo que lo usa y pasa desapercibido si nadie compara el proyecto que corre en el controlador contra una copia buena conocida. Ese es exactamente el hueco de detección que la actualización pide cerrar.
Y hay una segunda capa. Manipular los valores de un panel no es solo sabotaje; es desinformación dirigida al operador. Si el HMI dice que la presión es nominal cuando no lo es, la respuesta humana llega tarde o va en la dirección equivocada. Cualquier plan de defensa serio tiene que asumir que la pantalla puede mentir.
Por qué los controles de siempre no bastan aquí
La mayoría de organizaciones proyecta sus controles de TI sobre la OT y da por hecho que el perímetro corporativo cubre también la planta. No es así. Muchas redes industriales son planas, el acceso remoto de proveedores está permanentemente activo en lugar de habilitarse bajo demanda, y la visibilidad sobre lo que ocurre en el bus de control es mínima. Un antivirus de puesto no ve un cambio de lógica en un PLC, y un cortafuegos perimetral no impide que una estación de ingeniería comprometida hable con el controlador que tiene al lado.
Tampoco ayuda tratar esto como un problema de parcheo. Aquí no hay un CVE que aplicar: el vector es la exposición y la credencial débil. Por eso la priorización clásica por severidad —útil para vulnerabilidades explotables, como explicamos al hablar de KEV, EPSS y SSVC— no captura el riesgo real de un PLC que cualquiera puede alcanzar desde Internet. La pregunta correcta no es qué versión tienes, sino quién puede llegar hasta él.
Detección: qué mirar en tu entorno OT
La detección aquí es sobre todo integridad y contexto, no firmas. El control que cierra el hueco descrito en la alerta es mantener una línea base del proyecto y de la lógica de cada controlador, guardarla fuera de línea y compararla de forma periódica para detectar cambios no autorizados —incluidos los que viven en módulos de código reutilizables—.
A partir de ahí, cuatro señales que merece la pena vigilar de forma conceptual: cambios de modo del controlador (paso de RUN a PROGRAM fuera de una ventana de mantenimiento planificada); descargas de proyecto o escrituras de lógica que no correspondan a un cambio autorizado; actividad inusual desde estaciones de ingeniería o desde el acceso remoto de proveedores; y aparición del propio activo en servicios públicos de indexación de dispositivos, señal de que está expuesto. Un SOC gestionado con visibilidad OT y capacidad de caza de amenazas es quien convierte esas señales en detección real.
Sobre los indicadores renovados que publica la alerta: ingiérelos ya, pero con expectativas realistas. Un indicador de compromiso caduca rápido —la infraestructura rota, los hashes cambian—, así que valen para las primeras semanas y conviene apoyarse cuanto antes en detección por comportamiento y en inteligencia de amenazas que dé contexto al patrón, no solo la lista.
Defensa práctica
La mitigación de fondo no ha cambiado desde abril y la repiten agencias y analistas: los PLC y las HMI no deberían ser accesibles desde Internet. Traducido a controles concretos, empieza por enumerar todo activo OT con cualquier camino hacia Internet —incluidos módems celulares y equipos con doble red— y valida esa exposición desde fuera, escaneando tu propio rango de direcciones. Es, en la práctica, un ejercicio de gestión de la superficie de ataque aplicado a la planta.
Después, elimina cada camino directo o protégelo con un cortafuegos. Donde el acceso remoto sea imprescindible, hazlo pasar por un salto autenticado con MFA, grabación de sesión y acceso limitado en el tiempo; el acceso de proveedores debería habilitarse a petición y quedar deshabilitado por defecto, no permanecer siempre abierto. Cambia todas las credenciales por defecto de PLC y HMI, y activa las protecciones de modo del controlador donde la plataforma lo permita.
Como red de seguridad, guarda una copia fuera de línea de la configuración y la lógica de cada controlador: sirve para detectar cambios y para restaurar tras un incidente. Todo esto encaja en el marco IEC 62443, la referencia de seguridad para sistemas de automatización industrial, y se apoya en un buen bastionado de sistemas. Y, porque la pantalla puede mentir, ensaya en mesa el escenario concreto de la alerta —los paneles muestran valores normales mientras el proceso se desvía— para ver cómo lo reconocería tu equipo, con qué instrumentación independiente cuenta y cómo pasaría a operación manual. Si el incidente llega, un servicio de respuesta a incidentes con experiencia en OT marca la diferencia entre horas y semanas.
Cumplimiento: por qué esto también va de NIS2 y ENS
La alerta es estadounidense, pero la exposición es idéntica a ambos lados del Atlántico. En la UE, NIS2 clasifica la energía y el agua potable y las aguas residuales como sectores de alta criticidad; sus operadores son entidades esenciales, con responsabilidad directa de la dirección y obligaciones de notificación de incidentes en plazos cortos. Un PLC de una potabilizadora accesible desde Internet no es solo un riesgo técnico: es un incumplimiento esperando a materializarse.
Hay una dimensión adicional que conviene tener en el radar. Un análisis de ComplianceHub señala que la incorporación del Departamento del Tesoro de EE. UU. como coautor de la actualización apunta a una vía de sanciones (OFAC): cualquier pago de extorsión a una entidad designada arrastra exposición legal, con independencia de la intención. No es jurisprudencia europea, pero sí un recordatorio de que la respuesta a un incidente de este tipo tiene una capa financiera y de cumplimiento que va más allá de la técnica.
Para la Administración y las entidades públicas —el equivalente europeo de los “servicios gubernamentales y municipios” que cita la alerta—, el Esquema Nacional de Seguridad marca el mismo camino: control de accesos, segmentación y trazabilidad. Y conviene recordar que esto no ocurre en el vacío geopolítico: la actividad contra infraestructura crítica encaja en el patrón de amenaza híbrida que ya analizamos para la ciberseguridad europea, y refuerza la lógica de priorizar por impacto que defendemos al hablar de ciberseguridad OT/IT en la industria. Que en España la transposición de NIS2 siga pendiente de ley no suspende la exposición ni la responsabilidad.
Lo que no cambia
La actualización de AA26-097A no describe una técnica nueva. Describe la misma campaña llegando más lejos, a más fabricantes, con éxito suficiente como para que las agencias renueven los indicadores y refuercen la guía de detección. La lección tampoco es nueva, y por eso escuece: el control que lo corta —que los PLC no sean alcanzables desde Internet— es organizativamente difícil en sectores de operadores pequeños con dependencia de terceros y equipos ajustados, no técnicamente complicado. Quien revisó su exposición en abril y no encontró nada debería revisarla otra vez esta semana. La lista de lo que cuenta como “expuesto” acaba de crecer.
Nota: este artículo incluye orientaciones de detección y bastionado aplicables a entornos OT. Valídalas en un entorno controlado y adáptalas a tu arquitectura y a tu marco de cumplimiento antes de aplicarlas en producción.