Kurz gesagt: Fremde Admin-Konten finden Sie nur, wenn Sie alle Ebenen prüfen: das CMS oder den Shop, das Hosting-Panel, die Systembenutzer des Servers, die SSH-Zugänge und die Datenbankbenutzer. Verlassen Sie sich nicht auf die Benutzerliste im Backend, denn eingeschleuster Code kann Konten dort verstecken. Funde zuerst dokumentieren und sperren, dann Ursache klären, erst danach löschen.
Warum ein unbekannter Administrator so gefährlich ist
Ein zusätzliches Admin-Konto ist für Angreifer die bequemste Hintertür. Es braucht keinen Schadcode, fällt bei Datei-Scans nicht auf und übersteht jedes Update. Wer sich später mit diesem Konto anmeldet, sieht im Protokoll aus wie ein normaler Redakteur.
Nach PHP2Shell gewinnt diese Prüfung an Gewicht. Die Lücken CVE-2026-109618 und CVE-2026-109619 erlauben die Ausführung von Schadcode ohne Anmeldung. Wer Code auf dem Server ausführen kann, kann auch in die Datenbank schreiben und damit Konten anlegen. Ein PHP-Update schließt die Lücke, entfernt aber kein Konto, das vorher entstanden ist.
Für PHP2Shell gibt es keine veröffentlichten, bestätigten Indicators of Compromise, also keine Liste typischer Spuren. Ein unbekanntes Konto ist deshalb kein PHP2Shell-Beweis, aber ein klarer Hinweis auf unbefugten Zugriff, egal auf welchem Weg. Eine Übersicht weiterer Anzeichen steht unter Bin ich schon kompromittiert?.
Wo fremde Admin-Konten stecken können
Viele Betreiber schauen nur ins CMS. Angreifer denken in Ebenen, und jede Ebene hat eigene Konten:
| Ebene | Wo nachsehen | Worauf achten |
|---|---|---|
| CMS oder Shop | Benutzerverwaltung und Datenbanktabelle der Benutzer | Rolle Administrator, Anlagedatum, fremde Mailadresse |
| Hosting-Panel | Benutzer, Zusatzkonten, FTP-Konten | Konten, die niemand im Team angelegt hat |
| Linux-Server | /etc/passwd, Gruppen sudo oder wheel, sudoers |
weitere Konten mit UID 0, neue Login-Shells |
| SSH | authorized_keys aller Benutzer |
Schlüssel ohne bekannten Besitzer |
| Datenbank | Benutzertabelle des Datenbankservers | Benutzer mit globalen Rechten oder Host % |
| Externe Dienste | Domain, DNS, Search Console, CDN | zusätzliche Inhaber oder Berechtigte |
Die SSH-Ebene ist eigenständig genug für einen eigenen Beitrag: Unbekannte SSH-Schlüssel finden und entfernen.
Fremde Admin-Konten im CMS finden, auch versteckte
Die Benutzerliste im Backend wird von der Anwendung selbst erzeugt. Läuft eingeschleuster Code mit, kann er einzelne Einträge herausfiltern. Verlässlicher sind deshalb Werkzeuge, die direkt auf die gespeicherten Daten schauen. Für WordPress listet WP-CLI alle Administratoren mit Anlagedatum:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Noch eine Ebene tiefer geht eine lesende Abfrage in der Datenbank. Sie zeigt jedes Konto, dem die Administratorrolle zugeordnet ist, unabhängig davon, was die Oberfläche anzeigt. Das Tabellenpräfix wp_ passen Sie an Ihre Installation an:
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;
Vergleichen Sie die Ergebnisse von Backend, WP-CLI und Datenbank. Taucht ein Konto nur in der Datenbank auf, ist das ein starkes Warnsignal, weil dann zusätzlich Code im Spiel ist, der es versteckt. Für andere Systeme wie Shopware, TYPO3 oder Joomla gilt dasselbe Prinzip: Benutzertabelle direkt abfragen und mit der Anzeige im Backend vergleichen. Welche Tabellen das sind, steht in der Dokumentation des Herstellers.
Systembenutzer und Datenbankbenutzer prüfen
Auf dem Server selbst interessieren vor allem Konten mit Root-Rechten und Konten, die sich anmelden können. Die folgenden Befehle lesen nur:
# Konten mit UID 0 (normalerweise nur root)
awk -F: '$3 == 0 {print $1}' /etc/passwd
# Konten mit einer echten Login-Shell
grep -vE '(nologin|false)$' /etc/passwd
# Mitglieder der Admin-Gruppen
getent group sudo wheel
# Zusätzliche sudo-Regeln
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/
# Letzte Anmeldungen mit vollem Datum
last -F | head -30
Auf dem Datenbankserver prüfen Sie, welche Benutzer existieren und welche Rechte sie haben:
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
Eine Anwendung braucht in der Regel einen Benutzer mit Rechten auf genau eine Datenbank. Ein zusätzlicher Benutzer mit globalen Rechten, der von beliebigen Hosts (%) aus zugreifen darf, gehört geklärt.
Vergessen Sie die Konten außerhalb des Servers nicht. Wer Zugriff auf den Domain-Vertrag oder die DNS-Verwaltung hat, kann Besucher umleiten oder Zertifikate auf fremde Server ausstellen lassen. Ein zusätzlicher Inhaber in der Google Search Console kann Sitemaps einreichen und Einstellungen ändern. Gehen Sie deshalb bei Registrar, DNS-Anbieter, CDN und Search Console die Liste der Berechtigten durch und vergleichen Sie sie mit dem, was Ihr Team kennt.
So gehen Sie mit einem Fund richtig um
Der erste Impuls ist, das fremde Konto sofort zu löschen. Damit verschwindet aber auch eine wichtige Spur: Das Anlagedatum grenzt oft ein, wann der Angreifer im System war. Besser ist diese Reihenfolge:
- Dokumentieren: Benutzername, ID, E-Mail, Anlagedatum, Rolle und letzte Aktivität mit Uhrzeit festhalten, am besten als Bildschirmfoto und Export.
- Sperren statt löschen: Rolle entziehen, Passwort durch einen zufälligen Wert ersetzen oder das Konto deaktivieren.
- Zeitraum eingrenzen: Logs rund um das Anlagedatum prüfen. Welche Anfragen gab es kurz vorher, welche Dateien änderten sich?
- Weitere Ebenen prüfen: Wer ein Konto anlegt, hinterlässt selten nur eines. Dateien, Cronjobs, SSH-Schlüssel und Datenbank ebenfalls durchsehen.
- Bereinigen und Zugänge erneuern: Erst nach Bereinigung und PHP-Update alle Passwörter, Schlüssel und Sitzungen erneuern.
Ein Hinweis zur Vorsicht: Nicht jedes unbekannte Konto ist böswillig. Agenturen, frühere Dienstleister oder Wartungs-Plugins legen manchmal eigene Konten an. Klären Sie das, bevor Sie Alarm schlagen, aber klären Sie es zeitnah.
Wiederkehr verhindern
Nach der Bereinigung sollten Admin-Konten die Ausnahme sein, nicht die Regel. Bewährt haben sich persönliche Konten statt geteilter Zugänge, möglichst wenige Administratoren und eine Zwei-Faktor-Anmeldung für Admin-Zugänge. Legen Sie außerdem fest, wer neue Admin-Konten anlegen darf und wo das dokumentiert wird.
Eine regelmäßige Abfrage wie die obigen, etwa wöchentlich und mit Vergleich zur Vorwoche, macht neue Konten schnell sichtbar. Bei WordPress hilft zusätzlich der Ratgeber Backdoors in WordPress finden.
Wie hilft PHP SOS konkret?
- Wir prüfen alle Kontoebenen von CMS über Server bis Datenbank und gleichen Backend-Anzeige und gespeicherte Daten ab.
- Wir sichern Funde mit Zeitstempeln, bevor Konten gesperrt oder entfernt werden.
- Wir klären im Rahmen der Incident Response, wie das Konto entstanden ist und ob weitere Hintertüren bestehen.
- Wir erneuern Zugänge in der richtigen Reihenfolge und richten eine laufende Kontrolle neuer Admin-Konten ein.
Häufige Fragen
Soll ich ein unbekanntes Admin-Konto sofort löschen?
Besser nicht sofort. Dokumentieren Sie zuerst Benutzername, Anlagedatum, E-Mail-Adresse und letzte Aktivität und sperren Sie das Konto. Gelöscht wird erst, wenn die Spuren gesichert sind, denn das Anlagedatum ist oft ein wichtiger Hinweis auf den Zeitpunkt des Einbruchs.
Kann ein Admin-Konto im Backend unsichtbar sein?
Ja. Eingeschleuster Code kann einzelne Konten aus der Benutzerliste der Oberfläche ausblenden. Eine direkte Abfrage der Datenbank oder ein Kommandozeilenwerkzeug zeigt dagegen alle gespeicherten Konten. Deshalb sollten Sie nicht nur im Backend nachsehen.
Welche Ebenen muss ich außer dem CMS prüfen?
Hosting-Panel, FTP- und SFTP-Zugänge, Systembenutzer des Servers einschließlich sudo-Rechten, SSH-Schlüssel, Datenbankbenutzer sowie Konten bei Domain, DNS und Search Console. Ein Angreifer braucht nur eine dieser Türen, um zurückzukommen.
Reicht es, nach dem Fund alle Passwörter zu ändern?
Nein. Ein fremdes Konto zeigt, dass jemand Zugriff hatte. Dann müssen auch das Einfallstor, weitere Hintertüren und mögliche Datenabflüsse geklärt werden. Passwörter ändern Sie erst nach der Bereinigung und von einem sauberen Gerät aus.