# Servidor hackeado: o que fazer? Primeiros passos e ajuda urgente

> Servidor hackeado? Não apague nada, preserve os vestígios, esclareça os acessos. Assumimos o caso remotamente. Ligue ou escreva-nos por WhatsApp.

Fonte: https://phpsos.de/pt/soforthilfe/server-gehackt-was-tun/  
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:** está afetado? Ligue-nos. Nós ajudamos. Se suspeita de que o seu servidor foi hackeado, conta antes de mais uma coisa: preservar os vestígios. Desde a primeira mensagem, tratamos remotamente da avaliação da situação, da preservação, da contenção, da limpeza e da documentação, até o incidente estar encerrado.

> **Agir de imediato:**
> **Não apague nada nem reinstale nada agora.** E não reponha nenhuma cópia de segurança antes de se ter feito a preservação. Quem arruma destrói precisamente os vestígios que mostram como o atacante entrou. [Comunicar uma emergência](https://phpsos.de/pt/notfall/); depois procedemos em conjunto.

## Está afetado? Sinais de que um servidor foi hackeado

Uma suspeita basta para nos contactar. Não tem de provar o ataque. São indícios típicos:

- O servidor web ou o PHP-FPM inicia processos como `sh` ou `bash`. É um sinal de alerta forte, que explicamos na página [O servidor web inicia uma shell](https://phpsos.de/pt/blog/webserver-startet-shell/).
- Existem ficheiros PHP novos ou desconhecidos em pastas de uploads, de cache ou temporárias.
- Há cronjobs que ninguém criou ou chaves SSH que ninguém sabe atribuir.
- A carga é elevada sem motivo aparente, ou o servidor estabelece ligações de saída invulgares.
- O correio do seu servidor vai parar ao spam ou é rejeitado.
- O fornecedor de alojamento, um cliente ou um aviso no navegador comunica código malicioso.
- No CMS surgem contas de administrador que ninguém criou.

Encontra mais sinais em [Já fui comprometido?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/). Se vários pontos se aplicarem, trate o servidor como hackeado até se provar o contrário.

## Servidor hackeado: o que fazer já

1. **Manter a calma e não alterar nada.** Não apagar ficheiros, não fazer «reparações rápidas», não reinstalar por cima do estado antigo.
2. **Registar o momento.** Anote o que observou e quando, e quem fez as últimas alterações ao sistema.
3. **Conservar os registos.** Os registos de acesso, de erros e do sistema não podem rodar nem ser substituídos. No caso do PHP2Shell, a imprensa especializada aconselha a conservar os registos do servidor a partir de 20/10/2026.
4. **Reduzir a superfície de ataque.** Retire o servidor da rede pública ou bloqueie-o com a firewall, se puder haver fuga de dados. Não se limite a desligá-lo.
5. **Reunir os acessos.** Quem tem acesso por SSH, painel, FTP, CMS e base de dados? Altere as palavras-passe só depois de acordo connosco e apenas a partir de um dispositivo limpo.
6. **Nomear um interlocutor.** Deve estar contactável uma pessoa com poder de decisão, também para desligar e reiniciar.
7. **Contacte-nos agora.** Ligue ou escreva-nos por WhatsApp. Esclarecemos tudo o resto consigo, passo a passo.

## Retirar da rede ou deixar a funcionar?

É a pergunta mais frequente nos primeiros minutos e não tem uma resposta geral. Se está em funcionamento uma loja online com pagamentos ou um portal com dados de clientes, a proteção dos dados costuma prevalecer. Nesse caso, um isolamento temporário é o correto, por exemplo através de uma página de manutenção ou de uma regra de firewall que admita apenas os seus administradores.

Um desligamento brusco, em contrapartida, raramente é o melhor primeiro passo, porque na memória há vestígios que um reinício apaga. É melhor uma imagem do sistema, por exemplo um snapshot no fornecedor de alojamento, antes de alterar o que quer que seja. Na situação do PHP2Shell, o BSI recomenda retirar temporariamente os servidores web da rede, se uma atualização não for possível de imediato. Isso não significa que todo o servidor desligado tenha sido hackeado.

Se, no seu caso, deve isolar, limitar ou deixar a funcionar, decidimos consigo com base no que está no sistema.

## Reinstalar ou limpar?

Muitos querem, de preferência, reconstruir o servidor de imediato. Não está errado, mas só depois da preservação. Caso contrário, fica por esclarecer como o atacante entrou, e o mesmo caminho fica aberto também ao novo sistema. A ponderação é descrita na página [Reinstalar o servidor ou limpá-lo?](https://phpsos.de/pt/blog/neu-aufsetzen-oder-bereinigen/), a preservação antes de uma reconstrução na página [Preservar provas antes de reinstalar](https://phpsos.de/pt/blog/beweise-sichern-vor-neuinstallation/).

Importante: uma atualização do PHP, por si só, não resolve o problema. Fecha a vulnerabilidade, mas não remove software malicioso já introduzido. Como encontrar vestígios nos registos, explica-o [Analisar os registos do servidor web após um ataque](https://phpsos.de/pt/ratgeber/logfiles-auswerten/). E parta do princípio de que credenciais de ficheiros de configuração foram lidas: os acessos à base de dados, ao correio e a APIs entram na lista de segredos a renovar.

## Como ajuda concretamente a PHP SOS?

1. **Levantar a situação:** esclarecemos consigo o que foi observado, que sistemas podem estar afetados e que dados lá se encontram.
2. **Preservar e fechar:** preservamos ficheiros, base de dados e registos antes de alterar o que quer que seja. Depois contemos o ataque e fechamos a porta de entrada, no caso do PHP2Shell com patch e reinício de todos os processos PHP.
3. **Verificar e limpar:** procuramos webshells, backdoors, cronjobs e acessos alheios e removemo-los. Os pormenores estão em [Remoção de malware e webshells](https://phpsos.de/pt/leistungen/malware-entfernung/).
4. **Reforçar e relatar:** recebe uma documentação com cronologia, locais encontrados e recomendações. Se o incidente se estender para além de um servidor, passamos a uma [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/) estruturada.

## O que não deve fazer

Sob stress cometem-se erros evitáveis. Não apague ficheiros «suspeitos» por suspeita, sem os ter preservado antes. Não execute comandos de fóruns que não compreende. E não instale plugins de segurança num servidor que possa já estar comprometido: o código malicioso pode enganar os scanners, e o resultado dá-lhe uma falsa sensação de segurança. Cuidado também com as dicas de bloquear todos os pedidos com um determinado ID de sessão; os autores especializados rejeitam expressamente esses conselhos sobre o PHP2Shell. Pode verificar com segurança a sua própria versão com `php -v` e com uma olhadela ao changelog do pacote da sua distribuição, porque os backports deixam muitas vezes o número de versão igual.

## O que nos deve enviar

- uma breve descrição: o que chamou a atenção, desde quando, o que foi alterado por último
- o tipo de sistema: servidor próprio, vServer, servidor gerido ou pacote de alojamento
- o acesso por SSH ou painel, ou a autorização para falarmos com o seu fornecedor de alojamento
- indicações sobre as cópias de segurança existentes e a sua idade
- avisos do fornecedor de alojamento, do navegador ou de clientes, tal como foram formulados

Se faltar alguma destas coisas, contacte-nos na mesma. As lacunas fechamo-las em conversa.

## Porquê a PHP SOS

Trabalhamos com qualidade Made in Germany e, há mais de 25 anos, estamos especializados em segurança informática com a nossa rede de parceiros de profissionais de cibersegurança. Tem um interlocutor; trabalhamos remotamente, sem deslocações, em toda a Alemanha e na Europa. Cada passo fica documentado, e separamos abertamente o que está comprovado, o que é provável e o que é desconhecido. Não fazemos promessas que ninguém possa cumprir. Uma panorâmica do acompanhamento posterior está na [lista de verificação após um hack](https://phpsos.de/pt/ratgeber/checkliste-nach-dem-hack/), e toda a ajuda de emergência em [Site hackeado? Ajuda de emergência remota](https://phpsos.de/pt/leistungen/website-gehackt-notfallhilfe/). Sobre o dever de notificação em caso de violação de dados, leia a [regra das 72 horas](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/); a avaliação jurídica fica com os encarregados da proteção de dados e os advogados.

## Está afetado? Ligue-nos. Nós ajudamos.

Não espere que a suspeita se transforme num dano maior. Assumimos o caso desde a primeira mensagem e ficamos até o incidente estar encerrado e documentado. [Comunicar já uma emergência](https://phpsos.de/pt/notfall/).


## Perguntas frequentes

**Servidor hackeado: devo desligá-lo imediatamente?**  
Não de forma precipitada. Desligar pode destruir vestígios voláteis na memória. É melhor desligar o servidor da rede ou isolá-lo com a firewall e preservar primeiro. Se tiver dúvidas, contacte-nos antes.

**Como descubro se o meu servidor foi mesmo hackeado?**  
Dão indícios os processos iniciados pelo servidor web, os novos ficheiros PHP em pastas de uploads ou de cache, os cronjobs e chaves SSH desconhecidos e as ligações de saída invulgares. A certeza só vem de uma análise dos registos e dos ficheiros. Não existem indicadores PHP2Shell confirmados; a deteção baseia-se na análise de comportamento.

**Basta uma atualização do PHP se o servidor já tiver sido hackeado?**  
Não. Um patch fecha a porta de entrada, mas não remove software malicioso já introduzido e não prova que nada aconteceu antes. Depois da atualização, todos os processos PHP têm também de ser reiniciados.

**Tenho de comunicar um servidor hackeado?**  
Se dados pessoais puderem estar afetados, pode ser necessária uma notificação à autoridade de controlo no prazo de 72 horas. A avaliação cabe ao seu encarregado da proteção de dados ou ao seu advogado; nós fornecemos os factos técnicos para isso.

**Posso limpar eu próprio o servidor hackeado?**  
Em sistemas pequenos é possível, mas arriscado: quem remove apenas os ficheiros visíveis falha muitas vezes backdoors, cronjobs ou acessos. Verificamos se uma limpeza basta ou se faz mais sentido reconstruir a partir de fontes limpas.

## Fontes

- [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/)