Kort gezegd: Of u een server na een hack opnieuw opzet of opschoont, hangt ervan af hoe zeker u de omvang van de inbraak kent. Had de aanvaller mogelijk rootrechten, is het tijdstip van de inbraak onduidelijk of ontbreken logs, dan is een wederopbouw uit betrouwbare bronnen de betrouwbaardere keuze. Opschonen komt alleen in aanmerking bij een nauw begrensde, goed aangetoonde besmetting. In beide gevallen geldt: eerst bewijs veiligstellen en het lek dichten, dan pas opruimen.
Waarom deze vraag na PHP2Shell bijzonder vaak wordt gesteld
PHP2Shell maakt volgens php.net de uitvoering van schadelijke code op afstand mogelijk zonder aanmelding. Wie een niet-gepatchte server beheerde, moet zich daarom afvragen of er sinds 17 oktober 2026, de volgens mediaberichten eerste waargenomen aanvalspoging, iets is gebeurd. De patch beantwoordt deze vraag niet, en er zijn geen gepubliceerde, bevestigde Indicators of Compromise.
Vindt u dan een verdacht bestand, een onbekend proces of een vreemde cronjob, dan moet u beslissen. De impuls is vaak snel te verwijderen of direct opnieuw te installeren. Beide kan juist zijn, maar niet als eerste stap.
De volgorde vóór de beslissing
Voordat u kiest tussen opschonen en opnieuw opzetten, moeten drie dingen zijn gedaan. Ze gelden voor beide wegen.
- Insluiten: de server van het netwerk halen of de toegang tot het hoogstnoodzakelijke beperken, zonder hem uit te schakelen als het werkgeheugen nog moet worden veiliggesteld.
- Bewijs veiligstellen: logs, bestanden, database en liefst een image van het systeem veiligstellen, met datum en controlesom. Waarom dat vóór elke herinstallatie nodig is, legt Bewijs veiligstellen voordat u opnieuw opzet uit.
- Verzekeraar en gegevensbescherming betrekken: veel cyberpolissen verwachten dat wezenlijke stappen worden afgestemd. Aanwijzingen staan onder Cyberverzekering: wat bij schade telt. Of er een meldplicht volgens de AVG bestaat, beoordelen de functionaris voor gegevensbescherming of een advocaat.
Pas daarna loont de eigenlijke afweging.
Server opnieuw opzetten na de hack of opschonen: de criteria
| Criterium | Opschonen | Opnieuw opzetten |
|---|---|---|
| Omvang van de inbraak | Nauw begrensd, aangetoond, bijv. een bestand in de uploadmap zonder verdere sporen | Onduidelijk of met aanwijzingen voor systeemtoegang |
| Mogelijke rootrechten van de aanvaller | Uitgesloten met goed bewijs | Niet uit te sluiten |
| Beschikbaarheid van logs | Volledig voor de relevante periode | Onvolledig, overschreven of te manipuleren |
| Inspanning | Lager, als de bevinding duidelijk is | Hoger, maar beter te plannen |
| Resterende onzekerheid | Hoger, verborgen achterdeuren zijn moeilijk uit te sluiten | Lager, als netjes uit betrouwbare bronnen opgebouwd |
| Uitvaltijd | Meestal korter | Meestal langer, met voorbereiding goed te sturen |
| Geschiktheid voor oude systemen | Problematisch als het systeem toch al verouderd is | Goede gelegenheid om over te stappen op een ondersteunde PHP-versie |
Als vuistregel geldt: hoe minder u weet, hoe meer pleit voor de wederopbouw. Bij een lek in de PHP-interpreter dat code uitvoert in de context van de webservergebruiker, kan een aanvaller andere kwetsbaarheden gebruiken om meer rechten te krijgen. Dat is zonder grondig onderzoek nauwelijks uit te sluiten.
Beide wegen in de praktijk
Wat „opnieuw opzetten“ werkelijk betekent
Opnieuw opzetten betekent niet de oude back-up op een verse server kopiëren. Een wederopbouw begint met een schoon besturingssysteem uit een officiële bron, actuele pakketten en een gepatchte PHP-versie. De toepassing wordt geïnstalleerd vanuit het origineel van de fabrikant, plug-ins en thema's idem.
Pas dan komen de eigen inhouden erbij, en wel gecontroleerd. Geüploade bestanden mogen geen uitvoerbare scripts bevatten, de database kan ingebrachte inhoud bevatten, zoals verborgen beheerdersaccounts of scripts in berichten. Configuratiebestanden worden nieuw geschreven in plaats van gekopieerd. Alle inloggegevens worden vernieuwd: database, CMS-beheerders, SSH-sleutels, API-sleutels, hostingpaneel.
Back-ups spelen daarbij een belangrijke rol, maar alleen als hun stand van vóór de inbraak stamt en ze zelf niet zijn gewijzigd. Meerdere generaties op gescheiden plaatsen maken dat controleerbaar; meer daarover onder Back-ups volgens de 3-2-1-regel.
Als opschonen verdedigbaar is
Opschonen kan zinvol zijn als de besmetting vroeg is ontdekt, er volledige logs zijn en het onderzoek geen aanwijzing voor verdere toegangen oplevert. Dan worden de gevonden bestanden na de veiligstelling verwijderd, cronjobs, gebruikersaccounts en SSH-sleutels gecontroleerd en kernbestanden met het origineel van de fabrikant vergeleken.
Belangrijk is een realistische inschatting: webshells zijn vaak onopvallend en op meerdere plaatsen verborgen. Hoe u ze vindt, beschrijft Webshells herkennen en verwijderen. Na een opschoning moet de server nauwlettend worden gevolgd, zodat een over het hoofd geziene achterdeur opvalt.
Verwijder niets voordat logs en bestanden zijn veiliggesteld, en dicht het lek voordat de server weer aan het netwerk gaat. Anders verliest u de sporen en nodigt u de volgende inbraak uit.
Wanneer u geen dienstverlener nodig hebt
Bij een eenvoudige website op shared hosting, waar de hoster het systeem beheert en de PHP-patch bevestigt, ligt de beslissing vaak helemaal niet bij u. U kunt de toepassing vanuit het origineel opnieuw installeren, inhoud controleren en inloggegevens vernieuwen, ondersteund door de hoster. Ook een ervaren intern team kan een wederopbouw zelf aan, als bewijsveiligstelling en documentatie op orde zijn.
Externe hulp loont als rootrechten niet zijn uit te sluiten, persoonsgegevens getroffen kunnen zijn, de verzekering betrokken is of meerdere systemen samenhangen.
Hoe helpt PHP SOS concreet?
- Wij zetten logs, bestanden en database bewijskrachtig veilig voordat er iets wordt gewijzigd.
- Wij beoordelen de omvang van de inbraak en adviseren opschonen of wederopbouw met motivering, gescheiden naar aangetoond, waarschijnlijk en onbekend.
- Wij bouwen de server zo nodig opnieuw op uit betrouwbare bronnen, met gepatchte PHP-versie en vernieuwde toegangen.
- Wij nemen de malwareverwijdering over waar opschonen verdedigbaar is, en documenteren elke stap.
Conclusie
De vraag „opnieuw opzetten of opschonen?“ beantwoordt zich via de kennis van de inbraak. Wie de omvang niet zeker kent, bouwt opnieuw op. Wie haar goed aangetoond kan afbakenen, mag opschonen. In beide gevallen geldt dezelfde volgorde: insluiten, veiligstellen, lek dichten, dan opruimen.
Veelgestelde vragen
Is opnieuw opzetten na een hack altijd beter?
Niet altijd, maar vaak wel. Als onduidelijk is hoe ver de aanvaller kwam, is een wederopbouw uit betrouwbare bronnen meestal de betrouwbaardere keuze. Bij een nauw begrensde, goed aangetoonde besmetting kan opschonen volstaan.
Kan ik gewoon een oude back-up terugzetten?
Alleen als zeker is dat de back-up van vóór de inbraak stamt en geen achterdeur bevat. Bovendien moet het lek eerst zijn gedicht, anders is de server direct weer kwetsbaar. Recentere gegevens moeten afzonderlijk worden gecontroleerd.
Wat moet ik veiligstellen vóór het opnieuw opzetten?
Logs, een kopie van de bestanden en de database en, indien mogelijk, een image van het systeem. Dit bewijs hebt u nodig voor oorzaakanalyse, verzekering en een mogelijke melding. Na het wissen is het weg.
Volstaat het de gevonden webshell te verwijderen?
Zelden. Aanvallers leggen vaak meerdere achterdeuren aan, zoals cronjobs, gebruikersaccounts of SSH-sleutels. Wie alleen het zichtbare bestand verwijdert, laat de andere toegangen open.