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.
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; 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
shoubash. É um sinal de alerta forte, que explicamos na página O servidor web inicia uma 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?. Se vários pontos se aplicarem, trate o servidor como hackeado até se provar o contrário.
Servidor hackeado: o que fazer já
- 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.
- Registar o momento. Anote o que observou e quando, e quem fez as últimas alterações ao sistema.
- 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.
- 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.
- 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.
- Nomear um interlocutor. Deve estar contactável uma pessoa com poder de decisão, também para desligar e reiniciar.
- 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?, a preservação antes de uma reconstrução na página Preservar provas antes de reinstalar.
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. 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?
- Levantar a situação: esclarecemos consigo o que foi observado, que sistemas podem estar afetados e que dados lá se encontram.
- 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.
- Verificar e limpar: procuramos webshells, backdoors, cronjobs e acessos alheios e removemo-los. Os pormenores estão em Remoção de malware e webshells.
- 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 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, e toda a ajuda de emergência em Site hackeado? Ajuda de emergência remota. Sobre o dever de notificação em caso de violação de dados, leia a regra das 72 horas; 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.
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.