Uma investigação de cibersegurança revelou um comprometimento profundo dentro da infraestrutura da 3BB (Triple T Broadband), uma das maiores provedoras de internet banda larga da Tailândia, no qual um atacante conseguiu operar em sistemas internos com privilégios administrativos elevados e utilizou uma ferramenta perfeitamente legítima para manter o acesso.
A operação foi descoberta pela empresa de inteligência de ameaças Hunt.io, que encontrou em 3 de junho de 2026 um servidor pertencente à infraestrutura do atacante acidentalmente exposto à internet.
O conteúdo funcionava praticamente como uma janela para a operação.
Havia ferramentas de exploração, scripts para coleta de credenciais, mecanismos de persistência, informações sobre máquinas comprometidas e arquivos que indicavam atividades realizadas a partir da própria rede interna da 3BB. A análise mostrou ainda sistemas conectados ao ambiente de controle do invasor com agentes executando como root, o nível máximo de privilégio em sistemas Linux.
O aspecto mais interessante do ataque, entretanto, não foi um malware sofisticado desenvolvido exclusivamente para a campanha.
Para permanecer dentro da infraestrutura, o invasor utilizou o MeshCentral, uma ferramenta open source gratuita criada para administração remota legítima de computadores.
Na prática, o software que poderia ser utilizado normalmente por uma equipe de TI para administrar servidores passou a funcionar como uma porta de acesso persistente para o atacante.
MeshCentral não é malware
Essa distinção é essencial.
O MeshCentral é um projeto legítimo de gerenciamento remoto.
Administradores podem utilizá-lo para controlar computadores, acessar terminais, gerenciar dispositivos e prestar suporte remotamente.
O problema não está no software em si.
Está em quem o instalou e para onde os agentes estavam conectando.
Na infraestrutura investigada, os pesquisadores encontraram uma configuração do MeshCentral apontando para um servidor controlado pelo atacante.
Os dispositivos comprometidos estavam organizados em um grupo chamado:
TH-3BB
e os agentes se comunicavam com uma infraestrutura externa associada ao invasor.
Isso permitia manter controle remoto utilizando um programa que, superficialmente, poderia parecer apenas mais uma ferramenta administrativa.
Atacante tinha acesso root
Uma lista de dispositivos recuperada pelos pesquisadores revelou máquinas conectadas ao servidor MeshCentral utilizado na operação.
Algumas apareciam com o agente executando como root.
Isso é particularmente grave.
Em Linux, root representa o nível mais alto de privilégio do sistema.
Um processo executado nesse contexto pode, dependendo das proteções adicionais existentes, modificar arquivos, instalar programas, criar usuários, alterar configurações e acessar grande parte dos recursos disponíveis naquela máquina.
Os pesquisadores também encontraram evidência de execução de comandos privilegiados em um servidor interno da 3BB.
Portanto, o caso não representa apenas uma tentativa de ataque observada externamente.
As evidências recuperadas apontam para comprometimento efetivo de sistemas internos.
O atacante tentou apagar os rastros — mas deixou a porta aberta
Um dos arquivos recuperados ajuda a compreender a estratégia de persistência.
O invasor possuía um script de limpeza destinado a apagar rastros da operação.
Logs eram removidos.
Históricos de shell eram apagados.
Ferramentas utilizadas durante determinadas etapas do ataque também poderiam ser excluídas.
Mas havia uma exceção importante.
O agente MeshCentral era deliberadamente preservado.
A lógica é bastante eficiente.
Ferramentas de exploração podem levantar suspeitas.
Scripts maliciosos podem ser detectados.
Arquivos incomuns podem ser encontrados durante uma investigação.
Depois que o invasor consegue instalar uma ferramenta legítima de acesso remoto com privilégios elevados, parte desse arsenal pode ser eliminada.
O atacante reduz os vestígios mais óbvios, mas mantém um canal para voltar.
O principal alvo eram credenciais de assinantes
A investigação também encontrou pistas sobre aquilo que o atacante procurava.
Scripts recuperados tinham como alvo bancos de dados relacionados à infraestrutura RADIUS da 3BB.
RADIUS é um protocolo amplamente utilizado por operadoras, provedores e empresas para autenticação, autorização e contabilização de usuários que acessam redes.
No contexto de um provedor de internet, essa infraestrutura pode conter informações utilizadas para autenticar assinantes.
Os pesquisadores encontraram referências a três bases:
radius_corp
radiusinfo
job_radius
O código buscava informações de autenticação e também dados relacionados aos equipamentos autorizados a consultar os servidores RADIUS.
Isso indica que credenciais de clientes estavam entre os objetivos da operação.
Mas existe uma ressalva fundamental.
Até agora, não há confirmação pública da 3BB demonstrando que dados de assinantes tenham efetivamente sido roubados em escala.
Existe evidência de tentativa de acesso e coleta.
Isso não deve ser automaticamente transformado na afirmação de que “todos os dados dos clientes da 3BB vazaram”.
Mais de 55 máquinas internas apareceram na movimentação lateral
Depois de estabelecer presença na infraestrutura, o invasor também tentou ampliar o acesso.
Os pesquisadores encontraram scripts para realizar password spraying por SSH contra mais de 55 sistemas internos.
Password spraying funciona de maneira diferente de um ataque tradicional de força bruta.
Em vez de testar milhares de senhas contra uma única conta, o atacante pode experimentar um pequeno conjunto de senhas prováveis contra muitas contas ou máquinas.
Isso ajuda a reduzir a chance de bloqueios automáticos.
Ainda mais preocupante: alguns scripts continham termos e senhas aparentemente relacionados especificamente à organização.
Segundo os pesquisadores, isso sugere que o invasor já possuía algum conhecimento sobre credenciais utilizadas naquele ambiente.
A origem dessas informações, entretanto, não foi determinada.
Chaves SSH e senhas também estavam na mira
O arsenal encontrado procurava diferentes tipos de segredos dentro dos sistemas comprometidos.
Entre eles estavam:
chaves privadas SSH;
credenciais de banco de dados;
arquivos de configuração PHP;
strings de comunidade SNMP;
históricos de shell;
tokens e outros arquivos potencialmente sensíveis.
Essa etapa é extremamente comum em ataques avançados.
Depois de comprometer uma máquina, o invasor procura informações que permitam comprometer a próxima.
Uma chave SSH encontrada em um servidor pode abrir outro.
Uma senha de banco de dados pode revelar informações adicionais.
Um arquivo de configuração pode conter tokens.
Uma credencial administrativa pode funcionar em dezenas de equipamentos.
Assim, um único servidor comprometido pode se transformar em uma escada para atravessar toda a infraestrutura.
Vulnerabilidades antigas também faziam parte do arsenal
O conjunto de ferramentas incluía exploits para vulnerabilidades que já possuem vários anos.
Entre elas estava a PwnKit (CVE-2021-4034), falha de escalada de privilégios no pkexec, e a conhecida Dirty COW (CVE-2016-5195), vulnerabilidade histórica do kernel Linux.
Também havia ferramentas para criar backdoors através de arquivos SUID.
Isso demonstra outro problema recorrente da segurança corporativa.
Um atacante não precisa necessariamente descobrir um zero-day extremamente sofisticado.
Depois de entrar na rede, pode encontrar servidores antigos, sistemas esquecidos ou máquinas sem atualização contendo vulnerabilidades conhecidas há anos.
É por isso que segurança interna continua importante mesmo quando existe uma proteção forte no perímetro.
Até Ghostcat apareceu na operação
Os pesquisadores também identificaram código relacionado à CVE-2020-1938, conhecida como Ghostcat.
A vulnerabilidade afetou implementações do Apache Tomcat através do protocolo AJP.
No ambiente analisado, o código era direcionado a um servidor interno Pentaho Business Intelligence, aparentemente na tentativa de obter arquivos de configuração e informações de autenticação.
Novamente, isso mostra a progressão típica de uma invasão.
O atacante entra.
Mapeia a rede.
Encontra outros serviços.
Testa vulnerabilidades.
Procura credenciais.
Amplia privilégios.
Instala persistência.
E continua avançando.
FortiGate também aparece na investigação
Uma das partes que exige mais cuidado envolve um equipamento FortiGate SSL-VPN.
O arsenal recuperado continha código destinado a explorar a CVE-2024-21762, vulnerabilidade crítica da Fortinet divulgada em 2024.
Um gateway da 3BB estava executando uma versão de firmware afetada.
Alguns relatos sobre o caso passaram a apresentar essa vulnerabilidade diretamente como o vetor inicial confirmado da invasão.
As evidências públicas, entretanto, exigem mais cautela.
Análises do material recuperado indicam que o atacante preparou e tentou utilizar o exploit contra a infraestrutura, mas não está definitivamente demonstrado, apenas com as informações públicas disponíveis, que essa exploração específica tenha sido o ponto inicial bem-sucedido que colocou o invasor dentro da 3BB.
Portanto, a afirmação mais segura é:
a CVE-2024-21762 fazia parte do arsenal e a infraestrutura FortiGate da organização estava entre os alvos investigados.
O vetor inicial exato ainda não está totalmente estabelecido publicamente.
Um erro do próprio atacante revelou a operação
Existe uma ironia importante no caso.
A Hunt.io conseguiu observar grande parte da campanha porque o próprio atacante deixou um servidor acessível publicamente.
Quando os pesquisadores encontraram essa infraestrutura em 3 de junho, havia cerca de 30 diretórios, 298 arquivos e aproximadamente 19 MB de material operacional disponíveis.
Isso permitiu reconstruir parte da cadeia de ataque.
Scripts.
Alvos.
Configurações.
Informações sobre sistemas comprometidos.
Mecanismos de persistência.
Tentativas de exploração.
O servidor acabou sendo fechado posteriormente, mas os pesquisadores conseguiram preservar o material necessário para análise.
A operação estava acontecendo quando foi observada
Outro detalhe torna o caso especialmente relevante.
Não se tratava apenas da análise de um ataque ocorrido meses ou anos antes.
Quando a infraestrutura foi descoberta em junho, a operação aparentemente ainda estava ativa.
Os dados do MeshCentral mostravam sistemas conectados ao ambiente de controle do invasor.
Isso ofereceu aos pesquisadores uma fotografia incomum de uma invasão em andamento.
Ainda assim, existe uma limitação temporal importante.
O material demonstra a situação observada naquele período.
Não é possível afirmar, apenas com esses dados, que o invasor continue atualmente dentro da infraestrutura da 3BB em setembro.
A permanência atual do acesso não foi confirmada publicamente.
Há sinais de interesse em infraestrutura relacionada à Jasmine
Os pesquisadores encontraram ainda configurações OpenVPN e outros artefatos relacionados à rede da Jasmine, grupo empresarial historicamente ligado à 3BB.
Isso levantou a possibilidade de que o atacante estivesse tentando ampliar a operação para infraestrutura relacionada.
Mas novamente existe uma diferença importante entre interesse, tentativa e comprometimento confirmado.
As evidências públicas não permitem afirmar que a Jasmine tenha sido definitivamente comprometida nessa mesma operação.
Não há atribuição pública do atacante
Outro ponto importante: os pesquisadores não atribuíram publicamente a operação a um grupo conhecido.
Não existe, até agora, base suficiente para classificar o ataque como operação chinesa, russa, norte-coreana ou vinculada a qualquer outro governo.
Também não há informação pública conclusiva apontando para ransomware.
Não foi divulgado pedido de resgate.
Não existe grupo conhecido reivindicando a invasão.
O que existe é um conjunto significativo de evidências técnicas demonstrando atividade maliciosa dentro da infraestrutura.
A motivação final permanece parcialmente desconhecida.
O interesse por credenciais de assinantes e infraestrutura interna oferece pistas, mas não é suficiente para atribuir com segurança a operação a um ator específico.
O ataque ilustra o “living off trusted tools”
A utilização do MeshCentral coloca esse caso dentro de uma tendência cada vez mais importante.
Atacantes perceberam que nem sempre precisam criar malware.
Às vezes é melhor utilizar as mesmas ferramentas que administradores legítimos utilizam.
AnyDesk.
ScreenConnect.
TeamViewer.
MeshCentral.
PowerShell.
RDP.
SSH.
Ferramentas desse tipo possuem funções poderosas por definição.
O desafio para uma equipe de segurança deixa de ser simplesmente perguntar:
“Este programa é malicioso?”
e passa a ser:
“Este programa deveria estar aqui, configurado desta maneira e comunicando com esse servidor?”
Essa mudança é enorme.
Antivírus pode enxergar apenas uma ferramenta legítima
Imagine um antivírus analisando o MeshCentral.
O programa é legítimo.
O executável pode não conter código malicioso.
Suas funções de controle remoto existem porque essa é justamente sua finalidade.
O problema está no contexto.
Quem instalou?
Com quais privilégios?
Qual servidor está controlando os agentes?
Quem possui acesso à console?
Foi autorizado pela empresa?
A diferença entre uma ferramenta de suporte e uma backdoor pode estar simplesmente na configuração e no operador que está do outro lado.
Telecomunicações são alvos especialmente sensíveis
O comprometimento de um grande provedor possui implicações diferentes de uma invasão comum.
Operadoras administram infraestrutura que conecta milhões de pessoas e empresas.
Mantêm sistemas de autenticação.
Gerenciam equipamentos de rede.
Possuem informações de assinantes.
Operam sistemas críticos para conectividade.
Por isso, acesso administrativo dentro de uma operadora pode possuir enorme valor para espionagem, fraude ou outras operações.
No caso da 3BB, os artefatos apontando para bancos RADIUS tornam essa dimensão particularmente preocupante.
O caso também muda a lógica de detecção
Ferramentas tradicionais de segurança frequentemente procuram coisas conhecidas.
Hash de malware.
Arquivo suspeito.
Comando malicioso.
Domínio identificado.
Assinatura de ataque.
Mas ataques utilizando ferramentas legítimas exigem outro tipo de análise.
Uma empresa pode precisar manter uma lista de ferramentas de acesso remoto autorizadas.
Se utiliza apenas uma plataforma corporativa específica, a instalação inesperada de MeshCentral, AnyDesk ou outro RMM deveria gerar um alerta.
O mesmo vale para conexões desses agentes com servidores externos desconhecidos.
A pergunta não é se MeshCentral é perigoso.
É se aquele MeshCentral pertence à organização.
Root + RMM é uma combinação extremamente poderosa
Existe ainda um detalhe técnico que resume a gravidade do caso.
Uma ferramenta de administração remota já possui capacidades significativas.
Quando seu agente executa como root, essas capacidades se tornam ainda maiores.
Isso pode proporcionar ao controlador uma posição privilegiada no sistema comprometido.
O atacante não precisa necessariamente executar continuamente exploits sofisticados.
Depois que estabelece um agente persistente com privilégios administrativos, pode utilizar a própria ferramenta de gerenciamento para continuar operando.
É uma forma eficiente de transformar uma invasão em acesso remoto duradouro.
Apagar malware não significa expulsar o invasor
O script de limpeza encontrado pela Hunt.io oferece talvez a lição mais interessante de toda a investigação.
O atacante apagava ferramentas.
Apagava logs.
Apagava históricos.
Mas mantinha o MeshCentral.
Isso mostra por que resposta a incidentes não pode ser reduzida a “encontrar e apagar malware”.
O malware pode desaparecer.
A vulnerabilidade pode ser corrigida.
O arquivo utilizado no ataque pode ser removido.
Mas uma credencial roubada continua funcionando.
Uma chave SSH continua válida.
Uma conta criada continua existindo.
Um certificado VPN continua oferecendo acesso.
E uma ferramenta legítima de administração remota continua perfeitamente operacional.
A backdoor mais eficiente pode parecer software de TI
Durante anos, a imagem clássica de um ataque envolvia um arquivo estranho escondido no computador.
O caso da 3BB mostra uma realidade diferente.
O atacante pode utilizar software legítimo.
Executá-lo com privilégios legítimos obtidos ilegalmente.
Configurar um servidor próprio.
E operar através de protocolos que parecem administração normal.
Para empresas de telecomunicações, bancos, indústrias e organizações com infraestruturas complexas, isso exige uma mudança importante de mentalidade.
Não basta saber quais programas são maliciosos.
É necessário saber quais ferramentas legítimas estão autorizadas a controlar cada máquina.
Porque, em determinados ataques modernos, a diferença entre o administrador da empresa e o invasor pode não estar no software instalado.
Pode estar simplesmente em quem possui o painel de controle.
