31 de Julio de 2026

Las pruebas compartidas incluían la misma vulnerabilidad de acceso inicial, nombres de archivo y patrones de ejecución de malware, la huella digital de la clave SSH y la infraestructura de red. AhnLab señaló que las pruebas no confirman que un mismo actor haya llevado a cabo ambas operaciones. El informe no especifica qué pruebas llevaron a incluir a una organización en la cifra total, por lo que el número 72 no representa un recuento de compromisos totales confirmados por igual. El aviso no identifica al grupo patrocinado por el Estado.
Suficiente con visitar una página
El aviso conjunto fue emitido por KISA, el Servicio de Inteligencia Nacional, la Agencia de Policía Nacional y el Instituto de Seguridad Financiera, basándose en análisis realizados junto con AhnLab, S2W, ENKI Whitehat y Plainbit. KISA informó que se siguen detectando ataques de *phishing* y de tipo *watering hole* (sitio web comprometido) patrocinados por el Estado de esta índole. Los informes públicos no indican si los atacantes continuaron explotando AnySign4PC una vez que estuvo disponible la versión 1.1.5.0.
Los atacantes enviaron mensajes de *spear-phishing* (phishing dirigido) disfrazados de currículums, propuestas de contratación, material de inversión y encuestas del sector. Asimismo, comprometieron sitios web de noticias, salud, educación y manufactura, así como sitios más pequeños y con escasa seguridad que probablemente visitarían sus víctimas objetivo. ENKI Whitehat identificó AnySign4PC —un software utilizado para firmas electrónicas basadas en certificados— como uno de los productos vulnerables y señaló que los atacantes habían explotado una vulnerabilidad de día cero. ENKI observó esta actividad desde la segunda mitad de 2025, antes de que KISA publicara su aviso de parche en junio de 2026.

El informe de AhnLab sobre la «Operación Double Barrel» describe una cadena de explotación que utilizaba cuatro imágenes PNG para intercambiar claves, verificar la versión del software instalado, desplegar código de explotación específico para esa versión e informar si la ejecución había tenido éxito. La página maliciosa se comunicaba con el programa de seguridad local mediante WebSocket y provocaba un desbordamiento de búfer para ejecutar *shellcode*. A continuación, la carga útil (*payload*) se inyectaba en procesos legítimos de Microsoft. Dependiendo de la intrusión, los atacantes instalaban Struggle —que AhnLab asocia con SIGNBT 3.0— o Brandoor, nombre que la empresa asigna a la puerta trasera COPPERHEDGE. El malware permitía la ejecución remota de comandos, el robo de archivos, el reconocimiento interno, la inyección de procesos y la entrega de cargas útiles adicionales.
Plainbit reconstruyó de forma independiente uno de los incidentes de tipo *watering-hole* (ataque de abrevadero) en su informe forense. Los atacantes mapearon los sistemas de la víctima expuestos a Internet, comprometieron su sitio web, instalaron una *webshell* e insertaron código JavaScript en una página legítima de noticias. Cuando un objetivo visitaba dicha página, el programa de seguridad vulnerable generaba un error y creaba una DLL maliciosa sin mostrar ninguna solicitud de descarga ni requerir interacción alguna por parte del usuario. La puerta trasera resultante descifraba fases posteriores en la memoria, inyectaba código en svchost.exe y leía información de comando y control desde el registro de Windows. Posteriormente, los atacantes utilizaron *exploits* de escalada de privilegios, Mimikatz y otras herramientas de obtención de credenciales, conexiones mediante el Protocolo de Escritorio Remoto (RDP) y NLBrute para desplazarse por la red.
La puerta trasera resultante descifraba fases posteriores en la memoria, inyectaba código en svchost.exe y leía información de comando y control desde el registro de Windows. Posteriormente, los atacantes utilizaron *exploits* de escalada de privilegios, Mimikatz y otras herramientas de obtención de credenciales, conexiones mediante el Protocolo de Escritorio Remoto (RDP) y NLBrute para desplazarse por la red.
El análisis de S2W sobre tres grupos de *malware* reveló un patrón recurrente de carga lateral de DLL (*DLL side-loading*), bloques de datos cifrados en el registro y carga de ejecutables portables (PE) directamente en la memoria. Dos de los grupos desplegaron las versiones 0.0.1 y 1.2 de SIGNBT, mientras que un tercer cargador descifraba una carga útil externa que los investigadores no pudieron recuperar.
El rastro de Gunra
Una intrusión del *ransomware* Gunra ocurrida en marzo de 2026 utilizó el mismo sitio web del sector sanitario comprometido y la misma vulnerabilidad en el producto que AhnLab denomina «software de seguridad financiera A». Tanto la cadena de ataque patrocinada por un Estado como la del *ransomware* inyectaron código en SyncHost.exe. AhnLab no identifica el «software A», por lo que el informe no confirma que la vulnerabilidad asociada a Gunra fuera AnySign4PC.
AhnLab también descubrió que ambas operaciones utilizaban los nombres de archivo net.tmp e inet.tmp. El argumento para inet.tmp era idéntico, mientras que los argumentos para net.tmp seguían un formato GUID similar. Ambas operaciones emplearon la misma huella digital de clave pública SSH:
- Qr1to32lQHxEu6phzNyrTZrU0iElrOfVWMBLnqoen24.
Asimismo, utilizaron la misma dirección para túneles inversos: 176.65.128[.]26. El dominio jshosting[.]me se utilizó para distribuir *scripts* de *exploit* en ambos conjuntos de ataques. Los atacantes siguieron también el mismo procedimiento antiforense, renombrando los archivos maliciosos con nombres aleatorios de cuatro caracteres antes de eliminarlos. Plainbit observó la destrucción adicional de evidencias mediante el uso de SDelete y CCleaner.
AhnLab determinó que las pruebas apuntan a una probable conexión técnica, pero señaló que no era posible establecer la naturaleza de la relación entre los operadores. La empresa enumeró varias explicaciones posibles, entre ellas una colaboración limitada, el uso compartido de herramientas o infraestructura, la utilización de un intermediario de acceso común o el acceso a los mismos recursos operativos. Las coincidencias revelan una vía de acceso compartida o reutilizada que parte del sitio web comprometido y se extiende a través de la ejecución en el host y la infraestructura de soporte. Sin embargo, no demuestran que el mismo operador haya controlado ambos ataques.
Según una investigación independiente de S2W, Gunra opera bajo un modelo de *ransomware* como servicio.
La firma informó que, para el 9 de marzo de 2026, la operación había afectado a 32 empresas —incluidas cinco compañías surcoreanas— y que había evolucionado desde el uso de *ransomware* derivado de Conti hacia sus propias versiones para Windows y Linux. El actual aviso gubernamental y el informe de la «Operación Double Barrel» describen al operador —centrado en el espionaje— únicamente como un grupo de amenazas patrocinado por el Estado. Ninguno de los documentos atribuye formalmente a Lazarus la totalidad de la campaña desarrollada entre 2025 y 2026, ni establece una conexión entre Lazarus y Gunra.
No obstante, en un informe independiente publicado en abril, AhnLab atribuyó a Lazarus un ataque de tipo *watering hole* (trampa en sitio web) contra AnySign4PC ocurrido en marzo de 2026. Kaspersky también documentó el uso por parte de Lazarus de ataques *watering hole*, software de seguridad surcoreano, SIGNBT y COPPERHEDGE durante la anterior «Operación SyncHole«. Dichos informes documentan el uso previo por parte de Lazarus de AnySign4PC, SIGNBT, COPPERHEDGE y la explotación de ataques *watering hole*, pero no atribuyen a Lazarus la «Operación Double Barrel» ni las intrusiones de Gunra.
El aviso de seguridad de KISA del 1 de junio identifica las versiones de AnySign4PC de la 1.1.4.4 a la 1.1.4.6 como vulnerables a un desbordamiento de búfer que permite la ejecución remota de código. Señala la versión 1.1.5.0 como la versión corregida y recomienda eliminar las instalaciones vulnerables.
Los informes recomiendan buscar indicios como la carga sospechosa de archivos DLL por parte de ejecutables legítimos, datos cifrados almacenados en entradas del registro de servicios, ejecución de archivos PE en memoria, creación inusual de servicios, inyección en SyncHost.exe o svchost.exe y túneles SSH salientes inesperados.
ENKI descubrió que su puerta trasera (backdoor) de Tipo 1 eliminaba su configuración del registro, el cargador y los archivos de la propia puerta trasera tras copiarlos en la memoria al ejecutarse en los modos 1, 2, 4 o 5 con la autoprotección activada. Una vez iniciada, los archivos desaparecían del disco hasta que un apagado limpio los volvía a escribir, y el cargador restaurado presentaba un hash diferente. Esto hace que la telemetría de comportamiento sea más útil que un indicador basado en archivos estáticos.
Plainbit observó una cadena de persistencia en la que una tarea programada llamada RuntimeBroker iniciaba task.vbs; este script ejecutaba a continuación un cliente SSH renombrado como SearchHost.exe para establecer un túnel inverso. S2W aconseja preservar la memoria del proceso, las líneas de comandos, los valores del registro, los eventos de carga de DLL y los registros de red antes de finalizar los procesos o aislar los sistemas.
AhnLab también descubrió que varios sitios web comprometidos estaban vinculados a la misma empresa de desarrollo y gestión, lo que describió como una posible vía de ataque a la cadena de suministro. Las pruebas disponibles no confirman que el código fuente, el proceso de actualización de software o la plataforma de gestión central de dicha empresa se vieran comprometidos.
El aviso de KISA del 1 de junio no incluye un identificador CVE para la vulnerabilidad de AnySign4PC. A fecha de 30 de julio de 2026, The Hacker News solo encontró el CVE-2020-7882 en las búsquedas públicas del programa CVE y de la NVD para AnySign4PC; se trata de una vulnerabilidad de recorrido de directorios (directory traversal) no relacionada que afectaba a versiones anteriores. Este resultado no descarta la existencia de un identificador reservado, no publicado o descrito de otra manera. El software «A» y el «I» mencionados por AhnLab permanecen sin identificar en su informe, el cual tampoco revela las versiones afectadas ni las corregidas.