Em resumo: se o seu site foi pirateado, esta lista de verificação ajuda a não esquecer nada: primeiro conter e guardar provas, depois encontrar a causa e limpar, a seguir renovar todos os acessos, verificar as obrigações e concluir o incidente com documentação. A sequência é importante, pois quem apaga primeiro perde vestígios, e quem apenas limpa sem fechar a vulnerabilidade volta a ser atacado.
Para que serve esta lista de verificação quando o site foi pirateado
A lista de verificação dirige-se à gestão, aos proprietários e aos responsáveis de TI após um ataque confirmado ou provável a um site, uma loja ou um servidor web PHP. Serve também após o PHP2Shell, quando um servidor estava acessível antes da atualização e há indícios de comprometimento.
Nem todos os pontos se adequam a todos os ambientes. Percorra, ainda assim, a lista por completo e anote em cada ponto se está concluído, não aplicável ou em aberto. Este registo é mais tarde valioso para o seguro, a proteção de dados e o balanço interno.
Registe em cada passo a data, a hora, a pessoa responsável e o resultado. Se estiverem envolvidas várias pessoas, designe uma que conduza a lista e registe as decisões.
Fase 1: conter e guardar de imediato
- Limitar o dano: colocar o site em modo de manutenção ou retirá-lo da rede, se os visitantes estiverem em risco ou puderem fugir dados. O BSI (Serviço Federal Alemão para a Segurança da Informação) recomenda, no PHP2Shell, retirar temporariamente da rede os servidores web sem patch, quando uma atualização não é possível de imediato.
- Não apagar nada: não remover ficheiros, não reinstalar o servidor e não esvaziar registos antes de os vestígios estarem guardados.
- Guardar os registos: copiar os registos de acessos, de erros, do PHP-FPM e do sistema para outro sistema e registar as somas de verificação. Para o PHP2Shell, a imprensa especializada aconselha a guardar os registos a partir de 20/10/2026.
- Guardar uma imagem: criar como estado de prova uma cópia dos ficheiros e da base de dados, e nos servidores virtuais um snapshot, e não a alterar.
- Informar os responsáveis: envolver cedo a gestão, o encarregado da proteção de dados, o fornecedor de alojamento e, se existir, o seguro cibernético. Muitos seguros têm deveres de comunicação.
Fase 2: encontrar a causa e limpar
- Determinar a porta de entrada: analisar registos, alterações a ficheiros e versões. Verifique o próprio PHP, o CMS, os temas, as extensões, as credenciais e os serviços do servidor. Sem causa conhecida, mantém-se o risco de um novo ataque.
- Fechar a vulnerabilidade: levar o PHP a uma versão corrigida (8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou backport confirmado do fornecedor), atualizar o CMS e as extensões, reiniciar todos os workers PHP.
- Delimitar o período: determinar o momento mais antigo de atividade suspeita. Ele decide que backups podem estar limpos e que dados podem estar afetados.
- Remover backdoors: verificar e remover webshells, ficheiros PHP alheios em pastas de uploads e de cache, ficheiros do núcleo alterados, tarefas cron, chaves SSH e serviços do sistema. Substituir os ficheiros do núcleo por uma fonte limpa.
- Limpar a base de dados: remover contas de administrador desconhecidas, scripts introduzidos em conteúdos e definições, bem como conteúdos de spam.
- Ponderar a reconstrução: em caso de comprometimento profundo do servidor, uma reconstrução num sistema novo e com patch, com dados verificados, é muitas vezes o caminho mais fiável do que uma limpeza no sistema em funcionamento.
Fase 3: renovar os acessos e reforçar a segurança
- Alterar as palavras-passe: do CMS, da conta de alojamento, do painel, da base de dados, do FTP, do SFTP, do SSH e do e-mail, e isto a partir de um dispositivo limpo.
- Trocar chaves e tokens: gerar de novo chaves de API, interfaces de serviços de pagamento e de envio, chaves da aplicação do CMS, chaves SSH e certificados que estavam no servidor.
- Terminar sessões: terminar todas as sessões ativas no CMS e nos serviços e verificar os dispositivos de dois fatores registados.
- Ativar a autenticação de dois fatores: para todos os acessos de administração, incluindo alojamento, domínio e DNS.
- Reforçar o servidor: verificar e documentar as definições do PHP, as permissões de ficheiros, os bloqueios de execução em pastas de uploads, a firewall e os cabeçalhos de segurança.
Fase 4: obrigações, comunicação e conclusão
- Verificar as obrigações de notificação: se dados pessoais puderem estar afetados, pode ser necessária, nos termos do art. 33.º do RGPD, uma notificação no prazo de 72 horas. A avaliação cabe ao encarregado da proteção de dados ou a um advogado. Verificar em separado as obrigações setoriais, por exemplo ao abrigo da NIS2.
- Ponderar a queixa: os pontos de contacto centrais para cibercrime da polícia (Zentrale Ansprechstellen Cybercrime, na Alemanha) recebem queixas de empresas. Os registos guardados são para isso uma base importante.
- Informar clientes e o Google: informar os afetados de forma objetiva e coordenada. Se o Google mostrar um aviso, pedir a revisão após a limpeza, como descrito em Remover o aviso do Google.
- Documentar a conclusão e monitorizar: registar num relatório a causa, o período, as medidas e os pontos em aberto, retirar lições para o plano de emergência e monitorizar de forma reforçada os sistemas nas semanas seguintes.
Erros frequentes no acompanhamento
Muitos incidentes arrastam-se porque, na primeira agitação, se poupa no sítio errado ou se age depressa demais. Deve evitar estes erros:
- Remover apenas o que é visível: uma página de spam apagada ou um redirecionamento removido não é prova de um site limpo. As backdoors passam muitas vezes despercebidas.
- Alterar palavras-passe a partir do sistema afetado: se ainda correr software malicioso no computador ou servidor, as novas credenciais podem voltar a vazar de imediato.
- Restaurar um backup às cegas: sem vulnerabilidade fechada e sem verificação do backup, o atacante volta depressa à porta.
- Entender o patch como sinal de tranquilidade: uma atualização para uma versão corrigida do PHP não prova que antes não aconteceu nada e não remove software malicioso introduzido.
- Verificar as obrigações tarde demais: os prazos começam com o conhecimento do incidente, não com o fim da limpeza.
- Sem documentação: sem registo, as perguntas de seguradoras, autoridades ou clientes dificilmente se respondem mais tarde.
Esta lista de verificação não substitui aconselhamento jurídico. Em questões sobre obrigações de notificação, responsabilidade ou seguro, dirija-se ao seu encarregado da proteção de dados, a um advogado ou à sua seguradora.
Como ajuda concretamente a PHP SOS?
- Assumimos a resposta a incidentes estruturada e conduzimos a lista de verificação consigo, ponto por ponto e com registo.
- Guardamos registos e estados do sistema de modo que permaneçam utilizáveis para o seguro, as autoridades e uma eventual forense informática.
- Fechamos a vulnerabilidade, limpamos ou reconstruímos e renovamos os acessos pela sequência certa.
- Entregamos um relatório final com causa, medidas e recomendações e, se desejar, monitorizamos depois os sistemas.
Perguntas frequentes
Qual é a primeira coisa a fazer quando o meu site foi pirateado?
Manter a calma, não apagar nada e limitar o dano. Retire o site da rede ou coloque-o em modo de manutenção, se necessário, e guarde registos e ficheiros antes de limpar. Seguem-se depois a procura da causa e a limpeza.
Basta restaurar o site a partir de um backup?
Na maioria dos casos, não. O backup pode já conter código malicioso, e a vulnerabilidade por onde o atacante entrou continua aberta após a restauração. Primeiro fechar a causa, depois instalar um estado verificado e limpo num sistema atualizado.
Tenho de comunicar uma intrusão à autoridade de proteção de dados?
Se dados pessoais puderem estar afetados, o art. 33.º do RGPD prevê, em princípio, uma notificação no prazo de 72 horas após o conhecimento, desde que um risco para os titulares dos dados não seja improvável. A avaliação cabe ao seu encarregado da proteção de dados ou a um advogado.
Quando é que um incidente está realmente concluído?
Quando a causa está fechada, todas as backdoors conhecidas foram removidas, os acessos renovados, as obrigações cumpridas e as medidas documentadas. Faz parte um período de monitorização reforçada, para detetar vestígios despercebidos.
Fontes
- RGPD, art. 33.º: notificação à autoridade de controlo
- Polícia: pontos de contacto centrais para cibercrime (Zentrale Ansprechstellen Cybercrime, Alemanha)
- BSI (Serviço Federal Alemão para a Segurança da Informação): indicações sobre incidentes de segurança de TI
- php.net: avisos de segurança sobre o PHP2Shell