Wie ich eine verdeckte Injektion aufgespürt und die Umgebung gehärtet habe

Wie ich eine verdeckte Injektion aufgespürt und die Umgebung gehärtet habe

Sie führen einen Malware-Scan durch. Sie ersetzen Core-Dateien. Sie aktualisieren Plugins und ändern Passwörter. Die Website sieht sauber aus.

Zwei Tage später ruft der Kunde an. Neue Admin-Accounts sind wieder da. Besucher werden auf bösartige Websites umgeleitet.

Das ist der Albtraum der Persistenz.

Standard-Sicherheits-Plugins versagen oft. Anspruchsvolle Angreifer platzieren nicht einfach nur einen Payload. Sie bauen verschachtelte Backdoors, die sich in legitimen Dateien verstecken.

Ich habe vor Kurzem einen Fall bearbeitet, bei dem drei Reinigungsversuche scheiterten. Die Symptome waren spezifisch:

• Ghost-Admins: Alle 48 Stunden tauchten neue Konten mit zufälligen Namen auf. • Bedingte Weiterleitungen: Nur neue Besucher aus Suchmaschinen sahen die bösartige Website. Entwickler sahen nichts.

Das Team hatte den WordPress-Core bereits überschrieben und die Plugins aktualisiert. Scanner zeigten nichts an. Die Malware regenerierte sich wie eine Hydra.

Der Angreifer hatte einen Persistenzmechanismus in der Datenbank oder einen Cronjob. Automatisierte Scanner übersahen ihn, weil der Code maßgeschneidert war.

Ich nutzte die Kommandozeile, um der Wahrheit auf den Grund zu gehen.

Zuerst habe ich die Core-Dateien mithilfe von Prüfsummen verifiziert: wp core verify-checksums

Der Core war sauber. Die Backdoor befand sich in wp-content oder in der Datenbank.

Ich suchte nach Dateien, die in den letzten 7 Tagen geändert wurden: find . -type f -mtime -7 -name "*.php"

Dann suchte ich nach verdächtigen Funktionen wie eval() oder base64_decode(): grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode('

Ich fand eine versteckte Datei in einem veralteten Premium-Plugin. Aber das Löschen des Plugins stoppte die Infektion nicht.

Der Angreifer hatte einen Trigger in der Tabelle wp_options unter der Option cron hinterlassen. Jedes Mal, wenn der WordPress-Cron lief, wurde ein neuer Payload abgerufen. Er infizierte die Core-Dateien bereits Minuten nach deren Bereinigung erneut.

Um dies zu beheben, müssen Sie einer strikten Reihenfolge folgen:

1. Datenbank-Bereinigung

• Suchen Sie in wp_options nach bösartigen Autoload-Daten.
• Überprüfen Sie wp_cron auf unbekannte URLs.
• Nutzen Sie SQL, um unbefugte Benutzer direkt zu löschen.

2. Bereinigung des Dateisystems

• Löschen Sie alles außer wp-config.php und wp-content/uploads/.
• Ersetzen Sie alles durch frische Dateien aus dem offiziellen Repository.
• Löschen Sie alle PHP-Dateien innerhalb des uploads-Ordners.

3. Rotation der Zugangsdaten

• Generieren Sie alle Authentication Salts in wp-config.php neu.
• Setzen Sie alle Datenbank-, SSH- und Hosting-Passwörter zurück.

Ich habe zudem drei Schutzmaßnahmen implementiert, um eine Wiederholung zu verhindern:

• Edge-Schutz: Ich habe die Cloudflare WAF verwendet, um verdächtige POST-Anfragen an sensible Verzeichnisse zu blockieren. • Dateiberechtigungen: Ich habe die Verzeichnisstruktur gesperrt. Verzeichnisse wurden auf 755 und Dateien auf 644 gesetzt. Ich habe die wp-config.php auf schreibgeschützt gesetzt. • Bearbeitung deaktivieren: Ich habe DISALLOW_FILE_EDIT und DISALLOW_FILE_MODS zur wp-config.php hinzugefügt. Dies verhindert, dass jemand Code über das Dashboard ändern kann.

Vertrauen Sie keinem grünen Häkchen eines Plugins. Gehen Sie davon aus, dass bereits eine Sicherheitsverletzung stattgefunden hat. Schützen Sie Ihre Website von innen heraus.

Quelle: https://dev.to/jahidshah/how-i-tracked-a-stealthy-injection-and-hardened-the-environment-4clm