O infostealer Acreed ocupa o topo do mercado criminal de roubo de identidades depois da queda do LummaC2, e o produto à venda não é a senha isolada: são perfis completos de navegador, com sessões autenticadas de SaaS e contas de single sign-on que abrem o ambiente corporativo inteiro. Equipes que tratam vazamento de credencial como simples troca de senha perdem a janela de resposta, porque o cookie roubado continua válido depois da troca. A ação prioritária é monitorar o domínio da empresa em mercados de stealer logs e tratar qualquer ocorrência como incidente de endpoint, com revogação de sessões antes da rotação.
O vaivém do mercado criminal
A trajetória do Acreed resume o problema central do combate a infostealers: derrubar um serviço não elimina a demanda. A Bitsight acompanhou o malware nos mercados de língua russa e registrou a curva completa: sem atividade relevante em março de 2025, o Acreed saltou de 50 logs de credenciais em abril para mais de 118 mil em junho, passando por 864 em maio — semanas depois da operação que desmantelou a infraestrutura do LummaC2 e apreendeu mais de 2.300 domínios maliciosos. O LummaC2 havia sido responsável por cerca de 394.000 infecções em dois meses e cerca de 10 milhões no total antes da interrupção, volume que deixou um vácuo imediato de oferta.
Para a leitura defensiva, o dado relevante não é o nome do malware da vez, e sim a velocidade de reposição: a capacidade de coleta criminal permanece de pé, só muda a marca no rótulo. Vigiar famílias específicas tem valor tático curto, porque o catálogo se renova em semanas; o indicador durável é a presença do seu domínio em logs à venda. Quem só acompanha boletins por nome de malware percebe a troca de fornecedor, mas não percebe que a própria organização já entrou na prateleira.
Sessões valem mais que senhas
O que torna o Acreed atraente para compradores é o alvo. Na análise de logs com amostras do malware, 61% das credenciais estão ligadas a plataformas SaaS e 77% incluem credenciais de single sign-on, com maior impacto nos setores de serviços profissionais, científicos e técnicos (30%) e no setor de informação (28%). São contas cujo comprometimento dá acesso a e-mail corporativo, armazenamento, repositórios e consoles de nuvem de uma só vez.
O mecanismo é o sequestro de sessão: o malware copia cookies e tokens de plataformas como Microsoft 365, Google, AWS e Salesforce e os reutiliza a partir da máquina do atacante, contornando o segundo fator que a vítima já cumpriu na autenticação legítima. Nesse modelo, o MFA não falha — ele é atravessado, porque o invasor entra depois da verificação, com o cookie válido na mão. Por isso a resposta a um hit de stealer log começa pela revogação de sessões ativas e só depois passa à rotação de senha e à investigação do endpoint.
Infraestrutura difícil de derrubar
A persistência também aparece na engenharia do malware. A Intrinsec analisou 18 amostras de Acreed e descreveu um mecanismo de recuperação de servidores de comando que usa a testnet da BNB Smartchain e a plataforma Steam como dead drop resolvers: o malware consulta um registro público, obtém o endereço do servidor e só então exfiltra. O desenho elimina o ponto fixo que uma apreensão de domínio costuma atingir, padrão de resiliência parecido com o da botnet Cling, que disfarça seu comando em tráfego legítimo.
Entre as técnicas de evasão documentadas estão a exfiltração em JSON e o DLL side-loading. Os logs produzidos são minimalistas e omitem o vetor de infecção, o que dificulta descobrir como a máquina foi comprometida — o atacante reduz a própria pegada para não entregar de graça o método de entrada. Para detecção, isso significa priorizar comportamento e tráfego anômalo de saída, não só assinaturas de arquivo, a mesma lição deixada pela análise técnica do Warden Stealer: o artefato muda, o padrão de coleta e exfiltração deixa rastro.
O que observar na triagem
| Sinal | O que indica | Ação imediata |
|---|---|---|
| Domínio corporativo em stealer log | Pelo menos um endpoint infectado | Revogar sessões do usuário e isolar a máquina |
| Cookie ou token de SaaS no log | Acesso sob demanda do atacante | Invalidar tokens e revisar auditoria do serviço |
| Exfiltração em JSON para IP desconhecido | Padrão compatível com Acreed e variantes | Bloquear o IP e coletar artefatos para análise |
| DLL assinada carregando binário estranho | Suspeita de side-loading | Quarentena, caçar persistência e outros hosts |
Procedimento ao confirmar um hit
- Confirme o alcance: quais contas, cookies e tokens aparecem no log e de qual máquina partiram.
- Revogue todas as sessões ativas das contas afetadas antes de trocar senhas; a troca sozinha mantém o atacante conectado.
- Trate o dispositivo como infectado: colete evidência, limpe ou substitua a máquina e investigue o vetor provável, como anúncio de software crackeado, falso CAPTCHA ou tutorial malicioso em plataformas de vídeo.
- Revise a auditoria dos serviços atingidos procurando acessos de IPs, geolocalizações ou user-agents incomuns desde a data estimada do log.
- Estenda a busca no tempo: credenciais de um domínio raramente aparecem em um único log, então cubra uma janela de pelo menos 90 dias antes de fechar o caso.
Prioridades de defesa
P1 — colocar o domínio da empresa em monitoramento contínuo de credenciais expostas e manter um runbook cujo primeiro passo seja revogação de sessão, não troca de senha. Incluir no runbook os caminhos de revogação por plataforma, porque procurar onde se revoga um token do Google Workspace durante o incidente custa minutos que o atacante usa.
P2 — encurtar a vida útil das sessões de SSO, exigir dispositivos gerenciados para acessos corporativos e bloquear downloads de instaladores a partir de anúncios e resultados de busca não verificados, vetor recorrente dessas campanhas. Complementar com inventário de ferramentas de IA e SaaS em uso extraoficial: contas que o TI não conhece não podem ser revogadas, e o monitoramento só enxerga o que está no radar.