Exploração rápida de CVE-2026-39987 em Marimo e campanha massiva de Redis para minar XMRig

Duas investigações recentes — uma de Sysdig e outra de Hunt.io — sublinham que a separação entre descobrir uma vulnerabilidade e explorá-la diminuiu drasticamente: não só as ferramentas baseadas em inteligência artificial aceleram ataques, mas os operadores humanos altamente duchos podem mover-se para o mesmo ritmo e com grande sigilo. Sysdig documenta uma intrusão onde, após explorar uma vulnerabilidade em Marimo (reportada como CVE-2026-39987), um atacante conseguiu desde uma conexão WebSocket uma cadeia de pivotes que lhe permitiu recuperar uma chave privada da AWS Secrets Manager e autenticar-se por SSH a um bastão em questão de segundos. Ao mesmo tempo, Hunt.io descreve uma campanha massiva de cryptominería que comprometeu milhares de instâncias Redis mediante replicação maliciosa e outras técnicas de persistência.

Atos confirmados: Sysdig relatou a exploração ativa de CVE‐2026‐39987 em Marimo, com um ator que conseguiu uma shell interativa e, usando credenciais obtidas na máquina comprometida, chamou a AWS Secrets Manager para recuperar uma chave privada e se conectar por SSH a um bastão. De acordo com o registo que Sysdig publicou, o operador demorou apenas oito segundos para a violação inicial até à autenticação de SSH no bastião. Hunt.io confirmou a compromissão de 3.562 servidores Redis expostos na Internet, usando principalmente a replicação (comando SLAVEOF/REPLICAOF) para injetar payloads que exibem XMRig.

Informação estimada ou ainda incerta: Não há atribuição pública e confiável sobre qual grupo está por trás das intrusões; também não está completamente claro o alcance final das possíveis exfiltrações realizadas após o acesso ao bastão nem se houve acesso posterior a contas AWS adicionais. Sysdig afirmou que o operador não usou agentes de IA e que as ferramentas foram escritas “a mão” durante a sessão; essa afirmação baseia-se em telemetria e análise de táticas, técnicas e procedimentos, mas a possibilidade de o atacante ter usado ferramentas automatizadas fora da sessão observada não pode ser descartada.

Tecnicamente, a cadeia de ataque descrita por Sysdig segue este padrão: exploração pré-autenticada da funcionalidade de terminal WebSocket exposta por Marimo para obter execução remota; busca e extração de credenciais locais (arquivos de configuração ou variáveis de ambiente) que permitiram chamar a AWS Secrets Manager e recuperar uma chave privada; escrita dessa chave em disco e autenticação por SSH ao bastão. O vetor chave aqui é que uma aplicação com um endpoint interativo WebSocket expunha uma superfície que, uma vez vulnerada, dava acesso a credenciais no próprio host. No caso de Redis, a técnica que funcionou à escala foi usar o SLAVEOF para induzir o servidor alvo a replicar dados controlados pelo atacante; esse conteúdo pode terminar no arquivo AOF e, com condições suficientes, injetar chaves SSH ou outros artefatos persistentes. Para detalhes sobre o comando de replicação do Redis, consulte a documentação oficial em redis.io.

Quem é afectado: Organizações que executam o Marimo sem adesivos ou configurações que expõem o endpoint de terminal WebSocket na Internet; contas e sistemas na AWS que armazenam segredos acessíveis a partir de instâncias vulneradas; servidores Redis expostos no porto 6379 sem autenticação ou com ACLs fracos; sites WordPress desatualizados que podem ser identificados por barridos automatizados. A variedade de vítimas — desde servidores antigos até kernels recentes, segundo Hunt.io — mostra que o vetor não depende tanto de versões específicas como de configurações inseguras ou serviços expostos desnecessariamente.

As consequências práticas são tangíveis: acesso atestado a bastiones SSH (bloqueio de controle crítico da infraestrutura), roubo de chaves privadas desde Secrets Manager (risco de movimento lateral e escalada), implantação de mineiros XMRig que consomem recursos e elevam custos operacionais, e potencial implantação de portas traseiras persistentes. A nível organizacional, estas intrusões podem traduzir-se em interrupções de serviço, custos por abuso de nuvem e risco de serem utilizados acessos comprometidos para ações mais prejudiciais (exfiltração, destruição de dados, ransomware).

O que deve fazer o leitor (medidas concretas e priorizadas):

1) Parchee e reduza a superfície. Atualice Marimo e qualquer outro software com endpoints interativos; aplique adesivos assim que disponíveis e bloquee o acesso externo a endpoints de administração. Se você não puder corrigir imediatamente, restrinja o acesso através de listas de controle de acesso e firewalls.

2) Segmentar e endurecer o acesso a bastiones. Limite os IPs que podem aceder ao bastão, obrigue a autenticação multifator e considere usar mecanismos de sessão gerenciados (por exemplo, a AWS Systems Manager Session Manager) em vez de abrir SSH direto ao público. Revise e rote chaves privadas potencialmente comprometidas.

3) Minimizar privilégios em Secrets Manager e rotar segredos. Aplicar políticas IAM com o princípio de menor privilégio: uma instância não deve poder ler segredos que não necessita. Habilite CloudTrail e alertas sobre chamadas GetSecretValue invulgares na AWS; audite acessos e rote segredos se houver indícios de exposição. O guia da AWS sobre Secrets Manager pode ser consultado em docs.aws.amazon.com.

4) Proteger Redis e serviços de base de dados expostos. Não exponha Redis à Internet pública; active autenticação, use ACLs e bind ao localhost ou a uma rede privada. Bloqueie o porto 6379 em perímetros públicos e monitorize conexões de replicação entrantes. Para ataques baseados em APD, tenha políticas de integridade e não permita que processos externos descrevam arquivos críticos.

5) Detecção e resposta: instrumente detecção para padrões concretos observados: conexões WebSocket inesperadas a endpoints de terminal, chamadas a Secrets Manager a partir de instâncias que não deveriam ser necessárias, criação de arquivos de chave privada em discos efêmeros, picos de comandos interativos e processos que instalam mineiros como XMRig (informação sobre XMRig em XMRig xmrig.com). Defina alertas e playbooks de resposta rápida que incluam isolamento da máquina, captura de volcado e rotação de credenciais.

6) Rever e endurecer as implantaçãos do WordPress. Desactive o XML-RPC se não for usado, mantenha os plugins e o núcleo por dia, e limite a informação exposta que possa facilitar a varredura automática.

Em conclusão, os casos descritos mostram duas lições: primeiro, a velocidade de exploração pode vir tanto de automação como de pericia humana; segundo, a vulnerabilidade mais explorada nem sempre é uma falha técnica pontual, mas a combinação de software vulnerável e configurações que expõem credenciais e serviços chave. Prevenir significa reduzir a exposição, aplicar o princípio de menor privilégio e estabelecer detecção precoce específica para cadeias de pivot que impliquem acessos a secrets e a bastiones. Para leituras e seguimento dos relatos originais, você pode revisar os recursos nas páginas de pesquisa de Sysdig e Hunt.io: sysdig.com/blog e hunt.io/blog.