Em resumo: A cronologia de um incidente informático ordena cronologicamente todas as observações, decisões e medidas num fuso horário uniforme, de preferência UTC. Cada linha indica a fonte, a observação, a prova e uma classificação como comprovada, provável ou desconhecida. Obtém-se assim um quadro rastreável de quando o atacante esteve no sistema, do que conseguiu alcançar e de quando teve conhecimento disso.
Por que razão, no fim, todos perguntam pelo quando
Depois de um incidente, as perguntas chegam de todos os lados. O encarregado da proteção de dados quer saber desde quando havia dados pessoais acessíveis. A seguradora pergunta quando o dano foi descoberto e comunicado. A gestão quer saber se a vulnerabilidade já estava aberta antes da última atualização. Todas estas perguntas têm algo em comum: giram em torno de momentos no tempo.
Sem cronologia, cada um responde a estas perguntas de memória, e as respostas contradizem-se. Com uma cronologia bem mantida, há uma base comum à qual todos os envolvidos se podem referir. É também a estrutura do relatório final.
No caso do PHP2Shell, a cronologia é particularmente reveladora, porque os dados públicos essenciais estão bem documentados. Podem ser colocados como pontos de ancoragem ao lado das suas próprias observações. A sequência completa dos acontecimentos públicos é descrita no guia PHP2Shell: a cronologia.
A estrutura: que colunas precisa uma cronologia
Basta uma tabela, numa folha de cálculo ou num documento partilhado. O importante são colunas fixas, preenchidas em todas as linhas. O modelo seguinte mostra os dados públicos essenciais do PHP2Shell como âncoras e, por baixo, entradas próprias típicas em forma de marcadores:
| Hora (UTC) | Fonte | Observação | Prova | Classificação |
|---|---|---|---|---|
| 17/10/2026 | notícias dos meios de comunicação | primeira tentativa de ataque observada ao PHP2Shell | notícia da imprensa | comprovada como notícia dos meios de comunicação |
| 20/10/2026 | php.net | pré-anúncio das atualizações de segurança | comunicado no php.net | comprovada |
| 21/10/2026, 14:00 | php.net | publicação de 8.5.12, 8.4.27, 8.3.36, 8.2.35 | comunicado no php.net | comprovada |
| hora própria | registo de acessos | acumulação de erros 500 em páginas normais | excerto do registo, número da linha | provavelmente relevante |
| hora própria | sistema de ficheiros | novo ficheiro PHP na pasta de uploads | cópia com soma de verificação | comprovada, momento incerto |
| hora própria | interno | incidente notado, gestão informada | e-mail, nota de conversa | comprovada |
| hora própria | interno | atualização aplicada, todos os workers reiniciados | registo de pacotes, lista de processos | comprovada |
A coluna Classificação é a parte mais importante. Separa o que está demonstrado, o que parece plausível e o que fica em aberto. Os leitores posteriores veem assim de imediato onde a cronologia é sólida e onde existem lacunas.
Cronologia de um incidente informático: reunir as fontes
As entradas provêm de muitas fontes, cada uma com formatos e fusos horários próprios. Proceda por esta ordem:
- Fixar o fuso horário: manter tudo em UTC. A passagem à hora de inverno a 25/10/2026 desloca uma hora as horas locais alemãs a meio do período. Quem mistura horas locais desloca acontecimentos sem dar por isso.
- Verificar os relógios: o relógio do servidor estava certo? Uma comparação com um evento conhecido, por exemplo o seu próprio início de sessão, mostra desvios.
- Fontes externas primeiro: os registos do CDN, do WAF, do alojamento ou da firewall estão fora do servidor e são difíceis de manipular. Formam a estrutura.
- Acrescentar os registos do servidor: servidor web, PHP-FPM, inícios de sessão, journal do sistema. A metodologia está descrita em Analisar os registos do servidor web após um ataque.
- Enquadrar o sistema de ficheiros: acrescentar como indícios as datas de ficheiros novos e alterados.
- Registar os eventos internos: quando foi notado, quem foi informado, que decisão foi tomada e quando?
O que as datas dos ficheiros revelam e o que não revelam
O Linux guarda para cada ficheiro vários momentos, entre eles a última alteração do conteúdo (mtime) e a última alteração dos metadados (ctime). Ambos podem ser apresentados apenas em leitura, aqui como lista dos ficheiros PHP alterados desde uma data de referência, ordenada por hora em UTC:
# Alterações de conteúdo desde 17/10/2026, ordenadas, em UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Todas as datas de um único ficheiro
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Trabalhe aqui apenas numa cópia ou numa imagem preservada, como descrito em Preservar provas antes de reinstalar o servidor. Tenha presentes dois limites. Primeiro, um atacante pode repor com meios simples a data de alteração de um ficheiro; um mtime discreto não é uma absolvição. Segundo, as operações de cópia e algumas ferramentas alteram as datas. Por isso vale esta regra: as datas dos ficheiros são indícios, as entradas de registos externos são provas.
Registe o momento em que a sua empresa tomou conhecimento de uma possível violação de dados. Nos termos do art. 33 do RGPD, o prazo de 72 horas para uma notificação começa, em princípio, com o conhecimento. A avaliação cabe ao seu encarregado da proteção de dados ou a um advogado.
Erros típicos e como evitá-los
Os erros mais frequentes são pouco espetaculares. A cronologia só é reconstruída de memória no fim, em vez de ser mantida em contínuo. As entradas contêm conclusões em vez de observações, por exemplo «o atacante entrou pelo formulário» em vez de «pedido POST ao formulário, depois novo ficheiro». E faltam provas, porque ninguém anotou de que ficheiro de registo e de que linha vinha uma entrada.
Por isso, designe uma pessoa para manter a cronologia e registe os eventos logo que ocorrem. As conclusões pertencem a uma coluna própria ou ao relatório, não à observação.
Trate ainda a cronologia como um documento confidencial. Contém muitas vezes endereços IP, nomes de utilizador e indicações sobre pontos fracos. Defina quem pode lê-la e alterá-la e conserve as versões anteriores. Quando uma avaliação muda, por exemplo porque surge um novo excerto de registo, a linha antiga não é sobrescrita, mas complementada. Assim, fica rastreável o que era conhecido em cada momento e com que base se decidiu.
Como ajuda concretamente a PHP SOS?
- Mantemos a cronologia em contínuo desde o primeiro contacto e em UTC, com fonte e prova em cada entrada.
- Analisamos em conjunto os registos externos, os registos do servidor e o sistema de ficheiros e classificamos cada afirmação como comprovada, provável ou desconhecida.
- Se necessário, assumimos, com parceiros especializados, a perícia informática forense para uma análise utilizável em tribunal.
- Entregamos a cronologia como parte de um relatório para a gestão, a proteção de dados e o seguro.
Perguntas frequentes
Para que preciso de uma cronologia após um incidente de segurança?
Ordena todas as observações numa sequência e mostra quando o atacante esteve no sistema, o que conseguiu alcançar e quando teve conhecimento disso. Estes dados são necessários ao encarregado da proteção de dados, às seguradoras, às autoridades e à gestão para as suas decisões.
Em que fuso horário devo manter a cronologia?
De forma uniforme em UTC. Servidores, serviços e comunicações usam fusos horários diferentes e a passagem à hora de inverno, no final de outubro, desloca ainda as horas locais. Quem converte tudo para UTC e acrescenta a hora local apenas como complemento evita erros na comparação.
Posso confiar nas datas dos ficheiros?
Só com limitações. A data de alteração de um ficheiro pode ser falsificada com meios simples. Mais fiáveis são as entradas nos registos, sobretudo em registos fora do servidor afetado. As datas dos ficheiros são indícios que devem ser confirmados por outras fontes.
O que deve constar da cronologia além dos eventos técnicos?
Também decisões e comunicação: quando o incidente foi notado, quem foi informado, quando o servidor foi desligado da rede, quando foi aplicado o patch. O momento do conhecimento é precisamente importante para os prazos de notificação.