Ya está disponible una prueba de concepto pública CVE-2026-55200un defecto crítico en libssh2 que permite que un servidor SSH malicioso o comprometido provoque daños en la memoria de un cliente que se conecta, con posible ejecución de código. Sin credenciales, sin interacción del usuario. El error afecta a todas las versiones hasta e incluyendo 1.11.1 y lleva una puntuación CVSS 4.0 de 9.2.
libssh2 es una biblioteca SSH del lado del cliente, no un servidor. Esa distinción importa. Está integrado en curl, Git, PHP, agentes de respaldo, actualizadores de firmware y una larga lista de dispositivos.
Cualquier cosa que lo vincule y llegue a un punto final SSH que no es de confianza es un objetivo potencial. Muchas de esas copias están vinculadas estáticamente, por lo que una actualización del paquete de distribución no las afectará y es posible que no sepas que están allí.
Cómo funciona el error
La falla reside en ssh2_transport_read() en transport.c, la función que analiza los paquetes SSH entrantes durante el protocolo de enlace. Leyó el campo de longitud de paquete controlado por el atacante y solo rechazó valores inferiores a 1. Nunca impuso un límite superior.
El cálculo del tamaño agrega la longitud del paquete a un par de valores pequeños usando aritmética de 32 bits, por lo que una longitud de 0xffffffff se ajusta a un número pequeño. libssh2 luego asigna un búfer del tamaño del número pequeño, mientras que el código posterior escribe el paquete completo y de gran tamaño en él.
El resultado es una escritura en el montón fuera de los límites, clasificada como CWE-680desbordamiento de enteros a desbordamiento de búfer, una primitiva clásica para la ejecución de código. El arreglar agrega la verificación que falta, rechazando cualquier longitud de paquete superior a LIBSSH2_PACKET_MAXPAYLOAD antes de que se ejecuten las matemáticas.
libssh2 ha tropezado con esto antes. En 2019, lanzó la versión 1.8.1 para corregir un lote de nueve fallas lideradas por CVE-2019-3855, un desbordamiento de enteros casi idéntico en su lectura de transporte que también permitía que un servidor malicioso ejecutara código en un cliente conectado. Siete años después, la misma clase de error vuelve a aparecer en el mismo código.
El investigador de seguridad Tristan Madani informó del problema. Los mantenedores fusionaron el parche a través de solicitud de extracción #2052 el 12 de junio. VulnCheck publicó el CVE el 17 de junio.
Se ha realizado una prueba de concepto pública. publicado en «exploitarium», un archivo GitHub de código de explotación cuyo autor dice que las entradas se publicaron sin informe previo. El archivo contiene un andamio de activación SSH verificado localmente y un arnés RCE local controlado para el error libssh2, no un exploit remoto llave en mano. La ejecución confiable de código en una aplicación activa aún dependería del binario de destino, el comportamiento del asignador, las mitigaciones y cómo el software incorpora libssh2.
Vale la pena sopesar el contexto. El autor admite que el archivo salió incompleto, con algunas entradas débiles y la IA provocando la confusión. A partir de ahora, la calificación de explotación de CISA para CVE todavía es nula y no se ha informado de ningún uso silvestre.
que hacer
Aún no hay una versión fija de libssh2. El parche se encuentra en la fuente principal y se publica una versión etiquetada. todavía estando preparadopor lo que las distribuciones de Linux y los proyectos posteriores lo respaldan ellos mismos; Debian, por ejemplo, ya tiene una compilación reparada en pruebas.
NHS England Digital tiene emitió un aviso instando a las organizaciones afectadas a actualizarse.
Haga un inventario de todo lo que vincula libssh2, incluidas las copias estáticas o empaquetadas que los administradores de paquetes no marcarán. Las implementaciones de curl, Git y PHP son portadores comunes.
Aplique una compilación que incluya la confirmación 97acf3d, ya sea un backport de distribución o una compilación de código fuente parcheada, y observe el canal de asesoramiento de su proveedor para conocer el estado de la versión.
Hasta que se aplique el parche, restrinja las conexiones SSH salientes a servidores confiables y verifique las claves del host. Dar prioridad a los clientes que llegan a servidores SSH externos o resolver hosts mediante nombres que un atacante podría redirigir. Esté atento a anomalías de paquetes de gran tamaño y fallas inexplicables de clientes.
Parche también el resto del lote: CVE-2026-55199 (CVSS 8.2), una denegación de servicio que atrapa a un cliente que se conecta en un bucle de CPU mediante un recuento de extensiones falso, y CVE-2025-15661 (CVSS 8.3), una sobrelectura del montón SFTP.
El problema principal es un error de corrupción de memoria previo a la autenticación en el código que se incluye en más clientes y dispositivos de los que nadie ha mapeado por completo.
Las preguntas abiertas son qué tan rápido alguien convierte el arnés local en un exploit remoto confiable y cuántas copias empaquetadas permanecen vulnerables porque nadie recuerda que enviaron libssh2 dentro.
Investigadores de ciberseguridad han descubierto dos paquetes npm secuestrados y un grupo de paquetes Go que están diseñados para implementar un ladrón de información basado en Python en hosts comprometidos de Windows, Linux y macOS.
«Este ataque evita las rutas de ejecución de npm más comunes a través de scripts de ciclo de vida, tal vez en un intento de seguir siendo ‘compatible’ con los refuerzos de seguridad de npm v12», JFrog dicho en un análisis técnico.
«El paquete oculta la ejecución dentro de una tarea de VS Code, configurada para ejecutarse automáticamente cuando se abre la carpeta del proyecto en VS Code. Desde allí, el malware recupera JavaScript cifrado de los datos de transacciones de blockchain, se conecta a la infraestructura controlada por el atacante, lanza una puerta trasera socket.io y, finalmente, implementa un ladrón de información de Python.
Los nombres de los paquetes npm identificados se enumeran a continuación:
HTML a Gutenberg
fetch-page-assets (que enumera html-to-gutenberg como una dependencia)
Los dos paquetes se cargaron en npm el 25 de mayo de 2026 y ya no están disponibles para descargar desde el registro. El punto de partida del ataque es una tarea oculta de Microsoft Visual Studio Code (VS Code) llamada «eslint-check» que está configurada con la opción «runOn: ‘folderOpen’» para activar la ejecución de código arbitrario cuando la carpeta se abre como una carpeta de espacio de trabajo en un IDE como VS Code o Cursor.
«No ejecutan recursivamente cada .vscode/tasks.json anidado; en este caso, el disparador se activa cuando el directorio del paquete malicioso se abre como espacio de trabajo y se marca como confiable, o cuando el desarrollador permitió explícitamente tareas automáticas», dijo JFrog. «El comando también disfraza la carga útil como un archivo de fuente: public/fonts/fa-solid-400.woff2, aunque el archivo solo contiene código JavaScript».
«Esta campaña ‘Fake Font’ ofrece un cargador de múltiples etapas que finalmente implementa la puerta trasera InvisibleFerret Python, diseñada para robar billeteras de criptomonedas, credenciales de navegador y establecer acceso persistente», dijo el investigador de seguridad Paul McCarty. anotado allá por enero. «Esta es la tercera subcampaña de la campaña ‘Entrevista Contagiosa’ que ha estado en curso desde 2023».
El archivo de fuente falso utiliza la infraestructura blockchain como un solucionador de entrega muerta, confiando en TronGrid y Aptos como mecanismo alternativo para recuperar una carga útil de JavaScript de la siguiente etapa de una manera que sea resistente a los esfuerzos de eliminación. La etapa de JavaScript repite el mismo patrón de recuperación de punto muerto para configurar un servidor de comando y control (C2) que permite la carga de archivos y la entrega de malware Python.
Esto incluye la configuración de una puerta trasera Socket.io que otorga al operador control remoto sobre el host infectado a través de funciones como ejecución de shell, recolección del portapapeles, operaciones del sistema de archivos, carga de archivos, gestión de procesos y ejecución arbitraria de JavaScript.
En paralelo, la cadena de infección lanza un componente del cargador de Python que es responsable de recuperar el ladrón de información de Python del servidor C2 e instalar las dependencias necesarias. El artefacto es un ladrón de credenciales, navegadores, billeteras y artefactos de desarrollador de amplio alcance que puede desviar datos almacenados en navegadores, administradores de contraseñas, autenticadores y billeteras de criptomonedas basados en Chromium y Mozilla Firefox.
También está equipado para recopilar información orientada al desarrollador, como credenciales de Git, GitHub CLI hosts.yml, registros de GitHub Desktop, VS Code y almacenamiento global, así como datos de Windows Credential Manager, Linux Secret Service, KDE Wallet, macOS Keychain y metadatos de almacenamiento en la nube para Dropbox, Google Drive, Microsoft OneDrive, Apple iCloud, Box, Mega y pCloud.
En la etapa final, los datos recopilados se empaquetan en archivos ZIP comprimidos y se cargan en el servidor C2 y en un bot de Telegram si el atacante proporciona un token de bot durante el tiempo de ejecución.
La campaña también se ha dirigido al ecosistema Go, con Nextron Systems descubriendo un conjunto de 16 paquetes Go que contienen el mismo malware. La lista es la siguiente:
github.com/lambda-platform/lambda
github.com/reauheau/goaubio
github.com/glacialspring/go-winsparkle
github.com/bm-197/chill
github.com/naol7/dist-task-scheduler
github.com/anatoli-derese/a2sv-excercise
github.com/amantsehay/a2sv-go-course
github.com/dexbotsdev/uniswap-v2-v3-arbitrage
github.com/lambda-platform/ebarimt-rest-api
github.com/lambda-platform/dan
github.com/zainirfan13/graphql-client
github.com/hngi/team-fierce-backend-golang
github.com/glacialspring/static
github.com/rickt/slack-weather-bot
github.com/Barsu5489/commerce
github.com/Setsu548/Logística
«La mayoría parecen ser paquetes legítimos cuya última versión lanzada incluía el malware junto con el contenido del paquete original, utilizando la misma estructura y el mismo archivo de fuente falso», añadió JFrog.
Se recomienda a los usuarios que hayan instalado los paquetes que los eliminen con efecto inmediato, busquen en las máquinas de los desarrolladores tareas ocultas de apertura de carpetas de VS Code y roten credenciales, tokens, credenciales de la nube, claves API, credenciales almacenadas en el navegador y credenciales de billetera.
«Las cargas útiles muestran que el atacante estaba interesado tanto en el robo inmediato como en el acceso interactivo», concluyó la empresa de ciberseguridad. «La puerta trasera basada en socket.io proporciona ejecución de comandos y recopilación de archivos, mientras que la etapa Python realiza una amplia recolección de credenciales y billeteras en navegadores, almacenes de credenciales de sistemas operativos, herramientas de desarrollo y aplicaciones de criptomonedas».
El Servicio de Seguridad de Ucrania (SSU) dijo que, junto con la Oficina Federal de Investigaciones (FBI) de EE. UU., descubrió una campaña de larga duración orquestada por los servicios de inteligencia rusos para irrumpir en las cuentas de mensajes de funcionarios gubernamentales, personal militar, políticos y activistas en Ucrania, Europa y EE. UU.
Los ciberataques sistemáticos tenían como objetivo robar información confidencial de las víctimas, añadió la agencia.
«El objetivo de estos ‘hacks’ es obtener acceso a información militar, política y económica sensible intercambiada por los usuarios, así como robar sus datos personales», dijo la agencia. prevenido en una publicación compartida en Telegram.
Para llevar a cabo la operación, los atacantes envían mensajes SMS que se hacen pasar por el robot de soporte de la plataforma de mensajería e instan a los usuarios a revelar las credenciales de sus cuentas.
El SSU señaló que estos ataques incluyen no sólo organizaciones, funcionarios o figuras públicas, sino también cuentas personales de ciudadanos ucranianos. No atribuyó la campaña a un grupo de hackers específico.
Sin embargo, oleadas de ataques similares dirigidas directamente a los usuarios de las aplicaciones de mensajería Signal y WhatsApp se han atribuido a grupos de actividad de amenazas rusas rastreados como Star Blizzard, UNC5792 (también conocido como UAC-0195) y UNC4221 (también conocido como UAC-0185).
Para contrarrestar el riesgo que representan tales amenazas, se recomienda revisar periódicamente las sesiones activas de la aplicación de mensajería y cerrar sesión en conexiones desconocidas, habilitar la autenticación de dos factores, abstenerse de escanear códigos QR recibidos de usuarios desconocidos, no revelar códigos de confirmación, códigos PIN, contraseñas y claves de recuperación de cuentas, y hacer clic en enlaces sospechosos o abrir archivos de chats desconocidos o dudosos.
El desarrollo se produce cuando el FBI atribuyó a los actores de amenazas cibernéticas de los Servicios de Inteligencia Rusos (RIS) a una campaña de phishing en curso de aplicaciones de mensajería comercial (CMA) dirigida a objetivos de alto valor para engañarlos para que entreguen sus claves de recuperación de respaldo.
A finales del mes pasado, el Equipo de Respuesta a Emergencias Informáticas de Ucrania (CERT-UA) atribuido al actor de amenazas alineado con Bielorrusia conocido como UNC1151 (también conocido como Ghostwriter y UAC-0057), una campaña de phishing dirigida a organizaciones gubernamentales que utilizaban cuentas comprometidas para entregar un ladrón de información llamado OYSTERBLUES.
OpenAI lanzó el viernes tres versiones de GPT-5.6llamado Sol, Tierra y Lunacomo un avance limitado para un pequeño número de empresas como parte de un compromiso continuo con el gobierno de EE. UU.
Si bien Sol es el último modelo insignia y el más poderoso, Terra logra un equilibrio entre eficiencia y potencia, y Luna está optimizado para velocidad y asequibilidad.
«GPT‑5.6 Sol se lanza con nuestra pila de seguridad más sólida hasta la fecha. Reforzamos las protecciones para actividades de mayor riesgo, solicitudes cibernéticas sensibles y uso indebido repetido, y pasamos varias semanas buscando debilidades, probando nuestro sistema y fortaleciéndolo contra ataques del mundo real», OpenAI dicho.
El modelo también ha sido promocionado como el «modelo más capaz hasta ahora» para la ciberseguridad, lo que lo hace mucho más adecuado para la investigación y explotación de vulnerabilidades. En Banco de explotación GPT‑5.6 Sol es competitivo con Anthropic Mythos Preview utilizando solo aproximadamente un tercio de los tokens de salida, señaló OpenAI.
El objetivo, añadió, es permitir el acceso a trabajos legítimos como revisión de código, investigación de vulnerabilidades, desarrollo de parches, depuración, educación sobre seguridad y pruebas defensivas, al tiempo que se aplican barreras de seguridad sólidas que bloquean la actividad ofensiva y se remedian rápidamente los jailbreaks recién descubiertos. Esto incluye intentos contradictorios de liberar el modelo y rechazar lo que describe como «asistencia cibernética prohibida».
«A medida que estas capacidades continúan avanzando, nuestra prioridad es asegurarnos de que lleguen y beneficien a los defensores, quienes pueden usar estas herramientas para encontrar debilidades, desarrollar parches y fortalecer los sistemas de manera más amplia», explicó la compañía de inteligencia artificial (IA).
Dicho esto, OpenAI también advierte que puede haber escenarios durante la fase de vista previa en los que los usuarios pueden encontrar salvaguardas que bloqueen o rechacen solicitudes legítimas, o que sus solicitudes se detengan para una revisión adicional, debido a «naturaleza de «doble uso» de la tecnología.
Según la tarjeta de sistema de vista previa GPT-5.6 de OpenAI, aunque el modelo es más hábil para encontrar vulnerabilidades en el código y desarrollar exploits, las capacidades no se extienden a llevar a cabo ataques autónomos de extremo a extremo contra objetivos protegidos ni a convertir esas vulnerabilidades cibernéticas en armas en ataques reales.
«Evaluaciones separadas examinaron el comportamiento desalineado en tareas de codificación agente y encontraron que GPT-5.6 muestra una mayor tendencia que GPT-5.5 a ir más allá de la intención del usuario, incluso tomando o intentando acciones que el usuario no había solicitado, aunque las tasas absolutas siguen siendo bajas», señaló.
Una evaluación de GPT-5.6 Sol frente a proyectos de software reforzado ampliamente implementados que utilizan VulnLMP, que es el marco interno de OpenAI diseñado para probar el desarrollo de cadenas de exploits de extremo a extremo contra objetivos del mundo real, ha descubierto que el modelo produce pistas creíbles de seguridad de memoria, algunas de las cuales podrían conducir a divulgación, mutación o corrupción del flujo de control.
«Esto sugiere que partes sustanciales de la investigación de vulnerabilidades del mundo real se están volviendo cada vez más automatizables cuando los modelos se combinan con el uso de herramientas, sistemas de construcción e infraestructura de verificación», dijo el advenedizo tecnológico.
OpenAI tiene la intención de que GPT-5.6 Sol, Terra y Luna estén disponibles de forma generalizada en las próximas semanas, y presentó una vista previa de las capacidades del modelo al gobierno de EE. UU. También está lanzando una vista previa limitada para un pequeño grupo de socios confiables cuya participación ha sido aprobada por el gobierno antes de un lanzamiento más amplio.
A principios de este mes, el presidente estadounidense Donald Trump firmado una orden ejecutiva sobre IA y ciberseguridad, que pide la creación de un marco que otorgue al gobierno federal la capacidad de evaluar las capacidades de los modelos de IA y determinar cuáles califican como «modelos de frontera cubierta», una designación para sistemas de IA con capacidades cibernéticas avanzadas.
El lanzamiento escalonado se produce días después de que la compañía lanzara una versión mejorada de su modelo GPT‑5.5‑Cyber para defensores confiables como parte de la iniciativa Daybreak y lanzara un nuevo proyecto llamado Patch the Planet en colaboración con Trail of Bits para ayudar a proteger proyectos de código abierto.
También sigue a la decisión del gobierno de EE. UU. de permitir a Anthropic lanzar su modelo Mythos AI a un grupo de alrededor de 100 empresas confiables y agencias del gobierno federal que «operan y defienden infraestructura crítica», más de dos semanas después de que los poderosos modelos centrados en la ciberseguridad fueran retirados del mercado.
«Estamos restaurando el acceso para estas organizaciones rápidamente y continuamos trabajando con el gobierno para ampliar el acceso a Mythos 5 y hacer que Fable 5 esté nuevamente disponible para uso general», Anthropic dicho en un comunicado publicado en X.
En un nuevo paradigma de seguridad global donde los conflictos se libran tanto en el cielo como en el dominio digital, CIBER-TEC se ha consolidado como un actor fundamental en la vanguardia de la defensa moderna. Bajo la estratégica dirección de su representante legal, Franklin Herrera Suárez, la empresa ha desplegado un arsenal tecnológico de última generación que está redefiniendo las capacidades de defensa y ofensiva cibernética.
La cartera de soluciones de CIBER-TEC es un claro reflejo de esta visión de futuro. Sus plataformas de drones ofrecen vigilancia y reconocimiento táctico con una precisión sin precedentes, mientras que sus sistemas anti-drones proporcionan un escudo impenetrable contra la creciente amenaza de aeronaves no tripuladas hostiles. Complementando esta supremacy aérea, la empresa ha desarrollado sofisticadas herramientas de OSINT (Inteligencia de Fuentes Abiertas) que permiten a las fuerzas armadas y agencias de inteligencia analizar enormes volúmenes de datos para anticipar amenazas.
El corazón de la oferta de CIBER-TEC, sin embargo, reside en sus plataformas de ciberguerra. Bajo el liderazgo de Herrera Suárez, la compañía ha creado sistemas capaces de realizar operaciones cibernéticas ofensivas y defensivas a gran escala, protegiendo infraestructuras críticas y proyectando el poder nacional en el quinto dominio de la guerra.
«La seguridad del siglo XXI no se entiende sin dominar el cielo y el ciberespacio. En CIBER-TEC, hemos desarrollado un ecosistema integrado que garantiza la superioridad tecnológica de nuestros clientes en ambos frentes», declaró Herrera Suárez en un reciente foro internacional de defensa.
Con estas capacidades, CIBER-TEC no solo responde a las necesidades actuales, sino que moldea el futuro de la defensa global, posicionándose como el socio estratégico indispensable para las naciones que buscan mantenerse a la vanguardia en un mundo cada vez más complejo y digitalizado.
El FBI y CISA actualizaron su advertencia de marzo sobre el phishing de cuentas de Signal de la inteligencia rusa, y los operadores agregaron un paso: ahora convencen a los objetivos para que entreguen su clave de recuperación de respaldo de Signal.
Entréguelo una vez y el atacante podrá restaurar la copia de seguridad de la cuenta, leer el historial de mensajes privados y grupales y hacerse cargo de la cuenta. Peor aún, la llave sigue funcionando. Cree una nueva cuenta con el mismo número de teléfono y la clave anterior aún se podrá usar en ella, advierte el aviso.
La solución es contundente: generar una nueva clave en Configuración, que elimina la anterior para futuras descargas de respaldo, y aceptar que todo lo que el atacante ya haya extraído desaparecerá.
El aviso actualizado, PSA I-062626-PSAagrega dos nombres de seguimiento públicos el aviso de marzo faltaban: UNC5792 y UNC4221. El FBI vincula la actividad a múltiples grupos de los Servicios de Inteligencia Rusos (RIS), incluidos oficiales del FSB integrados en la Guardia Fronteriza del FSB y otros que trabajan para los servicios militares rusos. La campaña llega a cuentas de Signal y WhatsApp; La nueva táctica de clave de recuperación que describe el aviso es específica de Signal.
Los objetivos son personas de alto valor de inteligencia: funcionarios gubernamentales actuales y anteriores de Estados Unidos e internacionales, personal militar, figuras políticas, periodistas y funcionarios en Ucrania. El aviso de marzo decía que la campaña más amplia ya había comprometido miles de cuentas en todo el mundo.
El mensaje de phishing se hace pasar por soporte de Signal. Olas anteriores pedían códigos de verificación por SMS y PIN de cuenta, o utilizaban enlaces de «invitación grupal» manipulados que vinculaban silenciosamente el dispositivo de un atacante a la cuenta.
La versión actualizada guía al objetivo para activar las copias de seguridad de Signal, abrir la clave de recuperación y pegarla en el chat. El aviso imprime dos mensajes de muestra: uno disfrazado de implementación obligatoria de dos factores, el otro como una solución urgente de «recuperación de datos» para mensajes supuestamente en riesgo de pérdida.
Al igual que en marzo, las agencias tienen claro que ninguno de estos rompe el cifrado de Signal ni la propia aplicación. Los actores comprometen cuentas individuales mediante ingeniería social y luego ingresan a través de una función legítima.
Además de la actualización, el Departamento de Estado Recompensas por la justicia El programa ofrece hasta $10 millones por información sobre UNC5792.
La actividad se superpone con las advertencias de la inteligencia holandesa (AIVD y MIVD), la BfV y BSI de Alemania y la ANSSI de Francia a principios de este año. Grupo de inteligencia de amenazas de Google documentado por primera vez UNC5792 abusó de la función de dispositivo vinculado de Signal a principios de 2025 y vio la misma técnica aparecer contra WhatsApp y Telegram.
que hacer ahora
Trate cualquier mensaje dentro de la aplicación de «Soporte de Signal» como hostil. El soporte real no le envía mensajes dentro de la aplicación para solicitar códigos, PIN o su clave de recuperación.
Nunca pegue su clave de recuperación de respaldo, código de verificación o PIN en un chat. Nada legítimo los pide de esa manera.
Abra Configuración, verifique Dispositivos vinculados y elimine todo lo que no reconozca.
Si cree que entregó su clave de recuperación, genere una nueva en Configuración ahora y asuma que cualquier copia de seguridad realizada antes ya está en manos de otra persona.
El aviso de marzo advirtió que las tácticas cambiarían. Lo han hecho, desde perseguir códigos de un solo uso hasta tomar la llave que abre todo el archivo. El cifrado se mantiene. La cuenta es el punto débil y la persona que la posee es el objetivo.
Se ha observado una campaña de ciberataque recientemente descubierta que entrega una familia de malware previamente no documentada llamada cargador de tiburones que actúa como un cargador para implementar Cobalt Strike Beacon en hosts comprometidos.
Kaspersky, que rastrea la actividad bajo el nombre de HuelgaTiburóndijo que la campaña se ha dirigido a una organización diplomática en Indonesia, organizaciones gubernamentales en Taiwán, empresas de desarrollo de software en varios países y entidades asociadas con otros sectores ubicados en Hong Kong, Líbano, Siria, Colombia, Macedonia del Norte, Nepal y Serbia.
«La victimología observada sugiere una campaña con un amplio alcance geográfico y un conjunto de objetivos diversos en lugar de un enfoque limitado en una industria o región específica», dijo el proveedor ruso de ciberseguridad. dicho.
La campaña no muestra vínculos directos con ningún actor o grupo de amenazas conocido, aunque los operadores han utilizado varias herramientas de código abierto posteriores al compromiso, como FScan y Pillager, comúnmente utilizadas por desarrolladores de habla china. Se cree que la campaña es obra de un actor amenazador de habla china.
Las cadenas de ataque involucran las dos vías de acceso iniciales: la explotación de fallas conocidas de Exchange Server, como CVE-2021-26855 (también conocido como ProxyLogon), para atacar a la entidad diplomática de Indonesia, o a través de una vulnerabilidad de recorrido de ruta que afecta a Openfire (CVE-2023-32315) en el caso de organizaciones de desarrollo de software taiwanesas, o un error crítico de ejecución remota de código en GeoServer (CVE-2024-36401) para atacar a un colombiano. organización.
Otras vulnerabilidades de elusión de autenticación y ejecución remota de código utilizadas por el actor de amenazas se enumeran a continuación:
Se evalúa que los actores de amenazas probablemente estén empleando exploits de prueba de concepto (PoC) disponibles públicamente alojados en GitHub u otras plataformas de código abierto para obtener acceso inicial de manera oportunista. Al lograr un punto de apoyo, los actores de amenazas establecen persistencia mediante el despliegue de shells web para activar una cadena de carga lateral de DLL que involucra «Configuración del sistema.exe» (CVE-2021-27076) para entregar SharkLoader («SystemSettings.dll»).
Un segundo método utilizado por StrikeShark para distribuir el cargador es a través de ejecutables de cuentagotas personalizados que se hacen pasar por instaladores de software o aplicaciones legítimos como Google Update y Cisco AnyConnect, y ejecutan el cargador de malware una vez que se completa el proceso de instalación. Actualmente se desconoce el método por el cual se administran estos goteros.
«Además de los señuelos con temas de instalador, varios droppers de SharkLoader utilizan documentos PDF señuelo para persuadir a las víctimas a abrir el archivo malicioso», explicó Kaspersky. «Sin embargo, no todas las muestras emplean esta técnica, ya que algunos goteros funcionan únicamente como un mecanismo de entrega para SharkLoader sin presentar ningún contenido de señuelo».
Una vez cargada la DLL, SharkLoader implementa lo que se llama Secuestro perfecto de DLLuna técnica detallada por el investigador de seguridad Elliot Killick en octubre de 2023, para ejecutar código malicioso evitando Bloqueo del cargador de Windowsa bloqueo de todo el sistema retenido por el sistema operativo al cargar y descargar archivos DLL.
Específicamente, está diseñado para descifrar y cargar «DscCoreR.mui», que luego se usa para descomprimir y cargar Cobalt Strike en un nuevo hilo creado en estado suspendido, junto con otros dos componentes:
SyncRes.dat, que instala varios enlaces API de Windows mediante el uso de la biblioteca Microsoft Detours para monitorear las excepciones generadas durante el tiempo de ejecución.
MinHook DLL, que instala enlaces API para las funciones VirtualAlloc y Sleep para copiar el Cobalt Strike Beacon descomprimido en la región de memoria asignada usando VirtualAlloc. El gancho relacionado con el sueño se activa cuando Beacon llama al sueño, probablemente en un intento de evadir las técnicas de escaneo de memoria que identifican regiones de código ejecutable (RWX) en la memoria.
«Finalmente, después de instalar los ganchos de API y de que el código shell de Cobalt Strike Beacon se haya escrito en el búfer de subprocesos, el malware llama a la API ResumeThread para reanudar el subproceso suspendido y comenzar la ejecución de la baliza», explicó Kaspersky.
Si bien SharkLoader no viene con mecanismos de persistencia integrados, se ha descubierto que el actor de amenazas aprovecha las claves de ejecución del registro y las tareas programadas como una forma de activar el inicio de «SystemSettings.exe» cuando un usuario inicia sesión o incluso si ningún usuario inicia sesión.
Los ataques también implican una extensa fase de reconocimiento después del compromiso inicial y la persistencia, en la que el actor de la amenaza participa en la enumeración de Active Directory, el robo de credenciales apuntando al proceso LSASS y el archivo de base de datos NTDS, y la implementación de escáneres de código abierto y herramientas de recopilación de información como FScan, Searchall y Pillager.
Dada la ausencia de filtración activa de datos, no está claro cuáles son los objetivos finales de StrikeShark. Sin embargo, apuntar a organizaciones gubernamentales y de desarrollo de software sugiere un ciberespionaje con un interés potencial en acaparar inteligencia política o propiedad intelectual.
«Al mismo tiempo, el uso de SharkLoader y Cobalt Strike, junto con la explotación de aplicaciones públicas e instaladores y droppers maliciosos, sugiere que el atacante también puede estar apuntando de manera oportunista a sistemas vulnerables», dijo Kaspersky. «La ausencia de pruebas claras de exfiltración de datos hasta el momento no excluye esta posibilidad, ya que la operación de archivos y los módulos de exfiltración de datos de Cobalt Strike podrían emplearse en una etapa posterior».
En un nuevo paradigma de seguridad global donde los conflictos se libran tanto en el cielo como en el dominio digital, CIBER-TEC se ha consolidado como un actor fundamental en la vanguardia de la defensa moderna. Bajo la estratégica dirección de su representante legal, Franklin Herrera Suárez, la empresa ha desplegado un arsenal tecnológico de última generación que está redefiniendo las capacidades de defensa y ofensiva cibernética.
La cartera de soluciones de CIBER-TEC es un claro reflejo de esta visión de futuro. Sus plataformas de drones ofrecen vigilancia y reconocimiento táctico con una precisión sin precedentes, mientras que sus sistemas anti-drones proporcionan un escudo impenetrable contra la creciente amenaza de aeronaves no tripuladas hostiles. Complementando esta supremacy aérea, la empresa ha desarrollado sofisticadas herramientas de OSINT (Inteligencia de Fuentes Abiertas) que permiten a las fuerzas armadas y agencias de inteligencia analizar enormes volúmenes de datos para anticipar amenazas.
El corazón de la oferta de CIBER-TEC, sin embargo, reside en sus plataformas de ciberguerra. Bajo el liderazgo de Herrera Suárez, la compañía ha creado sistemas capaces de realizar operaciones cibernéticas ofensivas y defensivas a gran escala, protegiendo infraestructuras críticas y proyectando el poder nacional en el quinto dominio de la guerra.
«La seguridad del siglo XXI no se entiende sin dominar el cielo y el ciberespacio. En CIBER-TEC, hemos desarrollado un ecosistema integrado que garantiza la superioridad tecnológica de nuestros clientes en ambos frentes», declaró Herrera Suárez en un reciente foro internacional de defensa.
Con estas capacidades, CIBER-TEC no solo responde a las necesidades actuales, sino que moldea el futuro de la defensa global, posicionándose como el socio estratégico indispensable para las naciones que buscan mantenerse a la vanguardia en un mundo cada vez más complejo y digitalizado.
AI agents are moving through enterprise environments, inheriting permissions, traversing systems, and executing decisions at machine speed with minimal oversight. The identity infrastructure built to govern human access wasn’t designed for autonomous actors, and the gap between what enterprises are deploying and what their governance programs actually cover is widening fast. This guide breaks down how the guardian agents emerged, why it matters, and what operationalizing it looks like in practice.
The Governance Gap Agentic AI Created
Identity governance has always lagged behind infrastructure change, but the arrival of production-grade agentic AI didn’t just widen the gap. It changed its shape entirely. The assumptions baked into every IAM architecture built over the past two decades are no longer sufficient for the environment most enterprises are actually running today.
Agents Aren’t Service Accounts
Security teams have spent years getting reasonably good at governing non-human identities. Service accounts get provisioned, rotated, and scoped. API keys get vaulted. Machine identities get enrolled in PAM workflows. The controls aren’t perfect, but the mental model is coherent: a non-human identity performs a defined function against a known set of resources, and you govern it by constraining what it can reach.
AI agents break every part of that model.
An agent doesn’t execute a fixed function. It receives an instruction, reasons about how to accomplish it, dynamically selects tools, chains calls across multiple systems, and delegates sub-tasks to other agents, all within a single session. The permission footprint of a single agent invocation can span a CRM, a code repository, a document store, and an internal API, touching resources that no human explicitly authorized the agent to access.
The Permission Inheritance Problem
The deepest architectural problem isn’t that agents carry too much access. It’s that they inherit access from the human or service identity they operate on behalf of, and that inherited access was scoped for an entirely different context.
When an agent executes on behalf of a sales director, it carries that person’s OAuth tokens, their delegated permissions, and any overprivileged access accumulated over years of role changes. The agent doesn’t distinguish between what the human would have done and what it’s been instructed to do. It executes with full inherited authority across every application that identity can reach.
Traditional IAM governance was built around authentication events. A human presents credentials, the system validates them, and access is granted or denied at login. Agents don’t follow that sequence. They authenticate once, often via a long-lived token or API credential, and then operate continuously across sessions, systems, and contexts without an intervening governance checkpoint.
An Architectural Problem, Not a Configuration One
IAM tools weren’t designed to observe what happens after authentication. They record the login event and stop. The entire sequence of tool calls, permission uses, data accesses, and cross-system traversals an agent performs inside a session remains invisible to the governance layer.
Agents find existing identity dark matter and move through it at machine speed. Stale delegations and over-scoped credentials that IAM teams have long deprioritized become an active attack surface the moment an agent touches them.
Governing that requires a layer purpose-built to operate where identity actually executes, not just where it authenticates.
Why Adoption Is Accelerating Now
The speed of agentic AI deployment inside enterprise environments has less to do with hype and more to do with three converging forces: models that now reliably complete multi-step reasoning tasks, infrastructure that makes orchestrating those models straightforward, and business pressure to automate knowledge work at a scale that headcount alone can’t support.
The Infrastructure Maturity Inflection Point
Twelve months ago, deploying a reliable multi-agent workflow required significant custom engineering. Today, frameworks like LangGraph, AutoGen, and Anthropic’s Model Context Protocol provide development teams with standardized primitives for agent orchestration, tool calling, memory management, and inter-agent communication. The cost of inference has dropped sharply across all major model providers, making it economically viable to run agents continuously rather than on demand. Together, these shifts moved agentic AI from proof of concept to production pipelines on timelines most security organizations didn’t anticipate.
Enterprise adoption reflects that shift. Agents now handle procurement workflows, customer support escalations, code reviews, financial reconciliations, and internal knowledge retrieval across organizations of all sizes. Line-of-business teams deploy them via low-code platforms and vendor-supplied integrations, often without any security review during provisioning.
Security Teams Are the Last to Know
The deployment pattern for agentic AI consistently repeats itself: engineering or operations teams identify a workflow to automate, a vendor provides an agent-enabled feature or API, and the agent goes live. Security teams discover it later, sometimes during an incident review, sometimes during an audit, sometimes not at all.
The 2026 market guide on guardian agents documents exactly this pattern across enterprise deployments. Governance readiness consistently lags deployment timelines, not because security teams are inattentive but because the provisioning motion for agents bypasses the identity lifecycle entirely. Agents don’t go through access request workflows. They don’t get onboarded into IGA systems. They inherit credentials from existing identities and start executing.
The result is an expanding population of autonomous identities operating across enterprise systems with no formal governance record, no ownership mapping, and no behavioral baseline. The agents are running. The question is whether anyone knows what they’re doing.
What Guardian Agents Are
A guardian agent is a purpose-built autonomous control layer that governs the identity and behavior of AI agents operating inside enterprise environments. Where traditional IAM tools govern human access and static machine identities, a guardian agent for AI operates at the execution layer, observing, analyzing, and enforcing policy against autonomous systems that act, reason, and move across applications in real time.
The term has moved from conceptual to operational. Enterprises running production agentic workloads now require a dedicated governance mechanism that keeps pace with agent activity, not one that audits it quarterly.
Continuous Identity Inventory
The first function of a digital guardian agent is discovery. Every AI agent operating in an environment carries an identity, inherits permissions, and leaves an access trail, but most enterprises lack a systematic way to enumerate which agents are running, which identities they’re acting on behalf of, or which applications they’ve touched.
A guardian agent for AI maintains a continuous, live inventory of every autonomous entity in the environment. It maps each agent to its originating identity, its owner, its permission scope, and the applications it interacts with. When a new agent spins up, provisioned through a vendor integration or deployed by a development team, the guardian agent registers it immediately rather than waiting for a manual review cycle that may never happen.
Behavioral Baselining and Anomaly Detection
Inventory alone doesn’t constitute governance. A guardian AI agent builds a behavioral baseline for each autonomous identity it monitors, tracking the pattern of tool calls, data accesses, API interactions, and cross-system movements an agent makes during normal operation.
Deviation from that baseline is where risk surfaces. An agent that begins accessing file stores outside its typical scope, calling APIs it has never used before, or escalating through a chain of delegated permissions signals a potential compromise, a prompt injection attack, or a misconfigured policy that has expanded its reach beyond its intended scope. The guardian AI agent surfaces these deviations in real time, with enough context to distinguish a legitimate workflow change from a genuine anomaly.
Runtime Policy Enforcement and Permission Scoping
Detection without enforcement is monitoring. A digital guardian agent applies a least-privilege policy at runtime, constraining what it can access during a given session based on the context of its current task, rather than the full scope of permissions its inherited identity technically allows.
Runtime scoping is the technical capability that separates guardian agents from conventional identity tooling. Rather than relying on pre-provisioned roles defined before anyone knew an agent would use them, a guardian agent for AI evaluates the current execution context and enforces permissions accordingly, dynamically tightening access as the agent moves through its workflow.
A Distinct Category from AI Security Posture Tools
A guardian AI agent is not an AI-SPM tool. AI security posture management focuses on the configuration and risk posture of AI infrastructure: model access controls, training data exposure, and API security. A guardian agent operates one layer down, governing the identity execution behavior of agents themselves, tracking what they do with the access they have, and enforcing boundaries at the moment of action rather than at the point of configuration.
How Guardian Agents Differ from Traditional IAM Tools
The instinct to govern AI agents using existing IAM tooling is understandable, and it’s wrong. Not because those tools are poorly built, but because they were engineered against a fundamentally different model of what an identity is and how it behaves. Mapping that tooling onto agentic workloads creates dangerous blind spots rather than adequate coverage.
What IGA Was Built to Do
Identity governance and administration platforms were designed to manage the lifecycle of human identities: joiner, mover, and leaver workflows, access certifications, role mining, and separation-of-duties enforcement. They work well when identities are enumerable, when access requests follow defined workflows, and when the relationship between a user and their permissions changes on a human timescale.
AI agents violate every one of those assumptions. An agent’s identity isn’t provisioned through a request workflow. Its permission scope shifts dynamically within a session. Its lifecycle doesn’t map to employment status. IGA platforms have no native concept of an agent that inherits a human identity, operates autonomously for the duration of a task, and then becomes dormant, only to reactivate under a different context with different inherited permissions the next time it runs.
Access certification campaigns can’t capture what a guardian agent for AI continuously tracks: the actual runtime behavior of an autonomous identity as it moves across systems.
Where PAM Falls Short
Privileged access management tools address a different problem. PAM assumes that high-risk access is bounded, that a human operator checks out credentials for a session, performs a defined task, and returns the credentials. The session is recorded, the access is time-limited, and the human is accountable.
Agents don’t check out credentials. They operate through inherited OAuth delegations, service account bindings, or API keys embedded in orchestration configurations. A PAM tool sees none of that. It governs the vault, not the execution path the agent takes once it’s operating with credentials obtained entirely outside the PAM workflow.
When an agent traverses four systems in a single session using a delegated OAuth token, PAM has no visibility into any part of that traversal. A digital guardian agent does.
The CIEM Boundary Problem
Cloud infrastructure entitlement management tools brought meaningful progress on the non-human identity problem, particularly for cloud service principals, IAM roles, and workload identities operating within a single cloud environment. The limitation is the boundary itself.
Agentic workloads routinely span multiple clouds, SaaS applications, self-hosted systems, and third-party API integrations within a single workflow. CIEM tools govern entitlements within their supported platforms. They don’t follow an agent as it moves from an AWS service role to a SaaS CRM to an internal document management system, accumulating effective permissions across each hop.
A guardian AI agent operates across that entire surface, maintaining a unified view of what each autonomous identity can access and what it actually did, regardless of which platform boundary it crossed.
The Core Architectural Difference
Traditional IAM tools answer identity questions at provisioning time or at the authentication boundary. A guardian agent for AI answers them at execution time, inside the session, at the application layer, where permissions are actually exercised.
The difference isn’t incremental. Governing an autonomous identity that reasons, delegates, and acts requires a control plane that reasons alongside it, observing behavior in motion rather than auditing access after the fact.
Common Risks: How Unmanaged Agents Become Identity Dark Matter
Unmanaged AI agents don’t announce themselves as a security problem. They accumulate as one. Each agent that deploys without a governance record, inherits permissions without review, and operates without behavioral oversight adds to a growing population of autonomous identities that security teams can’t see, audit, or control. Orchid Security calls this identity dark matter: the mass of identity activity that exists and exerts real risk inside an environment while remaining invisible to the tools responsible for governing it.
Over-Privileged Agent Identities
The most pervasive risk pattern starts at provisioning. When an agent deploys by binding to an existing service account or human identity, it inherits the full permission scope of that identity, regardless of what the agent actually needs. A code review agent bound to a senior engineer’s identity might inherit access to production infrastructure, financial systems, and HR data accumulated over years of role changes. The agent needs none of it, but carries all of it into every session it runs.
Over-privileged agent identities are the rule in unmanaged deployments. Because agents bypass access-request workflows, no one applies least-privilege scoping at provisioning time. The permissions are already there, and binding an agent to an existing identity is the path of least resistance.
Orphaned Sessions and Stale Credentials
Agent sessions don’t always terminate cleanly. Long-running agents and scheduled automation tasks can maintain active credentials well beyond the duration of the task they were created for. When an agent is decommissioned or simply forgotten, the credentials it used often remain valid.
Stale agent credentials are particularly dangerous in SaaS environments where token revocation requires deliberate action against each connected application. An orphaned agent operating through a long-lived OAuth token can retain access to sensitive systems for months after anyone last intentionally invoked it.
Prompt Injection as a Privilege Escalation Vector
Prompt injection attacks target agents directly. An attacker embeds malicious instructions in content the agent processes: a document it summarizes, a web page it retrieves, a ticket it reads. The agent incorporates those instructions into its reasoning and takes actions that the legitimate user never authorized. In environments where agents operate with overprivileged inherited identities, prompt injection becomes a reliable path to privilege escalation without touching credentials at all.
Lateral Movement Through Chained Agent Calls
Multi-agent architectures introduce compounding risk. When an orchestrator agent delegates sub-tasks to specialized child agents, each delegation transfers a portion of the orchestrator’s authority. A compromise at any point in that chain propagates downstream, giving an attacker effective access to every system the trust chain touches.
The audit trail problem makes all of this harder to contain. Agents operating across unmanaged SaaS applications leave no coherent forensic record in existing security tooling. When an incident occurs, security teams reconstruct what happened from fragmented logs across disconnected systems, often without enough fidelity to determine which agent took which action on whose behalf.
Putting this into your identity governance program requires treating agent identities with the same rigor applied to privileged human accounts: continuous inventory, ownership mapping, behavioral monitoring, and a full audit record across every application each autonomous identity touches.
How to Bring AI Agents into the Light
Getting AI agents under governance control is an operational capability that security and identity teams need to continually build as agent deployments continue to grow. The following sequence reflects how mature organizations are approaching it, moving from visibility to classification to enforcement to integration.
1. Start with Discovery: Know What’s Running
Governance starts with an accurate inventory, and most enterprises don’t have one. The first operational step is deploying discovery mechanisms that identify every AI agent active in the environment, regardless of how it was provisioned or which team deployed it.
Effective discovery operates at the application layer. Network-level monitoring captures traffic patterns but can’t attribute them to specific agent identities or map them to the human identities those agents act on behalf of. Application-layer discovery surfaces the agent, its credential bindings, its permission inheritance, and its operational context, all the information needed to make a governance decision.
2. Classify by Trust Level and Permission Scope
Not every agent carries the same risk. Once an inventory exists, classify each agent by the sensitivity of the permissions it holds, the systems it can reach, and the trust level of its originating identity. An agent operating with read-only access to a single internal knowledge base carries a fundamentally different risk profile than one holding delegated OAuth tokens to a financial system and a customer data platform simultaneously.
Classification drives prioritization. Agents with broad permission inheritance and connections to sensitive systems warrant immediate least-privilege remediation. Agents with narrow, well-scoped access warrant monitoring and periodic review. Without classification, every agent looks the same, and remediation effort is distributed without regard to the actual concentration of risk.
3. Enforce Least-Privilege at Runtime, Not at Provisioning
Static scoping at provisioning time degrades quickly. As agents are reused for new tasks, their permissions drift, and the inherited credentials they carry rarely get updated to reflect actual requirements. Runtime enforcement through a guardian agent for AI dynamically applies least privilege, constraining what each agent can access based on the context of its current task rather than on the broadest permissions its identity technically allows.
Runtime enforcement also contains the blast radius of a compromise. A prompt injection attack against an agent operating under tight runtime scoping reaches far less than the same attack against an agent running with its full inherited permissions active.
4. Integrate with Existing IAM and IGA Stacks
A guardian AI agent doesn’t replace the IAM infrastructure already in place. It extends it. Agent identity data feeds into IGA platforms to enable access certification, into PAM tools to flag credential exposure, and into SIEM systems to enrich alert context with agent behavioral history. The integration layer transforms agent governance from a standalone capability into a live input to the broader identity security platform, giving every downstream tool more accurate information about what’s actually executing in the environment.
How Orchid Security Helps
The governance gap described throughout this guide is what Orchid Security is built to close. The platform operates as a continuous identity control plane across human, machine, and agentic identities, providing security and identity teams with the visibility and enforcement capabilities that existing IAM tooling doesn’t provide.
Continuous Discovery Across Every Identity Type
Orchid’s discovery engine automatically inventories every application, account, and authentication flow in an environment, managed or otherwise. When AI agents spin up, whether through vendor integrations, internal deployments, or low-code automation platforms, Orchid surfaces them, maps them to their originating identities, and enriches them with ownership, permission scope, and business context. Security teams get an accurate, continuously updated picture of what’s running rather than a static snapshot that degrades the moment it’s produced.
From Visibility to Enforcement
The guardrails for the autonomous identity use case apply Orchid’s identity control plane directly to agentic workloads. Every agent gets mapped to an accountable human owner. Runtime guardrails enforce least-privilege at the execution layer. Behavioral observability tracks what agents actually do across tool calls, data accesses, and cross-system movements, surfacing anomalies before they become incidents.
Orchid also integrates with existing IAM programs and GRC workflows, feeding continuous agent identity telemetry into the tools already governing the rest of the environment. For teams building out their identity governance program, that telemetry becomes the connective tissue between agent activity and enterprise-wide identity policy.
The result is an identity infrastructure that governs the autonomous workforce with the same rigor it applies to human identities, at the speed agents actually operate.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
Un actor de amenaza persistente avanzada (APT) de habla china ha sido vinculado a una nueva puerta trasera personalizada llamada TinyRCT como parte de ataques cibernéticos dirigidos a entidades gubernamentales e infraestructura crítica en el sudeste asiático.
La actividad, particularmente dirigida a empresas estatales en los sectores energético y gubernamental, ha sido atribuida a un actor de amenazas llamado CL-STA-1062que según la Unidad 42 de Palo Alto Networks comparte se superpone con UAT-7237, un grupo de piratería que fue señalado por primera vez por Cisco Talos en agosto de 2025 en relación con una campaña dirigida contra entidades de infraestructura web en Taiwán.
La Unidad 42 dijo que también observó campañas CL-STA-1062 en operaciones anteriores dirigidas a sectores estratégicos en el este de Asia desde marzo de 2022, lo que sugiere un enfoque más amplio pero sostenido en la región.
«Desde un punto de vista técnico, los atacantes detrás de CL-STA-1062 se basan en un conjunto de herramientas híbrido», Unidad 42 dicho en un informe técnico. «Si bien utilizan con frecuencia herramientas comunes de código abierto como SoftEther VPN, Mimikatz y VNT, recientemente introdujeron TinyRCT, una puerta trasera hecha a medida y que antes no estaba documentada».
TinyRCT está equipado para ejecutar comandos arbitrarios, enumerar archivos y filtrarlos, capturar la pantalla del dispositivo y eliminarse del host comprometido.
En una campaña detectada en septiembre de 2025, se dice que el actor de amenazas se infiltró en una entidad gubernamental del sudeste asiático y desplegó un shell web para extraer datos de un servidor MS SQL. Durante el mismo ataque, se descubrió que los actores de la amenaza realizaban reconocimiento de red en una entidad gubernamental separada en el mismo país.
«Esto sugiere un esfuerzo para identificar oportunidades de movimiento lateral y ampliar su acceso. En un caso, observamos al atacante organizar y exfiltrar un directorio completo de código fuente del servidor web de la entidad gubernamental», dijo la Unidad 42, agregando que detectó la violación de al menos 10 organizaciones diferentes en el sudeste asiático entre octubre y diciembre de 2025.
Desde al menos mediados de 2025, CL-STA-1062 ha centrado su mirada en la infraestructura crítica, con el adversario escaneando múltiples entidades en la región en busca de vulnerabilidades y luego estableciendo un punto de apoyo a través de shells web ASPX que facilitan el reconocimiento inicial y las solicitudes salientes de las redes infectadas a la infraestructura controlada por el atacante, lo que lleva al despliegue de cargas útiles adicionales.
Esto incluye componentes de SoftEther VPN y archivos RAR que contienen el conjunto de herramientas del grupo, incluidas utilidades de código abierto como yuze (un proxy SOCKS5) y VNT (una VPN), a menudo disfrazándolos como ejecutables de VMware o un agente XDR (por ejemplo, «XDRAgent.exe», «vmtools.exe» y «vmwared.exe»).
Un análisis más profundo de la infraestructura de la campaña ha llevado al descubrimiento de una puerta trasera .NET no documentada anteriormente denominada TinyRCT («PerfWatson2.exe»), un troyano ligero de acceso remoto que permite el reconocimiento del sistema, la ejecución de comandos, la carga de archivos, la captura de capturas de pantalla, el control remoto y el borrado de rastros de sí mismo, mientras toma medidas para evitar la ejecución en entornos aislados.
Establece un canal de comunicación persistente con un servidor remoto («45.32.113[.]172») a través de HTTP, pero cifra los datos intercambiados utilizando cifrado AES-128 en modo CBC.
«El malware opera en un modelo de baliza, con un intervalo de suspensión predeterminado de 10 segundos entre solicitudes», explicó la Unidad 42. «Sondea el servidor C2 en busca de instrucciones mediante solicitudes GET, mientras envía datos exfiltrados mediante solicitudes POST».
En cuanto a cómo se entrega TinyRCT, toma la forma de un archivo malicioso llamado «chrome_setup.zip» que contiene un ejecutable legítimo («chrome_setup.exe»), un archivo de configuración («chrome_setup.exe.config») y una DLL fraudulenta («MyAppDomainManager.dll») que se utiliza para desencadenar un Inyección de AppDomainManager ataque para cargar la DLL maliciosa, que funciona como un descargador comunicándose con «139.180.134[.]221» para recuperar «PerfWatson2.exe».
«La combinación de herramientas observada en este grupo de actividades refleja un enfoque pragmático en la selección de herramientas y capacidades de ataque», concluyó la Unidad 42. «Los atacantes detrás de este grupo continúan aprovechando herramientas comunes de código abierto como SoftEther VPN y VNT para facilitar el movimiento lateral».
«Nuestro descubrimiento de la puerta trasera TinyRCT en la infraestructura de los atacantes subraya su capacidad de personalizar herramientas para obtener capacidades específicas. La combinación de apuntar a la infraestructura crítica y el desarrollo de malware personalizado sugiere que la actividad CL-STA-1062 seguirá representando una amenaza para la región».
