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:
# 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; como encontrar backdoors, Reconhecer e remover webshells.
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. 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, 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.
- 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.