Um ator de espionagem suspeito de vínculo com a China, rastreado como ARMORY CASTLE e antes conhecido como UNC5221, invadiu appliances do BeyondTrust Remote Support depois de explorar a falha como zero-day no fim de agosto de 2026, semanas antes da divulgação pública da correção. O alvo típico é a empresa que mantém instância auto-hospedada do Remote Support, ferramenta que concentra senhas, chaves de API e acesso remoto privilegiado a praticamente toda a rede interna. A ação prioritária é aplicar o patch do advisory BT26-05 em toda instalação até a versão 26.2.3, tratar as credenciais guardadas no appliance como comprometidas e caçar os sinais descritos abaixo.
O que aconteceu
O caso veio à luz em um trabalho de resposta a incidente conduzido pela Mandiant, integrada ao Google Threat Intelligence, em coordenação com o fabricante. A falha CVE-2026-102764 nasce de validação inadequada de origem em um componente interno de mensagens do Remote Support: sob as condições certas, um atacante remoto executa operações de arquivo no appliance sem autenticação prévia. A vulnerabilidade recebeu nota CVSSv4 9.3 e foi divulgada em 15 de outubro de 2026 no advisory BT26-05, com severidade crítica. Todas as versões até a 26.2.3 são afetadas. Clientes SaaS receberam o patch automaticamente em 9 de outubro; instalações auto-hospedadas precisam aplicá-lo manualmente pela interface do appliance, e quem roda versão anterior a 24.3.1 precisa primeiro atualizar o produto.
A janela de exposição merece atenção: a exploração registrada pela Mandiant ocorreu no fim de agosto, o patch chegou ao SaaS no início de outubro e o detalhe técnico virou público duas semanas depois. A Mandiant avalia que a exploração pode se ampliar de forma oportunista agora que o mecanismo é conhecido, padrão já observado neste mesmo ator em divulgações anteriores. Ou seja, o risco não se limita à vítima inicial — qualquer instância sem patch é candidata a alvo.
Da falha ao webshell
A entrada começou com requisições POST para um caminho PHP incomum, seguidas cerca de 11 minutos depois pela criação do arquivo mangoapi.php no diretório público da aplicação. O SAWFLY, como a Mandiant batizou o webshell, é enxuto e ofuscado: responde apenas a requisições que carregam um parâmetro específico, devolve erro 404 para qualquer outra visita — o que engana scanners e crawlers automatizados — e cifra o tráfego de comando e controle com RC4 de chave de 256 bits sobre uma camada de transporte Base32 personalizada. O resultado é um canal bidirecional discreto rodando dentro do próprio appliance, difícil de separar do tráfego legítimo da aplicação sem inspeção de caminhos no proxy reverso.
Root, cofre e credenciais
Depois de abrir caminho, o grupo instalou o webshell SAWFLY e o tunelador BARECLAW e partiu para a escalada de privilégio. O webshell rodava como conta de serviço sem privilégios; para virar root, o ator copiou o shell do sistema para /usr/bin/dbus-authd, mudou o dono do arquivo para root e ligou o bit SUID, criando uma porta dos fundos que executa qualquer comando com privilégio máximo. Em seguida, mirou o cofre nativo do appliance com o utilitário proprietário bt-secrets, testando várias variações de sintaxe até despejar senhas, chaves de API e credenciais de endpoints. Para apagar rastros, removeu o registro de auditoria do próprio utilitário e, ao longo de toda a intrusão, eliminou logs de sistema, de servidor web e de aplicação — a antiforense foi rotina, não exceção.
Persistência e movimento lateral
O passo mais sofisticado foi sobreviver a reinicialização. O ator criou o diretório post_boot.d, reservado a scripts executados automaticamente no boot, e nele colocou um script que injeta a linha NOPASSWD no template de sudoers da configuração e força o backend a reconstruir o /etc/sudoers ativo. Como a alteração vive no template, ela resiste a reboot e a reset de configuração — justamente as medidas que uma equipe usaria para tentar limpar o appliance comprometido.
Com o controle do host garantido, o grupo entrou no portal administrativo com credencial de Administrator roubada e mudou permissões de Jump Items e de equipes de No Access para Administrator, garantindo autorização permanente para abrir sessões remotas nos sistemas internos listados no appliance. O BARECLAW, um tunelador escrito em C que oferece proxy SOCKS5 sobre WebSocket, completou o quadro ao permitir pivô pela rede interna a partir do próprio dispositivo invadido. A espionagem interna incluiu uso do serviço nativo de transferência de arquivos para exfiltrar inventários de software direto do ambiente das vítimas.
Por que appliances viraram alvo
A escolha do alvo não é acidental. Uma plataforma de acesso remoto privilegiado concentra, por definição, o cofre de senhas da organização, chaves de API e a lista de sistemas alcançáveis — comprometer um único host rende ao atacante credenciais e caminhos para toda a infraestrutura. O ator demonstrou conhecimento profundo das entranhas do produto, abusando de utilitários de linha de comando proprietários, templates de inicialização e o roteamento do proxy reverso local, técnica que dificulta detecção baseada apenas em assinaturas de malware. O perfil casa com a leitura de que malware de qualidade aposta na evasão e na persistência silenciosa, como mostramos na análise sobre evasão e persistência.
Sinais para caçar agora
Quem opera Remote Support auto-hospedado deve tratar o appliance como suspeito até concluir patch, caça e rotação de credenciais. Um detalhe operacional: os logs onde a exploração aparece ficam em partições LUKS que abrigam o diretório /home — sem montar esse acesso, a revisão fica incompleta. A tabela reúne os sinais de maior valor defendidos pela Mandiant:
| Sinal | Onde procurar | Leitura |
|---|---|---|
| Evento user_changed que eleva papel de Jump Item ou de equipe | syslog do appliance | Escalação de permissão sem chamado associado |
| Caminhos.php desconhecidos, como mangoapi.php | Proxy reverso ou WAF | Webshell no diretório público da aplicação |
| Upgrade de WebSocket de origem fora da equipe de suporte | Perímetro do appliance | Possível tunelador SOCKS5 em operação |
| Login administrativo de IP residencial ou VPN comercial, fora do horário comercial | Relatórios de sessão e auditoria | Credencial privilegiada roubada em uso |
| Lacuna no encaminhamento de syslog delimitada por uma única sessão | SIEM | Indício forte de remoção de logs |
Alertas sobre criação de contas, contas de API e provedores de segurança sem ticket de mudança completam o conjunto. No perímetro, vale correlacionar esses eventos com detecção de rede calibrada para reduzir ruído, no espírito do guia de ajuste de detecção com Suricata.
Plano de resposta priorizado
P1 — execute em até 24 horas:
- Aplicar o patch BT26-05 em toda instância até a versão 26.2.3; em versões anteriores a 24.3.1, atualizar o produto antes de aplicar.
- Tratar todas as credenciais do cofre interno e das contas de API como comprometidas e rotacioná-las a partir de estação limpa, incluindo credenciais de domínio que o appliance podia delegar.
- Reverter permissões: papel padrão de Jump Item em No Access em toda política de grupo e revisão manual de eventos user_changed sem justificativa.
- Procurar artefatos específicos: mangoapi.php, o binário ingredi_ws, /usr/bin/dbus-authd com bit SUID e scripts inesperados em post_boot.d.
P2 — execute em até uma semana:
- Encaminhar o syslog do appliance ao SIEM por TLS, com retenção que cubra uma janela de exposição de vários meses, e alertar sobre lacunas de log.
- Aplicar default-deny de saída no appliance, liberando apenas endpoints do fabricante e os destinos corporativos de syslog e diretório.
- Mover credenciais privilegiadas para cofre externo com injeção de credencial, mantendo no appliance apenas contas de serviço não interativas.
- Restringir contas de API ao mínimo de permissões, com dono nomeado para automações e rotação programada de segredos.