Joomla-website gehackt: wat je nu moet doen

2. Het eerste uur: beperk de schade

2.1 Zet de site offline

Zolang de site bereikbaar is, blijft hij bezoekers schaden, spam versturen en straffen van zoekmachines verzamelen. Zet hem uit.

De beste methode hangt af van hoe ernstig het is:

De offline-modus van Joomla is de zwakste van de drie. Hij houdt gewone bezoekers tegen, maar een achterdeur in een PHP-bestand wordt direct via een URL benaderd en vraagt Joomla nooit of de site offline staat. Vermoed je een webshell, blokkeer dan op serverniveau.

Heb je shelltoegang, dan is de vierde optie degene waar ik naar grijp, en degene die ik op mijn eigen gehackte site gebruikte (paragraaf 4.6), omdat het de enige methode is die het incident indamt en tegelijk het bewijs beschermt:

mv public_html public_html.hacked
chmod 700 public_html.hacked
mkdir public_html
printf '<h1>Tijdelijk niet beschikbaar</h1>' > public_html/index.html

De gehackte site is nu onbereikbaar vanaf het web, inclusief elke webshell erin, omdat de webservergebruiker de map niet meer in kan. Er is niets verwijderd, dus elk bestand en elke tijdstempel blijft bewaard voor fase 2. Bezoekers krijgen een eenvoudige statische pagina waar geen PHP aan te pas komt, dus geen Joomla, geen extensies, en niets meer dat een aanvaller kan aanroepen.

Controleer daarna als welke gebruiker je PHP eigenlijk draait. Draait PHP als hetzelfde account dat de bestanden bezit, dan geeft 700 nog steeds toegang; verplaats de map in dat geval helemaal buiten de webroot, of haal de site op hostingniveau offline.

2.2 Bewaar het bewijs voordat je iets verandert

Maak, voordat je ook maar een bestand aanraakt, een volledige kopie van de gehackte toestand: alle bestanden en een complete databasedump. Label die duidelijk als besmet en bewaar hem buiten de webroot, het liefst helemaal van de server af.

Deze kopie is geen back-up die je ooit gaat terugzetten. Het is je bewijsmateriaal. Je hebt het nodig omdat:

• Tijdstempels van bestanden en logregels verdwijnen zodra je begint met opschonen.
• Je de besmette bestanden wilt vergelijken met schone om elke injectie te vinden.
• Je bij persoonsgegevens later mogelijk moet uitleggen wat er is gebeurd en wanneer.
• Je, als je te agressief opschoont en iets sloopt, nog kunt nakijken hoe het was.

Kopieer de bestanden met een methode die wijzigingsdatums intact laat. Op de commandline behouden rsync -a of tar ze; slepen in sommige FTP-clients niet.

2.3 Licht je hostingprovider in

Neem vroeg contact op met je hostingprovider, ook als je alles zelf wilt oplossen. Twee redenen: hun serverlogs gaan meestal verder terug dan wat jij in je eigen account ziet, en een hack begint soms buiten je site - in een buuraccount, in een gestolen controlepaneel-wachtwoord, of in een kwetsbaarheid op serverniveau. Alleen je hoster kan dat nakijken.

Vraag specifiek om de ruwe access logs van de laatste maanden, de FTP- en SSH-inloghistorie van je account, en of ze hetzelfde besmettingspatroon op andere accounts zien.

Soms loopt het gesprek andersom en hoor je van de hack via een e-mail van iemand anders. Beveiligingsorganisaties scannen op beklade en kwaadaardige pagina's en melden die bij de hostingprovider en bij de domeinregistratie. Voor .nl-domeinen meldt Netcraft bevindingen bijvoorbeeld bij SIDN, de beheerder van de zone. Je hoster stuurt zo'n melding mogelijk door, of stuurt er zelf een.

Behandel die berichten als urgent, want er zit meestal een deadline aan met echte gevolgen: hostingproviders schorten accounts op, en een registratie kan de domeinnaam zelf stilleggen als niemand reageert. Antwoord meteen dat je ermee bezig bent, ook voordat je iets hebt opgelost. Een gemelde site die antwoordt wordt heel anders behandeld dan een gemelde site die stil blijft, en je zult moeten terugmelden zodra hij schoon is (paragraaf 9.6).

2.4 Zet nog geen back-up terug

De back-up van gisteravond terugzetten voelt als de snelste oplossing, en het is de meest gemaakte beginnersfout. Er gaan meestal twee dingen mis:

• Als de site weken geleden is gehackt, zit de achterdeur ook in de back-up van gisteren. Je zet de hack terug.
• Zelfs een echt schone back-up gaat regelrecht terug naar de kwetsbare toestand waardoor de aanvaller binnenkwam. Zonder de update of de wachtwoordwijziging ben je binnen dagen opnieuw besmet.

Een back-up terugzetten hoort bij fase 4, nadat je weet wanneer de inbraak plaatsvond en wat de oorzaak was. Niet eerder.

2.5 Stop de site met mail versturen

Wordt de site gebruikt om spam te versturen, dan beschadigt elk extra uur je domeinreputatie en duwt het je verder de blocklists op. Een domein weer van zo'n lijst af krijgen duurt veel langer dan de hack zelf.

Joomla heeft hier een schakelaar voor: zet Mail versturen (mailonline) op Nee onder Systeem → Globale configuratie → Server → Mailinstellingen. Hij staat standaard aan, en uitzetten zorgt dat Joomla helemaal niets meer verstuurt - ook je eigen contactformulieren niet, dus dit is een bewuste tijdelijke maatregel.

Let op de beperking, dezelfde als bij de offline-modus: dit stopt Joomla met mailen. Malware die de PHP-functie mail() rechtstreeks aanroept, of zelf met een SMTP-server praat, gaat niet via Joomla en negeert deze instelling volledig. Gaat de spam door nadat je hem hebt omgezet, dan is de verzender een bestand en niet Joomla, en heb je de blokkade op serverniveau uit paragraaf 2.1 nodig plus hulp van je hoster met de mailwachtrij.

2.6 Ga ervan uit dat ook de naburige websites besmet zijn

Staan er meerdere websites in hetzelfde hostingaccount, behandel ze dan vanaf het begin allemaal als gehackt, niet alleen die ene waar je iets opviel. Draaien alle sites als dezelfde Unix-gebruiker, dan kan code in de ene site meestal de bestanden van de andere lezen en schrijven, dus verspreidt de besmetting zich zijwaarts zonder tweede inbraak.

Dat verandert je eerste uur: inventariseer elke site in het account, controleer ze allemaal op de signalen uit paragraaf 1.2, en plan de opschoning voor het hele account in een keer. Ze een voor een schoonmaken terwijl de rest besmet blijft betekent dat de eerste site alweer besmet raakt terwijl jij aan de tweede werkt.

4. Achterhaal hoe ze binnenkwamen

4.1 De Joomla actionlog

Het Gebruikersactie log (com_actionlogs, gevoed door de plugin System - User Actions Log) is de eerste plek om te kijken. Open Gebruikers → Gebruikersactie log. Het registreert logins, installaties van extensies, wijzigingen aan artikelen en modules, en opgeslagen configuraties, met een gebruikersnaam en een tijdstempel. Je kunt de hele lijst exporteren naar CSV via de werkbalk, wat in een spreadsheet veel prettiger doorwerkt.

Twee standaardinstellingen zijn belangrijk voordat je op dit logboek vertrouwt:

• IP-logging staat standaard uit (ip_logging in de componentopties). Heeft niemand dat aangezet, dan vertelt je logboek wie en wanneer, maar niet vanwaar.
• API-acties worden standaard niet gelogd (loggable_api). Activiteit via de Web Services API laat geen spoor na in dit logboek tenzij die optie aan stond.

Allebei zijn het schakelaars om vandaag aan te zetten, nu je toch naar dat scherm kijkt. Ze kosten niets en het is precies wat je de volgende keer had willen hebben.

Er is een patroon in dit logboek dat mensen stelselmatig over het hoofd zien, omdat het er helemaal niet uitziet als een aanval: een geslaagde login met je eigen account, op een moment dat je niet aan het werk was. Iedereen scant de lijst op onbekende gebruikersnamen. Niemand zet vraagtekens bij zijn eigen naam.

Controleer dus je eigen regel. Vergelijk elke recente login van elke beheerder met waar die persoon toen echt was, en bevestig dat met iets onafhankelijks - je browsergeschiedenis, je agenda, je telefoon. Een login die je niet kunt verklaren is een van de sterkste signalen uit dit hele artikel, en hij zegt iets specifieks: de aanvaller had je wachtwoord niet nodig. Werkt je wachtwoord nog en is het nooit gereset, dan kwamen ze binnen met een gestolen sessie, een gelekt token, of een lek waardoor ze zich als jou konden aanmelden. Alleen dat wachtwoord veranderen verwijdert ze niet, en daarom bestaan paragraaf 3.2 en paragraaf 3.3.

4.2 Het logboek met mislukte logins

De plugin System - Log luistert naar het event onUserLoginFailure en schrijft elke mislukte inlogpoging naar een logbestand. Standaard is dat error.php in je logmap (administrator/logs/, tenzij je die hebt verplaatst in de globale configuratie).

Lees het op twee patronen. Duizenden mislukkingen vanaf veel adressen is gewone ruis van bots. Een korte reeks mislukkingen op een bestaande gebruikersnaam, gevolgd door stilte, is de interessante: stilte na mislukkingen betekent vaak dat het uiteindelijk lukte.

De plugin heeft een optie log_username die de geprobeerde gebruikersnaam aan elke regel toevoegt. Zonder die optie zie je alleen dat een login mislukte, niet welk account het doelwit was. Zet hem aan.

4.3 Server access logs

Het webserverlog is waar de inbraak meestal echt zichtbaar is, omdat het verzoeken vastlegt die de Joomla-applicatie nooit hebben bereikt. Vraag je hoster om de ruwe logs en zoek naar:

• POST-verzoeken naar bestanden die nooit een POST horen te krijgen, vooral onder images/, tmp/ of media/.
• Verzoeken naar bestandsnamen die je niet kent, met name korte willekeurige namen die eindigen op .php.
• Lange, gecodeerde querystrings vol %-escapes of base64-achtige tekst.
• Verzoeken naar een bekende kwetsbare component-URL, bijvoorbeeld index.php?option=com_iets&task=... voor een extensie die je hebt geinstalleerd.
• Het allereerste verzoek vanaf het IP-adres dat later bestanden uploadt. Dat verzoek is meestal de exploit.

Praktische truc: zodra je de tijdstempel van het oudste kwaadaardige bestand kent, grep je het access log op precies die minuut. Het verzoek dat het bestand aanmaakte staat er bijna altijd direct bij.

Verwacht meer dan een bezoeker. Zodra een site is opengebroken wordt het adres vaak gedeeld, en komen gelegenheidsgebruikers de webshell gebruiken die iemand anders heeft geplaatst. Een tweede IP-adres dat uren later opduikt, binnenkomt via een sociaal netwerk en regelrecht naar een bestand gaat dat het onmogelijk kan hebben geraden, is een bekend beeld. Het betekent niet twee losse inbraken; het betekent dat de eerste is rondverteld. Het verhoogt wel de urgentie, want elke nieuwkomer richt zijn eigen schade aan.

Heb je root op je eigen server, controleer dan ook het authenticatielogboek, om vast te stellen of de aanvaller ooit verder is gekomen dan de webapplicatie:

grep Accepted /var/log/auth.log     # geslaagde SSH- en SFTP-logins
grep Failed   /var/log/auth.log     # brute-force-pogingen

Zie je hier alleen je eigen logins, dan is dat echt goed nieuws: het wijst erop dat de hack binnen het webaccount bleef en de server zelf nooit bereikte. Let wel op de beperking, en wees daar eerlijk over: kreeg de aanvaller schrijftoegang buiten de webroot, dan had hij dit logboek kunnen aanpassen. Het is bewijsmateriaal, geen bewijs, en op shared hosting heb je het helemaal niet - vraag het dan aan je hoster.

4.4 Tijdstempels van bestanden

Wijzigingsdatums zijn het goedkoopste forensische gereedschap dat je hebt. Op een shell toon je alles wat in twee weken is veranderd:

find . -type f -name "*.php" -mtime -14 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

Op een site die niet recent is bijgewerkt hoort deze lijst vrijwel leeg te zijn. Groepeer de resultaten op tijd: bestandswijzigingen komen meestal in bursts van een paar seconden, en de oudste burst markeert de inbraak.

Houd er rekening mee dat een zorgvuldige aanvaller tijdstempels terugzet met touch om op te gaan in de rest. Zien de datums er verdacht uniform uit, of is de wijzigingstijd van een bestand ouder dan de inode-wijzigingstijd (ls -lc versus ls -l), beschouw de tijdstempels dan als onbetrouwbaar en leun op bestandsvergelijking (paragraaf 5.1).

4.5 Bouw een tijdlijn

Schrijf de bevindingen op in een simpele lijst, gesorteerd op tijd: het eerste verdachte verzoek, het eerste gewijzigde bestand, het nieuwe gebruikersaccount, de eerste geindexeerde spampagina. Je zoekt de vroegste gebeurtenis zonder onschuldige verklaring. Dat is je inbraakmoment, en het beantwoordt twee vragen tegelijk: welke back-upgeneratie nog schoon is, en welke kwetsbaarheid op die datum openstond.

Kijk ook na welke Joomla-versie en extensieversies je op die datum draaide. Heel vaak ligt het antwoord daar al: een extensie met een bekende beveiligingsupdate van twee weken eerder die nooit is geinstalleerd.

Stel daarna een tweede vraag, en stel die over jezelf in plaats van over de software: wat heb ik kort voor die datum aangezet en nooit teruggezet? Een verrassend deel van de echte incidenten begint met een tijdelijke maatregel tijdens het oplossen van iets heel anders. Debug-modus aan om een mailprobleem te zoeken. Foutrapportage op maximaal. Een map even schrijfbaar gemaakt. Een testbestand geupload om iets te controleren. Elk daarvan is onschuldig voor de tien minuten die bedoeld waren, en elk is een echte opening voor de maanden die het werkelijk duurde, want wat die tien minuten beeindigt is meestal een onderbreking en geen beslissing. Loop je eigen aantekeningen, je ticketgeschiedenis en je mail van de weken voor de inbraak terug.

Dezelfde redenering verklaart hoe aanvallers een site uberhaupt vinden. Niemand had jouw kleine Joomla-site bij naam op het oog; ze zochten op waar hij lekte. Debug-uitvoer, uitgebreide foutmeldingen en mapoverzichten bevatten allemaal herkenbare tekst, en zodra een zoekmachine een pagina met die tekst indexeert, is die pagina vindbaar voor iedereen die weet waarop te zoeken. Een referrer van https://www.google.com/ bij het allereerste verzoek vanaf het IP-adres van de aanvaller is hier het teken: ze hebben je domein niet geraden, ze kregen het aangereikt van een zoekmachine. Zoek zelf op je domein naar de teksten die jouw fouten opleveren, dan zie je ongeveer wat een aanvaller ziet.

4.6 Een uitgewerkt voorbeeld: hoe dit op mijn eigen site verliep

De methode hierboven is voor mij geen theorie. In oktober 2022 werd de website van mijn eigen Joomla User Group, Arnhem-Nijmegen, gehackt, en mijn onderzoek liep precies langs deze stappen. Het is de moeite waard om door te lopen, want de site was drie maanden oud, draaide maar een handvol extensies en was volledig bijgewerkt. Bijgewerkt zijn is noodzakelijk, en het was niet voldoende.

Het eerste uur

Ik kwam er om kwart over twaalf 's nachts achter, via een e-mail. Netcraft, dat bevindingen doorgeeft aan SIDN voor de .nl-zone, had een defacement-bestand op het domein gevonden en vroeg me het op te lossen, anders zou het domein worden stilgelegd. Mijn VPS-provider was ook ingelicht en waarschuwde dat de hele VPS offline gezet kon worden. Dat is de meldroute uit paragraaf 2.3, inclusief de deadline.

Via FTP vond ik twee bestanden die wij er nooit hadden neergezet: Ox.php, de defacement, en sec.php, een achterdeur met toegang tot het bestandssysteem en de database. Ik heb de site ingedamd zoals paragraaf 2.1 beschrijft, opzij gezet met strikte rechten en een statische onderhoudspagina ervoor. Daarna heb ik de bestanden, de database en de logs gearchiveerd en naar mijn eigen machine gehaald voordat ik iets verder aanraakte. Toen ben ik gaan slapen, want deen analyse vraagt om een helder hoofd en het bewijs had ik veiliggesteld.

Wat de logs lieten zien

De volgende dag leverde de database mij het bewijs. #__action_logs toonde een geslaagde login voor mijn eigen account op 12 oktober om 15:46. Maar ik was op dat moment nergens in de buurt van een computer geweest; mijn browsergeschiedenis bevestigde dat. Mijn wachtwoord werkte nog en was nooit gewijzigd. Dat is het patroon uit paragraaf 4.1, en het vertelde me meteen dat dit geen geraden wachtwoord was.

Met die tijdstempel dook ik het access log in. Het IP-adres van de aanvaller verscheen voor het eerst twee minuten eerder, op een gewone artikelpagina, met als verwijzende pagina https://www.google.com/. Een zoekopdracht op Google naar die pagina maakte duidelijk waarom: de pagina was geïndexeerd terwijl de debug-uitvoer van Joomla erop zichtbaar was. Ze waren niet op zoek geweest naar mijn gebruikersgroep. Ze waren op zoek geweest naar sites die debug-gegevens lekten, en Google had hen die van mij aangereikt.

De hoofdoorzaak lag bij mijzelf en was heel alledaags. Een JUG-bijeenkomst was afgelast, de nieuwsbrief over de aflasting, liep halverwege vast door SMTP-authenticatiefouten, en ik schakelde de debugmodus in om dit te onderzoeken. De echte fout bleek bij de DNS te liggen: twee mail.-records met verschillende IP-adressen, waarvan er één verkeerd was. Ik repareerde het, verstuurde de nieuwsbrief, plaatste het bericht over de afgelasting en vergat de debugmodus weer uit te schakelen. Precies de hierboven beschreven tijdelijke wijziging die nooit ongedaan was gemaakt.

Het logboek toonde ook een tweede, niet-gerelateerde bezoeker die later die avond via een Facebook-link binnenkwam, die het bestaande sec.php-bestand gebruikte om configuration.php te lezen en er vandoor ging met de database- en SMTP-inloggegevens. Eén inbraak, twee aanvallers, en de reden waarom paragraaf 3.1 erop aandringt dat je ervan uitgaat dat alles in dat bestand openbaar is.

Wat het heeft opgeleverd

Omdat het erop leek dat de Joomla core software hierbij betrokken was, heb ik alles doorgestuurd naar het Joomla Security Strike Team. Zij bevestigden dat er daadwerkelijk sprake was van een probleem, en het kreeg de aanduiding CVE-2022-27912, advisory [20221001] Core - Disclosure of critical information in debug mode, van toepassing op Joomla 4.0.0 tot 4.2.3 en opgelost in Joomla 4.2.4 op 25 oktober 2022. Pas toen heb ik alle inloggegevens vernieuwd en een schone back-up teruggezet. Een Duitse collega wiens Joomla 4-site maanden eerder was gehackt, bleek ook de debugmodus ingeschakeld te hebben gehad.

Het CVE-record is toegekend door het Joomla-project en vermeldt mij als de ontdekker van het issue. Ik vermeld dit hier om slechts één reden, en dat is juist de kern van paragraaf 9.5, niet om ermee te pronken: ik ga niet op jacht naar kwetsbaarheden en ik heb deze niet met opzet gevonden. Ik werd gehackt, heb het bewijsmateriaal bewaard, opgeschreven wat ik zag en het gerapporteerd aan mensen die het verder konden analyseren. Dat was genoeg. Als je eigen onderzoek ooit naar een issue in de Joomla core wijst, dan zijn je aantekeningen meer waard dan je denkt.

Twee dingen zijn het vermelden waard. Dat specifieke lek is gedicht: in de huidige versie van Joomla controleert de debug-AJAX-handler zowel de autorisatie van de gebruiker als een geldig sessietoken, zodat deze niet meer op dezelfde manier kan worden aangeroepen als in 2022. Maar de gewoonte die mij blootstelde, is nog steeds voor iedereen beschikbaar, omdat de optie Allowed Groups van de debug-plugin leeg is, wat betekent dat bij ingeschakelde debug-modus de uitvoer wordt getoond aan iedereen die kijkt. Als je op een live site moet debuggen, beperk die optie dan eerst tot Super Users en schakel debug uit als je klaar bent.

Ik heb een volledige verslag in het Joomla Community Magazine geschreven, inclusief de logregels en de tijdstippen: How my new Joomla 4 website got hacked. De Joomla User Group bijeenkomst die de hele situatie in gang zette, die we hadden afgezegd omdat er behalve de spreker precies één persoon zich had aangemeld, werd verplaatst naar 2 november. Die bijeenkomst trok een volle zaal. Naast een lezing over Joomla migraties was er een korte presentatie van ondergetekende met de titel "Hoe de JUG-website werd gehackt".

6. Opschonen of opnieuw opbouwen?

Nu bepaal je hoe je bij een betrouwbare site komt. Er zijn drie routes, en de eerlijke rangschikking is niet degene waar de meeste mensen op hopen.

6.1 Een schone back-up terugzetten - het snelst

Zegt je tijdlijn (paragraaf 4.5) dat de inbraak op de 14e was en heb je een volledige back-up van de 10e, dan is die back-up terugzetten de snelste en betrouwbaarste route. Je krijgt een bekende toestand, zonder giswerk over wat je hebt gemist.

De prijs is de inhoud tussen de 10e en vandaag, die je met de hand opnieuw invoert. Dat kost echt iets, maar meestal minder dan een onvolledige opschoning.

Zet de back-up nooit over de besmette bestanden heen. Verwijder eerst alles in de webroot en zet dan terug. Anders blijft de webshell die niet in je back-up zit gewoon staan.

6.2 Opnieuw opbouwen op schone bestanden - het betrouwbaarst

Is geen enkele back-up oud genoeg, bouw dan de bestandskant helemaal opnieuw op en behoud alleen de database en je eigen inhoud. Het kost een paar uur en laat niets achter, omdat je nooit een onbekend bestand meeneemt. Paragraaf 7 beschrijft de procedure stap voor stap.

Dit is de route die ik aanraad voor elke site waar de tijdlijn onduidelijk is, en de enige zinnige route als de hack ouder is dan elke back-up die je hebt.

6.3 Ter plekke opschonen - het laatste redmiddel

Kwaadaardige code uit de bestaande installatie halen is de aantrekkelijkste optie en degene die het vaakst mislukt. Het werkt alleen als je elke wijziging van de aanvaller kunt opsommen, en daar kun je nooit helemaal zeker van zijn.

Bewaar dit voor kleine, duidelijke, vers ontdekte besmettingen met een korte en complete tijdlijn. En volg het dan alsnog op met een volledige vergelijking tegen schone bronnen.

6.4 De database is het lastige deel

Welke route je ook kiest, de database kun je meestal niet vervangen, omdat daar de inhoud in zit die je wilt houden. Hij moet worden nagelopen in plaats van herbouwd: de geinjecteerde inhoud van paragraaf 5.3, de accounts van paragraaf 3.4, de extensierijen van paragraaf 5.4 en de geplande taken van paragraaf 5.5.

Een structurele controle wordt makkelijk vergeten. Ga naar Systeem → Beheren → Database, waar Joomla controleert of je tabelstructuur overeenkomt met het schema van je versie, en repareer wat daar wordt gemeld. Het detecteert geen kwaadaardige rijen, maar het vertelt wel of de structuur zelf is aangepast of half bijgewerkt is blijven staan.

8. Breng de site terug online

8.1 Blokkeer PHP waar het niet hoort

Vrijwel elke webshell uit paragraaf 5.2 leunt op een aanname: dat een PHP-bestand in een uploadmap ook echt wordt uitgevoerd als iemand het opvraagt. Die aanname kun je wegnemen, en het is het waardevolste dat je tijdens de herbouw kunt toevoegen.

Joomla doet dit niet voor je. De meegeleverde htaccess.txt blokkeert mapoverzichten, zet nosniff, en stopt scripts in geuploade SVG-bestanden, maar bevat geen regel tegen het draaien van PHP in images/. Die voeg je zelf toe, in een .htaccess-bestand in de uploadmap:

<FilesMatch "\.(?i:php|phtml|php[0-9]|phar|inc)$">
  Require all denied
</FilesMatch>

Op nginx staat het equivalent in het serverblok, omdat nginx geen .htaccess-bestanden leest:

location ^~ /images/ {
    location ~ \.php$ { return 403; }
}

Pas het toe op elke map die uploads ontvangt en nooit code hoeft te draaien: images/, je mediamappen, en elke uploadmap van een formulierextensie. Test daarna of je site het nog doet en of een testbestand echt geweigerd wordt, en verwijder dat testbestand daarna.

Dit maakt uploads op zichzelf niet veilig - de aanvaller kan het bestand nog steeds neerzetten - maar het maakt van een werkende achterdeur een dood bestand op schijf, en dat scheelt enorm.

Zet de regel buiten bereik van de aanvaller

In het advies hierboven zit een gat, en het is beter om dat hardop te zeggen dan het twee keer te ontdekken. De regel staat in een .htaccess-bestand, in een map waar de aanvaller al in kan schrijven. Hij kan jouw bestand overschrijven, of zijn eigen versie in een submap zetten, die Apache als laatste leest en dus laat winnen. Paragraaf 5.8 laat de variant zien die in de praktijk gebruikt wordt, waarbij het blokje van de aanvaller PHP weer aanzet voor .json-bestanden.

De reparatie is om de beslissing uit de webroot te halen en in de serverconfiguratie te zetten, waar niets wat een uploadformulier aanraakt eroverheen kan. In een Apache virtual host:

<Directory /var/www/example.test/images>
    AllowOverride None
    Options -Includes -ExecCGI
    <FilesMatch "\.(?i:php|phtml|php[0-9]|phar|inc|shtml)$">
        Require all denied
    </FilesMatch>
</Directory>

Options -Includes schakelt Server Side Includes uit, de tweede route uit paragraaf 5.8: een .shtml-bestand dat Apache verwerkt en uitvoert zonder dat er PHP aan te pas komt. Joomla gebruikt nooit SSI, dus je verliest er niets mee.

AllowOverride None is de regel die het echte werk doet, en het is goed om te weten waarom. SetHandler, AddHandler en AddType horen allemaal bij de FileInfo-groep van Apache, dus een .htaccess-bestand kan alleen veranderen welke handler een bestand draait als AllowOverride ook FileInfo bevat. Shared hosting levert bijna altijd AllowOverride All, en die bevat het. Zet het uit voor de mappen die alleen uploads bevatten, en het blokje van de aanvaller wordt een stuk commentaar. Omdat de instelling wordt overgeerfd, zijn de submappen meteen ook gedekt.

Let op: AllowOverride None schakelt ook je eigen .htaccess in die map uit, en daarom verhuist de FilesMatch-regel mee naar hetzelfde <Directory>-blok. Laat de .htaccess in de map er toch staan als tweede laag, voor de dag dat de site verhuist naar een hoster die dit niet heeft ingesteld.

Kun je de serverconfiguratie niet zelf aanpassen, vraag het dan aan je hoster. Het is aan hun kant een kleine wijziging, en het is het verschil tussen een verdediging die jij beheert en een verdediging die je aanvaller kan bewerken.

8.2 Test voordat je de knop omzet

Loop een korte checklist af voordat de site weer publiek is:

• De homepage en de belangrijkste templates renderen goed, uitgelogd.
• Test met een zoekmachine-referrer en een mobiele user agent (paragraaf 5.7). Geen onverwachte doorverwijzing.
• Bekijk de paginabron van een paar pagina's en zoek op script- en iframe-tags die je niet herkent.
• Formulieren werken en uitgaande mail komt aan. Controleer ook de mailwachtrij: een wachtrij vol berichten die jij niet hebt verstuurd betekent dat er nog iets verstuurt.
• Scan de site met een externe malwarescanner, en laat een tweede het bevestigen. Behandel ze allebei als detectiemiddel, niet als bewijs: signature-scanners missen standaard aangepaste of net gewijzigde malware, dus een schoon rapport is bemoedigend, niet doorslaggevend.
• Geen onbekende Super Users, geen onbekende plugins, geen onbekende geplande taken.
• Een test-PHP-bestand in images/ geeft 403 en wordt niet uitgevoerd (paragraaf 8.1).

8.3 Openstellen en in de gaten houden

Haal de site uit de offline-modus en blijf hem daarna minstens een maand volgen. Herbesmetting gebeurt bijna altijd snel, omdat de aanvaller geautomatiseerde scripts heeft die hun oude slachtoffers controleren.

Richt de bewaking zo in dat hij niet afhangt van jouw geheugen:

• Zet het Gebruikersactie log aan, nu met ip_logging en API-logging ingeschakeld.
• Zet de plugin System - Log aan met log_username, en lees error.php wekelijks.
• Zet de plugin Task - Update Notification aan met de taakplanner, zodat je updates per e-mail hoort.
• Koppel Google Search Console en zet de e-mailmeldingen aan.
• Voeg een externe uptime- en inhoudsmonitor toe die waarschuwt als de homepage onverwacht verandert.
• Maak nu een verse back-up - dit is je nieuwe schone referentiepunt - en bewaar vanaf hier meerdere generaties.

8.4 Als het terugkomt

Een herinfectie binnen enkele dagen betekent een van de volgende drie dingen, in volgorde van waarschijnlijkheid: je hebt een achterdeur over het hoofd gezien, de oorspronkelijke kwetsbaarheid is nog steeds aanwezig, of de inbreuk vindt helemaal niet plaats op je site, maar op de server, het configuratiescherm of de computer waarmee je de site beheert.

Herhaal niet zomaar dezelfde opschoonactie. Ga terug naar de tijdlijn en betrek deze keer ook de lagen buiten Joomla mee: scan het werkstation van de beheerder op programma’s die informatie stelen, controleer op onbekende SSH-sleutels en vraag je host om het account vanuit hun kant te bekijken.

10. Onder de motorkap (ontwikkelaarsblik)

10.1 Waar een aanvaller zich verstopt in de database

Die laatste regel verdient een tweede blik. Wijst #__update_sites ergens heen dat niet de officiele Joomla- of ontwikkelaars-URL is, dan komt elke toekomstige "update" die je installeert van de aanvaller.

10.2 Een praktische triage-gereedschapskist

Vier commando's die de meeste eerste vragen beantwoorden:

# 1. What changed recently?
find . -type f -newermt "2026-07-01" ! -path "./cache/*" ! -path "./tmp/*"

# 2. PHP where PHP does not belong
find images tmp cache media -type f -name "*.ph*"

# 3. Obfuscation markers
grep -rn --include="*.php" -E "eval\s*\(|base64_decode|gzinflate|\\\$GLOBALS\[" . | head -50

# 4. Files that are writable by everyone
find . -type f -perm -o+w

Een gehackte site ontvangt niet alleen verkeer, hij maakt ook zelf verbindingen: spam versturen, extra payloads ophalen, zich melden bij een command-and-control-host, of minen. Heb je shelltoegang terwijl het incident loopt, kijk dan wat de server op dit moment doet:

ss -plant          # luisterende sockets en actieve verbindingen
ps auxf            # procesboom, inclusief wat PHP heeft gestart
lsof -nP           # open bestanden en sockets per proces
mailq              # mail die klaarstaat om verstuurd te worden

Bewaar de uitvoer voordat je iets afschiet. Een draaiend proces is bewijs dat verdwijnt op het moment dat je het stopt, en de verbinding die het openhoudt wijst vaak sneller de infrastructuur achter de aanval aan dan welk bestand op schijf dan ook.

Staat de site in versiebeheer, dan heb je een veel beter gereedschap dan al deze:

git status --porcelain
git diff --stat

Elke onverwachte regel is een gewijzigd of toegevoegd bestand, zonder giswerk. Dit is het sterkste praktische argument om ook kleine Joomla-sites in Git te houden: na een incident wordt "wat is er veranderd" een vraag van een seconde in plaats van een onderzoek van twee uur.

10.3 Waarom de Site Secret belangrijk is

Joomla bouwt de naam van de sessiecookie met md5($secret . $session_name), waarbij $session_name terugvalt op de naam van de applicatieklasse. De token-plugins controleren tokens met hash_hmac($algorithm, $rawToken, $siteSecret). Een enkele wijziging aan $secret beeindigt dus alle sessies en maakt alle API-tokens ongeldig, precies wat je wilt in de eerste minuten van een incident.

Het is goed om de grenzen te benoemen, zodat niemand er te veel op leunt: wachtwoorden zijn bcrypt-hashes en blijven ongemoeid, ingeschreven MFA-methodes in #__user_mfa blijven werken, en onthoud-mij-tokens in #__user_keys worden per user agent bewaard en hebben hun eigen opruiming nodig.

10.4 Een opgeschoonde site verifieren

Vertrouw hier niet op je eigen ogen. Bouw een checksumlijst van een schone Joomla van dezelfde versie en vergelijk:

cd /pad/naar/schone-joomla && find . -type f -name "*.php" \
  -exec sha256sum {} \; | sort -k2 > /tmp/clean.sha256

cd /pad/naar/site && find . -type f -name "*.php" \
  -exec sha256sum {} \; | sort -k2 > /tmp/site.sha256

diff /tmp/clean.sha256 /tmp/site.sha256

Alles wat verschilt is ofwel een eigen aanpassing die je kunt benoemen, ofwel iets om uit te leggen. "Ik weet niet wat dat bestand is" is geen geslaagde uitkomst.

Twee beperkingen zijn belangrijk als je hier doorlopende bewaking van maakt. Een hashlijst vangt alleen gewijzigde bestanden, en de meeste malware voegt gewoon nieuwe toe, dus vergelijk ook de bestandslijsten en niet alleen de hashes. En bewaar de referentiegegevens ergens waar het webaccount niet kan schrijven - een andere server, of opslag waar je PHP-gebruiker niet bij kan. Een checksumbestand naast de site is een checksumbestand dat de aanvaller opnieuw kan genereren.

12. SEO en metadata

Een hack is net zo goed een zoekmachineprobleem als een technisch probleem, en de schade overleeft de besmetting vaak met maanden.

Wat er meestal gebeurt: de aanvaller publiceert honderden spampagina's die onder jouw domein worden geindexeerd, injecteert verborgen links in bestaande artikelen, en serveert de Googlebot andere inhoud dan jou. Google detecteert het, markeert de site in Search Console, en kan een waarschuwing in de resultaten tonen. Posities die je jaren hebt opgebouwd zakken binnen dagen weg.

De volgorde van herstel is belangrijk:

1. Maak de site eerst echt schoon. Een beoordelingsverzoek op een nog besmette site mislukt en kost je opnieuw wachttijd.
2. Laat de spam-URL's 404 teruggeven of, beter, 410 Gone. Verwijs ze niet door naar je homepage; dat vertelt Google alleen dat de spampagina is verhuisd.
3. Vraag een beoordeling aan onder Beveiligingsproblemen in Search Console.
4. Controleer of je domein op mail- of malware-blocklists is beland, en volg elke delisting-procedure.
5. Volg het aantal geindexeerde pagina's een paar weken tot de spam-URL's verdwenen zijn.

Er zit ook een preventieve kant aan. Meldingen van Search Console zijn gratis en bereiken je vaak eerder dan je bezoekers. Een site die niemand volgt kan maandenlang spam serveren voordat het opvalt, en hoe langer dat duurt, hoe langer het herstel duurt.

14. Best practices

Onthoud je maar een paar dingen uit dit artikel, onthoud dan deze:

• Eerst beperken, dan onderzoeken, dan opschonen. Draai die volgorde nooit om.
• Kopieer de besmette site en database voordat je iets verandert. Het is je bewijs en je vangnet.
• Vind het toegangspunt. Een opschoning zonder dat is uitstel, geen reparatie. Vraag je af wat je tijdens het troubleshooten hebt aangezet en nooit hebt uitgezet.
• Controleer de logintijden van je eigen account, niet alleen de lijst met onbekende gebruikers. Een login die je niet kunt verklaren betekent dat ze je wachtwoord niet nodig hadden.
• Verander alle inloggegevens, en verander de $secret in configuration.php om alle sessies en API-tokens in een keer te beeindigen.
• Leeg de webroot voordat je terugzet of herbouwt. Schoon nooit rond onbekende bestanden heen.
• Installeer extensies en templates opnieuw vanaf de originele bron, nooit vanaf de gehackte site.
• Controleer de database net zo zorgvuldig als de bestanden. Aangepaste modules en templateparameters verbergen injecties goed.
• Zoek de tweede en derde achterdeur: plugins, geplande taken, server-cron, .htaccess, auto_prepend_file.
• Blokkeer het uitvoeren van PHP in uploadmappen, en doe dat vanuit de serverconfiguratie met AllowOverride None, niet alleen vanuit een .htaccess-bestand dat de aanvaller kan overschrijven. Joomla doet dit niet voor je, en het schakelt de meeste webshells uit.
• Blokkeer het uitvoeren van PHP in uploadmappen. Joomla doet dit niet voor je, en het schakelt de meeste webshells uit.
• Verplicht MFA en werk alles bij voordat de site weer publiek gaat.
• Vervang de inloggegevens een tweede keer zodra de schone site er staat. De eerste ronde gebeurde terwijl de achterdeur meekeek.
• Volg de site een maand lang goed, en maak een verse back-up als je nieuwe schone referentie.
• Meld een datalek binnen 72 uur. Vertel je gebruikers gewoon wat er is gebeurd.
• Was Joomla core de ingang, meld het dan bij het JSST in plaats van het openbaar te maken.
• Meld terug aan je hoster en aan wie de hack meldde. Een openstaande abuse-melding kan je alsnog het account kosten.
• Repareer daarna de oorzaak: de gemiste update, het zwakke wachtwoord, de extensie die niemand onderhoudt.

16. Samenvatting

Een gehackte Joomla-site betekent een vervelende dag, maar niet dat de site verloren is, mits je de juiste stappen in de juiste volgorde neemt:

• Beperk voordat je opschoont. Blokkeer op serverniveau en kopieer de besmette toestand voordat je een byte verandert.
• Vind het toegangspunt. Het actielogboek, het logboek met mislukte logins, het server access log en de tijdstempels geven samen een tijdlijn, en die tijdlijn vertelt welke back-up nog schoon is.
• Sluit de aanvaller buiten. Vervang alle inloggegevens, verander de site secret, en leeg #__session en #__user_keys.
• Zoek alles wat ze achterlieten. Gewijzigde core-bestanden, webshells in uploadmappen, geinjecteerde artikelen en aangepaste modules, malafide plugins, geplande taken, .htaccess-doorverwijzingen en auto_prepend_file.
• Kies herbouwen boven opschonen als de tijdlijn onduidelijk is. Lege webroot, verse Joomla, verse extensies, nagekeken database.
• Kom voorzichtig terug. Werk alles bij, verplicht MFA, test zoals een vreemde dat zou doen, en volg de logs een maand.
• Meld wat de wet en het fatsoen vragen. Gebruikers, de toezichthouder binnen 72 uur bij persoonsgegevens, het JSST als Joomla core de ingang was, en een beoordelingsverzoek aan de zoekmachines zodra je echt schoon bent. Meld daarna terug aan je hoster en aan wie het meldde.

Het belangrijkste om mee te nemen is dat dit bijna allemaal geen ingewikkeld werk is. Het gaat om geduldig en systematisch controleren: één lijst met accounts, één lijst met bestanden, één lijst met databasetabellen, en de discipline om het onderzoek niet over te slaan omdat het opschonen productiever lijkt.

Als je op dit moment midden in een incident zit en de tijdlijn niet klopt (de logbestanden zijn verdwenen, de back-ups zijn allemaal te recent, of de site blijft maar terugkomen) dan is dat het moment waarop een tweede paar ervaren ogen meestal meer tijd bespaart dan het kost. Het methodisch herstellen van een gecompromitteerde Joomla-site en het vinden van de achterdeur waar iedereen aan voorbij is gelopen, is precies het soort werk dat een Joomla-specialist vaak genoeg doet om de patronen snel te herkennen.