Cookie-gesteuerte PHP-Web-Shells: Eine heimliche Bedrohung für Linux-Server
Bedrohungsakteure nutzen zunehmend HTTP-Cookies als Kontrollkanal für PHP-basierte Web-Shells auf Linux-Servern, was eine Remote Code Execution mit verbesserter Tarnung ermöglicht. Diese Technik erlaubt es bösartigem Code, ruhend zu bleiben, bis spezifische Cookie-Werte vorhanden sind, was die Erkennung erschwert.

Laut Erkenntnissen des **Microsoft Defender Security Research Team** nutzen Bedrohungsakteure HTTP-Cookies aus, um **PHP**-basierte Web-Shells auf **Linux**-Servern zu steuern. Dies ermöglicht ihnen, Remote Code Execution auf heimlichere Weise zu erreichen.
"Anstatt die Befehlsausführung über URL-Parameter oder Request Bodies offenzulegen, verlassen sich diese Web-Shells auf vom Bedrohungsakteur bereitgestellte Cookie-Werte, um die Ausführung zu steuern, Anweisungen zu übermitteln und bösartige Funktionalitäten zu aktivieren", erklärte **Microsoft**.
### Der Tarnvorteil
Dieser Ansatz bietet erhöhte Tarnung, da der bösartige Code während der normalen Anwendungs ausführung ruht. Die Web-Shell-Logik wird erst aktiviert, wenn spezifische Cookie-Werte vorhanden sind. Dieses Verhalten erstreckt sich auf Web-Anfragen, geplante Aufgaben und vertrauenswürdige Hintergrund-Worker.
Die bösartige Aktivität nutzt die Tatsache aus, dass Cookie-Werte zur Laufzeit über die `$_COOKIE`-Superglobale Variable in **PHP** leicht zugänglich sind. Dies ermöglicht die Aufnahme von vom Angreifer bereitgestellten Eingaben ohne zusätzliche Verarbeitung. Darüber hinaus ist es unwahrscheinlich, dass die Technik rote Flaggen auslöst, da Cookies sich in den normalen Webverkehr einfügen und so die Sichtbarkeit verringern.
### Implementierungsvarianten
Das cookie-gesteuerte Ausführungsmodell gibt es in verschiedenen Implementierungen:
* Ein **PHP**-Loader, der mehrere Ebenen der Verschleierung und Laufzeitprüfungen verwendet, bevor er strukturierte Cookie-Eingaben verarbeitet, um eine verschlüsselte sekundäre Payload auszuführen.
* Ein **PHP**-Skript, das strukturierte Cookie-Daten segmentiert, um operative Komponenten wie Datei-Handling und Dekodierungsfunktionen zu rekonstruieren und bedingt eine sekundäre Payload auf die Festplatte schreibt und ausführt.
* Ein **PHP**-Skript, das einen einzelnen Cookie-Wert als Marker verwendet, um vom Bedrohungsakteur gesteuerte Aktionen auszulösen, einschließlich der Ausführung von bereitgestellten Eingaben und des Hochladens von Dateien.
### Erster Zugriff und Persistenz
In mindestens einem Fall erlangten Bedrohungsakteure den ersten Zugriff auf die gehostete **Linux**-Umgebung eines Opfers über gültige Anmeldeinformationen oder die Ausnutzung einer bekannten Sicherheitslücke. Dieser Zugriff wurde genutzt, um einen Cron-Job einzurichten, der periodisch eine Shell-Routine aufruft, um einen verschleierten **PHP**-Loader auszuführen.

Diese "selbstheilende" Architektur ermöglicht es dem **PHP**-Loader, auch wenn er während Bereinigungsbemühungen entfernt wird, durch die geplante Aufgabe wiederholt neu erstellt zu werden. Dies schafft einen zuverlässigen und persistenten Kanal für Remote Code Execution. Nach der Bereitstellung bleibt der **PHP**-Loader während des normalen Verkehrs inaktiv und wird nur bei Erhalt von HTTP-Anfragen mit spezifischen Cookie-Werten aktiviert.
"Durch die Verlagerung der Ausführungssteuerung in Cookies kann die Web-Shell im normalen Verkehr verborgen bleiben und nur während bewusster Interaktionen aktiviert werden", fügte **Microsoft** hinzu. "Durch die Trennung der Persistenz durch Cron-basierte Neuerstellung von der Ausführungssteuerung durch Cookie-gesteuerte Aktivierung hat der Bedrohungsakteur operative Geräusche reduziert und beobachtbare Indikatoren in routinemäßigen Anwendungsprotokollen begrenzt."
Ein gemeinsames Merkmal aller Implementierungen ist die Verwendung von Verschleierung, um sensible Funktionalität zu verbergen, und die cookie-basierte Steuerung, um die bösartige Aktion zu initiieren und den interaktiven Fußabdruck zu minimieren.
### Minderungsstrategien
Um dieser Bedrohung entgegenzuwirken, empfiehlt **Microsoft**:
* Erzwingen von Multi-Faktor-Authentifizierung für Hosting-Kontrollpanels, SSH-Zugriff und administrative Schnittstellen.
* Überwachung auf ungewöhnliche Anmeldeaktivitäten.
* Beschränkung der Ausführung von Shell-Interpretern.
* Überprüfung von Cron-Jobs und geplanten Aufgaben auf Webservern.
* Überprüfung auf verdächtige Dateierstellung in Webverzeichnissen.
* Beschränkung der Shell-Fähigkeiten von Hosting-Kontrollpanels.
"Die konsistente Verwendung von Cookies als Kontrollmechanismus deutet auf die Wiederverwendung etablierter Web-Shell-Handwerkskunst hin", sagte **Microsoft**. "Durch die Verlagerung der Steuerungslogik in Cookies ermöglichen Bedrohungsakteure eine persistente Post-Kompromittierungs-Zugriff, der viele traditionelle Inspektions- und Protokollierungssteuerungen umgehen kann."
"Anstatt sich auf komplexe Exploit-Ketten zu verlassen, nutzte der Bedrohungsakteur legitime Ausführungspfade, die bereits in der Umgebung vorhanden waren, einschließlich Webserver-Prozessen, Kontrollpanel-Komponenten und Cron-Infrastruktur, um bösartigen Code zu inszenieren und zu erhalten."