Os sensores avisaram e a automação fechou o alerta: o caso BeyondTrust

Uma ferramenta que equipes de TI usam para acessar computadores à distância foi invadida por um grupo de espionagem. O detalhe mais incômodo não é a falha em si, e sim o que a própria empresa contou: os sensores dispararam, e uma triagem automática fechou os alertas como falso positivo.

Em 30 segundos

O que aconteceu

A BeyondTrust fabrica ferramentas de acesso remoto privilegiado. O Remote Support (antes chamado Bomgar) permite que um técnico controle à distância o computador de um funcionário ou um servidor para resolver problemas. Por isso mesmo, ele fica conectado a muitos sistemas internos e guarda credenciais para alcançá-los.

Linha do tempo

• 29/08: o grupo explora o zero-day contra uma instância hospedada pela BeyondTrust e contra um equipamento instalado em um cliente (BeyondTrust).
• 27/09: a exploração bem-sucedida contra equipamentos de outro fornecedor de segurança se torna pública. A BeyondTrust inicia caças em sua plataforma de inteligência de ameaças, e a Mandiant envia um aviso breve e não específico.
• 28/09: a equipe de defesa encontra indícios em um cliente de nuvem. A instância é contida 27 minutos depois da detecção, com evidências preservadas. Cerca de sete horas depois da contenção, a equipe de segurança de produto já tinha identificado a porta de entrada e a reproduzido em laboratório.
• 30/09: a Mandiant compartilha o que viu no cliente com equipamento próprio, confirmando as observações da BeyondTrust. A correção é validada em ambiente de teste.
• 08/10: a BeyondTrust libera o patch BT26-05 para clientes de nuvem e de instalação própria. As instâncias de nuvem recebem a correção automaticamente (o aviso registra a aplicação até 09/10).
• 15/10: divulgação coordenada: CVE, aviso público, post da BeyondTrust e análise da Mandiant. O Google adiou a publicação para dar tempo aos clientes de aplicar a correção.

O que se sabe e o que não se sabe

A cadeia do ataque, em imagens

Visão executiva: risco, ganho e decisão

Risco

Concentração de confiança. Uma ferramenta de acesso remoto privilegiado reúne em um ponto só as chaves de vários sistemas. Quem a controla pode usar conexões legítimas para chegar ao resto. O Google descreve que o grupo abriu sessões remotas em computadores internos e retirou documentos sensíveis; as áreas que o grupo costuma atacar, segundo o The Record, incluem escritórios de advocacia, provedores de software como serviço, terceirizadoras de processos e empresas de tecnologia.

Alerta descartado por automação. Quando a triagem encerra um sinal sem revisão humana, a invasão fica invisível para a equipe. A BeyondTrust tirou a conclusão pública de que a triagem automática "cannot close high-severity signals independently" (não pode fechar sozinha sinais de alta gravidade). Quem responde por isso, no fim, é o dono do negócio, não o fornecedor da ferramenta de triagem.

Custo. Não há estimativa pública de prejuízo para este caso, e este texto não inventa uma. O que se pode afirmar é o tipo de custo: reconstruir equipamentos, trocar senhas e chaves que estavam guardadas nele, investigar sistemas alcançados e, quando há dado pessoal envolvido, comunicar o incidente (orientação geral: confirmar com o jurídico as obrigações da LGPD).

Ganho

A regra de governança que sai do caso é barata: definir quais classes de alerta nunca são fechadas sem uma pessoa e revisar por amostragem o que a automação descartou. Não exige comprar ferramenta nova.

Decisão para os próximos 30 dias

1. Listar as ferramentas de acesso remoto e de administração privilegiada em uso (inclusive as de fornecedores de TI que acessam a sua rede) e quem é o dono de cada uma.
2. Descobrir se alguma está acessível pela internet e em que versão está.
3. Perguntar ao time de segurança: quais alertas uma máquina pode encerrar sozinha?
4. Definir quem confere, toda semana, uma amostra dos alertas fechados e registrar a conferência.
5. Pedir ao fornecedor de ferramentas de segurança, por escrito, a regra que ele aplica para fechar alertas de alta gravidade.

Aplicação comercial: onde há receita, economia, vantagem ou risco de marca e contrato

• Risco de marca e contrato. Uma empresa que presta serviços com acesso a sistemas de clientes (provedores de TI, consultorias, terceirizadoras) vive de confiança. Se a ferramenta dela de acesso remoto for invadida, o problema chega aos clientes. Vale revisar contratos: prazo de aviso de incidente, direito de receber registros (logs), tempo máximo para aplicar correções críticas e quem paga a investigação.
• Vantagem competitiva. Opinião minha: mostrar a clientes e parceiros, de forma objetiva, que há revisão humana para alertas de alta gravidade e inventário de acessos privilegiados tende a pesar em auditorias de fornecedores e em concorrências que exigem evidência de segurança.
• Economia. Automatizar a triagem reduz carga da equipe, e isso é um ganho real. O caso mostra o limite: automatizar a fila não é o mesmo que entregar à máquina o veredito final dos sinais de alta gravidade.
• Contexto de mercado. Segundo o Dark Reading, a BeyondTrust diz atender mais de 20 mil clientes, entre eles 75 das empresas da Fortune 100. É dado da empresa sobre si mesma; serve para dimensionar o alcance potencial, não o real.

Visão operacional: processos, pessoas e rotinas

• Dono do alerta. Cada classe de alerta precisa de um responsável nomeado e de um prazo de resposta. Alerta sem dono é o que a triagem automática tende a fechar.
• Amostragem. Reservar uma rotina semanal para conferir uma amostra do que foi fechado como falso positivo. Se não houver erro, a rotina vira evidência; se houver, a regra de triagem é ajustada.
• Caça a ameaças. A BeyondTrust descreve que as caças dela partem de inteligência de ameaças e rodam "whether or not an alert has fired" (com ou sem alerta disparado). Para empresas menores, uma versão enxuta é contratar essa função de um prestador, com escopo escrito.
• Plano de resposta. Treinar o roteiro que a Mandiant recomenda: preservar evidências antes de reiniciar, reconstruir o equipamento a partir de uma imagem limpa e só depois trocar as credenciais.
• Continuidade. Saber quanto tempo a equipe de suporte fica sem a ferramenta enquanto ela é reconstruída, e qual é o procedimento alternativo.

Visão de infraestrutura: nuvem, rede, servidores e dependências

• Nuvem versus instalação própria. No caso, as instâncias de nuvem da BeyondTrust receberam a correção sem ação do cliente. Equipamentos de instalação própria (self-hosted, também chamados de appliances) exigem que a própria empresa aplique o patch pela interface de administração, e versões anteriores à 24.3.1 precisam ser atualizadas antes.
• Exposição à internet. O Google recomenda tratar como potencialmente comprometido todo equipamento que estava acessível pela internet, em versão vulnerável, durante a janela de exploração. Restringir as páginas /login e /appliance a endereços conhecidos reduz esse risco.
• Tráfego de saída. Limitar o que o equipamento pode acessar na internet (apenas os endereços do fabricante) atrapalha túneis como o usado no ataque.
• Registros fora do equipamento. Enviar logs e eventos de sessão, quase em tempo real, para um sistema central (SIEM). O grupo apagou logs locais; sem cópia externa, não há como reconstruir o que aconteceu.
• Proxy e firewall de aplicação (WAF) na frente. Permitem enxergar caminhos de requisição fora do normal, como arquivos .php desconhecidos ou conexões WebSocket de quem não é da equipe de suporte.
• Dependências. O mesmo código está no Privileged Remote Access (PRA), outro produto da empresa. Os pesquisadores não encontraram forma de explorá-lo, mas a correção foi publicada por precaução.

Visão de segurança: prevenir, detectar e responder

Prevenir

• Aplicar o patch BT26-05 sem demora nos equipamentos de instalação própria.
• Exigir login único (SAML SSO) com autenticação em duas etapas resistente a phishing nas interfaces administrativas, como recomenda o Google.
• Definir o papel padrão dos Jump Items como "No Access" (nenhum acesso), para que uma conta comprometida não alcance tudo por padrão.
• Reduzir o que fica exposto: expor só o necessário e limitar interfaces administrativas a redes confiáveis.

Detectar

• Alertas sobre mudança de permissões (evento user_changed) que elevam papéis de Jump Item ou de equipe para administrador, e criação de contas ou chaves de API sem chamado de mudança.
• Logins bem-sucedidos em /login vindos de faixas de internet residencial ou de VPN comercial, e logins administrativos fora do horário comercial.
• Transferências de arquivos em sessões remotas, sessões iniciadas por contas cujo papel mudou, e lacunas no encaminhamento de logs (o Google diz que uma interrupção limitada a uma sessão é forte indício de adulteração).
• Caminhos de requisição fora do conjunto conhecido do produto.

Responder

1. Preservar evidências antes de agir: foto do equipamento (snapshot) com memória e disco, mais logs de proxy, WAF e firewall.
2. Isolar o endereço público e restringir a saída de rede.
3. Reconstruir em vez de limpar. Nas palavras do Google: "Customers cannot audit the appliance host file system, and host-level persistence survives reboot and configuration reset". Em português: o cliente não consegue auditar o sistema de arquivos do equipamento, e o que o invasor deixou instalado sobrevive a reinício e a reset de configuração.
4. Trocar credenciais só depois do patch ou da reconstrução, porque trocar antes entrega a senha nova a quem ainda controla o equipamento. O Google sugere seguir a ordem de dependência: administração do equipamento, usuários locais, chaves de API, contas de integração com identidade e certificados SAML, cofres e senhas de sistemas-alvo, credenciais de integrações (e-mail, logs, chamados) e qualquer senha digitada em sessão de suporte na janela de exposição.
5. Esperar tentativas em massa. O Google avalia que é possível ver tentativas amplas contra essa falha depois da divulgação, como ocorreu com o Ivanti em 2024. É previsão, não fato ocorrido.

Visão de tecnologia: como funciona por dentro

Esta seção traz o detalhe técnico, com os termos explicados. Os nomes de arquivos, caminhos e comandos vêm da análise do Google/Mandiant; a explicação em linguagem simples é minha.

A falha e a nota 9,3

O aviso BT26-05 descreve a falha como "Improper Origin Validation in an Internal Messaging Component" (validação inadequada de origem em um componente interno de mensagens) e a classifica como CWE-290. Em termos simples: uma parte do programa que troca mensagens internas não verificava direito de onde vinham as mensagens, e um atacante externo conseguia fazer operações com arquivos no equipamento. A Mandiant fala em envio arbitrário de arquivos. Afetadas: todas as versões do Remote Support até a 26.2.3.

A nota vem do CVSS 4.0, um sistema de pontuação de gravidade. O vetor publicado é CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Lendo parte por parte:

ObservaçãoA nota mede a falha isolada. A campanha real foi além: o grupo usou o equipamento como ponto de partida para outros sistemas. Por isso o 9,3 não resume o risco para quem tem a ferramenta ligada à rede inteira. (Explicação dos códigos do CVSS: conhecimento geral; conferir na especificação oficial do FIRST.)

Observação de datas: o aviso registra publicação em 15/10/2026 e informa que, "as of Oct 9, 2026" (em 9 de outubro), o patch já estava aplicado a todos os clientes de nuvem. O blog da BeyondTrust informa que o patch foi liberado em 08/10. Uma das reportagens trouxe 09/10 como data do patch, o que bate com a aplicação na nuvem, não com o lançamento.

Passo a passo do ataque (segundo o Google/Mandiant)

1. Entrada. Requisições para um arquivo chamado app_84304470%2Ephp (não recuperado). Cerca de 11 minutos depois, surge uma web shell na pasta do serviço web.
2. Web shell SAWFLY (mangoapi.php). Uma web shell é um pequeno programa escondido em um servidor web que aceita comandos de fora. Esta é escrita em PHP e ofuscada. Ela se comunica de forma cifrada e só responde se a requisição trouxer um parâmetro secreto (_c94mfe); sem ele, devolve "404 página não encontrada" para parecer inofensiva. O código recebido é executado com eval().
3. Escalada de privilégio. O invasor copiou o programa /bin/sh para /usr/bin/dbus-authd (nome parecido com um serviço legítimo), trocou o dono para root (administrador total do Linux) e ativou o bit SUID, que faz o programa rodar sempre com os poderes do dono. Resultado: um acesso de administrador pronto para uso pela conta de serviço do site.
4. Persistência. Criou o script /home/bomgar/sbin/post_boot.d/zz-root-persist, executado a cada inicialização. Ele acrescenta ao arquivo sudoers.template uma linha que permite à conta de serviço usar sudo sem senha, e depois regenera o arquivo de regras do sistema. Por isso, reiniciar o equipamento não remove o acesso.
5. Cofre de credenciais. Usou o utilitário nativo /ns/sbin/bt-secrets, com variações de sintaxe, para tentar ler o cofre (vault) onde o equipamento guarda senhas, chaves de API e credenciais de computadores. Depois apagou o log desse utilitário. O Google informa que foram tentativas de acesso; a lista de segredos efetivamente obtidos não foi divulgada.
6. Salto para dentro. Entrou no portal com uma conta administrativa comprometida e elevou, de "sem acesso" para "administrador", as permissões de Jump Items e equipes. Jump Items são conexões pré-configuradas com computadores internos, úteis para o suporte e igualmente úteis para um invasor. Abriu sessões remotas nesses computadores, navegou pelos arquivos e retirou documentos como inventários de software.
7. Túnel. Instalou o BARECLAW (ingredi_ws), um proxy SOCKS5 sobre WebSocket escrito em C, escutando na porta TCP 19800 e usando o caminho /uidchanarge. Um proxy SOCKS5 repassa tráfego de rede por dentro de um equipamento; aqui, permitia ao invasor alcançar destinos internos a partir do aparelho. Alterou a configuração do HAProxy (proxy reverso do equipamento) para encaminhar esse caminho ao túnel, tornando-o acessível pela internet sem abrir uma porta nova.
8. Anti-forense. Removeu logs de sistema, do servidor web e da aplicação, por todo o incidente. O Google observa que os clientes não conseguem auditar o sistema de arquivos do equipamento e que persistência em nível de host sobrevive a reinício. Por isso a orientação é reconstruir.

O Google também publicou regras YARA (padrões de busca para identificar arquivos maliciosos) para SAWFLY e BARECLAW, e indicadores adicionais (hashes) na plataforma Google Threat Intelligence, para usuários registrados. Não há hashes no texto público.

Como a triagem automática entrou na história

O modelo comum de detecção tem camadas: sensores geram alertas; uma triagem automática decide quais chegam a uma pessoa; a equipe investiga. A BeyondTrust descreve que usa esse modelo. No trecho central do post dela:

"Our sensors fired in real time when the actor escalated privileges, but the built-in triage tool in our third-party detection platform closed those alerts as false positives."
(Nossos sensores dispararam em tempo real quando o ator escalou privilégios, mas a ferramenta de triagem integrada à nossa plataforma de detecção de terceiros fechou esses alertas como falsos positivos.)

Um falso positivo é um alerta sobre algo que, na verdade, é inofensivo. A triagem existe para filtrar esse ruído; o risco é filtrar também um alerta verdadeiro. O que a empresa diz estar fazendo: trabalhar com o fornecedor para que a triagem automática "cannot close high-severity signals independently"; reverificar os vereditos externos com as próprias plataformas de caça antes de fechar alertas; e tratar o veredito da triagem como "one input" (uma entrada), mantendo os alertas fechados no escopo das caças.

A descoberta, segundo a empresa, não veio de um alerta, e sim de uma caça a ameaças (threat hunting): uma busca ativa por comportamentos de atacante, iniciada por inteligência sobre ameaças novas. A BeyondTrust escreve que as caças "look for what an attacker does on a system, not a vendor's verdict on an alert" (procuram o que um atacante faz em um sistema, não o veredito de um fornecedor sobre um alerta).

InferênciaO trecho sugere duas camadas independentes como boa prática: uma que reage a alertas e outra que procura comportamentos sem depender deles. Esta é leitura minha do texto, não afirmação da empresa. OpiniãoA lição vale também para automações de IA que ganham autonomia para decidir: o ponto de controle é quem pode encerrar a decisão sem olhar humano.

Mesma semana, mesmo padrão

Segundo o Dark Reading, na mesma semana foram divulgadas falhas exploradas em equipamentos de borda de outros fornecedores (Ivanti Connect Secure, Cisco Secure Email Gateway e Palo Alto PAN-OS, estes dois últimos no catálogo KEV da CISA). Fonte única para esses detalhes; serve de contexto, não de conclusão. O Google avalia, com confiança alta, que o ARMORY CASTLE continuará a usar zero-days em equipamentos de borda.

Para o leitor comum: o que fazer hoje

• Se você trabalha em uma empresa que usa suporte remoto de TI, pergunte ao responsável: "Usamos o BeyondTrust Remote Support? É de nuvem ou instalado aqui? Está atualizado?"
• Se a ferramenta for instalada na empresa e estiver acessível pela internet, peça confirmação de que o patch BT26-05 foi aplicado e de que alguém olhou os registros do período.
• Para qualquer ferramenta de segurança com alertas: pergunte quem vê o que a automação joga fora.
• Se você tem um prestador de TI com acesso à sua rede, peça por escrito como ele protege a ferramenta de acesso remoto e como avisa você em caso de incidente.

Termos desta matéria

Estes termos devem entrar no glossário do canal. Até a inclusão, ficam definidos aqui.

Zero-day

Falha explorada antes de existir correção disponível. O fabricante teve "zero dias" para corrigir.

CVE

Identificador público de uma falha de segurança (CVE-2026-102764, por exemplo), para que todos falem da mesma falha.

CVSS

Sistema de pontuação de gravidade de falhas, de 0 a 10. A nota 9,3 é classificada como crítica.

CWE

Catálogo de tipos de falha de programação. CWE-290 é a categoria citada no aviso.

Web shell

Programa escondido em um servidor web que aceita comandos de fora e dá controle remoto ao invasor.

Escalada de privilégio

Quando o invasor, com acesso limitado, consegue poderes maiores, como os de administrador.

SUID

Permissão especial em sistemas Linux que faz um programa rodar com os poderes de seu dono, mesmo quando outra pessoa o executa.

Persistência

Forma de o invasor manter o acesso mesmo depois de reinícios ou da troca de senhas.

Cofre de credenciais (vault)

Área do sistema que guarda senhas, chaves e outras credenciais para uso automático.

Jump Item

Conexão pré-configurada, no Remote Support, com um computador ou servidor interno, para o suporte entrar sem digitar tudo de novo.

Proxy SOCKS5 (túnel)

Passagem que repassa tráfego de rede por dentro de um equipamento, permitindo alcançar destinos que só aquele equipamento enxerga.

Proxy reverso (HAProxy)

Servidor que recebe conexões de fora e as encaminha ao serviço certo dentro do equipamento.

Appliance

Equipamento ou imagem de sistema entregue pronta para uma função, como o servidor do Remote Support instalado na empresa.

Triagem automática de alertas

Programa que separa alertas graves de ruído e decide quais chegam a uma pessoa, como o filtro de spam do e-mail.

Falso positivo

Alerta de algo que na verdade é inofensivo. Fechar um alerta verdadeiro como falso positivo deixa a invasão passar.

Caça a ameaças (threat hunting)

Busca ativa, feita por pessoas, por sinais de atacante no ambiente, sem esperar um alerta.

SIEM

Sistema central que reúne registros e alertas de vários equipamentos para análise e guarda de evidências.

Autenticação em duas etapas resistente a phishing

Método de segunda etapa (como chave física ou passkey) que não pode ser repassado a um golpista por engano.

YARA

Regras de busca para identificar arquivos maliciosos por padrões.

Fontes

Primárias

• BeyondTrust. Aviso de segurança BT26-05, "Improper Origin Validation in an Internal Messaging Component", 15/10/2026: beyondtrust.com/trust-center/security-advisories/bt26-05
• BeyondTrust. Relato do incidente (ARMORY CASTLE e BT26-05), publicado em 15/10/2026 e atualizado em 16/10/2026: beyondtrust.com/blog/entry/bt26-05
• Google Threat Intelligence Group e Mandiant, análise do ARMORY CASTLE, 15/10/2026: cloud.google.com/blog/topics/threat-intelligence/armory-castle-exploits-beyondtrust

Jornalísticas

• CSO Online, 16/10/2026: BeyondTrust zero-day tied to Chinese spies puts Remote Support users on alert
• Dark Reading, 16/10/2026: BeyondTrust Remote Support zero-day continues trend of exploited edge bugs
• The Record, 16/10/2026: therecord.media/beyond-trust-cyberattack-china
• The Hacker News, outubro de 2026: China-Linked Hackers Exploited BeyondTrust Zero-Day to Take Over Remote Support Servers
• SC Media, 16/10/2026: BeyondTrust zero-day exploited by China-linked group Armory Castle

Órgãos públicos, pesquisa independente e blogs de administradores

• Canadian Centre for Cyber Security, alerta AL26-025, 16/10/2026: cyber.gc.ca
• watchTowr, FAQ técnico do CVE-2026-102764: watchtowr.com
• The Back Room Tech, orientação a administradores: thebackroomtech.com
• WindowsForum, tópico sobre patch, caça e reconstrução: windowsforum.com (a página lida não trazia respostas de usuários)

Não consegui abrir o Reddit (r/sysadmin, r/netsec), o NVD nem o catálogo KEV da CISA nesta revisão. O que é dito aqui sobre KEV vem de imprensa e blogs.

Nota de método: a nota 9,3, o vetor CVSS, a data de publicação e a janela de versões foram conferidos na página do aviso BT26-05 e no alerta canadense. As datas do incidente vêm do post da BeyondTrust e do relatório do Google. Páginas lidas em 19/10/2026, em parte por resumo automático. O relato sobre a triagem automática aparece só no post da BeyondTrust (o CSO Online o repete); THN, SC Media e watchTowr não tratam do assunto.

Conferência cruzada: onde as fontes divergem

• Data do patch. O post da BeyondTrust diz 08/10. O aviso registra a correção das instâncias de nuvem até 09/10. THN e Dark Reading falam em 09/10 e o watchTowr, em 15/10 (data do aviso). Use "a partir de 08/10, com a nuvem corrigida até 09/10".
• Data do alerta. Aviso e divulgação coordenada: 15/10. O post foi atualizado em 16/10, e THN e o alerta canadense usam 16/10.
• Número de vítimas. A BeyondTrust fala em duas (uma instância hospedada por ela e um equipamento de cliente). O THN menciona um só equipamento. Prevalece a fonte primária, e a contagem é a conhecida, não o total.
• Versões. O aviso lista "todas as versões até 26.2.3". O patch cobre 24.3.1 a 26.2.3; quem está abaixo disso precisa atualizar antes. Um blog (SafeGuard) escreveu "anteriores à 26.2.3" e contradiz o aviso, então vale o aviso.
• Produto. Alguns veículos citaram também o Privileged Remote Access (PRA). O aviso lista só o Remote Support. A BeyondTrust diz não ter achado forma de explorar o PRA, mas aplicou o patch por precaução, porque o código afetado é compartilhado.
• CISA KEV. THN, Back Room Tech e SafeGuard dizem que a falha entrou no catálogo de vulnerabilidades exploradas da CISA em 16/10, com prazo de 19/10 para agências federais americanas. Não consegui abrir o catálogo. [CONFIRMAR]
• Como o grupo se escondeu. O THN acrescenta uso de VPNs comerciais e roteadores domésticos ou de pequenos escritórios comprometidos, e alteração do arquivo de configuração do HAProxy para expor o túnel à internet.

"They sit at the boundary of the enterprise while holding privileged access to what lies behind it." Justin Moore, Arctic Wolf, citado pela SC Media (trecho lido por resumo automático [CONFIRMAR]).

Pergunta final

Na sua empresa, quem confere o que a automação descartou? Responda no direct do Instagram @techtraduzida e conte como o seu time trata esse ponto. Se este conteúdo ajudou, siga o perfil, curta e compartilhe: isso ajuda a desenvolver e divulgar o canal.