Analisar os registos do servidor web após um ataque: ler corretamente o registo de acessos

Em resumo: quem quer analisar o registo de acessos após um ataque guarda primeiro os registos sem os alterar e trabalha depois apenas com cópias. Procuram-se pedidos com estado 200 a ficheiros PHP desconhecidos, pedidos POST suspeitos, acessos a diretórios de uploads e padrões temporais. Para o PHP2Shell não há Indicators of Compromise publicados e confirmados, por isso conta a imagem global de várias fontes de registo.

Primeiro guardar, depois analisar

Na maioria dos servidores, os ficheiros de registo são rodados automaticamente e apagados passado um tempo fixo. Após um ataque, o primeiro passo é, por isso, guardar os registos existentes antes que desapareçam. Isto vale também quando ainda não tem a certeza de que alguma coisa aconteceu. Para o PHP2Shell, a imprensa especializada aconselha a guardar os registos a partir de 20/10/2026.

# Copiar os registos com marcas temporais e registar somas de verificação
ZIEL=/root/sicherung-logs-$(date +%F)
mkdir -p "$ZIEL"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$ZIEL"/ 2>/dev/null
cp -a /var/log/auth.log* /var/log/syslog* "$ZIEL"/ 2>/dev/null
find "$ZIEL" -type f -exec sha256sum {} + > "$ZIEL.sha256"

Guarde também a cópia noutro sistema. Um atacante com acesso ao servidor poderia, de outro modo, alterar os registos a posteriori. As somas de verificação mostram mais tarde que a cópia está inalterada. Se for necessária uma salvaguarda com valor probatório em tribunal, por exemplo para uma queixa ou para o seguro, deve ser uma forense informática a assumir a salvaguarda.

Onde estão os registos e como é construída uma linha

Os locais de armazenamento dependem da distribuição e da interface de gestão. Caminhos típicos:

No formato Combined, muito difundido, cada linha contém o endereço do cliente, a data e a hora, o método e o caminho do pedido, o código de estado, o tamanho da resposta em bytes, o referer e o user agent. Preste atenção ao fuso horário na marca temporal, sobretudo ao comparar registos com mensagens em UTC. Os patches do PHP2Shell foram, por exemplo, publicados a 21/10/2026 às 14:00 UTC, ou seja, às 16:00 na hora alemã.

Se o seu site estiver atrás de um proxy, CDN ou balanceador de carga, no registo pode constar apenas o endereço destes. O endereço real do visitante encontra-se então num campo próprio ou nos registos do serviço intermédio.

Sem linha de comandos: registos no painel ou no fornecedor de alojamento

Nem todos os operadores têm acesso à shell. No alojamento partilhado ou em servidores geridos, as interfaces de gestão oferecem geralmente uma vista de registos e o download dos registos de acessos e de erros. Descarregue os ficheiros de todo o período disponível e guarde-os em segurança. Pergunte por escrito ao seu fornecedor de alojamento durante quanto tempo os registos são conservados e se estados mais antigos podem ser guardados antes de expirarem.

Tenha aqui em conta a proteção de dados: os registos contêm endereços IP e muitas vezes outros dados pessoais. Guarde as cópias com acesso protegido, transmita-as apenas a pessoas que delas precisem para o esclarecimento e defina quando serão apagadas após a conclusão do incidente.

Analisar o registo de acessos: as consultas mais importantes

Os comandos seguintes apenas leem e servem para Nginx e Apache no formato Combined. Os ficheiros rodados e comprimidos pesquisa-os com zgrep ou zcat.

LOG=/root/sicherung-logs-2026-10-25/nginx/access.log

# Pedidos bem-sucedidos a ficheiros PHP, por frequência
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Chamadas PHP em diretórios de uploads, cache ou imagens
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# Pedidos POST por destino e endereço
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Erros 5xx por hora: acumulações podem indicar processos PHP que falham
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Incluir registos rodados
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

Na primeira consulta interessam sobretudo nomes de ficheiro que não conhece ou que não pertencem à aplicação. Compare os ficheiros suspeitos com o sistema de ficheiros: quando foram criados, a quem pertencem, o que contêm? Indicações a este respeito dá o guia Detetar e remover webshells.

Particularidades do PHP2Shell

No PHP2Shell, as vulnerabilidades estão no processamento de pedidos do próprio PHP. No mod_php foi demonstrado um exploit antes sequer de correr código da aplicação. Isto significa: um pedido a uma página completamente normal pode bastar. No registo de acessos, tal pedido pode parecer discreto, porque o conteúdo do corpo do pedido não consta ali.

Não há Indicators of Compromise publicados e confirmados. Preste por isso atenção ao comportamento e às relações, por exemplo a partir de 17/10/2026, a primeira tentativa de ataque observada, segundo notícias dos meios de comunicação:

• Acumulações de erros 500 ou de respostas interrompidas em páginas comuns.
• Mensagens sobre memória esgotada ou workers terminados no registo de erros e do PHP-FPM.
• Ficheiros PHP novos ou ficheiros alterados pouco depois dessas acumulações.
• Novas tarefas cron, processos ou ligações de saída sob o utilizador do servidor web.

Nenhum destes sinais é, por si só, uma prova. Em conjunto com outros vestígios, formam porém uma imagem que responde à questão do comprometimento ou justifica uma investigação mais profunda. Uma vista geral dos sinais encontra-a em Já fui comprometido?.

Outras fontes: registo de erros, PHP-FPM e registos do sistema

O registo de acessos mostra apenas uma parte. Para uma imagem completa, recorra a outras fontes:

# PHP-FPM e servidor web no journal a partir de uma data
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Inícios de sessão no servidor
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Verificar tarefas agendadas de todos os utilizadores
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Erros típicos na análise são pesquisar apenas o registo atual em vez de também os rodados, ignorar o fuso horário e tomar resultados isolados de scanners automatizados por um ataque bem-sucedido. Igualmente arriscado é o contrário: considerar um registo de acessos discreto como sinal de tranquilidade, embora o registo de erros e o sistema de ficheiros ainda não tenham sido verificados.

Anote cada achado com hora, fonte e observação numa cronologia. Esta cronologia é mais tarde a base para decisões, para notificações a autoridades ou seguradoras e para o relatório final.

Como ajuda concretamente a PHP SOS?

• Guardamos registos e ficheiros relevantes de modo a permanecerem rastreáveis para verificações posteriores.
• Analisamos em conjunto os registos de acessos, de erros, do PHP e do sistema e elaboramos uma cronologia do incidente.
• Perante indícios de comprometimento, assumimos a resposta a incidentes, com contenção e limpeza.
• Configuramos a rotação e a conservação dos registos de modo que, no próximo incidente, os dados necessários existam.

Perguntas frequentes

Fontes

• TechTarget: PHP2Shell, 22M exposed servers at risk
• php.net: avisos de segurança
• BSI IT-Grundschutz (proteção de base de TI)