Introdução

Em fevereiro de 2026, a equipe de threat intelligence da ZenoX identificou durante atividade de hunting uma família de malware ainda desconhecida, classificada internamente como VENON devido a menções dele no código, porém com N mesmo. A amostra foi inicialmente sinalizada por comportamento consistente com trojans bancários da América Latina, em especial o uso de overlay bancário e monitoramento de janelas ativas, características presentes em famílias consagradas como Grandoreiro e Mekotio.

A diferença fundamental surgiu durante a análise estática: ao contrário de todas as famílias conhecidas do ecossistema latino-americano, o VENON não contém uma linha sequer de código Delphi. O binário é compilado inteiramente em Rust, com 88 dependências externas identificadas de Crates.

Durante a análise, a equipe levantou a hipótese de que o VENON pode ser, em sua essência, um refactor via Videcode por IA de um trojan bancário já consolidado na região, possivelmente o próprio Grandoreiro, reescrito do zero em Rust. A fidelidade com que padrões funcionais clássicos do ecossistema Delphi, como a lógica de overlay, o monitoramento de janelas e os mecanismos de swap, foram reproduzidos em uma linguagem de sistemas completamente diferente sugere que o autor não partiu de uma concepção original, mas de uma base comportamental conhecida, utilizando IA generativa para realizar a tradução técnica.

Evidências adicionais de uso de IA foram identificadas na própria infraestrutura do operador: o código do painel C2 apresenta padrões de geração assistida consistentes com o que a comunidade de segurança tem denominado vibe coding, reforçando a hipótese de que toda a operação, do malware ao backend, foi construída com auxílio extensivo de ferramentas de IA.

Até o momento desta publicação, a ZenoX não identificou nenhum outro trojan bancário do ecossistema brasileiro ou latino-americano com este perfil técnico. O VENON representa, possivelmente, a primeira aparição de um banker RAT brasileiro desenvolvido inteiramente em Rust, com nível de sofisticação comparável a ferramentas de grupos APT conhecidos.

Clique aqui para ler o relatório completo

Complexidade de Análise

O VENON apresenta um nível de dificuldade de análise estática significativamente superior ao dos trojans bancários latino-americanos tradicionais. Enquanto malwares em Delphi como Grandoreiro ou Mekotio podem ser examinados com relativa facilidade, com strings legíveis, RTTI exposta e componentes visuais identificáveis, o VENON combina múltiplas camadas de proteção que tornam cada etapa da reversão um desafio técnico distinto.

Para um analista familiarizado com trojans Delphi, onde uma sessão de análise com x64dbg revela strings como “Banco do Brasil” ou “Itau” nos primeiros minutos, o VENON exige um investimento de tempo e ferramental de ordem de magnitude superior.

Barreira	Detalhe
UPX com headers modificados	Impede descompressão automática; exige reconstrução manual dos headers antes de processar o binário
Compilação Rust nativa	Funções com nomes mangled, 88 crates, ausência de RTTI e símbolos de debug
XOR encryption com 95 funções únicas	Cada string sensível é decriptada por uma função de key derivation diferente; não há chave global reutilizável
Argon2id + XChaCha20-Poly1305	Criptografia estado-da-arte para o config remoto; exige reimplementação dos parâmetros KDF para decriptar
ChaCha20-Poly1305 no C2	Tráfego C2 encriptado por sessão via ring-0.17.14; sem possibilidade de inspeção passiva sem a chave de sessão
9 técnicas anti-análise ativas	AMSI bypass, ETW bypass, ntdll overwrite, indirect syscalls, thread hiding, DACL, anti-sandbox, anti-screenshot e Defender SID check

Tabela 1 – Barreiras de Análise

Nenhuma ferramenta isolada foi suficiente para cobrir todas as camadas de proteção. A análise exigiu a construção de um pipeline de seis fases, cada um alimentando a próxima com as informações necessárias para avançar:

Fase	Ferramenta / Técnica	Resultado
Fase 1	DIE/PE Analysis + descompressão UPX manual	libcef.dll descompactada (9,3 MB)
Fase 2	FLOSS v3.1.1	130.749 strings estáticas + 41.799 strings Rust extraídas; deobfuscação automática desabilitada pela densidade do binário
Fase 3	Ghidra 12.0.4 Headless	17.765 funções identificadas; 500 funções de interesse decompiladas; 143.093 linhas de C decompilado geradas
Fase 4	Python + Capstone	95 blocos XOR processados; 92 decifrados com sucesso (96,8% de cobertura)
Fase 5	Reimplementação de Argon2id KDF + XChaCha20-Poly1305	Config remoto decriptado; host C2 confirmado
Fase 6	Categorização das 143.093 linhas decompiladas	14 grupos funcionais mapeados, 70+ funcionalidades documentadas, módulos Rust reconstruídos

Tabela 2 – Pipeline de Análise Adotado

O nível de esforço necessário para analisar o VENON é, por si só, uma métrica da sofisticação do artefato. Um trojan que exige a construção de ferramentas de análise customizadas, não é um malware comum. É um artefato que reflete competência técnica avançada do seu autor e que eleva significativamente o custo de análise para qualquer equipe de resposta a incidentes ou threat intelligence.

Infection Chain

A infection chain do VENON é estruturada em onze fases sequenciais, combinando engenharia social via engenharia social, múltiplas camadas de evasão e um mecanismo de entrega de payload sofisticado. A campanha demonstra planejamento técnico considerável, com cada fase projetada para superar controles de segurança específicos antes de avançar para a próxima.

Vetor Inicial

O vetor de entrada confirmado é o DLL sideloading via o instalador legítimo do NVIDIANotification.exe: a libcef.dll maliciosa é carregada no lugar da Chromium Embedded Framework legítima aproveitando o DLL search order do Windows, que prioriza o diretório do executável. O mecanismo de entrega inicial do conjunto NVIDIANotification.exe + libcef.dll ao sistema da vítima, no entanto, não foi determinado com alta confiança durante esta análise.

Vale notar que, no período de identificação desta amostra, a ZenoX observou um aumento significativo de campanhas ClickFix utilizando o NVIDIANotification.exe como payload final, onde a vítima é induzida por engenharia social a executar um comando que realiza o download e a ativação do par de arquivos. A correlação entre o artefato analisado e este vetor de distribuição é plausível e está sendo investigada, mas não foi possível confirmar com confiança suficiente para incluí-la como achado definitivo neste relatório.

A análise da cadeia de infecção documentada neste relatório tem início a partir do momento em que o par NVIDIANotification.exe + libcef.dll já se encontra presente no sistema da vítima.

A distribuição ocorre via e-mails de phishing, páginas falsas imitando portais legítimos ou anúncios patrocinados. Em todos os cenários, a execução do dropper depende exclusivamente da ação voluntária da vítima; nenhum exploit técnico é necessário nesta etapa.

install via PowerShell

Arquivo batch ofuscado de ~1,6 KB. Strings críticas (URLs, caminhos, comandos) são reconstruídas em runtime por concatenação de variáveis fragmentadas, evitando detecção estática por assinatura.

O Script relança a si mesmo com RunAs via PowerShell caso não esteja rodando como administrador.

Figura 1 – Privilege Escalation

Adiciona C:\ProgramData\USOShared\ NuPLihaOH\ via Add-MpPreference antes do download. O diretório pai imita o Update Session Orchestrator; o espaço no nome da subpasta dificulta buscas por linha de comando.

Figura 2 – Defender exclusion

ZIP obtido de bucket S3 via Invoke-WebRequest, com URL construída dinamicamente por fragmentação de variáveis.

Figura 3 – Payload download

O ZIP contém NVIDIANotification.exe (binário NVIDIA assinado) e libcef.dll (malware). O executável é renomeado para ®mjtgr.exe; o caractere ® (U+00AE) no prefixo dificulta referências por CLI e ferramentas forenses.

Figura 4 – Extração e renomeação

Run key adicionada em HKCU\…\Run; exclusão individual criada para ®mjtgr.exe.

Figura 5 – Persistência + second exclusion

Script se auto-deleta via (goto) 2>nul & e força reboot em 3 segundos (shutdown /r /t 3 /f), ativando a run key e eliminando evidências do vetor de entrada.

Figura 6 – Self-deletion e reboot

DLL Sideloading

Após o reboot, o Windows executa ®mjtgr.exe via run key. Como o DLL search order do Windows prioriza o diretório do executável, a libcef.dll maliciosa é carregada no lugar da Chromium Embedded Framework legítima.

O processo aparece no Task Manager com nome e assinatura digital da NVIDIA. A DLL exporta as funções padrão de um COM object (DllCanUnloadNow, DllGetClassObject, DllMain, DllRegisterServer, DllUnregisterServer) para mimetizar uma DLL legítima; todo o código malicioso reside no handler DLL_PROCESS_ATTACH do DllMain.

Inicialização e Evasão

Ao ser carregada, a DLL executa nove técnicas de evasão em sequência antes de iniciar qualquer atividade maliciosa.

A técnica mais sofisticada desta fase é o overwrite da seção .text da ntdll.dll em memória com a versão limpa lida do disco.

Figura 7 – ntdll .text Overwrite

Para operações sensíveis, o malware implementa indirect syscalls: os syscall numbers são lidos diretamente da ntdll em disco e stubs são construídos em memória, contornando qualquer hook que pudesse ser reinstalado. Por fim, aplica thread hiding via NtSetInformationThread com o flag ThreadHideFromDebugger, modifica a DACL do próprio processo para negar acesso externo, e configura SetWindowDisplayAffinity nos overlays para que screenshots exibam apenas tela preta.

Figura 8 – ThreadHideFromDebugger + DACL Protection

Remote Config Fetch

A config thread realiza uma requisição GET para hxxps://storage.googleapis[.]com/mydns2026/startabril2026, com fallback para hxxps://pluginsafeguard[.]help/ipv4/config.enc. O Google Cloud Storage é utilizado como canal primário por ser raramente bloqueado por firewalls corporativos.

O response passa por três camadas de decriptação: Base64 decode, seguido de key derivation via Argon2id (m=19456 KiB, t=2, p=1) com senha L0@D_S3CR3T_K3Y_X9F2_PR0D_2024! e salt LOAD_SALT_2024!!, e por fim decriptação XChaCha20-Poly1305 com nonce de 24 bytes extraído do início do blob. O resultado é um JSON contendo o endereço do C2: {“host”:”brasilmotorsvs14[.]com”}.

Versões anteriores deste RAT utilizavam AES-256-CBC com SHA-256 e IV zero, significativamente mais fraco. A migração para Argon2id e XChaCha20-Poly1305 reflete evolução técnica deliberada entre versões.

Figura 1 – XOR Decrypt Secret Key + Salt

Persistência e C2

Após obter a configuração, o malware instala uma Scheduled Task denominada “NVIDIA Notification Service” com trigger AtLogOn e run level máximo, substituindo o mecanismo de WMI Event Subscription utilizado em versões anteriores. A conexão WebSocket ao C2 é estabelecida sob TLS 1.3 com cifra ChaCha20-Poly1305 via tungstenite e rustls. Cada vítima é identificada por um HardwareID calculado como SHA-256 do nome do computador concatenado ao volume serial.

Itaú Swap

Além dos mecanismos de ataque via overlay bancário e manipulação de clipboard, o VENON implanta dois blocos de código VBScript extraídos diretamente de libcef.dll. Esses blocos implementam um mecanismo de shortcut hijacking direcionado ao Aplicativo Itau, substituindo atalhos legítimos do sistema por versões adulteradas que redirecionam a vítima para uma página web sob controle do operador, preservando o icone original do banco para evitar suspeita.

Este é um módulo em VB exclusivo do Itaú, os demais bancos e alvos não foram encontrados scripts customizados como este.

O ataque é operado em dois estágios distintos: install, que realiza a substituição dos atalhos, e uninstall, que reverte as modificações. A presença do segundo bloco indica que o mecanismo e controlável via C2, permitindo ao operador restaurar os atalhos antes de encerrar a sessão ou ao detectar sinais de investigação.

Bloco 1: Install

O script de install e responsável por localizar e adulterar todos os atalhos do Aplicativo Itau presentes na máquina da vítima. A execução segue quatro etapas principais:

• Resolução do path do Microsoft Edge: o script consulta o registry em HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\msedge.exe. Caso a chave esteja ausente, tenta o caminho alternativo WOW6432Node, e em seguida verifica diretamente os caminhos padrão de instalação em Program Files (x86) e Program Files. Se o Edge não for encontrado por nenhum dos métodos, o script escreve -2 no arquivo de resultado e encerra sem realizar modificações.
  
  
• Enumeração de locais alvo: o script define um array com oito locais do sistema de arquivos onde atalhos do Itau podem existir.
  
  
• Identificação de atalhos Itau: para cada arquivo .lnk encontrado nos locais alvo, o script abre o atalho via WScript.Shell.CreateShortcut e verifica se o TargetPath contém qualquer das strings itauaplicativo.exe, aplicativo itau ou itauaplicativo. A comparação e feita em lowercase para garantir case-insensitivity.
  
  

Figura 2 – Identificação de atalhos do Itaú

• Substituição e preservação do icone: atalhos identificados como Itaú tem o TargetPath substituído pelo caminho do msedge.exe resolvido anteriormente, e os Arguments definidos como hxxps://www.itau.com[.]br/empresas. O WorkingDirectory e limpo. Criticamente, o IconLocation original e preservado caso existente, tornando o atalho visualmente idêntico ao original. O número de atalhos modificados e gravado no arquivo de resultado.

Variavel / Folder	Caminho expandido (exemplo)
Desktop (usuario)	%USERPROFILE%\Desktop
Desktop (publico)	%PUBLIC%\Desktop
StartMenu\Programs	%APPDATA%\Microsoft\Windows\Start Menu\Programs
StartMenu\Programs\Itau	…\Programs\Itau
StartMenu\Programs\Aplicativo Itau	…\Programs\Aplicativo Itau
AllUsersPrograms	%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs
AllUsersPrograms\Itau	…\Programs\Itau
AllUsersPrograms\Aplicativo Itau	…\Programs\Aplicativo Itau

Tabela 1 – Locais enumerados pelo script VBS

Bloco 2: Uninstall / Restore

O segundo bloco implementa a operação inversa: identifica atalhos previamente adulterados e os restaura para o executável original do Aplicativo Itaú. A logica de identificação e distinta do Bloco 1 e baseia-se nos artefatos deixados pela modificação, não nos atributos originais do atalho.

O script resolve o caminho do executável legitimo do Itau verificando dois possíveis locais de instalação: %USERPROFILE%\AppData\Local\Aplicativo Itau\itauaplicativo.exe e %USERPROFILE%\AppData\Local\ItauAplicativo\itauaplicativo.exe. Caso nenhum dos dois seja encontrado, usa o primeiro caminho como fallback. Isso sugere que o operador pode acionar o uninstall mesmo em máquinas onde o aplicativo não está instalado, possivelmente para encobrir rastros antes que a vítima note a adulteração.

A função IsModifiedItauShortcut identifica atalhos adulterados verificando se o TargetPath aponta para msedge.exe, microsoft-edge, chrome.exe ou firefox.exe, em combinação com um Arguments contendo a string itau.com.br. A inclusão de Chrome e Firefox como critérios de detecção indica que o operador pode ter variantes do ataque que usam outros navegadores, ou que o critério foi projetado para ser robusto contra futuras variações do Bloco 1.

Atalhos identificados tem o TargetPath restaurado para o executável do Itaú, os Arguments limpos, e o IconLocation redefinido para itauaplicativo.exe,0 caso o arquivo exista no disco. A contagem de atalhos restaurados e gravada no arquivo de resultado, o que sugere que o C2 monitora o sucesso da operação.

Alvos Monitorados

O VENON monitora 33 instituições financeiras e plataformas de ativos digitais, distribuídas em seis categorias. O monitoramento e realizado via verificação de título de janela e domínio ativo no navegador, ativando os mecanismos de ataque ao detectar qualquer um dos alvos abaixo.

#	Instituição	Domínio monitorado
1	Itaú Unibanco	itau.com.br
3	Santander Brasil	santander.com.br
4	Caixa Econômica Federal	caixa.gov.br
5	Banco do Brasil	bb.com.br
6	Nubank	nubank.com.br
7	Banco Inter	bancointer.com.br
9	Sicoob	(string parcialmente decodificada; confirmado via titulo “- sicoob”)
10	Sicredi	sicredi.com.br
11	Banco Original	original.com.br
12	Banco Safra	safra.com.br

Tabela 1 – Bancos tradicionais

#	Instituição	Domínio monitorado
13	BTG Pactual	btgpactual.com

Tabela 2 – Banco investimentos

#	Instituição	Domínio / Identificador
14	PagBank / PagSeguro	pagseguro.uol.com.br
15	PicPay	picpay.com
16	Mercado Pago	mercadopago.com.br
17	Bling ERP	(título de janela: “bling erp”)

Tabela 3 – Fintech / pagamentos

#	Instituição	Domínio monitorado
18	Receita Federal	receita.fazenda.gov.br, gov.br/receitafederal

Tabela 4 – Governo

#	Plataforma	Domínio monitorado
19	Binance	binance.com
20	Coinbase	coinbase.com
21	Kraken	kraken.com
22	Bybit	bybit.com
23	Mercado Bitcoin	mercadobitcoin.com
24	Foxbit	foxbit.com
25	Gemini	gemini.com
26	Nexo	nexo.com
27	Ripio	ripio.com

Tabela 5 – Exchange e criptos

#	Plataforma	Identificador
28	MetaMask	(título de janela: “metamask”)
29	Trust Wallet	(título de janela: “trust wallet”)
30	Phantom	phantom.app
31	Ledger Live	ledger.com
32	Rabby Wallet	rabby.io
33	Cake DeFi	app.cakedefi

Tabela 6 – Wallets cryptos

O Primeiro Banker RAT Brasileiro em Rust

Durante as fases iniciais da análise, a equipe da ZenoX identificou diversas similaridades comportamentais com famílias consagradas do ecossistema latino-americano, em especial o Grandoreiro: uso de overlay bancário para interceptação visual, monitoramento de janelas ativas, mecanismos de persistência via registro, e estrutura de comando e controle com capacidade de operação remota. A princípio, o artefato parecia mais um representante do paradigma clássico de trojans bancários LATAM.

A diferença fundamental surgiu durante a análise estática: ao contrário de todas as famílias conhecidas da região, o VENON não contém uma linha sequer de código Delphi. O binário inteiro é compilado a partir de Rust, com 88 crates identificados no Cargo.lock e 17.765 funções. Não se trata de somente um loader Rust entregando um payload Delphi, como observado de forma experimental no Casbaneiro. O payload final, com toda a lógica de ataque, criptografia, evasão e comunicação com C2, é Rust nativo end-to-end.

Até o momento desta publicação, a ZenoX não identificou nenhum outro trojan bancário do ecossistema latino-americano ou brasileiro com este perfil. O VENON representa, possivelmente, a primeira descoberta de um banker RAT brasileiro desenvolvido inteiramente em Rust, com nível de sofisticação técnica comparável a ferramentas de grupos APT.

O Ecossistema de Trojans Bancários Latino-Americanos

A América Latina, e o Brasil em particular, é o epicentro global de trojans bancários. Das 30 principais famílias detectadas mundialmente, 11 são de origem brasileira, representando 22% de todas as detecções em 2024. O Brasil sozinho concentra 61% das detecções de trojans bancários na região (ESET, 2024).

O ecossistema é historicamente dominado por famílias escritas em Delphi, uma linguagem que oferece binários autossuficientes e facilidade de desenvolvimento de interfaces gráficas para os overlays bancários. A tabela abaixo lista as principais famílias ativas e suas características de linguagem:

Família	Linguagem	Perfil
Grandoreiro	Delphi	O maior banker LATAM: 1.700 bancos, 45 países, modelo MaaS parcial
Mekotio	Delphi	Europa e LATAM, uso extensivo de PowerShell no dropper
Casbaneiro	Delphi + Rust*	Uso experimental de Rust apenas no downloader; payload final em Delphi
Guildma	Delphi	Também conhecido como Astaroth; ofuscação XOR de strings
Mispadu	Delphi	SAMBA SPIDER; dropper via HTA/VBScript
Coyote	.NET + Nim	Surgido em 2024; instalador Squirrel; 61 bancos brasileiros
Kiron	Rust	Downloader Rust com DGA e roubo de credenciais de navegadores (2024); sem lógica de ataque bancário em Rust
VENON	Rust nativo	RAT bancário completo em Rust: 88 crates, evasão ativa, criptografia estado-da-arte

Tabela 1 – Comparação de perfis entre malwares latino-americanos

* O Casbaneiro utilizou Rust de forma experimental apenas em componente de download em 2023; o core do malware permanece em Delphi.

A tabela a seguir compara os atributos técnicos do VENON com as três famílias mais representativas do ecossistema: Grandoreiro (volume e abrangência), Coyote (linguagem moderna, Brasil) e Mekotio (presença europeia).

Característica	VENON	Grandoreiro	Coyote	Mekotio
Linguagem	Rust nativo	Delphi	.NET + Nim	Delphi
Período ativo	2024-2026	2017-2026	2024-2026	2015-2026
Tamanho binário	9,3 MB (UPX)	390-414 MB	~50 MB	~20-30 MB
Alvos (bancos)	36+	1.700+	61+	50+
Alvos (crypto)	21 plataformas	276 wallets	Não	Não
Abrangência geo	Brasil	45 países	Brasil	LATAM + Europa
Protocolo C2	WebSocket TLS	RealThinClient	SSL mutual	TCP custom
Criptografia C2	ChaCha20-Poly1305	AES-CTS	AES	XOR + custom
Config encrypt	Argon2 + XChaCha20	AES-256	AES	XOR
AMSI bypass	Sim	Não	Não	Não
ETW bypass	Sim	Não	Não	Não
ntdll unhook	Sim	Não	Não	Não
Indirect syscalls	Sim	Não	Não	Não
Pix QR intercept	Sim	Não	Não	Não
Boleto swap	Sim	Não	Não	Parcial
Screen streaming	DXGI (GPU)	Screenshots	Screenshots	Screenshots
Modelo operacional	Solo / artesanal	MaaS (parcial)	Solo	Solo

Tabela 2 – Análise Comparativa: VENON vs. Famílias Estabelecidas

Atribuição

A atribuição do VENON a um operador ou grupo conhecido apresentou baixa confiança ao longo de toda a análise. Apesar de o malware compartilhar diversas características comportamentais com famílias estabelecidas da América Latina, como Grandoreiro, Mekotio e Coyote, as diferenças técnicas estruturais são suficientemente profundas para impedir uma atribuição com alta confiança a qualquer grupo ou campanha previamente documentada na região.

Hipótese: Desenvolvimento Assistido por IA

Um elemento que complicou tanto a análise quanto a atribuição é a hipótese de que o VENON pode ter sido desenvolvido com auxílio extensivo de inteligência artificial, o que a comunidade de segurança tem denominado como “vibe coding”. A estrutura do código Rust apresenta padrões que sugerem um desenvolvedor familiarizado com as capacidades dos trojans bancários latino-americanos existentes, mas que utilizou IA generativa para reescrever e expandir essas funcionalidades em Rust, uma linguagem que exige experiência técnica significativa para ser usada com o nível de sofisticação observado.

Esta hipótese explicaria algumas assimetrias observadas no código: a convivência de implementações criptográficas estado-da-arte com estruturas de controle relativamente diretas, e a reprodução em Rust de padrões funcionais comuns em Delphi, como a lógica de swap e a enumeração de janelas, com fidelidade técnica maior do que seria esperado de um desenvolvedor Rust de primeira viagem. Se confirmada, esta seria uma das primeiras evidências documentadas de uso de IA para desenvolvimento de trojans bancários na América Latina.

Exposição do Desenvolvedor via Artefatos de Compilação

Durante o processo de extração de strings em uma versão inicial da DLL (janeiro de 2026), identificada em fase de hunting, a equipe da ZenoX localizou caminhos de compilação locais expostos no binário. Diferentemente da versão analisada como objeto principal deste relatório, esta amostra anterior não havia removido os paths completos do ambiente de desenvolvimento do autor.

Os paths expostos contêm repetidamente o username byst4, revelando o nome de usuário da máquina local onde o malware foi compilado. A sequência de strings presentes no binário inclui caminhos como C:\Users\byst4\.cargo\registry\src\..., padrão consistente ao longo de dezenas de entradas correspondentes aos crates Rust utilizados no projeto.

Tabela 1 – Menção de username nos crates do Rust expondo o desenvolvedor

Este tipo de exposição é comum em compilações Rust quando o código não passa por um processo de sanitização de paths de debug, e representa um erro operacional do desenvolvedor na preparação da amostra inicial.

Artefato	Observação
Path de compilação exposto	C:\Users\byst4\.cargo\registry\src\index.crates.io-… presente em dezenas de strings do binário
Username do desenvolvedor	byst4, identificado consistentemente nos paths de crates Rust: tokio, tungstenite, chacha20poly1305, cipher, generic-array, futures-util
Versão da amostra	Amostra de janeiro de 2026; versão posterior remove os paths; indica maturação operacional entre as versões

Tabela 2 – Análise dos fingerprints do programador

Repositório GitHub e Infraestrutura C2

A partir do username byst4, a equipe realizou hunting em plataformas de desenvolvimento de código e identificou um repositório deletado no GitHub, cujo histórico de commits permaneceu parcialmente acessível. O repositório estava vinculado ao usuário byst4****(REDACTED), variante do nome identificado no binário e coerente com o alias ST4RK presente nas strings do malware da versão de janeiro de 2026, que posteriormente foi renomeado para VENON em fevereiro de 2026.

O repositório continha um script de configuração de infraestrutura intitulado setup_ssl_infrastructure.sh, com 934 linhas e autoria atribuída ao “Quantum Team”, versão 2.0, datado de 2024. O script automatiza o provisionamento completo de um servidor C2, incluindo configuração SSL, proxy reverso, usuários de sistema e página de camuflagem.

Tabela 3 – Arquivo deletado de infraestrutura C2

Dois elementos do script são particularmente relevantes para a correlação com o VENON:

• A rota /ws aparece explicitamente no script de infraestrutura como endpoint WebSocket do C2. Esta é a mesma rota identificada no código do malware e confirmada durante a análise do tráfego de rede, representando um indicador técnico de correlação entre o desenvolvedor do script e o autor do VENON.
  
  
• O script provisiona um diretório /var/www/quantum/ para uma página de camuflagem (“FASE 14: PÁGINA DE CAMUFLAGEM”), com title Analytics Platform – Professional Data Analysis. O uso de uma página legítima como fachada é consistente com a infraestrutura de C2 observada no VENON, que opera em domínios de aparência legítima.
  
  

Indicador	Evidência	Nível de confiança
Username do desenvolvedor	byst4 em paths de compilação da amostra de jan/2026	Alto
Alias operacional	ST4RK em strings do malware; byst4****( REDACTED) no GitHub	Alto
Correlação de infraestrutura	Rota /ws no script de infra corresponde ao endpoint C2 do malware	Médio-Alto
Repositório GitHub deletado	setup_ssl_infrastructure.sh acessível via commit history em conta byst4****(REDACTED)	Médio
Padrão de domínios C2	Promosepotify[.]com (script) e brasilmotorsvs14[.]com (malware); ambos com aparência legítima	Médio
Atribuição a grupo conhecido	Sem correspondência com TTPs de grupos documentados na América Latina	Baixo

Tabela 4 – Indicadores de Atribuição

Indicadores de comprometimento

Tipo	Indicador	Descrição / Contexto
Domínios
Domain	brasilmotorsvs14[.]com	C2 WebSocket principal (Cloudflare)
Domain	lazybearpottery[.]net	C2 alternativo (Cloudflare)
Domain	digitalmoineyp[.]com	Infraestrutura de distribuição
Domain	portalhondihs[.]com	Infraestrutura de distribuição
Domain	storage.googleapis[.]com	Dead drop – GCS bucket mydns2026
URLs
URL	https://s3.sa-east-1.amazonaws[.]com/8151218-25.2025.7.12.5178/modmarco2026-2.zip	Payload – AWS S3 (sa-east-1)
URL	https://storage.googleapis[.]com/mydns2026/startabril2026	Dead drop resolver – GCS
URL	https://storage.googleapis[.]com/mydns2026/startmarco2026_1_	Dead drop resolver – GCS
URL	https://storage.googleapis[.]com/mydns2026/startjaneiro_1_	Dead drop resolver – GCS
URL	https://storage.googleapis[.]com/mydns2026/startabril_2	Dead drop resolver – GCS
URL	https://pastebin.com/raw/2qEMcLsD	Dead drop resolver – Pastebin
URL	https://digitalmoineyp[.]com/v2/cloudflare/avsmail/recive.php	Endpoint de distribuição
Endereços IP – C2 / Painel
IP	104.21.7[.]106	brasilmotorsvs14.com – Cloudflare CDN
IP	188.114.96[.]3	lazybearpottery.net – Cloudflare CDN
IP	206.0.29[.]58	Painel VENON – LACNIC
IP	51.222.75[.]250	Painel VENON – OVH Canada
IP	51.222.75[.]248	Painel VENON – OVH Canada
IP	192.99.226[.]117	Painel VENON – OVH Canada
IP	212.69.5[.]84	Painel VENON – Europa
IP	34.227.229[.]85	Painel VENON – AWS EC2
Endereços IP – Serviços Legítimos Abusados
IP	34.117.59[.]81	ipinfo.io – fingerprinting de geolocalização
IP	142.251.140[.]187	storage.googleapis.com – dead drop GCS
IP	142.251.141[.]67	c.pki.goog – validação CRL
IP	142.251.140[.]163	o.pki.goog – validação OCSP
Caminhos no Sistema de Arquivos
Path	C:\ProgramData\USOShared\NuPLihaOH\	Diretório de staging do implante
Path	C:\ProgramData\USOShared\NuPLihaOH\NVIDIANotification.exe	Executável legítimo NVIDIA (sideloading)
Path	C:\ProgramData\USOShared\NuPLihaOH\®mjtgr.exe	Implante principal (prefixo Unicode)
Path	C:\ProgramData\USOShared\NuPLihaOH\qYogBt.zip	ZIP temporário no staging
Chaves de Registro
Registry	HKCU\Software\Microsoft\Windows\CurrentVersion\Run	Persistência – executa ®mjtgr.exe no logon
Processos
Process	®mjtgr.exe	Implante principal (PID 6864)
Process	NVIDIANotification.exe	Executável legítimo NVIDIA – veículo de sideloading
Process	CasPol.exe	LOLBin – alvo de sideloading
Process	wscript.exe	Executor de scripts VBS
Arquivos
File	libcef.dll	DLL maliciosa – sideloading via CEF (packed)
File	NVIDIANotification.exe	Executável legítimo NVIDIA usado como loader
File	®mjtgr.exe	Implante renomeado (prefixo Unicode ®)
File	qYogBt.zip	ZIP temporário no staging
File	modmarco2026.zip	Payload versionado – hospedado em S3
File	DocumentReclamaAQUI_56b2ca9811.cmd.bin	CMD dropper (fase F1)
File	Itau_swap_install.vbs	Script VBS – swap de atalho Itaú
File	startabril2026	Dead drop resolver – GCS
File	startmarco2026_1_	Dead drop resolver – GCS
File	startjaneiro_1_	Dead drop resolver – GCS
File	startabril_2	Dead drop resolver – GCS
Hashes
MD5	427ccfa456ed27a819aa152708212ff4	libcef.dll (packed)
SHA256	c482286a7fdfb64d308c197a4deabcd773b8b62d9e74d1d08fcfd02568d75d72	libcef.dll (packed)
MD5	2d1c4778094ba0e1a6e13bb67ce1b631	libcef.dll (unpacked)
SHA256	75d1a2560cf93c6a028aa3573febddaf713014d64b0e8904488111772e4cff49	libcef.dll (unpacked)
MD5	a99cb35768489b7aacf2d31d33d8f541	Itau_swap_install.vbs
SHA256	fd5d9effc1ef77a49b0720d2691bc144f513609760c22fa62bc1e8b84dedf879	Itau_swap_install.vbs
SHA256	78b62856878cb09602b14104df18ca2bedac8640e09d74b934ff3ea0e15627f3	Amostra adicional
SHA256	d61be2b21e135726c547a388ecb47552559e5221894f5005ce35bdb24efc0c26	Amostra adicional