Linux-Server im Visier: PHP-Web-Shells nutzen Cookies als Stealth-Kanal

Web Shells gehören zu den klassischen Werkzeugen, mit denen Angreifer nach einem erfolgreichen Einbruch die Kontrolle über einen kompromittierten Server aufrechterhalten. Doch die Taktiken werden zunehmend raffinierter. Wie das Microsoft Defender Security Research Team aktuell aufzeigt, haben Bedrohungsakteure eine Methode perfektioniert, die herkömmliche Sicherheitsmechanismen fast blind macht: Die Steuerung von PHP-Web-Shells über HTTP-Cookies, kombiniert mit einer selbstheilenden Persistenz über Cron-Jobs.

Tarnung im Standard-Traffic: Der Cookie-Trick

Klassische Web Shells empfangen ihre Befehle oft über URL-Parameter (GET) oder versteckte Formulardaten (POST). Das ist aus Sicht eines Angreifers riskant, da diese Übertragungen in Server- und Firewall-Logs leicht aufzufallen sind oder von Web Application Firewalls (WAF) blockiert werden. Der neue Ansatz nutzt stattdessen HTTP-Cookies als Steuerungskanal.

In PHP stehen Cookies zur Laufzeit bequem über die Superglobale $_COOKIE zur Verfügung. Der Angreifer muss keine Daten parsen, sondern kann direkt auf die Werte zugreifen. Der entscheidende Vorteil: Cookies sind ein völlig normaler Bestandteil des HTTP-Traffics. Sie fließen unsichtbar mit jedem Request mit und lösen bei standardmäßigen Überwachungstools keine Alarme aus.

Noch gefährlicher ist das Verhalten der Schadcode-Logik selbst: Die Web Shell verhält sich während des normalen Anwendungsbetriebs völlig inert. Der schädliche Code wird erst dann aktiviert, wenn ein spezifischer, vom Angreifer gesetzter Cookie-Wert in der Anfrage erkannt wird. Das bedeutet, dass Sicherheitsadministratoren den Server scannen oder den Traffic analysieren können, ohne dass die Web Shell auch nur eine Aktion ausführt – sie bleibt im Tiefschlaf, bis der Meister ruft.

Drei Varianten der Ausführung

Microsoft hat identifiziert, dass Angreifer diese Cookie-gesteuerte Ausführung auf drei verschiedene Weisen implementieren:

1. Der Obfuskierte Loader: Ein PHP-Skript, das mehrere Schichten von Verschleierung und Laufzeitprüfungen durchläuft, bevor es strukturierte Cookie-Daten parst, um einen verschlüsselten sekundären Payload auszuführen.
2. Der Segmentierte Rekonstruktor: Ein Skript, das die Daten im Cookie in Segmente aufteilt, um daraus operative Funktionen (wie Datei-Handling oder Dekodierung) wiederherzustellen. Es schreibt bedingt einen sekundären Payload auf die Festplatte und führt diesen aus.
3. Der Single-Value-Trigger: Ein minimalistischer Ansatz, bei dem ein einzelner Cookie-Wert als reiner Auslöser dient, um beliebige Befehle anzunehmen oder Datei-Uploads zu ermöglichen.

Die Terminator-Strategie: Selbstheilung via Cron

Die reine Stealth-Fähigkeit reicht Angreifern jedoch nicht aus. Sie müssen sicherstellen, dass der Zugang auch dann bestehen bleibt, wenn ein Admin den Schadcode entdeckt und löscht. Hier kommt die Infrastruktur des Linux-Servers selbst ins Spiel.

In mindestens einem dokumentierten Fall verschafften sich die Angreifer initialen Zugriff entweder durch kompromittierte Zugangsdaten oder die Ausnutzung einer bekannten Sicherheitslücke. Anstatt jedoch die Web Shell direkt als dauerhafte Datei abzulegen, richteten sie einen Cron-Job ein – einen geplanten Task –, der in regelmäßigen Abständen eine Shell-Routine ausführt. Diese Routine lädt oder generiert den obfuskierten PHP-Loader neu.

Das Resultat ist eine „selbstheilende“ Architektur. Löscht ein Verteidiger die Web Shell im Rahmen von Bereinigungsmaßnahmen, erstellt der Cron-Job diese einfach beim nächsten Lauf neu. Die Trennung von Persistenz (Cron) und Ausführungssteuerung (Cookie) reduziert das operationelle Rauschen drastisch. Es gibt keine verdächtigen Prozesse, die ständig im Hintergrund laufen, und keine Einträge in den Anwendungslogs, die auf permanente Skript-Ausführung hindeuten.

Kritische Einordnung: Ein Blind Spot in der Verteidigung

Die Beobachtungen von Microsoft sind ein klassisches Beispiel für „Living off the Land“-Angriffe (LotL). Die Angreifer müssen keine Zero-Day-Exploits mit sich bringen oder komplexe C2-Infrastrukturen aufbauen. Sie nutzen das, was ohnehin vorhanden ist: den Webserver, legitime Cron-Dienste und das PHP-Runtime-Environment.

Aus Sicht der Verteidigung offenbart dieser Angriffsvektor eine gefährliche Lücke. Viele Logging- und Monitoring-Lösungen fokussieren sich stark auf den URI-Pfad und den POST-Body, da hier traditionell die Angriffe stattfinden. Cookies werden oft nur als Sitzungs-IDs oder Tracking-Token abgetan und nicht tiefgehend auf injizierte Befehle oder Base64-kodierte Payloads inspiziert. Wenn die Ausführung zudem erst beim Vorhandensein eines spezifischen Triggers startet, wird es für dynamische Analysesysteme (Sandboxes) extrem schwer, das bösartige Verhalten überhaupt zu provozieren.

Gegenmaßnahmen: Was Admins jetzt tun müssen

Um dieser Bedrohung zu begegnen, reicht es nicht mehr aus, nur auf Signaturen von bekannten Web Shells zu vertrauen. Microsoft empfiehlt einen mehrschichtigen Ansatz, der den Fokus auf Systemintegrität und Zugriffskontrolle legt:

• Härtung der Zugänge: Multi-Faktor-Authentifizierung (MFA) für SSH, Hosting-Kontrollpanels und administrative Interfaces zwingend aktivieren. Ungewöhnliche Login-Aktivitäten müssen überwacht werden.
• Restriktion von Interpretern: Die Ausführung von Shell-Interpretern (wie /bin/bash oder /bin/sh) durch den Webserver-Prozess sollte so weit wie möglich eingeschränkt werden.
• Cron-Audits: Cron-Jobs und geplante Tasks auf Webservern müssen regelmäßig und streng auditiert werden. Jeder unbekannte Task ist hochgradig verdächtig.
• Dateisystem-Monitoring: Das Erstellen von verdächtigen Dateien in Web-Verzeichnissen (besonders in beschreibbaren Ordnern wie /tmp oder Upload-Verzeichnissen) muss Alarme auslösen.
• Begrenzung von Panel-Fähigkeiten: Shell-Funktionen innerhalb von Hosting-Kontrollpanels (wie cPanel oder Plesk) sollten deaktiviert oder stark limitiert werden, da sie oft als Eintrittspunkt für die Cron-Manipulation dienen.

Fazit: Die Verschiebung der Steuerungslogik in HTTP-Cookies zeigt, wie Angreifer die blinde Flecken gängiger Sicherheitsarchitekturen ausnutzen. Verteidiger müssen ihre Überwachung anpassen und weg von rein signaturbasierten Ansätzen hin zu Verhaltensanalysen und strenger Systemhärtung denken.

Quelle: The Hacker News