Em resumo: quando um ataque afeta mais do que um único site, precisa de um prestador de resposta a incidentes que trate o incidente de forma estruturada. Assumimos o panorama da situação, a contenção, a limpeza e a recuperação segura, com funções claras e documentação sem lacunas. As decisões continuam consigo; nós asseguramos a base técnica.
O que significa resposta a incidentes em ataques a servidores
A resposta a incidentes é o tratamento ordenado de um incidente de segurança. Em vez de ações isoladas e apressadas, o trabalho segue fases definidas: reconhecer e classificar, conter, eliminar, recuperar, fazer o balanço. Cada medida é registada com o momento e a fundamentação.
Nos servidores web, isto é particularmente importante. Um servidor com aplicações PHP contém muitas vezes credenciais de bases de dados, prestadores de pagamento, servidores de correio e interfaces. Quem aí entrou pode deslocar-se para outros sistemas. A situação após o PHP2Shell mostra a rapidez com que uma situação destas pode surgir: execução de código sem autenticação, mais de 22,6 milhões de instâncias expostas segundo a Unit 42 e nenhum indicador de compromisso (IOC) confirmado e publicado.
Quando precisa de um prestador de resposta a incidentes
- vários servidores ou aplicações estão afetados ou poderão estar
- há suspeita de que dados pessoais ou dados de pagamento tenham saído
- um atacante poderá ainda estar ativo, por exemplo através de ligações em curso ou de contas novas
- existe uma extorsão ou um anúncio público do ataque
- a seguradora, as autoridades ou os parceiros de negócio esperam um processo documentado
Num único site infetado, basta muitas vezes a assistência de emergência para sites comprometidos. Falamos consigo sobre a transição para o tratamento completo do incidente assim que se vislumbrar uma dimensão maior.
Como ajuda concretamente a PHP SOS?
- Triagem e panorama da situação: esclarecemos o que foi observado, que sistemas e dados podem estar afetados e quem tem de ser envolvido internamente. O resultado é um primeiro panorama escrito da situação, com as questões em aberto.
- Preservar vestígios e conter: registos, sistemas de ficheiros e bases de dados são preservados antes de intervirmos. Depois isolamos os sistemas afetados, bloqueamos os acessos comprometidos e interrompemos as ligações identificáveis do atacante.
- Eliminar: fechamos a porta de entrada, por exemplo aplicando o patch às versões corrigidas do PHP e reiniciando todos os workers, removemos backdoors e substituímos segredos. Para a análise de detalhe, envolvemos, se necessário, parceiros especializados em perícia forense informática.
- Recuperar: os sistemas voltam a funcionar de forma controlada, se possível a partir de fontes limpas ou em servidores reinstalados. Depois vigiamo-los de forma reforçada quanto a novas anomalias.
- Balanço: recebe um relatório final com cronologia, causas, medidas e recomendações. Em conjunto, registamos o que deve ser mais rápido da próxima vez.
Guarde os registos do servidor e não altere sistemas antes de os preservar. Para o PHP2Shell, o BSI recomenda desligar temporariamente da rede os servidores web a que não seja possível aplicar o patch de imediato.
Funções e comunicação durante o incidente
Um incidente precisa de responsabilidades claras. Provou-se uma pequena equipa composta por uma pessoa com poder de decisão, um interlocutor técnico do seu lado e nós como direção técnica. As reuniões de situação realizam-se a intervalos fixos e os resultados são registados por escrito.
Em paralelo decorrem tarefas que não assumimos, mas para as quais fornecemos factos: a avaliação de uma obrigação de notificação do RGPD no prazo de 72 horas, a informação à seguradora, uma possível denúncia e a comunicação de crise com clientes e parceiros.
O que precisamos de si e o que recebe
Precisamos de acessos administrativos aos sistemas afetados, de uma visão geral da infraestrutura e dos prestadores de serviços, de uma pessoa com poder de decisão e da disponibilidade para desligar temporariamente sistemas, se necessário. São úteis os planos de emergência existentes, os esquemas de rede e as cópias de segurança com data.
Recebe um protocolo contínuo do incidente, panoramas regulares da situação em linguagem compreensível, um relatório final para a administração, o encarregado da proteção de dados e a seguradora, bem como uma lista priorizada de melhorias. Como se preparar melhor para o próximo incidente, descreve-o Elaborar um plano de emergência de TI para servidores web.
Erros típicos nas primeiras horas
Muitos incidentes agravam-se porque, na agitação, passos bem-intencionados são dados pela ordem errada. Estes são os padrões que vemos com frequência:
- Reinstalar de imediato: o servidor é apagado e reinstalado antes de ser preservado. Depois já não se consegue esclarecer se saíram dados.
- Alterar palavras-passe a partir do sistema infetado: se o atacante ainda tem acesso, vê também as palavras-passe novas.
- Apagar apenas o ficheiro visível: a webshell desaparece, a segunda backdoor no cronjob permanece.
- Aplicar o patch sem reiniciar: os ficheiros PHP novos estão no disco, os workers antigos continuam a correr na memória.
- Ninguém mantém um registo: mais tarde, ninguém sabe quem alterou o quê e quando. Isso dificulta as conversas com a seguradora e as autoridades.
Um processo coordenado evita estes erros sem atrasar a contenção.
O que não prometemos
Não prometemos que todos os incidentes sejam totalmente esclarecidos; sem vestígios, ficam questões em aberto, e escrevemo-lo assim no relatório. Não prestamos aconselhamento jurídico nem fazemos afirmações sobre responsabilidade ou cobertura do seguro. O nosso objetivo é um fim claro: trabalhamos no incidente até estar concluído e documentado.
Perguntas frequentes
Qual é a diferença entre resposta a incidentes e perícia forense informática?
A resposta a incidentes tem como objetivo conter o incidente e restabelecer o funcionamento em segurança. A perícia forense informática esclarece em detalhe e com valor probatório o que aconteceu. Na prática, ambas se complementam; a perícia forense preserva muitas vezes os vestígios em paralelo.
Quando devo recorrer a um prestador de resposta a incidentes?
Assim que haja suspeita de que um atacante teve acesso a sistemas e não consiga avaliar com segurança a dimensão. Quanto mais cedo começar a preservação de vestígios, mais se poderá comprovar depois.
Quem decide durante o incidente?
As decisões são suas, por exemplo sobre desligamentos, comunicação ou notificações. Nós preparamos as bases técnicas, mostramos as opções com as suas consequências e executamos as decisões.
Tenho de recorrer à polícia?
Uma denúncia é útil em muitos casos e relevante para algumas seguradoras. Os pontos de contacto centrais para o cibercrime da polícia alemã (ZAC) são os responsáveis. Se e quando apresenta denúncia, decide-o com o seu advogado.