Operação XENOFISCAL: SideCopy implanta XenoRAT persistente visando o Ministério das Finanças do Afeganistão.

Autores: Dixit Panchal e Vaibhav Krushna Billade

Sumário:

• Introdução:
• Principais alvos:
• Cadeia de infecção:
• Resultados iniciais sobre a campanha:
• Análise do Decoy:
• Análise técnica:
  • Etapa 1: Análise do arquivo LNK.
  • Etapa 2: Análise da carga útil HTA/JavaScript
  • Etapa 3: Análise da DLL do carregador da Etapa 1
  • Etapa 4: Análise da DLL do carregador da Etapa 2 e do Shellcode
  • Etapa 5: Análise do XenoRAT.
• Artefatos de infraestrutura e atribuições de agentes de ameaça.
• Conclusão: Operação XENOFISCAL?
• Seqrite Cobertura:
• COI:
• MITRE ATT&CK:

Introdução:

Seqrite O Labs tem monitorado ativamente campanhas de spear phishing em todo o mundo e possui um histórico consolidado de rastreamento do cluster APT SideCopy — um grupo de ameaças ligado ao Paquistão que opera sob o guarda-chuva mais amplo do Transparent Tribe/APT36. Dando continuidade a esse esforço de rastreamento, identificamos uma campanha direcionada ao Ministério das Finanças do Afeganistão, com TTPs (Táticas, Técnicas e Procedimentos) que se sobrepõem aos do SideCopy com um nível de confiança de médio a alto.

A campanha começa com uma tentativa de spear phishing — um arquivo ZIP contendo um arquivo LNK malicioso com um nome cuidadosamente elaborado em pashto:

د_هغو_کارکوونکو_لېست_چې_د_فکري_او_رواني_جګړې_سیمینار_ته_ورپېژندل_شوي_وو12.pdf.lnk (“Lista de funcionários que eram Apresentado ao Seminário de Guerra Intelectual e Psicológica”)

A escolha do pashto é deliberada. É a língua dominante nas instituições governamentais do Afeganistão e o idioma principal dos alvos pretendidos — funcionários financeiros provinciais que atuam nos 34 distritos afegãos (Mustoufiates). Ao estruturar a isca em torno de um seminário sobre guerra psicológica e intelectual, o agente demonstrou conhecimento preciso do contexto operacional e administrativo de seus alvos.

O que se segue neste relatório é uma análise técnica completa da campanha — desde a cadeia de execução do LNK até o envio do sinal de localização do implante XenoRAT para a infraestrutura europeia à prova de balas — juntamente com mudanças de infraestrutura, análise de documentos de isca e mapeamento de atribuição em relação à linha de base TTP conhecida do SideCopy.

Principais alvos:

• Ministério das Finanças do Emirado Islâmico do Afeganistão.
• Diretorias Provinciais de Receita e Finanças (Mustoufiats).
• Funcionários do governo que falam pashto.
• Funcionários do governo provincial, não do ministério central.

Cadeia de infecção:

Resultados iniciais sobre a campanha:

Durante nossa análise, observamos que o agente da ameaça iniciou o ataque por meio de um arquivo ZIP distribuído via spear phishing, contendo um arquivo LNK malicioso criado em pashto — uma escolha deliberada que reflete um profundo conhecimento do ambiente alvo.

Uma vez executado, o LNK utiliza silenciosamente o mshta.exe para obter um payload HTA remoto de um domínio educacional afegão comprometido, que decodifica o JavaScript ofuscado na memória, estabelece persistência baseada no Registro camuflada como uma entrada do Microsoft Edge e, por fim, implanta o XenoRAT 1.8.7 — enviando sinais para uma infraestrutura de hospedagem europeia à prova de falhas, totalmente separada da camada de entrega, garantindo resiliência a longo prazo.

Análise do Decoy:

O documento falso lançado durante a execução é um diretório de funcionários provinciais do Ministério das Finanças do Afeganistão, abrangendo todas as 34 províncias, listando diretores de finanças, chefes de receita, funcionários financeiros e secretários, juntamente com seus números de telefone celular diretos — escrito inteiramente em dari e pashto.

O nível de detalhamento organizacional sugere coleta prévia de informações por parte do agente da ameaça. Seu papel no ataque é simples: enquanto a vítima lê o que parece ser um documento interno rotineiro do governo, o malware já concluiu silenciosamente sua instalação em segundo plano.

Análise técnica:

Etapa 1: Análise do arquivo LNK.

O arquivo LNK atua como vetor de infecção inicial e gatilho de execução na cadeia de ataque. Embora disfarçado com um ícone de PDF e um nome de arquivo enganoso para parecer um documento legítimo, a inspeção das propriedades do atalho revela que ele inicia o utilitário do Windows mshta.exe a partir de C:\Windows\System32. O comando incorporado no atalho aponta para um recurso PHP malicioso remoto hospedado via HTTPS ( hxxp[:]//< abimj.edu.af >/index.php ), permitindo que o atacante execute conteúdo de script hospedado externamente diretamente na memória, sem precisar gravar um executável no disco. Isso ocorre por meio do abuso do mshta.exe — um binário legítimo da Microsoft comumente associado à execução de aplicativos HTML (HTA).

O atacante utiliza a técnica LOLBIN (Living-off-the-Land Binary) para burlar os mecanismos de detecção tradicionais e evitar suspeitas por parte do usuário. O uso excessivo de vírgulas para ofuscar a estrutura da URL indica ainda uma tentativa de dificultar a análise estática e a detecção baseada em assinaturas.

Etapa 2: Análise da carga útil HTA/JavaScript

O payload PHP remoto obtido através do mshta.exe contém código JavaScript fortemente ofuscado, projetado para executar lógica maliciosa no contexto do mecanismo HTA. Uma inspeção inicial revela a presença de arrays de strings codificadas, como _$_f1bf=[“\x55\x33\x6…”], um método comum de ofuscação usado para ocultar nomes de funções, URLs, comandos ou payloads secundários de analistas e ferramentas de segurança. O script também define textos de janela enganosos, como “Erro de Arquivo do Windows”, para imitar o comportamento legítimo do sistema e potencialmente distrair a vítima durante a execução. Esta etapa serve como a principal camada de execução e entrega da campanha, onde o JavaScript ofuscado provavelmente é decodificado dinamicamente para executar ações subsequentes, como obtenção do payload, execução de comandos, estabelecimento de persistência ou exfiltração de dados.

Analisando um JScript ofuscado

Após análise, o arquivo .js foi identificado como um carregador de malware baseado em JScript, altamente ofuscado, projetado para ser executado em ambientes Windows Script Host (WSH) ou em versões antigas do Internet Explorer com suporte a ActiveX habilitado. O script incorpora diversas técnicas maliciosas, incluindo execução baseada em ActiveX, decodificação personalizada de payload em Base64, desserialização com .NET BinaryFormatter e execução de payload em memória.

A primeira etapa do malware começa com um grande array JavaScript ofuscado, geralmente definido como uma variável como _$_f1bf, que contém inúmeros fragmentos de string codificados em hexadecimal representando uma carga útil embutida. Esses fragmentos são posteriormente concatenados e passados ​​para uma função de decodificação personalizada. Em vez de depender das APIs nativas de decodificação Base64, o script implementa sua própria rotina de decodificação Base64 para ocultar a carga útil e dificultar a análise.

A função personalizada reconstrói dinamicamente o conjunto de caracteres Base64 padrão (A–Z, a–z, 0–9, +, /) usando String.fromCharCode e, em seguida, processa os dados codificados em blocos, reconstruindo o fluxo de bytes original por meio de uma série de operações bit a bit. Ao lidar manualmente com o processo de decodificação, o malware evita indicadores suspeitos como atob() ou bibliotecas de decodificação comuns, tornando a detecção estática e a análise baseada em assinaturas significativamente mais difíceis.

Reconstrução de carga útil usando objetos COM do .NET

Na segunda etapa, o malware converte a carga útil decodificada em um objeto executável na memória, utilizando múltiplas classes .NET instanciadas por meio de ActiveXObject. O script cria um objeto System.Text.ASCIIEncoding para converter a string decodificada em um array de bytes e, em seguida, usa o método System.Security.Cryptography.FromBase64Transform para realizar uma transformação Base64 adicional na carga útil. O fluxo de bytes resultante é gravado em um objeto System.IO.MemoryStream, reconstruindo efetivamente a carga útil serializada inteiramente na memória, sem acessar o disco. Essa abordagem em etapas é comumente usada em malware sem arquivo, pois permite que os atacantes preparem objetos .NET maliciosos para execução, minimizando os artefatos forenses e reduzindo a probabilidade de detecção por produtos de segurança tradicionais baseados em arquivos.

Após decodificar o payload embutido, o script entra em sua fase de execução criando um objeto ActiveX WScript.Shell , que permite o acesso a operações de registro, variáveis ​​de ambiente e outras funcionalidades do sistema. Em seguida, o script verifica se a versão 4.0.30319 do .NET Framework está instalada, consultando o caminho do registro HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 . Se a versão mais recente do runtime não estiver disponível, ele utiliza a versão 2.0.50727 do .NET. O malware, então, define a variável de ambiente COMPLUS_Version para forçar o processo a carregar uma versão específica do runtime CLR, garantindo a compatibilidade com o payload da DLL do .NET embutida.

Durante a execução, o malware explora componentes confiáveis ​​de desserialização do .NET, incluindo gadgets XAML do WPF, como ObjectDataProvider e ResourceDictionary, juntamente com objetos de serialização do Windows Forms, como AxHost e PropertyBagBinary. Esses componentes ajudam a manter a cadeia de gadgets de desserialização e acionam a execução durante a reconstrução do objeto.

Finalmente, o objeto serializado malicioso armazenado no objeto MemoryStream é processado por meio do .NET BinaryFormatter.Deserialize_2() , permitindo a execução furtiva de DLLs na memória, minimizando artefatos forenses e contornando os mecanismos tradicionais de detecção baseados em arquivos.

Etapa 3: Análise da DLL do carregador da Etapa 1 (Carregador Inicial)

Esta é uma DLL de carregamento .NET responsável pela execução da carga útil da próxima etapa, persistência e armazenamento em memória dos próximos componentes da cadeia de ataque.

Ao iniciar, a função openthefile() é responsável por baixar e abrir um documento PDF falso a partir da URL hxxp[:]//abimj.edu.af/institute/cloudiyaf/document.pdf. A função primeiro extrai o nome do arquivo da URL e salva o arquivo baixado no diretório temporário do Windows usando WebClient.DownloadFile(). Antes de iniciar o download, o malware habilita explicitamente a comunicação TLS 1.2 por meio de ServicePointManager.SecurityProtocol, garantindo a compatibilidade com conexões HTTPS/TLS seguras. Após baixar o documento, o malware pausa a execução por cinco segundos e, em seguida, abre o arquivo PDF baixado por meio de uma rotina de execução de comando oculta.

A função RunProcessWithHiddenCmd() é usada para executar arquivos ou comandos através do cmd.exe. A função constrói um argumento de linha de comando usando /c, que instrui o cmd.exe a executar o caminho do arquivo fornecido e encerrar em seguida. A função inicializa uma nova instância de processo, atribui o cmd.exe como o executável a ser iniciado e passa a string de argumento gerada para o processo. Uma vez iniciado, o interpretador de comandos executa o arquivo ou comando especificado e encerra automaticamente após a conclusão.

Após abrir o documento de isca, o malware cria um diretório chamado USOShared-1de48789-1285 em C:\Users\Public\ para armazenar o payload HTA da próxima etapa (zuidrt.hta). Em seguida, invoca a função RegWorkExePathFromPublic() , que contém comandos de registro codificados em Base64, os quais são decodificados em tempo de execução usando a rotina de decodificação Base64 BSDSD94() . Uma vez decodificado, o comando cria uma nova entrada na chave de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run com o nome Edgre. A entrada de registro executa:

cmd /C iniciar C:\Users\Public\USOShared-1de48789-1285\zuidrt.hta

Para garantir ainda mais discrição e persistência, o malware grava o comando decodificado em um arquivo em lote chamado noway.bat no diretório temporário do usuário e o executa por meio de um processo oculto. A execução é configurada para suprimir todas as janelas visíveis, impedindo que qualquer prompt de comando apareça para o usuário. Isso garante que a carga útil HTA seja iniciada automaticamente durante o login do usuário, mantendo a persistência no sistema.

A função CopyExeToUsersPublic() é responsável por recuperar e reconstruir o payload HTA da próxima etapa (zuidrt.hta) no diretório C:\Users\Public\USOShared-1de48789-1285\. Primeiro, ela verifica se o diretório de destino existe e o cria, caso não exista, usando Directory.CreateDirectory(). Em seguida, ela baixa o payload codificado de:

hxxp[:]//abimj.edu.af/institute/cloudiya/

O payload zuidrt.hta baixado é armazenado em formato compactado e codificado em Base64 para evitar detecção. O malware posteriormente descompacta e decodifica os dados para reconstruir o payload HTA final, que é executado através de RunProcessWithHiddenCmd(), que internamente executa cmd.exe /c start C:\Users\Public\USOShared-1de48789-1285\zuidrt.hta , aproveitando a associação de arquivos do Windows para invocar o mshta.exe para a execução do HTA.

Execução do Payload HTA (zuidrt.hta)

O arquivo zuidrt.hta segue uma estrutura semelhante à carga útil HTA inicial, mas contém componentes incorporados modificados e lógica de execução atualizada. Ele continua a cadeia de ataque reutilizando rotinas de ofuscação e decodificação para ocultar sua funcionalidade e evitar análises. O script reinicializa os caminhos de execução baseados em ActiveX para manter a execução dentro do ambiente HTA e reconstrói a carga útil serializada incorporada na memória.

Semelhante ao estágio inicial do HTA, a carga útil utiliza componentes de desserialização do .NET e cadeias de gadgets para acionar a execução em memória da DLL do carregador de Estágio 2 incorporada. Este estágio atua como uma camada de execução secundária dentro da cadeia de infecção, garantindo a persistência do fluxo de trabalho do ataque e facilitando a transição para a DLL do próximo estágio, responsável pela entrega e execução final da carga útil.

Etapa 4: Análise da DLL do carregador da Etapa 2 e do Shellcode

Após a descriptografia em tempo de execução, o fluxo de execução é passado para uma DLL maliciosa.

A DLL é um carregador de shellcode baseado em .NET responsável por recuperar, decodificar, descompactar e executar o payload da próxima etapa inteiramente na memória. O malware utiliza múltiplas camadas de preparação e execução em tempo de execução para burlar os mecanismos de segurança tradicionais e reduzir os artefatos armazenados em disco.

A DLL atua como um carregador intermediário entre o estágio HTA baseado em JavaScript e a carga útil final do Xeno RAT.

Configuração do ambiente e recuperação da carga útil

Após a execução, a DLL inicializa um ambiente de preparação projetado para armazenar e processar a carga útil da próxima etapa, minimizando suspeitas. O malware primeiro decodifica uma string codificada em Base64 ( ZmlyZWZ4LTFkZTg3ZWVjOC0xMjQx ) usando a rotina personalizada BSDSD94() , resultando no nome do diretório firefx-1de87eec8-1241. Em seguida, ele cria um diretório de trabalho no caminho público do Windows:

• C:\Users\Public\firefx-1de87eec8-1241

O uso de C:\Users\Public\ permite que o malware evite restrições de gravação relacionadas a privilégios, enquanto se mistura à atividade legítima do sistema de arquivos. A convenção de nomenclatura do diretório imita pastas de cache ou perfil geradas por aplicativos, ajudando a reduzir a suspeita do usuário e a evitar detecções básicas baseadas em indicadores de comprometimento (IOCs). O malware também define nomes de arquivos de carga útil temporários, como ayui.vmxx e ayhui.vmxx , que são disfarçados intencionalmente com extensões não padronizadas para evitar a identificação imediata como conteúdo executável.

Após estabelecer o diretório de preparação, a DLL inicia uma comunicação de saída com a infraestrutura controlada pelo atacante para recuperar a carga útil da próxima etapa. O malware contém vários URLs fixos no código, incluindo:

• hxxps[:]//abimj[.]edu[.]af/instituto/10/
• hxxps[:]//abimj[.]edu[.]af/instituto/7/

e seleciona dinamicamente o ponto de extremidade de download com base na versão do sistema operacional da vítima. Sistemas identificados como Windows 7 (versão 6.1) são redirecionados para um local alternativo de entrega de payload, indicando uma entrega de payload compatível.

Utilizando o método WebClient.DownloadFile() do .NET , juntamente com os protocolos TLS/TLS1.1/TLS1.2 explicitamente habilitados, o malware baixa o payload criptografado e o armazena localmente como ayui.vmxx . O conteúdo baixado não é diretamente executável; em vez disso, serve como um blob de preparação codificado e compactado que passa por decodificação Base64 e descompressão GZIP adicionais antes que a execução do shellcode seja iniciada na memória.

Decodificação de carga útil e reconstrução de shellcode

Após baixar com sucesso o payload da segunda etapa, a DLL armazena os dados recuperados no diretório de preparação como um arquivo disfarçado chamado ayui.vmxx. Em vez de implantar um executável portátil (PE) diretamente no disco, o malware usa mecanismos de codificação e compressão em camadas para ocultar o conteúdo real do payload e burlar os mecanismos de detecção estática. O arquivo contém dados codificados em Base64 e comprimidos em GZIP que parecem não executáveis ​​durante uma inspeção superficial. Essa técnica reduz significativamente a visibilidade da assinatura para produtos antivírus e complica a análise manual, impedindo que os analistas identifiquem imediatamente o formato do payload. O malware lê o arquivo inteiro para a memória usando File.ReadAllBytes() e começa a reconstruir o payload incorporado dinamicamente durante a execução.

O processo de reconstrução é gerenciado pela função personalizada `decompressdata()` , que executa múltiplas operações de decodificação e descompressão inteiramente na memória. A rotina primeiro decodifica o blob Base64, extrai o cabeçalho de tamanho descomprimido e utiliza a classe `GZipStream` do .NET para restaurar o buffer de payload original. Uma vez concluída a descompressão, os dados resultantes são novamente passados ​​por `Convert.FromBase64String()` para recuperar os bytes brutos do shellcode. O payload totalmente reconstruído é então gravado localmente como `ayhui.vmxx` , que serve como contêiner intermediário do shellcode antes da execução. Ao combinar decodificação em etapas, compressão e reconstrução do payload em tempo de execução, o malware evita expor o shellcode final em formato de texto simples no disco, contornando assim os mecanismos convencionais de varredura de arquivos e detecção baseada em conteúdo, enquanto prepara o payload para execução reflexiva na memória.

Execução do Shellcode:

Após a reconstrução da carga útil, a DLL transita para a fase final de execução, funcionando como um carregador de shellcode em memória. Em vez de executar um arquivo executável tradicional a partir do disco, o malware aloca memória executável diretamente dentro do processo atual usando a API VirtualAlloc() do Windows . A solicitação de alocação utiliza o sinalizador MEM_COMMIT juntamente com as permissões de memória PAGE_EXECUTE_READWRITE (RWX) , criando uma região de memória capaz de armazenar e executar código arbitrário. Esse padrão de alocação RWX é um indicador conhecido de execução de shellcode e carregamento reflexivo de malware. Após a alocação de memória, o malware copia o buffer de shellcode reconstruído para a região alocada usando Marshal.Copy() , efetivamente armazenando a carga útil inteiramente na memória do processo, sem depender do carregador PE do Windows.

Uma vez que o shellcode é mapeado na memória executável, o malware transfere a execução para o buffer injetado através da API CreateThread() , usando o endereço base da memória alocada como ponto de entrada da thread. Essa técnica permite que o shellcode seja executado diretamente da memória, contornando o monitoramento de execução convencional baseado em disco e reduzindo significativamente os artefatos forenses. A DLL então invoca WaitForSingleObject() com um valor de tempo limite infinito para manter a sincronização da thread e garantir a execução ininterrupta do shellcode. Essa metodologia de execução está alinhada com as técnicas modernas de malware sem arquivo, onde os payloads são descriptografados e executados dinamicamente na memória para burlar mecanismos antivírus baseados em assinaturas, mecanismos de controle de aplicativos e tecnologias de varredura estática. O shellcode subsequentemente atua como o carregador para o payload final do Xeno RAT, permitindo persistência, comunicação de comando e controle e acesso remoto do atacante ao sistema comprometido.

O shellcode funciona como um carregador em memória responsável por preparar e executar a carga útil final do Xeno RAT.

Durante a execução, ele geralmente realiza validação de ambiente, resolução dinâmica de API e modificações de permissões de memória usando APIs como VirtualProtect() e GetProcAddress() . Em carregadores Donut, o shellcode burla os mecanismos de segurança modificando funções como AmsiScanBuffer() para desativar a varredura AMSI e reduzir a visibilidade do conteúdo carregado dinamicamente.

Como a carga útil final é um assembly .NET gerenciado, o shellcode inicializa o Common Language Runtime (CLR) do .NET carregando componentes como clr.dll e mscoree.dll. A carga útil incorporada é então descriptografada e carregada diretamente da memória usando técnicas reflexivas como Assembly.Load(byte[]) , evitando completamente a implantação baseada em disco. Uma vez carregada, a carga útil do Xeno RAT é executada na memória, permitindo comunicação de comando e controle, persistência e acesso remoto do atacante ao sistema comprometido.

Etapa 5: Análise do XenoRAT.

A carga útil final identificada na cadeia de infecção é o Xeno RAT , um Trojan de Acesso Remoto (RAT) de código aberto, disponível publicamente no GitHub e comumente usado por agentes maliciosos para acesso remoto persistente, vigilância e atividades de pós-exploração.

Após a execução, o malware inicializa um canal de comunicação seguro de comando e controle (C2) usando um endereço IP fixo (185.235.137.106) e uma configuração de porta específica, permitindo a conexão direta com a infraestrutura controlada pelo atacante. Para manter a execução de instância única e evitar execuções múltiplas, o malware também emprega um mutex (“clouda”) , garantindo que apenas uma instância do cliente seja executada no sistema infectado por vez. Essas etapas de inicialização são seguidas por lógica de persistência e reconexão contínua para manter o acesso a longo prazo ao host comprometido.

Agora, vamos examinar algumas funções interessantes e analisar suas funcionalidades.

A função `ConnectAndSetupAsync` é responsável por estabelecer e inicializar uma conexão de comando e controle (C2) baseada em TCP entre o cliente e o servidor remoto. Ela cria uma nova instância de `Node` usando um `SocketHandler` configurado com o socket e a chave de criptografia fornecidos, permitindo a comunicação criptografada pela conexão. Após a inicialização, a função realiza um handshake de autenticação assíncrono usando `AuthenticateAsync` para validar a conexão com base nos valores de tipo e ID fornecidos. Se a autenticação falhar ou ocorrer uma exceção durante a configuração, a função retorna `null`, indicando que o canal de comunicação C2 não pôde ser estabelecido com sucesso. Caso contrário, ela retorna um objeto `Node` totalmente inicializado e autenticado, pronto para a troca segura de dados.

A função DllNodeHandler gerencia o carregamento e a execução dinâmicos de módulos DLL externos recebidos por meio de uma conexão Node remota. Ela primeiro recebe o nome da DLL do cliente conectado e verifica se o assembly já está carregado na memória. Se a DLL não estiver presente, ela solicita os dados binários do lado remoto, carrega-os dinamicamente usando Assembly.Load e os armazena no dicionário Assemblies para reutilização; caso contrário, informa ao cliente que a DLL já existe. Após o carregamento, a função cria uma instância de uma classe especificada a partir do assembly usando reflexão e invoca seu método público Run de forma assíncrona, passando a conexão Node ativa como argumento.

O método SendAsync envia dados de forma assíncrona através do manipulador de socket e verifica se a transmissão foi bem-sucedida, desconectando o nó caso a operação de envio falhe. Da mesma forma, o método ReceiveAsync recupera os dados criptografados e formatados do manipulador de socket subjacente e retorna o fluxo de bytes processado ao chamador; se a operação falhar ou retornar nulo, o nó é desconectado automaticamente para manter um estado de conexão válido. Juntos, esses métodos fornecem comunicação C2 confiável baseada em TCP com gerenciamento de conexão integrado e limpeza automática durante erros de transmissão.

Além disso, os dados da carga útil são compactados usando as APIs de compressão RTL nativas do Windows (RtlCompressBuffer) antes da transmissão e descompactados usando RtlDecompressBuffer na recepção, com base no cabeçalho de tamanho original, melhorando a eficiência da transferência e preservando a integridade dos dados. A segurança dos dados é garantida por meio de criptografia AES, onde os dados brutos são criptografados com uma chave compartilhada e um vetor de inicialização fixo via CryptoStream, assegurando uma comunicação segura durante a transmissão.

Métodos adicionais dentro da classe gerenciam outras operações de rede, incluindo desconexão de socket (Disconnect), estabelecimento de subconexões secundárias (ConnectSubSockAsync), validação do status de conexão ativa (Connected) e manutenção de relacionamentos entre nós filhos (AddSubNode).

A função AddToStartupAdmin cria uma Tarefa Agendada do Windows chamada “ XenoUpdateManager ” que executa o executável especificado automaticamente sempre que um usuário faz login no sistema com os privilégios mais altos disponíveis (administrador). Ela cria uma definição de tarefa em XML, grava-a em um arquivo temporário e usa o schtasks.exe para registrar a tarefa no Agendador de Tarefas do Windows. Após executar o comando, ela verifica a saída para determinar se a tarefa foi criada com sucesso e, em seguida, retorna o resultado.

 

A função AddToStartupNonAdmin adiciona o executável à inicialização do Windows do usuário atual, gravando-o na chave de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run , para que seja executado automaticamente ao fazer login sem privilégios de administrador, e retorna se a operação foi bem-sucedida.

A função GetAntivirus recupera informações de antivírus do sistema usando o Windows Management Instrumentation (WMI), consultando a classe AntivirusProduct em root\SecurityCenter2. Ela coleta os valores displayName retornados por essa consulta, que representam os produtos antivírus instalados usados ​​para identificação do sistema.

A função RemoveStartup remove um aplicativo da inicialização do Windows, excluindo todas as entradas correspondentes tanto do Agendador de Tarefas (usando o schtasks.exe) quanto da chave de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Primeiro, ela verifica se o usuário possui direitos de administrador para remover tarefas agendadas e, em seguida, examina e exclui qualquer tarefa que aponte para o caminho do executável especificado. Por fim, remove qualquer entrada de inicialização correspondente no registro para o usuário atual.

A função de desinstalação remove os mecanismos de persistência do aplicativo e, em seguida, encerra o programa automaticamente. Primeiro, ela chama a função RemoveStartup para excluir quaisquer entradas de inicialização (tarefa agendada ou registro) associadas ao executável atual.

Ele inicia um processo oculto do cmd.exe com um comando decodificado em Base64 (/C escolha /CY /N /DY /T 3 & Del) que aguarda alguns segundos e, em seguida, exclui o arquivo executável em execução do disco. Finalmente, a função encerra o processo atual à força, garantindo que o aplicativo seja finalizado imediatamente após a limpeza.

CAPACIDADES DO Xeno-RAT

O Xeno RAT revela informações significativas sobre seu comportamento operacional e capacidades de pós-exploração. Com base no código analisado, na atividade observada e na funcionalidade disponível em seu projeto de código aberto no GitHub, o malware demonstra uma ampla gama de características comumente associadas a trojans de acesso remoto (RATs) avançados.

• Monitora a atividade da vítima e coleta informações de reconhecimento do hospedeiro.
• Estabelece comunicação de comando e controle (C2) criptografada baseada em TCP.
• Suporta tunelamento de rede baseado em proxy SOCKS5.
• Carrega dinamicamente assemblies externos na memória usando Assembly.Load.
• Executa comandos arbitrários emitidos pelo atacante remotamente.
• Oferece funcionalidades de gerenciamento de arquivos, incluindo upload, download e exclusão.
• Executa atividades de registro de teclas digitadas (keylogging), captura de tela, monitoramento da área de transferência e vigilância por webcam/microfone.
• Envia atualizações periódicas de status e pulsação para o servidor C2.
• Utiliza tráfego de rede criptografado e comprimido para dificultar a análise.
• Mantém a persistência usando Tarefas Agendadas e chaves de execução do Registro.
• Pode ser adicionado ou removido dos locais de inicialização do Windows.
• Opera de forma secreta para manter o acesso não autorizado a longo prazo.
• Inclui funcionalidades de desinstalação e exclusão automáticas para limpeza após a execução.

Artefatos de infraestrutura e atribuições de agentes de ameaça:

Com base em nossa análise e no histórico de rastreamento desta cadeia e dos TPPs, com todas as provas apresentadas, atribuímos esta campanha ao cluster SideCopy com um nível de confiança médio a alto, conforme mencionado anteriormente. Durante a análise da infraestrutura, o domínio de entrega abimj[.]edu[.]af resolveu para dois endereços IP — 103.132.98.224 e 103.132.98.226 — ambos localizados no bloco 103.132.98.0/23 atribuído ao AS58469, o Ministério das Comunicações e Tecnologia da Informação do Afeganistão.

A análise passiva de DNS nesse bloco de IP revelou mais de 200 domínios legítimos do governo e da área educacional afegã hospedados na mesma infraestrutura, confirmando que o agente malicioso posicionou deliberadamente sua camada de distribuição dentro da própria infraestrutura soberana de internet do Afeganistão — uma manobra calculada para misturar tráfego malicioso com comunicações governamentais legítimas e evitar a detecção em nível de rede.

Ao analisar mais detalhadamente o servidor C2 do RAT, 185.235.137.106, descobrimos um host Windows executando HTTP, HTTPS e uma porta RDP não padrão — consistente com um servidor C2 dedicado gerenciado pelo operador.

O servidor está hospedado no AS59711 (HZ Hosting Ltd), um provedor registrado na Bulgária com presença física em Frankfurt, previamente documentado nos relatórios de infraestrutura do SideCopy. Seqrite.

Três clusters de domínios apontavam para este IP no momento da análise, incluindo domínios descartáveis ​​registrados pelo agente malicioso em TLDs .xyz, .live e .online, juntamente com um domínio de infraestrutura de e-mail totalmente configurado — indicando que o mesmo servidor estava servindo tanto comunicações RAT quanto operações de entrega de phishing simultaneamente.

A cadeia de ataque — LNK executando mshta.exe para obter um HTA remoto por meio de um endpoint index.php — é uma TTP (Tática, Técnica e Procedimento) de SideCopy documentada consistentemente desde 2019 e continua sendo um dos identificadores mais confiáveis ​​do grupo. O uso do XenoRAT reforça especificamente essa atribuição, pois Seqrite Em dezembro de 2024, a Labs confirmou que a SideCopy adotou formalmente variantes personalizadas do XenoRAT como parte de seu conjunto de ferramentas atualizado, seguindo um padrão semelhante de adoção de RATs de código aberto visto anteriormente com o AsyncRAT. A persistência baseada no registro por meio de uma chave "Executar" com um nome de processo que simula um aplicativo legítimo do Windows é igualmente consistente com o comportamento pós-exploração documentado da SideCopy.

Em termos de infraestrutura, o domínio de entrega foi registrado através da AFGNIC e hospedado no mesmo bloco de IP que a infraestrutura legítima do governo afegão — uma técnica de mesclagem deliberada, consistente com o padrão documentado da SideCopy. O servidor RAT C2 na HZ Hosting (AS59711) corrobora ainda mais essa informação, visto que o mesmo provedor já apareceu em clusters de infraestrutura da SideCopy rastreados anteriormente. SeqriteNotavelmente, a consistência na nomenclatura entre o caminho de entrega (cloudiyaf) e o nome fixo da inicialização do RAT (clouda) sugere um único operador gerenciando ambas as camadas de infraestrutura — vinculando as camadas de entrega e pós-exploração ao mesmo ator.

Conclusão: Por que a Operação XENOFISCAL?

O nome deriva diretamente das duas características definidoras desta campanha: XenoRAT, a ferramenta de acesso remoto de código aberto implantada como carga útil final, e Fiscal, que reflete o direcionamento preciso à rede provincial do Ministério das Finanças do Afeganistão. Juntas, elas formam um único codinome que engloba tanto a arma quanto a vítima em uma só palavra. A escolha deliberada do agente da ameaça de implantar uma isca com temática financeira contra um ministério das finanças, combinada com uma ferramenta de acesso remoto capaz de vigilância silenciosa de longo prazo, tornou essa combinação inevitável. XENOFISCAL não é apenas um nome — é um resumo de toda a operação em oito letras.

Seqrite Cobertura:

• Link.Downloader.50744.GC
• Script.Netloader.50745.GC
• Trojan.LoaderCiR
• Trojan.YakbeexMSIL.ZZ4
• cld.script.trojan.1779477414

COI:

Nome do arquivo	SHA256
Zip	194B912C242604D6F9A79369F22338C58A13CE0CC2ED280CE505075808BC2F14
LNK	3B4194BDFE40D94031A94B30397FFD8A4B09D0A4057668E897B8BDCD1703DD01
PDF de isca	DF9173A28C0B0B878C10A53D35CD7CE6F6ED66D207B6B7C4FF723721F1C027AB
ugayt.hta	A63E90EE57A1F213A8FE76EF1A6CFF5AE9ED7EBCEDA258431533825E648C0C67
de jeito nenhum.bat	5833917BD137804F5A021D2CB37ADFE5C4B7B67DBB06D59C3B9C5CF393835E45
zuidrt.hta	99127C8C67D90E2776BEEB85281F9C68399BF4567B07A6B638D68B760212E88D
WayBroad.dll	8F2D979EF33B2900351C94C7335275A9342C75189E1A901998E90A539E944A1A
Aotestpass.dll	0019212F25EB04BBB33BB194879C095265DB7855D6003BDD777CF0CBB90EB772
XenoRato	9AE3D785486022AF82EA92E51B26E3F55C1BBA88A7BE2AD9790F4240E8499D14

 

MITRE ATT&CK:

Tática	Nome da técnica	ID da técnica
Acesso Inicial	Anexo de Spearphishing	T1566.001
Execução	Execução de proxy de utilitários de desenvolvedor confiáveis: mshta	T1218.005
	Interpretador de comandos e scripts: Shell de comando do Windows	T1059.003
	Comando e interpretador de scripts: JavaScript	T1059.007
	Módulos compartilhados	T1129
	API nativa	T1106
Persistência	Chaves de execução do Registro / Pasta de inicialização	T1547.001
	Tarefa agendada	T1053.005
Escalonamento de Privilégios	Tarefa agendada
Evasão de Defesa	Arquivos ou informações ofuscados	T1053.005
	Desofuscar / decodificar arquivos ou informações	T1027
	Armazenamento/Execução sem Arquivos	T1140
	Carregamento de código reflexivo	T1027.011
	Vivendo da Terra: Binários e Scripts (LOLBAS)	T1620
	Arquivos e diretórios ocultos	T1218
	Injeção de Processos / Execução em Memória	T1564.001
	Desvio AMSI	T1055
	Remoção do Indicador no Host: Exclusão de Arquivo	T1562.001
Discovery	Registro de consulta	T1070.004
	Descoberta de informações do sistema	T1012
	Descoberta de software	T1082
	Descoberta de software de segurança	T1518
Coleção	Keylogging	T1518.001
	Screen Capture	T1056.001
	Dados da área de transferência	T1113
	Captura de áudio	T1115
	Captura de vídeo	T1123
Comando e controle	Protocolo de camada de aplicativo: protocolos da Web	T1125
	Protocolo de camada de não aplicação	T1071.001
	Canal criptografado	T1095
	Proxy: Proxy Externo	T1573
	Resolução Dinâmica	T1090.002
Desenvolvimento de Recursos	Adquirir infraestrutura: domínios	T1568
	Infraestrutura de compromisso	T1583.001