Zusammenfassung
Wir reagieren auf einen Sicherheitsvorfall, der PushEngage betrifft. Ein Angreifer hat sich Zugang zu Anmeldeinformationen für unser Content Delivery Network (CDN) verschafft und diese genutzt, um eine manipulierte Version der JavaScript-Datei auszuliefern, die diese Produkte an Kunden-Websites liefern. Für ein begrenztes Zeitfenster luden Websites, die unser Skript einbetten, diese modifizierte Datei direkt von unserem CDN.
Der bösartige Code wurde nur für eingeloggte WordPress-Administratoren aktiviert. Wenn er auf einer betroffenen Website ausgeführt wurde, versuchte er, einen versteckten Administrator-Account zu erstellen und ein verschleiertes Backdoor-Plugin zu installieren, und sendete dann Daten an einen vom Angreifer kontrollierten Server. Normale Website-Besucher waren nicht das Ziel, aber da der Code einem Angreifer die Kontrolle über eine Website übertragen kann, sollte jede betroffene Website als kompromittiert behandelt werden.
Umfang – was erreicht wurde und was nicht:
Unsere Anwendungsserver, unser Quellcode und die Systeme, die Ihre PushEngage-Kontoinformationen speichern, sind separat gehostet und waren nicht betroffen. Wir haben keine Beweise dafür, dass auf Kontodaten oder persönliche Details, die wir speichern, zugegriffen wurde. Der Vorfall beschränkte sich auf unseren Marketing-Website-Server und, über einen dort gespeicherten CDN-API-Schlüssel, auf unser CDN-Konto. Wichtig ist, dass dies die Dringlichkeit für betroffene Website-Besitzer nicht verringert: Die an Ihre Website gelieferte Datei wurde manipuliert, weshalb die folgenden Schritte immer noch wichtig sind, wenn Sie sich im Expositionsfenster befanden.
Wer muss jetzt handeln: Wenn Ihre Website PushEngage aktiv hatte und ein Administrator während des unten genannten Expositionsfensters eingeloggt war, behandeln Sie Ihre Website bitte als kompromittiert und befolgen Sie sofort [Was zu überprüfen und zu tun ist](#what-to-check-and-do). Die zuverlässigsten Überprüfungen finden auf Ihrem Server statt, nicht im WordPress-Dashboard.
Expositionsfenster
Basierend auf den Protokollen unseres CDN-Anbieters war die unbefugte Konfiguration mit manipulierten Dateien ungefähr mehrere Stunden am 12. Juni 2026 (UTC) vorhanden. Bei einer Teilmenge von Benutzern wurde sie bis zum 14. Juni (UTC) von bestimmten CDN-Edge-Standorten weiter ausgeliefert. Wir überprüfen weiterhin den genauen Zeitraum, in dem betroffene Inhalte ausgeliefert wurden, und werden diese Mitteilung aktualisieren, sobald zusätzliche Details verifiziert sind.
Nur Websites, die das betroffene Skript mit einem eingeloggten Administrator während dieses Fensters geladen haben, könnten kompromittiert worden sein.
Die betroffenen Dateien waren die Standard-Einbettungsskripte, die von folgenden Adressen geliefert wurden:
- https://clientcdn.pushengage.com/sdks/pushengage-web-sdk.js (PushEngage)
- https://clientcdn.pushengage.com/sdks/pushengage-subscription.js (PushEngage)
Was ist passiert
Ein Angreifer nutzte eine bekannte Schwachstelle in einem Drittanbieter-WordPress-Plugin (UpdraftPlus), um Zugang zu dem Server zu erhalten, auf dem sich unsere Marketing-Website befindet. Dieser Server ist vollständig getrennt: anderer Host, andere Infrastruktur als die Anwendungsserver, die PushEngage betreiben und Kundendaten speichern.
Auf dem Marketing-Server fand der Angreifer einen API-Schlüssel für unser CDN-Konto. Mit diesem Schlüssel mussten sie unseren Anwendungsursprung überhaupt nicht anfassen. Sie modifizierten die Dateien, die unser CDN auslieferte, sodass das manipulierte Skript für eine begrenzte Zeit an Websites ausgeliefert wurde, die es einbetteten, bevor wir die Änderung entdeckten und rückgängig machten.
Wir haben seitdem die Marketing-Website bereinigt, auf einen neuen Server migriert und alle Anmeldeinformationen rotiert, einschließlich des CDN-API-Schlüssels.
Was der bösartige Code getan hat
Auf einer betroffenen Website versuchte der Code, wenn ein angemeldeter Administrator eine Seite lud:
- Bestätigen, dass er in einem WordPress-Admin-Kontext lief, und dann die Sicherheitstoken sammeln, die benötigt werden, um als dieser Administrator zu handeln.
- Erstellen eines versteckten Administrator-Kontos. Bekannte Konten sind developer_api1 ([email protected]) und zufällig generierte Konten der Form dev_xxxxxx.
- Installieren eines sich selbst versteckenden Backdoor-Plugins, das sich vor dem Dashboard verbirgt und eine nicht authentifizierte Webshell und einen Code-Ausführungsendpunkt freigibt – was effektiv die volle Kontrolle über die Website gewährt.
- Senden der neuen Anmeldeinformationen und Website-Details an einen vom Angreifer kontrollierten Server.
Da sich die Backdoor vor den WordPress-Admin-Bildschirmen versteckt, wird das Dashboard allein nicht anzeigen, ob Sie betroffen sind. Die zuverlässigen Prüfungen erfolgen auf dem Server-Dateisystem und über einen serverseitigen Scan.
Was zu prüfen und zu tun ist
Wenn Sie PushEngage auf Ihrer Website laufen hatten UND ein Administrator sich während des Expositionsfensters bei Ihrer WordPress-Website angemeldet hat, tun Sie so schnell wie möglich Folgendes. Wenn Sie unsicher sind, ob ein Administrator angemeldet war, ist es sicherer, dies zu überprüfen.
- Entfernen Sie nicht autorisierte Administrator-Konten. Suchen Sie nach developer_api1 / [email protected] und allen unerwarteten dev_xxxxxx-Konten und löschen Sie diese.
- Überprüfen Sie das Dateisystem – nicht nur das Dashboard – auf die Backdoor-Plugin. Suchen Sie unter wp-content/plugins nach content-delivery-helper („Content Delivery Helper“) oder database-optimizer („Database Optimizer“). Die Tarnung rotiert, vertrauen Sie also dem, was auf der Festplatte ist, mehr als dem, was das Dashboard anzeigt. Entfernen Sie alle gefundenen.
- Führen Sie einen serverseitigen Malware-Scan durch. Da die Payload nur für angemeldete Administratoren lief, sind Dashboard- und clientseitige Prüfungen unzuverlässig; ein serverseitiger Scan ist der zuverlässigste Weg, die Backdoor oder weitere Änderungen zu finden.
- Wenn Sie einen der obigen Indikatoren finden, gehen Sie von einer vollständigen Kompromittierung aus und rotieren Sie alles: Administrator-Passwörter, Anwendungs-/API-Schlüssel, Datenbank-Anmeldeinformationen und Ihre WordPress-Sicherheitsschlüssel/Salts in wp-config.php. Die Backdoor erlaubte beliebige Codeausführung, daher können zusätzliche Persistenzen vorhanden sein.
Wenn Sie keine dieser Indikatoren finden und während des Fensters kein Administrator angemeldet war, ist Ihre Website höchstwahrscheinlich nicht betroffen und es sind keine weiteren Maßnahmen erforderlich, abgesehen von der Standardhygiene (Zwei-Faktor-Authentifizierung aktivieren, Software auf dem neuesten Stand halten).
Was wir bisher getan haben
- Erkannten die Manipulation und machten die betroffenen CDN-Dateien sofort rückgängig; löschten den CDN-Cache, sodass saubere Dateien ausgeliefert werden.
- Widerriefen und rotierten den CDN-API-Schlüssel und alle zugehörigen Anmeldeinformationen.
- Die kompromittierte Marketing-Website wurde bereinigt und auf einen neuen Server mit separater Infrastruktur migriert.
- Bestätigt, dass unsere Anwendungsserver, Quellcodes und Kundendaten-Systeme, die sich auf separater Infrastruktur befinden, keine Anzeichen eines Zugriffs aufweisen.
- Unser Sicherheitsteam wurde eingeschaltet und wir arbeiten mit unserem CDN-Anbieter zusammen, um Zustellprotokolle zu erhalten.
Status und laufendes Risiko
Unsere CDN-Konfiguration wurde korrigiert und die manipulierten Dateien entfernt, die betroffenen Anmeldeinformationen wurden rotiert und der Einstiegspunkt auf unserem Marketing-Server wurde bereinigt.
Die Bereinigung unserer Systeme bereinigt keine Website, die bereits kompromittiert war. Wenn Ihre Website während des Expositionszeitraums betroffen war, bleiben das bösartige Administratorkonto und das versteckte Backdoor-Plugin bestehen, bis Sie sie mit den obigen Schritten entfernen. Wir empfehlen, umgehend zu handeln. Wir werden diese Seite aktualisieren, wenn zusätzliche relevante Informationen auftauchen.
Indikatoren für Kompromittierung
Für Website-Besitzer und Sicherheitsteams:
Bösartige Konten:
- developer_api1 / [email protected] (festes Betreiberkonto)
- dev_xxxxxx / [email protected] (zufällige Konten)
Tarnungen von Backdoor-Plugins (rotierend; Dateisystem prüfen):
- content-delivery-helper “Content Delivery Helper” v2.7.1
- database-optimizer “Database Optimizer” v2.9.4
Angreifer-Infrastruktur:
- tidio.cc (ähnlich aussehender Domain – NICHT das legitime tidio.com)
Eindeutige Zeichenfolgen:
- jX9kM2nP4qR6sT8v (Verschlüsselungsschlüssel, der von der Malware verwendet wird)
- WPM File Manager & Shell (Backdoor-Shell-Schnittstelle)
Kontakt
Wenn Sie Fragen haben, Hilfe bei der Überprüfung Ihrer Website benötigen oder etwas Ungewöhnliches bemerken, kontaktieren Sie uns unter [email protected]. Wir priorisieren Anfragen im Zusammenhang mit dem Vorfall und werden diese Seite auf dem neuesten Stand halten.
Der Schutz unserer Kunden hat für uns Priorität. Wir verstehen, dass dieser Vorfall besorgniserregend sein kann, und bedauern alle dadurch verursachten Störungen. Die obigen Informationen spiegeln unsere bisherige Untersuchung wider, und wir werden diese Seite aktualisieren, sobald zusätzliche Details bestätigt werden.
