Kort gezegd: Treft een aanval meer dan één website, dan hebt u een incident response-dienstverlener nodig die het incident gestructureerd afhandelt. Wij nemen het situatiebeeld, de beperking, de reiniging en het veilige herstel over, met duidelijke rollen en sluitende documentatie. U behoudt de beslissingen, wij zorgen voor de technische grondslag.
Wat incident response bij serveraanvallen inhoudt
Incident response is de ordelijke afhandeling van een beveiligingsincident. In plaats van hectische losse acties volgt het werk vaste fasen: herkennen en inschatten, beperken, opruimen, herstellen, nazorg. Elke maatregel wordt met tijdstip en motivering vastgelegd.
Juist bij webservers is dat belangrijk. Een server met PHP-toepassingen bevat vaak toegangsgegevens tot databases, betaaldienstverleners, mailservers en koppelingen. Wie daar is binnengedrongen, kan zich verder verplaatsen. De situatie na PHP2Shell laat zien hoe snel zo'n situatie kan ontstaan: niet-geauthenticeerde code-uitvoering, volgens Unit 42 meer dan 22,6 miljoen blootgestelde instanties en geen gepubliceerde, bevestigde Indicators of Compromise.
Wanneer u een incident response-dienstverlener nodig hebt
- meerdere servers of toepassingen zijn getroffen of kunnen getroffen zijn
- er bestaat een vermoeden dat persoonsgegevens of betaalgegevens zijn weggelekt
- een aanvaller is mogelijk nog actief, bijvoorbeeld door lopende verbindingen of nieuwe accounts
- er is sprake van afpersing of een openbare aankondiging van de aanval
- verzekeraar, instanties of zakenpartners verwachten een gedocumenteerd verloop
Bij één enkele besmette website volstaat vaak de noodhulp bij een gehackte website. De overgang naar de volledige incidentafhandeling bespreken we met u zodra een grotere omvang zich aftekent.
Hoe helpt PHP SOS concreet?
- Triage en situatiebeeld: wij bespreken wat is waargenomen, welke systemen en gegevens getroffen kunnen zijn en wie intern moet worden betrokken. Resultaat is een eerste, schriftelijk situatiebeeld met openstaande vragen.
- Sporen veiligstellen en beperken: logs, bestandssystemen en databases worden veiliggesteld voordat we ingrijpen. Daarna isoleren we getroffen systemen, blokkeren we gecompromitteerde toegangen en onderbreken we herkenbare verbindingen van de aanvaller.
- Opruimen: wij sluiten de toegangspoort, bijvoorbeeld door te patchen naar de verholpen PHP-versies en alle workers te herstarten, verwijderen achterdeuren en vervangen geheimen. Voor de detailanalyse betrekken we zo nodig gespecialiseerde partners voor IT-forensica.
- Herstellen: systemen gaan gecontroleerd weer in bedrijf, bij voorkeur vanuit schone bronnen of op opnieuw opgezette servers. Daarna bewaken we ze extra op nieuwe opvallende zaken.
- Nazorg: u ontvangt een eindrapport met tijdlijn, oorzaken, maatregelen en aanbevelingen. Samen leggen we vast wat de volgende keer sneller moet.
Bewaar serverlogs en wijzig geen systemen voordat er een kopie is veiliggesteld. Het BSI adviseert bij PHP2Shell webservers die niet direct te patchen zijn tijdelijk van het netwerk te halen.
Rollen en communicatie tijdens het incident
Een incident vraagt om duidelijke verantwoordelijkheden. Bewezen werkt een kleine kring van een beslissingsbevoegd persoon, een technisch aanspreekpunt aan uw kant en wij als technisch leiding. Situatiebesprekingen vinden met vaste tussenpozen plaats, resultaten worden schriftelijk vastgelegd.
Parallel lopen taken die wij niet overnemen, maar waarvoor wij feiten leveren: de beoordeling van een meldplicht op grond van de AVG binnen 72 uur, het informeren van de verzekeraar, een mogelijke aangifte en de crisiscommunicatie naar klanten en partners.
Wat wij van u nodig hebben en wat u krijgt
Wij hebben administratieve toegang tot de getroffen systemen nodig, een overzicht van de infrastructuur en dienstverleners, een beslissingsbevoegd persoon en de bereidheid systemen zo nodig tijdelijk uit te schakelen. Nuttig zijn bestaande noodplannen, netwerkschema's en back-ups met datum.
U krijgt een doorlopend incidentprotocol, regelmatige situatiebeelden in begrijpelijke taal, een eindrapport voor directie, functionarissen voor gegevensbescherming en verzekeraar en een geprioriteerde lijst van verbeteringen. Hoe u zich beter opstelt voor het volgende incident, beschrijft IT-noodplan voor webservers opstellen.
Typische fouten in de eerste uren
Veel incidenten worden zwaarder doordat in de opwinding goedbedoelde stappen in de verkeerde volgorde gebeuren. Deze patronen zien wij vaak:
- Meteen opnieuw opzetten: de server wordt gewist en opnieuw geïnstalleerd voordat er een kopie is veiliggesteld. Daarna valt niet meer vast te stellen of gegevens zijn weggelekt.
- Wachtwoorden wijzigen vanaf het besmette systeem: als de aanvaller nog toegang heeft, ziet hij de nieuwe wachtwoorden mee.
- Alleen het zichtbare bestand wissen: de webshell is weg, de tweede achterdeur in de cronjob blijft.
- Patchen zonder herstart: nieuwe PHP-bestanden staan op de schijf, de oude workers draaien door in het geheugen.
- Niemand houdt een protocol bij: later weet niemand meer wie wanneer wat heeft gewijzigd. Dat bemoeilijkt gesprekken met verzekeraar en instanties.
Een afgestemd verloop voorkomt deze fouten zonder de beperking van de aanval te vertragen.
Wat we niet beloven
Wij beloven niet dat elk incident volledig wordt opgehelderd; zonder sporen blijven vragen open, en dat schrijven we ook zo in het rapport. Wij geven geen juridisch advies en doen geen uitspraken over aansprakelijkheid of verzekeringsdekking. Ons doel is een duidelijk einde: we werken aan het incident tot het is afgesloten en gedocumenteerd.
Veelgestelde vragen
Wat is het verschil tussen incident response en IT-forensica?
Incident response heeft als doel het incident te beperken en de bedrijfsvoering veilig te herstellen. IT-forensica stelt gedetailleerd en bewijskrachtig vast wat er is gebeurd. In de praktijk grijpen beide in elkaar; de forensica veiligstelt vaak parallel sporen.
Wanneer moet ik een incident response-dienstverlener inschakelen?
Zodra het vermoeden bestaat dat een aanvaller toegang had tot systemen en u de omvang niet zeker kunt inschatten. Hoe eerder het sporenbehoud begint, hoe meer er later kan worden aangetoond.
Wie beslist tijdens het incident?
De beslissingen neemt u, bijvoorbeeld over uitschakelingen, communicatie of meldingen. Wij bereiden de technische grondslagen voor, tonen opties met hun gevolgen en voeren de beslissingen uit.
Moet ik de politie inschakelen?
Een aangifte is in veel gevallen zinvol en voor sommige verzekeringen relevant. De centrale aanspreekpunten cybercrime van de politie zijn daarvoor bevoegd. Of en wanneer u aangifte doet, beslist u samen met uw advocaat.