So spüren Sie versteckte WordPress-Backdoors mit WP-CLI und SQL auf
makedream30 Juli 2026
0
Internet Technology
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
Bei einer von Agenturen oder Freelancern erstellten WordPress-Website zögert man oft, auf den Button für das Core-Update zu klicken. Aus Angst, dass sich Themes oder individuelle Plugins verhaken und der Bildschirm weiß bleibt (White Screen of Death), schiebt man es auf – bis die Website voller Sicherheitslücken steckt. Wenn sich das mulmige Gefühl breitmacht, dass die Seite bereits gehackt worden sein könnte, hilft dieses praxisnahe Prüfverfahren, um Datenbank und Server schnellstmöglich zu durchleuchten.
Angreifer verschaffen sich meist unauffällig Zugang. Eine typische Methode besteht darin, die Tabelle wp_usermeta in der Datenbank direkt zu manipulieren, um einem bestehenden Konto klammheimlich Administratorrechte zu gewähren. In der normalen Benutzerliste im Dashboard fällt das kaum auf, aber eine direkte Datenbankabfrage bringt es sofort ans Licht.
`sql
SELECT
u.ID,
u.user_login,
u.user_email,
u.user_registered,
m.meta_value AS capabilities
FROM
wp_users u
INNER JOIN
wp_usermeta m ON u.ID = m.user_id
WHERE
m.meta_key = 'wp_capabilities'
AND (
m.meta_value LIKE '%"administrator"%'
OR m.meta_value LIKE '%"administrator":true%'
)
ORDER BY
u.user_registered DESC;
`
Als Nächstes ist das Dateisystem an der Reihe. Wenn im Verzeichnis wp-content/uploads, in dem eigentlich nur Bilder oder Dokumente liegen sollten, PHP-Dateien herumdümpeln, handelt es sich in neun von zehn Fällen um eine Backdoor. Öffnen Sie ein SSH-Terminal und durchsuchen Sie das System nach gefährlichen Dateien.
`bash
find wp-content/uploads/ -type f -name "*.php" -ls
find . -type f -name "*.php" -exec grep -HnE "(eval(|base64_decode(|gzinflate(|passthru(|shell_exec()" {} ;
wp core verify-checksums --include-root
`
Auch die Server-Logs müssen überprüft werden. Angriffe auf die REST-API feuern meist in kurzer Zeit zahlreiche POST-Requests ab und erzwingen die Antworten 200 oder 201. Filtern Sie in der access.log von Nginx nach Anfragen, die verdächtige Reaktionen gezeigt haben.
`bash
grep -E "POST|PUT" /var/log/nginx/access.log | grep -E "/wp-json/|rest_route=" | awk '/ {print $1, $4, $6, $7, $9}' | sort | uniq -c | sort -nr | head -n 30
`
Patches direkt auf der Live-Website einzuspielen, ist kein Mut, sondern grenzt an Leichtsinn. Erstellen Sie zuerst eine Staging-Umgebung, indem Sie die Datenbank und das Dateisystem komplett duplizieren.
`bash
wp db export production_backup.sql --add-drop-table
rsync -avz --exclude='wp-content/cache' /var/www/html/ staging:/var/www/staging/
wp db import production_backup.sql
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid
wp plugin list --update=available --fields=name,version,update_version,requires_php --format=table
`
Sobald die Duplizierung abgeschlossen ist, führen Sie die Updates durch und testen Sie mindestens 5 Minuten lang die Kernfunktionen. Registrierung, Login, Warenkorb, Aufruf der Kasse und Absenden von Kontaktformularen sollten Sie selbst manuell durchklicken, um auf Nummer sicher zu gehen.
Es gibt frustrierende Situationen, in denen das Core-Update nicht sofort durchgeführt werden kann, weil der Entwickler eines Plugins kein Update bereitstellt. In solchen Fällen müssen Sie Zeit gewinnen, indem Sie den Zugriff auf bestimmte Pfade auf Serverebene oder über eine WAF blockieren. Wenn Sie Nginx nutzen, sperren Sie in der nginx.conf die Endpunkte für die REST-API-Benutzererstellung und Batch-Verarbeitung für alle IPs außer Ihrer eigenen.
`nginx
location ~* ^/wp-json/(batch/v1|wp/v2/users) {
limit_except GET {
allow 192.0.2.1;
deny all;
}
try_files $uri args;
}
`
Für den Fall der Fälle empfiehlt es sich außerdem, ein Backup-Skript einzurichten, das die Datenbank und den Uploads-Ordner in einen S3-Bucket hochlädt.
`bash
#!/bin/bash
WP_PATH="/var/www/html"
BACKUP_DIR="/tmp/wp_backups"
DATE=$(date +%Y%m%d_%H%M%S)
S3_BUCKET="s3://my-wordpress-secure-backups"
mkdir -p $BACKUP_DIR
wp db export BACKUP_DIR/db_DATE.sql --path=$WP_PATH --quiet
tar -czf BACKUP_DIR/files_DATE.tar.gz -C $WP_PATH wp-content/uploads/
aws s3 cp BACKUP_DIR/db_DATE.sql S3_BUCKET/db_DATE.sql
aws s3 cp BACKUP_DIR/files_DATE.tar.gz S3_BUCKET/files_DATE.tar.gz
find $BACKUP_DIR -type f -mtime +7 -delete
`
Mit dem Löschen von Schadcode und dem Einspielen von Sicherheitspatches ist die Arbeit noch nicht getan. Angreifer könnten sich mit gestohlenen Session-Cookies erneut Zugang verschaffen. Beenden Sie daher alle aktiven Sitzungen und erneuern Sie sämtliche Salt-Keys in der wp-config.php.
`bash
wp user list --field=ID | xargs -n 1 wp user session destroy --all
wp config shuffle-salts
`
Deaktivieren Sie außerdem die Funktion, mit der Plugins oder Theme-Dateien direkt im Admin-Dashboard bearbeitet werden können. Dies ist eine grundlegende Sicherheitsmaßnahme, die verhindert, dass Angreifer Code einschleusen, selbst wenn sie Admin-Rechte erlangen. Fügen Sie die folgenden zwei Zeilen in die wp-config.php ein:
`php
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
`
Fügen Sie schließlich einen eigenen Filter im Verzeichnis mu-plugins ein, um zu verhindern, dass nicht angemeldete Benutzer die Benutzerliste über die REST-API ausspähen.
`php
<?php
/**
`