# Já estou comprometido? Sinais após o PHP2Shell

> Servidor comprometido? Sinais típicos após o PHP2Shell, primeiras verificações sem perder vestígios e o que fazer em caso de suspeita, passo a passo.

Fonte: https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/  
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:** se um servidor foi comprometido através do PHP2Shell não se lê numa única característica. Não existem indicadores de compromisso (IOCs) confirmados e publicados; a deteção assenta na análise de comportamento. Sinais típicos são ficheiros PHP novos, cronjobs desconhecidos e ligações invulgares. Preserve primeiro os registos desde 20 de outubro, antes de alterar o que quer que seja.

## Existem sinais inequívocos de um ataque PHP2Shell?

Não, e essa é a resposta honesta. Para muitas vulnerabilidades conhecidas, os fabricantes ou as empresas de segurança publicam vestígios concretos: nomes de ficheiros, somas de verificação, endereços IP. Para o PHP2Shell, esses indicadores de compromisso confirmados não existem até agora.

O que é conhecido: segundo notícias dos meios de comunicação, foi observada uma primeira tentativa de ataque a 17 de outubro, quatro dias antes dos patches de 21 de outubro. A Cloudflare comunicou outras tentativas. Segundo o BSI, não eram inicialmente conhecidos ataques bem-sucedidos em larga escala. Quem esteve acessível e desprotegido entre 17 de outubro e o seu próprio patch deve, por isso, verificar em vez de esperar.

Para a avaliação, conta sobretudo o período. Entre a primeira tentativa de ataque observada, a 17 de outubro, e os patches de 21 de outubro, não houve nenhuma atualização oficial. Todo o servidor PHP acessível publicamente foi, nesse período, potencialmente atacável. Durante quanto tempo o seu servidor esteve aberto para além disso depende de quando a atualização foi instalada e o PHP reiniciado. Quanto mais longo esse período e mais sensíveis os dados, por exemplo contas de clientes, encomendas ou candidaturas, mais rigorosa deve ser a verificação.

## Sinais típicos de que um servidor foi comprometido

Após uma execução de código bem-sucedida, os atacantes tentam normalmente fixar-se e usar o servidor. Daí resultam sinais que não são específicos do PHP2Shell, mas que contam em qualquer verificação de intrusão:

- **Ficheiros PHP novos ou alterados,** sobretudo em diretórios de uploads, de cache ou de imagens, onde normalmente não há ficheiros PHP.
- **Cronjobs desconhecidos** ou tarefas agendadas, por exemplo para o utilizador do servidor web.
- **Ligações de saída invulgares** para endereços desconhecidos, carga de rede elevada ou envio de correio que ninguém desencadeou.
- **Contas de administrador novas** no CMS ou na loja, palavras-passe alteradas, chaves SSH desconhecidas.
- **Carga anómala:** utilização permanentemente elevada do CPU por processos desconhecidos, muitas vezes um indício de mineração de criptomoeda.
- **Consequências visíveis:** redirecionamentos para páginas alheias, páginas de spam no índice do Google, avisos no navegador ou no Search Console.

Nenhum destes sinais prova, por si só, uma intrusão, e a sua ausência não prova o contrário. O decisivo é o quadro geral.

## Primeiras verificações, sem destruir vestígios

Antes de apagar ou reiniciar seja o que for: preserve os registos. A imprensa especializada aconselha a conservar os registos do servidor desde 20 de outubro. Copie os registos do servidor web, do PHP e do sistema para um local seguro fora do servidor.

Depois, ajudam verificações apenas de leitura. Os caminhos e os nomes de utilizador variam conforme o sistema:

```bash
# ficheiros PHP alterados desde 17/10
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls

# ficheiros PHP em diretórios de uploads (exemplo WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls

# cronjobs do utilizador do servidor web e de todo o sistema
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null

# ligações de rede ativas com processo
ss -tunp

# últimos inícios de sessão
last -n 30
```

Tenha em conta: os atacantes podem falsificar as marcas temporais dos ficheiros. Um resultado discreto do `find` não é, por isso, uma absolvição. Como analisar registos de forma dirigida, descreve-o [Analisar registos do servidor web após um ataque](https://phpsos.de/pt/ratgeber/logfiles-auswerten/); como encontrar backdoors, [Reconhecer e remover webshells](https://phpsos.de/pt/ratgeber/webshell-erkennen/).

> **Agir de imediato:**
> Se encontrar indícios concretos, por exemplo um ficheiro PHP desconhecido na pasta de uploads: não apague, não reinstale, não “repare depressa” a aplicação. Desligue ou isole o servidor da rede, preserve os registos e uma imagem do sistema e inicie um tratamento estruturado do incidente.

## O que não deve fazer

- **Apenas aplicar o patch e continuar.** Um patch não remove software malicioso já introduzido.
- **Apagar de imediato ficheiros suspeitos.** Com isso desaparecem as provas do que aconteceu e dos dados que podem estar afetados.
- **Reinstalar o servidor antes de preservar.** A causa fica por esclarecer, e uma backdoor na base de dados ou nas credenciais sobrevive à reinstalação.
- **Repor cópias de segurança antigas sem verificar.** Também uma cópia de segurança pode já conter a backdoor.
- **Esquecer as credenciais.** Após uma execução de código, as palavras-passe de bases de dados, chaves de API e outras credenciais de ficheiros de configuração podem ter saído. Renove-as depois da limpeza, e não antes, para que um atacante ainda ativo não leia logo as novas.

## Quando a suspeita se confirma

Então trata-se de mais do que técnica. Verifique com o seu encarregado da proteção de dados se é necessária uma notificação nos termos do RGPD; o prazo é de 72 horas a contar do conhecimento, pormenores em [Obrigação de notificação do RGPD](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/). Informe cedo o seu ciberseguro, se existir, e esclareça com um advogado se deve apresentar denúncia. Damos a esse respeito indicações gerais, e não aconselhamento jurídico.

## Como ajuda concretamente a PHP SOS?

Com a nossa [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/), tratamos uma suspeita de forma estruturada:

- **Preservar:** registos desde 20 de outubro e, quando necessário, uma imagem do sistema, antes de se alterar o que quer que seja.
- **Investigar:** análise de comportamento de ficheiros, processos, ligações e contas; se necessário, com valor probatório em tribunal através da [perícia forense informática](https://phpsos.de/pt/leistungen/it-forensik/).
- **Limpar e fechar:** remover backdoors, atualizar o PHP, renovar credenciais, reforçar o servidor.
- **Documentar,** até o incidente estar concluído e documentado, como base para a proteção de dados, a seguradora e a administração.


## Perguntas frequentes

**A atualização do PHP prova que o meu servidor está limpo?**  
Não. Um patch fecha a vulnerabilidade para o futuro, mas não remove software malicioso já introduzido. Também não diz nada sobre se alguém entrou antes do patch.

**Existe um analisador que reconheça com segurança ataques PHP2Shell?**  
Até agora, não. Não existem indicadores de compromisso (IOCs) confirmados e publicados que um analisador pudesse procurar de forma dirigida. Os analisadores de malware encontram webshells conhecidas, mas a avaliação de um servidor assenta na análise de comportamento.

**Tenho de comunicar uma suspeita à autoridade de proteção de dados?**  
Depende de poderem estar em causa dados pessoais. O RGPD prevê, para as violações de dados sujeitas a notificação, um prazo de 72 horas a contar do conhecimento. Esclareça-o cedo com o seu encarregado da proteção de dados ou com um advogado; não prestamos aconselhamento jurídico a esse respeito.

**Devo simplesmente reinstalar o servidor comprometido?**  
Não como primeiro passo. Preserve primeiro os registos e, se possível, uma imagem do sistema. Quem reinstala de imediato perde os vestígios que mostram o que aconteceu e que dados podem estar afetados.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [BSI: Gabinete 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/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)