Um técnico precisa entrar numa estação de uma filial às seis da tarde. Ele abre a ferramenta de acesso remoto, digita a credencial e resolve o chamado em dez minutos. Ninguém pergunta mais nada, porque é rotina.
Agora imagine que a mesma ferramenta, instalada para facilitar a vida da TI, seja a porta que um invasor usa para entrar. Ela já está na rede, já é confiável, já tem permissão para controlar máquinas. É o caminho ideal.
Isso não é hipótese. Em 2026, uma falha crítica num produto de acesso remoto corporativo mostrou como o atalho da TI vira o atalho do ataque.
O que a CVE-2026-1731 deixou claro
A CVE-2026-1731 afeta o BeyondTrust Remote Support e o Privileged Remote Access. Segundo o catálogo de vulnerabilidades exploradas da CISA, é uma injeção de comandos de sistema operacional que permite a um atacante remoto, sem autenticação e sem interação do usuário, executar comandos no servidor. A CISA incluiu a falha no catálogo em 13 de fevereiro de 2026.
A velocidade chama atenção. De acordo com a reportagem do SecurityWeek, de 20 de fevereiro de 2026, a exploração ativa começou em menos de 24 horas depois da publicação de uma prova de conceito, em 10 de fevereiro. Na noite de 19 de fevereiro, a CISA marcou a entrada como usada em campanhas de ransomware.
Os relatos da Unit 42, da Palo Alto Networks, descrevem o que veio depois da entrada: reconhecimento da rede, criação de contas, web shells, ferramentas de gestão remota instaladas pelo invasor, movimentação lateral e roubo de dados.
O invasor não precisou inventar um caminho. Usou o que a TI já tinha aberto para si mesma.
Acesso remoto é a porta de maior valor da rede
Não é só uma falha pontual. O relatório Active Adversary da Sophos, do primeiro semestre de 2024, analisou mais de 150 casos de resposta a incidentes de 2023. O abuso de RDP apareceu em 90% dos ataques, e os serviços remotos externos foram a forma de acesso inicial em 65% dos casos.
É um dado de 2023, anterior ao episódio de 2026, mas aponta na mesma direção: quem ataca procura o serviço que já foi feito para controlar máquinas à distância.
Por que ele serve tão bem? Por três razões:
- ele já tem privilégio para agir em muitas estações;
- o tráfego dele parece trabalho normal de suporte;
- quase ninguém olha o registro dele até a hora do incidente.
O resultado é que uma falha na ferramenta e uma política frouxa em torno dela acabam no mesmo lugar: alguém entra com um acesso que parece legítimo e o primeiro sinal é o dano. Atualizar é necessário, mas não responde quem mais já tem uma chave.
Quatro perguntas que a TI precisa saber responder
Antes de falar de ferramenta, vale testar a operação atual. Se a equipe não responde com segurança a alguma destas, o acesso remoto é um ponto cego:
Quem entrou, em qual máquina e quando?
Não vale “o time de suporte”. Vale o nome, o equipamento e o horário de cada sessão, de forma que a auditoria consiga reconstituir o dia.
Quem pode entrar fora do horário?
Um terceiro com credencial permanente e sem janela de atendimento é um risco que ninguém lembra de revisar. A pergunta é se o acesso a servidor, de madrugada, é negado ou apenas esperado que não aconteça.
O usuário sabe que alguém está na máquina dele?
Em estação com dado pessoal, a sessão sem aviso é difícil de explicar depois. Quando a política exige, o consentimento precisa ser parte do fluxo, não um acordo informal.
Onde fica o registro da sessão?
Se a trilha está no serviço de um terceiro, a evidência depende de outra empresa, de outro prazo e de outra política de retenção. Se está num servidor seu, depende de você.
Como o Tz0 Remote trata o acesso
O Tz0 Remote parte da ideia de que acesso remoto sem registro é confiança, não controle. A página do módulo descreve um fluxo em cinco passos: solicitar, autorizar, atender, registrar e auditar.
Na prática, segundo a página, a política verifica nível, horário e escopo antes da sessão. As credenciais têm níveis diferentes para suporte, infraestrutura e terceiro, e a janela de atendimento define quando cada grupo pode ser acessado, registrando as tentativas fora dela. Onde a política exigir, o usuário vê quem pede, o motivo e o chamado, e decide; sem o aceite, não há sessão.
A sessão ocorre dentro da rede, sem intermediário, e é aberta pelo SiN, a ferramenta para Windows do administrador. A auditoria fica no Dashboard, por usuário e por dispositivo, com linha do tempo e trilha detalhada: abertura da conexão, programas usados, tempo ocioso e fechamento, cada evento com horário.
A trilha da sessão fica no servidor do próprio cliente, junto com o restante da evidência. Isso não torna o módulo imune a falhas: ele continua sendo um software que precisa de atualização, e o servidor deve ficar dentro da política de patch da casa. O que muda é quem tem a guarda do registro e das regras.
Antes de abrir a próxima sessão
Faça um exercício simples esta semana: escolha uma estação de uma filial e tente reconstituir quem a acessou nos últimos trinta dias, por quanto tempo e para fazer o quê. Se levar mais que uma tarde, o acesso remoto da sua operação depende de memória e de boa vontade.
Depois repita para os terceiros: liste cada empresa externa com credencial, o que cada uma alcança e em que horário. As lacunas costumam aparecer nessa segunda lista.
Para a parte de investigação, vale ler também o que escrevemos sobre o que o resgate pago não explica na máquina e sobre acesso remoto sem porta dos fundos.
Se você opera um parque grande e quer ver essa trilha funcionando no seu ambiente, peça uma avaliação do Trauma Zer0.