Voltar para serviços

Resposta a Incidente: Sequestro de Sessão no DirectAdmin e Infecção em Massa de WordPress

Capa principal - Resposta a Incidente: Sequestro de Sessão no DirectAdmin e Infecção em Massa de WordPress

Resumo da Ocorrência

Fui acionado com urgência após múltiplos sites WordPress hospedados no mesmo servidor DirectAdmin sofrerem desfiguração (defacement), injeção de malware e criação indevida de administradores quase ao mesmo tempo.

A auditoria forense no nível do sistema operacional provou um cenário de ataque de dentro para fora. O servidor Linux e o kernel estavam limpos e isolados. O invasor operou com privilégios legítimos de administrador após roubar o token de sessão ativa (Cookie Hijacking) no computador pessoal do Gerente de Desenvolvimento. A máquina local havia sido infectada por um infostealer ao descompactar temas e plugins piratas (nulled) para testes locais. Com o cookie injetado no navegador, o atacante entrou no DirectAdmin sem precisar de login ou 2FA e fez o upload de webshells pelo próprio Gerenciador de Arquivos do painel.

Responsável técnico: Percio Andrade Castelo Branco (Infraestrutura Linux e Resposta a Incidentes).

Ambiente e Parâmetros Operacionais

Investigação Forense Passo a Passo

Com tantas contas comprometidas de uma vez, a equipe achou que o servidor havia sido invadido ou que o DirectAdmin tinha uma falha de dia zero. Fui direto aos logs para checar os fatos antes de qualquer conclusão.

1. Triagem nos Logs de Acesso do DirectAdmin

Abri os registros de autenticação em /var/log/directadmin/login.log e os comandos do sistema em /var/log/directadmin/system.log:

# Checando tentativas de login e autenticações aceitas
grep -E "result=(failed|successful)" /var/log/directadmin/login.log | tail -n 30

# Rastreando uso do gerenciador de arquivos no painel
grep "CMD_FILE_MANAGER" /var/log/directadmin/system.log

A linha do tempo mostrou o que realmente aconteceu:

  1. O atacante começou com requisições automatizadas de força bruta na API do DirectAdmin. Todas falharam.
  2. Pouco depois, surgiu um registro de login como admin marcado com status successful, mas sem qualquer envio prévio de formulário com usuário e senha. O painel apenas validou uma sessão que já existia.

2. Cruzamento de IPs e Identificação do Cookie Hijacking

Cruzei o ID da sessão com os registros de conexão de rede:

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

O primeiro acesso foi feito às 08:14 pelo IP físico do escritório da empresa, na máquina do Gerente de Desenvolvimento. Vinte e oito minutos depois, exatamente o mesmo token de sessão (da_sess_9a8f7c12) foi usado por um IP localizado na Coreia. O invasor colou o cookie no próprio navegador e navegou direto para o painel com permissão total, contornando login e 2FA.

3. Ação Pós-Acesso: Upload de Webshells

Com a sessão administrativa nas mãos, o invasor usou o próprio File Manager do DirectAdmin para subir arquivos maliciosos nos sites:

# Localizando arquivos PHP criados recentemente nas pastas públicas
find /home/*/public_html/ -type f -name "*.php" -mtime -3 -ls

# Monitorando chamadas para a webshell nos logs do Apache
grep "POST /wp-content/uploads/cat.php" /var/log/httpd/domains/*.log

Ele subiu um arquivo chamado cat.php na pasta de uploads e disparou requisições POST para puxar mais scripts de um repositório no GitHub. A partir dessa base, infectou os arquivos de outros clientes no mesmo servidor.

Causa Raiz Confirmada (RCA)

O sistema operacional e o kernel Linux ficaram intactos. Não houve rootkit, invasão de SSH ou quebra de permissão root. O vetor veio da ponta do usuário:

  1. Arquivos não oficiais: Para agilizar testes, o Gerente de Desenvolvimento baixou temas e plugins WordPress piratas (nulled) em sites suspeitos.
  2. Infecção por Infostealer: O arquivo compactado continha um malware ladrão de dados. A empresa não utilizava antivírus padronizado nas máquinas (quando questionei certa vez quem protegia as estações locais, a resposta de um analista foi literalmente: "Deus"). Mais tarde chegaram a testar o Bitdefender gratuito, mas na ocasião o endpoint estava desprotegido.
  3. Roubo do banco de cookies: O malware leu os arquivos SQLite do Chrome e do Firefox, copiou as sessões ativas e enviou o cookie do DirectAdmin para o servidor de comando do atacante.

Ações Técnicas de Contenção que Executei

1. Expurgamento Imediato de Todas as Sessões

Derrubei todos os acessos abertos no servidor para cortar a conexão do invasor no mesmo minuto:

# Apagando os arquivos de sessão do DirectAdmin em disco
rm -rf /usr/local/directadmin/data/sessions/*

# Reiniciando o serviço para forçar o encerramento de conexões
systemctl restart directadmin

Orientei a equipe a limpar os navegadores e forcei a redefinição de todas as senhas administrativas.

2. Script de Auditoria em Usuários do DirectAdmin

Criei e rodei um script em Bash para checar se o atacante havia deixado contas secundárias ou revendedores ocultos:

#!/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 "=== FIM DA AUDITORIA ==="

O resultado confirmou que nenhuma conta backdoor havia sido criada.

3. Varredura e Quarentena com Imunify360 e Wordfence

Combinei a proteção do servidor com o scanner CLI do Wordfence Premium para isolar as infecções:

# Varredura completa do servidor com o agente do Imunify360
imunify360-agent malware user scan --all

# Varredura recursiva nos document roots dos clientes via Wordfence CLI
for dir in /home/*/public_html; do
    echo "Checando $dir..."
    wordfence scan --path="$dir" --output-path="/root/audit_$(basename $(dirname $dir)).log"
done

Isolei o script cat.php e todos os arquivos ofuscados em quarentena. Entreguei o relatório com a lista exata de caminhos alterados para a equipe de desenvolvimento realizar a limpeza definitiva do código dos clientes.

Mudanças Práticas Implementadas

Falar sobre este serviço

Quer aplicar esse modelo de resposta a incidente no seu ambiente com execução técnica orientada por evidência?

Abrir formulário LinkedIn