Em resumo: Para verificar os ficheiros principais do CMS, compare os ficheiros instalados com um original limpo da mesma versão: no WordPress, através das somas de verificação oficiais; noutros sistemas, através de uma transferência nova ou de uma reconstrução a partir do composer.lock. Cada divergência é uma tarefa de verificação. A comparação encontra também código malicioso desconhecido, mas só abrange os ficheiros para os quais existe um original.
Por que razão a comparação encontra mais do que qualquer assinatura
Os scanners de malware procuram padrões conhecidos. O que não conhecem, deixam passar. Uma comparação com o original funciona ao contrário: não pergunta se um ficheiro parece suspeito, mas se corresponde exatamente ao que o fabricante entregou. Qualquer divergência salta à vista, siga ou não um padrão conhecido.
Depois do PHP2Shell, isto é particularmente valioso. Para as vulnerabilidades CVE-2026-109618 e CVE-2026-109619 não existem indicadores de comprometimento publicados e confirmados. Os scanners não podem, portanto, procurar de forma dirigida vestígios do PHP2Shell. Uma comparação com o original encontra, em contrapartida, qualquer alteração ao núcleo, independentemente de como surgiu. Por que razão os scanners, sozinhos, não bastam é explicado no artigo Scanners de malware para sites: o que encontram e o que não encontram.
O princípio: mesma versão, fonte limpa
Uma comparação só vale o que valer a sua referência. É preciso cumprir três condições:
- Exatamente a mesma versão: uma comparação com uma versão mais recente mostra centenas de diferenças inofensivas. Determine a versão instalada a partir da aplicação ou do
composer.lock. - Fonte oficial: o original vem do fabricante, do diretório oficial de pacotes ou do seu próprio sistema de controlo de versões. Não de uma cópia de segurança antiga do servidor afetado.
- Comparação numa cópia: trabalhe numa cópia preservada do diretório web, para que as datas e os vestígios se mantenham.
| Sistema | Referência | Ferramenta |
|---|---|---|
| Núcleo do WordPress e plugins do diretório | somas de verificação do WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Projetos Composer (p. ex. Shopware 6, Laravel, Symfony, Drupal, TYPO3 em modo Composer) | reconstrução a partir do composer.lock |
composer install num diretório vazio, depois diff |
| CMS com pacote de transferência | pacote da mesma versão, do fabricante | diff -rq |
| Projetos próprios com Git | último commit conhecido | git status, git diff |
| Pacotes de sistema do servidor | base de dados de pacotes da distribuição | dpkg --verify, rpm -Va |
WordPress: mais do que verify-checksums
O guia Encontrar backdoors no WordPress explica como verificar o núcleo e os plugins com o WP-CLI. Vale a pena um complemento: segundo a documentação do WP-CLI, a opção --include-root verifica todos os ficheiros e pastas no diretório principal e avisa sobre entradas que não pertencem ao WordPress. É aí que os atacantes gostam de deixar ficheiros cujos nomes fazem lembrar ficheiros principais.
# Núcleo contra as somas de verificação oficiais, incluindo ficheiros alheios no diretório principal
wp core verify-checksums --include-root
Os plugins e temas comerciais não são abrangidos por este caminho. Para eles, descarregue do fornecedor o pacote original da mesma versão e compare com diff.
Verificar os ficheiros principais do CMS em projetos Composer
Muitas aplicações PHP modernas são constituídas, em grande parte, por pacotes que o Composer instala, o gestor de pacotes do PHP. Como funciona é explicado na página Composer: o gestor de pacotes do PHP. O ficheiro composer.lock regista exatamente que versões estão instaladas. Segundo a documentação do Composer, o composer install utiliza essas versões exatas. Assim, é possível reconstruir o estado de entrega:
# Num sistema limpo, não no servidor afetado
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Listar as diferenças na pasta vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
As opções --no-scripts e --no-plugins impedem que, na reconstrução, sejam executados scripts dos pacotes. Se a produção foi instalada com --no-dev, use essa opção também na reconstrução; caso contrário, os pacotes de desenvolvimento aparecem como diferença. Atenção a dois tipos de resultado: ficheiros que diferem e ficheiros que existem apenas no servidor. O segundo grupo é muitas vezes o mais interessante. Como verificar adicionalmente os pacotes instalados quanto a vulnerabilidades conhecidas é descrito no guia Verificar dependências do Composer quanto a vulnerabilidades.
Comparar também o sistema operativo
Se um atacante teve direitos de root, pode também ter substituído programas do sistema. Os gestores de pacotes trazem uma comparação própria:
# Debian, Ubuntu: ficheiros cujo conteúdo diverge do pacote
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: verificar todos os pacotes
sudo rpm -Va
Um 5 na terceira posição da saída significa que o conteúdo de um ficheiro mudou. Segundo o manual do dpkg, a comparação do conteúdo é aí, atualmente, a única verificação eficaz. Os ficheiros de configuração alterados são normais e estão marcados com c. Um programa alterado em /usr/bin é, em contrapartida, um sinal de alarme sério. Tenha em conta: um atacante com direitos de root pode também manipular a base de dados de pacotes. Perante a suspeita de acesso root, uma reconstrução é mais fiável do que qualquer comparação.
Um sistema de controlo de versões para o código da aplicação torna as comparações futuras uma questão de segundos. O git status mostra então qualquer divergência em relação ao estado aprovado.
Avaliar as divergências e conhecer os limites
Nem toda a divergência é um ataque. Algumas agências adaptaram antes diretamente os ficheiros principais, em vez de usarem extensões. Pacotes de idiomas, fins de linha após uma transferência por FTP ou correções aplicadas posteriormente também geram diferenças. O decisivo é saber se alguém consegue explicar a alteração.
Analise cada divergência individualmente e anote o resultado: conhecida e documentada, explicável e inofensiva ou pouco clara. Os ficheiros pouco claros abra-os apenas como texto, numa cópia, e substitua-os a partir da fonte limpa. Nos ficheiros que existem apenas no servidor, a questão é mais simples: quem não os conhece deve mandar preservá-los e removê-los depois de o seu conteúdo ter sido verificado.
Os uploads, os ficheiros de configuração como wp-config.php ou .env, as adaptações próprias e as caches não têm original. Têm de ser verificados de forma dirigida, tal como a base de dados, as tarefas agendadas, as contas de utilizador e as chaves SSH. Uma comparação limpa é, por isso, uma peça importante, mas não uma absolvição de todo o servidor.
Como ajuda concretamente a PHP SOS?
- Determinamos as versões instaladas e montamos uma referência limpa a partir de fontes oficiais.
- Comparamos núcleo, extensões, pacotes Composer e programas do sistema e avaliamos cada divergência.
- Verificamos de forma dirigida as áreas sem original e substituímos os ficheiros alterados, a partir de uma fonte limpa, no âmbito da remoção de malware.
- Se pretender, configuramos um estado de versão contra o qual correm as verificações futuras.
Perguntas frequentes
Como verifico se os ficheiros principais do WordPress foram alterados?
Com o WP-CLI e o comando wp core verify-checksums. Compara os ficheiros com as somas de verificação que o WordPress.org publica para a versão instalada. Com a opção --include-root, o WP-CLI avisa também sobre ficheiros no diretório principal que não pertencem ao WordPress.
O que faço com um CMS sem função de verificação integrada?
Descarrega exatamente a mesma versão a partir da fonte oficial do fabricante e compara os dois diretórios com diff. Em projetos Composer, reconstrói o estado a partir do composer.lock num diretório vazio e compara a pasta vendor.
A comparação encontra também código malicioso em plugins e temas?
Só se existir um original limpo para eles, por exemplo do diretório oficial ou do fornecedor. As adaptações próprias, os uploads e os ficheiros de configuração não têm original e têm de ser verificados à parte.
A comparação substitui um scanner de malware?
Complementa-o. A comparação encontra qualquer alteração em ficheiros conhecidos, incluindo código malicioso desconhecido. Mas nada diz sobre ficheiros sem original, a base de dados, as tarefas agendadas ou os acessos.