Backdoor GSocket em servidores web Linux: verifique hosts PHP, cPanel e Apache quanto a comprometimento

O que aconteceu

Em 11 de novembro de 2026, a Microsoft publicou uma pesquisa sobre vários grupos distintos de atacantes que instalam o GSocket em servidores Linux comprometidos. A BleepingComputer noticiou o caso em 12 de novembro de 2026. O GSocket é uma ferramenta legítima de acesso remoto de código aberto. Depois que ela é executada em um servidor, tanto o servidor quanto o atacante fazem conexões de saída para um serviço público de retransmissão, a Global Socket Relay Network. O serviço então une as duas partes em uma sessão criptografada. O servidor não precisa de porta aberta nem de endereço IP público. Os atacantes não mantêm infraestrutura própria, portanto não há endereço IP ou domínio do atacante para bloquear.

Isso não é uma vulnerabilidade no GSocket. Os atacantes primeiro invadem uma aplicação web exposta à internet e depois instalam o GSocket para manter o acesso. Como o GSocket roda separadamente da aplicação, aplicar a correção na aplicação não o remove. A Microsoft afirma que as detecções relacionadas ao GSocket em sua telemetria aumentaram 356,2% entre março e agosto de 2026.

A Microsoft descreve os ataques da seguinte forma:

• Os atacantes exploram uma aplicação web e usam curl para baixar e executar um script de instalação.
• O script coloca o cliente GSocket em caminhos graváveis ou baseados em memória, como /dev/shm.
• O processo é disfarçado com nomes que parecem threads do kernel, por exemplo [kaluad], ou com nomes semelhantes aos do sistema, como systemd-remount-d e /usr/bin/defunct.
• A persistência é configurada por meio de tarefas cron, serviços systemd, arquivos de inicialização do shell, watchdogs e cópias extras. Os arquivos de preparação são então apagados e os carimbos de data dos arquivos são retroagidos.
• Em alguns casos, os atacantes tentaram obter root por meio da falha no kernel Linux CVE-2026-43284, conhecida como "Dirty Frag".

Quem é afetado

Servidores Linux que executam aplicações web expostas à internet e que foram comprometidas em algum momento. Nos dados da Microsoft, 87,1% dos incidentes envolveram aplicações web e hospedagem. Dentro desse grupo, aplicações web PHP e hospedagem cPanel somaram 63,9%, e Apache, 24,3%. A Microsoft também lista alertas para shells iniciados a partir de aplicações web Java e Node.js. Servidores em que uma falha em aplicação web foi encontrada e corrigida recentemente merecem atenção especial, porque os atacantes podem ter entrado antes da correção.

Servidores cujas aplicações web nunca foram comprometidas não são afetados. O GSocket instalado intencionalmente pela sua própria equipe não é, por si só, um sinal de comprometimento.

O que fazer agora

1. Verifique todo servidor web Linux exposto à internet seguindo os passos da próxima seção. Comece pelos servidores em que uma falha em aplicação web, CMS, plugin ou painel de hospedagem foi corrigida nos últimos meses.
2. Se encontrar o GSocket, trate o servidor como comprometido. Interrompa o processo. Em seguida, remova o binário, todas as cópias e todas as entradas de inicialização automática: cron, unidades systemd, arquivos de inicialização do shell e scripts de watchdog. A Microsoft observa que a persistência costuma ser em camadas, por isso encerrar apenas o processo não remove o acesso. Se os atacantes possivelmente obtiveram root, por exemplo por meio do CVE-2026-43284, a opção mais segura é reconstruir o servidor a partir de uma imagem limpa ou de um backup feito antes do comprometimento.
3. Troque as credenciais de um servidor afetado: senhas de banco de dados, segredos de aplicação, chaves de API e chaves SSH. Verifique também o authorized_keys em busca de entradas desconhecidas.
4. Encontre e feche a porta de entrada. Atualize aplicações web, plataformas CMS, plugins e servidores de aplicação. Remova componentes que você não usa e restrinja os caminhos de upload de arquivos e de administração.
5. Corrija o kernel contra o CVE-2026-43284 ("Dirty Frag") com a atualização de kernel da sua distribuição e reinicie para o novo kernel.
6. Restrinja o tráfego de saída. Sempre que possível, bloqueie conexões de saída por padrão e permita apenas os destinos de que cada servidor precisa. O tráfego do GSocket é somente de saída, então regras de firewall de entrada não o detectam.
7. Reforce os diretórios temporários. Quando for prático, monte /tmp e /dev/shm com noexec.
8. Verifique depois se o servidor não se conecta mais à retransmissão do GSocket nem aos domínios listados abaixo.

Como verificar se você é afetado

Execute estas verificações como root. Um resultado positivo não é prova por si só, mas deve ser investigado.

Arquivos e caminhos citados pela Microsoft:

ls -la /dev/shm/.gs-* /tmp/.gsn_ora /tmp/systemd-remount-d /usr/bin/systemd-remount-d /usr/bin/defunct 2>/dev/null
find / -xdev \( -name 'gs-netcat*' -o -name 'defunct.service' -o -name 'defunct' -o -name 'systemd-remount-d' \) 2>/dev/null

Processos em execução:

ps -eo pid,ppid,user,args | grep -Ei 'gs-netcat|gsocket|defunct|remount-d' | grep -v grep

Threads reais do kernel não têm arquivo executável. Se um processo com nome entre colchetes, como [kaluad], aponta para um arquivo, ele é suspeito:

for p in /proc/[0-9]*; do n=$(cat $p/cmdline 2>/dev/null | tr '\0' ' '); case "$n" in \[*) e=$(readlink $p/exe 2>/dev/null); [ -n "$e" ] && echo "${p#/proc/} $n -> $e";; esac; done

Persistência:

for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.* /var/spool/cron* 2>/dev/null
systemctl list-unit-files --type=service | grep -Ei 'defunct|remount'
grep -sEl 'gs-netcat|gsocket|defunct|GS_' /etc/profile /etc/profile.d/* /etc/bash.bashrc /root/.bashrc /root/.profile /home/*/.bashrc /home/*/.profile

Verifique com atenção as unidades systemd com nomes plausíveis que você não criou. Confira os diretórios pessoais de contas de serviços web, como www-data, apache e nobody, e de usuários do cPanel.

Hashes conhecidos de arquivos (SHA-256) divulgados pela Microsoft:

• d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa
• f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5
• 55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f
• 12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c

Rede e logs: Pesquise nos logs de DNS, proxy e firewall por gsocket.io, cdn.gsocket.io e gsgg.b-cdn.net. Esses domínios são usados para baixar a ferramenta. Pesquise também no histórico do shell e nos logs do servidor web por comandos que busquem gsocket.io/y ou gsocket.io/install.sh com curl. Procure shells iniciados pelo servidor web ou por processos PHP. Use ss -tnp para verificar quais processos mantêm conexões de saída e investigue aquelas que você não consegue explicar. Lembre-se de que os atacantes apagam arquivos de preparação e o histórico de comandos, então a ausência de rastros em um lugar não prova que o servidor está limpo.

Fontes

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://www.bleepingcomputer.com/news/security/hackers-plant-gsocket-on-linux-servers-for-persistent-access/