Según Defused Cyber, una falla de seguridad crítica que afecta a Oracle E-Business Suite ha sido explotada activamente en la naturaleza.
La vulnerabilidad, rastreada como CVE-2026-46817 (Puntuación CVSS: 9,8), se refiere a una falla de autenticación y gestión de privilegios inadecuada en Oracle Payments de la que se podría abusar para hacerse cargo de instancias susceptibles.
«Una vulnerabilidad fácilmente explotable permite a un atacante no autenticado con acceso a la red a través de HTTP comprometer Oracle Payments», según una descripción de la falla en la Base de datos nacional de vulnerabilidad (NVD) del NIST. «Los ataques exitosos a esta vulnerabilidad pueden resultar en la adquisición de Oracle Payments».
La deficiencia afecta a las versiones desde la 12.2.3 hasta la 12.2.15. Los parches para el defecto fueron enviado por Oracle como parte de su Actualización de parche de seguridad crítica el mes pasado.
Desde entonces, CVE-2026-46817 ha estado bajo explotación activa, con Defused Cyber observando el lunes que «durante el fin de semana, observamos a un actor explotando la vulnerabilidad en nuestros honeypots de Oracle E-Business», y agregó que «esta vulnerabilidad no tiene ninguna explotación previa conocida ni PoC pública». [proof-of-concept] El código existe.»
Dicho esto, actualmente no hay detalles disponibles sobre cómo se está explotando la falla de seguridad, quién está detrás de ella y si es parte de una campaña oportunista o dirigida más amplia dirigida a sistemas sin parches.
A fines del año pasado, actores de amenazas vinculados a la operación de ransomware Cl0p utilizaron otra falla crítica en el mismo producto (CVE-2025-61882, puntuación CVSS: 9.8), y los primeros ataques se lanzaron ya en agosto de 2025.
A principios de este mes, la compañía abordó una vulnerabilidad crítica de día cero de autenticación faltante en PeopleSoft Suite (CVE-2026-35273, puntuación CVSS: 9.8) que fue explotada activamente en ataques de extorsión y robo de datos de ShinyHunters.
Desde entonces, el fabricante de automóviles Nissan admitido que estaba entre los afectados, afirmando que fue víctima de un robo que implicó la explotación de la falla de PeopleSoft, potencialmente exponiendo registros de nómina, datos bancarios, números de Seguro Social y otros datos personales y financieros que pertenecen a sus empleados en EE. UU., Canadá, México y Brasil.
«Lo que destacó fue que CVE-2026-35273 no es simplemente otra vulnerabilidad trivial y fácil de explotar de una sola solicitud», dijo en un comunicado Jake Knott, investigador principal de seguridad de watchTowr. «La cadena de ataque es considerablemente más complicada, ya que combina múltiples vulnerabilidades para colocar un archivo malicioso que no se ejecuta inmediatamente sino que espera hasta que el servidor se reinicie».
«Donde normalmente veríamos errores simples, se trata de una cadena de múltiples vulnerabilidades, lo que sugiere un actor de amenazas con conocimiento y familiaridad genuinos con el código base subyacente, y la capacidad de desarrollar capacidades específicas contra él».
Knott también señaló que los actores de amenazas están explotando las vulnerabilidades más rápido que nunca, instando a las organizaciones a asumir compromisos y activar procesos de respuesta a incidentes para determinar si se obtuvo acceso antes de que se aplicaran los parches, a qué se accedió y si se estableció la persistencia.
Google ha publicado actualizaciones de seguridad para abordar 74 vulnerabilidades, incluida una que ha sido objeto de explotación activa en la naturaleza.
La vulnerabilidad de alta gravedad, rastreada como CVE-2026-11645 (Puntuación CVSS: 8,8), se ha descrito como un acceso a memoria fuera de los límites en V8, el motor JavaScript y WebAssembly de Chrome.
«La lectura y escritura fuera de límites en V8 en Google Chrome anterior a 149.0.7827.103 permitía a un atacante remoto ejecutar código arbitrario dentro de una zona de pruebas a través de una página HTML diseñada», se lee en un descripción de la falla en la Base de Datos Nacional de Vulnerabilidad (NVD) del NIST.
A un investigador de seguridad llamado «303f06e3» se le atribuye el descubrimiento y el informe de la falla el 27 de abril de 2026. El investigador recibió una recompensa de 55.000 dólares por la divulgación responsable.
Como es habitual en estos casos, Google reconoció que «existe un exploit para CVE-2026-11645», pero no compartió detalles adicionales para garantizar que la mayoría de los usuarios estén actualizados con una solución y evitar una mayor explotación.
Con el último desarrollo, Google ha abordado un total de cinco días cero de Chrome explotados activamente desde principios de año. Esto incluye CVE-2026-2441, CVE-2026-3909, CVE-2026-3910 y CVE-2026-5281.
Para una protección óptima, se recomienda a los usuarios actualizar su navegador Chrome a las versiones 149.0.7827.102/.103 para Windows y Apple macOS, y 149.0.7827.102 para Linux. Para asegurarse de que estén instaladas las últimas actualizaciones, los usuarios pueden navegar a Más > Ayuda > Acerca de Google Chrome y seleccionar Reiniciar.
También se recomienda a los usuarios de otros navegadores basados en Chromium, como Microsoft Edge, Brave, Opera y Vivaldi, que apliquen las correcciones cuando estén disponibles.
La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) el lunes agregado una falla de alta gravedad que afecta a BerriAI LiteLLM a sus vulnerabilidades explotadas conocidas (KEV) catálogo, citando evidencia de explotación activa.
La vulnerabilidad, rastreada como CVE-2026-42271 (Puntuación CVSS: 8,7) es una vulnerabilidad de inyección de comandos que podría permitir a cualquier usuario autenticado ejecutar comandos arbitrarios en el host.
Afecta a la siguiente versión del paquete LiteLLM Python:
«Dos puntos finales utilizados para obtener una vista previa de un servidor MCP antes de guardarlo – POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list – aceptaron una configuración completa del servidor en el cuerpo de la solicitud, incluidos los campos comando, args y env utilizados por el transporte stdio», según un descripción del defecto compartido por BerriAI.
«Cuando se les llamó con una configuración stdio, los puntos finales intentaron conectarse, lo que generó el comando proporcionado como un subproceso en el host proxy con los privilegios del proceso proxy».
Los mantenedores de la puerta de enlace AI de código abierto y el SDK de Python dijeron que los puntos finales estaban protegidos solo por medio de una clave API proxy válida, como resultado de lo cual cualquier usuario autenticado, incluidas las claves de usuario interno privilegiado, podría ejecutar comandos arbitrarios en un sistema susceptible.
Como parte de los parches lanzados en la versión 1.83.7, ambos puntos finales de prueba ahora requieren la función PROXY_ADMIN, lo que lo hace coherente con el punto final de guardado.
LiteLLM Ejecución remota de código no autenticado a través de la omisión de validación del encabezado del host Starlette
La semana pasada, Horizon3.ai dijo que encadenó CVE-2026-42271 con CVE-2026-48710 (Puntuación CVSS: 6,5), un «Mal anfitrión» Vulnerabilidad de omisión de validación del encabezado del host que afecta estrellaun marco liviano de interfaz de puerta de enlace de servidor asíncrono (ASGI), para eludir por completo la autenticación y lograr la ejecución remota de código contra implementaciones vulnerables de LiteLLM.
«CVE-2026-48710 se puede utilizar para omitir completamente el mecanismo de autenticación en implementaciones LiteLLM cuyo árbol de dependencia incluya versiones de Starlette ≤ 1.0.0», Horizon3.ai dicho. «Esto transforma la vulnerabilidad en una ejecución remota de código no autenticado sin necesidad de credenciales».
La utilización exitosa de la cadena de exploits como arma podría permitir a los atacantes ejecutar comandos arbitrarios en el host LiteLLM, acceder a las credenciales del proveedor del modelo, desviar claves API y secretos almacenados por el proxy, moverse lateralmente a la infraestructura de IA conectada e incluso comprometer los sistemas posteriores integrados con la puerta de enlace.
Según Horizon3.ai, la vulnerabilidad encadenada tiene una puntuación CVSS combinada de 10,0, lo que la hace crítica por naturaleza.
Actualmente no hay información sobre cómo se está explotando la vulnerabilidad, la identidad de los actores de amenazas detrás de los esfuerzos, quiénes son el objetivo, qué tan extendidos están estos ataques o si la actividad ha comprometido con éxito alguna instancia. Tampoco está claro si los ataques observados en la naturaleza están aprovechando la cadena de explotación.
Se recomienda a los usuarios actualizar LiteLLM a la versión 1.83.7 o posterior y Starlette a la versión 1.0.1 o posterior. Si la aplicación inmediata de parches no es una opción, se recomiendan las siguientes mitigaciones:
Bloquee POST /mcp-rest/test/connection y POST /mcp-rest/test/tools/list en el proxy inverso o la puerta de enlace API.
Restrinja el acceso a la red a segmentos confiables.
Rotar las credenciales almacenadas por el proxy.
Revise los registros para detectar actividades inusuales en el encabezado del host y eventos de ejecución de subprocesos.
El desarrollo se produce poco más de un mes después de que una falla crítica de inyección SQL en LiteLLM (CVE-2026-42208, puntuación CVSS: 9.3) fuera explotada activamente dentro de las 36 horas posteriores a que el error se hiciera público.
Una falla de seguridad recientemente revelada que afecta a NGINX Plus y NGINX Open ha sido explotada activamente en la naturaleza, días después de su divulgación pública, según VulnCheck.
La vulnerabilidad, rastreada como CVE-2026-42945 (puntaje CVSS: 9.2), es un desbordamiento del búfer de montón en ngx_http_rewrite_module que afecta las versiones de NGINX 0.6.27 a 1.30.0. Según Depthfirst, la empresa de seguridad nativa de IA, la vulnerabilidad se introdujo en 2008.
La explotación exitosa de la falla puede permitir que un atacante no autenticado bloquee los procesos de trabajo o ejecute código remoto con solicitudes HTTP manipuladas. Sin embargo, cabe señalar que la ejecución de código solo es posible en dispositivos donde la aleatorización del diseño del espacio de direcciones (ASLR), una protección contra ataques basados en memoria, está desactivada.
«Se basa en que una configuración NGINX específica sea vulnerable y que un atacante conozca o descubra la configuración para explotarla», dijo el investigador de seguridad Kevin Beaumont. dicho. «Para llegar a RCE [remote code execution]también es necesario que ASLR esté desactivado en la casilla».
En una evaluación similar, los mantenedores de AlmaLinux dicho: «Convertir el desbordamiento del montón en una ejecución confiable de código no es trivial en la configuración predeterminada, y en sistemas con ASLR habilitado (que es el valor predeterminado en todas las versiones compatibles de AlmaLinux), no esperamos que un exploit genérico y confiable sea fácil de producir».
«Dicho esto, ‘no es fácil’ no es ‘imposible’, y el DoS por accidente de trabajo es lo suficientemente explotable por sí solo como para recomendar tratar esto como urgente», agregaron los mantenedores.
Los últimos hallazgos de VulnCheck muestran que los actores de amenazas han comenzado a convertir la falla en un arma, y se detectaron intentos de explotación contra sus redes honeypot. Actualmente se desconocen la naturaleza de la actividad de ataque y los objetivos finales. Se recomienda a los usuarios que apliquen las últimas correcciones de F5 para proteger sus redes contra amenazas activas.
También se explotan fallos en openDCIM
El desarrollo se produce cuando VulnCheck también reveló esfuerzos de explotación dirigidos a dos fallas críticas en openDCIM, una aplicación de código abierto utilizada para la gestión de infraestructura de centros de datos. Las vulnerabilidades, ambas con una calificación de 9,3 en el sistema de puntuación CVSS, se enumeran a continuación:
CVE-2026-28515 – Una vulnerabilidad de autorización faltante que podría permitir a un usuario autenticado acceder a la funcionalidad de configuración LDAP independientemente de sus privilegios asignados. En implementaciones de Docker donde REMOTE_USER está configurado sin aplicación de autenticación, se puede acceder al punto final sin credenciales, lo que permite modificaciones no autorizadas de la configuración de la aplicación.
CVE-2026-28517 – Una vulnerabilidad de inyección de comandos del sistema operativo que afecta al componente «report_network_map.php» que procesa un parámetro llamado «punto» sin desinfección y lo pasa directamente a un comando de shell, lo que resulta en la ejecución de código arbitrario.
Las dos vulnerabilidades fueron descubierto junto a CVE-2026-28516 (Puntuación CVSS: 9,3), una vulnerabilidad de inyección SQL en openDCIM, realizada por el investigador de seguridad de VulnCheck Valentin Lobstein en febrero de 2026. Según Lobstein, las tres fallas se pueden encadenar para lograr la ejecución remota de código en cinco solicitudes HTTP y generar un shell inverso.
«El grupo de actividad de atacantes que estamos observando hasta ahora se origina en una única IP china y utiliza lo que parece ser una implementación personalizada de la herramienta de descubrimiento de vulnerabilidades de IA Vulnhuntr para comprobar automáticamente si hay instalaciones vulnerables antes de soltar un shell web PHP», Caitlin Condon, vicepresidenta de investigación de seguridad de VulnCheck, dicho.
Los atacantes están explotando activamente una vulnerabilidad de día cero que afecta los firewalls de algunos clientes de Palo Alto Networks, dijo el proveedor de seguridad en un consultivo Martes.
La vulnerabilidad crítica de corrupción de memoria: CVE-2026-0300 — afecta el portal de autenticación de PAN-OS y permite a atacantes no autenticados ejecutar código con privilegios de root en los firewalls PA-Series y VM-Series del proveedor, dijo la compañía.
Palo Alto Networks no dijo cuándo ni cómo tuvo conocimiento de la explotación activa, ni cuándo ocurrió la primera explotación conocida. La Agencia de Seguridad de Infraestructura y Ciberseguridad añadió el defecto a su catálogo de vulnerabilidades explotadas conocidas Miércoles.
La compañía no ha lanzado un parche para la vulnerabilidad ni ha descrito el alcance y el objetivo de los ataques confirmados.
«Esta vulnerabilidad es específica de un número limitado de clientes con su Portal de autenticación de ID de usuario (Portal cautivo) expuesto a la Internet pública o a direcciones IP que no son de confianza. Hemos observado una explotación limitada de este problema y estamos trabajando para publicar correcciones de software, y se espera que las primeras actualizaciones estén disponibles el 13 de mayo», dijo un portavoz de Palo Alto Networks a CyberScoop.
La compañía dijo que los firewalls expuestos a la vulnerabilidad de desbordamiento del búfer, que tiene una calificación CVSS de 9,3, están ampliamente expuestos en implementaciones del mundo real, y describió la complejidad del ataque como baja.
Los escaneos de Shadowserver encontraron más de 5.800 cortafuegos de la serie VM expuestos públicamente ejecutando PAN-OS a partir del martes, sin embargo, se desconoce cuántas de esas instancias han restringido el acceso de autenticación a direcciones IP internas confiables o han desactivado la función por completo.
«Hemos proporcionado una guía de mitigación clara a nuestros clientes para proteger sus entornos de inmediato. Este problema no afecta a los dispositivos Cloud NGFW o Panorama. Seguimos comprometidos con un enfoque transparente que priorice la seguridad para proteger nuestra base global de clientes», agregó el portavoz de Palo Alto Networks.
Benjamin Harris, director ejecutivo y fundador de watchTowr, señaló que Palo Alto Networks alertó proactivamente a los clientes sobre el día cero, un paso que permitió a los defensores tomar medidas en instancias potencialmente expuestas.
«En una mala situación, eso es lo mejor que pueden hacer de inmediato. Sin embargo, eso también alerta a todos sobre la existencia de una vulnerabilidad», dijo a CyberScoop.
A pesar del riesgo, Harris dijo que watchTowr espera que los ataques vinculados al exploit de día cero sean «muy limitados».
Palo Alto Networks y sus clientes afectados siguen siendo los únicos que han observado explotación en la naturaleza, pero los investigadores advierten que eso probablemente cambiará pronto.
«Es probable que las reglas también comiencen a aplicarse en organizaciones de terceros y honeypots en breve», dijo a CyberScoop Caitlin Condon, vicepresidenta de investigación de seguridad de VulnCheck.
“Las interfaces de gestión, las páginas de inicio de sesión y los portales de autenticación han sido objetivos comunes de las campañas oportunistas y específicas en los últimos años”, añadió. «Con los ojos de los investigadores y la comunidad puestos en la vulnerabilidad, es probable que veamos exploits públicos y una explotación más amplia rápidamente, siempre que el problema no sea prohibitivamente difícil de explotar».
Palo Alto Networks aún tiene que atribuir los ataques a ningún grupo de amenazas conocido, publicar indicadores o compromisos, ni revelar el tipo de organizaciones que han sido atacadas y afectadas.
Los investigadores están buscando actividad maliciosa y aconsejan a los clientes que apliquen parches una vez lanzados.
Según investigadores de seguridad y proveedores de hosting, una grave vulnerabilidad de omisión de autenticación en cPanel, una de las plataformas de panel de control de alojamiento web más implementadas en Internet, está siendo explotada activamente en la naturaleza.
La vulnerabilidad, rastreada como CVE-2026-41940afecta a todas las versiones compatibles de cPanel y WebHost Manager (WHM) lanzadas después de la versión 11.40, así como a WP al cuadradoun panel de gestión de alojamiento de WordPress integrado en la plataforma cPanel. Escaneos de Internet realizados por la empresa de seguridad Rapid7 utilizando el motor de búsqueda Shodan identificados aproximadamente 1,5 millones Instancias de cPanel expuestas en línea, aunque se desconoce el número exacto de sistemas vulnerables.
cPanel lanzó un parche Martes. En ese momento, la explotación ya había comenzado. KnownHost, un proveedor de hosting que depende de cPanel, dijo a principios de esta semana que se habían observado exploits exitosos en la naturaleza antes de que cualquier solución estuviera disponible.
La Agencia de Seguridad de Infraestructura y Ciberseguridad agregó el CVE a su lista de vulnerabilidades explotadas conocidas (KEV) el jueves.
La empresa de ciberseguridad watchTowr proporcionó detalles técnicos en un blog publicado el miércoles: La falla surge del manejo inadecuado de la entrada del usuario durante el proceso de inicio de sesión. Cuando un usuario intenta iniciar sesión, cPanel escribe los datos de la solicitud en un archivo de sesión del lado del servidor antes de verificar la identidad del usuario. Un atacante puede aprovechar esto incorporando saltos de línea ocultos en el campo de contraseña de una solicitud de inicio de sesión (caracteres que cPanel no puede eliminar), lo que permite inyectar datos arbitrarios directamente en ese archivo.
A través de un paso secundario, que también involucra una solicitud deliberadamente mal formada, los datos inyectados se promueven al caché activo de la sesión, donde cPanel los lee como legítimos. Una vez que eso sucede, el sistema considera que la sesión ya está autenticada y omite por completo la verificación de la contraseña, otorgando acceso sin verificar las credenciales reales del usuario.
Panel c ha publicado un script de detección diseñado para escanear archivos de sesión en busca de indicadores de compromiso, incluidas sesiones que contienen marcas de tiempo de autenticación inyectadas, sesiones de autenticación previa con atributos autenticados y campos de contraseña que contienen nuevas líneas incrustadas. WatchTowr lanzado por separado un «generador de artefactos de detección» que los administradores pueden utilizar para verificar si sus instancias siguen siendo vulnerables.
Namecheap, un importante registrador de dominios y proveedor de alojamiento, tomó la medida de bloquear temporalmente las conexiones a los puertos 2083 y 2087 de cPanel y WHM antes de la disponibilidad del parche. citando la necesidad de proteger a los clientes mientras estaba pendiente una solución oficial. La compañía comenzó a aplicar el parche después del lanzamiento de cPanel a principios de esta semana.
Las versiones parcheadas de cPanel abordan el problema en siete ramas de versiones, desde 11.110.0 hasta 11.136.0, así como en la versión 11.136.1 de WP Squared. Las notas informativas de la empresa. que la solución garantiza que las entradas potencialmente peligrosas se eliminen automáticamente dentro del proceso principal de guardado de sesiones, en lugar de depender de que cada parte individual del código base lo haga por separado. El parche también agrega manejo para los casos en los que falta una clave de cifrado por sesión, una condición que el código original no tuvo en cuenta y que los atacantes pudieron aprovechar para evitar por completo la codificación de contraseñas.
Un ciberataque que afirmó un grupo de hackers iraní se llevó a cabo contra el fabricante de dispositivos médicos Stryker podría marcar la primera acción cibernética significativa de Teherán desde el inicio del conflicto conjunto entre Estados Unidos e Israel.
Pero incluso eso puede haber sido un feliz accidente para los piratas informáticos iraníes en lo que ha sido un bajo nivel de actividad durante ese período de tiempo, con los atacantes obteniendo ganancias por casualidad y no a propósito.
Las empresas de ciberseguridad, los rastreadores de inteligencia de amenazas y los propietarios de infraestructuras críticas han estado luchando para separar el ruido sobre los ataques proclamados desde Irán y las advertencias y amenazas relacionadas con el conflicto, de lo que realmente está sucediendo y representa un peligro significativo.
“Todo el mundo está luchando en este momento”, dijo Alex Orleans, analista de amenazas de Irán desde hace mucho tiempo y jefe de inteligencia de amenazas de Sublime Security. Otros dijeron que la naturaleza incipiente del conflicto dificulta las evaluaciones.
«Lo que vemos es bastante difícil de cuantificar o caracterizar sobre si ha habido un aumento o una disminución», dijo Saher Naumaan, investigador senior de amenazas en Proofpoint. «Creo que como solo llevamos un par de semanas en el conflicto y la cadencia regular de los actores iraníes no es muy consistente, necesariamente no tenemos suficientes datos ni suficiente tiempo para juzgar realmente».
Signos de actividad
En los primeros días del conflicto, hubo indicios de que ataques fisicos sobre Irán podría haber obstaculizado los esfuerzos de represalia iraníes u otras actividades cibernéticas, ya que aquellos que llevarían a cabo ataques cibernéticos probablemente estaban «escondidos en búnkeres», dijo Orleans, y como Irán sufrió cortes de internet.
Sin embargo, en los últimos días, el ataque Stryker y otros indicadores sugieren que la actividad cibernética iraní podría estar calentándose.
«Durante varios días después del estallido del conflicto, se notó una disminución en la actividad de amenazas cibernéticas provenientes de Irán», dijo un grupo de centros de análisis e intercambio de información de la industria. advirtió el miércoles. «Sin embargo, hay señales de vida en las operaciones cibernéticas ofensivas iraníes».
El ataque de Stryker destaca tanto por el tamaño como por la ubicación del objetivo, un fabricante de dispositivos médicos con sede en Michigan con más de 25 mil millones de dólares en ingresos en 2025.
Pero tanto Orleans como Sergey Shykevich, gerente del grupo de inteligencia de amenazas en Check Point Research, dijeron que el ataque tiene las características de ser oportunista en lugar de uno deliberado y enfocado. El grupo que se atribuye el mérito del ataque, Handala, un equipo vinculado al Ministerio de Inteligencia, es más conocido por aprovechar las debilidades que encuentra en lugar de hacerlo. persiguiendo obstinadamente objetivos particulares.
En particular, Stryker también es la clase de vehículo militar utilizado por las fuerzas estadounidenses. Esa conexión militar, incluso si se confunde con el fabricante de dispositivos médicos, posiblemente podría explicar por qué la empresa era un objetivo.
Aún así, “fue un ataque de mucho mayor perfil de lo que esperábamos de Handala”, dijo Shykevich. «Desafortunadamente, se puede definir como un éxito relativamente grande para ellos».
Ha habido informes de otras actividades cibernéticas que podrían estar relacionadas con el conflicto. Albania dijo el sistema de correo electrónico de su parlamento había sido atacado, y los piratas informáticos iraníes se habían atribuido el mérito. Estaba el orientación de cámaras de infraestructura vinculada a Irán en países a los que Irán luego lanzó misiles. Polonia dijo que era mirando hacia si Irán estuvo detrás de un intento de ciberataque a una instalación de investigación nuclear.
Algunas de las afirmaciones no coinciden con la realidad. «Hay muchos grupos hacktivistas que son muy activos en Telegram, pero en realidad no tienen ningún éxito significativo», dijo Shykevich.
También hay otros acontecimientos relacionados con la cibernética en el conflicto, como el espionajela proliferación de desinformación impulsada por la inteligencia artificial y la posibilidad de que Rusia o China ayudando en el ciberespacio en nombre de Irán, incluso si algunos expertos dudan de la probabilidad de que esto último ocurra.
Aún no está claro qué tan efectivo ha sido todo esto. Stryker, por ejemplo, dijo el ataque afectó principalmente a sus redes internas, aunque había señales También podría estar afectando las comunicaciones en los hospitales.
Pero el daño podría no venir al caso. Orleans dijo que los ataques podrían ser de naturaleza psicológica, destinados a producir miedo en el extranjero y afirmar la posición de los piratas informáticos ante los líderes nacionales en Irán durante el conflicto.
Incluso la desfiguración de bajo nivel o los ataques distribuidos de denegación de servicio pueden influir.
“Llegar al trabajo y encontrar una bandera iraní en su estación de trabajo sería un poco desconcertante, porque le hacen saber que 'puedo extender la mano y tocarlo'”, dijo Sarah Cleveland, directora senior de estrategia federal en ExtraHop y ex oficial cibernética de la Fuerza Aérea de EE. UU.
Posibles impactos posteriores
Si bien se la conoce principalmente como una empresa de suministros médicos, Stryker ha recibido contratos importantes con el ejército para equipos hospitalarios y suministros quirúrgicos, por ejemplo. No está claro si los piratas informáticos pretendían utilizar la conexión militar de Stryker para explotar los sistemas gubernamentales.
El Pentágono tiene advertido durante mucho tiempo de ciberataques cada vez mayores y complejos contra la base industrial de defensa, una vasta red de empresas -con niveles dispares de ciberseguridad- de las que depende el ejército para obtener desde armamento avanzado hasta camillas básicas. El DIB es a menudo visto por los adversarios como puerta trasera a los sistemas militares.
Si bien no abordó directamente el hackeo de Stryker, el principal asesor cibernético del Ejército, Brandon Pugh, describió algunos de los desafíos que enfrenta el DIB y la parte del servicio al tratar de protegerlo durante un seminario web el jueves en respuesta a una pregunta sobre el tema.
Dijo que los adversarios, «con razón o sin ella», ven a las empresas «como una extensión del ejército» y creen que un ataque a la industria privada tendría un impacto secundario en las fuerzas armadas.
«Algunas son empresas multinacionales muy grandes y sofisticadas», dijo, señalando que las necesidades de seguridad en todo el DIB no son universales. «Otras son empresas muy pequeñas que tienen suerte de tener un director de TI, y mucho menos un equipo cibernético sofisticado, y creo que ahí es donde es realmente importante apoyarse».
Pugh dijo que agencias de todo el gobierno federal han estado trabajando con el DIB para aumentar su resistencia a los ataques, y que el esfuerzo cibernético del Ejército enfatiza afianzar la ciberseguridad desde el comienzo del proceso de adquisición.
«Lo cibernético no puede ser una ocurrencia tardía, no digo que lo sea», añadió Pugh. “Yo diría que el Ejército hace un gran trabajo aquí, pero asegurándose de que nunca se olvide y siempre se lo considere de esa manera”.
Matt Tait, director ejecutivo y presidente de MANTECH, dijo en respuesta a una pregunta sobre el ataque Stryker y las protecciones DIB que defenderse contra tales incidentes incluye aprovechar los acuerdos y el acceso gubernamentales, como con la NSA, y compartir información rápidamente después de un ataque.
«Para mí, se trata de compartir información en tiempo real», dijo. “Cuando te atacan, necesitas compartir información en tiempo real para poder compartir esa información con el resto de la industria, así como con el gobierno, porque ellos pueden compartir esa información entre” entidades federales de ciberseguridad.
«Si quieres realizar un trabajo tecnológico centrado en una misión, este es el mundo en el que tienes que vivir y deberías compartir esta información en tiempo real», añadió. «24 horas después, 48 horas después, llamo a esa ambulancia que me persigue. Eso es demasiado posterior al hecho desde una perspectiva cibernética».
