Vreemde beheerdersaccounts in CMS en server vinden

Kort gezegd: Vreemde beheerdersaccounts vindt u alleen als u alle lagen controleert: het CMS of de webshop, het hostingpaneel, de systeemgebruikers van de server, de SSH-toegangen en de databasegebruikers. Vertrouw niet op de gebruikerslijst in de backend, want ingebrachte code kan accounts daar verbergen. Vondsten eerst documenteren en blokkeren, dan de oorzaak vaststellen, pas daarna verwijderen.

Waarom een onbekende beheerder zo gevaarlijk is

Een extra beheerdersaccount is voor aanvallers de gemakkelijkste achterdeur. Het heeft geen schadelijke code nodig, valt bij bestandsscans niet op en overleeft elke update. Wie zich later met dit account aanmeldt, ziet er in het logboek uit als een gewone redacteur.

Na PHP2Shell wint deze controle aan gewicht. De lekken CVE-2026-109618 en CVE-2026-109619 maken de uitvoering van schadelijke code zonder aanmelding mogelijk. Wie code op de server kan uitvoeren, kan ook in de database schrijven en daarmee accounts aanmaken. Een PHP-update dicht het lek, maar verwijdert geen account dat eerder is ontstaan.

Voor PHP2Shell bestaan geen gepubliceerde, bevestigde Indicators of Compromise, dus geen lijst met typische sporen. Een onbekend account is daarom geen PHP2Shell-bewijs, maar wel een duidelijke aanwijzing voor onbevoegde toegang, ongeacht langs welke weg. Een overzicht van verdere tekenen staat onder Ben ik al gecompromitteerd?.

Waar vreemde beheerdersaccounts kunnen zitten

Veel exploitanten kijken alleen in het CMS. Aanvallers denken in lagen, en elke laag heeft eigen accounts:

De SSH-laag is zelfstandig genoeg voor een eigen artikel: Onbekende SSH-sleutels vinden en verwijderen.

Vreemde beheerdersaccounts in het CMS vinden, ook verborgen

De gebruikerslijst in de backend wordt door de toepassing zelf gegenereerd. Draait ingebrachte code mee, dan kan die afzonderlijke vermeldingen eruit filteren. Betrouwbaarder zijn daarom hulpmiddelen die rechtstreeks naar de opgeslagen gegevens kijken. Voor WordPress somt WP-CLI alle beheerders met aanmaakdatum op:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Nog een laag dieper gaat een lezende query in de database. Ze toont elk account waaraan de beheerdersrol is toegewezen, ongeacht wat de interface weergeeft. Het tabelvoorvoegsel wp_ past u aan uw installatie aan:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

Vergelijk de resultaten van backend, WP-CLI en database. Duikt een account alleen in de database op, dan is dat een sterk waarschuwingssignaal, omdat er dan bovendien code in het spel is die het verbergt. Voor andere systemen zoals Shopware, TYPO3 of Joomla geldt hetzelfde principe: de gebruikerstabel rechtstreeks bevragen en vergelijken met de weergave in de backend. Welke tabellen dat zijn, staat in de documentatie van de fabrikant.

Systeemgebruikers en databasegebruikers controleren

Op de server zelf zijn vooral accounts met rootrechten en accounts die zich kunnen aanmelden interessant. De volgende opdrachten lezen alleen:

# Accounts met UID 0 (normaal alleen root)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Accounts met een echte login-shell
grep -vE '(nologin|false)$' /etc/passwd

# Leden van de beheerdersgroepen
getent group sudo wheel

# Extra sudo-regels
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/

# Laatste aanmeldingen met volledige datum
last -F | head -30

Op de databaseserver controleert u welke gebruikers bestaan en welke rechten ze hebben:

SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';

Een toepassing heeft in de regel één gebruiker nodig met rechten op precies één database. Een extra gebruiker met globale rechten die vanaf willekeurige hosts (%) mag toegang krijgen, moet worden opgehelderd.

Vergeet de accounts buiten de server niet. Wie toegang heeft tot het domeincontract of het DNS-beheer, kan bezoekers omleiden of certificaten voor vreemde servers laten uitgeven. Een extra eigenaar in de Google Search Console kan sitemaps indienen en instellingen wijzigen. Loop daarom bij registrar, DNS-aanbieder, CDN en Search Console de lijst van gemachtigden na en vergelijk die met wat uw team kent.

Zo gaat u juist met een vondst om

De eerste impuls is het vreemde account meteen te verwijderen. Daarmee verdwijnt echter ook een belangrijk spoor: de aanmaakdatum beperkt vaak wanneer de aanvaller in het systeem was. Beter is deze volgorde:

1. Documenteren: Gebruikersnaam, ID, e-mail, aanmaakdatum, rol en laatste activiteit met tijdstip vastleggen, bij voorkeur als schermafbeelding en export.
2. Blokkeren in plaats van verwijderen: Rol intrekken, wachtwoord door een willekeurige waarde vervangen of het account deactiveren.
3. Periode afbakenen: Logs rond de aanmaakdatum controleren. Welke verzoeken waren er kort ervoor, welke bestanden veranderden?
4. Verdere lagen controleren: Wie een account aanmaakt, laat zelden slechts één ding achter. Bestanden, cronjobs, SSH-sleutels en database eveneens doorzoeken.
5. Opschonen en toegangen vernieuwen: Pas na opschoning en PHP-update alle wachtwoorden, sleutels en sessies vernieuwen.

Een opmerking ter voorzichtigheid: niet elk onbekend account is kwaadaardig. Bureaus, eerdere dienstverleners of onderhoudsplug-ins maken soms eigen accounts aan. Stel dat vast voordat u alarm slaat, maar doe het tijdig.

Terugkeer voorkomen

Na de opschoning moeten beheerdersaccounts de uitzondering zijn, niet de regel. Bewezen zijn persoonlijke accounts in plaats van gedeelde toegangen, zo weinig mogelijk beheerders en een tweestapsverificatie voor beheerderstoegangen. Leg bovendien vast wie nieuwe beheerdersaccounts mag aanmaken en waar dat wordt gedocumenteerd.

Een regelmatige query zoals de bovenstaande, bijvoorbeeld wekelijks en met vergelijking met de week ervoor, maakt nieuwe accounts snel zichtbaar. Bij WordPress helpt bovendien de gids Achterdeuren in WordPress vinden.

Hoe helpt PHP SOS concreet?

• Wij controleren alle accountlagen van CMS via server tot database en vergelijken de weergave in de backend met de opgeslagen gegevens.
• Wij stellen vondsten met tijdstempels veilig voordat accounts worden geblokkeerd of verwijderd.
• Wij stellen in het kader van de incident response vast hoe het account is ontstaan en of er verdere achterdeuren bestaan.
• Wij vernieuwen toegangen in de juiste volgorde en richten een doorlopende controle van nieuwe beheerdersaccounts in.

Veelgestelde vragen

Bronnen

• WordPress
• php.net: beveiligingsmeldingen
• BSI: aanwijzingen over IT-beveiligingsincidenten (Duitse federale dienst voor informatiebeveiliging)