Una investigación conjunta de autoridades surcoreanas y varias firmas de seguridad advierte sobre una campaña de intrusión respaldada por un actor estatal. El objetivo fue aprovechar sitios web de confianza en Corea del Sur para comprometer equipos que tenían instalada una versión vulnerable de AnySign4PC, instalando AnySign4PC backdoors sin que el usuario realizara una descarga o interacción.
La alerta describe un flujo en el que una página comprometida bastaba para ejecutar el ataque cuando un visitante caía en el escenario correcto. A continuación, resumimos qué se sabe sobre las versiones afectadas, cómo operaron los atacantes y qué acciones prácticas recomiendan los investigadores para reducir el riesgo.
Qué pasó: sitios legítimos como punto de entrada
Según el aviso conjunto, los atacantes comprometieron sitios domésticos que eran “visitables” para las víctimas previstas. Entre los ejemplos mencionados aparecen medios de noticias, instituciones de salud, educación y entornos industriales, además de webs pequeñas con medidas de seguridad insuficientes.
El patrón reportado combina técnicas de phishing (mensajes suplantando currículums, procesos de contratación, material de inversión o encuestas) y watering-hole. En el segundo caso, el contenido malicioso se alojaba dentro de recursos del sitio legítimo comprometido, de modo que el sistema del visitante quedaba expuesto al problema del software instalado.
AnySign4PC backdoors: explotación sin descarga ni aviso
Lo más preocupante es que, en los casos descritos, una visita a la página comprometida podía desencadenar la intrusión. En particular, el material analizado indica que el atacante podía explotar la versión del programa de firma electrónica instalada localmente y proceder con la infección sin prompts y sin una descarga iniciada por el usuario.
La Korea Internet & Security Agency (KISA) señala que las versiones 1.1.4.4 a 1.1.4.6 están afectadas. Como corrección, recomienda eliminar instalaciones vulnerables y especifica que la versión 1.1.5.0 es la publicación corregida.
En el lado privado, AhnLab se refiere a dos productos explotados únicamente como “software de seguridad financiera A” e “I”, sin revelar identidades, versiones afectadas, versiones corregidas ni identificadores de vulnerabilidad. Esto impide, por ahora, verificar con precisión el alcance exacto de cada componente más allá de la señal general de riesgo.
Campaña y evidencias: herramientas, patrones y límites de atribución
Los informes describen una operación con evidencia compartida entre incidentes: se mencionan el mismo tipo de falla de acceso inicial, nombres de archivos de malware y patrones de ejecución, además de huellas y conexiones asociadas a la infraestructura del atacante.
AhnLab estima que encontró indicios relacionados en 72 organizaciones durante 2026. Sin embargo, el propio análisis aclara que ese número no equivale necesariamente a un recuento de compromisos completos confirmados por igual. El documento tampoco proporciona detalles sobre qué criterio exacto se usó para incluir cada organización en esa cifra.
Además, los documentos señalan que la evidencia no prueba que una sola entidad controlara ambas operaciones descritas. Se plantean explicaciones alternativas como colaboración limitada, reutilización de herramientas o infraestructura, uso de un “broker” de acceso común o empleo de recursos operacionales compartidos.
La cadena de explotación: de imágenes PNG a código en procesos
Uno de los reportes de investigación, conocido como “Operation Double Barrel”, describe una cadena técnica que usa cuatro imágenes PNG para intercambiar claves, verificar la versión instalada, entregar el código de explotación específico y reportar si la ejecución tuvo éxito.
Tras esto, la página maliciosa se comunica con el software local de seguridad por WebSocket. El siguiente paso descrito implica un desbordamiento de búfer para ejecutar shellcode.
Luego, el payload se inyecta en procesos legítimos de Microsoft. Dependiendo del escenario de intrusión, los investigadores mencionan instalaciones de dos variantes: “Struggle”, asociado por AhnLab a SIGNBT 3.0, o “Brandoor”, nombre usado para COPPERHEDGE. En general, el malware resultante incluye capacidades como ejecución remota de comandos, robo de archivos, reconocimiento interno, inyección de procesos y entrega de etapas adicionales.
Persistencia y ejecución: shells, DLL y carga en memoria
En una reconstrucción forense independiente, Plainbit relata un incidente de watering-hole donde el atacante añadió un webshell y además insertó JavaScript dentro de una página legítima de noticias. Cuando una víctima visitaba la página, el software de seguridad vulnerable generaba un error y creaba una DLL maliciosa sin necesidad de descargas ni interacción visible.
La etapa resultante descifra fases posteriores en memoria, inyecta código en svchost.exe y obtiene información de control y comunicaciones desde el Registro de Windows. Posteriormente, los atacantes se movían lateralmente con técnicas de escalada de privilegios y herramientas como Mimikatz, además de conexiones mediante Remote Desktop Protocol y el uso de NLBrute.
Por su parte, S2W analiza clústeres de malware y observa un patrón recurrente de DLL side-loading, blobs cifrados en entradas del Registro y carga de ejecutables portables en memoria. Dos clústeres despliegan versiones específicas de SIGNBT, mientras que otro cargador se describe como capaz de descifrar un payload externo que los investigadores no pudieron recuperar.
El rastro hacia Gunra: reutilización de infraestructura y técnicas
La alerta también conecta, al menos de forma técnica, un caso de ransomware Gunra con un escenario anterior. En marzo de 2026, una intrusión de ransomware vinculada a Gunra habría usado el mismo sitio de atención médica comprometido y una vulnerabilidad explotada en el producto “software de seguridad financiera A” (el nombre real no se revela en el informe).
El documento indica que, tanto en el caso respaldado por el Estado como en la cadena de ransomware, se inyecta código en SyncHost.exe. Aun así, la ausencia de identificación del software A impide confirmar si la vulnerabilidad de Gunra corresponde específicamente a AnySign4PC.
Además, se reporta reutilización de nombres de archivo (“net.tmp” e “inet.tmp”), así como un formato similar en argumentos y una misma huella de clave pública SSH. También se menciona una dirección de túnel inverso concreta y el dominio “jshosting[.]me” como parte del reparto de scripts de explotación en ambos conjuntos de ataques.
En cuanto a anti-forense, AhnLab describe que el operador renombraba archivos maliciosos con nombres aleatorios de cuatro caracteres antes de eliminarlos. Plainbit añade evidencias de destrucción adicional usando herramientas como SDelete y CCleaner.
Señales de compromiso y qué buscar tras el parche
Tras recibir la información de KISA, el punto práctico es actuar sobre el riesgo del componente. La guía recomienda:
- Actualizar al reparar y retirar instalaciones vulnerables, especialmente si está presente AnySign4PC en rangos afectados.
- Buscar señales relacionadas con carga sospechosa de DLL por ejecutables legítimos.
- Revisar datos cifrados guardados en entradas asociadas al Registro.
- Vigilar ejecuciones en memoria de PE (Portable Executable).
- Detectar creación inusual de servicios, e inyecciones en SyncHost.exe o svchost.exe.
- Atender a túneles SSH salientes inesperados.
ENKI, por ejemplo, identifica un comportamiento particular del backdoor: en ciertos modos de ejecución elimina su configuración, cargador y archivos del disco al copiarse a memoria bajo protección propia. Tras inicializarse, los archivos no se mantienen en el sistema hasta un apagado limpio donde se restauran con cambios de hash. Este detalle refuerza la idea de que la telemetría conductual puede ser más útil que indicadores basados solo en archivos estables.
También se documenta una cadena de persistencia con una tarea programada que lanza un script y luego ejecuta un cliente SSH renombrado para establecer un túnel inverso. Por eso, S2W aconseja conservar memoria del proceso, líneas de comando, valores de Registro, eventos de carga de DLL y registros de red antes de cerrar, aislar o eliminar sistemas.
Sobre Lazarus y el alcance de la atribución
En estos reportes, la campaña se describe como una amenaza respaldada por un Estado, pero sin atribución completa formal al grupo “Lazarus” en la totalidad del periodo 2025 a 2026. Los documentos no conectan explícitamente a Lazarus con el caso de Gunra.
No obstante, AhnLab sí atribuye un ataque de watering-hole de marzo de 2026, ligado a AnySign4PC, a Lazarus en un informe separado publicado en abril. Asimismo, Kaspersky documenta que Lazarus usó watering holes, software de seguridad surcoreano y backdoors como SIGNBT y COPPERHEDGE en una operación anterior llamada “Operation SyncHole”.
En conjunto, estas fuentes sugieren reutilización de técnicas y componentes en distintos momentos, aunque el material disponible en el aviso actual no confirma que el conjunto “Double Barrel” y la intrusión de Gunra provengan del mismo operador.
Conclusión: respuesta rápida y caza de comportamiento
La campaña descrita muestra cómo los atacantes pueden convertir sitios aparentemente confiables en vectores para explotar software instalado localmente. En el caso de AnySign4PC backdoors, el riesgo se amplifica porque la infección puede ocurrir sin descarga ni acción del usuario, simplemente al visitar una página manipulada.
Si usas AnySign4PC, prioriza la actualización a la versión corregida (1.1.5.0) y elimina instalaciones vulnerables dentro del rango indicado. Después, realiza una búsqueda activa de comportamientos sospechosos: carga anómala de DLL, ejecución en memoria, inyecciones en procesos del sistema y túneles SSH inesperados.
Con una estrategia basada en señales de comportamiento y preservación de evidencias, las organizaciones mejoran su capacidad para detectar intrusiones como las descritas y reducir el impacto de futuras campañas similares.
Fuente: https://thehackernews.com/2026/07/hackers-exploit-anysign4pc-via-hacked.html
