La Agencia de Seguridad de Infraestructura y Ciberseguridad insta a los propietarios y operadores de infraestructuras críticas a planificar la prestación de servicios esenciales en condiciones de emergencia, potencialmente durante meses seguidos.

La principal agencia de ciberseguridad del gobierno federal advirtió que los piratas informáticos patrocinados por el estado, en particular dos grupos chinos conocidos como Salt Typhoon y Volt Typhoon, continúan amenazando sectores críticos como la electricidad, el agua e Internet.

La agencia ahora está trabajando con el sector privado para proteger la tecnología operativa (los sistemas que controlan la maquinaria pesada y el equipo que alimenta la infraestructura más crítica) de ataques que ingresan a través de sistemas de TI comerciales o productos de proveedores externos.

La iniciativa conocido como CI Fortify – incluirá que CISA realice evaluaciones técnicas específicas de entidades de infraestructura crítica y tiene como objetivo crear planes que “permitan operaciones seguras durante semanas o meses mientras están aislados” de redes de TI y herramientas de terceros, según el sitio web de la agencia.

Nick Andersen, director interino de CISA, dijo a los periodistas que el objetivo es «la prestación de servicios [that] aún puede llegar a la infraestructura crítica después de que el propietario del activo se haya desconectado de TI y OT, de proveedores externos y conexiones de proveedores de servicios y de equipos de telecomunicaciones de terceros”.

En los últimos dos años, las guerras en Ucrania, Gaza, Irán y otros lugares han visto plantas acuáticas, subestaciones eléctricas, centros de datos y otras infraestructuras críticas dirigido por cinéticos o ciberataques.

Andersen dijo que la agencia ya ha comenzado a colaborar con algunas empresas para poner a prueba las evaluaciones y espera que el trabajo aumente considerablemente a medida que CISA contrate personal adicional en los próximos meses.

Se negó a nombrar las entidades involucradas en el programa piloto, pero dijo que se centrarán en organizaciones que apoyan la seguridad nacional, la defensa, la salud y seguridad públicas y la continuidad económica. Añadió que las evaluaciones de CISA variarán de un sector a otro dependiendo de sus necesidades únicas.

«El agua no está necesariamente diseñada para priorizar las necesidades específicas de los clientes fuera de los períodos de recuperación, mientras que la energía y el transporte tienen compensaciones más inmediatas al seleccionar una carga o un conjunto de carga sobre otro», dijo Andersen como ejemplo.

Un pilar de la estrategia de CISA es el aislamiento: esencialmente apagar todas las conexiones de redes comerciales y de terceros a una red OT cuando se enfrenta una emergencia o una vulnerabilidad desconocida.

Las organizaciones también necesitan desarrollar un plan interno sobre cómo serían los niveles de servicio aceptables en esas condiciones y llegar a entendimientos con sus clientes críticos, como las instalaciones militares de EE. UU. y los servicios de salvamento.

El segundo pilar, la recuperación, implica las mejores prácticas para las organizaciones: realizar copias de seguridad de archivos, documentar sistemas y realizar copias de seguridad manuales para las operaciones cuando los sistemas informáticos normales no funcionan.

En conversaciones con especialistas en ciberseguridad que se centran en infraestructura crítica y tecnología operativa, se supone ampliamente que China no es la única nación que ha comprometido ampliamente la infraestructura crítica de los estadounidenses. Que es casi seguro que los grupos de hackers vinculados a otras naciones hayan notado y explotado las mismas vulnerabilidades básicas y problemas de higiene encontrados por los tifones.

Agencias como el FBI y la Comisión Federal de Comunicaciones han promocionado esfuerzos para purgar a los piratas informáticos chinos y trabajar voluntariamente con las empresas de telecomunicaciones para reforzar la seguridad de sus redes. Pero los funcionarios de seguridad nacional y los defensores de la ciberseguridad de EE. UU. han dicho constantemente que tanto Salt Typhoon como Volt Typhoon siguen siendo amenazas activas para la infraestructura crítica de EE. UU.

La Agencia de Seguridad de Infraestructura y Ciberseguridad ha obtenido “con diferencia” los mayores beneficios de la automatización de la inteligencia artificial en su unidad de operaciones de seguridad para ayudar a los analistas a examinar las amenazas, pero también ha demostrado ser valiosa en otras partes de la agencia, dijeron funcionarios de CISA el martes.

«Realmente está permitiendo a esos analistas realizar una clasificación muy rápidamente, de modo que se concentren en lo que importa versus el ruido», dijo Tammy Barbour, jefa interina de gestión de aplicaciones en CISA. «Son capaces de realizar muchas miradas rápidas en tiempo real antes de que ocurran eventos en la mayoría de los lugares».

Barbour, hablando en el Evento UiPath FUSION Sector Público organizado por Scoop News Group, dijo que la automatización también ha sido una gran ayuda para el Centro de Operaciones Tecnológicas de CISA.

«Los mejores analistas pueden responder rápidamente a los clientes que se acercan para hablar y hacer preguntas, y pueden obtener eficiencias en tiempo real con eso», dijo.

Y ha sido de gran ayuda para la migración de datos, afirmó Barbour.

Lauren Wind, subdirectora interina de tecnología de CISA, dijo que desde su ala del departamento, se centra en encontrar beneficios de la automatización en áreas como recursos humanos, contratación y finanzas.

“De modo que podemos seguir impulsando la misión, pero también acelerar las funciones de apoyo a la misión”, dijo. «Realmente queremos asegurarnos de que nuestros analistas cibernéticos se centren en las cosas que importan, como el malware».

Pero existen algunas barreras para la adopción de la tecnología, dijeron ambos.

«Todavía estamos en nuestra infancia», dijo Barbour. «Pero todavía luchamos con los flujos de trabajo y procesos heredados. Todavía tenemos algunos sistemas que deben modernizarse, y actualmente estamos trabajando para adoptarlos. A la gente le encantan sus hojas de cálculo. Simplemente no puedo quitárselas de las manos, especialmente… lo siento, todos los contadores presentes, les pido disculpas, pero tienen que dejarlo pasar».

La gobernanza de la IA también debe establecerse con antelación y de forma transparente, afirmó Wind.

«Una de las cosas más importantes es garantizar que el CTO impulse la gobernanza, ya sea para datos o para IA», dijo. «Creo que somos bastante buenos en generativo y todo el mundo se está poniendo al día con la industria en materia de agentes».

Cómo manejar los datos es otra consideración, dijo Wind.

«Ya sea que esté en la nube y sin servidor o todavía en las instalaciones, si no ha descubierto cómo es la estructura de su plataforma de datos, la automatización es mucho más difícil», dijo.

Los comentarios de Barbour y Wind ofrecieron una ventana a cómo CISA ve la IA internamente. Gran parte del trabajo reciente de la agencia relacionado con la IA se centra en asesorar para el despliegue seguro de IA agente en otras organizaciones, o en examinar la forma en que se utiliza la IA. amenazas cada vez más profundas.

Un ataque a la cadena de suministro recientemente identificado dirigido al software DAEMON Tools ha comprometido a sus instaladores para entregar una carga útil maliciosa, según los hallazgos de Kaspersky.

«Estos instaladores se distribuyen desde el sitio web legítimo de DAEMON Tools y están firmados con certificados digitales pertenecientes a los desarrolladores de DAEMON Tools», dijeron los investigadores de Kaspersky Igor Kuznetsov, Georgy Kucherin, Leonid Bezvershenko y Anton Kargin. dicho.

Los instaladores han sido troyanizados desde el 8 de abril de 2026, con versiones que van desde 12.5.0.2421 a 12.5.0.2434 identificadas como comprometidas como parte del incidente. El ataque a la cadena de suministro está activo al momento de escribir este artículo. AVB Disc Soft, el desarrollador del software, ha sido notificado de la infracción.

Específicamente, se han manipulado tres componentes diferentes de DAEMON Tools:

• DTHelper.exe
• DiscSoftBusServiceLite.exe
• DTShellHlp.exe

Cada vez que se inicia uno de estos binarios, lo que suele ocurrir durante el inicio del sistema, se activa un implante en el host comprometido. Está diseñado para enviar una solicitud HTTP GET a un servidor externo («env-check.daemontools[.]cc»), un dominio registrado el 27 de marzo de 2026, para recibir un comando de shell que se ejecuta mediante el proceso «cmd.exe».

El comando shell, por su parte, se utiliza para descargar y ejecutar una serie de cargas útiles ejecutables. Estos incluyen –

• envchk.exe, un ejecutable .NET para recopilar amplia información del sistema.
• cdg.exe y cdg.tmp, el primero de los cuales es un cargador de shellcode responsable de descifrar el contenido del segundo archivo y abrir una puerta trasera minimalista que contacta a un servidor remoto para descargar archivos, ejecutar comandos de shell y ejecutar cargas útiles de shellcode en la memoria.

La empresa rusa de ciberseguridad dijo que observó varios miles de intentos de infección que involucraban herramientas DAEMON en su telemetría, lo que afectó a personas y organizaciones en más de 100 países, como Rusia, Brasil, Turquía, España, Alemania, Francia, Italia y China. Sin embargo, la puerta trasera de la siguiente etapa se entregó solo a una docena de hosts, lo que indica un enfoque específico.

Los sistemas que recibieron el siguiente malware han sido marcados como pertenecientes a organizaciones minoristas, científicas, gubernamentales y de fabricación en Rusia, Bielorrusia y Tailandia. Es más, una de las cargas útiles entregadas a través de la puerta trasera es un troyano de acceso remoto denominado QUIC RAT. El uso del implante C++ se ha registrado contra una única víctima: una institución educativa ubicada en Rusia.

«Esta forma de implementar la puerta trasera en un pequeño subconjunto de máquinas infectadas indica claramente que el atacante tenía intenciones de llevar a cabo la infección de manera específica», dijo Kaspersky. «Sin embargo, su intención, ya sea ciberespionaje o ‘caza mayor’, no está clara actualmente».

El malware admite una variedad de protocolos de comando y control (C2), incluidos HTTP, UDP, TCP, WSS, QUIC, DNS y HTTP/3, y viene equipado con capacidades para inyectar cargas útiles en procesos legítimos «notepad.exe» y «conhost.exe».

La actividad no se ha atribuido a ningún actor o grupo de amenazas conocido. Pero la evidencia apunta a que es obra de un adversario de habla china según un análisis de los artefactos observados.

El compromiso de DAEMON Tools es el último de una lista cada vez mayor de incidentes en la cadena de suministro de software en la primera mitad de 2026, y sigue a violaciones similares de alto perfil que involucraron a eScan en enero, Notepad++ en febrero y CPUID en abril.

«Un compromiso de esta naturaleza pasa por alto las defensas perimetrales tradicionales porque los usuarios confían implícitamente en el software firmado digitalmente y descargado directamente de un proveedor oficial», dijo Kucherin, investigador senior de seguridad de Kaspersky GReAT, en un comunicado compartido con The Hacker News.

«Debido a esto, el ataque de DAEMON Tools ha pasado desapercibido durante aproximadamente un mes. Este período de tiempo, a su vez, indica que el actor de amenaza detrás de este ataque es sofisticado y tiene capacidades ofensivas avanzadas. Dada la alta complejidad del compromiso, es por lo tanto de suma importancia para las organizaciones aislar las máquinas que tienen instalado el software Daemon Tools, así como realizar barridos de seguridad para evitar una mayor propagación de actividades maliciosas dentro de las redes corporativas».

La Apache Software Foundation (ASF) ha publicado actualizaciones de seguridad para abordar varias vulnerabilidades de seguridad en el servidor HTTP, incluida una vulnerabilidad grave que podría conducir a la ejecución remota de código (RCE).

La vulnerabilidad, rastreada como CVE-2026-23918 (puntuación CVSS: 8,8), ha sido descrito como un caso de «doble RCE libre y posible» en el manejo del protocolo HTTP/2. Este problema afecta al servidor Apache HTTP 2.4.66 y se solucionó en la versión 2.4.67.

El cofundador de Striga.ai, Bartlomiej Dmitruk, y el investigador de ISEC.pl, Stanislaw Strzalkowski, han sido acreditado con el descubrimiento y reporte de la vulnerabilidad.

Cuando se le contactó para hacer comentarios, Dmitruk le dijo a The Hacker News por correo electrónico que la gravedad de CVE-2026-23918 es crítica, ya que puede explotarse para lograr denegación de servicio (DoS) y RCE. Los detalles adicionales de la vulnerabilidad se encuentran a continuación:

CVE-2026-23918 es un doble libre en Apache httpd 2.4.66 mod_http2específicamente en la ruta de limpieza de flujo de h2_mplx.c. El error se activa cuando un cliente envía una trama HTTP/2 HEADERS seguida inmediatamente por RST_STREAM con un código de error distinto de cero en la misma secuencia, antes de que el multiplexor haya registrado la secuencia.

Luego se activan dos devoluciones de llamada nghttp2 en secuencia, on_frame_recv_cb para el RST y on_stream_close_cb para el cierre, y ambos terminan llamando a h2_mplx_c1_client_rst -> m_stream_cleanup, que empuja el mismo puntero h2_stream a la matriz de limpieza spurge dos veces. Cuando c1_purge_streams luego itera spurge y llama a h2_stream_destroy -> apr_pool_destroy en cada entrada, la segunda llamada llega a la memoria que ya ha sido liberada.

El DoS, añadió Dmitruk, es trivial y funciona en cualquier implementación predeterminada con mod_http2 y un MPM multiprocesomientras que la ruta RCE requiere un Apache Portable Runtime (ABR) con el asignador mmap, que es el predeterminado en los sistemas derivados de Debian y en la imagen oficial httpd de Docker. Dmitruk explicó con más detalle:

La primera es la denegación de servicio, que es trivial: una conexión TCP, dos tramas, sin autenticación, sin encabezados especiales, sin una URL específica y el trabajador falla. Apache lo reaparece, pero todas las solicitudes del trabajador bloqueado se descartan y el patrón puede mantenerse mientras el atacante siga enviando.

El segundo resultado es la ejecución remota de código y creamos una prueba de concepto funcional en x86_64. La cadena coloca una estructura h2_stream falsa en la dirección virtual liberada mediante la reutilización de mmap, apunta su función de limpieza del grupo a system() y utiliza la memoria del marcador de Apache como un contenedor estable para las estructuras falsas y la cadena de comando.

El marcador se encuentra en una dirección fija durante toda la vida útil del servidor, incluso con ASLR, que es lo que hace que la ruta RCE sea práctica. Se aplican las advertencias habituales: la explotación práctica requiere una fuga de información para el sistema() y las compensaciones del marcador, y la pulverización del montón es probabilística, pero en condiciones de laboratorio la ejecución se realiza en minutos.

Dmitruk también señaló que el Horquilla MPM no se ve afectado por el defecto. Sin embargo, el investigador advirtió que la superficie de ataque es grande ya que mod_http2 se incluye en versiones predeterminadas y HTTP/2 está ampliamente habilitado en implementaciones de producción. Dada la gravedad de la falla, se recomienda a los usuarios que apliquen las últimas soluciones para una protección óptima.

Un juez federal condenó a un ciudadano letón a 102 meses de prisión por su participación en una serie de ataques de ransomware durante más de dos años antes de su arresto en 2023, dijo el lunes el Departamento de Justicia.

Deniss Zolotarjovs, residente en Moscú en ese momento, ayudó a una organización dirigida por exlíderes del grupo de ransomware Conti a extorsionar a más de 54 empresas.

Al hombre de 35 años le correspondía principalmente presionar a las víctimas de la tripulación. En un caso, Zolotarjovs instó a los cómplices a filtrar o vender registros médicos de niños robados de una empresa de atención médica pediátrica y, en última instancia, envió una recopilación de datos confidenciales a “cientos de pacientes”, según registros judiciales.

El equipo de ransomware se identificó en notas de rescate con varios nombres durante la participación de Zolotarjovs, incluidos Conti, Karakurt, Royal, TommyLeaks, SchoolBoys Ransomware, Akira y otros.

Zolotarjov y sus cómplices extorsionaron a sus víctimas con casi 16 millones de dólares en pagos de rescate confirmados. Las autoridades estiman que los crímenes del grupo resultaron en pérdidas por cientos de millones de dólares, sin incluir la exposición psicológica y financiera futura que enfrentarán decenas de miles de personas cuyos datos personales fueron robados.

«Deniss Zolotarjovs ayudó a su banda de ransomware a beneficiarse de los ataques a docenas de empresas, e incluso a una entidad gubernamental cuyo sistema 911 se vio obligado a desconectarse», dijo en un comunicado A. Tysen Duva, fiscal general adjunto de la División Penal del Departamento de Justicia.

Los funcionarios dijeron que Zolotarjovs buscó puntos de influencia después de investigar las empresas víctimas y analizar los datos robados. Muchas de las víctimas impactadas durante su participación activa entre junio de 2021 y agosto de 2023 estaban radicadas en Estados Unidos.

Zolotarjov fue arrestado en el país de Georgia en diciembre de 2023 y extraditado a Estados Unidos en agosto de 2024. Se declaró culpable de lavado de dinero y fraude electrónico en julio de 2025.

«Los ciberdelincuentes podrían pensar que son invulnerables al esconderse detrás de herramientas de anonimización y patrones complejos de criptomonedas mientras atacan a víctimas estadounidenses de países no extraditados», dijo en un comunicado Dominick S. Gerace II, fiscal estadounidense para el Distrito Sur de Ohio. «Pero el procesamiento de Zolotarjovs demuestra que las autoridades federales también tienen un alcance global, y haremos responsables a los malos actores como Zolotarjovs, que ahora pasarán mucho tiempo en prisión».

El equipo ruso de ransomware fue prolífico y se dividió en varios equipos, confiando en empresas registradas en Rusia, Europa y Estados Unidos para ocultar sus operaciones. Las autoridades dijeron que el grupo incluía a ex agentes de la ley rusos cuyas conexiones permitían a los miembros acceder a bases de datos del gobierno ruso para acosar a detractores e identificar posibles nuevos reclutas.

Conti estuvo durante un tiempo entre los grupos de ransomware más prolíficos a nivel mundial, lo que afectó a cientos de proveedores de infraestructura crítica, al gobierno de Costa Rica en 2022 y, en última instancia, llevó al Departamento de Estado a ofrecer una recompensa de 10 millones de dólares por información relacionada con los líderes de Conti. El grupo fue notoriamente resistente, se recuperó con nueva infraestructura y alcanzó nuevos objetivos después de que una filtración masiva expusiera chats entre los miembros del grupo en 2022.

Conti se disolvió más tarde ese año, pero los miembros del grupo en cirílico cambiaron su nombre a tres subgrupos: Zeon, Black Basta y Quantum, que rápidamente pasó a llamarse Royal, antes de volver a llamarse BlackSuit en 2024.

Un sofisticado grupo de amenaza persistente avanzada (APT) del nexo China se ha atribuido a ataques dirigidos a entidades gubernamentales en América del Sur desde al menos finales de 2024 y a agencias gubernamentales en el sureste de Europa en 2025.

Cisco Talos está rastreando la actividad bajo el nombre de UAT-8302y la post-explotación implica el despliegue de familias de malware personalizadas que han sido utilizadas por otros grupos de hackers alineados con China.

Entre las familias de malware destaca una puerta trasera basada en .NET denominada NetDraft (también conocida como NosyDoor), una variante C# de FINALDRAFT (también conocida como Squidoor) que se ha vinculado anteriormente a grupos de amenazas conocidos como Ink Dragon, CL-STA-0049, Earth Alux, Jewelbug y REF7707.

ESET está rastreando el uso de NosyDoor en un grupo al que llama LongNosedGoblin. Curiosamente, el mismo malware también ha sido implementado contra organizaciones de TI rusas por un actor de amenazas conocido como Erudite Mogwai (también conocido como Space Pirates y Webworm), según la empresa rusa de ciberseguridad Solar, que le ha dado el nombre. Agente de LuckyStrike.

Algunas de las otras herramientas utilizadas por UAT-8302 son las siguientes:

«El malware implementado por UAT-8302 lo conecta con varios grupos de amenazas previamente divulgados públicamente, lo que indica al menos una estrecha relación operativa entre ellos», dijeron los investigadores de Talos Jungsoo An, Asheer Malhotra y Brandon White en un informe técnico publicado hoy.

«En general, los diversos artefactos maliciosos desplegados por UAT-8302 indican que el grupo tiene acceso a herramientas utilizadas por otros actores APT sofisticados, todos los cuales han sido evaluados como nexo con China o de habla china por varios informes de la industria de terceros».

Actualmente no se sabe qué métodos de acceso inicial emplea el adversario para irrumpir en las redes objetivo, pero se sospecha que involucra el enfoque probado de convertir en armas exploits de día cero y día N en aplicaciones web.

Al conseguir un punto de apoyo, se sabe que los atacantes realizan un reconocimiento exhaustivo para trazar un mapa de la red, ejecutan herramientas de código abierto como gogó para realizar escaneos automatizados y moverse lateralmente por el entorno. Las cadenas de ataques culminan con la implementación de NetDraft, CloudSorcerer (versión 3.0) y VShell.

También se ha observado que UAT-8302 utiliza una variante de SNOWLIGHT basada en Rust llamada SNOWRUST para descargar la carga útil de VShell desde un servidor remoto y ejecutarla. Además de utilizar malware personalizado, el actor de amenazas configura medios alternativos de acceso por puerta trasera utilizando herramientas de proxy y VPN como Stowaway y SoftEther VPN.

Los hallazgos subrayan la tendencia de tácticas de colaboración avanzadas entre múltiples grupos alineados con China. En octubre de 2025, Trend Micro arrojó luz sobre un fenómeno llamado «Premier Pass-as-a-Service», donde el acceso inicial obtenido por Earth Estries se pasa a Earth Naga para su posterior explotación, lo que nubla los esfuerzos de desgaste. Se estima que esta asociación existe desde al menos finales de 2023.

«Premier Pass-as-a-Service proporciona acceso directo a activos críticos, reduciendo el tiempo dedicado a las fases de reconocimiento, explotación inicial y movimiento lateral», afirmó Trend Micro. «Aunque aún no se conoce el alcance total de este modelo, el número limitado de incidentes observados, combinado con el riesgo sustancial de exposición que implica un servicio de este tipo, sugiere que el acceso probablemente esté restringido a un pequeño círculo de actores de amenazas».

Los actores de amenazas están explotando activamente una falla de seguridad crítica que afecta a un sistema de gestión de contenidos (CMS) de código abierto conocido como MetInfo, según nuevos hallazgos de VulnCheck.

La vulnerabilidad en cuestión es CVE-2026-29014 (Puntuación CVSS: 9,8), una falla de inyección de código que podría resultar en la ejecución de código arbitrario.

«Las versiones 7.9, 8.0 y 8.1 de MetInfo CMS contienen una vulnerabilidad de inyección de código PHP no autenticado que permite a atacantes remotos ejecutar código arbitrario enviando solicitudes diseñadas con código PHP malicioso», según la Base de datos nacional de vulnerabilidades (NVD) del NIST. estados.

«Los atacantes pueden aprovechar una neutralización de entrada insuficiente en la ruta de ejecución para lograr la ejecución remota del código y obtener control total sobre el servidor afectado».

Según el investigador de seguridad Egidio Romano, quien descubierto Debido a la vulnerabilidad, el problema tiene su origen en el script «/app/system/weixin/include/class/weixinreply.class.php» y surge de una falta de desinfección adecuada de la entrada proporcionada por el usuario al emitir solicitudes de API de Weixin (también conocido como WeChat).

Como resultado, atacantes remotos y no autenticados podrían aprovechar esta laguna para inyectar y ejecutar código PHP arbitrario. Un requisito previo clave para una explotación exitosa cuando MetInfo se ejecuta en servidores que no son Windows es que el directorio «/cache/weixin/» debe existir de antemano. El directorio se crea al instalar y configurar el complemento oficial de WeChat.

Los parches para CVE-2026-29014 fueron liberado por MetInfo el 7 de abril de 2026. Desde entonces, la vulnerabilidad ha estado bajo explotación a partir del 25 de abril, con una «pequeña cantidad de exploits» implementados contra honeypots susceptibles ubicados en los EE. UU. y Singapur.

Aunque estos esfuerzos fueron inicialmente escasos y asociados con sondeos automatizados, la actividad experimentó un aumento el 1 de mayo de 2026, centrándose en las direcciones IP de China y Hong Kong, Caitlin Condon, vicepresidenta de investigación de seguridad de VulnCheck, dicho. Se puede acceder en línea a hasta 2.000 instancias de MetInfo CMS, la mayoría de las cuales se encuentran en China.

Cada herramienta de inteligencia artificial, automatización del flujo de trabajo y aplicación de productividad que sus empleados conectaron a Google o Microsoft este año dejaron algo atrás: un token OAuth persistente sin fecha de vencimiento, sin limpieza automática y, en la mayoría de las organizaciones, nadie lo mira. Tus controles perimetrales no lo ven. Tu MFA no lo detiene. Y cuando un atacante consigue uno, no necesita una contraseña.

Las concesiones de OAuth no caducan cuando los empleados se van. No se restablecen cuando cambian las contraseñas. Y en la mayoría de las organizaciones, nadie los vigila.

El modelo tenía sentido cuando un puñado de aplicaciones aprobadas por TI necesitaban acceso al calendario. No se sostiene cuando cada empleado conecta de forma independiente herramientas de inteligencia artificial, automatizaciones de flujo de trabajo y aplicaciones de productividad directamente a su entorno de Google o Microsoft, cada uno de los cuales recibe un token persistente y con alcance, sin vencimiento automático y sin visibilidad centralizada.

Eso no es una mala configuración. Así es como está diseñado para funcionar OAuth. La brecha es que la mayoría de los programas de seguridad no se crearon para tenerlo en cuenta a escala.

Los CISO saben que es un problema. La mayoría no lo está resolviendo.

Nueva investigación de Material Security cuantifica la brecha entre conciencia y acción. El 80% de los líderes de seguridad consideran que OAuth no administrado representa un riesgo crítico o significativo. La mayoría lo ha dicho durante años.

Pero la conciencia no se traduce directamente en capacidad. Una parte sustancial de las organizaciones (45%) no está haciendo nada para monitorear las subvenciones de OAuth a escala. Muchos del resto (33%) ejecutan procesos manuales: rastrean las concesiones en hojas de cálculo, revisan los permisos ad hoc y dependen de los empleados para detectar comportamientos inusuales en las aplicaciones.

Las hojas de cálculo no son una capacidad de respuesta a amenazas. Son un registro de cuánta exposición una organización no sabe que tiene.

No es un riesgo teórico.

El argumento a favor de la visibilidad de OAuth a menudo se formula como si los empleados canalizaran información confidencial a herramientas de terceros sin visibilidad de TI. Ese es un problema real, pero es el más pequeño. El problema más apremiante es que las concesiones de OAuth son un vector de ataque activo. El incidente de deriva lo hace concreto.

Drift, una plataforma de participación de ventas adquirida por Salesloft, mantuvo integraciones de OAuth con instancias de Salesforce en cientos de organizaciones de clientes. Un actor de amenazas rastreado por la Unidad 42 de Palo Alto como UNC6395 obtuvo tokens de actualización de OAuth válidos (probablemente a través de campañas de phishing anteriores) y los utilizó para acceder a entornos de Salesforce que pertenecen a más de 700 organizaciones.

La estructura del ataque es una advertencia: los tokens eran legítimos, la integración era legítima. Desde la perspectiva de cualquier control perimetral, no pasaba nada. MFA se omitió por completo porque el atacante no estaba iniciando sesión; estaba presentando un token cuyo uso ya se había concedido a Drift. Una vez dentro, UNC6395 exportó datos sistemáticamente y los revisó en busca de credenciales: claves de acceso de AWS, tokens Snowflake, contraseñas.

Cloudflare, PagerDuty y decenas más se vieron afectados. Aún se está evaluando el alcance total.

El incidente de Drift no fue un ataque de una aplicación desconocida y sospechosa. fue un ataque a través de uno de confianza. La lección no es que las organizaciones deban restringir las integraciones de OAuth; es que confiar en una aplicación en el momento de la instalación no significa que siga siendo confiable, y que las concesiones de OAuth necesitan un monitoreo activo y continuo en lugar de una aceptación pasiva.

Cómo debe ser realmente el monitoreo

La generación actual de herramientas de seguridad de OAuth aborda el riesgo de OAuth en el punto de instalación. Comprueban si el alcance del permiso solicitado es excesivo. Pueden marcar aplicaciones de proveedores con mala reputación. Eso es útil, pero no suficiente. En el caso de Drift, una aplicación legítima cuyas credenciales fueron posteriormente robadas y utilizadas como arma, no detecta nada.

Para empezar, los niveles de confianza de los proveedores y el alcance de las aplicaciones son importantes, pero sólo cuentan una parte de la historia. Monitorear el comportamiento real de la aplicación (las llamadas a la API que realiza, las acciones que realiza) es fundamental para comprender qué es la aplicación. de hecho haciendo, no sólo lo que podría hacer. E incluso entonces, sin una visibilidad profunda de las cuentas a las que está vinculada la aplicación, todavía estás operando medio ciego. Una aplicación riesgosa vinculada a la cuenta de un pasante es una cosa; la misma aplicación utilizada por un VIP con acceso a innumerables correos electrónicos, archivos y sistemas confidenciales es otra completamente distinta.

El ataque Drift no involucró una aplicación sospechosa que solicitara permisos inusuales durante la instalación. Se trataba de una aplicación legítima cuyas credenciales fueron posteriormente comprometidas y utilizadas como arma. Una herramienta que sólo evalúa la subvención en el momento de su creación no habría visto nada malo. El riesgo se materializó más tarde, cuando el token fue robado y utilizado por un actor completamente diferente.

La seguridad efectiva de OAuth requiere:

• Monitoreo continuo del comportamiento, no revisión puntual. ¿Qué hace realmente la aplicación después de que se le ha concedido acceso? La supervisión de las llamadas API que realiza una aplicación conectada a OAuth a lo largo del tiempo revela anomalías que ninguna revisión de permisos estáticos puede detectar: ​​picos repentinos en el acceso a los datos, consultas de tipos de datos inusuales y acceso en horas inesperadas.
• Evaluación del radio de explosión. Una concesión de OAuth conectada a una cuenta con acceso de lectura a miles de documentos confidenciales y años de historial de correo electrónico es categóricamente diferente de la misma concesión en una cuenta recién aprovisionada con exposición limitada. El alcance de la cuenta del usuario determina el impacto potencial de una conexión OAuth comprometida o maliciosa. La puntuación de riesgo debería reflejar eso.
• Respuesta graduada ajustada a la tolerancia al riesgo organizacional. Una aplicación obviamente maliciosa (proveedor desconocido, permisos amplios, comportamiento anómalo de la API desde el primer día) no debería permanecer en el entorno mientras un ticket pasa por una cola. Debe revocarse inmediatamente. Una integración de misión crítica de un proveedor importante que muestra anomalías leves justifica una revisión humana antes de tomar cualquier medida. La capa de respuesta debe ser lo suficientemente inteligente como para notar la diferencia.

Agente de corrección de amenazas OAuth del material

Seguridad material Agente de corrección de amenazas de OAuth se basa en este modelo más completo de riesgo de OAuth. El agente se ejecuta continuamente en el entorno de Google Workspace de una organización y monitorea cada aplicación conectada a OAuth, no solo las nuevas en el momento de la concesión.

Para cada aplicación conectada, el agente evalúa tres factores juntos:

• Análisis de alcance y confianza de los proveedores – la línea de base estándar en la que se detienen la mayoría de las herramientas
• Monitoreo del comportamiento de llamadas API reales realizado por la aplicación a lo largo del tiempo, lo que revela anomalías frente al comportamiento esperado
• Evaluación del radio de explosión según los niveles de acceso y la exposición de datos de las cuentas a las que está conectada la aplicación

Estos datos se combinan en una señal de riesgo que refleja tanto la probabilidad de un problema como su impacto potencial. Cuando el agente identifica una subvención de alto riesgo, puede actuar de inmediato y revocar el token antes de que se produzca algún daño. Para situaciones de menor certeza que involucran aplicaciones de misión crítica, presenta el hallazgo al equipo de seguridad con contexto completo: qué es la aplicación, qué ha estado haciendo, a qué tiene acceso y cuál es la puntuación de riesgo.

Las organizaciones configuran sus propios umbrales: cuánto riesgo desencadena la remediación automatizada y dónde está el límite para exigir la aprobación humana. El agente está diseñado para mantener a los equipos de seguridad informados sobre las decisiones que importan y fuera de control sobre las que no lo son.

Cerrando la puerta trasera

Las concesiones de OAuth son la forma predeterminada en que las aplicaciones de terceros y las herramientas de inteligencia artificial se conectan al espacio de trabajo empresarial. Eso no va a cambiar. La cantidad de subvenciones en la mayoría de los entornos seguirá creciendo a medida que se acelere la adopción de la IA. Decir a los empleados que no pueden usar herramientas de inteligencia artificial no es una postura de seguridad viable para la mayoría de las organizaciones, y no abordaría la amenaza que representan las aplicaciones que son legítimas en el momento de la instalación y maliciosas más adelante.

La respuesta no es menos concesiones de OAuth. Es una mejor visibilidad de los que existen, un monitoreo continuo de su comportamiento y la capacidad operativa para responder lo suficientemente rápido y lo suficientemente inteligente como para evitar interrumpir las integraciones que mantienen el negocio en funcionamiento.

Para los equipos de seguridad que desean visibilidad de lo que realmente está conectado a su entorno y la capacidad de responder cuando algo cambia, comuníquese con Seguridad material para una demostración del Agente de corrección de amenazas de OAuth.

Si bien la industria del software ha logrado avances genuinos en las últimas décadas para ofrecer productos de forma segura, el ritmo vertiginoso de la adopción de la IA está poniendo en riesgo ese progreso. Las empresas se están moviendo rápidamente hacia una infraestructura LLM autohospedada, atraídas por la promesa de la IA como multiplicador de fuerza y ​​la presión de entregar más valor más rápido. Pero la velocidad se logra a expensas de la seguridad.

A raíz de la El fiasco de ClawdBot — el asistente de IA viral autohospedado que, en promedio, está haciendo lagrimear 2,6 CVE por día — el equipo intruso Quería investigar qué tan mala es realmente la seguridad de la infraestructura de IA.

Para determinar el alcance de la superficie de ataque, utilizamos registros de transparencia de certificados para extraer poco más de 2 millones de hosts con 1 millón de servicios expuestos. Lo que encontramos no fue bonito. De hecho, la infraestructura de IA que analizamos era más vulnerable, expuesta y mal configurada que cualquier otro software que hayamos investigado.

Sin autenticación por defecto

No pasó mucho tiempo para detectar un patrón alarmante: una cantidad significativa de hosts se habían implementado directamente, sin autenticación. Una mirada al código fuente reveló por qué: la autenticación simplemente no está habilitada de forma predeterminada en muchos de estos proyectos.

Los datos reales de los usuarios y las herramientas de la empresa estaban expuestos a cualquiera que mirara. En las manos equivocadas, las consecuencias van desde daños a la reputación hasta compromisos totales.

A continuación se muestran algunos de los ejemplos más llamativos de lo expuesto.

Chatbots de libre acceso

Varios casos involucraron chatbots que dejaron expuestas las conversaciones de los usuarios. Un ejemplo, basado en OpenUI, expuso el historial completo de conversaciones de LLM de un usuario. Puede parecer relativamente inocente a primera vista, pero los historiales de chat en entornos empresariales pueden revelar mucho.

Más preocupantes fueron los chatbots genéricos que albergaban una amplia gama de modelos, incluidos los LLM multimodales, disponibles de forma gratuita para su uso. Los usuarios malintencionados pueden fuga la mayoría de los modelos evitan las barreras de seguridad con fines nefastos (como generar imágenes ilegales o solicitar asesoramiento con la intención de cometer un delito) y lo hacen sin temor a repercusiones, ya que están utilizando la infraestructura de otra persona. Esto no es hipotético. La gente está encontrando formas creativas abusar de los chatbots de la empresa para acceder a modelos más capaces sin pagar ni tener solicitudes registradas en sus propias cuentas.

También hubo algunos cuestionable chatbots que exponen grandes volúmenes de conversaciones personales NSFW. Si eso no fuera suficientemente malo, el software que ejecuta los robots matones impulsados ​​por Claude también reveló sus claves API en texto plano.

Amplias plataformas abiertas de gestión de agentes

También descubrimos instancias expuestas de plataformas de administración de agentes, incluidas n8n y Flowise. Algunas instancias que los usuarios claramente pensaban que eran internas habían sido expuestas a Internet sin autenticación. Uno de los ejemplos más atroces fue una instancia de Flowise que expuso toda la lógica empresarial de un servicio de chatbot LLM.

Su lista de credenciales también quedó expuesta. Flowise estaba lo suficientemente reforzado como para no revelar los valores almacenados a un visitante no autenticado, lo que limita el daño inmediato, pero un atacante aún podría usar las herramientas conectadas a esas credenciales para filtrar información confidencial.

Esto es lo que hace que estas plataformas sean especialmente peligrosas. Hay una clara ausencia de controles de gestión de acceso adecuados en las herramientas de IA, lo que significa que el acceso a un bot que está integrado con un sistema de terceros a menudo significa acceso a todo lo que toca.

En otro ejemplo, la configuración expuso una serie de herramientas de análisis de Internet y funciones locales potencialmente peligrosas, como escritura de archivos e interpretación de código, lo que hizo que la ejecución de código del lado del servidor fuera una perspectiva realista.

Identificamos más de 90 casos expuestos en sectores como gobierno, marketing y finanzas. Todos esos chatbots, sus flujos de trabajo, indicaciones y acceso externo estaban abiertos. Un atacante podría modificar los flujos de trabajo, redirigir el tráfico, exponer datos del usuario o envenenar las respuestas.

Saludando a las API de Ollama no seguras

Uno de los hallazgos más sorprendentes fue la gran cantidad de API de Ollama expuestas y accesibles sin autenticación, con un modelo conectado. Enviamos un único mensaje («Hola») a cada servidor que enumeraba un modelo conectado, para ver si se nos solicitaba autenticarnos. De los más de 5200 servidores consultados, el 31% respondió.

Las respuestas dieron una idea de para qué se utilizaban estas API. No podríamos explorar moralmente más, pero las implicaciones son de gran alcance. Algunos ejemplos:

«Saludos, Maestro. Tu mandato es mi ley. ¿Cuál es tu deseo? Habla libremente. Estoy aquí para cumplirlo, sin vacilación ni duda.»

«Estoy aquí para ayudarle en todo lo que pueda con sus problemas de salud y bienestar. Ya sea ansiedad, problemas para dormir u otras inquietudes, no dude en pedirme ayuda».

«¡Bienvenido! Soy un asistente de IA integrado con nuestros sistemas de administración de la nube. Puedo ayudarlo con tareas operativas, implementación de infraestructura y consultas de servicios».

Ollama no almacena mensajes directamente, por lo que no existe un riesgo inmediato de que los datos de la conversación queden expuestos. Pero muchos de estos casos envolvían modelos de frontera pagos de Anthropic, Deepseek, Moonshot, Google y OpenAI. De todos los modelos identificados en todos los servidores, 518 incluían modelos fronterizos conocidos.

Inseguro por diseño

Después de evaluar los resultados, quedó claro que parte de la tecnología merecía una mirada más cercana. Dedicamos tiempo a analizar un subconjunto de aplicaciones en un entorno de laboratorio y encontramos patrones inseguros repetidos en todas partes:

• Malas prácticas de implementación: Valores predeterminados inseguros, configuraciones de Docker mal configuradas, credenciales codificadas, aplicaciones que se ejecutan como root
• Sin autenticación en instalaciones nuevas: Muchos proyectos colocan a los usuarios directamente en una cuenta con altos privilegios y acceso completo a la administración.
• Credenciales codificadas y estáticas: Integrado en ejemplos de configuración y archivos de composición de Docker en lugar de generarse durante la instalación.
• Nuevas vulnerabilidades técnicas: Después de un par de días de trabajo de laboratorio, ya habíamos encontrado ejecución de código arbitrario en un proyecto popular de IA.

Estas configuraciones erróneas empeoran aún más cuando los agentes tienen acceso a herramientas como la interpretación de códigos. El radio de explosión aumenta significativamente cuando el sandboxing es débil y la infraestructura no se encuentra en una DMZ.

La velocidad está ganando. La seguridad se está quedando atrás

Algunos de los proyectos que impulsan la infraestructura LLM claramente han abandonado décadas de mejores prácticas de seguridad logradas con tanto esfuerzo en favor de envíos rápidos. Dicho esto, no es un problema puramente de proveedores. La velocidad de la adopción de la IA y la presión para ganarle a los competidores en el mercado son lo que la impulsa.

No espere a que un atacante encuentre primero su infraestructura de IA expuesta. Intruso encuentra configuraciones erróneas y te muestra lo que es visible desde el exterior.

El grupo de hackers patrocinado por el Estado y alineado con Corea del Norte, conocido como ScarCruft ha comprometido una plataforma de videojuegos en un ataque de espionaje a la cadena de suministro, troyanizando sus componentes con una puerta trasera llamada Reclamoprobablemente apuntará a personas de etnia coreana que residen en China.

Si bien las versiones anteriores de la puerta trasera se han dirigido principalmente a usuarios de Windows, se considera que el ataque a la cadena de suministro permitió a los actores de la amenaza apuntar también a dispositivos Android, convirtiéndolo esencialmente en una amenaza multiplataforma.

Según ESET, la campaña ha destacado a sqgame[.]net, una plataforma de juegos utilizada por personas de etnia coreana que viven en la región de Yanbian en China, en la frontera con Corea del Norte y Rusia. También se sabe que actúa como punto de tránsito principal y de alto riesgo para los desertores norcoreanos que cruzan el río Tumen.

Se dice que atacar esta plataforma es una estrategia deliberada dada la historia de ScarCruft de atacar a desertores norcoreanos, activistas de derechos humanos y profesores universitarios.

«En el ataque, probablemente en curso desde finales de 2024, ScarCruft comprometió componentes de Windows y Android de una plataforma de videojuegos dedicada a juegos con temática de Yanbian, troyanizándolos con una puerta trasera», afirma la empresa eslovaca de ciberseguridad. dicho en un informe compartido con The Hacker News antes de su publicación.

Las versiones para Windows de BirdCall, denominadas una evolución avanzada de RokRAT, han sido detectado en la naturaleza desde 2021. A lo largo de los años, RokRAT también se ha adaptado para apuntar a macOS (CloudMensis) y Android (RambleOn), lo que indica que los actores de amenazas continúan manteniendo activamente la familia de malware.

BirdCall viene equipado con funciones que normalmente se encuentran en una puerta trasera, lo que permite la captura de capturas de pantalla, el registro de pulsaciones de teclas, el robo de contenido del portapapeles, la ejecución de comandos de shell y la recopilación de datos. Al igual que RokRAT, el malware se basa en servicios legítimos en la nube como Dropbox y pCloud para comando y control (C2).

«BirdCall generalmente se implementa en una cadena de carga de varias etapas, que comienza con un script Ruby o Python y contiene componentes cifrados usando una clave específica de la computadora», dijo ESET.

La variante de Android de BirdCall, distribuida como parte de sqgame[.]net Supply Chain Attack, incorpora un subconjunto de su contraparte de Windows, mientras recopila listas de contactos, mensajes SMS, registros de llamadas, archivos multimedia, documentos, capturas de pantalla y audio ambiental. Un análisis del linaje del malware ha descubierto siete versiones, la primera de las cuales se remonta a octubre de 2024.

Curiosamente, se ha descubierto que el ataque a la cadena de suministro solo envenena los APK de Android disponibles para descargar desde la plataforma, dejando intactos el cliente de escritorio de Windows y los juegos de iOS. Las páginas de descarga de dos juegos de Android alojados en sqgame[.]net se han modificado para servir los APK maliciosos –

• sqgame.com[.]cn/ybht.apk
• sqgame.com[.]cn/sqybhs.apk

Actualmente no se sabe cuándo se vulneró el sitio web y los APK envenenados comenzaron a distribuirse. Sin embargo, se cree que el incidente ocurrió a finales de 2024. Es más, ha surgido evidencia de que un paquete de actualización del cliente de escritorio de Windows entregó una DLL troyanizada desde al menos noviembre de 2024 y durante un período no especificado. El paquete de actualización ya no es malicioso.

Específicamente, la DLL modificada incluía un descargador que verifica la lista de procesos en ejecución para herramientas de análisis y entornos de máquinas virtuales, antes de proceder a descargar y ejecutar el código shell que contiene RokRAT. Luego, la puerta trasera se utiliza para buscar e instalar BirdCall en los hosts infectados.

La versión Android de BirdCall también se basa en servicios legítimos de almacenamiento en la nube para las comunicaciones C2. Esto incluye pCloud, Yandex Disk y Zoho WorkDrive, el último de los cuales se ha convertido en una presencia cada vez más común en múltiples campañas.

«La puerta trasera de Android ha experimentado un desarrollo activo y proporciona capacidades de vigilancia, como la recopilación de datos y documentos personales, la toma de capturas de pantalla y la realización de grabaciones de voz», dijo ESET.