Die Datenbank auf eingeschleusten Code prüfen

Kurz gesagt: Um die Datenbank auf Schadcode zu prüfen, durchsuchen Sie einen Export oder eine Kopie mit lesenden Abfragen nach eingeschleusten Skripten, fremden Adressen und verschleiertem Code in Inhalten und Einstellungen. Prüfen Sie außerdem Trigger, geplante Ereignisse, gespeicherte Prozeduren und die Datenbankbenutzer. Bereinigen Sie erst nach der Bewertung und nie per blindem Suchen und Ersetzen, weil serialisierte Daten sonst zerbrechen.

Der blinde Fleck vieler Bereinigungen

Nach einem Einbruch prüfen die meisten Betreiber die Dateien. Sie ersetzen den CMS-Kern, löschen verdächtige PHP-Dateien und spielen Erweiterungen neu ein. Die Website sieht danach sauber aus, und eine Woche später leitet sie wieder auf fremde Seiten um. Der Grund liegt oft in der Datenbank, die bei der Bereinigung unverändert übernommen wurde.

Für Angreifer ist die Datenbank ein attraktives Versteck. Ein Skript in einem Widget wird auf jeder Seite ausgeliefert. Eine geänderte Adress-Einstellung lenkt alle Besucher um. Ein zusätzliches Admin-Konto öffnet die Tür für später. Nichts davon fällt bei einem Datei-Scan auf.

Nach PHP2Shell, den Lücken CVE-2026-109618 und CVE-2026-109619 mit Codeausführung ohne Anmeldung, gehört die Datenbank deshalb zu jeder Prüfung. Wer Code auf dem Server ausführen kann, kann in der Regel die Zugangsdaten der Datenbank aus der Konfiguration lesen und dort beliebig schreiben. Wie die Anwendung überhaupt mit der Datenbank spricht, erklärt PHP und Datenbanken: PDO und mysqli.

Wo Schadcode in der Datenbank steckt

Die letzten drei Zeilen werden besonders oft übersehen, weil sie nicht in den Tabellen des CMS liegen, sondern im Datenbankserver selbst.

Bei Onlineshops verdient ein Fundort besondere Aufmerksamkeit: Einstellungen, über die zusätzliche Skripte in Kasse und Bestellabschluss eingebunden werden. Ein fremdes Skript an dieser Stelle kann Eingaben der Kunden mitlesen, bevor sie verschlüsselt an den Zahlungsdienst gehen. Prüfen Sie deshalb gezielt alle Felder für Kopf- und Fußzeilen-Code, Tracking-Einbindungen und Design-Einstellungen, die auf Kassenseiten wirken.

Denken Sie außerdem an weitere Datenbanken auf demselben Server. Test- und Staging-Kopien, alte Projektstände oder Datenbanken anderer Websites liegen oft daneben und sind mit denselben Zugangsdaten erreichbar. Was in der Live-Datenbank gefunden wird, sollte auch dort geprüft werden, bevor eine Kopie später wieder als Grundlage dient.

Datenbank auf Schadcode prüfen: Inhalte und Einstellungen

Arbeiten Sie auf einem Export. Er ist zugleich Beweissicherung und Suchgrundlage. Der Export lässt sich als Textdatei durchsuchen, ohne die laufende Datenbank zu belasten:

# Konsistenten Export erstellen (Zugangsdaten werden abgefragt)
mysqldump --single-transaction --routines --triggers --events -u BENUTZER -p DATENBANK > export.sql
sha256sum export.sql > export.sql.sha256

# Typische Muster im Export zählen
grep -oiE '<script[^>]{0,80}' export.sql | sort | uniq -c | sort -rn | head -30
grep -oiE '(eval\(|base64_decode|fromCharCode|document\.write|atob\()' export.sql | sort | uniq -c
grep -oiE 'https?://[a-z0-9.-]+' export.sql | sort | uniq -c | sort -rn | head -50

Die letzte Abfrage listet alle Domains, die in der Datenbank vorkommen, nach Häufigkeit. Fremde Domains, die niemand im Team kennt, sind die wichtigsten Kandidaten. Für gezielte Abfragen in der Datenbank selbst eignen sich SELECT-Befehle. Das Beispiel nutzt WordPress-Tabellen; das Präfix und die Tabellennamen anderer Systeme stehen in deren Dokumentation:

-- Einstellungen mit Skripten oder verdächtigen Funktionen
SELECT option_name, LENGTH(option_value) AS laenge
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%eval(%'
   OR option_value LIKE '%base64_decode%'
ORDER BY laenge DESC;

Einträge mit sehr großem Inhalt verdienen besondere Aufmerksamkeit. Hintergründe zu WordPress-spezifischen Verstecken bietet der Ratgeber Backdoors in WordPress finden.

Trigger, Ereignisse und Datenbankkonten

Trigger und geplante Ereignisse sind in vielen Webanwendungen gar nicht vorgesehen. Wenn sie existieren, sollte jemand erklären können, warum. Diese Abfragen lesen nur aus den Systemtabellen von MySQL und MariaDB:

-- Trigger in allen Datenbanken
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE, CREATED
FROM information_schema.TRIGGERS;

-- Geplante Ereignisse
SELECT EVENT_SCHEMA, EVENT_NAME, STATUS, CREATED, LAST_EXECUTED
FROM information_schema.EVENTS;

-- Gespeicherte Prozeduren und Funktionen
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE, CREATED
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');

-- Datenbankbenutzer
SELECT user, host FROM mysql.user ORDER BY user;

Nutzt Ihre Anwendung PostgreSQL oder ein anderes Datenbanksystem, heißen Systemtabellen und Befehle anders; das Prinzip bleibt gleich. Für die Analyse empfiehlt sich ein eigener Datenbankbenutzer, der nur lesen darf. So kann auch ein Tippfehler in einer Abfrage nichts verändern, und die Prüfung hinterlässt keine Spuren in den Daten.

Ein Trigger, der beim Speichern eines Beitrags Code anhängt, erklärt, warum Schadcode nach jeder Bereinigung zurückkehrt. Unbekannte Datenbankbenutzer gehören ebenso zur Kontenprüfung wie Admin-Konten im CMS; mehr dazu unter Fremde Admin-Konten in CMS und Server finden.

Sauber bereinigen, ohne Daten zu zerstören

Die Bereinigung ist der heikelste Teil. Diese Reihenfolge hat sich bewährt:

1. Funde bewerten: Jeder Treffer wird als bekannt, harmlos erklärbar oder fremd eingestuft. Tracking- und Kartencodes sind oft legitim.
2. Einfallstor schließen: PHP auf einen behobenen Stand bringen (8.5.12, 8.4.27, 8.3.36, 8.2.35 oder bestätigter Backport), alle Worker neu starten, Anwendung aktualisieren.
3. Gezielt entfernen: Fremde Inhalte über die Anwendung oder mit Werkzeugen bereinigen, die serialisierte Daten korrekt behandeln. Fremde Trigger, Ereignisse und Konten löschen.
4. Zugangsdaten wechseln: Neues Datenbankpasswort, in der Konfiguration der Anwendung eintragen, Rechte des Anwendungsbenutzers auf die eigene Datenbank begrenzen.
5. Nachprüfen: Die Suchabfragen nach einigen Tagen wiederholen.

Weiterleitungen, die trotz sauberer Datenbank auftreten, haben ihre Ursache in einer anderen Schicht. Der Beitrag Die Website leitet auf fremde Seiten um hilft bei der Eingrenzung.

Wie hilft PHP SOS konkret?

• Wir sichern die Datenbank mit Prüfsumme und durchsuchen den Export nach Skripten, fremden Domains und verschleiertem Code.
• Wir prüfen Trigger, Ereignisse, Prozeduren und Datenbankbenutzer, die außerhalb des CMS liegen.
• Wir bereinigen Funde im Rahmen der Malware-Entfernung, ohne serialisierte Daten zu beschädigen.
• Wir begrenzen die Rechte des Anwendungsbenutzers und wiederholen die Prüfung nach der Bereinigung.

Häufige Fragen

Quellen

• OWASP Top 10
• OWASP Cheat Sheets
• php.net: Sicherheitsmeldungen