Cyber Incident Response Plan — Remote Code Execution PrestaShop 1.6.x¶

Opgesteld door: Flooris B.V.
Van toepassing op: Brekz PrestaShop 1.6.x — alle landen (NL, BE, DE, FR, AT, IT, DK, CH, SE)
Status: Operationeel

Aanname: Cloudflare actief

Dit plan gaat ervan uit dat alle Brekz-domeinen achter Cloudflare draaien. Stappen rondom maintenance pages en WAF-isolatie zijn gebaseerd op deze setup.

Gerelateerde documenten

1. Verantwoordelijkheden en taakverdeling¶

Team	Verantwoordelijk	Rol
Communicatie	Flooris Servicedesk	Klantcommunicatie, meldingen aan betrokkenen en Autoriteit Persoonsgegevens
Analyse	Florian Kwakkenbos	Incidentanalyse, bepalen scope en impact
Handelen	Florian Kwakkenbos + Flooris engineer(s)	Technische mitigatie, isolatie, herstel

Escalatie

Bij een incident buiten kantooruren: bel direct de primaire technische contactpersoon van Flooris. Zie Flooris contactpersonen.

2. Identificatie¶

Documenteer alles

Vanaf het moment van identificatie: alle stappen documenteren in een nieuw ClickUp Security Incident document — inclusief tijdstip, bevindingen en screenshots. Dit is vereist voor de formele afronding en eventuele melding bij de Autoriteit Persoonsgegevens.

2.1 Eerste melding¶

Verantwoordelijk team: Analyse

Mogelijke bronnen van een eerste melding:

E-mail notificatie vanuit Google Search Console
Melding van Brekz: afwijkend gedrag op de website (bijv. prijzen ineens € 0,- op productpagina's)
Downtime-melding vanuit monitoring (Sentry, UptimeRobot, Cloudflare)
Interne constatering door een medewerker

2.2 Informatie verzamelen¶

Verantwoordelijk team: Analyse

Maak een nieuw Security Incident document aan in ClickUp (gebruik het incident template) en begin met het vastleggen van:

Datum en tijdstip van ontdekking
Wie de melding heeft gedaan
Eerste beschrijving van het incident
Betrokken systemen en domeinen

2.3 Eerste analyse — herkenning van RCE¶

Verantwoordelijk team: Analyse

Mogelijke signalen dat het gaat om een Remote Code Execution aanval:

Afwijkende database-data — queries die niet via de normale UI uitgevoerd kunnen worden (bijv. alle prijzen op € 0,-, lege tabellen, onbekende records)
Aangepaste bestanden — wijzigingen in bestanden waar de webserver-user schrijftoegang toe heeft
Vreemde actieve processen:

# Overzicht van actieve processen
sudo ps -ef

# Interactief procesoverzicht
htop

Relatief hoge CPU-load zonder aanwijsbare oorzaak
Aanwezigheid van een reverse shell proces
Bash history — uitvoering van onverwachte commando's door de webserver-user

2.4 Bepalen getroffen assets¶

Verantwoordelijk team: Analyse

Beantwoord per aangetroffen indicator:

Welke servers zijn getroffen? (zie Flooris serverinfrastructuur)
Welke gedeelde disk volumes zijn bereikbaar geweest?
Welke databases zijn toegankelijk geweest?
Welke credentials zijn mogelijk gecompromitteerd?
- Database credentials
- API keys van externe diensten
- SSH-sleutels
- .env-bestanden

2.5 Bepalen betrokkenen¶

Verantwoordelijk team: Analyse

Welke klanten, diensten en/of leveranciers zijn getroffen? Denk aan:

Brekz webshop klanten (consumenten)
Externe integraties: DPD, CM Payments, Copernica, Algolia, TrustPilot
HD Services (bij impact op de MySQL Slave BR09SQL001 op locatie Utrecht)

2.6 Getroffen persoonsgegevens¶

Verantwoordelijk team: Analyse

Betreft de gecompromitteerde data persoonsgegevens? Zo ja, beschrijf welk type:

NAW-gegevens (naam, adres, woonplaats)
E-mailadressen
Orderhistorie
Betaalgegevens

Referentie

Wat zijn persoonsgegevens? — Autoriteit Persoonsgegevens

2.7 Communiceren naar betrokkenen¶

Verantwoordelijk team: Communicatie

Stuur een eerste notificatie naar de betrokken klanten en leveranciers. Dit is een initiële melding — meer details volgen bij de wrap-up (stap 3.11).

Gebruik het incident-communicatietemplate beschikbaar in ClickUp.

2.8 Melding bij Autoriteit Persoonsgegevens¶

Verantwoordelijk team: Communicatie

Wanneer er een reële kans bestaat dat persoonsgegevens zijn gelekt: maak binnen 72 uur melding via het AP-meldloket.

Datalek melden — Autoriteit Persoonsgegevens

Timing

Deze stap moet worden opgepakt door een teamlid dat niet tegelijk bezig is met de technische mitigatie in stap 3.

3. Handelen¶

Blijf documenteren

Leg elke actie vast in het Security Incident document: wat is er gedaan, door wie, op welk tijdstip en met welk resultaat.

3.1 Dienst offline halen — maintenance mode¶

Verantwoordelijk team: Handelen

PrestaShop maintenance mode activeren via het admin panel of via de server.

Cloudflare maintenance page activeren:

Schakel de DNS-records om naar een statische Cloudflare Pages maintenance-pagina. Documenteer welke DNS-records zijn gewijzigd — deze moeten later exact worden teruggedraaid.

Cron jobs uitschakelen:

# Open de crontab
crontab -e
# Commentarieer alle actieve cron jobs (#)

Supervisor processen uitschakelen:

sudo supervisorctl stop all

Reverse shell

Bij een actieve reverse shell kan er ook na isolatie nog code worden uitgevoerd vanuit een externe verbinding. Overweeg direct over te gaan naar stap 3.4.

3.2 Overweging: direct rebooten¶

Verantwoordelijk team: Handelen

Overweeg al in een vroeg stadium te rebooten naar recovery mode (zie stap 3.4), zeker als:

Er aanwijzingen zijn voor een actieve reverse shell
Processen actief zijn die niet gestopt kunnen worden
De omvang van de besmetting onduidelijk is

3.3 Logfiles veiligstellen¶

Verantwoordelijk team: Handelen

Stel zo snel mogelijk de volgende bestanden veilig (kopieer naar een externe, geïsoleerde locatie):

Nginx access logs
Nginx error logs
Nginx configuratiebestanden
Syslog bestanden (/var/log/syslog, /var/log/auth.log)
Bash history per user (~/.bash_history)
Alle omgevingsbestanden (releases, shared directories, .env)

3.4 Server shutdown of reboot naar recovery mode¶

Verantwoordelijk team: Handelen

Isolatieopties (van licht naar zwaar):

Netwerk interfaces uitschakelen — via de Hetzner Robot/Cloud console
Reboot naar recovery mode — via de Hetzner Robot recovery system
Full shutdown — als er een directe dreiging is voor andere systemen op hetzelfde netwerk

3.5 Besluitvorming: aanpak¶

Verantwoordelijk team: Handelen

Op basis van de analyse bepalen we welke hersteloptie van toepassing is:

Optie 1 — Elimineren van malwareOptie 2 — Volledig opnieuw opbouwen

Wanneer: De malware is goed te identificeren en de omvang is beperkt en duidelijk afgebakend.

Stappen:

Identificeer alle geïnfecteerde bestanden
Verwijder de geïnfecteerde bestanden
Los de kwetsbaarheid op (zie stap 3.7)
Verifieer de integriteit van het systeem

Wanneer: De omvang van de besmetting onduidelijk is, de malware niet volledig te isoleren is, of het systeem fundamenteel gecompromitteerd is.

Stappen:

Nieuwe server provisioneren bij Hetzner
1Password bijwerken met nieuwe credentials
Airtable serverrecord bijwerken
SSH-sleutels opnieuw uitrollen
Hosting opnieuw provisioneren vanuit de flooris-hosting-provisioning repository
Data terugzetten vanuit de meest recente schone backup

3.6 Kwetsbaarheid oplossen¶

Verantwoordelijk team: Handelen

Verhelp de kwetsbaarheid die tot de RCE heeft geleid. Mogelijke maatregelen:

PHP versie updaten — PrestaShop 1.6.x draait op PHP 7.2 (EOL); overweeg migratie
PrestaShop module updates — controleer alle geïnstalleerde modules op bekende CVEs
OS-updates uitrollen
Bestandspermissies corrigeren — minimale rechten voor de webserver-user
Cloudflare WAF inschakelen / aanscherpen — zie Cloudflare documentatie
Specifieke Nginx-configuratie aanpassen

PHP 7.2 / PrestaShop 1.6 — EOL

Beide zijn end-of-life en ontvangen geen beveiligingsupdates meer. Bekende CVEs worden niet gepatcht door de leveranciers. Zie ook de Compliance Gap Analyse — A.8.8.

3.7 Credentials opnieuw uitrollen (re-roll)¶

Verantwoordelijk team: Handelen

Met externe partijen (afstemmen vóór uitvoering):

HD Services — SMTP server credentials, FTP printserver credentials
CM Payments / Docdata — API keys laten re-rollen
DPD — API credentials
TrustPilot — API credentials

Zelf uit te voeren (Flooris):

Tip

Controleer alle .env bestanden op credentials die niet in de bovenstaande lijst staan.

3.8 Diensten terug online brengen¶

Verantwoordelijk team: Handelen

Voer de stappen uit in omgekeerde volgorde t.o.v. stap 3.1:

Supervisor processen starten:
```
sudo supervisorctl start all
```
Cron jobs inschakelen — verwijder de commentaar-tekens uit de crontab
Cloudflare maintenance page deactiveren — herstel de DNS-records zoals gedocumenteerd in stap 3.1
PrestaShop maintenance mode uitschakelen

3.9 Communicatie — wrap-up aan betrokkenen¶

Verantwoordelijk team: Communicatie

Stuur een afsluitende communicatie naar alle betrokken klanten, diensten en leveranciers met:

Totaaloverzicht en tijdlijn van het incident
Welke maatregelen zijn getroffen
Bevestiging dat de diensten zijn hersteld
Vervolgstappen of aanbevelingen

3.10 Communicatie naar eindklanten¶

Verantwoordelijk team: Communicatie

Webshopklanten informeren — dit bericht wordt samen met Brekz opgesteld en bevat:

Welke persoonsgegevens het incident betrof
De periode en impact van het incident
Mogelijke gevolgen voor de klant
Concrete stappen die de klant wordt geadviseerd te ondernemen (bijv. wachtwoord wijzigen)

4. Evalueren¶

Verantwoordelijk team: Allen

Na afronding van het incident: een evaluatiemoment intern en met de betrokkenen. Terugkijken op het verloop van het incident.

Evaluatiepunten:

Welke lessen zijn er geleerd?
Hoe voorkomen we herhaling?
Zijn verantwoordelijkheden duidelijk gebleken, of moeten die worden aangescherpt?
Welke afspraken worden er nieuw gemaakt?
Moet dit Cyber Incident Response Plan worden verbeterd?

5. Openstaande vragen en risico's¶

Vraag / Risico	Status
Wat als de back-ups ook gecompromitteerd zijn?	Nog niet uitgewerkt
Hoe snel kan Brekz Logistiek zelfstandig opereren bij een langdurige outage?	Nog niet uitgewerkt
Filechanges loggen op filesystem- of OS-niveau?	Nog niet uitgewerkt
ClamAV overwegen voor dagelijkse malwarescan met e-mailnotificaties?	Nog niet uitgewerkt

6. Gerelateerde actiepunten (ClickUp)¶

De volgende open actiepunten zijn geregistreerd in ClickUp onder het Flooris Security project:

Cloudflare static maintenance page configureren en testen
Incident communicatietemplate finaliseren (eerste melding, wrap-up, eindklanten)
Cyber Incident Response Plan omzetten naar ClickUp Page Template voor hergebruik bij nieuwe incidenten
Responsible disclosure beleid publiceren op Brekz-domeinen (zie securitytxt.org)