Kort gezegd: Of een server via PHP2Shell is gehackt, laat zich niet aan één enkel kenmerk aflezen. Er zijn geen gepubliceerde, bevestigde Indicators of Compromise; de herkenning berust op gedragsanalyse. Typische tekenen zijn nieuwe PHP-bestanden, onbekende cronjobs en ongebruikelijke verbindingen. Veiligstel eerst de logs vanaf 20 oktober voordat u iets wijzigt.
Zijn er ondubbelzinnige tekenen van een PHP2Shell-aanval?
Nee, en dat is het eerlijke antwoord. Voor veel bekende kwetsbaarheden publiceren fabrikanten of beveiligingsbedrijven concrete sporen: bestandsnamen, controlesommen, IP-adressen. Voor PHP2Shell bestaan zulke bevestigde Indicators of Compromise tot nu toe niet.
Wat bekend is: volgens berichten in de media werd op 17 oktober een eerste aanvalspoging waargenomen, vier dagen vóór de patches van 21 oktober. Cloudflare meldde verdere pogingen. Bevestigde succesvolle aanvallen op grote schaal waren volgens het BSI (de Duitse federale dienst voor informatiebeveiliging) aanvankelijk niet bekend. Wie tussen 17 oktober en de eigen patch onbeschermd bereikbaar was, moet daarom controleren in plaats van hopen.
Voor de inschatting telt vooral de periode. Tussen de eerste waargenomen aanvalspoging op 17 oktober en de patches op 21 oktober was er geen officiële update. Elke openbaar bereikbare PHP-server was in die tijd mogelijk kwetsbaar voor aanvallen. Hoe lang uw server daarna nog openstond, hangt ervan af wanneer de update is geïnstalleerd en PHP is herstart. Hoe langer die periode en hoe gevoeliger de gegevens, bijvoorbeeld klantaccounts, bestellingen of sollicitaties, des te grondiger moet de controle zijn.
Typische tekenen dat een server is gehackt
Na een geslaagde code-uitvoering proberen aanvallers meestal zich vast te zetten en de server te gebruiken. Daaruit volgen tekenen die niet specifiek voor PHP2Shell zijn, maar bij elke inbraakcontrole tellen:
- Nieuwe of gewijzigde PHP-bestanden, vooral in upload-, cache- of afbeeldingsmappen waar anders geen PHP-bestanden staan.
- Onbekende cronjobs of geplande taken, bijvoorbeeld voor de gebruiker van de webserver.
- Ongebruikelijke uitgaande verbindingen naar onbekende adressen, hoge netwerkbelasting of mailverzending die niemand heeft aangestuurd.
- Nieuwe beheerdersaccounts in CMS of shop, gewijzigde wachtwoorden, onbekende SSH-sleutels.
- Opvallende belasting: permanent hoge CPU-belasting door onbekende processen, vaak een aanwijzing voor cryptomining.
- Zichtbare gevolgen: doorverwijzingen naar vreemde sites, spampagina's in de Google-index, waarschuwingen in de browser of in de Search Console.
Geen van deze tekenen bewijst op zichzelf een inbraak, en hun afwezigheid bewijst het tegendeel niet. Beslissend is het totaalbeeld.
Eerste controles zonder sporen te vernietigen
Voordat u iets wist of herstart: veiligstel de logs. De vakpers adviseert serverlogs vanaf 20 oktober te bewaren. Kopieer webserver-, PHP- en systeemlogs naar een veilige plaats buiten de server.
Daarna helpen puur lezende controles. Paden en gebruikersnamen verschillen per systeem:
# PHP-bestanden die sinds 17-10 zijn gewijzigd
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP-bestanden in uploadmappen (voorbeeld WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Cronjobs van de gebruiker van de webserver en systeembreed
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# actieve netwerkverbindingen met proces
ss -tunp
# laatste aanmeldingen
last -n 30
Let op: aanvallers kunnen tijdstempels van bestanden vervalsen. Een onopvallend resultaat van find is daarom geen vrijspraak. Hoe u logs gericht analyseert, beschrijft Webserverlogs na een aanval analyseren; hoe u achterdeuren vindt, Webshells herkennen en verwijderen.
Vindt u concrete aanwijzingen, bijvoorbeeld een onbekend PHP-bestand in de uploadmap: niet wissen, niet opnieuw opzetten, de toepassing niet „snel repareren”. Server van het netwerk scheiden of isoleren, logs en systeemkopie veiligstellen en een gestructureerde incidentafhandeling beginnen.
Wat u niet moet doen
- Alleen patchen en doorgaan. Een patch verwijdert geen reeds binnengebrachte schadelijke software.
- Verdachte bestanden meteen wissen. Daarmee verdwijnen bewijzen voor wat er is gebeurd en welke gegevens getroffen kunnen zijn.
- De server opnieuw opzetten voordat er een kopie is gemaakt. De oorzaak blijft onduidelijk, en een achterdeur in database of toegangsgegevens overleeft de nieuwe installatie.
- Oude back-ups ongecontroleerd terugzetten. Ook een back-up kan de achterdeur al bevatten.
- Toegangsgegevens vergeten. Na een code-uitvoering kunnen databasewachtwoorden, API-sleutels en andere toegangsgegevens uit configuratiebestanden zijn weggelekt. Vernieuw ze na de reiniging, niet ervoor, zodat een nog actieve aanvaller de nieuwe niet meteen meeleest.
Als het vermoeden zich bevestigt
Dan gaat het om meer dan techniek. Beoordeel met uw functionaris voor gegevensbescherming of een melding op grond van de AVG nodig is; de termijn bedraagt 72 uur vanaf kennisname, details onder AVG-meldplicht. Informeer uw cyberverzekeraar vroegtijdig, indien aanwezig, en stem met een advocaat af of aangifte moet worden gedaan. Wij geven daarover algemene aanwijzingen, geen juridisch advies.
Hoe helpt PHP SOS concreet?
Met onze incident response handelen we een vermoeden gestructureerd af:
- Veiligstellen: logs vanaf 20 oktober en, waar nodig, een kopie van het systeem voordat er iets wordt gewijzigd.
- Onderzoeken: gedragsanalyse van bestanden, processen, verbindingen en accounts; zo nodig bewijskrachtig met IT-forensica.
- Reinigen en sluiten: achterdeuren verwijderen, PHP bijwerken, toegangsgegevens vernieuwen, server hardenen.
- Documenteren, tot het incident is afgesloten en gedocumenteerd, als grondslag voor gegevensbescherming, verzekering en directie.
Veelgestelde vragen
Bewijst de PHP-update dat mijn server schoon is?
Nee. Een patch dicht het lek voor de toekomst, maar verwijdert geen reeds binnengebrachte schadelijke software. Hij zegt ook niets over of er vóór de patch iemand is binnengedrongen.
Is er een scanner die PHP2Shell-aanvallen zeker herkent?
Tot nu toe niet. Er zijn geen gepubliceerde, bevestigde Indicators of Compromise waarnaar een scanner gericht kan zoeken. Malwarescanners vinden bekende webshells, maar de beoordeling van een server berust op gedragsanalyse.
Moet ik een vermoeden melden bij de toezichthouder voor gegevensbescherming?
Dat hangt ervan af of persoonsgegevens getroffen kunnen zijn. De AVG kent voor meldplichtige datalekken een termijn van 72 uur vanaf kennisname. Bespreek dat vroeg met uw functionaris voor gegevensbescherming of een advocaat; wij geven daarover geen juridisch advies.
Moet ik de gehackte server gewoon opnieuw opzetten?
Niet als eerste stap. Veiligstel eerst logs en, indien mogelijk, een kopie van het systeem. Wie meteen opnieuw opzet, verliest de sporen die laten zien wat er is gebeurd en welke gegevens getroffen kunnen zijn.