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

> Analisar o registo de acessos após um ataque: guardar os registos, encontrar vestígios típicos, comandos para Apache e Nginx e particularidades do PHP2Shell.

Fonte: https://phpsos.de/pt/ratgeber/logfiles-auswerten/  
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:** 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.

```bash
# 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](https://phpsos.de/pt/leistungen/it-forensik/) a assumir a salvaguarda.

> **Importante:**
> Verifique a rotação dos registos (`/etc/logrotate.d/`) e prolongue temporariamente a conservação, para que durante a análise não sejam apagados mais ficheiros.

## 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:

| Sistema | Registo de acessos e de erros |
|---|---|
| Debian, Ubuntu com Apache | `/var/log/apache2/` |
| RHEL, AlmaLinux, Rocky com Apache | `/var/log/httpd/` |
| Nginx | `/var/log/nginx/` |
| Plesk | `/var/www/vhosts/system/<domain>/logs/` |
| PHP-FPM | `/var/log/php*-fpm.log` ou no journal |

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`.

```bash
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](https://phpsos.de/pt/ratgeber/webshell-erkennen/).

## 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?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

## 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:

```bash
# 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](https://phpsos.de/pt/leistungen/incident-response/), 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

**Durante quanto tempo devo conservar os registos do servidor web?**  
Enquanto o seu conceito de proteção de dados o permitir e uma análise fizer sentido. Para o PHP2Shell, a imprensa especializada aconselha a guardar os registos a partir de 20/10/2026. Verifique a rotação dos registos, para que os ficheiros mais antigos não sejam apagados automaticamente.

**O registo de acessos mostra se um ataque teve êxito?**  
Não por si só. Mostra pedidos, códigos de estado e tamanhos de resposta, mas não que código foi executado no servidor. Só em conjunto com o registo de erros, o registo do PHP-FPM, as alterações a ficheiros e os registos do sistema surge uma imagem sólida.

**Posso transmitir a terceiros endereços IP dos registos?**  
Os endereços IP são, em regra, considerados dados pessoais. Para o esclarecimento de um incidente e para queixas-crime existem bases legais, mas a transmissão deve ser articulada com o encarregado da proteção de dados.

**Porque vejo muitos ataques no registo, embora nada tenha acontecido?**  
Os servidores públicos são constantemente varridos de forma automatizada. A maioria destes pedidos não leva a lado nenhum e termina com 404 ou 403. Interessam sobretudo os pedidos com estado 200 a ficheiros desconhecidos e os padrões que coincidem no tempo com outros vestígios.

## Fontes

- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: avisos de segurança](https://www.php.net/)
- [BSI IT-Grundschutz (proteção de base de TI)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)