Webshell em WordPress: como achar e remover

Webshell é um arquivo que o invasor deixa no servidor para voltar quando quiser. Normalmente é um script PHP pequeno que recebe comandos pelo navegador: listar pastas, enviar arquivos, ler a senha do banco de dados, mandar spam. Em sites WordPress, é uma das formas mais comuns de manter acesso depois de uma invasão. O MITRE ATT&CK cataloga a técnica como persistência em componente de servidor.

O perigo está na discrição. O site continua no ar, o painel funciona, e o webshell fica quieto até ser usado. Este guia mostra onde procurar, como remover sem piorar a situação e o que fazer para ele não voltar.

Antes de mexer: três cuidados

1. Faça uma cópia do estado atual. Copie os arquivos e exporte o banco antes de apagar qualquer coisa. Se algo der errado, você tem para onde voltar, e a cópia ajuda a entender como o invasor entrou.
2. Troque as senhas depois, não antes. Se você trocar a senha com o webshell ainda lá, o invasor pode ler a nova no wp-config.php. Primeiro limpe, depois troque tudo.
3. Use outro computador, se puder. Se a senha vazou por um vírus no seu computador, trocar a senha nele não resolve.

Onde o webshell costuma ficar

Pasta de uploads

A pasta wp-content/uploads deveria ter só imagens, PDFs e outros arquivos de mídia. Qualquer arquivo .php ali é suspeito. Procure com: find wp-content/uploads -type f -name "*.php". Também vale procurar extensões disfarçadas, como .php5, .phtml, .phar ou imagem.jpg.php.

Plugins e temas

O invasor pode criar um arquivo novo dentro de um plugin ou alterar um arquivo existente, colando o código malicioso no começo ou no fim. Plugins abandonados e temas "nulled" (pirateados) são suspeitos de saída: muitos já vêm com backdoor.

Raiz e pastas do núcleo

Arquivos com nomes que imitam os do WordPress, como wp-confg.php, wp-login1.php ou class-wp-cache.php fora do lugar, merecem atenção. O núcleo do WordPress tem uma lista fixa de arquivos; qualquer coisa a mais em wp-admin ou wp-includes não deveria estar lá.

Banco de dados

Nem todo código malicioso fica em arquivo. Às vezes ele está numa opção da tabela wp_options, num widget ou num post, injetando script no site. Usuários administradores que ninguém reconhece, na tabela wp_users, também são sinal de invasão.

Como procurar

1. Compare o núcleo e os plugins com os originais

O WP-CLI tem dois comandos que comparam os arquivos instalados com as versões oficiais:

• wp core verify-checksums aponta arquivos do núcleo alterados ou que não deveriam existir.
• wp plugin verify-checksums --all faz o mesmo para os plugins do repositório oficial.

É o jeito mais rápido de achar arquivo mexido sem ler código.

2. Procure funções típicas de webshell

Webshells usam quase sempre as mesmas funções para executar comandos ou esconder código. Uma busca simples ajuda a separar o que olhar com calma:

• grep -rnE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(|assert\(" wp-content
• grep -rnE "shell_exec|passthru|system\(|proc_open|popen" wp-content

Atenção: plugins legítimos também usam algumas dessas funções. O resultado é uma lista de suspeitos, não uma lista de culpados. Desconfie mais de código ofuscado, linhas gigantes sem quebra e variáveis com nomes aleatórios.

3. Olhe as datas

Arquivos alterados perto da data em que o problema começou são bons candidatos. find . -name "*.php" -mtime -15 lista os PHP modificados nos últimos 15 dias. Invasores às vezes mudam a data do arquivo para disfarçar, então essa busca ajuda, mas não é prova.

4. Confira os logs de acesso

No log do servidor web, procure requisições POST para arquivos estranhos, principalmente dentro de uploads. Um arquivo que só recebe POST de um ou dois IPs, e que nenhuma página do site chama, é forte candidato a webshell.

Sinais de que existe um webshell

Antes mesmo de procurar arquivos, alguns sintomas costumam aparecer:

• A hospedagem avisa que a conta está mandando spam ou consumindo CPU demais.
• O Google mostra páginas estranhas do seu domínio, em outro idioma ou vendendo produtos que você não vende.
• Visitantes vindos do Google são redirecionados para outro site, mas quando você digita o endereço direto tudo parece normal.
• Aparecem administradores novos no painel ou plugins que ninguém instalou.
• Arquivos voltam a aparecer depois de apagados. É sinal de que existe outro acesso escondido recriando tudo.

Qualquer um desses sinais justifica a busca completa descrita acima. Se o servidor inteiro estiver comprometido, e não só o WordPress, veja também como saber se o servidor foi invadido.

Como remover com segurança

1. Coloque o site em manutenção para o invasor não usar o acesso enquanto você limpa.
2. Reinstale o núcleo do WordPress com wp core download --force --skip-content, que substitui os arquivos do núcleo pelos oficiais sem mexer em wp-content.
3. Reinstale plugins e temas a partir das fontes oficiais. Plugin que você não usa, apague. Tema pirateado, troque.
4. Remova os arquivos suspeitos que sobraram em uploads e nas pastas do conteúdo. Em vez de apagar direto, mova para uma pasta fora do site, para poder analisar e restaurar se tiver sido engano.
5. Limpe o banco: remova administradores desconhecidos e scripts injetados em opções, widgets e posts.
6. Troque todas as senhas e chaves: administradores do WordPress, banco de dados, FTP ou SFTP, painel da hospedagem e as chaves de segurança (salts) do wp-config.php. O gerador oficial cria chaves novas.
7. Atualize tudo e descubra por onde o invasor entrou. Se a falha continuar aberta, o webshell volta em dias.

Se o Google já marcou o site como perigoso, depois da limpeza peça a revisão no Search Console. O passo a passo completo está em site hackeado: o que fazer.

Como evitar que volte

• Bloqueie PHP na pasta de uploads. No Nginx, uma regra location que nega .php dentro de uploads; no Apache, um .htaccess na pasta. Assim, mesmo que um arquivo malicioso seja enviado, ele não executa.
• Desligue o editor de arquivos do painel com define('DISALLOW_FILE_EDIT', true); no wp-config.php.
• Mantenha núcleo, plugins e temas atualizados e apague o que não usa.
• Use verificação em duas etapas para todos os administradores.
• Faça backup fora do servidor e teste a restauração.
• Vigie arquivos novos e alterados. O que mais demora a ser percebido é o arquivo que aparece numa pasta onde não deveria haver código.

O guia oficial de endurecimento do WordPress detalha esses ajustes. Para o servidor como um todo, veja o checklist de segurança de VPS.

Vigilância contínua

Achar um webshell uma vez é trabalho de uma tarde. O difícil é perceber o próximo no dia em que ele aparece, e não meses depois. O Oven Sec roda dentro do servidor e, a cada 12 horas, varre arquivos novos e alterados por assinatura e comportamento, move o suspeito para uma quarentena reversível e avisa a sua equipe por e-mail, Telegram ou Slack. Se o problema é força bruta no login, leia também fail2ban é suficiente?.

Fontes

• MITRE ATT&CK, Server Software Component: Web Shell (T1505.003).
• WordPress Developer Resources, wp core verify-checksums e wp plugin verify-checksums.
• WordPress Developer Resources, Hardening WordPress.
• OWASP Cheat Sheet Series, File Upload Cheat Sheet.