Kort gezegd: Gewijzigde bestanden vindt u onder Linux met find en een tijdvenster, bijvoorbeeld vanaf 17 oktober 2026, volgens mediaberichten de eerste waargenomen aanvalspoging op PHP2Shell. Controleer daarbij niet alleen de wijzigingstijd van de inhoud (mtime), maar ook die van de metagegevens (ctime), omdat de eerste gemakkelijk te vervalsen is. Betrouwbaar wordt het resultaat pas door de vergelijking met pakketcontrolesommen, Git of een back-up.
Waarom tijdstempels een goed begin zijn, maar geen bewijs
Wie code op een server brengt, wijzigt bestanden. Nieuwe webshells, aangepaste configuratiebestanden, toegevoegde regels in bestaande scripts: dat alles laat tijdstempels achter. Het zoeken naar wijzigingen in het juiste tijdvenster is daarom een van de snelste wegen naar eerste vondsten.
Voor PHP2Shell biedt zich 17 oktober 2026 aan als begin van het venster, de dag van de volgens mediaberichten eerste waargenomen aanvalspoging. De patches verschenen op 21 oktober. Wie zijn server pas daarna heeft bijgewerkt, zoekt tot de dag van de eigen update en daarna. Hoe u webshells onder de vondsten herkent, beschrijft Webshell herkennen en verwijderen. Hier gaat het om de zoekmethode zelf.
De drie tijdstempels van een bestand
Linux slaat bij elk bestand meerdere tijdstippen op. Voor het zoeken naar wijzigingen zijn er twee beslissend.
| Tijdstempel | Betekenis | Vervalsbaar? |
|---|---|---|
| mtime | laatste wijziging van de inhoud | ja, bijv. met touch, door iedereen die het bestand mag schrijven |
| ctime | laatste wijziging van inhoud of metagegevens zoals rechten | niet met eenvoudige middelen |
| atime | laatste leestoegang | vaak uitgeschakeld of onnauwkeurig, weinig geschikt voor de zoekopdracht |
Aanvallers dateren de mtime graag terug naar de datum van de naastgelegen bestanden, zodat een nieuw bestand niet opvalt. De ctime verandert daarbij echter mee. Een bestand met oude mtime en verse ctime is daarom een sterke aanwijzing voor manipulatie.
Let bij de vergelijking op tijdzones. find en ls tonen de lokale tijd van de server, veel logbestanden en services werken daarentegen in UTC. Wie vondsten uit bestandssysteem en logs naast elkaar legt, moet alle gegevens naar dezelfde tijdzone omrekenen, anders lijken gebeurtenissen niet bij elkaar te passen. De patches verschenen ongeveer op 21 oktober om 14:00 UTC, dus om 16:00 uur Duitse tijd.
Gewijzigde bestanden onder Linux met find vinden
Alle opdrachten lezen alleen. Pas pad en datum aan.
# Inhoud sinds 17 oktober 2026 gewijzigd, gesorteerd, met mtime, ctime en eigenaar
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metagegevens sinds 17 oktober 2026 gewijzigd (vindt ook teruggedateerde bestanden)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Bekende ruis uitfilteren: cache, logs, sessies
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Ook buiten de webmap kijken
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
Vergelijk bij elke treffer beide tijdstempels. Is de ctime duidelijk jonger dan de mtime, en heeft niemand in die tijd rechten gewijzigd of bestanden gekopieerd, dan hoort het bestand op de lijst. Let ook op eigenaren: een bestand van de webservergebruiker tussen bestanden van de deploy-gebruiker valt op.
Vergeet verborgen bestanden en mappen niet. Namen die met een punt beginnen, tonen veel bestandsbeheerders en een eenvoudige ls niet. Aanvallers gebruiken dat graag, net als namen die sterk lijken op echte bestanden.
# Verborgen bestanden en mappen in de webmap, zonder bekende zoals .htaccess en .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Vergelijken met een betrouwbare bron
Tijdstempels tonen waar iets is bewogen. Of het een legitieme wijziging was, toont pas de vergelijking met een bron die u vertrouwt.
- Pakketbeheerder: Voor systeembestanden controleren
dpkg --verify(Debian/Ubuntu) ofrpm -Va(RHEL-familie) de bestanden tegen de controlesommen van de geïnstalleerde pakketten. Configuratiebestanden wijken legitiem af, programmabestanden niet. - Git: Staat de toepassing in een repository, dan toont
git -C /var/www/projekt status --porcelainelke afwijking van de laatste commit. - CMS-controlesommen: Veel systemen kunnen hun kernbestanden vergelijken met de officiële controlesommen, zie CMS-kernbestanden met het origineel vergelijken.
- Back-up van vóór het incident: Een vergelijking in proefmodus somt verschillen op zonder iets te kopiëren.
# Verschillen tussen back-upstand en live-systeem alleen opsommen (proefmodus, kopieert niets)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
De back-upvergelijking veronderstelt dat de back-up vóór het incident is ontstaan en zelf niet is gewijzigd. Waarom gescheiden bewaarde back-ups hier beslissend zijn, legt Back-ups volgens de 3-2-1-regel uit.
Bewaar de resultaten van elke zoekopdracht met datum in een bestand buiten de server. Uit deze lijsten ontstaat later de tijdlijn van het incident, en ze bewijzen wat u wanneer hebt gecontroleerd.
Als er geen back-up en geen repository is
Bij veel kleinere websites bestaat geen schone vergelijkingsbasis: geen Git, geen back-up van vóór het incident, plug-ins jarenlang met de hand bijgewerkt. Geheel zonder aanknopingspunt bent u toch niet.
Download het CMS en de extensies in precies de geïnstalleerde versies bij de fabrikant en vergelijk die bestanden met de server. Wat daar afwijkt of ontbreekt, verdient een blik. Wat overblijft, zijn uw eigen aanpassingen, uploads en configuratie; daar helpt de zoekopdracht op tijdstempels, aangevuld met een blik op eigenaar en rechten. Bestanden die als enige in een map een andere groep, andere rechten of een duidelijk jongere ctime dan hun buren hebben, horen op de lijst.
Eerlijk gezegd: zonder vergelijkingsbasis blijft een restonzekerheid. Bij systemen met gevoelige data is een heropbouw uit schone bronnen dan vaak betrouwbaarder dan het zoeken naar elk afzonderlijk gewijzigd bestand. Voor de toekomst is de les eenvoudig: een repository voor de code en regelmatige, gescheiden bewaarde back-ups.
Typische foutbronnen bij het zoeken
- Te royale uitsluitingen: Cache- en uploadmappen zijn geliefde schuilplaatsen.
- Alleen mtime gecontroleerd: Teruggedateerde bestanden glippen erdoor.
- Deployment in het tijdvenster: Een reguliere uitrol wijzigt honderden bestanden en verhult afzonderlijke vondsten. Vergelijk met de repository.
- Bestanden al geopend of gekopieerd: Kopieën zonder behoud van de tijdstempels vernietigen sporen. Maak back-ups met hulpmiddelen die tijdstempels behouden.
- Alleen de webmap doorzocht: Aanvallers plaatsen hulpmiddelen ook in
/tmp,/dev/shmof in de thuismap van de webservergebruiker. - Rechtenwijzigingen over het hoofd gezien: Een bestand waarvan de rechten plotseling schrijftoegang voor iedereen toestaan, is een vondst, ook als de inhoud ongewijzigd is.
Hoe de vondsten tot een verloop worden samengevoegd, toont De tijdlijn van een incident opstellen.
Hoe helpt PHP SOS concreet?
- Systematisch zoeken: Wij doorzoeken webmappen en systeempaden op wijzigingen in het relevante tijdvenster en beoordelen mtime en ctime samen.
- Tegen originelen controleren: Wij vergelijken met pakketten, repository, CMS-controlesommen en uw back-ups.
- Vondsten beoordelen: Wij scheiden reguliere wijzigingen van manipulaties en stellen bewijs veilig.
- Opschonen: Met de malwareverwijdering herstellen wij een schone stand en documenteren wij die.
Veelgestelde vragen
Hoe vind ik alle bestanden die sinds een bepaalde datum zijn gewijzigd?
Met find en de optie -newermt, bijvoorbeeld find /var/www -type f -newermt "2026-10-17". Voor wijzigingen aan de metagegevens gebruikt u -newerct. Beide opdrachten lezen alleen en wijzigen niets.
Wat is het verschil tussen mtime en ctime?
mtime is het tijdstip van de laatste wijziging van de inhoud en laat zich met eenvoudige middelen terugdateren. ctime is het tijdstip van de laatste wijziging aan inhoud of metagegevens en laat zich niet zo gemakkelijk vervalsen. Wijken beide sterk van elkaar af, dan loont een nauwkeurige blik.
Hoe sluit ik cachebestanden uit van de zoekopdracht?
Met -not -path voor bekende cache-, log- en sessiemappen. Sluit echter niet te royaal uit, want aanvallers plaatsen bestanden graag precies waar veel wijzigingen normaal zijn.
Welke controle is het betrouwbaarst?
De vergelijking met een betrouwbare bron: controlesommen van de pakketbeheerder, een Git-repository of een back-up van vóór het incident. Tijdstempels zijn een goed begin, maar geen bewijs.