GSocket em servidores Linux tornou-se parte de uma estratégia de invasão que preocupa administradores de sistemas: criminosos estão utilizando uma ferramenta legítima de código aberto para manter acesso remoto a máquinas comprometidas, mesmo depois que a vulnerabilidade responsável pela invasão inicial é corrigida.
Um relatório publicado pela Microsoft Security em 11 de novembro de 2026 revela um crescimento expressivo dessa atividade. Entre março e agosto de 2026, as detecções relacionadas ao uso malicioso do GSocket aumentaram 356,2% na telemetria do Microsoft Defender for Endpoint. Os ataques concentram-se principalmente em aplicações web e ambientes de hospedagem, incluindo servidores que utilizam PHP, cPanel e Apache.
O problema é particularmente preocupante porque a ferramenta permite estabelecer conexões remotas sem depender de um endereço IP público controlado pelo invasor ou de uma porta de entrada aberta no servidor. Com isso, mecanismos tradicionais de proteção podem deixar passar uma conexão que parece apenas mais uma comunicação de saída.
Para administradores Linux, a principal lição é que corrigir a vulnerabilidade explorada inicialmente não significa necessariamente recuperar o controle de um servidor. É preciso investigar possíveis mecanismos de persistência, conexões suspeitas e ferramentas de acesso remoto instaladas durante a invasão. Microsoft Security Blog+1
O que é o GSocket e como os invasores contornam firewalls
O GSocket (Global Socket) é um projeto legítimo de código aberto desenvolvido para permitir comunicação entre computadores por meio de uma infraestrutura de retransmissão. Sua proposta é facilitar conexões remotas mesmo quando os dispositivos estão atrás de roteadores, firewalls ou mecanismos de tradução de endereços de rede, conhecidos como NAT.
Em situações legítimas, essa tecnologia pode ser utilizada para administração remota, transferência de dados e comunicação entre sistemas que não possuem conectividade direta.
O problema começa quando invasores utilizam essa capacidade para transformar o GSocket em um canal de comando e controle (C2). Depois de explorar uma aplicação vulnerável e conseguir executar comandos no servidor, eles instalam a ferramenta e estabelecem um caminho de comunicação que pode continuar funcionando independentemente da falha original.
Essa independência é justamente o que torna a estratégia perigosa. Mesmo que o administrador atualize o WordPress, corrija uma aplicação PHP ou instale uma atualização de segurança no servidor web, o GSocket poderá continuar executando se não for identificado e removido.
Como a rede GSR torna o ataque invisível para bloqueios de IP
O mecanismo utilizado nessa estratégia é a Global Socket Relay Network (GSRN), uma rede de retransmissão que permite conectar dois computadores sem exigir uma conexão direta entre eles.
O funcionamento é diferente daquele observado em um backdoor tradicional.
Em uma conexão convencional de comando e controle, o malware geralmente precisa conhecer o endereço IP ou o domínio do servidor controlado pelo criminoso. O administrador pode tentar interromper a comunicação bloqueando esse destino no firewall.
Com o GSocket, a arquitetura muda.
O servidor comprometido inicia uma conexão de saída com a rede de retransmissão. O operador do ataque também estabelece sua própria conexão de saída com essa infraestrutura. A rede identifica os dois lados por meio de um segredo compartilhado e faz a intermediação da comunicação.
O resultado é uma sessão protegida por criptografia de ponta a ponta, sem exigir que o servidor comprometido mantenha uma porta de entrada aberta ou exponha seu endereço IP público ao operador.
Existem três características importantes nessa arquitetura:
- Conexões de saída nos dois extremos: tanto a máquina comprometida quanto o operador iniciam suas próprias conexões com a rede de retransmissão.
- Identificação por segredo compartilhado: a comunicação pode ser restabelecida sem que o invasor precise conhecer o endereço IP ou o nome do servidor comprometido.
- Criptografia de ponta a ponta: o canal de comunicação protege os dados transmitidos entre os participantes.
Isso significa que bloquear um endereço IP específico ou fechar uma porta de entrada pode não interromper o acesso clandestino. A comunicação utiliza uma infraestrutura compartilhada, e o tráfego de saída costuma ser permitido em muitas redes corporativas e ambientes de hospedagem.
Entretanto, isso não significa que o GSocket seja impossível de bloquear. A filtragem de tráfego de saída, o monitoramento de conexões e a restrição de acesso a serviços de retransmissão podem reduzir significativamente a superfície de ataque. Microsoft Security Blog+1
Dados da Microsoft mostram foco em hospedagem web e cPanel
A investigação da Microsoft utilizou a telemetria do Microsoft Defender for Endpoint para analisar incidentes relacionados ao abuso do GSocket em servidores Linux.
O levantamento identificou um crescimento de 356,2% nas detecções entre março e agosto de 2026, considerando março como referência. A evolução, entretanto, não foi linear: houve oscilações ao longo dos meses, indicando que a atividade não cresceu de maneira uniforme.
Aumento de 356,2%
Crescimento das detecções relacionadas ao GSocket entre março e agosto de 2026.
A distribuição dos incidentes também revela uma concentração importante em infraestruturas que disponibilizam aplicações e serviços pela internet.
| Ambiente identificado | Participação |
|---|---|
| Aplicações web e hospedagem | 87,1% |
| PHP e cPanel, dentro do grupo web | 63,9% |
| Apache, dentro do grupo web | 24,3% |
| Serviços de banco de dados | 7,7% |
| Acesso remoto SSH ou SFTP | 5,2% |
É importante interpretar corretamente esses números: os percentuais de PHP/cPanel e Apache representam subdivisões do grupo de aplicações web e hospedagem, não percentuais adicionais sobre todos os incidentes.
A concentração em ambientes PHP e cPanel chama a atenção de empresas de hospedagem compartilhada, provedores de serviços gerenciados e administradores responsáveis por múltiplos sites.
Servidores que hospedam aplicações antigas, plugins desatualizados e sistemas de gerenciamento de conteúdo podem oferecer oportunidades para a execução inicial de comandos. Uma vez dentro do ambiente, o invasor pode instalar mecanismos independentes de persistência.
A Microsoft também identificou organizações afetadas em diferentes setores:
- Educação e pesquisa: 30,7%.
- Tecnologia e telecomunicações: 22,9%.
- Indústria, manufatura e energia: 13,1%.
- Governo e administração pública: 10,5%.
Esses números representam a distribuição das organizações afetadas na amostra analisada. Não demonstram necessariamente uma seleção deliberada desses setores pelos criminosos. A exposição de sistemas web e a dificuldade de administrar infraestruturas distribuídas também ajudam a explicar a concentração observada. Microsoft Security Blog+1
Técnicas de persistência e a falha Dirty Frag no kernel Linux
A estratégia identificada pela Microsoft não depende apenas da instalação do GSocket. Os invasores também procuram esconder sua presença e garantir que o acesso remoto continue funcionando depois de reinicializações ou tentativas de limpeza realizadas pelos administradores.
O processo geralmente começa com a exploração de uma aplicação acessível pela internet. Após conseguir execução remota de código (RCE), o invasor utiliza comandos de shell para identificar a arquitetura do sistema, baixar o cliente apropriado do GSocket e preparar sua execução.
Entre as técnicas observadas estão o uso de diretórios temporários e caminhos ocultos, além da alteração dos nomes dos executáveis para dificultar sua identificação.
Como os invasores escondem o processo e mantêm a persistência
Um dos métodos mais interessantes é a utilização de nomes semelhantes aos de processos internos do Linux. Em vez de executar um programa com um nome claramente associado ao GSocket, os criminosos renomeiam o binário para imitar componentes legítimos do sistema operacional.
A Microsoft observou executáveis utilizando nomes como systemd-remount-d e defunct, além de processos apresentados com identificadores semelhantes aos de threads do kernel.
Essa técnica explora um comportamento comum durante auditorias: administradores frequentemente encontram dezenas de processos com nomes técnicos e podem não investigar imediatamente cada um deles.
Outro recurso é o armazenamento de arquivos em diretórios temporários, como /dev/shm, que utiliza memória compartilhada. Nos incidentes analisados, a Microsoft identificou arquivos escondidos em caminhos como:
/dev/shm/.gs-0/
/tmp/.gsn_oraO diretório /dev/shm merece atenção especial porque normalmente não é utilizado para armazenar executáveis permanentes. Entretanto, programas maliciosos podem aproveitar esse espaço para dificultar a identificação de arquivos durante inspeções convencionais.
A persistência também pode ser implementada por diferentes mecanismos:
- Cron: tarefas agendadas executam novamente o programa em intervalos definidos.
- Systemd: serviços são criados ou modificados para iniciar o executável automaticamente.
- Perfis do shell: arquivos de inicialização podem receber comandos que executam o programa durante novas sessões.
- Watchdogs: mecanismos de monitoramento reiniciam o processo caso ele seja encerrado.
- Cópias redundantes: arquivos adicionais permitem recuperar o acesso mesmo quando uma das instalações é removida.
A combinação dessas técnicas dificulta a resposta a incidentes. Encerrar um processo suspeito não garante que ele não será iniciado novamente, principalmente quando existem várias entradas de persistência.
A Microsoft também identificou tentativas de apagar arquivos temporários, alterar registros de data e hora dos executáveis e remover rastros da execução. Isso reforça a importância de preservar evidências antes de iniciar uma limpeza emergencial. Microsoft Security Blog
Escalonamento de privilégios com a CVE-2026-43284
Outro componente importante da campanha envolve a vulnerabilidade CVE-2026-43284, conhecida como Dirty Frag, que afeta o kernel Linux.
Diferentemente da exploração de uma aplicação web, essa falha não representa, por si só, uma vulnerabilidade de execução remota. Trata-se de uma vulnerabilidade de escalonamento local de privilégios (LPE).
Seu funcionamento está relacionado ao processamento de fragmentos de memória compartilhados durante operações envolvendo buffers de soquete e mecanismos criptográficos do kernel.
De maneira simplificada, determinados caminhos de processamento do subsistema de rede permitem que dados associados a páginas de memória compartilhadas sejam modificados sem a cópia privada necessária para preservar sua integridade. Isso pode proporcionar a um processo local sem privilégios elevados uma capacidade de escrita indevida no cache de páginas do sistema.
Com essa condição, um invasor que já conseguiu executar código no servidor pode tentar modificar arquivos sensíveis e obter privilégios de root.
O problema envolve principalmente o caminho XFRM/ESP, utilizado em funcionalidades relacionadas ao IPsec, e exige atenção às condições específicas de exploração e aos módulos presentes no sistema.
A Microsoft identificou tentativas de utilização da Dirty Frag depois que os invasores obtiveram execução no contexto da conta do serviço web. Portanto, a sequência representa duas etapas distintas: primeiro, a invasão da aplicação; depois, a tentativa de elevar os privilégios no kernel.
Essa distinção é fundamental para entender o risco. Um processo executado inicialmente como usuário do Apache ou PHP pode ter permissões limitadas. Se o escalonamento para root funcionar, entretanto, o invasor passa a ter controle muito mais amplo sobre o servidor.
A vulnerabilidade recebeu classificação Importante pela Red Hat, com pontuação CVSS 3.1 de 7,8 em sua avaliação. Existem correções disponibilizadas pelos fornecedores Linux, e a atualização deve considerar o pacote de kernel específico da distribuição utilizada. Red Hat Customer Portal+2
Como detectar e proteger seus servidores Linux contra o GSocket
A proteção contra ataques com GSocket exige uma abordagem que vá além da atualização de aplicações web. Administradores precisam investigar o comportamento dos processos, os mecanismos de inicialização automática e as conexões de saída.
A própria Microsoft recomenda combinar correções de segurança, auditoria de persistência, monitoramento de rede e endurecimento do ambiente Linux.
1. Audite processos e conexões de rede
Comece identificando processos suspeitos e verificando quais contas estão executando aplicações inesperadas.
Alguns comandos úteis incluem:
ps auxfPara procurar nomes associados às atividades identificadas:
ps aux | grep -Ei 'gsocket|gs-netcat|defunct|systemd-remount'Também é importante verificar conexões estabelecidas:
ss -tunapObserve especialmente processos iniciados por usuários como www-data, apache e nobody que estejam executando comandos ou estabelecendo conexões incompatíveis com sua função.
2. Verifique tarefas cron
Investigue tarefas agendadas de usuários e do sistema:
crontab -lls -la /etc/cron.*Não limite a inspeção à conta root. Aplicações comprometidas podem utilizar a conta responsável pelo serviço web para criar mecanismos de execução recorrente.
3. Inspecione os serviços systemd
Liste os serviços ativos e procure unidades desconhecidas:
systemctl list-units --type=serviceVerifique também os serviços habilitados para inicialização automática:
systemctl list-unit-files --type=serviceArquivos de unidades inesperados, nomes semelhantes aos componentes do sistema e referências a executáveis em diretórios temporários merecem investigação.
4. Examine os perfis de inicialização do shell
Confira arquivos como:
/etc/profile
/etc/bash.bashrc
~/.bashrc
~/.profileProcure comandos desconhecidos, execuções automáticas e referências a diretórios ocultos.
5. Implemente filtragem de tráfego de saída
Essa é uma das medidas mais importantes para reduzir o impacto da arquitetura GSocket.
Muitos servidores permitem conexões de saída sem restrições. Embora essa configuração facilite atualizações, integrações e comunicação entre aplicações, também permite que ferramentas maliciosas estabeleçam canais remotos.
Implemente uma política de egress filtering, permitindo somente os destinos e serviços necessários para o funcionamento da infraestrutura.
O monitoramento deve considerar conexões persistentes, processos que iniciam comunicações inesperadas e acessos a serviços de retransmissão. Bloquear apenas endereços IP conhecidos não é suficiente quando existe uma infraestrutura compartilhada de relay.
6. Atualize o kernel e as aplicações web
Instale as atualizações de segurança disponibilizadas pela distribuição Linux para corrigir a CVE-2026-43284.
Em distribuições baseadas em Debian e Ubuntu, por exemplo, a atualização dos pacotes pode ser realizada com:
sudo apt update
sudo apt upgradeEm sistemas baseados em RHEL, Rocky Linux, AlmaLinux e derivados, utilize o gerenciador de pacotes apropriado.
Depois, verifique se o kernel corrigido está efetivamente em execução. Dependendo da atualização, pode ser necessário reiniciar o servidor.
Também atualize PHP, Apache, cPanel, CMS, plugins e demais aplicações expostas à internet. Remova componentes sem utilização e restrinja funcionalidades de upload e painéis administrativos.
7. Trate servidores comprometidos como incidentes de segurança
Se houver evidências de execução maliciosa do GSocket, não considere a simples exclusão do executável uma solução definitiva.
É necessário identificar o ponto de entrada, remover os mecanismos de persistência, investigar possíveis alterações no sistema e verificar se houve escalonamento para root.
Quando o comprometimento de privilégios administrativos for confirmado, a alternativa mais segura pode ser reconstruir o servidor a partir de uma imagem confiável, restaurando somente dados previamente verificados.
Também é recomendável revisar credenciais, chaves SSH, tokens e senhas que possam ter sido expostos durante o incidente.
A Microsoft disponibiliza orientações de investigação e consultas de Advanced Hunting para identificar processos GSocket, downloads suspeitos, arquivos temporários e mecanismos de persistência. Essas informações podem ajudar equipes de segurança a transformar os indicadores observados em regras de monitoramento. Microsoft Security Blog+1
Conclusão
O abuso do GSocket em servidores Linux demonstra como ferramentas legítimas de código aberto podem ser transformadas em instrumentos de persistência por criminosos. A utilização de uma rede de retransmissão, conexões exclusivamente de saída e canais criptografados dificulta a identificação de atividades maliciosas por mecanismos tradicionais de proteção.
Os dados da Microsoft mostram que o problema merece atenção especial em ambientes de hospedagem, particularmente aqueles que utilizam PHP, cPanel e Apache. A possibilidade de combinar persistência com tentativas de escalonamento de privilégios por meio da Dirty Frag amplia ainda mais os riscos para servidores comprometidos.
A principal mudança necessária na estratégia de defesa é compreender que proteger uma infraestrutura Linux não significa apenas bloquear conexões de entrada. Monitorar o tráfego de saída, auditar processos e investigar mecanismos de persistência tornou-se igualmente importante.
Administradores devem tratar atualizações como parte de uma estratégia contínua de segurança, e não como garantia automática de que uma invasão foi encerrada.
