# Lista de verificação após uma intrusão: 20 pontos para o acompanhamento

> Lista de verificação para quando o site foi pirateado: 20 pontos, da contenção e salvaguarda de provas à limpeza, novos acessos e obrigações de notificação.

Fonte: https://phpsos.de/pt/ratgeber/checkliste-nach-dem-hack/  
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 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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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

6. **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.
7. **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.
8. **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.
9. **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.
10. **Limpar a base de dados:** remover contas de administrador desconhecidas, scripts introduzidos em conteúdos e definições, bem como conteúdos de spam.
11. **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

12. **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.
13. **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.
14. **Terminar sessões:** terminar todas as sessões ativas no CMS e nos serviços e verificar os dispositivos de dois fatores registados.
15. **Ativar a autenticação de dois fatores:** para todos os acessos de administração, incluindo alojamento, domínio e DNS.
16. **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

17. **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](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/). 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.
18. **Ponderar a queixa:** os [pontos de contacto centrais para cibercrime](https://phpsos.de/pt/compliance/anzeige-polizei-zac/) da polícia (Zentrale Ansprechstellen Cybercrime, na Alemanha) recebem queixas de empresas. Os registos guardados são para isso uma base importante.
19. **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](https://phpsos.de/pt/ratgeber/google-warnung-entfernen/).
20. **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.

> **Importante:**
> 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](https://phpsos.de/pt/leistungen/incident-response/) 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](https://phpsos.de/pt/leistungen/it-forensik/).
- 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](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Polícia: pontos de contacto centrais para cibercrime (Zentrale Ansprechstellen Cybercrime, Alemanha)](https://www.polizei.de/)
- [BSI (Serviço Federal Alemão para a Segurança da Informação): indicações sobre incidentes de segurança de TI](https://www.bsi.bund.de/)
- [php.net: avisos de segurança sobre o PHP2Shell](https://www.php.net/)