Kort gezegd: Als uw website is gehackt, helpt deze checklist om niets te vergeten: eerst indammen en bewijs veiligstellen, dan de oorzaak vinden en opruimen, daarna alle toegangen vernieuwen, plichten controleren en het incident gedocumenteerd afsluiten. De volgorde is belangrijk, want wie eerst verwijdert, verliest sporen, en wie alleen opruimt zonder de kwetsbaarheid te dichten, wordt opnieuw aangevallen.
Waarvoor deze checklist geldt als de website is gehackt
De checklist is bedoeld voor directie, eigenaren en IT-verantwoordelijken na een bevestigde of waarschijnlijke aanval op een website, een webshop of een PHP-webserver. Ze is ook geschikt na PHP2Shell, als een server vóór de update bereikbaar was en er aanwijzingen zijn voor een compromittering.
Niet elk punt past op elke omgeving. Werk de lijst toch volledig door en noteer bij elk punt of het is afgehandeld, niet van toepassing of nog open is. Dit protocol is later waardevol voor verzekering, gegevensbescherming en interne nabespreking.
Noteer bij elke stap datum, tijdstip, verantwoordelijke persoon en resultaat. Zijn meerdere personen betrokken, wijs dan één persoon aan die de lijst bijhoudt en beslissingen vastlegt.
Fase 1: direct indammen en veiligstellen
- Schade beperken: Website in onderhoudsmodus zetten of van het netwerk halen als bezoekers gevaar lopen of gegevens kunnen weglekken. Het BSI (de Duitse federale dienst voor informatiebeveiliging) adviseert bij PHP2Shell ongepatchte webservers tijdelijk van het netwerk te halen als een update niet direct mogelijk is.
- Niets verwijderen: Geen bestanden verwijderen, de server niet opnieuw opzetten en geen logs legen voordat sporen zijn veiliggesteld.
- Logs veiligstellen: Toegangs-, fout-, PHP-FPM- en systeemlogs naar een ander systeem kopiëren en controlesommen vastleggen. Voor PHP2Shell adviseert de vakpers logs te bewaren vanaf 20-10-2026.
- Image veiligstellen: Een kopie van bestanden en database, bij virtuele servers een snapshot, aanmaken als bewijsstand en niet wijzigen.
- Verantwoordelijken informeren: Directie, functionaris voor gegevensbescherming, hoster en, indien aanwezig, cyberverzekering vroeg betrekken. Veel verzekeringen kennen meldingsverplichtingen.
Fase 2: oorzaak vinden en opruimen
- Toegangspoort vaststellen: Logs, bestandswijzigingen en versies analyseren. Controleer PHP zelf, CMS, thema's, extensies, toegangsgegevens en serverdiensten. Zonder bekende oorzaak blijft het risico van een nieuwe aanval bestaan.
- Kwetsbaarheid dichten: PHP naar een verholpen versie brengen (8.5.12, 8.4.27, 8.3.36 of 8.2.35 resp. bevestigde backport van de aanbieder), CMS en extensies bijwerken, alle PHP-workers herstarten.
- Periode afbakenen: Het vroegste tijdstip van verdachte activiteit bepalen. Het beslist welke back-ups schoon kunnen zijn en welke gegevens getroffen kunnen zijn.
- Achterdeurtjes verwijderen: Webshells, vreemde PHP-bestanden in upload- en cachemappen, gewijzigde kernbestanden, cronjobs, SSH-sleutels en systeemdiensten controleren en verwijderen. Kernbestanden vervangen vanuit een schone bron.
- Database opruimen: Onbekende beheerdersaccounts, binnengebrachte scripts in inhoud en instellingen en spaminhoud verwijderen.
- Heropbouw overwegen: Bij ingrijpende compromittering van de server is een heropbouw op een vers, gepatcht systeem met gecontroleerde gegevens vaak de betrouwbaardere weg dan opruiming op het draaiende systeem.
Fase 3: toegangen vernieuwen en verharden
- Wachtwoorden wijzigen: Voor CMS, hostingaccount, paneel, database, FTP, SFTP, SSH en e-mail, en wel vanaf een schoon apparaat.
- Sleutels en tokens vervangen: API-sleutels, koppelingen met betaal- en verzenddiensten, toepassingssleutels van het CMS, SSH-sleutels en certificaten die op de server stonden, opnieuw aanmaken.
- Sessies beëindigen: Alle actieve aanmeldingen in het CMS en bij diensten afmelden en geregistreerde tweefactorapparaten controleren.
- Tweefactorauthenticatie activeren: Voor alle beheertoegangen, inclusief hosting, domein en DNS.
- Server verharden: PHP-instellingen, bestandsrechten, uitvoeringsblokkades in uploadmappen, firewall en security headers controleren en documenteren.
Fase 4: plichten, communicatie en afsluiting
- Meldplichten controleren: Kunnen persoonsgegevens getroffen zijn, dan kan volgens art. 33 AVG een melding binnen 72 uur nodig zijn. De beoordeling hoort bij functionaris voor gegevensbescherming of advocaat. Branchespecifieke plichten, bijvoorbeeld volgens NIS2, apart controleren.
- Aangifte overwegen: De Zentrale Ansprechstellen Cybercrime van de Duitse politie nemen aangiftes van bedrijven op. De veiliggestelde logs zijn daarvoor een belangrijke basis.
- Klanten en Google informeren: Getroffenen zakelijk en afgestemd informeren. Toont Google een waarschuwing, vraag dan na de opruiming de herbeoordeling aan, zoals beschreven onder Google-waarschuwing verwijderen.
- Afsluiting documenteren en bewaken: Oorzaak, periode, maatregelen en openstaande punten in een rapport vastleggen, lessen voor het noodplan afleiden en de systemen in de weken daarna verscherpt bewaken.
Veelgemaakte fouten bij de nazorg
Veel incidenten slepen zich voort omdat in de eerste opwinding op de verkeerde plek wordt bespaard of te snel wordt gehandeld. Deze fouten moet u vermijden:
- Alleen het zichtbare verwijderen: Een verwijderde spampagina of een verwijderde doorverwijzing is geen bewijs voor een schone website. Achterdeurtjes blijven vaak onopgemerkt.
- Wachtwoorden wijzigen vanaf het getroffen systeem: Draait op de computer of server nog schadelijke software, dan kunnen nieuwe toegangsgegevens meteen weer weglekken.
- Blind een back-up terugzetten: Zonder gedichte kwetsbaarheid en zonder controle van de back-up staat de aanvaller snel weer in de deuropening.
- De patch als geruststelling zien: Een update naar een verholpen PHP-versie bewijst niet dat er eerder niets is gebeurd en verwijdert geen binnengebrachte schadelijke software.
- Plichten te laat controleren: Termijnen beginnen bij het bekend worden van het incident, niet bij het einde van de opruiming.
- Geen documentatie: Zonder protocol zijn vragen van verzekering, autoriteiten of klanten later nauwelijks te beantwoorden.
Deze checklist vervangt geen juridisch advies. Wend u bij vragen over meldplichten, aansprakelijkheid of verzekering tot uw functionaris voor gegevensbescherming, een advocaat of uw verzekeraar.
Hoe helpt PHP SOS concreet?
- We nemen de gestructureerde incident response over en doorlopen de checklist samen met u, punt voor punt met protocol.
- We stellen logs en systeemstanden zo veilig dat ze bruikbaar blijven voor verzekering, autoriteiten en een mogelijk IT-forensica-onderzoek.
- We dichten de kwetsbaarheid, ruimen op of bouwen opnieuw op en vernieuwen toegangen in de juiste volgorde.
- We leveren een eindrapport met oorzaak, maatregelen en aanbevelingen en bewaken de systemen daarna op verzoek verder.
Veelgestelde vragen
Wat is het eerste dat ik moet doen als mijn website is gehackt?
Kalm blijven, niets verwijderen en de schade beperken. Haal de website zo nodig van het netwerk of zet haar in onderhoudsmodus en zet logs en bestanden veilig voordat u opruimt. Daarna volgen oorzaakonderzoek en opruiming.
Volstaat het om de website uit een back-up te herstellen?
Meestal niet. De back-up kan al schadelijke code bevatten en de kwetsbaarheid waarlangs de aanvaller binnenkwam, staat na het terugzetten nog open. Eerst de oorzaak dichten, dan een gecontroleerde, schone stand op een bijgewerkt systeem installeren.
Moet ik een hack melden bij de toezichthouder voor gegevensbescherming?
Als persoonsgegevens getroffen kunnen zijn, voorziet art. 33 AVG in beginsel in een melding binnen 72 uur nadat het incident bekend is geworden, tenzij het onwaarschijnlijk is dat er een risico voor betrokkenen bestaat. De beoordeling hoort bij uw functionaris voor gegevensbescherming of een advocaat.
Wanneer is een incident echt afgesloten?
Wanneer de oorzaak is gedicht, alle bekende achterdeurtjes zijn verwijderd, toegangen zijn vernieuwd, plichten zijn vervuld en de maatregelen zijn gedocumenteerd. Een periode van verscherpte bewaking daarna hoort erbij, om over het hoofd geziene sporen te herkennen.
Bronnen
- AVG art. 33: melding aan de toezichthouder
- Politie: Zentrale Ansprechstellen Cybercrime (centrale contactpunten voor cybercriminaliteit bij de Duitse politie)
- BSI: aanwijzingen over IT-beveiligingsincidenten (Duitse federale dienst voor informatiebeveiliging)
- php.net: beveiligingsmeldingen over PHP2Shell