Key Findings:
Durante atividades de threat hunting conduzidas na plataforma ANY.RUN, o artefato foi identificado em submissões públicas do sandbox interativo. A análise das amostras disponíveis no repositório público permitiu correlacionar os hashes e comportamentos de rede com a infraestrutura C2 já mapeada (24.152.36.241), confirmando que a campanha GrabBot/Slinky está ativa e sendo distribuída em ambiente real. Os resultados do sandbox complementam a análise estática apresentada neste relatório, fornecendo evidências de execução dinâmica
Vetor de Ataque e Engenharia Social: O malware disfarça-se como um hack para Minecraft denominado “Slinky”. Utiliza o ícone oficial do jogo para induzir a execução voluntária, explorando a confiança de usuários jovens no cenário de gaming.
Arquitetura e Evasão: O software opera em uma estrutura modular de dois estágios:
Loader (load.exe): Empacotado em Node.js (via pkg), possui 53.5 MB. O tamanho elevado e a presença de milhares de bibliotecas legítimas (V8, OpenSSL) visam “diluir” assinaturas maliciosas e burlar limites de upload de sandboxes.
Payload (chromelevator.exe): Um binário nativo em C++ de 1.4 MB, injetado diretamente na memória.
Capacidades de Exfiltração e Roubo: O malware é um infostealer altamente abrangente, visando 5 categorias de dados em 8 navegadores diferentes (Chrome, Edge, Brave, Opera GX, Firefox, etc.):
Sumário Executivo:
Este relatório documenta a análise estática de dois binários PE64 que compõem um infostealer modular identificado como LoFyStealer, com características do GrabBot/1.0 construído com o builder “Slinky Cracked” e distribuído como um suposto hack para o jogo Minecraft, explorando a confiança de um público predominantemente jovem.
A ameaça opera em dois estágios: um loader de 53.5 MB (load.exe) baseado em Node.js empacotado via pkg, e um payload nativo C++ de 1.4 MB (chromelevator.exe) que é descriptografado em memória e injetado diretamente nos processos de browser da vítima via syscalls diretas ao kernel do Windows.
A separação entre loader e payload, aliada ao uso de syscalls que contornam hooks de EDR, demonstra um nível de sofisticação acima da média para malware distribuído em contexto de gaming.
ANÁLISE DO LOADER:
O load.exe é uma aplicação JavaScript empacotada com pkg (ferramenta da Vercel que compila apps Node.js em executáveis standalone). A evidência definitiva está no caminho do PDB: C:\Users\runneradmin\AppData\Local\Temp\pkg.6709935bf6bb94abb8c538bc\node\out\Release\node.pdb. O “runneradmin” indica compilação via GitHub Actions (serviço de CI/CD do GitHub), o que significa que o build é automatizado.
O binário de 53.5 MB contém o runtime completo do Node.js (engine V8 do Google, libuv para I/O assíncrono, OpenSSL para criptografia, zlib para compressão, ICU para internacionalização, llhttp para parsing HTTP) além do código malicioso em JavaScript que é embarcado no binário e executado pelo runtime.
Essa técnica é cada vez mais comum em malware moderno pois: dificulta a análise estática (o código real está em JavaScript, não em código nativo), o tamanho grande (53 MB) dificulta uploads para sandboxes e serviços de análise, e o binário “parece” legítimo por conter milhares de funções de bibliotecas conhecidas.
O load.exe importa 12 DLLs com mais de 500 funções, um perfil muito mais amplo que o chromelevator.exe, refletindo a complexidade do runtime Node.js. Além das funções herdadas do Node.js, destacam-se as seguintes DLLs com relevância para a atividade maliciosa:
dbghelp.dll (13 funções): Inclui MiniDumpWriteDump, que permite criar dumps de processos em execução. Funções Sym* (SymSetOptions, SymSetSearchPathW, SymGetModuleBase64) são usadas para resolução de símbolos. Esta DLL dá ao loader a capacidade de extrair memória de processos em execução, potencialmente para capturar dados sensíveis que não são acessíveis via sistema de arquivos.
WS2_32.dll (43 funções): Biblioteca de sockets do Windows (Winsock2). As 43 funções importadas fornecem capacidade completa de rede de baixo nível, incluindo sockets TCP/UDP, DNS, e operações assíncronas. Usada pelo libuv (biblioteca de I/O do Node.js) para todas as operações de rede, incluindo HTTP, WebSocket e potencialmente comunicação direta com o C2.
As submissões públicas identificadas no ANY.RUN confirmaram a atividade de rede via WS2_32, registrando conexões TCP ao IP 24.152.36.241 na porta 8080 durante a execução dinâmica do loader, validando que estas funções são efetivamente utilizadas para comunicação C2 e não apenas herdadas passivamente do runtime Node.js.
CRYPT32.dll (7 funções): Inclui CertOpenStore, CertCloseStore, CertEnumCertificatesInStore, CertFindCertificateInStore e CertDuplicateCertificateContext. Estas funções dão acesso aos certificados digitais e chaves privadas armazenados no Windows Certificate Store. Podem ser usadas para roubar certificados de autenticação ou para manipular a confiança TLS.
IPHLPAPI.DLL (8 funções): Funções de informação de rede como GetBestRoute2, if_nametoindex e NotifyIpInterfaceChange. Usadas para reconhecimento de rede e detecção de mudanças de conectividade.
KERNEL32.dll (279 funções): Inclui as funções críticas para o ataque: CreateRemoteThread e OpenProcess (injeção de processo via API padrão), VirtualAlloc e VirtualProtect (manipulação de memória), CreateNamedPipeW e ConnectNamedPipe (IPC), LoadLibraryA/W/ExW (carregamento dinâmico), IsDebuggerPresent (anti-debug). A análise comportamental disponível nas execuções públicas do ANY.RUN corroborou a chamada a CreateProcessW em estado suspenso e a subsequente injeção via VirtualAllocEx/WriteProcessMemory no processo do browser, confirmando que o loader utiliza tanto a API padrão da KERNEL32 quanto as syscalls diretas resolvidas de ntdll.dll em runtime pelo payload.
Algorítmo de Criptografia:
O payload utiliza criptografia para dois propósitos distintos, ambos baseados no algoritmo SHA-256 via Windows CNG (bcrypt.dll).
1. Chave mestra (ASTER_KEY): A string “ASTER_KEY:” sugere que uma chave mestra é fornecida como parâmetro (possivelmente via –secret ou embutida no binário). “ASTER” pode ser um acrônimo interno do autor ou referência a um esquema de derivação customizado.
2. SHA-256 (CNG): BCryptOpenAlgorithmProvider é chamada com o identificador “SHA256” (confirmado via string UTF-16). A chave mestra é processada por BCryptHashData para gerar um digest de 32 bytes.
3. Descriptografia: O digest SHA-256 resultante é usado como chave para descriptografar o payload em memória. O algoritmo de cifra simétrica específico não é identificável apenas por análise estática, pode ser AES-256 (usando os 32 bytes como chave), XOR com o hash, ou um algoritmo customizado. A string “[+] Payload decrypted (<size> bytes)” confirma o sucesso da operação.
O campo “sig” no JSON enviado ao C2 contém um hash SHA-256 que funciona como assinatura de integridade. O processo provável: os dados do ZIP (antes da codificação Base64) são hashados via BCryptHashData com SHA-256, e o digest hexadecimal resultante é incluído como “sig” no JSON. O C2 pode então verificar se os dados foram transmitidos sem corrupção.
TLS/SSL: Conexões seguras via SSL_CTX_*, SSL_connect, SSL_read, SSL_write. Pode ser usado para comunicação C2 criptografada.
Geração de números aleatórios: RAND_bytes, BCryptGenRandom (importado de bcrypt.dll) para geração de nonces e chaves de sessão.
Abaixo, segue comparação entre Loader e Payload final.
| Aspecto | chromelevator.exe | load.exe |
| Papel | Payload / worker | Loader / orquestrador |
| Linguagem | C++ nativo (MSVC) | JavaScript (Node.js via pkg) |
| Tamanho | 1.4 MB (cirúrgico) | 53.5 MB (runtime completo) |
| Subsystem | GUI (sem janela) | Console |
| Compilação | 21/04/2026 (mais recente) | 25/03/2026 (mais antigo) |
| DLLs importadas | 5 DLLs, 127 funções | 12 DLLs, 500+ funções |
| Onde roda | Injetado no processo do browser | Processo independente |
| Evasão | Syscalls diretas, sem PDB/metadata | Camuflado em binário Node.js |
| Metadados | Zero (stripped) | “Slinky Cracked” exposto |
| Comunicação C2 | WinHTTP (11 funcs) | WS2_32 + OpenSSL/TLS |
| Criptografia | bcrypt (SHA-256 CNG) | OpenSSL completo + bcrypt |
| Injeção | Syscalls diretas (ntdll runtime) | API padrão (CreateRemoteThread) |
| Persistência | Nenhuma (vive em memória) | Arquivo em disco |
ANÁLISE DO PAYLOAD – STAGE 2
O binário possui as seguintes proteções habilitadas no compilador: HIGH_ENTROPY_VA (suporte a ASLR de 64-bit com alta entropia), DYNAMIC_BASE (ASLR, randomização do endereço base), NX_COMPAT (DEP, prevenção de execução de dados) e TERMINAL_SERVER_AWARE. Notavelmente, GUARD_CF (Control Flow Guard) está desabilitado, o que facilita a exploração de controle de fluxo.
O binário possui 6 seções. A seção .text ocupa 98.4% do arquivo total com entropia de 7.84, extremamente alta. Essa entropia indica compilação com LTCG (Link-Time Code Generation) combinada com possíveis dados criptografados inline, como o payload de injeção e chaves de descriptografia. O Detect It Easy (DiE) classificou como “[Heur] Compressed or packed data”, porém não há packer clássico, os ratios Raw/Virtual são todos próximos de 1.0.
O chromelevator.exe importa apenas 5 DLLs com 127 funções, um perfil extremamente enxuto e cirúrgico. Cada DLL tem um propósito claro no ciclo de ataque. Além das DLLs importadas estaticamente, o binário carrega ntdll.dll e mscoree.dll em runtime via LoadLibraryExW/GetProcAddress para resolver syscalls diretas e verificar o ambiente .NET.
Imports – Análise funcional:
A KERNEL32.dll fornece as funções base utilizadas pelo malware, cobrindo múltiplas etapas da operação. Ela é usada para criação e controle de processos, incluindo iniciar o browser suspenso para injeção, encerrar processos existentes e gerenciar temporização.
Também viabiliza a comunicação interna (IPC) via Named Pipes entre o payload e o processo principal. No acesso a dados, permite a manipulação de arquivos, lendo bancos de dados de navegadores (cookies, credenciais) e organizando diretórios temporários. Para execução do código injetado, utiliza controle de memória (VirtualProtect), enquanto funções mais sensíveis de alocação são resolvidas dinamicamente via syscalls.
O malware emprega resolução dinâmica de APIs (LoadLibrary/GetProcAddress) para evitar exposição na IAT, dificultando análise estática. Inclui ainda mecanismos de anti-análise, como detecção de debugger e verificações de tempo contra sandbox.
Por fim, realiza reconhecimento do sistema (hostname, horário, variáveis de ambiente) e conversão de encoding (UTF-16 ↔ UTF-8) para estruturar e exfiltrar os dados ao C2.
A WinHTTP é a biblioteca de HTTP cliente do Windows, usada aqui para toda a comunicação com o servidor C2. As 11 funções importadas formam o ciclo completo de uma requisição HTTP: WinHttpOpen inicializa a sessão HTTP com o User-Agent “GrabBot/1.0”. WinHttpConnect estabelece a conexão com o IP do C2 (24.152.36.241). WinHttpOpenRequest cria a requisição POST para o endpoint /upload. WinHttpAddRequestHeaders adiciona “Content-Type: application/json”. WinHttpSetOption configura opções como timeout e flags de segurança. WinHttpSendRequest envia a requisição com o body JSON contendo os dados roubados em Base64. WinHttpReceiveResponse aguarda a resposta do servidor. WinHttpQueryHeaders e WinHttpQueryDataAvailable verificam o status HTTP e tamanho da resposta. WinHttpReadData lê a resposta. WinHttpCloseHandle libera os recursos.
A bcrypt.dll é a API de criptografia moderna do Windows (CNG, Cryptography Next Generation). As 6 funções formam um pipeline completo de hashing:
BCryptOpenAlgorithmProvider abre o provedor do algoritmo SHA-256 (identificado via string “SHA256” em UTF-16). BCryptCreateHash cria um objeto de hash. BCryptHashData alimenta os dados a serem hashados. BCryptFinishHash finaliza e obtém o digest. BCryptDestroyHash e BCryptCloseAlgorithmProvider liberam os recursos.
Este pipeline é usado para dois propósitos: (1) derivação de chaves de descriptografia em runtime (“Deriving runtime decryption keys…”) usando SHA-256 para transformar a chave mestra (ASTER_KEY) em chaves de sessão, e (2) geração do campo “sig” (assinatura) no JSON de exfiltração, para que o C2 possa validar a integridade dos dados recebidos.
RegOpenKeyExW abre as chaves de registro para localizar os browsers instalados. O malware consulta dois conjuntos de caminhos: (1) HKLM\SOFTWARE\Clients\StartMenuInternet\{browser}\shell\open\command para encontrar o executável do browser, e (2) HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{browser} para obter o InstallLocation e verificar a presença do browser. Ambos os caminhos são consultados tanto na raiz de 64-bit quanto em WOW6432Node (32-bit). RegQueryValueExW lê os valores das chaves. RegCloseKey fecha os handles.
GetFileVersionInfoSizeW, GetFileVersionInfoW e VerQueryValueW são usadas para ler a versão dos executáveis dos browsers encontrados. Isso permite ao malware verificar a compatibilidade e selecionar os métodos de extração corretos para cada versão do browser.
O ntdll.dll não aparece na IAT (Import Address Table) do binário, é carregado em runtime via LoadLibraryExW e as funções são resolvidas via GetProcAddress. Isso é uma técnica deliberada de evasão para contornar hooks de EDR/antivírus que monitoram funções da IAT.
As funções resolvidas de ntdll.dll são syscalls de baixo nível (nível do kernel) que executam as operações de injeção de processo sem passar pelas funções wrapper da KERNEL32.dll.
Striungs e funções:
A extração de strings (FLOSS + pefile) revelou 2.925 strings ASCII e 531 strings UTF-16LE. A categorização das strings mais relevantes expõe completamente a lógica do malware:
Comunicação C2: O servidor de comando e controle está hardcoded no binário em UTF-16LE: 24.152.36.241. Os endpoints são /upload (POST, para envio de dados roubados) e /time (GET, provável keepalive ou sincronização de relógio). O User-Agent usado é “GrabBot/1.0” e o Content-Type é “application/json”.
Browsers Alvo e Detecção via Registro: O malware busca 8 browsers através de consultas ao registro do Windows. Para cada browser, são consultadas as chaves StartMenuInternet (para o executável), Uninstall (para o InstallLocation) e App Paths, tanto em HKLM\SOFTWARE quanto em HKLM\SOFTWARE\WOW6432Node:
| Browser | Executável | Pipe Pattern | Chave Uninstall | StartMenuInternet |
| Chrome | chrome.exe | chrome.sync.%u.%u.%04X | Google Chrome | Google Chrome |
| Chrome Beta | chrome.exe | chrome.nacl.%u_%04X | Google Chrome Beta | Google Chrome Beta |
| Edge | msedge.exe | msedge.sync.%u.%u | Microsoft Edge | Microsoft Edge |
| Brave | brave.exe | (via Chromium) | BraveSoftware Brave-Browser | Brave |
| Avast | AvastBrowser.exe | (via Chromium) | (não listado) | (não listado) |
| Opera | opera.exe | opera.sync.%u.%u.%04X | Opera Stable | Opera |
| Opera GX | opera.exe | opera.ipc.%u_%04X | Opera GX Stable | Opera GX |
| Firefox | xfirefox.exe | firefox.%u.%u | Mozilla Firefox | Firefox |
Dados Roubados, Protocolo IPC: Os dados extraídos dos browsers são transmitidos via named pipes usando um protocolo de texto simples com prefixos. Cada tipo de dado é precedido por um marcador em maiúsculas seguido de dois-pontos:
COOKIES: <dados codificados>
Injeção de Processo, Sequência Completa: As mensagens de log do binário revelam a sequência exata da injeção de processo, que segue o padrão de process hollowing com syscalls diretas
Compressão e Exfiltração: Após a coleta, os dados são comprimidos usando PowerShell em modo oculto:
powershell.exe -NoProfile -NonInteractive -WindowStyle Hidden
-Command “Compress-Archive -Path ‘…’ -DestinationPath ‘…'”
Os arquivos gerados seguem dois padrões de nomenclatura: .grab_<nome>.zip e output_YYYYMMDD_HHMMSS.zip. Após compressão, o ZIP é codificado em Base64 e enviado ao C2 como parte de um payload JSON.
Payload JSON de Exfiltração
A reconstrução dos fragmentos de strings revela a estrutura completa do JSON enviado ao C2:
Flags de Linha de Comando:
| Flag | Propósito |
| –verbose | Ativa modo verboso com todas as mensagens de log |
| –fingerprint | Coleta fingerprint do host (FINGERPRINT_TRUE/FINGERPRINT_FALSE) |
| –kill | Mata processos de browser antes da injeção |
| –secret | Chave de autenticação enviada ao C2 no campo “secret” |
| –output-path | Define caminho alternativo para os ZIPs gerados |
| –help | Exibe ajuda/uso |
Infraestrutura C2, Painel Web LofyStealer
A investigação do endereço IP do C2 (24.152.36.241) revelou a existência de um painel web completo de gerenciamento de vítimas, acessível na porta 8080. A plataforma se identifica como “LofyStealer, Advanced C2 Platform V2.0” e oferece uma interface gráfica para operadores gerenciarem campanhas de roubo de dados em tempo real.
Após autenticação, o operador é redirecionado para um dashboard com visão geral da campanha:
o subtítulo “Gerencie sua conta e monitore vítimas”, o painel “Vítimas Recentes” com status “Nenhuma vítima ainda, Aguardando conexões…”, e as informações da conta no card lateral (Usuário, Tipo: Free, Total vítimas: 0, Online agora: 0).
A seção “Ações Rápidas” apresenta quatro botões: Painel (monitoramento de vítimas), Meu Perfil (configurações), Premium (upgrade de plano) e Builder (gerador de executável). A existência de um botão “Refresh” no painel de vítimas indica monitoramento em tempo real das máquinas comprometidas.
Com base na análise das screenshots e no comportamento observado, a arquitetura do painel C2 pode ser descrita:
Frontend: Aplicação web SPA (Single Page Application) servida como bundle JavaScript. A interface utiliza tema escuro com paleta de roxo/dourado, componentes modernos de UI com animações de partículas no background, e design responsivo.
Backend: Node.js servindo na porta 8080 do IP 24.152.36.241. O mesmo servidor que recebe os dados exfiltrados nos endpoints /upload (POST) e /time (GET) também serve o painel web de gerenciamento.
Modelo de negócio: MaaS (Malware-as-a-Service) com dois tiers, Free (acesso limitado, sem builder nem painel de vítimas) e Premium (acesso completo via chave de ativação). Multi-operador, com cada operador possuindo sua própria conta e secret key vinculada aos executáveis gerados.
| Endpoint | Método | Função |
| / (porta 8080) | GET | Landing page — LofyStealer V2.0 |
| /?role=client | GET | Dashboard do operador (autenticado) |
| /upload | POST | Recebimento de dados exfiltrados (JSON/Base64) |
| /time | GET | Keepalive / sincronização de relógio |
IOC’s
Hashes de arquivos
| Arquivo | Algoritmo | Hash |
| chromelevator.exe | MD5 | d21a5d08b4614005c8fcd9d0068f0190 |
| SHA1 | 9b1264eb4ff5ee8f00b8b80341fb6917dc3d3148 | |
| SHA256 | 293006cec43c663ccff331795d662c3b73b4d7af5f8584e2899e286c672c9881 | |
| load.exe | MD5 | fb203c0ac030a97281960d7c28d86ebf |
| SHA1 | f9fe23f24d45eae418c60819c523a83ddba4ca50 | |
| SHA256 | 45d4040e76a0d357dd6e236e185aba2eb82420d78640bfd1f3dede32b33931f7 |
Artefato de rede:
| Indicador | Valor |
| IP do C2 | 24.152.36.241 |
| Endpoint de upload | /upload (HTTP POST) |
| Endpoint de tempo | /time (HTTP GET) |
| User-Agent | GrabBot/1.0 |
| Content-Type | application/json |
| Protocolo fallback | WebSocket |
| Painel C2 | http://24.152.36.241:8080 (LofyStealer V2.0) |
| Nome da plataforma | LofyStealer — Advanced C2 Platform V2.0 |
Strings de detecção
| String | Contexto |
| [chromelevator] | Tag de identificação do payload |
| __DLL_PIPE_COMPLETION_SIGNAL__ | Sinal IPC de conclusão |
| GrabBot/1.0 | User-Agent HTTP do C2 |
| Slinky Cracked | Nome do builder (VersionInfo do loader) |
| ASTER_KEY: | Prefixo de chave de criptografia |
| FINGERPRINT_TRUE / FINGERPRINT_FALSE | Flags de fingerprinting do host |
| Deriving runtime decryption keys… | Log de descriptografia do payload |
| LofyStealer | Nome da plataforma C2 (landing page) |
MITRE ATT&CK
| Técnica | Nome | Evidência | Binário |
| T1055.012 | Process Injection: Process Hollowing | Criação de processo suspenso + injeção de payload | chromelevator |
| T1055.003 | Process Injection: Thread Execution Hijacking | Criação de thread remota via syscall direta | chromelevator |
| T1106 | Native API | Uso de syscalls diretas de ntdll.dll em runtime | chromelevator |
| T1539 | Steal Web Session Cookie | Extração de cookies de 8 browsers | chromelevator |
| T1555.003 | Credentials from Web Browsers | Extração de senhas armazenadas | chromelevator |
| T1012 | Query Registry | Consulta ao registro para localizar browsers | chromelevator |
| T1082 | System Information Discovery | Coleta de hostname e fingerprint do host | chromelevator |
| T1057 | Process Discovery | Detecção de processos de browser em execução | load.exe |
| T1059.001 | Command and Scripting: PowerShell | Compressão via Compress-Archive oculto | chromelevator |
| T1560.001 | Archive Collected Data: Archive via Utility | Compressão ZIP dos dados roubados | chromelevator |
| T1132.001 | Data Encoding: Standard Encoding | Codificação Base64 do ZIP para exfiltração | chromelevator |
| T1041 | Exfiltration Over C2 Channel | Envio dos dados via HTTP POST ao C2 | ambos |
| T1071.001 | Application Layer Protocol: Web Protocols | Comunicação C2 via HTTP/JSON | ambos |
| T1562.001 | Impair Defenses: Disable or Modify Tools | Terminação de processos de browser (–kill) | chromelevator |
| T1027 | Obfuscated Files or Information | Payload criptografado, descriptografado em runtime | chromelevator |
| T1497.003 | Virtualization/Sandbox Evasion: Time Based | Timing checks via GetTickCount/QPC | chromelevator |
Conclusão:
Contribuição do ANY.RUN: A plataforma ANY.RUN foi essencial nesta investigação, permitindo identificar o artefato em submissões públicas durante threat hunting e confirmar que a campanha está ativa em ambiente real. Os dados de execução dinâmica do sandbox validaram as hipóteses da análise estática, conexões ao C2, injeção de processo e exfiltração via PowerShell, consolidando a plataforma como recurso indispensável para equipes de threat intelligence.
A análise estática dos binários chromelevator.exe e load.exe confirma que se trata de um infostealer sofisticado e modular, operando sob a identidade “GrabBot/1.0” e construído com o builder “Slinky Cracked”. Os dois componentes demonstram uma divisão clara de responsabilidades que reflete maturidade no design:
Modularidade: O loader (Node.js/JavaScript) é responsável pela orquestração, enquanto o payload (C++ nativo) realiza as operações sensíveis de extração de dados. Essa separação permite que os autores atualizem o payload independentemente do loader, como evidenciado pela diferença de 27 dias nas datas de compilação.
Evasão avançada: O uso de syscalls diretas (ntdll.dll resolvido em runtime) para injeção de processo é uma técnica que contorna hooks de EDR/antivírus que monitoram apenas as funções de alto nível da KERNEL32.dll. O payload não possui nenhum metadado identificável (PDB, VersionInfo, resources) e opera exclusivamente em memória após injeção.
Camuflagem via pkg: O uso de Node.js empacotado via pkg para o loader é uma técnica crescente no cenário de ameaças. O binário de 53 MB dificulta análise em sandbox, e as ~3000 exports legítimas do Node.js/V8/OpenSSL diluem os indicadores maliciosos. O build automatizado via GitHub Actions indica uma cadeia de produção profissionalizada.
Exfiltração resiliente: O mecanismo de exfiltração com fallback WebSocket, assinatura SHA-256 para validação de integridade, e autenticação via “secret” demonstra preocupação com a confiabilidade e segurança da comunicação C2.
Amplitude do roubo: O malware visa 8 browsers diferentes e extrai 5 categorias de dados sensíveis (cookies, senhas, tokens, cartões, IBANs), cobrindo tanto credenciais de acesso quanto dados financeiros diretos.
A análise dinâmica (sandboxing, debugging, monitoramento de rede) seria necessária para confirmar comportamentos como: o algoritmo exato de criptografia simétrica usado na descriptografia do payload, a estrutura completa do código JavaScript do loader, possíveis mecanismos de persistência não identificados por análise estática, e comportamento específico do fallback WebSocket.
