Trzy rodziny backdoorów w jednej instalacji WordPress

Die Kundenseite war einige Tage lang nicht verfügbar. Darunter: drei unabhängige Backdoor-Familien, ein chinesischer C&C-Server, ein ukrainischer Telegram-Bot und ein Phishing-Kit, das sich als japanischer Laden tarnt. Alles in einer WordPress-Installation, die von außen gesund aussah.

Als der Kunde uns kontaktierte, gab es kein einziges „etwas funktioniert nicht” -Symptom. Es gab ein spezifisches, messbares Problem: Die Unternehmenswebsite reagierte nicht. Unter diesem Misserfolg gab es ein Dutzend oder so kleine Signale, die einzeln nichts bedeuteten, aber zusammen ein Bild von systematischen, langfristigen Zugriffen Dritter auf den Server bildeten. Wir haben die Geschichte an einem Tag beendet. Wir haben den Mechanismus verlassen, der uns die Gewissheit gab, dass das Problem wirklich für den Kunden dauerhaft verschwunden ist. Wenn Sie genau diese Art von Pflege suchen, unterhalts- und Entwicklungsangebote der Parteien.

Im Falle einer Unternehmenswebsite, die als Website und Leads-Quelle fungiert, ist es ein einfacher Weg zu einem messbaren Verlust:

• null RFQs für den gesamten Zeitraum der Nichtverfügbarkeit
• suchmaschineneinträge, die für Wochen nach der Rückkehr wieder aufgebaut werden sollen (Google stürzt in wenigen Stunden aus dem Index ab, stellt in wenigen Wochen wieder her)
• vertrauensverlust von Kunden, die in der Zwischenzeit auf eine Fehlermeldung gestoßen sind
• das Risiko, die Domain von Google Safe Browsing und Microsoft SmartScreen dauerhaft als „betrügerische Website” zu markieren, was die Website in Chrome, Edge, Firefox und in Antivirus-Warnungen auch nach dem Entfernen des Codes blockiert

Unsere Arbeit begann mit fehlerwiederherstellung: Die Wiederherstellung der Verfügbarkeit der Website für den normalen Datenverkehr war der erste Schritt, und die Diagnose und Bereinigung fanden erst nach dem Start der Seite parallel statt.

Branche und Kontext

Der Kunde betreibt mit Elementor Pro und der Jet-Plug-in-Familie einen Corporate Landing + Offer Service auf Basis von WordPress. Shared Hosting. Ein Standard-Stack, der Hunderttausende von Unternehmen in Polen bedient. Deshalb ist dieser Fall interessant: Er zeichnet sich durch nichts Besonderes aus. Es hätte die Website eines beliebigen Unternehmens sein können. Zum Vergleich:, ähnlicher WordPress-Fall, den wir für die Numerologie-Schule gemacht haben: andere Branche, gleiche Komplexität unter der Haube.

Ausgangspunkt

Kleine, schwer zu verbindende Dinge begannen auf der Website zu passieren:

• in regelmäßigen Abständen erschienen neue Dateien index.php in zufälligen Plugin-Unterordnern
• Datei license.txt im Hauptkatalog war Null-Größe und wurde regelmäßig alle paar Tage „bemuskelt” (Änderung des Zeitstempels ohne Änderung des Inhalts)
• in der Google Search Console wurden auf Japanisch indizierte Seiten vorgestellt, die nicht veröffentlicht wurden
• neben WordPress, unter Quiz, das Quiz „Berechnung der Kosten für die Photovoltaikanlage” lief in polnischer Sprache, obwohl sich der Auftraggeber nicht mit Photovoltaik beschäftigt

Jedes dieser Signale kann separat ignoriert werden. Zusammen ist es ein Lehrbuchmuster der langfristigen Verlegenheit.

Diagnose: drei Hintertürfamilien + Phishing-Kit

Die Untersuchung ergab, dass der Server im Raum der mehr als drei Jahre, von verschiedenen Gruppen, mit unterschiedlichen Zielen. Nachfolgend finden Sie eine kurze Beschreibung jeder der Familien, und unter jeder Beschreibung gibt es einen Abschnitt mit technischen Details für Interessierte.

Familie 1: Japanischer SEO-Umhang + chinesischer RCE

Allgemein index.php die Website, auf der normalerweise WordPress ausgeführt wird, wurde überarbeitet, um drei überlappende Schichten bösartigen Codes. Ein normaler Benutzer aus Polen sah eine normale Seite. Der Googlebot aus Japan hat einen gefälschten Shop gesehen. Der Angreifer mit dem richtigen Parameter in der URL erhielt Remotecodeausführung.

Familie 2: Pipette mit zufälligen Hashes

Die zweite Familie ist fernlader, die von Zeit zu Zeit einen neuen Ordner mit einem zufälligen Hash erstellt und PHP hineingeworfen hat, der durch kräuselung eine Textantwort vom C&C-Server abgerufen und über abwägen. Drei Generationen von Dropper lebten parallel im Server, in verschiedenen Altersstufen. Die älteste von Dezember 2022.

Familie 3: Magic-URL-Admin-Ersteller mit automatischer Heilung

Es war die gefährlichste Familie, weil sie bauen sich selbst wieder auf. Eine HTTP-ANFRAGE mit dem entsprechenden Parameter in der URL veranlasste den Server, selbst ein WordPress-Administratorkonto zu erstellen und den Angreifer sofort zu protokollieren. Die zweite Datei, an einem versteckten Ort, baute das Ganze wieder auf, wenn jemand die erste löschte.

Add-on: Phishing-Kit Quiz

Unabhängig von Hintertüren, in einem Unterordner Quiz Es gab ein Quiz basierend auf SaaS Marquiz. Quizaufbau: Polnischer Lead-Gen-Betrug für Photovoltaik. Leads aus dem Formular wurden über zwei Kanäle gesendet: an das Firmenpostfach des Kunden (Der Angreifer gab seine Adresse als Absender aus) i auf dem ukrainischen Telegram-Bot (Chat-ID + Bot-Token im Code eingebettet).

Zeitleiste des Angriffs (rekonstruiert)

Drei Jahre Persistenz, einschließlich einer Reihe aktiver Operationen im letzten Monat. Der Kunde wusste nichts davon.

Was wir getan haben

Schritt 1: Verfügbarkeit wiederherstellen

Die ersten Stunden wurden damit verbracht, die Website überhaupt zum Laufen zu bringen, egal, was wir darunter finden. Außenverkehr ausschließen, einen sauberen Einstiegspunkt wiederherstellen (index.php), wobei offensichtliche 500er entfernt werden. Erst dann begann die eigentliche Diagnose.

Schritt 2: Aufzählung aller Dropper

Vollständiger Webroot-Scan mit charakteristischen Markern (gehe zu +base64, 2DUAN, eval(curl(...)), ungewöhnliche Anführungszeichen in Ordnernamen als Anti-Lstat-Trick). Jede gefundene Datei: Offsite-Sicherung + Löschung.

Schritt 3: Schneiden der Regenerationskette

Familie 3 regeneriert für fixer.php. Soweit unserem fixer.php er am Leben war, kamen die anderen Akten zurück. Wir mussten feststellen, dass fixer.php existiert in drei Standorte gleichzeitig und entfernen Sie alle drei in einem Durchgang. Nach dem ersten Versuch, bei dem wir nur eine Kopie im Theme gelöscht haben, kamen die Dateien innerhalb weniger Minuten zurück.

Schritt 4: Phishing-Kit + Telegramm

Löschen eines gesamten Verzeichnisses Quiz und das zugehörige Marquiz-Konto (wir haben dem Kunden eine Liste der Schritte gegeben, die er bei sich zu Hause durchführen muss). Sperren von Sendungen aus eigener Domäne als Absender (SPF + DMARC ablehnen).

Schritt 5: Watcher Mu-Plugin (bleibt dauerhaft)

Wir haben ein spezielles Mu-Plugin entwickelt, nennen wir es einen „forensischen Beobachter”, der in wp-content/mu-plugins/ und startet mit jeder PHP-Anfrage. Es ist Teil des Pakets, das wir jedem Vertrag als Teil wartung und Entwicklung der Parteien.

Schritt 6: Datenbank-Audit

Darüber hinaus haben wir durch den Beobachter überprüft, dass es gibt keinen Müll von Angreifern in der Basis: wp_users (der einzige Administrator ist ein Kundenkonto, keine von Angreifern erstellten Konten), wp_options.autoload (sauber), WP-Cron (sauber, keine registrierten Haken, die nicht Standard-Plugins zugeordnet werden können).

Warum es überhaupt passiert ist

Drei unabhängige Vektoren sind selten, aber die spezifischen Gründe, die Angreifer eingeben, sind eines von drei Dingen in 95%-Fällen:

1. Veraltete Plugins mit öffentlichem CVE. Der Server verfügte vor etwa einem Dutzend Monaten über mehrere Plugins aus der Jet-Familie. Einer von ihnen hatte im Zeitraum 2022-2023 eine öffentlich beschriebene Lücke, die den Upload authentifizierter Dateien ermöglichte.
2. Schwaches Admin-Passwort oder Leck aus externem Dienst (Datenschutzverletzung). Der ursprüngliche Kompromiss war möglicherweise nicht „technisch”: Es reicht aus, dass jemand an mehreren Stellen dasselbe Passwort verwendet hat und einer von ihnen durchgesickert ist.
3. Gemeinsames Gastgeben. Einige dokumentierte Angriffe auf Shared Hosting beinhalteten den Übergang von einer kompromittierten Seite eines Nachbarn zur anderen durch eine gemeinsame TMP oder die Standard-Verzeichnisrechte.

Ergebnisse in Zahlen

Was uns dieser Fall gelehrt hat

1. Hintertüren können nebeneinander existieren

Die Gewohnheit „ein Angriff = eine Art von Schädling” ist irreführend. Wenn eine Seite seit Jahren exponiert und anfällig ist, könnte sie mehrmals von verschiedenen Gruppen mit unterschiedlichen Zielen kompromittiert worden sein. Jeder von ihnen hinterlässt seinen eigenen Mechanismus der Beharrlichkeit und jeder von ihnen muss separat gefunden werden. Das Anhalten nach dem Löschen der ersten Datei ist ein häufiger Fehler.

2. Auto-Heilung ist der wichtigste Überlebensmechanismus moderner Malware

Dateien an sichtbaren Stellen sind Köder. Der wahre Überlebensmechanismus ist regenerator an einem nicht offensichtlichen Ort, der sichtbare Dateien jedes Mal neu erstellt, wenn jemand sie löscht. Wenn nach dem „Löschen” der Seiten die Dateien innerhalb weniger Stunden zurückkehren, bedeutet dies, dass nur die Symptome beseitigt wurden.

3. Ihre Domain kann ein Werkzeug sein, auch wenn Ihre Website in Ordnung aussieht

Das Phishing-Kit mit dem Telegram-Bot hat aus Sicht des Besuchers nichts sichtbar gemacht. Er hat keine Anzeigen geschaltet, er hat nicht umgeleitet, er hat SEO nicht geändert. Er hat nur verwendet domain als Absender. Für Google, Microsoft, Barracuda und den Rest der Anti-Spam-Betreiber sieht es so aus, als ob du derjenige bist, der das Phishing sendet. Die Folgen (SPAMhaus Blacklist, Verlust der Zustellbarkeit) sind gravierender als Defacement.

4. Datei-Überwachung ist kein Luxus

Die meisten Kunden erkennen den Angriff erst, wenn etwas visuell kaputt geht: Die Seite wird nicht geladen, eine Chrome-Warnung „Täuschungsseite” erscheint, Google stürzt aus dem Index ab. An dieser Stelle dauern schädliche Aktivitäten auf dem Server oft monatelang an. Ein einfacher Beobachter, der Änderungen protokolliert .PHP, gibt die Reaktionszeit in Stunden an, nicht in Monaten. Dies ist ein Standardbestandteil jedes unserer Verträge wartung.

5. Backups vor dem X-Datum enthalten Hintertüren

Der Standardreflex nach Erkennung eines Kompromisses („Ich werde das Backup von vor einer Woche wiederherstellen”) würde in diesem Fall nicht funktionieren. Das Backup von vor einer Woche enthielt einen kompletten Satz von Hintertüren. Auch ein Backup von vor einem Jahr. Der einzige Weg ist eine vollständige forensische Bereinigung + frische Backups von Grund auf.

Für wen dieser Fall wichtig ist

• Inhaber von Unternehmenswebsites auf WordPress, die „von einer Agentur gehostet werden” und nicht wissen, wer für ihre Sicherheit verantwortlich ist
• Unternehmen, die aufgehört haben, Plugins zu aktualisieren, weil „es funktioniert, nicht bewegen”
• Jeder, der seltsame Dateien auf seiner Website gesehen hat index.php an unerwarteten Orten und entfernte sie manuell, vorausgesetzt, es war das Ende der Angelegenheit

Wenn Ihnen das bekannt vorkommt, ist ein guter erster Schritt prüfung aller Akten .PHP im Server-Webroot + Liste der Administratorkonten in WordPress. Ein solches Audit dauert in der Regel einige Stunden und zeigt, ob das Problem überhaupt besteht. Noch mehr Fälle finden Sie in den Ressourcen, das vollständige Angebot ist in Unser Angebot umfasst:.