Ataques recentes mostram um problema que vai muito além de uma vulnerabilidade: quando a infraestrutura legítima de uma empresa passa a distribuir o código do atacante, a própria cadeia de confiança se transforma em arma.

A segurança de uma infraestrutura corporativa não depende apenas de firewalls, antivírus ou da aplicação rápida de patches. Em ataques sofisticados, o próprio software considerado confiável pode ser transformado em uma ferramenta para comprometer outros sistemas.

Dois casos documentados em 2026 ilustram bem essa evolução.

Em julho, pesquisadores da Kaspersky identificaram uma nova campanha atribuída ao grupo Head Mare, que explorou vulnerabilidades em servidores não corrigidos do TrueConf para obter privilégios elevados, instalar backdoors e substituir instaladores legítimos do cliente por versões comprometidas.

Em outra campanha, denominada HelloNet, os atacantes abusaram do mecanismo de atualização do ViPNet para estabelecer persistência por meio de DLL sideloading e carregar componentes maliciosos dentro de processos legítimos do Windows.

Embora sejam operações diferentes, existe uma característica em comum entre elas: o atacante explora a confiança que administradores e usuários depositam em componentes legítimos da infraestrutura.

E, para quem trabalha com TI, essa talvez seja a parte mais importante da história.

Head Mare: quando o servidor de videoconferência vira um distribuidor de malware

Em 11 de agosto de 2026, a Kaspersky publicou uma análise detalhada de uma nova campanha do grupo Head Mare, detectada em julho.

Segundo os pesquisadores, os ataques atingiram organizações russas de setores como instrumentação, eletrônica, transporte, energia, tecnologia da informação e desenvolvimento de software.

A operação explora uma cadeia de duas vulnerabilidades no TrueConf Server, identificadas pelos pesquisadores pelos códigos internos KLCERT-26-057 e KLCERT-26-058.

A combinação permite que os invasores executem código com privilégios elevados no servidor comprometido.

O ponto mais preocupante, entretanto, não é simplesmente conseguir executar código no servidor.

É o que os invasores fazem depois.

Em vez de parar no comprometimento da máquina, o grupo utiliza o servidor TrueConf como uma espécie de plataforma de distribuição para infectar os próprios usuários da organização.

Esse detalhe muda completamente a gravidade do incidente.

Do comprometimento do servidor à infecção dos clientes

De acordo com a investigação da Kaspersky, os atacantes conseguem acessar o TrueConf Server pela porta TCP 4307, que fica aberta por padrão segundo a documentação do produto.

A cadeia observada começa com a exploração da vulnerabilidade identificada como KLCERT-26-057. Os invasores conseguem enviar um script malicioso para o servidor e executá-lo dentro do ambiente utilizado pelo TrueConf.

A segunda vulnerabilidade, KLCERT-26-058, é então utilizada para escapar das limitações desse ambiente e executar código com privilégios mais altos no sistema operacional.

Com acesso privilegiado, os invasores conseguem avançar para as etapas seguintes da operação.

É aqui que o ataque deixa de ser apenas uma invasão de servidor.

O objetivo passa a ser comprometer a cadeia de distribuição do software.

O instalador legítimo deixa de ser confiável

Depois de comprometer o servidor, os invasores substituem o instalador legítimo do TrueConf Client por uma versão modificada.

Para o usuário final, a situação pode parecer absolutamente normal.

Ele acessa o servidor corporativo, baixa o cliente que acredita ser oficial e instala o programa.

A diferença é que o arquivo já foi adulterado.

A versão comprometida contém o PhantomCore, um backdoor utilizado pelos invasores para obter controle do sistema infectado.

Segundo a Kaspersky, essa técnica permitiu que o ataque ultrapassasse o servidor inicialmente comprometido e alcançasse os participantes das videoconferências que utilizavam o instalador adulterado.

Por que isso é mais grave do que simplesmente distribuir um malware?

Porque existe uma diferença enorme entre:

“Um funcionário recebeu um executável suspeito por e-mail.”

e:

“O servidor corporativo que normalmente distribui o software utilizado pela empresa entregou o executável malicioso.”

No segundo cenário, a confiança do usuário trabalha a favor do atacante.

Na minha avaliação, essa é uma das características mais interessantes da campanha Head Mare. O ataque não depende exclusivamente de engenharia social para convencer cada vítima individualmente. O invasor tenta comprometer o ponto de confiança que atende várias vítimas ao mesmo tempo.

É uma lógica semelhante à observada em ataques de supply chain, ainda que a cadeia específica aqui esteja concentrada na infraestrutura do próprio produto.

PhantomCore e PhantomGraph: dois componentes dentro da mesma operação

A campanha não se limita ao PhantomCore.

Durante a análise de um servidor comprometido, a Kaspersky identificou também um segundo backdoor denominado PhantomGraph.

Os pesquisadores encontraram sobreposição de código entre PhantomGraph e PhantomCore, indicando relação entre os componentes.

O PhantomGraph utiliza dois módulos DLL principais:

SysExcSvc.dll

Esse componente funciona como uma camada de comunicação.

Entre suas funções está o recebimento de comandos e o envio dos resultados para a infraestrutura controlada pelos atacantes.

Um detalhe particularmente interessante é a utilização do Microsoft OneDrive como parte da infraestrutura de comando e controle.

Isso é relevante porque serviços legítimos de nuvem podem dificultar a distinção entre tráfego normal e comunicação maliciosa.

SysReadSvc.dll

O segundo componente é responsável por interpretar os comandos recebidos pelo primeiro módulo, executá-los e armazenar os resultados.

A divisão das funcionalidades entre diferentes DLLs também complica a análise.

Em vez de existir um único executável contendo toda a lógica do backdoor, diferentes componentes assumem funções específicas.

Para um analista de segurança, isso significa que encontrar apenas um dos módulos não necessariamente revela toda a extensão da intrusão.

Persistência e abuso de ferramentas legítimas

Outro aspecto observado na campanha é a tentativa de estabelecer persistência utilizando mecanismos nativos do Windows.

Os invasores executam comandos PowerShell codificados em Base64 para instalar os componentes maliciosos como serviços.

Também foram observadas técnicas voltadas à coleta de informações do sistema e movimentação posterior, incluindo:

• identificação do hostname;
• identificação do usuário atual;
• coleta de informações do sistema;
• criação de túnel SSH reverso;
• obtenção de informações a partir do processo lsass.exe.

A presença dessas técnicas mostra que o objetivo não era simplesmente executar um malware uma única vez.

A cadeia foi construída para manter acesso, coletar informações e ampliar o controle sobre o ambiente comprometido.

As versões vulneráveis do TrueConf Server

A boa notícia é que as vulnerabilidades exploradas nessa campanha já possuem correções.

A própria TrueConf publicou um boletim de segurança em 18 de junho de 2026, recomendando a atualização imediata para:

• TrueConf Server 5.3.9
• TrueConf Server 5.4.9
• TrueConf Server 5.5.5

O changelog oficial confirma essas versões e suas respectivas datas de lançamento em junho de 2026.

A recomendação oficial é particularmente importante porque as versões anteriores das respectivas linhas permanecem vulneráveis à cadeia explorada pelo Head Mare.

Para organizações que utilizam TrueConf Server, portanto, a atualização não deve ser tratada como uma melhoria opcional.

É uma medida de segurança.

E existe um detalhe que considero ainda mais importante: se um servidor vulnerável ficou exposto à Internet, simplesmente atualizá-lo pode não ser suficiente.

Se o invasor já conseguiu acesso ao servidor, é necessário investigar se houve comprometimento antes de instalar o patch.

O que fazer se o TrueConf Server estava vulnerável?

Esse é um ponto que muitas notícias sobre vulnerabilidades deixam de abordar.

Imagine que uma empresa esteja executando uma versão vulnerável e descubra o problema hoje.

Ela instala a versão corrigida.

Ótimo.

Mas como saber se ninguém explorou a vulnerabilidade antes da atualização?

Não há como responder isso apenas olhando para o número da versão.

Em um cenário real de resposta a incidentes, a organização deveria considerar:

1. verificar logs do TrueConf Server;
2. investigar conexões relacionadas à porta TCP 4307;
3. procurar arquivos e scripts inesperados;
4. verificar alterações no instalador do TrueConf Client;
5. investigar criação de serviços desconhecidos;
6. procurar sinais de execução anômala do PowerShell;
7. verificar atividades relacionadas a lsass.exe;
8. investigar túneis SSH reversos;
9. verificar conexões incomuns com serviços de nuvem;
10. avaliar endpoints que instalaram o cliente a partir do servidor comprometido.

Esse último ponto é especialmente importante.

Se o servidor foi comprometido e o instalador foi adulterado, o incidente não termina no servidor.

Os computadores que receberam o instalador também precisam ser considerados potencialmente expostos.

CVE-2026-3502: outro problema importante no ecossistema TrueConf

Existe ainda uma segunda vulnerabilidade do TrueConf que merece ser mencionada, mas não deve ser confundida com as falhas KLCERT-26-057 e KLCERT-26-058.

Trata-se da CVE-2026-3502, uma vulnerabilidade encontrada no TrueConf Client.

Segundo o NIST, a falha ocorre porque o cliente baixa código de atualização e o aplica sem realizar uma verificação adequada de integridade. Um atacante capaz de interferir no caminho de entrega poderia substituir o payload legítimo por código adulterado.

A vulnerabilidade recebeu pontuação CVSS 3.1 de 7,8, considerada alta pela CNA responsável pelo registro.

Ela afeta as versões 8.1.0 até 8.5.2 do TrueConf Client.

O caso também é diferente da campanha Head Mare descrita anteriormente.

A CVE-2026-3502 esteve associada à chamada Operation TrueChaos, uma campanha que explorou a vulnerabilidade como zero-day contra entidades governamentais no Sudeste Asiático.

A vulnerabilidade foi incluída no catálogo Known Exploited Vulnerabilities (KEV) da CISA, indicando exploração real.

Portanto, há dois assuntos relacionados ao TrueConf que merecem ser acompanhados separadamente:

TrueConf Server: KLCERT-26-057 e KLCERT-26-058, utilizados na campanha Head Mare.

TrueConf Client: CVE-2026-3502, relacionada à ausência de verificação de integridade no mecanismo de atualização.

Essa distinção é importante para evitar que diferentes incidentes sejam apresentados como se fossem uma única vulnerabilidade.

HelloNet: quando o próprio sistema de atualização vira ponto de persistência

O caso TrueConf não é o único exemplo recente de abuso da confiança em mecanismos legítimos.

Em julho de 2026, pesquisadores da Kaspersky detalharam a campanha HelloNet, ativa desde pelo menos maio.

O ataque atingiu organizações russas de grande porte nos setores governamental, energético, de transporte, educação, logística e indústria.

A característica mais interessante da campanha é que os atacantes utilizaram o próprio sistema de atualização do ViPNet como mecanismo para estabelecer persistência e carregar componentes maliciosos.

Isso foi possível por meio de DLL sideloading.

wtsapi32.dll: o arquivo que não deveria estar ali

Os pesquisadores encontraram um arquivo chamado:

wtsapi32.dll

dentro do diretório:

C:\Program Files (x86)\InfoTeCS\VIPNet Update System

O nome não é aleatório.

wtsapi32.dll é um nome associado a uma biblioteca legítima do Windows.

O malware se aproveita justamente dessa característica.

O executável legítimo do sistema de atualização do ViPNet, itcsrvup64.exe, é suscetível à técnica de DLL sideloading.

Ao encontrar a DLL maliciosa no local apropriado, o processo legítimo acaba carregando o código do atacante.

A Kaspersky batizou esse carregador de HelloInjector.

HelloInjector: do processo legítimo ao código malicioso

O objetivo do HelloInjector é chegar ao processo svchost.exe.

Depois de iniciado, o malware verifica o processo em que está sendo executado.

Se não estiver dentro de svchost.exe, ele procura processos ativos cujo nome contenha svchost e cuja linha de comando contenha netsvcs.

Quando encontra um processo compatível, utiliza:

NtWriteVirtualMemory
NtCreateThreadEx

para realizar a injeção.

Depois de reiniciado dentro do novo processo, o HelloInjector verifica novamente se está em um svchost.exe.

Confirmada a condição, o carregador executa o payload armazenado em seu próprio corpo.

Para quem trabalha com Windows internamente, esse comportamento é particularmente relevante.

svchost.exe é um processo extremamente comum.

Por isso, simplesmente detectar sua execução não é suficiente.

O contexto é que importa:

qual processo iniciou o svchost.exe, quais DLLs foram carregadas, de qual diretório vieram e que comportamento ocorreu imediatamente antes e depois?

Essa é a diferença entre monitoramento baseado apenas em indicadores e uma abordagem realmente comportamental.

HelloProxy: proxy oculto e carregador de novos módulos

Depois da injeção, o HelloInjector carrega outro componente denominado HelloProxy.

A Kaspersky descreve o HelloProxy como um proxy oculto e carregador de novos payloads enviados pelo servidor de comando.

O componente utiliza técnicas de interceptação de funções para controlar determinadas operações de rede, incluindo:

NtDeviceIoControlFile
closesocket
shutdown

Para isso, os atacantes utilizaram a biblioteca Microsoft Detours.

Essa escolha é interessante porque demonstra novamente uma característica recorrente de campanhas modernas:

o invasor não precisa reinventar tudo.

Bibliotecas legítimas e técnicas conhecidas podem ser combinadas de maneira maliciosa para construir uma cadeia de ataque sofisticada.

HelloBackdoor: malware escrito em Rust

Os pesquisadores também identificaram o HelloBackdoor, um backdoor desenvolvido em Rust.

Sua função inclui manipulação do sistema de arquivos, principalmente operações de upload e download de arquivos.

Comandos que não correspondem ao formato específico esperado pelo malware podem ser encaminhados para execução através do cmd.exe.

A utilização de Rust chama atenção porque a linguagem vem sendo cada vez mais utilizada para desenvolvimento de malware moderno.

Mas é importante não cair em uma conclusão simplista.

Rust não é uma técnica de evasão por si só.

Um malware escrito em Rust continua sendo detectável por seu comportamento.

Para um EDR, o mais relevante não é saber se o binário foi escrito em Rust, C++, Go ou outra linguagem.

O que importa é o conjunto de ações realizado pelo processo.

Atribuição: por que é preciso ter cuidado

A HelloNet também apresenta elementos que podem sugerir uma possível conexão com atores de língua chinesa.

Entretanto, a própria Kaspersky trata essa atribuição com baixa confiança.

Entre os elementos considerados estão referências a serviços chineses e infraestrutura relacionada ao ecossistema de desenvolvimento.

Isso não é suficiente, por si só, para afirmar que um determinado governo ou grupo específico está por trás da operação.

Essa cautela é necessária porque infraestrutura, idioma, domínios e referências encontradas dentro de malware podem ser falsificados ou utilizados deliberadamente para dificultar a atribuição.

Em segurança ofensiva e inteligência de ameaças, atribuição é uma hipótese construída a partir de múltiplos indicadores, e não uma conclusão baseada em uma única evidência.

O que essas duas campanhas ensinam aos profissionais de TI?

É aqui que, na minha opinião, as duas histórias ficam realmente interessantes.

TrueConf e ViPNet são produtos diferentes.

As técnicas também são diferentes.

Mas ambos os ataques exploram um mesmo conceito:

confiança excessiva em software legítimo.

No primeiro caso, o servidor de videoconferência é comprometido e passa a distribuir instaladores adulterados.

No segundo, o mecanismo de atualização legítimo é utilizado para carregar uma DLL maliciosa.

Em ambos os casos, o atacante tenta ficar dentro do fluxo normal da infraestrutura.

E isso muda a estratégia de defesa.

1. Não basta verificar se o software é legítimo

Um executável assinado e conhecido merece confiança, mas não confiança absoluta.

O monitoramento precisa considerar o comportamento.

Um atualizador que normalmente apenas verifica e instala atualizações não deveria, por exemplo, começar a:

• carregar DLLs inesperadas;
• iniciar processos incomuns;
• injetar código em svchost.exe;
• estabelecer túneis SSH;
• acessar credenciais;
• executar PowerShell de forma anômala.

2. Atualizações precisam ter integridade verificável

A CVE-2026-3502 é um excelente exemplo do problema.

Um mecanismo de atualização não deve simplesmente confiar no conteúdo que recebe.

É necessário verificar a integridade e autenticidade do código antes de executá-lo.

Esse princípio vale para qualquer software corporativo, não apenas para o TrueConf.

3. Servidores que distribuem software devem ser tratados como ativos críticos

Se um servidor hospeda instaladores, scripts, plugins ou atualizações utilizadas por dezenas ou milhares de endpoints, seu comprometimento pode gerar um efeito em cascata.

Por isso, esse tipo de servidor merece controles adicionais:

• autenticação forte;
• segmentação de rede;
• monitoramento de alterações de arquivos;
• controle de integridade;
• logs centralizados;
• EDR;
• backups;
• controle rigoroso de privilégios.

4. Assinatura digital é importante, mas não resolve tudo

A assinatura digital é uma camada essencial.

Mas segurança não pode depender de uma única camada.

O administrador também deve verificar:

• hash do arquivo;
• certificado utilizado;
• cadeia de confiança;
• origem do download;
• comportamento do processo;
• alterações inesperadas no diretório de instalação.

No caso investigado pela Kaspersky, a presença de instaladores adulterados tornou a integridade do canal de distribuição uma questão central.

5. EDR precisa enxergar o contexto

Um alerta informando que svchost.exe foi executado provavelmente não significa nada.

Um alerta informando que:

itcsrvup64.exe
        ↓
wtsapi32.dll
        ↓
svchost.exe
        ↓
injeção de código

já conta uma história completamente diferente.

A segurança moderna depende cada vez mais da capacidade de reconstruir cadeias de comportamento.

É por isso que telemetria de processos, DLLs carregadas, criação de serviços, PowerShell, rede e alterações de arquivos é tão importante.

O verdadeiro problema não é o malware. É a cadeia de confiança.

PhantomCore, PhantomGraph, HelloInjector, HelloProxy e HelloBackdoor são nomes diferentes para componentes diferentes.

Mas todos fazem parte de uma tendência que merece muito mais atenção:

atacantes estão procurando lugares onde as organizações naturalmente baixam a guarda.

Um servidor corporativo.

Um atualizador.

Um instalador.

Uma biblioteca.

Um processo legítimo.

Uma conta de armazenamento em nuvem.

Esses elementos não são necessariamente vulneráveis por natureza.

O problema acontece quando o atacante consegue inserir seu código dentro desses fluxos confiáveis.

É por isso que considero a campanha Head Mare particularmente interessante.

O maior dano potencial não está apenas no backdoor instalado no servidor.

Está na possibilidade de transformar o servidor comprometido em um ponto de distribuição para outras máquinas.

Nesse cenário, o ataque deixa de ser:

atacante → servidor

e passa a ser:

atacante → servidor → software legítimo → usuários → endpoints

A superfície de ataque aumenta dramaticamente.

Conclusão

As campanhas Head Mare e HelloNet mostram duas faces de um mesmo problema: a confiança em componentes legítimos pode ser explorada como vetor de ataque.

No caso do Head Mare, vulnerabilidades em servidores TrueConf permitiram que os invasores obtivessem privilégios elevados e substituíssem instaladores legítimos por versões infectadas com PhantomCore, além de utilizar o PhantomGraph durante a operação.

No caso do HelloNet, o mecanismo de atualização do ViPNet foi abusado para estabelecer persistência através de DLL sideloading, carregar o HelloInjector, realizar injeção em svchost.exe e executar outros componentes maliciosos, incluindo o HelloProxy e o HelloBackdoor.

Para administradores e equipes de segurança, a mensagem é bastante direta:

aplicar patches continua sendo indispensável, mas não é suficiente.

É necessário saber quem está executando o quê, de onde o código veio, quais processos estão interagindo entre si e se o comportamento observado é compatível com aquilo que o software deveria fazer.

Em um ambiente onde praticamente tudo depende de software de terceiros, atualizadores automáticos e componentes compartilhados, a pergunta mais importante já não é simplesmente:

“Este software é confiável?”

A pergunta mais importante é:

“Como posso provar que este software continua fazendo apenas aquilo que deveria fazer?”

Essa é uma das perguntas que definem a segurança de uma infraestrutura moderna.

Fontes

Kaspersky Securelist — Head Mare APT explora servidores TrueConf para distribuir PhantomCore e PhantomGraph.
Publicado em 11 de agosto de 2026. Kaspersky Securelist — Head Mare e TrueConf

TrueConf — Security Updates for June 2026.
Boletim oficial publicado em 18 de junho de 2026, com as versões corrigidas 5.3.9, 5.4.9 e 5.5.5. TrueConf — Security Updates for June 2026

TrueConf — Changelog oficial.
Registro das versões 5.3.9, 5.4.9 e 5.5.5. TrueConf — Changelog

Kaspersky Securelist — HelloNet.
Análise técnica da campanha, HelloInjector, HelloProxy e HelloBackdoor. Publicada em 16 de julho de 2026. Kaspersky Securelist — HelloNet

NIST National Vulnerability Database — CVE-2026-3502.
Registro oficial da vulnerabilidade do TrueConf Client. NIST NVD — CVE-2026-3502

CISA — Known Exploited Vulnerabilities Catalog.
Catálogo oficial de vulnerabilidades exploradas ativamente, incluindo CVE-2026-3502. CISA — Known Exploited Vulnerabilities Catalog

The Hacker News — TrueConf vulnerabilities exploited by Head Mare.
Cobertura independente da campanha divulgada em agosto de 2026. The Hacker News — Head Mare e TrueConf

Nota editorial

Este artigo foi deliberadamente escrito separando fatos confirmados, interpretações técnicas e atribuições de baixa confiança. Não tratei como fato qualquer ligação entre HelloNet e um grupo específico quando a evidência disponível não sustenta essa conclusão.