Em resumo: reconhece uma webshell por ficheiros PHP novos ou alterados em locais pouco habituais, por processos estranhos do utilizador do servidor web e por ligações invulgares. Guarde os vestígios antes de apagar o que quer que seja e restaure o código a partir de uma fonte limpa. Um patch, por si só, não remove uma backdoor.
Porque é que as webshells são um tema após o PHP2Shell
As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 no próprio PHP permitem a execução remota de código malicioso sem autenticação. Um objetivo óbvio após um ataque bem-sucedido é uma backdoor persistente, ou seja, uma webshell. Permanece mesmo depois de o PHP ter sido entretanto atualizado.
Segundo notícias dos meios de comunicação, uma primeira tentativa de ataque foi observada já a 17/10/2026; os patches seguiram-se a 21/10. Quem esteve vulnerável neste período deve verificar de forma orientada. Até agora não há Indicators of Compromise confirmados publicados. A procura assenta, por isso, em anomalias de comportamento, e não numa lista já pronta.
Se encontrar uma webshell num servidor com dados de clientes: não apague nada à pressa. Primeiro guarde as provas, depois isole o servidor e planeie o tratamento seguinte.
Como reconhecer uma webshell: verificar ficheiros
A maioria das webshells são ficheiros PHP na pasta web. Chamam a atenção ficheiros criados ou alterados depois de 17/10, ficheiros PHP em pastas de uploads e de cache e ficheiros com código ofuscado. Os comandos seguintes não alteram nada, apenas listam:
# Ficheiros PHP alterados desde 17/10/2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# Ficheiros PHP em pastas de uploads, cache ou tmp
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Ofuscação típica: eval combinado com descodificação
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# Linhas invulgarmente longas indicam muitas vezes código compactado
grep -rlE ".{3000,}" /var/www --include="*.php"
Os resultados são indícios, não provas. Alguns plugins usam legitimamente código codificado. Compare os ficheiros suspeitos com o pacote original do fabricante. O mais fiável é uma comparação com somas de verificação ou com um sistema de controlo de versões como o Git:
# Desvios em relação ao último estado conhecido no repositório Git
git -C /var/www/projekt status --porcelain
Uma marca temporal pode ser falsificada. Por isso, não confie apenas na data de alteração de um ficheiro.
Que características tornam um ficheiro suspeito
| Característica | Porque chama a atenção |
|---|---|
| Ficheiro PHP numa pasta de uploads ou de imagens | Ali só deveriam estar ficheiros multimédia |
Extensão dupla como .jpg.php ou .php.png |
Disfarce de ficheiro inofensivo |
| Linhas muito longas, sem quebra | Típico de código compactado ou cifrado |
| Nome de ficheiro semelhante a um ficheiro do núcleo, mas ausente do pacote original | Camuflagem num ambiente conhecido |
| O proprietário ou as permissões divergem dos ficheiros vizinhos | O ficheiro foi criado por outra via |
Quantas mais características coincidirem, maior é a probabilidade de se tratar de um achado. Abra os ficheiros suspeitos apenas como texto, nunca através do navegador, porque abri-los através do site executaria o código.
Verificar processos, ligações e tarefas cron
Uma webshell ativa deixa muitas vezes vestígios fora do sistema de ficheiros. O utilizador do servidor web, por exemplo www-data, apache ou nginx, normalmente não inicia shells, ferramentas de rede nem compiladores.
# Processos dos utilizadores típicos do servidor web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Ligações de rede abertas com o processo associado
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# Tarefas agendadas do utilizador do servidor web
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Chamam a atenção ligações de saída permanentes para destinos desconhecidos, processos com nomes crípticos e tarefas cron que descarregam ficheiros da Internet. Verifique também nos registos de acesso os pedidos a ficheiros que antes não existiam. Como fazê-lo, descreve-o o guia Analisar os registos do servidor web após um ataque.
Guardar vestígios antes de remover
Quem apaga primeiro perde a resposta às perguntas mais importantes: como entrou o atacante, o que viu, que dados estão afetados? Precisa destas respostas para uma eventual notificação RGPD, para as seguradoras e para decidir se outros sistemas estão em risco.
Sequência sensata:
- Documentar o estado: lista de processos, ligações de rede, utilizadores com sessão iniciada.
- Copiar os ficheiros suspeitos e os registos com soma de verificação, sem os abrir nem executar.
- Se possível, criar uma imagem do sistema ou um snapshot da máquina virtual.
- Retirar o servidor da rede ou restringir fortemente o acesso.
Em sistemas com dados sensíveis ou possível litígio, a salvaguarda deve ser feita de forma forense correta. Encontra antecedentes em Forense informática após um ataque a um servidor web.
Remover webshells corretamente
Apagar um único ficheiro raramente é o fim. Os atacantes criam com frequência vários acessos: outros ficheiros em locais escondidos, entradas em ficheiros de configuração como .htaccess ou .user.ini, novas contas de administrador na aplicação ou tarefas cron. Uma limpeza fiável segue estes passos:
- Levar o PHP a uma versão corrigida (8.5.12, 8.4.27, 8.3.36, 8.2.35 ou backport confirmado) e reiniciar todos os processos PHP.
- Reinstalar o código da aplicação a partir de uma fonte limpa, em vez de reparar ficheiros isolados.
- Aproveitar apenas conteúdos verificados, como uploads e base de dados, e procurar aí de forma orientada código introduzido.
- Mudar todas as credenciais: base de dados, SSH, FTP, contas de administrador, chaves de API.
- Limitar ao mínimo necessário as permissões de escrita do servidor web e impedir a execução de PHP nas pastas de uploads.
Para o WordPress existem esconderijos típicos próprios, que o guia Encontrar backdoors no WordPress descreve. Depois, o site deve ser monitorizado mais de perto durante algum tempo, para detetar cedo um novo acesso.
Como ajuda concretamente a PHP SOS?
- Guardamos registos, ficheiros e estado do sistema de forma rastreável, antes de alterar o que quer que seja.
- Procuramos backdoors em ficheiros, base de dados, tarefas cron e configuração e classificamos os achados.
- Reinstalamos a aplicação a partir de uma fonte limpa, mudamos os acessos e reforçamos a segurança do servidor.
- Documentamos o incidente até estar concluído, como base para notificações e seguradoras.
O procedimento de uma limpeza está descrito no serviço Mandar remover malware e webshells.
Perguntas frequentes
O que é uma webshell?
Uma webshell é um ficheiro introduzido, geralmente em PHP, através do qual os atacantes podem controlar o servidor remotamente. Disfarça-se muitas vezes de ficheiro inofensivo com um nome discreto e continua ativa mesmo depois de uma atualização.
Um antivírus encontra todas as webshells?
Não. Os scanners reconhecem padrões conhecidos; variantes novas ou muito ofuscadas passam despercebidas. Para o PHP2Shell não existem, além disso, Indicators of Compromise publicados e confirmados, por isso a análise de comportamento é mais importante do que uma lista de assinaturas.
Basta apagar o ficheiro encontrado?
Geralmente não. Os atacantes criam muitas vezes vários acessos, por exemplo outros ficheiros, tarefas cron ou novas contas de administrador. Sem análise da causa e sem mudar todas as credenciais, é provável um novo acesso.
Tenho de comunicar alguma coisa depois de encontrar uma webshell?
Se dados pessoais puderem estar afetados, pode existir uma obrigação de notificação nos termos do RGPD, em regra no prazo de 72 horas. Esclareça-o com o seu encarregado da proteção de dados ou com um advogado; isto não constitui aconselhamento jurídico.