AsyncRAT sem máscaras: desvendando o labirinto de variantes

O AsyncRAT tornou-se uma peça central no cenário do malware moderno, consolidando-se como uma ameaça persistente graças à sua vasta rede de forks e variantes. Embora suas funções isoladas não sejam extraordinárias, o código aberto potencializou seu alcance e impacto. Neste post, apresentamos uma análise dos principais forks do AsyncRAT, explorando suas conexões e a evolução desse malware ao longo do tempo.

Pontos-chave deste artigo:

• Trazemos insights exclusivos sobre o ecossistema do AsyncRAT e suas múltiplas variantes, ajudando a desvendar o labirinto de forks.
• Mapeamos a hierarquia e as interconexões únicas entre os forks do AsyncRAT, destacando formas de identificar e diferenciar cada variante.
• Investigamos variantes menos conhecidas, que incorporam plugins específicos; desde um simples plugin de som (screamer) até mecanismos de disseminação por USB.

Origens do AsyncRAT

Você provavelmente já ouviu falar do AsyncRAT, sigla para asynchronous remote access trojan (trojan de acesso remoto assíncrono). Publicado como projeto open source no GitHub em 2019 por um usuário chamado NYAN CAT, o AsyncRAT foi desenvolvido em C# e oferece uma ampla gama de funcionalidades típicas de RATs, como keylogging, captura de tela e roubo de credenciais. Sua simplicidade e código aberto rapidamente o tornaram uma escolha popular entre cibercriminosos, contribuindo para seu uso disseminado em diferentes ataques.

Mas qual a verdadeira origem do AsyncRAT? Acredita-se que ele tenha se inspirado no Quasar RAT, outro trojan open source lançado no GitHub em 2015 e também escrito em C#. Apesar das semelhanças, análises revelam que os códigos-fonte são fundamentalmente distintos. Isso indica que o AsyncRAT não é um simples fork do Quasar, mas sim uma reescrita completa, ainda que compartilhem conceitos e abordagens semelhantes. Vale lembrar que, no contexto do desenvolvimento, um fork é uma cópia do repositório de outro projeto, permitindo modificações independentes sem afetar o original.

O principal ponto de convergência entre os dois está no uso de classes de criptografia personalizadas para descriptografar configurações do malware. Em especial, as classes Aes256 e Sha256 aparecem no namespace Client.Algorithm do AsyncRAT e no Quasar.Common.Cryptography do Quasar. A Imagem 1 ilustra o uso de códigos idênticos nas implementações da classe Aes256 em ambos os projetos.

O código foi amplamente copiado e colado, mantendo inclusive o mesmo valor de salt e configurações de descriptografia. Essa similaridade, especialmente nas classes Aes256 e Sha256, reforça a influência do Quasar RAT sobre o desenvolvimento do AsyncRAT.

Apesar dessas semelhanças, o AsyncRAT trouxe avanços importantes, principalmente em sua arquitetura modular e recursos aprimorados de furtividade, tornando-o mais adaptável e difícil de detectar nos ambientes de ameaça atuais. Sua estrutura baseada em plugins e a facilidade de personalização contribuíram para a proliferação de inúmeros forks, ampliando ainda mais o alcance desse malware.

Labirinto de forks

Desde que foi disponibilizado ao público, o AsyncRAT deu origem a uma infinidade de forks baseados em sua estrutura original. Algumas dessas versões ampliaram o framework com novas funcionalidades e aprimoramentos, enquanto outras são, essencialmente, cópias com pequenas alterações visuais ou superficiais.

Hierarquia dos forks

A Imagem 2 ilustra a evolução de alguns dos forks mais relevantes do AsyncRAT, mostrando como eles se ramificaram e se desenvolveram a partir da versão original ao longo do tempo.

No centro dessa árvore evolutiva destacam-se o DcRat e o VenomRAT, identificados como as variantes mais utilizadas e responsáveis por uma parcela significativa das campanhas observadas. Outros forks menos conhecidos representam fatias menores, mas continuam relevantes no cenário de ameaças. A Imagem 3 mostra a distribuição dos forks mais prevalentes, de acordo com nossa telemetria.

O DcRat representa um avanço notável em relação ao AsyncRAT, especialmente em termos de funcionalidades e capacidades. Uma das principais inovações está na estrutura de dados: o DcRat utiliza o MessagePack, uma biblioteca open-source reconhecida por oferecer serialização binária eficiente para a transferência bidirecional de informações.

Além disso, o DcRat implementa técnicas sofisticadas de evasão, como o patching do AMSI e do ETW. Essas técnicas desativam mecanismos de segurança do Windows, dificultando a detecção e o registro de comportamentos maliciosos; o patching do AMSI impede a varredura de scripts, enquanto o do ETW bloqueia o rastreamento de eventos. Outro diferencial é o sistema anti-processos, que encerra automaticamente processos presentes em uma lista de negação (denylist), incluindo Taskmgr.exe, ProcessHacker.exe, MsMpEng.exe, Taskkill.exe e outros.

A arquitetura de plugins do DcRat também se apoia no AsyncRAT, mas vai além, oferecendo recursos como acesso à webcam, gravação de microfone, roubo de tokens do Discord, e uma série de "coisas divertidas"; plugins criados para brincadeiras, como abrir ou fechar a bandeja do CD, bloquear teclado e mouse, mover o cursor e desligar o monitor. Notavelmente, o DcRat ainda introduz um plugin de ransomware simples, que utiliza AES-256 para criptografar arquivos, sendo a chave de descriptografia liberada apenas sob solicitação.

Outras modificações incluem pequenas alterações para dificultar a detecção, como o uso de uma string como salt (em vez de valor binário), variáveis renomeadas, resolução dinâmica de APIs e outros ajustes técnicos.

O VenomRAT, por sua vez, parece ter sido fortemente inspirado no DcRat, como evidenciado na seção de identificação de versões. Apesar de possuir uma gama extensa de funcionalidades, suficiente para ser considerado uma ameaça independente, foi agrupado sob o AsyncRAT neste contexto devido à grande similaridade entre as partes cliente dos dois. As funcionalidades e plugins do VenomRAT já foram detalhados por outros pesquisadores, por isso não serão abordados em profundidade aqui.

É importante notar que nem todos os RATs são criados com propósitos sérios, e isso se aplica aos forks do AsyncRAT. Clones como SantaRAT e BoratRAT (ver Imagem 4) adotam uma abordagem mais jocosa. No caso do SantaRAT, os próprios autores admitem que o projeto foi "descaradamente copiado do DcRat". Ainda assim, há registros de que esses RATs têm sido utilizados em ataques reais.

Identificação de versões

Durante a análise, utilizamos diferentes métodos para identificar e categorizar cada amostra de malware. O foco principal foi a parte cliente, já que esse é o binário instalado nas máquinas das vítimas e contém informações essenciais, como configurações do malware e detalhes sobre o servidor de comando e controle (C&C).

O método mais rápido para identificar um fork é examinar diretamente a configuração do malware, geralmente localizada na função InitializeSettings. Essas configurações costumam ser criptografadas com AES-256 e armazenadas em formato base64 na classe Settings. Em grande parte das amostras, o nome do fork aparece claramente rotulado como Version, fornecendo uma indicação direta do fork ou do pseudônimo do autor. Aproximadamente 90% das amostras analisadas traziam uma descrição significativa nesse campo, enquanto nas demais o campo estava intencionalmente vazio.

A Imagem 5 demonstra como ocorre o procedimento típico de inicialização da configuração no DcRat e em seus derivados, como o VenomRAT.

Quando o campo Version está vazio, outra pista útil pode ser obtida ao analisar o valor do Salt usado na criptografia das configurações. Muitas vezes, os cibercriminosos esquecem de alterar esse parâmetro ao criar um novo fork. O valor de Salt pode ser localizado na classe Client.Algorithm.Aes256, como ilustrado na Imagem 6.

Outra maneira de coletar informações adicionais é analisar o certificado embutido usado para autenticar o servidor de C&C. Esse certificado geralmente está armazenado na configuração como um valor em base64. Ao decodificar esse valor, é possível revelar dados como o common name (CN), organização e unidade organizacional do servidor.

Quando um fork tem um nome próprio no campo Version, muitas vezes é possível rastrear sua origem analisando o campo CN do certificado, identificando o fork anterior no qual ele se baseou. A Imagem 7 apresenta um exemplo de certificado em formato DER que, após extração e decodificação, revela o fork BoratRAT.

As técnicas descritas acima são eficazes principalmente em casos simples, quando os autores do malware não se preocuparam em remover vestígios ou apenas utilizaram certificados padrão. No entanto, existe um método mais avançado para identificar servidores AsyncRAT: o envio de um pacote especialmente elaborado ao servidor de C&C, técnica detalhada por Axel Mahr em seu artigo.

Se todas as tentativas automatizadas falharem, resta recorrer ao método tradicional: a inspeção manual do código. Esse processo exige uma análise minuciosa da estrutura, sintaxe e funcionalidades, comparando com padrões já conhecidos em amostras previamente classificadas.

Lista de forks

A seguir, destacamos alguns dos forks mais proeminentes do AsyncRAT. Diante da quantidade expressiva de variantes, não é possível analisar cada uma em detalhe. Para fins de abrangência, a Imagem 8 apresenta uma lista ampliada de forks do AsyncRAT identificados como ativos em atividades maliciosas, de acordo com a telemetria da ESET.

Explorando variantes menos conhecidas

Até agora, destacamos os principais forks que predominam no cenário de ameaças. Nesta seção, apresentamos alguns forks menos conhecidos que estendem a funcionalidade do AsyncRAT além dos recursos presentes nas versões convencionais. Essas variantes exóticas, geralmente desenvolvidas por indivíduos ou pequenos grupos, representam menos de 1% do total de amostras identificadas.

NonEuclid RAT

Esse fork chama a atenção principalmente pela inclusão de plugins inéditos, além dos recursos padrões. Enquanto alguns desses plugins servem apenas para funções triviais ou "coisas divertidas", outros, como o WormUsb.dll, têm objetivos claramente maliciosos. A Tabela 1 apresenta uma seleção de plugins do NonEuclid RAT que se diferenciam da base comum encontrada nos forks tradicionais.

Screamer.dll

Este plugin inclui cinco imagens de jump scare incorporadas. O cibercriminoso pode selecionar qual imagem será exibida, enviar um arquivo WAV para reprodução e definir um tempo de atraso para acionar o susto na vítima. A Imagem 9 apresenta as três primeiras imagens pré-instaladas disponíveis para escolha do cibercriminoso.

Piano.dll

Este plugin permite a reprodução de arquivos WAV arbitrários, armazenando todos os sons na pasta %appdata%\Piano. O piano.dll suporta três comandos principais:

• SetSound – Adiciona um novo arquivo de som à pasta %appdata%\Piano.
• PlayMisc – Reproduz um arquivo de som específico solicitado dessa mesma pasta.
• ClientAdd – Recupera múltiplos arquivos de som diretamente do servidor de C&C.

Service.dll

Este plugin permite o gerenciamento de serviços do Windows, possibilitando iniciar, parar e pausar serviços do sistema operacional.

Maps.dll

Plugin projetado para coletar informações de geolocalização da vítima. Utiliza a classe .NET GeoCoordinateWatcher para registrar uma função de retorno (callback) que coleta dados como latitude, longitude, nome de usuário e nome do computador sempre que a localização estiver disponível.

WormUsb.dll

Este plugin compromete arquivos PE com uma carga maliciosa definida pelo invasor. Apesar do nome "Usb", o plugin pode atuar em diversos locais, dependendo do comando enviado:

• InfectExe – Compromete um arquivo PE individual.
• InfectExeInWindows – Alvo são arquivos PE em pastas pessoais como Área de Trabalho, Documentos, Downloads e Minhas Músicas.
• InfectUsbExe – Infecta arquivos PE em todas as unidades, exceto a unidade C.

Internamente, o plugin funciona movendo o arquivo original para um local temporário e, em seu lugar, insere um pequeno stub. A seção de recursos desse stub é preenchida com o arquivo original e a carga maliciosa especificada, ambos comprimidos e criptografados com uma chave exclusiva gerada para cada arquivo no momento da criação.

Em seguida, o malware aplica técnicas de ofuscação ao stub, incluindo a introdução de métodos intermediários (proxy methods), a aplicação de ofuscação personalizada no fluxo de controle e a renomeação de variáveis para dificultar a análise. Como etapa final, o stub modificado recebe o ícone e os metadados originais do arquivo comprometido. A Imagem 10 apresenta a função responsável por comprometer um arquivo individual, exibindo os nomes originais dos métodos utilizados.

Quando um arquivo comprometido desse tipo é executado, ele primeiro descriptografa, descompacta e executa o payload malicioso. Em seguida, repete o processo com o programa original, garantindo que ambas as cargas sejam executadas em sequência.

Brute.dll

Este plugin possibilita ataques de força bruta contra os protocolos SSH e FTP diretamente do lado do cliente. O invasor informa três parâmetros (host, login e senha) e o plugin tenta se conectar usando essas credenciais. Caso a conexão seja bem-sucedida, as informações são enviadas de volta ao invasor junto com um indicador de sucesso. Isso facilita a distribuição dos ataques de força bruta entre diversas máquinas comprometidas, dificultando a detecção e a mitigação baseada em bloqueio por endereço IP.

SignatureAntivirus.dll

Apesar do nome, este plugin oferece apenas uma funcionalidade antivírus rudimentar e manual. O invasor envia uma lista de hashes MD5, que o plugin compara com os hashes de todos os arquivos EXE presentes em todos os discos. Ao encontrar uma correspondência, aciona a função DetectVirus — um nome inadequado, já que a única ação realizada é apagar o arquivo, sem análise adicional. O plugin pode ser utilizado para remover malwares concorrentes ou excluir qualquer arquivo arbitrário, tornando seu propósito e nome bastante questionáveis.

cliper.dll

Este plugin atua como um clipper autônomo, monitorando continuamente a área de transferência da vítima. Se detectar um endereço de carteira de criptomoeda, substitui-o por um endereço fornecido pelo invasor. Essas carteiras são enviadas dinamicamente apenas quando o plugin é ativado pela primeira vez, e não ficam codificadas no plugin.

Além disso, como mostrado na Imagem 11, o plugin também pode detectar entradas de cartões de crédito. Ele utiliza uma extensa lista de expressões regulares (regex) para identificar tanto carteiras de criptomoedas quanto informações de cartões. Quando um cartão é detectado, os dados são enviados diretamente ao invasor.

JasonRAT

Identificado em 2024, o JasonRAT ainda demonstra sinais de atividade. Essa variante chama atenção pelo uso de convenções obscuras de nomenclatura de variáveis, inspiradas em termos "satânicos" citados pelo autor como parte do "Livro de Jason". Na Imagem 12, é possível observar valores típicos de configuração do AsyncRAT em base64, mas com variáveis renomeadas. Já a Imagem 13 exibe a lógica do ponto de entrada principal do malware. Além das configurações usuais, o JasonRAT amplia as capacidades do cliente ao introduzir funcionalidades de segmentação por país.

Outra peculiaridade dessa variante é a técnica de ofuscação de strings adotada. Um subconjunto das strings é protegido por uma camada adicional de ofuscação, utilizando uma versão estendida do código Morse. Essa abordagem inclui letras maiúsculas e minúsculas, além de alguns caracteres especiais. A Imagem 14 ilustra uma string de chave de registro codificada usando esse mapeamento estendido.

XieBroRAT

Esta variante do RAT possui localização em chinês e traz novidades relevantes, como o plugin BrowserGhost.dll, especializado no roubo de credenciais armazenadas em navegadores. Outro plugin, Abstain.dll, permite a interação com servidores Cobalt Strike por meio de conexões reversas.

Para ampliar seu alcance, o malware oferece a cadeia de entrega em diversos idiomas. O binário cliente padrão em .NET pode ser empacotado e distribuído por meio de shellcode, VBS ou JavaScript.

Além disso, o autor expandiu significativamente as funcionalidades do malware ao integrar projetos de código aberto, incorporando ferramentas conhecidas como mimikatz, SharpWifiGrabber, SharpUnhooker, entre outras.

Conclusão

A ascensão do AsyncRAT e de seus inúmeros forks revela os riscos significativos associados a frameworks de malware open source. Nossa análise destacou um ecossistema diversificado e em constante evolução, com derivados que vão desde ameaças persistentes, como DcRat e VenomRAT, até variantes mais obscuras e curiosas, como JasonRAT e BoratRAT, que muitas vezes têm apelo mais experimental do que prático.

Esses forks não apenas ampliam as capacidades técnicas do AsyncRAT, mas também ilustram a agilidade e criatividade com que atores maliciosos adaptam e reutilizam código aberto. A facilidade de acesso a esses frameworks reduz drasticamente a barreira de entrada para aspirantes a cibercriminosos, permitindo que até iniciantes implementem malwares sofisticados com pouco esforço.

Além disso, o cenário se complica com a popularização dos grandes modelos de linguagem (LLMs) e o potencial de uso indevido dessas tecnologias, acelerando a criação, customização e proliferação de novas ferramentas maliciosas. Com isso, o ambiente de ameaças se torna cada vez mais dinâmico e desafiador.

Diante dessas tendências, é plausível esperar que futuros forks incorporem técnicas ainda mais avançadas de ofuscação, modularidade e evasão. Esse panorama ressalta a importância de estratégias de defesa proativas, com foco em detecção comportamental e análise aprofundada, para lidar com ameaças cada vez mais sofisticadas e em rápida evolução.

Indicadores de Comprometimento

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

Arquivos

Técnicas MITRE ATT&CK

Esta tabela foi criada usando a versão 17 do framework MITRE ATT&CK.