Nep-beheerders in Joomla: verborgen Super Users vinden en verwijderen

Een aanvaller die via een kwetsbare extensie binnenkomt, heeft één acute zorg: die deur gaat straks dicht. Zodra jij die extensie updatet, is zijn toegang weg. Daarom is de eerste handeling na een succesvolle inbraak bijna altijd hetzelfde — een eigen manier om terug te komen. Het makkelijkste middel daarvoor is een gewoon Joomla-account met Super User-rechten. Geen exotische code, geen exploit: gewoon inloggen op je backend, net als jij.

Dat account valt niet op, want het is ontworpen om niet op te vallen. In deze uitleg lees je hoe je het vindt, op welke drie plekken je moet kijken, en waarom er meestal meer aan de hand is dan dat ene account.

Hoe een nep-beheerder eruitziet

Vergeet de namen die je verwacht. De accounts die wij aantreffen heten Web Editor, Content Manager, Support, Webmaster of simpelweg Admin2. Namen waarvan je denkt: die heeft de vorige bouwer vast aangemaakt. Het e-mailadres is vaak een wegwerpadres of een adres op een domein dat net genoeg op het jouwe lijkt.

Soms gaat het subtieler. In plaats van een nieuw account wordt het e-mailadres van een bestaande, inactieve beheerder gewijzigd. Het aantal accounts blijft dan gelijk — en daar kijk je naar — terwijl de aanvaller met "wachtwoord vergeten" op elk moment binnen kan. Controleer bij een verdachte situatie dus niet alleen de lijst, maar ook de e-mailadressen.

Checklist 1: de gebruikerslijst in de backend

Begin hier, want het kost twee minuten. Ga naar Users → Manage en werk dit af:

• Filter op de groep Super Users. Op de meeste sites horen daar één of twee accounts in te zitten. Zie je er meer, dan heb je werk te doen.
• Sorteer op registratiedatum, nieuwste eerst. Een account dat is aangemaakt op een moment dat jij niemand hebt toegevoegd, is verdacht — ongeacht hoe geloofwaardig de naam is.
• Controleer de kolom "Laatste bezoek". Een recent bezoek van een account waarvan jij weet dat de eigenaar er al een jaar niet is geweest, betekent dat iemand anders dat wachtwoord heeft.
• Loop alle e-mailadressen langs, ook die van accounts die je herkent.
• Kijk naar de andere groepen. Administrator en Manager geven ook backendtoegang. Een aanvaller die niet wil opvallen, kiest soms bewust niet voor Super User.
• Check Users → Groups voor nieuwe groepen met verdacht ruime rechten, en Users → Access Levels voor aanpassingen daaraan.

Checklist 2: de database

De backend liegt niet, maar hij kan wel iets verzwijgen. Een aanvaller met databasetoegang kan een account aan het overzicht onttrekken, bijvoorbeeld door het te blokkeren of door de toewijzing aan een groep zo te zetten dat het uit je standaardfilter valt. Kijk daarom ook rechtstreeks in de database, via phpMyAdmin of Adminer:

• #__users — alle accounts, met registerDate, lastvisitDate en email. Vergelijk het aantal rijen met wat je in de backend ziet.
• #__user_usergroup_map — welk account in welke groep zit. Groep 8 is standaard Super Users. Elke user_id die daar staat maar niet in je backendlijst voorkomt, is een probleem.
• #__usergroups — nieuwe of aangepaste groepen.
• #__action_logs — als actielogging aan stond, staat hier wie wat wanneer deed. Dit is vaak het snelste spoor terug naar het moment van de inbraak.
• #__extensions — plugins die je niet herkent, of een plugin die op enabled = 1 staat terwijl jij hem hebt uitgezet.
• #__session — actieve sessies. Een ingelogde sessie van een account dat niemand gebruikt, betekent dat iemand op dit moment binnen is.

De tabelprefix (#__) is op jouw site iets als jos_ of een willekeurige reeks; je vindt hem in configuration.php.

Checklist 3: het bestandssysteem

Een account is de makkelijke terugweg. De betrouwbare terugweg is een bestand. Zoek op de server naar:

• PHP-bestanden op plekken waar die niet horen: images/, tmp/, cache/, logs/ of een map met geüploade documenten.
• Recent gewijzigde bestanden. Sorteer de hele installatie op wijzigingsdatum. Alles wat is aangepast op een dag dat jij niets deed en er geen update draaide, verdient aandacht.
• Bestanden met een naam die er net naast zit, zoals index2.php, wp-config.php (op een Joomla-site) of configuration.bak.php.
• Toegevoegde regels in bestaande bestanden, meestal bovenaan of onderaan. Let op lange reeksen versleutelde tekst en functies als eval, base64_decode, gzinflate of assert.
• Een aangepaste .htaccess met doorverwijzingen of regels die uploads in een bepaalde map toestaan.
• Geplande taken: de Joomla Task Scheduler en de cronjobs in je hostingpaneel. Een taak die de besmetting elke nacht opnieuw plaatst, maakt elke schoonmaak zinloos.

De tweede vector: de JCE-profielen-hack

Er is één variant die zelden op een checklist staat en die wij regelmatig tegenkomen. JCE is een veelgebruikte editor voor Joomla en heeft een eigen rechtensysteem met profielen: per profiel staat ingesteld wie bestanden mag uploaden en welke bestandstypen zijn toegestaan.

Een aanvaller die één keer binnen is geweest, past zo'n profiel aan. Hij zet bij de toegestane extensies php, phtml of php7 erbij, of maakt een extra profiel dat aan alle gebruikersgroepen is toegewezen. Daarna heeft hij geen kwetsbaarheid meer nodig: hij kan via de doodnormale bestandsbeheerder van de editor een webshell uploaden. Je kunt JCE updaten zo vaak je wilt, die instelling blijft gewoon staan.

Controleer daarom bij elke schoonmaak Components → JCE Editor → Profiles: welke profielen bestaan er, aan wie zijn ze toegewezen, en welke bestandstypen staan er bij de upload-instellingen? Dezelfde logica geldt voor formulier-extensies met een uploadveld en voor mediabeheerders van derden.

Wat een echte schoonmaak inhoudt

Het verwijderen van een vals account duurt vijf seconden. Het probleem is dat je daarmee het gevolg opruimt en niet de oorzaak — en dat je de volgende ochtend een nieuw account aantreft. Een schoonmaak die wél standhoudt, bestaat uit deze stappen:

1. Vastleggen. Volledige backup van de besmette situatie, plus een notitie van alle verdachte accounts met datum en e-mailadres.
2. Tijdlijn bepalen. Uit registratiedata, bestandsdata en serverlogs volgt wanneer het begon. Zonder die datum weet je niet welke backup schoon is.
3. Alle toegangswegen dichten. Malafide bestanden weg, geïnjecteerde code uit legitieme bestanden halen, onbekende plugins verwijderen, geplande taken opschonen, uploadprofielen terugzetten.
4. De extensie updaten waardoor het binnenkwam. Vind je die niet, dan blijft de site kwetsbaar — dan is de kwetsbaarheid zelf het eerste wat we opsporen.
5. Credentials vervangen. Alle wachtwoorden, de databasegebruiker en de Joomla secret key uit configuration.php. Die laatste maakt gestolen sessies en tokens ongeldig en wordt bijna altijd vergeten.
6. Pas nu de valse accounts verwijderen, tweefactorauthenticatie aanzetten voor iedereen die overblijft, en de beheeromgeving afschermen.
7. Nacontrole. Een tweede scan een paar dagen later. Komt er niets terug, dan was het volledig.

Hulp nodig?

Vind je een account dat je niet kunt plaatsen, dan is de kans groot dat er meer ligt. Wij doen dit onderzoek dagelijks en werken met een doorlooptijd van 48 uur: opsporen, opruimen, dichtzetten en een rapport waarin staat wat er is gebeurd. Lees hoe dat werkt op Joomla website gehackt. Wil je daarna voorkomen dat het opnieuw gebeurt, kijk dan naar Joomla upgrade & veiligheid voor de hardening, en naar onderhoud & support voor het bijhouden ervan.