CWPdoor: Hintertür im Control Web Panel erkennen und bereinigen

CWP-Server prüfen lassen? WZ-IT prüft Linux-Server im Server-Audit und betreibt sie mit Server-Betreuung und CVE-Monitoring. Ein Verdacht auf Kompromittierung wird gesondert eingeordnet. Termin vereinbaren

Am 5. November 2026 hat das Forschungsteam XLab von QiAnXin die Hintertür CWPdoor im Control Web Panel (CWP, früher CentOS Web Panel) veröffentlicht. Sie steckt nicht in einer Zusatzdatei, sondern im Webserver des Panels. Angreifer haben den Quelltext von cwpsrv um Hintertürcode ergänzt, neu kompiliert und die Original-Binary ersetzt. Die Hintertür bleibt passiv, bis eine signierte Anfrage eintrifft, und hinterlässt dann keinen Eintrag im Access-Log. BleepingComputer und The Hacker News haben den Bericht aufgegriffen.

CWP ist ein Hosting-Panel für CentOS und andere Linux-Distributionen mit kostenloser Variante; daneben gibt es CWPpro. cwpsrv bedient die Oberfläche, über die Websites, DNS und Mail der gehosteten Accounts verwaltet werden. Wer diesen Dienst kontrolliert, kann je nach Ausführungsrechten, Konfiguration und Isolation auf einen großen Teil dessen zugreifen, was das Panel verwaltet.

Dieser Beitrag fasst zusammen, wie CWPdoor arbeitet, was die Versionsangaben bedeuten, welche Befehle den Befall prüfen, wo diese Prüfung an Grenzen stößt und was bei einem Treffer zu tun ist. Alle Angaben haben den Stand 9. November 2026. Für cPanel gilt dieser Fall nicht; dazu gibt es den Beitrag cPanel CVE-2026-41940.

Inhaltsverzeichnis

1. Das Wichtigste in Kürze
2. So funktioniert CWPdoor
3. Welche cwpsrv-Versionen sind betroffen
4. Was noch unbekannt ist
5. Indikatoren im Überblick
6. Server prüfen: Befehle für Admins
7. Was eine saubere Prüfung nicht beweist
8. Bei einem Treffer: so gehen Sie vor
9. Absicherung für CWP-Server
10. Hosting-Panels als Angriffsziel
11. Unser Vorgehen bei WZ-IT
12. Weiterführende Guides

Das Wichtigste in Kürze

Quelle: XLab, CWPdoor.

CWPdoor ist keine Schwachstelle in CWP, sondern ein Implantat. Der erfasste Installer läuft nur mit Root-Rechten. Ob dem ein eigener Root-Einbruch vorausgeht oder ein Administrator das Skript als vermeintliches Update ausführt, ist nicht bekannt; XLab kennt den Verbreitungsweg nicht. Die Hintertür ermöglicht danach verdeckten Zugriff auf den Server.

So funktioniert CWPdoor

Installation. Das Erfassungssystem von XLab hat am 29. Juni 2026 das Skript cwpsrv_update.sh gefunden. Es gibt sich als Versionsupdate aus, läuft nur als Root und unterstützt nur cwpsrv 1.24.0 und 1.15.10. Der Ablauf nach XLab:

1. Die lokale cwpsrv-Version prüfen, die passende Binary von 136.0.141.71 laden und die Version der geladenen Datei verifizieren.
2. Die Original-Binary sichern, den Dienst stoppen, /usr/local/cwpsrv/bin/cwpsrv überschreiben und den Dienst starten.
3. Prüfen, ob Master-, Worker- und Helper-Prozess laufen. Bei einem Fehler macht das Skript den Austausch rückgängig.
4. Bei Erfolg die temporären Dateien und das Backup löschen.
5. Zugriffs- und Änderungszeit (atime und mtime) der neuen Binary und des übergeordneten Verzeichnisses auf die ursprünglichen Werte zurücksetzen, bei Erfolg wie bei Fehler.
6. Mit history -d den Befehlsverlauf der aktuellen Sitzung bereinigen (siehe Hinweis unten).
7. Das Ergebnis an 136.0.141.71 melden.

Nach XLab erscheint die ersetzte Datei bei Routineprüfungen mit ls und stat damit so, als sei sie nie verändert worden. Das gilt für atime und mtime: stat zeigt zusätzlich die Änderungszeit des Inodes (ctime), die das Zurücksetzen nicht erfasst (Prüfschritt 6). XLab beschreibt history -d als Löschen des Sitzungsverlaufs; laut Bash-Handbuch entfernt -d jedoch nur einen angegebenen Eintrag oder Bereich (-c leert die ganze Liste). Wie vollständig der Verlauf bereinigt wird, ist deshalb offen.

Auslöser. Der Angreifer sendet eine HTTP-Anfrage mit drei Headern an den Panel-Port. Die Prüfung läuft am Eintritt der Anfragebearbeitung:

Der AES-Schlüssel ist der SHA-256-Wert des eingebetteten Public-Key-Strings, der Public Key liegt in der Binary XOR-verschleiert (Byte 0x55). Scheitert die Zeit- oder Signaturprüfung, behandelt cwpsrv die Anfrage wie normalen Verkehr. XLab bewertet die Bindung der drei Felder aneinander und das 300-Sekunden-Fenster als Replay-Schutz und Autorisierung. Ob die Hintertür bereits verarbeitete Anfragen zusätzlich verwirft, beschreibt der Bericht nicht; ein vollständiger Schutz gegen Wiederholung innerhalb des Fensters ist damit nicht belegt.

Ausführung und Antwort. Der Master-Prozess entschlüsselt den Befehl und übergibt ihn über einen Unix-Socket namens ngx_http_integrity_helper an einen separaten Helper-Kindprozess. Das Ergebnis geht AES-verschlüsselt als HTTP 200 mit dem Content-Type application/octet-stream zurück. Mit welchen Rechten der Helper arbeitet, nennt XLab nicht.

Keine Spur im Log. Bei einer auslösenden Anfrage kopiert und verändert die Hintertür das Kontext-Array der Anfrage und ersetzt den Zeiger des Logging-Moduls. Die Anfrage wird dadurch nicht protokolliert.

Drei Folgen für die Praxis:

• Kein zuverlässiger Test von außen. Ohne gültige Signatur verhält sich der Server wie ein normaler cwpsrv. Eine gültige Signatur erzeugt nur, wer den zugehörigen privaten Schlüssel besitzt; eine bereits signierte Anfrage genügt innerhalb ihres Zeitfensters. Die Prüfung gehört auf den Server oder an eine gesicherte Kopie der Binary.
• Das Access-Log belegt keine Sauberkeit. Ein leeres oder unauffälliges Access-Log schließt eine Nutzung nicht aus.
• Binary und Host sind die Prüfgrundlage. Socket, Prozesse, Strings, Hash und ausgehende Verbindungen sind die Prüfpunkte.

Welche cwpsrv-Versionen sind betroffen

Quellen: Versionen und Hashes aus dem XLab-Bericht, Plattformzuordnung aus dem CWP-Changelog (Version 1.29).

Die Versionsnummern sind die nginx-Basisversionen der Standard-Builds von cwpsrv. Der Changelog zu CWP 1.29 vom 31. Oktober 2026 formuliert: cwpsrv wurde auf nginx 1.30.6 angehoben, von 1.24.0 auf EL8/EL9 und 1.15.10 auf EL7. Daraus folgt eine Einordnung, die XLab nicht ausdrücklich trifft: Der Installer zielt damit auf die Standard-Builds, die CWP vor Version 1.29 ausgeliefert hat. Die Versionsnummer trennt deshalb nicht zwischen betroffen und nicht betroffen: Eine ersetzte und eine unveränderte Binary können dieselbe Versionsangabe tragen. Entscheidend ist, ob die Binary auf dem Server durch den Hintertür-Build ersetzt wurde.

Ob es weitere Hintertür-Builds für andere cwpsrv-Versionen gibt, ist offen. XLab hat zwei Samples erfasst.

Aktueller Stand von CWP ist laut Changelog die Version 1.30.5 vom 8. November 2026. Die Version 1.30.1 vom 3. November 2026 ist als "security and stability update of the LTS version" ausgewiesen, 1.30.2 am selben Tag als Sicherheitsupdate. CWPdoor erwähnt der Changelog nicht. Ein Update ist damit sinnvoll, aber kein Nachweis, dass ein Server sauber ist.

Was noch unbekannt ist

Ein Hinweis auf reale Fälle ist der VirusTotal-Upload. Laut XLab wurde am 30. September 2026 aus Brasilien eine Datei evidencia.tgz hochgeladen. Sie enthielt libkeyutils.so.1.5.2, das die meisten Hersteller als Ebury-Hintertür erkennen, und cwpsrv.suspeito, die CWPdoor-Binary, für die XLab null Erkennungen berichtet. Ein einzelner Upload belegt weder Anzahl noch Umfang der Fälle. Ebury ist laut BleepingComputer seit mindestens 2009 aktiv; ESET hat die Familie im Mai 2024 dokumentiert.

Zur Zahl 340.000: XLab zählt über die Hunter-Plattform von QiAnXin mehr als 340.000 im Internet erreichbare CWP-Instanzen im Monat vor dem Bericht vom 5. November 2026. Das ist die Menge möglicher Ziele, keine Zahl bestätigter Infektionen.

Indikatoren im Überblick

Quelle: XLab-Bericht einschließlich IOC-Liste. XLab veröffentlicht nur MD5-Werte. Die IP-Adresse ist ein Indikator für ausgehenden Verkehr, nicht für die Angreifer selbst. Sie kann wechseln oder abgeschaltet werden.

Server prüfen: Befehle für Admins

Alle Befehle laufen lokal. Root oder sudo ist nötig, um Prozesse und Sockets anderer Benutzer vollständig ihren Programmen zuzuordnen (je nach /proc-Einstellung hidepid sind fremde Prozesse auch ohne Root sichtbar); Namespace-Grenzen und manipulierte Systemwerkzeuge können die Sicht trotzdem einschränken. Datei-Prüfungen wie strings und sha256sum gehen mit Leserechten auf die Binary. Die Befehle sind auf lesende Prüfung ausgelegt und nehmen keine Reparatur- oder Konfigurationsänderungen vor, hinterlassen aber Spuren: Lesezugriffe können atime verändern, sudo wird je nach Konfiguration protokolliert, und rpm -V kann Verifikationsskripte des Pakets ausführen; deshalb enthalten die rpm-Befehle unten --noscripts. Bei Verdacht Ausgaben vor dem Eingreifen sichern (siehe nächster Abschnitt).

1. Socket des Helpers. Das ist der Hauptindikator von XLab.

sudo ss -axp | grep -i integrity

Auf einem sauberen System erscheint nichts, was ngx_http_integrity_helper heißt. Ein Treffer mit diesem Namen ist ein starker Indikator für eine aktive CWPdoor. Der Name ist frei wählbar, deshalb gehören Prozess und ausführbare Datei (Schritte 2, 3 und 5) zur Bestätigung. Der Filter integrity ist bewusst weit gefasst; als Indikator zählt der vollständige Name.

2. cwpsrv-Prozesse. XLab nennt verdächtige Helper-Kindprozesse von cwpsrv als Indikator.

ps -eo pid,ppid,user,lstart,args | grep '[c]wpsrv'

Wie der Prozessbaum einer sauberen Installation genau aussieht, dokumentiert XLab nicht. Ein Vergleich mit einem unverdächtigen Server derselben Version hilft.

3. Strings in der Binary.

strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity

# ohne binutils:
grep -a -o 'X-Ngx-Integrity-[A-Za-z]*' /usr/local/cwpsrv/bin/cwpsrv | sort -u

Ein sauberer cwpsrv liefert keine Ausgabe. Drei Treffer (-Time, -Data, -Sig) sind ein starker Hinweis auf den Hintertür-Build. Ein String-Fund allein zeigt nicht, dass der Code ausgeführt wird; er rechtfertigt die Untersuchung mit den übrigen Schritten.

4. Hash der Binary.

md5sum /usr/local/cwpsrv/bin/cwpsrv
sha256sum /usr/local/cwpsrv/bin/cwpsrv

# Abgleich mit den XLab-Werten:
md5sum /usr/local/cwpsrv/bin/cwpsrv | grep -E '965aea67fb40de1bab5169ada993349f|d3f4e95113d49ab3991b45e457bda75b'

Ein Treffer entspricht einem der von XLab veröffentlichten Sample-Hashes und ist ein sehr starker Hinweis, vorausgesetzt Host und Prüfwerkzeuge sind nicht selbst manipuliert. Ein fehlender Treffer beweist nichts: Angreifer können einen anderen Build verwenden, der einen anderen Hash ergibt. Den SHA-256-Wert für die Dokumentation und als Baseline notieren.

5. Die tatsächlich laufende Binary. Der Pfad /usr/local/cwpsrv/bin/cwpsrv stammt aus dem XLab-Bericht. Welche Datei der Prozess wirklich ausführt, zeigt /proc, unabhängig vom Verzeichnisnamen. Die Schleife erfasst alle Prozesse mit dem exakten Namen cwpsrv; trägt ein Prozess einen anderen Namen, die PID aus Schritt 2 verwenden:

for pid in $(pgrep -x cwpsrv); do
  sudo ls -l /proc/$pid/exe
  sudo sha256sum /proc/$pid/exe
done

Der Zusatz (deleted) hinter dem Pfad bedeutet zunächst nur, dass der Pfadname der laufenden Datei entfernt wurde (unlink; proc_pid_exe(5)). Ob eine Ersatzdatei am selben Pfad liegt, zeigt der Vergleich der Hashes von Pfad und laufender Datei. Ein Austausch bei laufendem Prozess, etwa ein Update ohne Dienstneustart, ist eine mögliche Ursache, aber nicht die einzige.

6. Zeitstempel (Hinweis, kein Beweis). XLab beschreibt das Zurücksetzen von mtime und atime; ctime erwähnt der Bericht nicht. Beim Zurücksetzen über utimensat(2) wird ctime auf den aktuellen Zeitpunkt gesetzt (man-Seite); die Systemschnittstelle erlaubt es nicht, ctime auf einen frei gewählten Wert zu setzen. Ein Angreifer mit Root kann sie dennoch verfälschen, etwa über die Systemuhr oder durch direkte Eingriffe ins Dateisystem.

stat -c '%n | mtime %y | ctime %z' /usr/local/cwpsrv/bin/cwpsrv /usr/local/cwpsrv/bin

Liegt ctime deutlich nach mtime, wurde nach der letzten Inhaltsänderung der Inode verändert. Das kann ein zurückgesetzter mtime sein, aber auch eine reine Metadatenänderung: Eigentümer-, Modus- oder Link-Änderungen aktualisieren ctime, ohne dass sich der Inhalt ändert (inode(7)). Das ist eine eigene Ableitung, kein XLab-Indikator. Auch eine Wiederherstellung aus einem Backup mit erhaltenen Zeitstempeln erzeugt dasselbe Muster. Als Anlass zur genaueren Prüfung taugt der Befund, als Urteil nicht.

7. Backup des Installers.

ls -la /usr/local/cwpsrv/bin/
find /usr/local/cwpsrv/bin -name 'cwpsrv.prev-*'

Der Installer löscht das Backup laut XLab bei Erfolg. Ein Fund passt nicht zum beschriebenen Erfolgsablauf und verdient einen genaueren Blick; ein leeres Ergebnis sagt nichts.

8. Spuren im Netz. Der Installer lädt von 136.0.141.71 und meldet dorthin zurück.

grep -rIF '136.0.141.71' /var/log 2>/dev/null
sudo ss -tnp | grep -F 136.0.141.71

Firewall- und Flow-Protokolle des Netzes sind belastbarer als Logs auf dem Server, sofern sie unabhängig vom Server erfasst und geschützt werden: Ein Angreifer mit Root kann lokale Einträge löschen. DNS-Protokolle erfassen direkte Verbindungen zu einer IP-Adresse nicht. Die Adresse in diesen Protokollen über den gesamten verfügbaren Zeitraum suchen.

9. Paketprüfung, falls anwendbar. Ob cwpsrv als RPM-Paket installiert wird, dokumentieren die ausgewerteten Quellen nicht. Die Abfrage zeigt, ob ein Paket die Datei besitzt:

rpm -qf /usr/local/cwpsrv/bin/cwpsrv

Antwortet rpm mit "is not owned by any package", entfällt der Vergleich mit der lokalen Paketdatenbank; ein Vergleich mit einer extern bezogenen, vertrauenswürdigen Kopie der Binary bleibt möglich. Gehört die Datei einem Paket, prüft rpm -V --noscripts <Paketname> Größe, Hash und weitere Attribute gegen die RPM-Datenbank (RPM-Handbuch). Wer Root hatte, konnte auch diese Datenbank verändern; der Befund ist ein zusätzlicher Hinweis, kein Ersatz für den Neuaufbau.

10. Bibliothek aus dem Ebury-Fund. XLab fand im selben Archiv eine manipulierte libkeyutils. Auf RPM-Systemen vergleicht die Paketprüfung die Bibliothek mit dem Paket:

ls -l /usr/lib64/libkeyutils*
rpm -V --noscripts keyutils-libs

Keine Ausgabe von rpm -V --noscripts bedeutet: keine Abweichung der geprüften Dateien und Attribute gegenüber der lokalen RPM-Datenbank. Eine Ausgabe ist zu bewerten: Eine Digest-Abweichung (5 in der Zeile, nicht zwingend MD5) bei libkeyutils ist ein ernster Befund und gehört in die Incident-Prüfung, abweichende Zeit, Eigentümer oder Rechte können auch legitime Ursachen haben.

Was eine saubere Prüfung nicht beweist

Die Prüfungen decken nur bekannte Indikatoren ab; XLab veröffentlicht Indikatoren für die zwei erfassten Samples. Ein leeres Ergebnis schließt andere Varianten nicht aus. Das ist unsere Einordnung, keine Aussage von XLab. Für den Schluss "sauber" fehlen mehrere Dinge:

• Zeitpunkt. Wann ein Server infiziert wurde, lässt sich aus diesen Prüfungen nicht ablesen; forensische Analyse kann Hinweise liefern. Frühester dokumentierter Zeitpunkt ist der Installer vom 29. Juni 2026; ältere Aktivität ist nicht ausgeschlossen.
• Andere Implantate. Wer Root hatte, kann weitere Zugänge angelegt haben: SSH-Schlüssel, Benutzer, Cron-Jobs, Systemd-Units, manipulierte Bibliotheken. CWPdoor ist nur der Teil, den XLab kennt.
• Virenscanner. XLab berichtet für das Sample aus der VirusTotal-Einreichung vom 30. September 2026 null Erkennungen. Ein negatives Scanergebnis ist ohnehin kein Unbedenklichkeitsnachweis; signaturbasierte Scanner liefern hier keine Entwarnung.
• Logs. Die auslösende Anfrage steht nicht im Access-Log, und der Installer versucht, den Befehlsverlauf seiner Sitzung zu bereinigen.

Sinnvoll ist daher die Kombination aus den Prüfungen oben, einem Blick auf ausgehenden Verkehr über einen längeren Zeitraum und einer Bewertung, ob Root-Zugriff durch Dritte zuvor möglich war: ungepatchte Panel-Version, geteilte oder schwache Zugangsdaten, öffentlich erreichbare Management-Ports.

Bei einem Treffer: so gehen Sie vor

XLab empfiehlt bei bestätigtem Befall drei Schritte: die Original-Binary wiederherstellen, auf die neueste Version aktualisieren und prüfen, dass der Socket-Check leer bleibt, sowie alle Zugangsdaten des Panels sofort rotieren und den Host als kompromittiert behandeln. Die Anleitung unten geht weiter, weil der Binary-Tausch allein keine Aussage über den Rest des Systems erlaubt.

1. Beweise sichern, bevor etwas verändert wird. Snapshot oder Abbild des Systems anlegen, Kopie der Binary mit Hash ablegen, Ausgaben von ss -axp, ps und ss -tnp sowie die Logs sichern. Beweissichere Forensik ist eine eigene Disziplin; die Schritte hier erhalten die Ausgangslage dafür.
2. Erreichbarkeit einschränken. Die Ports, an denen cwpsrv lauscht, sofort für fremde Netze sperren. Welche das sind, zeigt sudo ss -tlnp | grep cwpsrv. Kunden-Websites laufen üblicherweise über getrennte Webserver-Dienste weiter; ob das auf dem konkreten Server zutrifft, hängt von der Proxy- und Weiterleitungs-Konfiguration ab und ist vorher zu klären. Panel, User-Panel und Webmail laufen laut CWP-Changelog über cwpsrv-Ports und sind über die gesperrten Pfade danach nicht mehr erreichbar.
3. Das Installer-Backup ist kein verlässlicher Ausweg. XLab empfiehlt, die vom Installer angelegte Sicherung cwpsrv.prev-<Zeitstempel> zurückzuspielen; sie enthält die ursprüngliche Binary. Der Installer löscht diese Sicherung aber bei Erfolg. Fehlt sie, bleibt nur eine saubere Binary aus einer vertrauenswürdigen Quelle, am besten durch eine Neuinstallation von CWP. Am Root-Zugriff, den Angreifer vorher gehabt haben können, ändert auch das nichts.
4. Zugangsdaten rotieren. Als vorsorgliche Incident-Annahme gelten alle Geheimnisse, die auf dem Server lagen oder über ihn erreichbar waren, als kompromittiert (XLab nennt die Panel-Zugangsdaten): Panel-Admin und Root, SSH-Schlüssel, Datenbank-Passwörter (auch in Anwendungskonfigurationen wie wp-config.php), Passwörter der Hosting-Accounts und Mailkonten, API-Token für DNS und Provider, TLS-Schlüssel. Rotation von einem sauberen Rechner aus; Reihenfolge und Zeitpunkt richten sich nach der Eindämmung, denn solange der Zugriff der Angreifer besteht, kann er neue Werte mitlesen.
5. Neu aufbauen. Ein frisches Betriebssystem-Image, CWP in der aktuellen Version neu installieren, danach Daten wiederherstellen. Wiederhergestellt werden Websites, Datenbanken und Mail, nicht Binaries oder Konfigurationen des alten Systems. Wiederhergestellte Daten auf Webshells und fremde Cron-Einträge prüfen. Das ist die WZ-IT-Einordnung: Nach einer Root-Übernahme lässt sich die Integrität des Systems mit Bordmitteln des Hosts nicht belastbar belegen; ein Vergleich mit vertrauenswürdigen externen Baselines oder Images wäre möglich, der Neuaufbau ist der verlässlichere Weg. XLab formuliert es vorsichtiger mit der Empfehlung, den Host als kompromittiert zu behandeln.
6. Meldepflichten prüfen. Liegen auf dem Server personenbezogene Daten, kann eine Verletzung des Schutzes personenbezogener Daten vorliegen; die bloße Speicherung löst noch keine Meldung aus. Dann gilt Art. 33 DSGVO: Der Verantwortliche meldet die Verletzung der Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, außer sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Ein Auftragsverarbeiter (etwa ein Hoster, der Server für Kunden betreibt) informiert den Verantwortlichen unverzüglich (Art. 33 Abs. 2). Bei voraussichtlich hohem Risiko sind nach Art. 34 DSGVO auch die Betroffenen unverzüglich zu benachrichtigen; Art. 34 Abs. 3 nennt Ausnahmen mit engen Voraussetzungen: Verschlüsselung nur, wenn die Daten dadurch für Unbefugte unzugänglich sind (bei einer Root-Übernahme mit erreichbaren Schlüsseln ist das fraglich), nachträgliche Maßnahmen nur, wenn das hohe Risiko voraussichtlich nicht mehr besteht, und bei unverhältnismäßigem Aufwand eine öffentliche oder ähnlich wirksame Information statt der Einzelbenachrichtigung. Jede Verletzung ist nach Art. 33 Abs. 5 zu dokumentieren, auch wenn keine Meldung erfolgt. Die Bewertung hängt vom Einzelfall ab.
7. Angrenzende Systeme prüfen. Wurden die Zugangsdaten auch anderswo verwendet, gehören die anderen Systeme in die Prüfung: weitere Server, Provider-Konsole, DNS-Verwaltung, Passwortmanager.

Absicherung für CWP-Server

Die folgenden Maßnahmen gelten unabhängig vom Prüfergebnis. Sie verkleinern die Angriffsfläche und erleichtern es, eine Manipulation zu bemerken. Eine Garantie, Angriffe zu verhindern oder zu erkennen, bieten sie nicht, insbesondere nicht gegenüber einem Angreifer mit Root-Rechten.

Beispiel für eine Überwachungsregel mit auditd: Schreib- und Attributänderungen im Verzeichnis der Binary landen im Audit-Log, sofern die Regel geladen ist und wirkt: auditd muss laufen und das Auditing aktiv sein, ausschließende Regeln oder verworfene Ereignisse können Einträge verhindern. Die -w-Form ist in auditctl(8) als veraltet gekennzeichnet (Leistung); die Man-Page empfiehlt Regeln auf Systemaufruf-Basis (-a always,exit mit Filtern).

sudo auditctl -w /usr/local/cwpsrv/bin/ -p wa -k cwpsrv-bin
sudo ausearch -k cwpsrv-bin

Eine mit auditctl gesetzte Regel gilt nur zur Laufzeit und kann entfernt werden, sofern die Audit-Konfiguration nicht gesperrt ist (-e 2). Für eine dauerhafte Regel gehört sie in eine Datei mit der Endung .rules unter /etc/audit/rules.d/; andere Dateien dort werden ignoriert. augenrules --load führt die Dateien zu /etc/audit/audit.rules zusammen und lädt sie in den Kernel (augenrules(8)). Zur Einordnung der Maßnahmen und weiteren Härtung des Systems dient die Härtungs-Checkliste für Linux-Server.

Ein reiner Abgleich mit CVE-Nummern erfasst CWPdoor nicht, weil in den ausgewerteten Quellen keine CVE-Nummer genannt ist. Für solche Fälle helfen Berichte der Forscher und Hersteller, Integritätsprüfungen und regelmäßige Sichtung der Indikatoren.

Hosting-Panels als Angriffsziel

Hosting-Panels haben Eigenschaften, die sie für Angreifer attraktiv machen können: Ein Dienst läuft in der Regel mit weitreichenden Rechten, ist oft aus dem Internet erreichbar und verwaltet viele Kundenaccounts gleichzeitig. Die Beispiele zeigen wiederholte Angriffe auf Hosting-Panels in den letzten Jahren:

Quellen: Facefish nach dem Bericht von Juniper Threat Labs (Bericht vom 26.04.2021, die verlinkte HPE-Seite wurde migriert und zeigt inzwischen ein anderes Datum; erster beobachteter Angriff am 1. Februar 2021), dem Bericht von Netlab (27.05.2021) und The Record (28.05.2021); keiner nennt eine CVE-Nummer für die genutzte Lücke. Katalogdaten nach den NVD-Einträgen. XLab verknüpft keine der CWP-Lücken mit CWPdoor; die Spalte zeigt nur, dass CWP bereits früher aktiv angegriffen wurde.

Die Frage dahinter, wie sich ein Panel-Daemon mit Root-Rechten auf öffentlichen Ports sicher betreiben lässt, behandelt der Beitrag zum cPanel-Massenhack ausführlich. Im Fall CWPdoor kommt ein zweiter Punkt hinzu: Selbst ein vollständig gepatchtes Panel schützt nicht vor einem Angreifer, der Root bereits hat. Aus Sicht von WZ-IT gehören Zugänge, Erreichbarkeit der Management-Ports und Integritätsüberwachung deshalb zum Betrieb eines Panels wie das Patchen.

Unser Vorgehen bei WZ-IT

Bei einem Hinweis wie CWPdoor läuft die Arbeit in fünf Schritten:

1. Betroffenheit feststellen. Betriebssystem, CWP-Version und Erreichbarkeit der Panel-Ports erfassen und die Prüfbefehle oben ausführen.
2. Eingrenzen. Bei einem Treffer oder Verdacht die Management-Ports sperren und die Ausgangslage sichern, bevor etwas verändert wird. Ein Verdacht auf einen Sicherheitsvorfall ist nicht Bestandteil des planbaren Basis-Audits. Wir prüfen die Anfrage separat und stimmen Vorgehen, Verfügbarkeit und Kosten vorab ab.
3. Zugangsdaten rotieren und neu aufbauen. Rotation in sauberer Reihenfolge, Neuaufbau auf einem frischen System, Daten wiederherstellen und prüfen. Wiederherstellungen produktiver Daten erfolgen nur mit ausdrücklicher Freigabe oder nach vereinbartem Runbook.
4. Absichern. Management-Ports begrenzen, Updates und Integritätsüberwachung einrichten, Zugänge härten.
5. Dauerhaft betreiben. Das System in Monitoring, Updates und CVE-Monitoring aufnehmen.

Das Server-Audit erfasst den Zustand einer Standard-Linux-Instanz einmalig ab 290 € netto: erreichbare Ports und nicht benötigte Dienste, Patchstand und bekannte Schwachstellen, SSH-, Root- und sudo-Konfiguration, Firewall-Regeln und Hinweise auf verbreitete Kompromittierungen. Penetrationstest und beweissichere IT-Forensik gehören nicht zum Basis-Audit.

Die laufende Server-Betreuung beginnt bei 149,90 € netto pro Monat für den ersten Server und umfasst 24/7-Monitoring, Updates in vereinbarten Wartungsintervallen, CVE-Monitoring auf Betriebssystemebene, Baseline-Hardening, Backup-Management und zentrale Log-Sammlung. Debian, Ubuntu und RHEL-Derivate wie AlmaLinux und Rocky Linux gehören zum Tagesgeschäft. Welche Anwendungen wie ein Hosting-Panel im Einzelnen zum Umfang zählen, wird vor dem Betriebsstart festgelegt. Die Betreuung erfolgt remote und weltweit; die Server bleiben beim Provider und im Vertrag des Kunden. Das CVE-Monitoring wertet Hersteller-Advisories und Distributions-Tracker aus.

Weiterführende Guides

• cPanel CVE-2026-41940: Massenhack bei Shared-Hosting, warum Hosting-Panels ein strukturelles Risiko sind und welche Alternativen es gibt.
• CVE-Monitoring für Self-Hosted Software, wie Schwachstellen strukturiert verfolgt werden und wo CVE-Feeds enden.
• Linux-Server härten: Checkliste mit CIS und BSI, SSH, Firewall, Konten und Protokollierung mit Prüfbefehlen.
• Linux-Patch-Management: Prozess, Fristen und Nachweis, Patch-Zyklen und Nachweise für den Betrieb.
• Linux End of Life: Supportende von Debian, Ubuntu und CentOS, Supportdaten für Betriebssysteme wie CentOS 7.
• Linux-Kernel-Schwachstellen 2026, Patch-Management als Aufgabe der Leitung.
• Managed Operations, der Hub mit allen Angeboten zu Betrieb, Monitoring und CVE-Monitoring.
• SSHole (CVE-2026-123158): OpenSSH bei Alpine prüfen - weiterer aktueller Sicherheitsfall (Stand November 2026)
• Kernel-TCP-Lücke CVE-2026-98432: Proxmox, Debian, Ubuntu patchen - weiterer aktueller Sicherheitsfall (Stand November 2026)
• APT-Lücke CVE-2026-109518 in Debian und Ubuntu - weiterer aktueller Sicherheitsfall (Stand November 2026)
• Node-RED-Editor ohne adminAuth: CVE-2026-58115 (Siemens IoT2050) - weiterer aktueller Sicherheitsfall (Stand November 2026)

CWP-Server auf CWPdoor prüfen lassen? Wir erfassen Ports, Patchstand und Zugänge im Server-Audit, ordnen Treffer und Verdachtsfälle ein und übernehmen auf Wunsch den laufenden Betrieb. Termin vereinbaren

Quellen

• XLab (QiAnXin), CWPdoor: The Invisible Backdoor Living Inside Control Web Panel
• BleepingComputer, Hackers backdoor Linux servers using trojanized CWP web server
• The Hacker News, Hackers Hide Linux Backdoor in Control Web Panel Server
• eSecurityPlanet, CWPdoor Malware Detection and Removal
• webhosting.today, cwpdoor replaces Control Web Panel's web server
• Control Web Panel, Changelog
• Control Web Panel, Features
• NVD, CVE-2022-44877
• NVD, CVE-2025-48703
• NVD, CVE-2026-41940
• The Record, Malware campaign targets server hosting software CWP (Facefish, 2021)
• Juniper Threat Labs, Linux Servers Hijacked to Implant SSH Backdoor (Facefish, 2021)
• Netlab 360, Facefish (2021)
• ESET, Ebury is alive but unseen
• GNU Bash Reference Manual, Bash History Builtins
• Linux man-pages, inode(7)
• Linux man-pages, utimensat(2)
• Linux man-pages, proc_pid_exe(5)
• RPM, rpm(8)
• Linux man-pages, auditctl(8)
• Linux man-pages, augenrules(8)
• DSGVO, Verordnung (EU) 2016/679, Art. 33 und 34