Die stille Tür im Linux-Server: Was BPFDoor über unsere Telekommunikationsnetze verrät

Ein Linux-Server kann nach außen vollkommen ruhig wirken. Kein ungewöhnlicher Port steht offen, kein verdächtiger Dienst meldet sich regelmäßig bei einem Kontrollserver, und ein gewöhnlicher Portscan findet nichts. Trotzdem kann im System eine Hintertür warten. Nicht auf eine normale Anmeldung, sondern auf ein präpariertes Netzwerkpaket.

Genau dieses Prinzip nutzt BPFDoor. Die Backdoor ist kein theoretisches Laborstück und auch keine neue Windows-Schadsoftware mit Linux-Anstrich. Sie wurde für langfristige Zugriffe auf Linux-Systeme entwickelt und mit Spionagekampagnen gegen Telekommunikations- und Regierungsnetze verbunden. Rapid7 berichtete 2026 nach einer mehrmonatigen Untersuchung über eine fortdauernde, China-nahe Kampagne in Telekommunikationsumgebungen. Fraunhofer FKIE führt die Malwarefamilie in Malpedia, MITRE ordnet ihre Techniken im ATT&CK-Katalog ein.

Der Fall ist technisch interessant. Politisch ist er noch wichtiger. Berlin diskutiert gleichzeitig neue offensive Befugnisse für Nachrichtendienste, einschließlich Eingriffen in fremde IT-Systeme und des Umgangs mit unbekannten Schwachstellen. Brüssel verpflichtet Betreiber und Hersteller mit NIS2 und Cyber Resilience Act zu mehr Sicherheitsmanagement. Die eine politische Hand verlangt also bessere Verteidigung. Die andere will sich offensive Zugriffsmöglichkeiten erhalten.

Die entscheidende Frage lautet deshalb nicht nur, wie BPFDoor funktioniert. Sie lautet: Wie glaubwürdig ist staatliche Cybersicherheit, wenn derselbe Staat ein Interesse daran haben kann, Schwachstellen nicht sofort zu schließen?

BPF ist keine Firewall

Der Name BPFDoor verweist auf den Berkeley Packet Filter. BPF ist keine eigenständige Linux-Firewall. Es ist eine Filter- und Ausführungsmechanik, mit der Netzwerkpakete früh und effizient ausgewählt werden können. Werkzeuge wie tcpdump und Bibliotheken wie libpcap nutzen diese Technik, damit nicht jedes Paket vollständig in den Userspace kopiert und dort ausgewertet werden muss.

BPFDoor missbraucht diese legitime Fähigkeit. Die Malware bindet einen Filter an einen Raw Socket und prüft eintreffende TCP-, UDP- oder ICMP-Pakete auf bestimmte Aktivierungsdaten. Normale Pakete werden ignoriert. Ein passendes „Magic Packet“ löst dagegen die nächste Stufe aus. Je nach Variante startet die Malware eine Bind- oder Reverse-Shell und verschafft dem Angreifer eine Kommandozeile auf dem kompromittierten System.

Das ist der eigentliche Tarnvorteil: Die Backdoor braucht keinen dauerhaft sichtbaren Listening-Port und kein regelmäßiges Beaconing. Sie muss nicht alle paar Minuten nach Hause telefonieren. Sie wartet passiv im vorhandenen Verkehr.

Unsichtbar ist sie deshalb nicht. Sie hinterlässt Prozesse, Speicherzustände, Socket-Aktivität, geladene Filter, veränderte Firewallregeln oder Laufzeitdateien. Bekannte Varianten manipulieren Prozessnamen, löschen die abgelegte Binärdatei nach dem Start, verändern Zeitstempel und leiten Shell-Historien nach /dev/null. MITRE dokumentiert außerdem Varianten, die hohe TCP-Ports verwenden und iptables-Regeln zur Weiterleitung von Paketen einrichten.

Wer nur nach offenen Standardports sucht, kann BPFDoor übersehen. Wer Host, Speicher, Raw Sockets, BPF-Nutzung, Prozessbaum und ausgehenden Verkehr gemeinsam überwacht, ist nicht hilflos.

Ein Magic Packet ist kein universeller Generalschlüssel

In populären Erklärvideos wird gern eine feste Bytefolge gezeigt, die angeblich „die“ Backdoor aktiviert. Das ist anschaulich, aber gefährlich verkürzt. BPFDoor existiert in mehreren Varianten. Protokolle, Magic Values, Passwörter, Shell-Verhalten und Verschleierung können sich unterscheiden. Der 2022 öffentlich gewordene Quellcode erleichterte es weiteren Akteuren, Varianten abzuleiten.

Eine einzelne Signatur kann deshalb einen bekannten Stand erkennen, aber keine ganze Malwarefamilie abschließend ausschließen. Gute Erkennung kombiniert mehrere Ebenen:

  • bekannte Hashes und YARA-Regeln für Dateien und Speicher;
  • auffällige Raw Sockets und BPF-Filter;
  • unerwartete Prozesse mit Namen legitimer Systemdienste;
  • ungewöhnliche Runtime- oder Lock-Dateien;
  • neue oder unerklärliche iptables– beziehungsweise nftables-Regeln;
  • Shell-Verbindungen auf hohen Ports;
  • ausgehende Verbindungen, die nicht zum Zweck des Servers passen;
  • Unterschiede zwischen sauberer Referenzinstallation und produktivem Zustand.

Für einen kleinen selbstgehosteten Matrix- oder Nextcloud-Server bedeutet das nicht, jede Nacht eine Geheimdienstoperation zu vermuten. Es bedeutet, Monitoring nicht auf CPU, RAM und „Port 443 antwortet“ zu reduzieren. Ein System kann verfügbar und trotzdem kompromittiert sein.

Warum Telekommunikationsnetze so wertvoll sind

Telekommunikationsnetze verbinden Identität, Standort und Kommunikation. Im Kern liegen Systeme für Teilnehmerverwaltung, Authentifizierung, Roaming, Abrechnung und Signalisierung. Protokolle wie SS7, Diameter und SCTP transportieren Informationen darüber, welcher Teilnehmer sich wo befindet, wie Verbindungen geroutet und wie fremde Netze einbezogen werden.

Wer sich langfristig in einer solchen Umgebung positioniert, erhält nicht automatisch Zugriff auf jedes Gespräch. Er kann aber Kommunikationsmetadaten, Teilnehmerkennungen, Bewegungsereignisse, Authentifizierungsvorgänge und interne Vertrauensbeziehungen ausspähen. Außerdem kann ein kompromittierter Randserver als Sprungbrett in tiefer liegende Netzsegmente dienen.

Rapid7 beschreibt keinen einzelnen spektakulären Einbruch, sondern ein Kampagnenmodell: erste Zugriffe über exponierte VPNs, Firewalls, Router oder Webanwendungen; danach Zugangsdaten sammeln, seitlich weiterbewegen und langfristige Implantate platzieren. Genannt werden unter anderem missbrauchte Konten und Schwachstellen in öffentlich erreichbaren Systemen.

Das ist keine Besonderheit „des unsicheren Linux“. Linux dominiert viele Server- und Infrastruktursegmente gerade wegen seiner Offenheit, Anpassbarkeit und Stabilität. Diese Stärke schützt aber nicht vor schlechten Zugangsdaten, ungepatchten Appliances, mangelhafter Segmentierung oder fehlender Telemetrie. Open Source ermöglicht Prüfung. Sie ersetzt die Prüfung nicht.

China-Zuschreibung: ernst nehmen, aber sauber formulieren

Malpedia verbindet BPFDoor mit dem Akteur Red Menshen. Rapid7 spricht von einem China-nahen Bedrohungsakteur. Das ist eine fachliche Attribution aus Infrastruktur, Werkzeugen, Vorgehensweisen, Zielauswahl und anderen nachrichtendienstlichen Indikatoren.

Eine solche Zuschreibung kann belastbar sein, bleibt aber etwas anderes als ein öffentlich vollständig beweisbares Strafverfahren. Deshalb ist „China hat alle Netze übernommen“ keine seriöse Schlussfolgerung. Belegt sind Kampagnen und technische Indikatoren. Nicht belegt ist, dass praktisch jedes internationale Telekommunikationsnetz infiziert oder grundsätzlich nicht mehr bereinigbar wäre.

Gerade bei staatlicher Spionage ist Präzision kein Weichspüler. Sie verhindert, dass politische Kritik durch Übertreibung angreifbar wird.

Berlin: Der Staat als Verteidiger und Angreifer

Darknight-Coffee hat die geplante Reform des Nachrichtendienstrechts bereits ausführlich analysiert. Der veröffentlichte Beitrag „Der Geheimdienst als Hacker“ behandelt vorgesehene Eingriffe in fremde Systeme, automatisierte Maßnahmen, Attribution und den Umgang mit Zero-Day-Schwachstellen.

BPFDoor liefert dazu den technischen Realitätscheck. Eine Backdoor dieser Klasse lebt davon, dass Angreifer zuerst einen Zugang finden und anschließend unauffällige Persistenz aufbauen. Jede nicht geschlossene Schwachstelle in VPNs, Firewalls, Routern oder Serverdiensten kann Teil dieser Angriffskette werden.

Wenn staatliche Stellen unbekannte Schwachstellen für eigene Zugriffe zurückhalten, bleiben dieselben Lücken auch für fremde Dienste und kriminelle Gruppen offen. Der Staat kann eine Zero-Day-Lücke nicht exklusiv besitzen. Er kann nur hoffen, dass niemand anderes sie findet oder kauft.

Darum braucht Deutschland ein verbindliches und kontrollierbares Schwachstellenmanagement: Offenlegung und Schließen als Regelfall, eng begrenzte Ausnahmen, unabhängige Risikoprüfung, kurze Neubewertungsfristen und nachvollziehbare Verantwortung. Ohne diesen Vorrang wird der Satz „Wir stärken die Cybersicherheit“ politisch hohl.

Brüssel: NIS2 und CRA reichen allein nicht

NIS2 verlangt von wesentlichen und wichtigen Einrichtungen ein systematisches Risikomanagement und Meldeprozesse für erhebliche Sicherheitsvorfälle. Telekommunikation gehört zum Kernbereich kritischer digitaler Infrastruktur. Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen schrittweise zu Sicherheitsanforderungen, Schwachstellenmanagement und Meldungen aktiv ausgenutzter Lücken.

Beide Regelwerke setzen richtige Punkte. Betreiber müssen Risiken beherrschen; Hersteller dürfen Sicherheit nicht nach dem Verkauf einstellen. Doch Regulierung kann zur Papiermaschine verkommen. Eine gepflegte Richtlinie, ein ausgefülltes Auditformular und eine fristgerechte Meldung entdecken keinen passiven Implantatprozess im Arbeitsspeicher.

Entscheidend ist die technische Umsetzung:

  • belastbare Inventare aller Systeme und Abhängigkeiten;
  • schnelle Patch- und Notfallwege;
  • Segmentierung zwischen Rand-, Management- und Kernsystemen;
  • minimal notwendige Rechte und rotierende Zugangsdaten;
  • zentrale, manipulationsgeschützte Logs;
  • Egress-Filter und nachvollziehbare Netzwerkflüsse;
  • Host- und Speicherforensik für Linux;
  • regelmäßige Wiederherstellungs- und Neuaufbauproben;
  • unabhängige Red-Team- und Incident-Response-Übungen.

Digitale Souveränität heißt hier nicht, jeden Server selbst zu betreiben. Sie heißt, Systeme, Schlüssel, Protokolle und Wiederherstellung so zu beherrschen, dass ein Betreiber nicht blind vom Hersteller, einem Cloudanbieter oder einer ausländischen Behörde abhängig bleibt.

Was Betreiber konkret tun können

Ein Verdacht auf BPFDoor ist kein Fall für hektisches Löschen einzelner Dateien. Das System muss isoliert werden, ohne forensische Spuren unnötig zu zerstören. Flüchtige Daten wie Prozesse, Netzwerkverbindungen, Raw Sockets, geladene Filter und Speicherinhalte sind besonders wichtig. Danach müssen Zugangsdaten und Schlüssel aus einer sauberen Umgebung rotiert, seitliche Bewegungen geprüft und betroffene Systeme kontrolliert neu aufgebaut werden.

Ein Backup ist dabei notwendig, aber kein Freispruch. Wer ein komplettes kompromittiertes Systemabbild blind zurückspielt, kann die Hintertür gleich mit restaurieren. Wiederhergestellt werden sollten geprüfte Daten in eine saubere, aktualisierte Umgebung. Konfigurationen gehören mit einer bekannten Referenz verglichen.

Für Community-Infrastruktur gilt derselbe Grundsatz im kleineren Maßstab. Nginx-Logs, Synapse-Tokens, Nextcloud-App-Passwörter und Backupschlüssel müssen getrennt gedacht werden. Ein kompromittierter Reverse Proxy darf nicht automatisch Zugriff auf jede Datenbank und jedes Sicherungsziel besitzen.

Fazit: Verteidigung beginnt mit politischer Ehrlichkeit

BPFDoor zeigt, wie leise ein langfristiger Zugriff auf Linux-Infrastruktur sein kann. Die Backdoor braucht keinen auffälligen offenen Port und kein regelmäßiges Lebenszeichen. Sie kann legitime Kernelmechanismen missbrauchen und sich hinter vertraut wirkenden Prozessnamen verbergen.

Das macht Verteidigung anspruchsvoll, aber nicht aussichtslos. Wer nur Verfügbarkeit überwacht, sieht zu wenig. Wer Host, Netzwerk, Identitäten, Segmentierung und Wiederherstellung gemeinsam prüft, kann solche Angriffe erkennen und eindämmen.

Politisch bleibt der Widerspruch: Berlin und Brüssel fordern zu Recht mehr Cybersicherheit. Gleichzeitig will Berlin Nachrichtendiensten offensive Cybermacht und Zugriff auf Schwachstellen ermöglichen. Beides passt nur zusammen, wenn das Schließen von Lücken nachweisbar Vorrang hat.

Ein Staat, der seine digitale Infrastruktur schützen will, darf Sicherheitslücken nicht wie geheime Dietriche sammeln. Denn jede Tür, die für den eigenen Dienst offenbleibt, steht möglicherweise längst auch für einen fremden offen.

Quellen

1. Rapid7 Labs, „BPFdoor in Telecom Networks: Sleeper Cells in the Backbone“: https://www.rapid7.com/blog/post/tr-bpfdoor-telecom-networks-sleeper-cells-threat-research-report/ 2. MITRE ATT&CK, BPFDoor S1161: https://attack.mitre.org/software/S1161/ 3. Fraunhofer FKIE Malpedia, elf.bpfdoor: https://malpedia.caad.fkie.fraunhofer.de/details/elf.bpfdoor 4. EU, NIS2-Richtlinie 2022/2555: https://eur-lex.europa.eu/eli/dir/2022/2555/oj 5. EU, Cyber Resilience Act 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/oj 6. Darknight-Coffee, „Der Geheimdienst als Hacker“: https://carrabelloy.darknight-coffee.org/blog/2026/07/26/der-geheimdienst-als-hacker-mehr-cybermacht-verlangt-staerkere-kontrolle/

CTA

Diskussion: https://treff.darknight-coffee.eu Podcast: https://podcast.darknight-coffee.org/@carrabelloy/episodes/die-stille-tur-im-linux-server-bpfdoor-und-der-politische-preis-offener-schwachstellen Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.