AsyncRAT: análise técnica do RAT modular que se esconde em processos assinados

O que você vai aprender neste artigo: a arquitetura e o funcionamento interno do AsyncRAT, um RAT (Remote Access Trojan — trojan de acesso remoto) modular e open-source escrito em C# (.NET). Você vai percorrer a cadeia de infecção em 5 estágios documentada pela Point Wild (empresa de threat intelligence que publica análises detalhadas de campanhas de malware), desde o .bat de engenharia social até a DLL final rodando dentro do charmap.exe — o Mapa de Caracteres do Windows, um executável assinado pela Microsoft. Vai aprender também a analisar cada estágio estaticamente, extrair a configuração do RAT, e montar regras de detecção para identificar a infecção antes que o C2 receba dados.

Pré-requisitos

Para acompanhar esta análise, você vai precisar de:

• Conhecimento básico de análise de malware e do ecossistema Windows: processos, binários .NET, registro e a suíte Sysinternals.
• Um ambiente isolado: máquina virtual com snapshots, rede simulada e captura de tráfego com Wireshark ou tcpdump.
• PEStudio, a ferramenta de análise estática que revela seções, imports e entropia sem executar o arquivo.
• XWorm, outro RAT modular que já analisamos aqui no Zero Day Security — vale como referência para comparar arquiteturas de RATs .NET.
• Opcional: PE-Sieve (ferramenta que detecta injeção de código em processos) e um depurador como x64dbg para análise dinâmica.

Introdução

O AsyncRAT é um RAT open-source hospedado no GitHub (repositório público do projeto mantido pelo perfil NYAN-x-CAT) e mantido desde 2019. Diferente de RATs comerciais ou vendidos em fóruns fechados, seu código-fonte é público e auditável — o que, paradoxalmente, o torna ainda mais perigoso: qualquer atacante pode modificá-lo, remover telemetria, trocar C2s e gerar builds personalizadas indetectáveis por assinaturas estáticas.

Já cobrimos a campanha ativa que entrega o AsyncRAT via AutoIt em uma notícia recente. Este artigo é o mergulho técnico: vamos abrir cada estágio, entender o que cada parte faz, como os dados são ofuscados e, principalmente, como detectar cada etapa da cadeia.

A arquitetura do AsyncRAT

O AsyncRAT segue o padrão clássico de RATs .NET: um servidor C2 escrito em C# com interface Windows Forms que controla múltiplos clientes (as máquinas infectadas). A comunicação é feita por TCP na porta configurável (4944 no espécime analisado), com o tráfego protegido por compressão e uma camada simples de XOR — não é criptografia real, mas é suficiente para esconder os comandos de uma inspeção de rede superficial.

Entre as capacidades nativas do AsyncRAT estão:

• Keylogging — captura completa de teclado, com suporte a teclas especiais e janela em foco.
• Captura de tela — via API Graphics.CopyFromScreen(), com compressão JPEG antes da transmissão.
• Acesso a webcam e microfone — gravação sob demanda.
• Gerenciamento remoto de arquivos — upload, download, execução e deleção.
• Reverse shell — shell remoto via cmd.exe ou PowerShell.
• Roubo de senhas — extração de credenciais salvas em navegadores (Chrome, Firefox, Edge).
• Sistema de plugins — módulos .NET carregados em memória que estendem as funcionalidades do RAT.

O sistema de plugins é o diferencial mais relevante: o AsyncRAT carrega assemblies .NET adicionais do C2 em tempo de execução, dentro do mesmo processo injetado. Isso significa que a capacidade do malware não é fixa — o atacante pode entregar módulos sob demanda, exatamente como o XWorm faz com seus plugins de ransomware e DDoS.

Os 5 estágios da infecção

A campanha analisada pela Point Wild usa uma cadeia de 5 estágios. Cada estágio resolve o próximo, e o payload final — a DLL do AsyncRAT — nunca toca o disco em texto claro. O diagrama abaixo mostra o fluxo completo:

Estágio 1: o .bat que parece fatura

O primeiro estágio começa com engenharia social. O arquivo Right-click to open Invoice Details.bat chega à vítima por e-mail (phishing com anexo malicioso — MITRE T1566.001), link, mensagem ou software trojanizado. O nome sugere uma fatura que precisa de atenção imediata — um gatilho clássico de urgência.

Ao ser executado (MITRE T1204.002), o .bat faz três coisas:

O primeiro passo é lançar o PowerShell com a janela oculta e o perfil desabilitado:

powershell.exe -WindowStyle Hidden -NoProfile -File temp.ps1 muYQOgi

A combinação de janela oculta com perfil desabilitado reduz a superfície de detecção: sem janela visível, sem logs de perfil, sem prompts para o usuário.

Em seguida, o script PowerShell cria um diretório com nome ofuscado sob %TEMP%. O nome é montado por código ASCII: [char]100,121,107,114,118,117,99,52,120 → dykrvuc4x. É um nome de aparência aleatória, mas gerado deterministicamente — o que permite que diferentes estágios usem o mesmo diretório.

Por fim, o PowerShell remonta um payload em Base64 que foi picado em dez fragmentos, armazenados em variáveis separadas, poluídos com asteriscos e interrogações, e decodificados com XOR de chave repetitiva de 16 bytes. Esse é o padrão clássico de ofuscação de cargas em estágios intermediários: tudo é montado em tempo de execução para que uma varredura estática do .bat ou do script .ps1 encontre apenas fragmentos sem sentido.

O script então salva dois arquivos no diretório dykrvuc4x:

• ogftogcyiblzjccmcbnw.exe — o interpretador AutoIt legítimo, assinado digitalmente, apenas renomeado.
• kojuyn.ini — o script AutoIt compilado (formato a3x) que age como loader.

E escreve um terceiro arquivo sem extensão: nloemfbihmhm (537 KB), o payload criptografado que será lido pelo loader.

Persistência: o .bat na pasta Startup

Antes de disparar a execução, o PowerShell escreve um arquivo h73la8.bat na pasta Startup do usuário (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup). O conteúdo é simples:

start "" "C:\Users\User\AppData\Local\Temp\dykrvuc4x\ogftogcyiblzjccmcbnw.exe" "C:\Users\User\AppData\Local\Temp\dykrvuc4x\kojuyn.ini"

É persistência em nível de usuário (MITRE T1547.001) — sem necessidade de administrador, sem chave de registro, sem tarefa agendada. O .bat aponta o interpretador AutoIt renomeado para o script loader, e o par é relançado a cada logon.

O PowerShell então executa o par imediatamente com Start-Process em janela oculta e encerra.

Estágio 2: o loader AutoIt que não parece nada

O interpretador AutoIt legítimo (cerca de 900 KB, assinado digitalmente, com nome aleatório) carrega o kojuyn.ini — um script AutoIt compilado que é o coração técnico da cadeia de evasão.

A primeira característica notável do script é que nenhuma string de API ou nome de função existe em texto claro. Cada string relevante é montada em tempo de execução a partir de listas de bytes codificados em XOR. O script carrega três decodificadores diferentes:

1. Decoder A — entrada separada por vírgulas, XOR byte a byte.
2. Decoder B — mesma lógica, mas separada por espaços (provavelmente uma variação gerada aleatoriamente pelo builder).
3. Decoder C — literais hex (0xD9E6FDFBFAEEE3), XOR com chave fixa 0x8F.

As strings decodificadas revelam a intenção completa:

Até mesmo as constantes de acesso são decompostas aritmeticamente: 250451 + 1785260 produz 0x1F0FFF (PROCESS_ALL_ACCESS), 990 + 11298 produz 0x3000 (MEM_COMMIT | MEM_RESERVE). Nenhum valor mágico aparece como literal hexadecimal.

A execução do loader segue esta sequência:

O primeiro passo é verificar se o arquivo nloemfbihmhm existe no mesmo diretório. Se não existir, o script sai silenciosamente — sem erro, sem mensagem, sem evento no Event Log. Esse é o ponto de falha mais importante para detecção: uma verificação de arquivo que falha silenciosamente significa que, se o AV remover o payload antes da execução, o script simplesmente morre sem levantar suspeita.

Em seguida, o script lê o payload criptografado em uma estrutura DllStruct e decodifica byte a byte com XOR de chave 0x36, percorrendo o buffer do último byte ao primeiro. O sentido reverso não altera o resultado do XOR, mas derrota regras de YARA que esperam um loop de decodificação progressivo. O payload decodificado — shellcode puro — existe apenas na memória heap do processo AutoIt.

Por fim, o script lança %WINDIR%\Syswow64\charmap.exe com a janela oculta (reforçada por WinSetState) e executa a cadeia clássica de injeção:

OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread

Cada chamada é uma função wrapper separada, e cada falha leva a uma saída imediata com Exit. O AutoIt então termina naturalmente, deixando o shellcode rodando dentro do charmap.exe.

Estágio 3: confirmação da injeção com PE-Sieve

Para confirmar a injeção, a Point Wild utilizou o PE-Sieve — ferramenta que varre a memória de um processo em busca de código implantado, hooks e módulos suspeitos. Contra o PID do charmap.exe, o resultado foi:

PID 27512 — Implanted PE: 1

Um PE completo — sem arquivo correspondente em disco — foi encontrado na memória do charmap.exe. O dump foi salvo como 3200000.exe.

Duas outras detecções chamam a atenção:

• 71380000.clr.dll — o runtime .NET carregado e hooked, confirmando que o PE implantado é um assembly .NET.
• 73ff0000.amsi.dll — a biblioteca AMSI (Antimalware Scan Interface, a API que expõe conteúdo malicioso aos antivírus do Windows) com AmsiScanBuffer patcheado. O loader fez o bypass de AMSI antes de carregar o assembly, para que nem o .NET nem scripts subsequentes sejam varridos.

O bypass de AMSI é o mesmo padrão visto em outros RATs .NET como o XWorm: um patch no prólogo da função AmsiScanBuffer que retorna AMSI_RESULT_CLEAN independentemente do conteúdo.

Estágio 4: o carregador .NET em estágios

O dump 3200000.exe não é o AsyncRAT final — é um carregador intermediário. A análise revelou uma função que processa um payload em múltiplos estágios de decodificação, cada um alimentando o próximo com uma chave extraída do estágio anterior.

Quando a decodificação termina, o buffer resultante começa com um cabeçalho PE — é uma DLL .NET completa. O carregador então injeta essa DLL de volta no mesmo processo charmap.exe (já com o AMSI bypassado), usando as APIs de hospedagem do .NET. O assembly é carregado com a flag InMemory = Yes — não existe em disco, não aparece em varreduras de arquivo.

Estágio 5: a DLL final do AsyncRAT

O último estágio é Veukuzmw.dll — uma DLL .NET fortemente ofuscada que contém o AsyncRAT completo. A análise estática identificou a função CaptureScreen(), que usa Graphics.CopyFromScreen() para capturar o conteúdo do monitor primário:

// Reconstruto conceitual da função de captura de tela
Bitmap screenshot = new Bitmap(Screen.PrimaryScreen.Bounds.Width,
                                Screen.PrimaryScreen.Bounds.Height);
Graphics g = Graphics.FromImage(screenshot);
g.CopyFromScreen(0, 0, 0, 0, screenshot.Size);
// Codifica como JPEG e transmite ao C2 via socket TCP

A imagem capturada é redimensionada e comprimida como JPEG antes de ser convertida em array de bytes e transmitida ao C2. O padrão é idêntico ao de outros RATs que cobrimos: captura contínua para monitoramento da atividade da vítima.

O C2 identificado foi 158.51.122.136:4944 — um IP direto (sem DNS), porta 4944, protocolo TCP customizado. A conexão não estava estabelecida no momento da captura, indicando que o servidor C2 pode estar intermitente ou que a amostra foi analisada antes do heartbeat completo.

Explicação técnica: por que a evasão funciona

A cadeia do AsyncRAT não é revolucionária em técnicas individuais — cada uma já é conhecida — mas a combinação delas cria um desafio real para defesas baseadas em assinatura.

DLL side-loading com binário legítimo

O interpretador AutoIt (AutoIt3.exe) é um executável legítimo e assinado digitalmente. Ao renomeá-lo e apontá-lo para um script .ini (que o AutoIt aceita como argumento de script), o atacante faz com que um binário confiável execute código arbitrário. Qualquer solução que confie cegamente em assinaturas digitais — sem observar o que o processo faz — vai deixar passar.

Ofuscação total de strings

Nenhuma string de API relevante existe no script AutoIt em texto claro. Cada nome de função, cada caminho de arquivo, cada constante é reconstruída em tempo de execução por decodificadores XOR. Isso derruba:

• Regras de YARA baseadas em strings literais (ex: WriteProcessMemory).
• Assinaturas de antivírus que procuram sequências conhecidas.
• Scanners de memória superficiais que varrem páginas não-executáveis.

AMSI bypass in-memory

O patch no AmsiScanBuffer é aplicado antes do assembly .NET ser carregado. Como o loader (o shellcode injetado pelo AutoIt) roda em código nativo, ele pode modificar a página de código da AMSI.dll sem acionar as proteções do .NET. O resultado é que o assembly .NET final — o AsyncRAT — carrega em um ambiente onde o AMSI está efetivamente desligado.

Injeção em processo assinado

O charmap.exe é um executável da Microsoft, assinado digitalmente, presente em todas as edições do Windows desde o Windows 95 (modo Unicode). Qualquer firewall de host que confie em processos assinados para liberar tráfego de saída vai permitir que o AsyncRAT se comunique com o C2. E qualquer ferramenta de inventário que liste apenas processos no disco vai perder o AsyncRAT completamente.

A carga nunca toca o disco em texto claro

Do estágio 1 ao 5, o payload malicioso existe em disco apenas em formas inócuas: fragmentos Base64 poluídos por caracteres lixo, ou um blob criptografado (XOR) sem extensão. O conteúdo decodificado só existe na memória — e dentro de uma região alocada por VirtualAllocEx em outro processo. Não há arquivo malicioso para hash, não há binário para enviar ao sandbox.

Como se proteger

A detecção do AsyncRAT e de cadeias similares baseadas em AutoIt exige uma abordagem que vá além da varredura de arquivos. As recomendações abaixo focam nos comportamentos que a cadeia não consegue esconder:

Monitoramento de criação de processos suspeitos. O PowerShell executando scripts temporários com -WindowStyle Hidden -NoProfile é um comportamento que ferramentas de EDR (Endpoint Detection and Response, detecção e resposta em endpoint) devem sinalizar. Crie regras de detecção para PowerShell com janela oculta disparando processos filho de %TEMP%.

Controle de aplicação com allowlisting. Soluções como AppLocker ou WDAC (Windows Defender Application Control) podem bloquear a execução de interpretadores AutoIt a partir de diretórios de usuário (%TEMP%, %APPDATA%). Configure regras que permitam executáveis apenas em Program Files, System32 e diretórios gerenciados centralmente.

Detecção de injeção em charmap.exe. Monitore o processo charmap.exe por comportamento anômalo: conexões de rede de saída em portas não padrão (acima de 1024, especialmente portas como 4944), carga de assemblies .NET em processos que normalmente não carregam o runtime, ou threads recém-criadas fora do padrão do processo. O PE-Sieve pode ser usado como ferramenta de resposta para confirmar suspeitas.

Regras YARA para fragmentos de cadeia. Embora o payload principal seja ofuscado, é possível detectar padrões nos estágios intermediários — especialmente as constantes de ascesso decompostas aritmeticamente (somas que produzem PROCESS_ALL_ACCESS) e os decodificadores XOR do AutoIt com listas de bytes separados por vírgula ou espaço.

rule AutoIt_XOR_Decoder_Strings {
  meta:
    description = "Detecta padrões de decodificadores XOR em scripts AutoIt"
    reference = "Point Wild AsyncRAT analysis"
  strings:
    $decoder_comma = "StringSplit" ascii
    $decoder_value = "Asc" ascii
    $decoder_xor = "BitXOR" ascii
  condition:
    all of them
}

Bloqueio de extensões não padrão no Startup. Monitore a pasta Startup para arquivos .bat que invoquem executáveis de %TEMP%. A cadeia do AsyncRAT precisa escrever um .bat no Startup para persistir — é o elo mais frágil e o mais fácil de detectar com uma regra de Sysmon:

<!-- Regra Sysmon para Event ID 11 (FileCreate) -->
<RuleGroup name="" groupRelation="or">
  <FileCreate onmatch="include">
    <TargetFilename condition="contains">Startup</TargetFilename>
    <TargetFilename condition="ends with">.bat</TargetFilename>
  </FileCreate>
</RuleGroup>

Conclusão

O AsyncRAT exemplifica o estado da arte de RATs modulares open-source: o código é público, as técnicas são conhecidas, mas a combinação delas em uma cadeia de 5 estágios com AutoIt legítimo, AMSI bypass e injeção em processo assinado cria um desafio real para defesas tradicionais baseadas em hash ou assinatura de arquivo.

O ponto central para defesa não é o AsyncRAT em si — é o loader. Se o .bat de persistência for detectado, se o AutoIt for bloqueado em diretórios de usuário, ou se o charmap.exe for monitorado por conexões de saída suspeitas, a cadeia inteira cai. Ao focar nos comportamentos que a cadeia precisa executar — escrever no Startup, lançar PowerShell oculto, carregar o runtime .NET em charmap.exe — a detecção se torna possível mesmo sem conhecer o hash específico da amostra.

Perguntas frequentes

Fontes e leituras adicionais

• Point Wild — AsyncRAT Delivered via AutoIT: Full Chain Analysis — 10/09/2026
• Point Wild — The Rise of AsyncRAT — 2026
• ANY.RUN — AsyncRAT's Infection Tactics via Open Directories: Technical Analysis — 07/11/2024
• Any Run — AsyncRAT Malware Analysis Overview — 2026
• Zero Day Security — O trojan que se esconde dentro de um app da Microsoft — 28/09/2026
• GitHub (NYAN-x-CAT) — AsyncRAT — Remote Access Tool — 2019–2026