Kort gezegd: Om CMS-kernbestanden te controleren, vergelijkt u de geïnstalleerde bestanden met een schoon origineel van dezelfde versie: bij WordPress via de officiële controlesommen, bij andere systemen via een verse download of een nabouw uit de composer.lock. Elke afwijking is een controleopdracht. De vergelijking vindt ook onbekende schadelijke code, maar dekt alleen bestanden af waarvoor een origineel bestaat.
Waarom de vergelijking meer vindt dan welke signatuur ook
Malwarescanners zoeken naar bekende patronen. Wat ze niet kennen, zien ze over het hoofd. Een vergelijking met het origineel werkt andersom: ze vraagt niet of een bestand verdacht oogt, maar of het exact overeenkomt met wat de fabrikant heeft geleverd. Elke afwijking valt op, of ze nu een bekend patroon volgt of niet.
Dat is na PHP2Shell bijzonder waardevol. Voor de kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 bestaan geen gepubliceerde, bevestigde Indicators of Compromise. Scanners kunnen dus niet gericht zoeken naar PHP2Shell-sporen. Een vergelijking met het origineel vindt daarentegen elke wijziging aan de kern, ongeacht hoe die is ontstaan. Waarom scanners alleen niet volstaan, legt het artikel Malwarescanners voor websites: wat ze wel en niet vinden uit.
Het principe: dezelfde versie, schone bron
Een vergelijking is maar zo goed als haar referentie. Aan drie voorwaarden moet worden voldaan:
- Exact dezelfde versie: een vergelijking met een nieuwere versie toont honderden onschuldige verschillen. Achterhaal de geïnstalleerde versie uit de applicatie of de
composer.lock. - Officiële bron: het origineel komt van de fabrikant, uit de officiële pakketdirectory of uit uw eigen versiebeheersysteem. Niet uit een oude back-up van de getroffen server.
- Vergelijking op een kopie: werk op een veiliggestelde kopie van de webmap, zodat tijdstempels en sporen behouden blijven.
| Systeem | Referentie | Hulpmiddel |
|---|---|---|
| WordPress-kern en plug-ins uit de directory | Controlesommen van WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Composer-projecten (bijv. Shopware 6, Laravel, Symfony, Drupal, TYPO3 in Composer-modus) | Nabouw uit composer.lock |
composer install in lege map, daarna diff |
| CMS met downloadpakket | Pakket van dezelfde versie van de fabrikant | diff -rq |
| Eigen projecten met Git | laatst bekende commit | git status, git diff |
| Systeempakketten van de server | Pakketdatabase van de distributie | dpkg --verify, rpm -Va |
WordPress: meer dan verify-checksums
Hoe u kern en plug-ins met WP-CLI controleert, staat in de gids Backdoors in WordPress vinden. Een aanvulling loont: volgens de WP-CLI-documentatie controleert de optie --include-root alle bestanden en mappen in de hoofdmap en waarschuwt ze voor items die niet bij WordPress horen. Daar zetten aanvallers graag bestanden neer met namen die aan kernbestanden doen denken.
# Kern tegen officiële controlesommen, inclusief vreemde bestanden in de hoofdmap
wp core verify-checksums --include-root
Commerciële plug-ins en thema's dekt deze weg niet af. Daarvoor downloadt u het originele pakket van dezelfde versie bij de aanbieder en vergelijkt u met diff.
CMS-kernbestanden controleren bij Composer-projecten
Veel moderne PHP-applicaties bestaan grotendeels uit pakketten die Composer installeert, het pakketbeheer voor PHP. Hoe het werkt, legt de pagina Composer: het pakketbeheer voor PHP uit. Het bestand composer.lock legt vast welke versies precies zijn geïnstalleerd. Volgens de Composer-documentatie gebruikt composer install exact deze versies. Daarmee kunt u de leveringstoestand nabouwen:
# Op een schoon systeem, niet op de getroffen server
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
# Verschillen in de vendor-map opsommen
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
De opties --no-scripts en --no-plugins voorkomen dat bij de nabouw scripts uit de pakketten worden uitgevoerd. Is de productie met --no-dev geïnstalleerd, gebruik die optie dan ook bij de nabouw, anders verschijnen ontwikkelpakketten als verschil. Let op twee soorten resultaten: bestanden die verschillen en bestanden die alleen op de server bestaan. De tweede groep is vaak de interessantere. Hoe u de geïnstalleerde pakketten daarnaast op bekende kwetsbaarheden controleert, beschrijft de gids Composer-afhankelijkheden controleren op kwetsbaarheden.
Ook het besturingssysteem vergelijken
Had een aanvaller rootrechten, dan kan hij ook systeemprogramma's hebben vervangen. De pakketbeheersystemen hebben een eigen vergelijking:
# Debian, Ubuntu: bestanden waarvan de inhoud afwijkt van het pakket
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: alle pakketten controleren
sudo rpm -Va
Een 5 op de derde plaats van de uitvoer betekent dat de inhoud van een bestand is veranderd. Volgens de dpkg-handleiding is de inhoudsvergelijking daar momenteel de enige werkende controle. Gewijzigde configuratiebestanden zijn normaal en gemarkeerd met c. Een gewijzigd programma in /usr/bin is daarentegen een serieus alarmsignaal. Let op: een aanvaller met rootrechten kan ook de pakketdatabase manipuleren. Bij vermoeden van roottoegang is een herinstallatie betrouwbaarder dan welke vergelijking ook.
Een versiebeheersysteem voor de applicatiecode maakt toekomstige vergelijkingen een kwestie van seconden. git status toont dan elke afwijking van de vrijgegeven toestand.
Afwijkingen beoordelen en grenzen kennen
Niet elke afwijking is een aanval. Sommige bureaus hebben vroeger kernbestanden rechtstreeks aangepast in plaats van uitbreidingen te gebruiken. Taalpakketten, regeleinden na een overdracht via FTP of achteraf doorgevoerde correcties veroorzaken eveneens verschillen. Beslissend is of iemand de wijziging kan verklaren.
Loop elke afwijking afzonderlijk na en noteer het resultaat: bekend en gedocumenteerd, onschuldig te verklaren of onduidelijk. Onduidelijke bestanden opent u alleen als tekst op een kopie en vervangt u uit de schone bron. Bij bestanden die alleen op de server bestaan is de vraag eenvoudiger: wie ze niet kent, moet ze laten veiligstellen en verwijderen nadat hun inhoud is gecontroleerd.
Uploads, configuratiebestanden zoals wp-config.php of .env, eigen aanpassingen en caches hebben geen origineel. Ze moeten gericht worden gecontroleerd, net als de database, cronjobs, gebruikersaccounts en SSH-sleutels. Een schone vergelijking is daarom een belangrijke bouwsteen, maar geen vrijspraak voor de hele server.
Hoe helpt PHP SOS concreet?
- Wij stellen de geïnstalleerde versies vast en bouwen een schone referentie op uit officiële bronnen.
- Wij vergelijken kern, uitbreidingen, Composer-pakketten en systeemprogramma's en beoordelen elke afwijking.
- Wij controleren de gebieden zonder origineel gericht en vervangen gewijzigde bestanden in het kader van de verwijdering van malware uit een schone bron.
- Op verzoek richten wij een versiestand in waartegen toekomstige controles draaien.
Veelgestelde vragen
Hoe controleer ik of WordPress-kernbestanden zijn gewijzigd?
Met WP-CLI en de opdracht wp core verify-checksums. Die vergelijkt de bestanden met de controlesommen die WordPress.org voor de geïnstalleerde versie publiceert. Met de optie --include-root waarschuwt WP-CLI bovendien voor bestanden in de hoofdmap die niet bij WordPress horen.
Wat doe ik bij een CMS zonder ingebouwde controlefunctie?
U downloadt exact dezelfde versie van de officiële bron van de fabrikant en vergelijkt beide mappen met diff. Bij Composer-projecten bouwt u de toestand uit de composer.lock in een lege map na en vergelijkt de vendor-map.
Vindt de vergelijking ook schadelijke code in plug-ins en thema's?
Alleen als er voor die onderdelen een schoon origineel bestaat, bijvoorbeeld uit de officiële directory of van de aanbieder. Eigen aanpassingen, uploads en configuratiebestanden hebben geen origineel en moeten apart worden gecontroleerd.
Vervangt de vergelijking een malwarescanner?
Ze vult hem aan. De vergelijking vindt elke wijziging aan bekende bestanden, ook onbekende schadelijke code. Maar ze zegt niets over bestanden zonder origineel, de database, cronjobs of toegangen.