Estudo de caso (RCA): sequestro de sessão no DirectAdmin e infecção em massa de WordPress

Sequestro de sessão administrativa e infecção em massa de WordPress via endpoint comprometido#

Quando vários sites corporativos em WordPress hospedados no mesmo servidor caem com defacement e injeção de malware ao mesmo tempo, a primeira reação de quem está no plantão costuma ser o pânico de achar que o Linux foi invadido ou que o painel sofreu um exploit de dia zero.

Neste estudo de caso de análise de causa raiz (RCA), relato um incidente que atendi na linha de frente da infraestrutura. A perícia técnica comprovou algo bem diferente de uma invasão de perímetro: o servidor Linux e o DirectAdmin estavam limpos e atualizados. O ataque veio de dentro para fora. O invasor operou com a conta legítima de administrador usando uma sessão ativa roubada (Cookie Hijacking) no computador pessoal do Gerente de Desenvolvimento da empresa.

Para cumprir as normas da LGPD e preservar o sigilo das empresas envolvidas, todos os nomes, domínios e IPs foram anonimizados.

1. O incidente e o chamado de emergência#

O chamado chegou no começo do expediente: dezenas de sites de clientes estavam saindo do ar com páginas desfiguradas, usuários administradores desconhecidos criados no WordPress e arquivos PHP estranhos espalhados na pasta /wp-content/uploads/.

Quando um único site WordPress é infectado, a culpa quase sempre é de um plugin desatualizado ou de uma senha fraca de FTP. Mas quando dezenas de contas isoladas no mesmo servidor são adulteradas nos mesmos minutos, o problema costuma ser mais em cima. Assumi o caso como root para entender se a blindagem do servidor tinha cedido ou se alguém com chave mestra havia entrado pela porta da frente.

2. A investigação forense no terminal#

Em vez de especular, fui direto aos arquivos de log brutos do DirectAdmin e do sistema operacional.

2.1. O que os logs do DirectAdmin registraram#

Abri o arquivo /var/log/directadmin/login.log:

# Filtrando o historico recente de tentativas de autenticacao
grep -E "result=(failed|successful)" /var/log/directadmin/login.log | tail -n 40

A cronologia dos eventos chamou atenção na hora:

1. O atacante começou fazendo testes automatizados de força bruta contra a API do DirectAdmin. Todas as requisições deram result=failed.
2. Logo depois dessas tentativas falhas, apareceu um login com o usuário admin registrado com status result=successful.

A questão era: não existia nenhum registro prévio de requisição POST enviando usuário e senha para o formulário web. O painel apenas aceitou uma conexão com base em um identificador de sessão que já existia.

2.2. O cruzamento de IPs e o cookie roubado#

Cruzei o ID dessa sessão com os registros em /var/log/directadmin/system.log:

# Rastreando o token de sessao nos logs do painel
grep "da_sess_9a8f7c12" /var/log/directadmin/login.log /var/log/directadmin/system.log

O log entregou a sequência exata:

2026:10:01-08:14:10: admin (192.0.2.45) login: successful session=da_sess_9a8f7c12
2026:10:01-08:42:19: admin (198.51.100.77) session validated: da_sess_9a8f7c12

O primeiro login, às 08:14, veio do IP físico da rede do escritório da empresa, na estação de trabalho do Gerente de Desenvolvimento. Vinte e oito minutos depois, esse mesmo token de sessão (da_sess_9a8f7c12) foi apresentado por um IP da Coreia.

O invasor não precisou adivinhar senha nem quebrar o segundo fator de autenticação (2FA). Ele injetou o cookie ativo no próprio navegador e entrou direto no painel com privilégios de administrador.

3. A movimentação pós-acesso: webshells via File Manager#

Com o painel aberto como admin, o invasor não precisou de SSH nem de FTP. Ele usou o próprio Gerenciador de Arquivos nativo do DirectAdmin para subir arquivos:

2026:10:01-08:44:03: admin (198.51.100.77) executed CMD_FILE_MANAGER : action=upload path=/domains/cliente-alfa.com.br/public_html/wp-content/uploads file=cat.php

Ele enviou um arquivo chamado cat.php para a pasta de uploads de uma das contas. Em seguida, acionou o script via HTTP, como registrei nos logs do Apache:

grep "cat.php" /var/log/httpd/domains/*.log

198.51.100.77 - - [01/Oct/2026:08:45:12 +0000] "POST /wp-content/uploads/cat.php HTTP/1.1" 200 6512 "-" "Mozilla/5.0"

A webshell disparava chamadas PHP com curl para baixar outros códigos maliciosos hospedados no GitHub, espalhando arquivos ofuscados para outras pastas de clientes no mesmo host.

Um alívio técnico importante durante a perícia: o atacante não conseguiu escalar privilégios para root nem comprometeu o kernel do Linux. A estrutura do servidor e os limites de processos continuavam intactos. O estrago ficou nos arquivos dos clientes porque o invasor usou a própria interface web do DirectAdmin para espalhar os arquivos.

4. Análise de causa raiz (RCA)#

Para descobrir como o cookie de sessão do Gerente de Desenvolvimento foi parar na mão do atacante, conversei com ele e com o Gerente de Infraestrutura para entender a rotina da máquina local.

A origem do problema foi comportamental:

1. Uso de scripts piratas (nulled): Para testar protótipos de clientes em ambiente local, o gestor de desenvolvimento costumava baixar temas e plugins WordPress piratas em fóruns e sites duvidosos.
2. Infecção por Infostealer no Windows: Um dos arquivos ZIP continha um malware ladrão de dados.
3. Extração do banco de cookies: O infostealer leu o banco SQLite do Chrome e do Firefox, empacotou as credenciais salvas e os cookies de sessão abertos e enviou tudo para o servidor de comando do atacante.

Aqui vale um detalhe que resume a cultura de segurança do ambiente: a empresa simplesmente não usava antivírus nas máquinas desde que entrei e acho que continuou assim até eu sair (nem soluções gratuitas eram padronizadas). Certa vez, cheguei a perguntar na sala quem protegia os computadores do escritório e a resposta de um analista foi direta: "Deus. É Deus quem protege os computadores aqui". Mais tarde, se não me falha a memória, chegaram a colocar o Bitdefender gratuito em algumas estações. Mas com essa postura, quando o ataque bateu de dentro para fora, ficou fácil entender por onde a porteira estava escancarada.

5. As ações práticas de contenção que executei#

Como responsável pela infraestrutura e resposta ao incidente, executei três passos para estancar o ataque e limpar o ambiente:

1. Expurgamento imediato de sessões ativas#

A primeira medida foi derrubar todos os acessos abertos no DirectAdmin para cortar a conexão do invasor:

# Apagando fisicamente os arquivos de sessao do DirectAdmin
rm -rf /usr/local/directadmin/data/sessions/*

# Reiniciando o servico para forcar o encerramento dos sockets abertos
systemctl restart directadmin

Em seguida, orientei a equipe interna a limpar o histórico de cookies e forcei a troca de senhas de todos os administradores.

2. Script em Bash para auditar privilégios#

Para garantir que o atacante não tinha criado contas secundárias ou revendedores de backdoor no painel, escrevi este script para inspecionar os arquivos de configuração:

#!/usr/bin/env bash
echo "=== AUDITANDO USUARIOS NO DIRECTADMIN ==="
for userconf in /usr/local/directadmin/data/users/*/user.conf; do
    user=$(dirname "$userconf" | xargs basename)
    usertype=$(grep -E "^usertype=" "$userconf" | cut -d= -f2)
    creator=$(grep -E "^creator=" "$userconf" | cut -d= -f2)
    suspended=$(grep -E "^suspended=" "$userconf" | cut -d= -f2)
    if [ "$usertype" = "admin" ] || [ "$usertype" = "reseller" ]; then
        echo "[PRIVILEGIO] Usuario: $user | Tipo: $usertype | Criador: $creator | Suspenso: $suspended"
    fi
done
echo "=== AUDITORIA FINALIZADA ==="

O script confirmou que não havia nenhum usuário extra criado no painel.

3. Caça a webshells e quarentena em massa#

Para limpar as pastas dos clientes, rodei duas verificações combinadas:

• No nível do servidor, o agente do Imunify360 para varrer todos os usuários;
• No nível do WordPress, o CLI do Wordfence Premium para conferir a integridade dos arquivos das contas:

# Varredura completa com Imunify360
imunify360-agent malware user scan --all

# Varredura das pastas publicas com o CLI do Wordfence
for dir in /home/*/public_html; do
    wordfence scan --path="$dir" --output-path="/root/relatorio_$(basename $(dirname $dir)).log"
done

Isolei o cat.php e todos os arquivos ofuscados em quarentena. Montei a lista detalhada com os caminhos dos arquivos adulterados e passei para o time de desenvolvimento fazer a desinfecção final do código dos clientes.

6. Novas regras de segurança implementadas#

Depois de apresentar o laudo técnico da perícia, definimos mudanças obrigatórias na operação:

1. EDR Corporativo: Substituição de antivírus comuns em computadores de desenvolvimento por soluções profissionais de monitoramento de endpoint, como o CrowdStrike Falcon.
2. Painel só pela VPN: Fechamos a porta 2222 do DirectAdmin no firewall para acessos externos. A partir desse dia, a gestão do servidor só pode ser feita conectada à VPN interna da empresa com 2FA. Se outro cookie for roubado fora do escritório, o atacante nem consegue abrir a página.
3. Cofres de Senhas: Proibição de reaproveitar senhas e obrigatoriedade de gerenciador de senhas com credenciais fortes e individuais.
4. Isolamento de Testes: Proibição de baixar plugins piratas ou códigos não homologados em máquinas que tenham acesso aos servidores de produção.

Conclusão#

Esse caso me marcou porque mostra o limite da infraestrutura isolada. Eu posso fechar portas, ajustar permissões de kernel e manter o Linux 100% atualizado, mas se quem tem a chave de administrador baixa arquivo pirata no próprio computador, a porta da frente é aberta do mesmo jeito. A segurança de uma empresa depende tanto do servidor quanto da máquina de quem opera nele.

Veja também

Cibersegurança Caça a bugs pé no barro: usando o grep para triagem rápida de segurança em javascript

WordPress WordPress Admin Bloqueado: Diagnóstico Forense, Desbloqueio e Recuperação de Acesso via WP-CLI e MySQL

WordPress Auditoria forense em WordPress: como identificar usuários maliciosos via terminal (WP-CLI e logs)

Este post está licenciado sob CC BY-NC.