# Detetar e remover uma webshell

> Detetar webshell após o PHP2Shell: encontrar ficheiros PHP, processos e ligações suspeitos, guardar vestígios e mandar remover corretamente as backdoors.

Fonte: https://phpsos.de/pt/ratgeber/webshell-erkennen/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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.

> **Agir de imediato:**
> 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:

```bash
# 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:

```bash
# 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.

```bash
# 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](https://phpsos.de/pt/ratgeber/logfiles-auswerten/).

## 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:

1. Documentar o estado: lista de processos, ligações de rede, utilizadores com sessão iniciada.
2. Copiar os ficheiros suspeitos e os registos com soma de verificação, sem os abrir nem executar.
3. Se possível, criar uma imagem do sistema ou um snapshot da máquina virtual.
4. 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](https://phpsos.de/pt/leistungen/it-forensik/).

## 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](https://phpsos.de/pt/ratgeber/backdoor-wordpress-finden/) 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](https://phpsos.de/pt/leistungen/malware-entfernung/).


## 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.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI (Serviço Federal Alemão para a Segurança da Informação)](https://www.bsi.bund.de/)
- [RGPD, art. 33.º: notificação à autoridade de controlo](https://dsgvo-gesetz.de/art-33-dsgvo/)