Em resumo: No Linux, encontra ficheiros alterados com find e uma janela de tempo, por exemplo a partir de 17 de outubro de 2026, a primeira tentativa de ataque observada ao PHP2Shell segundo relatos dos meios de comunicação. Verifique não só a hora de alteração do conteúdo (mtime), mas também a dos metadados (ctime), porque a primeira é fácil de falsificar. O resultado só se torna fiável com a comparação com somas de verificação de pacotes, Git ou uma cópia de segurança.
Porque é que os carimbos de data/hora são um bom começo, mas não uma prova
Quem leva código para um servidor altera ficheiros. Novas webshells, ficheiros de configuração adaptados, linhas acrescentadas a scripts existentes: tudo isso deixa carimbos de data/hora. Procurar alterações na janela de tempo certa é por isso um dos caminhos mais rápidos para os primeiros achados.
Para o PHP2Shell, como início da janela sugere-se 17 de outubro de 2026, o dia da primeira tentativa de ataque observada segundo relatos dos meios de comunicação. Os patches surgiram a 21 de outubro. Quem só atualizou o servidor depois disso procura até ao dia da sua própria atualização e para além dele. Como reconhecer webshells entre os achados descreve-o Reconhecer e remover webshells. Aqui trata-se do método da própria pesquisa.
Os três carimbos de data/hora de um ficheiro
O Linux guarda vários momentos para cada ficheiro. Para a pesquisa de alterações, dois são decisivos.
| Carimbo | Significado | Falsificável? |
|---|---|---|
| mtime | última alteração do conteúdo | sim, p. ex. com touch, por qualquer pessoa que possa escrever no ficheiro |
| ctime | última alteração do conteúdo ou dos metadados como permissões | não com meios simples |
| atime | último acesso de leitura | muitas vezes desativado ou impreciso, pouco adequado para a pesquisa |
Os atacantes gostam de retrodatar o mtime para a data dos ficheiros vizinhos, para que um novo ficheiro não dê nas vistas. O ctime, porém, muda nesse processo. Um ficheiro com mtime antigo e ctime recente é por isso um forte indício de manipulação.
Ao comparar, tenha atenção aos fusos horários. O find e o ls mostram a hora local do servidor, enquanto muitos ficheiros de registo e serviços trabalham em UTC. Quem põe lado a lado achados do sistema de ficheiros e dos registos deve converter todas as indicações para o mesmo fuso, caso contrário os acontecimentos parecem não coincidir. Os patches surgiram por volta de 21 de outubro às 14:00 UTC, ou seja, às 16h00 hora alemã.
Encontrar ficheiros alterados no Linux com find
Todos os comandos só leem. Adapte o caminho e a data.
# Conteúdo alterado desde 17/10/2026, ordenado, com mtime, ctime e proprietário
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metadados alterados desde 17/10/2026 (encontra também ficheiros retrodatados)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Ocultar o ruído conhecido: cache, registos, sessões
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Verificar também fora do diretório web
find /etc /usr/local/bin /tmp /var/tmp /dev/shm -xdev -type f -newerct "2026-10-17" -printf '%C+ %p\n' 2>/dev/null | sort
Em cada resultado, compare os dois carimbos. Se o ctime for claramente mais recente do que o mtime, e ninguém tiver alterado permissões ou copiado ficheiros nesse período, o ficheiro vai para a lista. Atenção também ao proprietário: um ficheiro do utilizador do servidor web entre ficheiros do utilizador de deploy dá nas vistas.
Não se esqueça dos ficheiros e diretórios ocultos. Os nomes que começam por um ponto não são mostrados por muitos gestores de ficheiros nem por um simples ls. Os atacantes aproveitam isto de bom grado, tal como nomes quase idênticos aos de ficheiros verdadeiros.
# Ficheiros e pastas ocultos no diretório web, sem os conhecidos como .htaccess e .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Comparar com uma fonte de confiança
Os carimbos de data/hora mostram onde algo se mexeu. Se foi uma alteração legítima, só a comparação com uma fonte em que confia o mostra.
- Gestor de pacotes: para ficheiros do sistema,
dpkg --verify(Debian/Ubuntu) ourpm -Va(família RHEL) verificam os ficheiros face às somas de verificação dos pacotes instalados. Os ficheiros de configuração divergem legitimamente, os ficheiros de programa não. - Git: se a aplicação estiver num repositório,
git -C /var/www/projekt status --porcelainmostra qualquer divergência face ao último commit. - Somas de verificação do CMS: muitos sistemas podem comparar os seus ficheiros principais com as somas de verificação oficiais, ver Comparar os ficheiros principais do CMS com o original.
- Cópia de segurança anterior ao incidente: uma comparação em ensaio lista diferenças sem copiar nada.
# Apenas listar diferenças entre a cópia de segurança e o sistema em produção (ensaio, não copia nada)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
A comparação com a cópia de segurança pressupõe que esta foi feita antes do incidente e não foi ela mesma alterada. Porque é que cópias de segurança guardadas em separado são aqui decisivas explica-o Cópias de segurança segundo a regra 3-2-1.
Guarde os resultados de cada pesquisa, com data, num ficheiro fora do servidor. Dessas listas nasce mais tarde a cronologia do incidente, e elas comprovam o que verificou e quando.
Quando não há nem cópia de segurança nem repositório
Em muitos sites mais pequenos não existe uma base de comparação limpa: sem Git, sem cópia de segurança anterior ao incidente, plugins atualizados à mão há anos. Mesmo assim, não fica sem qualquer ponto de apoio.
Descarregue do fabricante o CMS e as extensões exatamente nas versões instaladas e compare esses ficheiros com o servidor. O que divergir ou faltar merece uma olhadela. Sobram as suas próprias adaptações, uploads e configuração; aí a pesquisa por carimbos de data/hora ajuda, complementada por um olhar ao proprietário e às permissões. Ficheiros que são os únicos num diretório com outro grupo, outras permissões ou um ctime claramente mais recente do que os vizinhos vão para a lista.
Sinceramente: sem base de comparação, fica uma incerteza residual. Em sistemas com dados sensíveis, uma reconstrução a partir de fontes limpas é então muitas vezes mais fiável do que procurar cada ficheiro alterado. Para o futuro, a lição é simples: um repositório para o código e cópias de segurança regulares, guardadas em separado.
Fontes de erro típicas na pesquisa
- Exclusões demasiado generosas: as pastas de cache e de upload são esconderijos populares.
- Só o mtime verificado: os ficheiros retrodatados escapam.
- Deployment na janela: uma publicação regular altera centenas de ficheiros e encobre achados isolados. Compare com o repositório.
- Ficheiros já abertos ou copiados: cópias que não preservam os carimbos destroem vestígios. Guarde com ferramentas que preservem os carimbos.
- Só o diretório web pesquisado: os atacantes guardam ferramentas também em
/tmp,/dev/shmou no diretório pessoal do utilizador do servidor web. - Alterações de permissões ignoradas: um ficheiro cujas permissões passaram de repente a permitir escrita a todos é um achado, mesmo que o conteúdo esteja inalterado.
Como os achados se compõem numa sequência mostra-o Elaborar a cronologia de um incidente.
Como ajuda concretamente a PHP SOS?
- Pesquisar sistematicamente: pesquisamos diretórios web e caminhos do sistema à procura de alterações na janela de tempo relevante e avaliamos o mtime e o ctime em conjunto.
- Verificar face aos originais: comparamos com pacotes, repositório, somas de verificação do CMS e as suas cópias de segurança.
- Avaliar achados: separamos alterações regulares de manipulações e guardamos provas.
- Limpar: com a remoção de malware, restabelecemos um estado limpo e documentamo-lo.
Perguntas frequentes
Como encontro todos os ficheiros alterados desde uma determinada data?
Com find e a opção -newermt, por exemplo find /var/www -type f -newermt "2026-10-17". Para alterações nos metadados, use -newerct. Ambos os comandos só leem e não alteram nada.
Qual é a diferença entre mtime e ctime?
O mtime é o momento da última alteração do conteúdo e pode ser retrodatado com meios simples. O ctime é o momento da última alteração do conteúdo ou dos metadados e não é tão fácil de falsificar. Se os dois divergirem muito, vale a pena olhar com atenção.
Como excluo ficheiros de cache da pesquisa?
Com -not -path para pastas conhecidas de cache, registos e sessões. Mas não exclua com demasiada generosidade, porque os atacantes gostam de guardar ficheiros precisamente onde muitas alterações são normais.
Que verificação é a mais fiável?
A comparação com uma fonte de confiança: somas de verificação do gestor de pacotes, um repositório Git ou uma cópia de segurança anterior ao incidente. Os carimbos de data/hora são um bom começo, mas não uma prova.