


Equipo Shieldworkz
Presentamos una investigación basada en evidencia sobre las presuntas vulneraciones cibernéticas a bordo de dos buques cisterna de energía con destino a Texas, examinando la seguridad de TI/OT marítima, las afirmaciones no verificadas sobre el control del motor y la posible conexión iraní.
En agosto de 2026, las autoridades estadounidenses investigaron presuntas vulneraciones cibernéticas que involucraban a dos buques comerciales de transporte de energía que navegaban hacia Texas.
Los buques eran el petrolero de crudo VL Prosperity y el transportador de GLP Kohaku. Según los informes basados en funcionarios estadounidenses y datos de rastreo de buques, ambos barcos fueron el objetivo mientras transitaban por el Estrecho de Gibraltar. Después de que los buques llegaron al Golfo de México, personal de la Guardia Costera de EE. UU. y del FBI llevó a cabo abordajes especializados de ciberseguridad el 21 y 24 de agosto.
Hemos cubierto el incidente del VL Prosperity aquí.
El gobierno de EE. UU. ha confirmado un hecho importante: los investigadores tenían indicios de que las redes de los buques habían sido comprometidas por actores cibernéticos extranjeros. La Guardia Costera y el FBI examinaron tanto los sistemas de tecnología de la información como los de tecnología operativa y colaboraron con la tripulación y los operadores de los buques para hacer frente a la amenaza. La Guardia Costera informó posteriormente que no se produjeron interrupciones operativas, inestabilidad en los buques, peligro físico para las tripulaciones ni impactos ambientales.
Una versión distinta y mucho más dramática provino de los medios de comunicación iraníes. La Agencia de Noticias Mehr informó que el VL Prosperity sufrió un ciberataque el 7 de agosto y perdió las comunicaciones durante aproximadamente 30 horas. Citando a un miembro de la tripulación no identificado, el informe afirmó que los atacantes accedieron a los sistemas de la sala de máquinas, redujeron el flujo de enfriamiento del motor, aumentaron su velocidad e interfirieron con los sistemas de combustible y aceite de motor. Esas afirmaciones no han sido verificadas de forma independiente por el gobierno de EE. UU. y ninguna evidencia forense pública ha demostrado que los atacantes hayan manipulado la propulsión u otra OT crítica para la seguridad.
La distinción es fundamental.
El registro público actual establece una vulneración de la red y una posterior investigación cibernética federal. No establece que un atacante haya controlado remotamente el sistema de propulsión, el sistema de navegación o los sistemas de carga de ninguno de los buques cisterna.
No obstante, el incidente es importante porque demuestra que los investigadores cibernéticos consideraron el compromiso lo suficientemente relevante como para llevar a cabo inspecciones a bordo tanto en sistemas de TI como de OT. También ilustra por qué el riesgo cibernético marítimo no puede tratarse únicamente como un problema de seguridad de la información: en un buque moderno, una vulneración cibernética puede intersectarse potencialmente con los sistemas responsables de la propulsión, la navegación, la maquinaria y las operaciones de carga. La contraalmirante Amy Grable, comandante del Comando Cibernético de la Guardia Costera, advirtió específicamente que los sistemas interconectados del buque pueden acarrear consecuencias para la seguridad si son vulnerados y controlados.
Las interrogantes técnicas más importantes siguen sin respuesta:
· ¿Cómo obtuvieron los atacantes el acceso inicial?
· ¿Qué redes y sistemas se vieron realmente comprometidos?
· ¿La intrusión pasó de la tecnología de la información a la tecnología operativa?
· ¿La interrupción de las comunicaciones reportada fue causada por la intrusión?
· ¿Se modificó realmente algún parámetro del motor o de la maquinaria?
· ¿El mismo mecanismo de acceso afectó a ambos buques?
· ¿Qué evidencia, si la hay, respalda una conexión iraní?
Hasta el 18 de septiembre de 2026, esas preguntas siguen sin resolverse públicamente.
¿Qué ocurrió?
El incidente consiste esencialmente en dos versiones superpuestas.
La primera es la respuesta estadounidense documentada públicamente.
La segunda es la versión técnica no verificada publicada por medios iraníes.
Hemos intentado mantener estas dos líneas de evidencia por separado.
¿Qué han establecido las autoridades estadounidenses?
Según la Guardia Costera y el FBI:
Las autoridades estadounidenses recibieron indicios de que las redes a bordo de dos buques comerciales de bandera extranjera habían sido vulneradas.
La Guardia Costera indicó que la actividad involucraba a actores cibernéticos extranjeros.
Un equipo especializado abordó un buque el 21 de agosto.
El equipo incluía personal de las fuerzas del orden de la Guardia Costera, miembros del Cyber Protection Team de la Guardia Costera, un inspector de buques y operadores del Cyber Action Team del FBI.
Los investigadores examinaron tanto los sistemas de TI como los de OT.
Un segundo buque fue abordado el 24 de agosto.
Las autoridades no reportaron inestabilidad en los buques, interrupciones operativas, peligro físico para las tripulaciones ni impacto ambiental.
Las declaraciones públicas de EE. UU. no identificaron al actor de la amenaza.
Lo que sigue siendo una afirmación reportada
Los medios iraníes informaron que el VL Prosperity experimentó un ciberataque el 7 de agosto mientras transitaba por el Estrecho de Gibraltar y perdió las comunicaciones durante aproximadamente 30 horas.
La versión de Mehr, citando a un tripulante no identificado, alegó que los atacantes alcanzaron los sistemas de la sala de máquinas y manipularon el enfriamiento del motor, su velocidad y los sistemas de combustible/aceite lubricante.
El WSJ informó sobre estas acusaciones, pero declaró que no pudo confirmarlas de forma independiente.
Cronología del incidente
Fecha | Evento | Estado de la evidencia |
1 de agosto de 2026 | El VL Prosperity zarpó de Sidi Kerir, Egipto, según datos de rastreo marítimo. | Confirmado por datos del buque |
7 de agosto de 2026 | Los medios iraníes informaron que el VL Prosperity sufrió un ciberataque mientras transitaba por el Estrecho de Gibraltar y experimentó una interrupción en las comunicaciones. | Reportado / No verificado |
20 de agosto de 2026 | Mehr News reportó públicamente el presunto ataque y afirmó que los sistemas de la sala de máquinas se habían visto afectados. | Publicación confirmada; afirmaciones no verificadas |
21 de agosto de 2026 | Personal de la Guardia Costera de EE. UU./FBI llevó a cabo un abordaje especializado de ciberseguridad en un buque entrante de bandera extranjera. | Confirmado |
24 de agosto de 2026 | El FBI declaró que se abordó un segundo buque tras indicios de que su red había sido comprometida. | Confirmado |
Finales de agosto | Se informó que el VL Prosperity fue autorizado para reanudar operaciones normales tras la investigación. | Confirmado para el VL Prosperity; no establecido públicamente en el mismo grado para el Kohaku |
15–17 de septiembre | Las autoridades estadounidenses reconocieron públicamente los abordajes de ciberseguridad tras reportes en los medios. | Confirmado |
18 de septiembre | Sin atribución pública por parte de EE. UU. a Irán u otro actor de amenaza específico. | Posición pública actual |
El informe público de la Guardia Costera hace referencia específicamente al abordaje del 21 de agosto, mientras que la información del FBI estableció posteriormente que se abordó un segundo buque el 24 de agosto. Reuters señaló que las agencias no explicaron públicamente todas las diferencias entre sus versiones.
Los buques
VL Prosperity
Los registros públicos identifican al VL Prosperity como un petrolero de crudo de gran tamaño (VLCC):
· IMO: 9683697
· Bandera: Liberia
· Eslora: aproximadamente 333 metros
· Año de construcción: 2015
· Peso muerto: aproximadamente 319,547 toneladas
· Capacidad de crudo: aproximadamente 2.3 millones de barriles
· Travesía: De Egipto hacia Galveston, Texas
Los informes estadounidenses y los datos de rastreo sitúan al buque en una travesía desde Egipto hacia Galveston. La Guardia Costera no nombró públicamente al buque de manera directa, pero múltiples informes lo identificaron como el VL Prosperity.
Kohaku
Los datos públicos del buque identifican al Kohaku como:
· IMO: 9932608
· Tipo de buque: Transportador de GLP
· Eslora: aproximadamente 227 metros
· Año de construcción: 2023
· Bandera: Islas Marshall
Según los reportes, el buque navegaba hacia un puerto de Texas para cargar GLP.
¿Qué se sabe realmente sobre la vulneración cibernética?
Confirmado o sólidamente respaldado
Compromiso de la red:
El FBI afirmó que su equipo conjunto de la Guardia Costera y el FBI abordó los buques tras recibir indicios de que las redes de ambos barcos estaban comprometidas. La Guardia Costera describió a los responsables como actores cibernéticos extranjeros.
Inspección de TI y OT:
La Guardia Costera declaró que los investigadores examinaron tanto los sistemas de tecnología operativa como los de tecnología de la información de los buques.
Respuesta cibernética federal:
La respuesta involucró a personal cibernético especializado de la Guardia Costera y operadores del Cyber Action Team del FBI.
Sin consecuencias de seguridad reportadas públicamente:
La Guardia Costera no reportó interrupciones operativas, inestabilidad en los buques, peligro físico para las tripulaciones ni impactos ambientales.
Reportado pero no verificado
Mehr informó:
· aproximadamente 30 horas de interrupción de las comunicaciones;
· acceso a los sistemas de la sala de máquinas;
· reducción del enfriamiento del motor;
· aumento de la velocidad del motor;
· interferencia en los sistemas de combustible y aceite de motor.
Dichas afirmaciones se originaron en medios iraníes y en una fuente anónima de la tripulación. El WSJ indicó que no pudo confirmarlas de forma independiente.
Desconocido
Actualmente no existe evidencia pública que establezca:
el malware utilizado;
el vector de acceso inicial;
credenciales comprometidas;
VPN comprometida;
explotación de una terminal satelital;
explotación de una conexión de proveedor;
movimiento lateral de TI a OT;
manipulación de PLCs o controladores de motor;
manipulación del ECDIS;
control remoto del timón;
manipulación del sistema de carga;
persistencia tras la llegada de los buques a aguas estadounidenses.
Estos elementos deben permanecer como desconocidos, no reconstruidos como hechos. Pasemos ahora a la pregunta más importante.
¿Podría un ciberatacante controlar realmente un buque cisterna?
La respuesta depende totalmente de la arquitectura.
El compromiso de la red corporativa de TI de un buque no proporciona automáticamente el control de la propulsión o la navegación.
Una cadena de ataque realista requeriría (potencialmente) varias condiciones adicionales (similar al modelo del queso suizo):
Conectividad externa → red de a bordo → autenticación/control de acceso → frontera de segmentación → estación de trabajo de ingeniería u OT → red de control → controlador relevante → proceso físico
Cada paso representa una barrera técnica adicional.
La arquitectura precisa del VL Prosperity y el Kohaku no está disponible públicamente, por lo que sería inadecuado afirmar que alguno de los buques utiliza un protocolo de PLC en particular, arquitectura de firewall, diodo de datos, jump server o topología de mantenimiento remoto.
Por lo tanto, deben distinguirse cuatro niveles diferentes de compromiso
Nivel | Significado | Evidencia en este caso |
Acceso a la red | Acceso a una red de a bordo | Respaldado por declaraciones de EE. UU. |
Interrupción de TI | Interferencia en comunicaciones o sistemas administrativos | Reportado parcialmente |
Acceso a OT | Acceso a redes de maquinaria/control | No establecido públicamente |
Manipulación de procesos físicos | Alteración real de procesos de propulsión, navegación o carga | No establecido públicamente |
Esa distinción es más importante que la dramática pregunta de si un atacante podría teóricamente “tomar el control de un barco”.
La contraalmirante Amy Grable ha confirmado que los sistemas interconectados del buque pueden crear una vía que lleve desde el compromiso cibernético hasta consecuencias para la seguridad. Pero su declaración describe la condición de riesgo, no una evidencia de que los dos buques en este caso hayan sido controlados de manera remota.
Las afirmaciones sobre la sala de máquinas
La acusación técnicamente más significativa se refiere a la sala de máquinas del VL Prosperity.
Mehr informó que los atacantes:
· redujeron el flujo de enfriamiento del motor;
· aumentaron la velocidad del motor;
· interfirieron con los sistemas de combustible;
· interfirieron con los sistemas de aceite del motor.
Estas afirmaciones merecen escrutinio, pero no deben considerarse conclusiones confirmadas.
Existen varias posibilidades:
· Las afirmaciones podrían describir una manipulación real de los sistemas de maquinaria.
· Podrían describir una interrupción temporal o lecturas anómalas en lugar de un control directo.
· Podrían representar una comprensión incompleta o inexacta de lo ocurrido.
· Podrían reflejar información divulgada durante una investigación en curso.
· Podrían ser una combinación de actividad cibernética real y una interpretación técnica inexacta.
La evidencia pública actual no permite separar estas posibilidades.
Más importante aún, la ausencia de consecuencias físicas confirmadas públicamente no prueba automáticamente que la OT haya quedado intacta. A la inversa, la existencia de una red comprometida no demuestra automáticamente que se haya alcanzado la OT.
Esa incertidumbre es precisamente la razón por la que la investigación federal examinó tanto TI como OT.
Investigando la conexión iraní
EE. UU. investiga si Irán fue responsable o estuvo involucrado.
El WSJ reportó que funcionarios estadounidenses investigaban una posible implicación iraní. El mismo informe señala que las autoridades estadounidenses no habían atribuido públicamente los ataques a Irán.
Evidencia de atribución disponible actualmente
Evidencia | Evaluación |
Investigación de EE. UU. sobre una posible implicación iraní | Reportada |
Identificación de EE. UU. de actores cibernéticos extranjeros | Confirmada |
Informes de medios iraníes sobre el incidente del VL Prosperity | Confirmada |
Identificación por medios iraníes de efectos técnicos específicos | Confirmada como reporte, no como hecho comprobado |
Evidencia pública de malware/C2 vinculada a Irán | No divulgada |
Evidencia pública de IP/infraestructura vinculada a Irán | No divulgada |
Atribución pública de EE. UU. al gobierno/grupo iraní | Ninguna identificada |
Actor de amenaza adjudicándose la responsabilidad | Ninguno identificado |
El hecho de que los medios iraníes informaran detalles sobre el incidente es relevante para la investigación, pero no constituye en sí mismo una evidencia forense de atribución.
Tampoco hay pruebas públicas que establezcan que los reportes provinieran de comunicaciones interceptadas, una fuente de inteligencia o conocimiento directo de los atacantes.
Por lo tanto:
La atribución sigue sin resolverse.
La postura analítica apropiada es que la participación iraní es una hipótesis de investigación activa.
Mapeo MITRE ATT&CK
MITRE ATT&CK no debe utilizarse para llenar vacíos en la investigación.
Por consiguiente, el siguiente mapeo distingue entre lo que es potencialmente aplicable y lo que realmente se ha demostrado.
Técnica | ID | Relevancia | Estado |
Exploit Public-Facing Application | T1190 | Podría aplicar si se explotó una aplicación o dispositivo expuesto a Internet | Posible / No hay evidencia revelada |
Valid Accounts | T1078 | Podría aplicar si se utilizaron credenciales robadas o comprometidas | Posible / No hay evidencia revelada |
Remote Services | T1021 | Podría aplicar si se utilizaron servicios remotos para movimiento lateral | Posible / No hay evidencia revelada |
Modify Parameter | T0836 | Relevante para la supuesta afirmación de manipulación de parámetros de maquinaria/control | Alegado, no verificado |
MITRE define T0836 como la modificación de parámetros utilizados para dar instrucciones a dispositivos ICS. Por lo tanto, es conceptualmente relevante para la acusación sobre la sala de máquinas, pero mapear una técnica no establece que dicha técnica haya tenido lugar.
Del mismo modo, T1190, T1078 y T1021 no deben presentarse como pasos de ataque reconstruidos sin evidencia que demuestre el uso de tales mecanismos.
La superficie de ataque de OT marítima
Aunque la arquitectura de los dos buques no está documentada públicamente, los operadores marítimos comúnmente necesitan gestionar el riesgo cibernético a lo largo de varios dominios tecnológicos conectados.
Estos pueden incluir:
· comunicaciones satelitales;
· TI administrativa de a bordo;
· redes de la tripulación;
· sistemas de navegación;
· monitoreo de motores y maquinaria;
· sistemas de control de propulsión;
· sistemas de control de carga;
· sistemas de lastre;
· estaciones de trabajo de ingeniería;
· conexiones de soporte remoto de proveedores;
· enlaces de datos tierra-buque;
· medios extraíbles;
· plataformas de gestión de flotas.
Por consiguiente, la interrogante relevante de seguridad no es simplemente:
“¿Está conectado el buque a Internet?”
Sino:
“¿Qué sistemas conectados pueden comunicarse con los sistemas que influyen en la operación segura del buque y bajo qué controles?”
La orientación sobre riesgos cibernéticos marítimos de la OMI utiliza un enfoque de gestión de riesgos que abarca la identificación, protección, detección, respuesta y recuperación. La organización también ha reconocido explícitamente que el riesgo cibernético forma parte del entorno más amplio de la gestión de la seguridad en el transporte marítimo.
El límite TI/OT es una cuestión crítica
La cuestión técnica central en este incidente es si el compromiso se mantuvo dentro de las redes de información o cruzó a la tecnología operativa.

La implementación exacta debe determinarse mediante una evaluación de riesgos específica para el buque.
Un diodo de datos puede ser apropiado para ciertas arquitecturas de monitoreo unidireccional, pero no debe presentarse como un requisito universal para la OT marítima. Del mismo modo, aislar físicamente (“air-gap”) las computadoras portátiles de diagnóstico no siempre es operativamente realista.
En su lugar, el objetivo de seguridad debe ser:
· minimizar la conectividad innecesaria;
· controlar estrictamente el acceso remoto;
· autenticar a los usuarios con privilegios;
· segmentar los sistemas de acuerdo con el riesgo operativo;
· monitorear las comunicaciones de OT;
· controlar los medios extraíbles;
· mantener mecanismos seguros de respaldo manual;
· validar cambios en sistemas de control críticos;
· preservar la capacidad de recuperación.
Consecuencias de seguridad: Teóricas vs. observadas
Riesgo | Consecuencia potencial | Evidencia en este incidente |
Manipulación de la propulsión | Pérdida de velocidad/control, colisión o encallamiento | No establecida |
Compromiso del sistema de navegación | Desviación de ruta o degradación de la navegación | No establecido |
Manipulación de la maquinaria | Daño al equipo o pérdida de propulsión | Alegado por medios iraníes; no verificado de forma independiente |
Interrupción de comunicaciones | Pérdida de la capacidad normal de comunicación | Reportado para el VL Prosperity, no verificado de forma independiente en hallazgos públicos de EE. UU. |
Manipulación del sistema de carga | Problemas en la transferencia o contención de la carga | No establecida |
Incendio/explosión | Graves consecuencias físicas y ambientales | Riesgo teórico; ninguno reportado |
Evento de seguridad de la tripulación | Lesiones o respuesta a emergencias | Ninguno reportado |
Fuga o derrame ambiental | Evento contaminante de petróleo/GLP | Ninguno reportado |
Esta distinción debe mantenerse en todo el artículo.
Las consecuencias ciberfísicas potenciales son reales. La evidencia pública no demuestra que hayan ocurrido en este incidente.
Por qué es importante el Estrecho de Gibraltar
El Estrecho de Gibraltar es un corredor marítimo de importancia estratégica que conecta el Mediterráneo con el Atlántico.
El WSJ informó que aproximadamente 300 barcos transitan por esta vía navegable cada día, lo que ilustra la escala del tráfico marítimo a través del corredor.
Para los defensores cibernéticos, la relevancia no radica únicamente en que el estrecho sea geográficamente angosto.
Un buque en tránsito enfrenta restricciones de respuesta distintas a las de una instalación en tierra:
· los ingenieros en tierra pueden no estar disponibles de inmediato;
· el acceso físico a los sistemas es limitado;
· la conectividad de red puede ser intermitente o degradada;
· la tripulación debe mantener una navegación segura mientras investiga un incidente;
· la respuesta cibernética debe coexistir con los procedimientos de ingeniería y seguridad marina;
· preservar la evidencia puede ser difícil sin interrumpir las operaciones.
Eso convierte a la respuesta a incidentes a bordo de buques en una disciplina operativa diferenciada.
El desarrollo más importante: Investigación cibernética en alta mar
Uno de los aspectos más significativos de este incidente no es la afirmación no verificada de la manipulación remota del motor.
Es la decisión del gobierno de EE. UU. de llevar a cabo una investigación cibernética especializada a bordo de los buques una vez que ingresaron al Golfo de México.
El equipo de la Guardia Costera incluía especialistas cibernéticos, personal de las fuerzas del orden y un inspector de buques, mientras que personal del Cyber Action Team del FBI participó en la investigación. El equipo examinó tanto los entornos de TI como los de OT.
Esto demuestra un requisito cada vez más importante para los operadores marítimos:
Un incidente cibernético a bordo de un buque puede convertirse en un problema de respuesta física ante incidentes.
La investigación puede requerir personal que comprenda:
· análisis forense de redes;
· ingeniería naval;
· arquitectura de OT;
· navegación;
· control de maquinaria;
· preservación de evidencia;
· seguridad marítima;
· operaciones portuarias.
Esa convergencia es, posiblemente, la lección operativa más importante del caso.
Lo que este incidente revela sobre la ciberseguridad marítima
El compromiso de la red no equivale al control del buque
La distinción entre acceso, persistencia, acceso a OT y manipulación física debe permanecer explícita.
Los límites entre TI y OT requieren evidencia, no suposiciones
Un buque puede tener una conectividad considerable sin proporcionar una vía directa hacia la propulsión o la navegación.
Los incidentes cibernéticos pueden requerir intervención física
La respuesta de EE. UU. demuestra que las autoridades pueden necesitar examinar los sistemas de a bordo directamente cuando se sospecha de un compromiso en la red de un buque.
La respuesta cibernética marítima debe ser consciente de las operaciones
Investigar un barco comprometido es diferente a investigar la red comprometida de una oficina.
La conectividad de terceros merece una atención rigurosa
La gestión de flotas, el soporte del OEM y las conexiones remotas de ingeniería pueden generar vías legítimas que exigen autenticación sólida, segmentación, autorización y monitoreo.
La resiliencia importa tanto como la prevención
Un buque debe ser capaz de mantener operaciones seguras cuando los sistemas digitales dejen de estar disponibles o no sean confiables.
Recomendaciones defensivas
La respuesta adecuada no es desconectar cada barco de cada red externa.
Consiste en hacer que la conectividad sea controlada, observable y recuperable.
1. Establecer un inventario completo de activos cibernéticos del buque
Identificar:
· sistemas de TI;
· sistemas de OT;
· sistemas de navegación;
· sistemas de control de maquinaria;
· sistemas de carga;
· equipos de comunicación;
· estaciones de trabajo de ingeniería;
· puertas de enlace (gateways) de acceso remoto;
· conexiones de proveedores;
· interfaces de medios extraíbles.
Los activos críticos deben mapearse con respecto a sus consecuencias operativas.
2. Segmentar las redes del buque según el riesgo operativo
Separar, donde sea técnica y operativamente adecuado:
· redes de tripulación/bienestar;
· TI administrativa;
· comunicaciones;
· navegación;
· ingeniería;
· control de maquinaria;
· sistemas de control de carga.
Utilizar conductos controlados y acceso monitoreado entre zonas.
3. Eliminar el acceso remoto permanente innecesario
El acceso de proveedores debe emplear:
autenticación robusta;
privilegio mínimo;
acceso con límite de tiempo;
jump hosts controlados;
flujos de trabajo de aprobación;
registro de sesiones;
monitoreo de accesos.
4. Monitorear la OT de forma pasiva
El monitoreo de OT debe establecer patrones normales de comunicación e identificar:
conexiones inesperadas de estaciones de ingeniería;
cambios de configuración no autorizados;
tráfico de control inusual;
nuevos dispositivos;
sesiones remotas inesperadas;
cambios en parámetros críticos.
5. Fortalecer los controles sobre medios extraíbles
Los dispositivos USB de ingeniería deben inventariarse, escanearse y controlarse antes de introducirlos en entornos sensibles.
6. Diseñar procedimientos de respuesta a incidentes específicos para el buque
Los planes deben responder a:
¿Quién declara un incidente cibernético?
¿Quién puede aislar una red?
¿Quién controla la maquinaria si los sistemas digitales dejan de estar disponibles?
¿Cómo se preserva la evidencia?
¿Cuándo se notifica al operador del buque?
¿Cuándo se contacta a las autoridades?
¿Cómo continúa navegando el buque de manera segura mientras se realiza el trabajo forense?
7. Practicar el respaldo manual
Los ejercicios cibernéticos deben incluir escenarios de redes degradadas en lugar de limitarse a simulaciones de ransomware en TI.
El objetivo no es simplemente restaurar un servidor.
Es mantener la operación segura del buque.
Una arquitectura práctica de seguridad OT marítima
Una arquitectura de referencia debe centrarse en segmentación, acceso controlado y visibilidad, en lugar de asumir que cada barco requiere el mismo hardware.

La comunicación entre zonas debe estar explícitamente autorizada, monitoreada y minimizada.
Para las arquitecturas de monitoreo, pueden considerarse flujos de datos unidireccionales donde brinden valor operativo sin introducir rutas de control innecesarias.
Esto debe determinarse mediante ingeniería y análisis de riesgos específicos para cada buque, en lugar de imponerse como una arquitectura genérica.
Programa de Ciberseguridad Marítima de 30–90–180 días
Período | Prioridad |
0–30 días | Inventariar conectividad externa, rutas de acceso remoto, activos críticos de OT y cuentas privilegiadas |
30–90 días | Revisar segmentación, acceso de proveedores, MFA, medios extraíbles y controles de estaciones de trabajo de ingeniería |
90–180 días | Implementar monitoreo pasivo de OT, establecer procedimientos específicos de RI cibernética para buques y realizar simulacros |
6–12 meses | Completar evaluaciones de riesgo cibernético del buque/flota, reforzar la arquitectura e integrar el riesgo cibernético en los procesos operativos y de gestión de la seguridad |
La orientación sobre riesgos cibernéticos de la OMI enfatiza la identificación continua, protección, detección, respuesta y recuperación en lugar de tratar la ciberseguridad como un ejercicio de cumplimiento de una sola vez.
Preguntas sin resolver
Diversas interrogantes siguen siendo clave para la investigación:
¿Cuál fue el vector de acceso inicial?
¿Se comprometieron credenciales?
¿Se explotó un sistema expuesto a Internet?
¿Estuvo involucrada la infraestructura de comunicaciones satelitales?
¿Hubo una conexión de proveedor o de gestión de flotas involucrada?
¿Alcanzaron los atacantes las redes de OT?
¿Se comprometió algún PLC, HMI o estación de trabajo de ingeniería?
¿La interrupción de comunicaciones reportada derivó directamente de una actividad maliciosa?
¿Se modificaron realmente los parámetros del motor?
¿Se comprometió el Kohaku mediante el mismo mecanismo?
¿Estuvieron expuestos otros buques de la misma flota?
¿Identificaron los investigadores mecanismos de persistencia?
¿Se recuperaron muestras de malware?
¿Darán a conocer las autoridades IoCs o hallazgos forenses?
¿Qué evidencia sustenta la investigación sobre la posible participación iraní?
Hasta que estas preguntas encuentren respuesta, cualquier reconstrucción detallada de la cadena de ataque seguirá siendo provisional.
Evaluación de Shieldworkz
La evidencia disponible respalda una conclusión más acotada de lo que sugieren algunos de los primeros reportes.
Dos buques comerciales de transporte de energía con destino a EE. UU. fueron objeto de presuntas vulneraciones cibernéticas lo suficientemente graves como para activar investigaciones cibernéticas especializadas por parte de la Guardia Costera y el FBI. Las autoridades estadounidenses identificaron a actores cibernéticos extranjeros y examinaron entornos tanto de TI como de OT. No se informó públicamente de interrupciones operativas, inestabilidad de los buques, peligro físico para las tripulaciones ni impacto ambiental.
La afirmación más dramática referente a que los atacantes manipularon la propulsión y los sistemas de la sala de máquinas a bordo del VL Prosperity continúa sin verificarse en el registro público.
Del mismo modo, la participación iraní sigue siendo una hipótesis de investigación. Por lo tanto, la lección estratégica no depende de demostrar que un atacante tomó exitosamente el control de un petrolero.
La lección más inmediata es que los buques comerciales son entornos ciberfísicos cuyo compromiso de red puede requerir la misma combinación de análisis forense digital, experiencia en OT, criterio de ingeniería y respuesta de seguridad que normalmente se asocia con instalaciones industriales.
Para los operadores de flotas, la pregunta clave no radica en si cada ciberataque puede provocar una colisión.
Radica en si un atacante puede desplazarse desde un sistema de información o comunicaciones comprometido hacia un sistema fundamental para la navegación segura, la propulsión o las operaciones de carga, y si el operador es capaz de detectar, contener y recuperarse de dicho movimiento antes de que se transforme en un incidente operativo.
Ese es el límite de seguridad que merece la máxima atención.
Lo que los operadores marítimos deben aprender de este incidente
Las prioridades prácticas son claras:
· Saber qué está conectado.
· Saber qué conexiones pueden alcanzar la OT.
· Controlar quién puede acceder a ellas.
· Monitorear cambios en sistemas críticos.
· Mantener una alternativa segura de respaldo manual.
· Estar preparado para investigar un buque mientras continúa en operación.
· Tratar el riesgo cibernético como parte del riesgo operativo y de seguridad, no simplemente como un asunto de TI.
El marco de gestión de riesgos cibernéticos marítimos de la OMI ubica explícitamente el riesgo cibernético dentro del objetivo más amplio de lograr un transporte marítimo seguro y resiliente.
Recursos de Shieldworkz sobre OT Marítima
Para los lectores interesados en convertir estas lecciones en un programa de seguridad para OT, los siguientes recursos de Shieldworkz son directamente relevantes:
Seguridad OT/ICS para Puertos e Infraestructura Marítima — guía sobre inventario de activos, segmentación, resiliencia en la navegación, acceso de proveedores, monitoreo de OT y recuperación.
Guía Práctica de Evaluación de Riesgos de Ciberseguridad OT Marítima según IEC 62443-3-2 — enfocada en la evaluación de riesgos de OT marítima, inventario de activos, zonas y conductos, calificación de riesgos y planificación del tratamiento.
Protegiendo Puertos Modernos y Terminales Marítimas — un plan alineado con IEC 62443 que abarca arquitectura de OT marítima, segmentación, visibilidad de activos y preparación ante incidentes.
Recurso principal de Shieldworkz:
Seguridad OT/ICS para Puertos e Infraestructura Marítima
Fuentes y base de evidencia
Esta investigación debe leerse considerando la siguiente jerarquía de evidencia:
Fuentes primarias / oficiales
Declaraciones de la Guardia Costera de EE. UU. sobre el abordaje de ciberseguridad y sus hallazgos.
Declaraciones del FBI sobre el abordaje de los dos buques.
Orientación sobre riesgos cibernéticos marítimos de la OMI.
Reportes de alta calidad
Investigación de The Wall Street Journal basada en funcionarios estadounidenses.
Reportes de Reuters sobre el compromiso de los buques y la respuesta del gobierno.
Información de CBS News que incorpora declaraciones de la Guardia Costera y datos sobre los buques.
Reportes secundarios: Información de The Jerusalem Post basada en la investigación del WSJ.
Reportes de la industria marítima acerca de las identidades de los buques y las afirmaciones en medios iraníes.
Material de origen de las afirmaciones
Reportes de la Agencia de Noticias Mehr sobre el presunto ataque del 7 de agosto y los efectos en la sala de máquinas.
La evidencia no debe considerarse equivalente entre estas categorías. En particular, las afirmaciones de manipulación del motor se originan en medios iraníes y en una fuente anónima de la tripulación, y siguen sin verificarse en el registro público.
Recibe semanalmente
Recursos y Noticias
Vea cómo nuestras soluciones de seguridad de OT líderes en la industria abordan los desafíos de seguridad críticos
También te puede interesar

IE & E Industries Ransomware Claim: What Orova’s Listing Does and Doesn’t Prove

Team Shieldworkz

Calmont Wire & Cable Ransomware Claim 2026: What Akira's Listing Means for Industrial Suppliers

Team Shieldworkz

NIST SP 800-82 Rev 4 Draft: What Changes for OT Security Teams (Comments Due Nov 30)

Team Shieldworkz

Bridgestone HosePower Ransomware Claim: What Pear’s Listing Does and Doesn’t Prove

Team Shieldworkz

France Blood Storage Cyberattack 2026: What Happened to EFS Cold Rooms, and What It Means for Healthcare OT

Team Shieldworkz

Amadeus Breach Explained: How One Vendor’s Stolen Credentials Exposed Airline Passenger Data Across Asia

Team Shieldworkz

