# Encontrar ficheiros alterados recentemente no servidor web > Encontrar ficheiros alterados no Linux: janela de tempo com find, interpretar mtime e ctime, comparar com pacotes e cópias de segurança e filtrar falsos alarmes. Fonte: https://phpsos.de/pt/blog/geaenderte-dateien-finden/ 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:** 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](https://phpsos.de/pt/ratgeber/webshell-erkennen/). 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. ```bash # 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. ```bash # 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. 1. **Gestor de pacotes:** para ficheiros do sistema, `dpkg --verify` (Debian/Ubuntu) ou `rpm -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. 2. **Git:** se a aplicação estiver num repositório, `git -C /var/www/projekt status --porcelain` mostra qualquer divergência face ao último commit. 3. **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](https://phpsos.de/pt/blog/cms-kerndateien-vergleichen/). 4. **Cópia de segurança anterior ao incidente:** uma comparação em ensaio lista diferenças sem copiar nada. ```bash # 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](https://phpsos.de/pt/ratgeber/backups-3-2-1/). > **Dica:** > 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/shm` ou 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](https://phpsos.de/pt/blog/zeitleiste-eines-vorfalls/). ## 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](https://phpsos.de/pt/leistungen/malware-entfernung/), 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. ## Fontes - [BSI: Agência Federal Alemã para a Segurança da Informação](https://www.bsi.bund.de/) - [Debian Security Tracker](https://security-tracker.debian.org/) - [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)