Reverse Shells erkennen, ohne so zu tun, als reiche eine Sigma-Regel
Reverse-Shell-Erkennung braucht Prozess-, Netzwerk- und Workload-Kontext. Einzelne Signaturen erzeugen Lärm und verpassen echte Fälle.
Reverse Shells zu erkennen ist undankbar, weil die Technik simpel ist. Ein Prozess öffnet eine ausgehende Verbindung und verbindet Ein- und Ausgabe mit einer Shell oder einem Interpreter. Das kann ein Angriff sein. Es kann aber auch ein hässliches Admin-Skript sein, das jemand während eines Incidents geschrieben hat.
Die schwache Erkennung lautet: Alarm, wenn bash ins Internet spricht. Damit findest du einige Tests. Du verpasst aber Python-Callbacks, PowerShell, missbrauchte Admin-Tools, Container-Kontexte und alles, was durch ohnehin laute Automatisierung läuft.
Prozessdaten zeigen die Absicht
Netzwerklogs sagen, dass eine Verbindung existiert. Prozessbäume erklären, warum sie verdächtig ist.
Nützliche Signale sind Shells als Kinder von Webservern, Interpreter unter php-fpm, cmd.exe oder PowerShell aus exponierten Services, kurzlebige Prozesse mit sofortiger ausgehender Verbindung oder Systembinaries, die nicht zum Host-Rollenprofil passen. Unter Linux helfen auditd, eBPF-Sensoren oder EDR, wenn argv, Benutzer und Parent PID erhalten bleiben. Unter Windows ist Sysmon Event ID 1 zusammen mit Netzwerkereignissen ein brauchbarer Start.
Eine grobe Suchhypothese:
process.name in ("sh", "bash", "dash", "zsh", "cmd.exe", "powershell.exe", "python", "perl", "php", "ruby")
AND network.direction = "outbound"
AND destination.ip NOT IN approved_admin_ranges
Das ist keine fertige Produktionsregel. Es ist ein Einstieg. Die Ausnahmen und der Kontext entscheiden, ob sie nutzbar wird.
Der Parent-Prozess erzählt die Geschichte
bash aus einer interaktiven SSH-Sitzung kann normal sein. bash gestartet von nginx, apache2, php-fpm, postgres, jenkins oder einem Dokumentkonverter ist deutlich ernster.
Angreifer wissen das. Sie verstecken sich hinter Interpretern und vorhandenen Tools, weil viele Detection-Regeln auf Namen statt Verhalten schauen. Eine Reverse Shell in Python enthält vielleicht keine leicht erkennbare Zeichenkette. Nur Socket, subprocess und Dateideskriptoren.
String-Matching allein reicht nicht.
Netzwerk-Kontext bleibt wichtig
Ausgehende Verbindungen von Servern zu hohen Ports in Residential-ASNs sind selten harmlos. Lange Sessions aus Workloads, die normalerweise nur Datenbanken, Queues oder interne APIs erreichen, sind ebenfalls interessant. DNS hilft bei Wegwerfdomains, aber direkte IP-Callbacks sind in Labs und opportunistischen Angriffen weiter üblich.
In Container-Umgebungen gehören Pod, Namespace, Image und Service Account in den Alarm. Ohne diese Daten bekommt der Analyst eine Node-IP und einen Prozessnamen. Das ist zu wenig.
False Positives töten gute Ideen
Laute Reverse-Shell-Regeln werden stummgeschaltet. Backup-Skripte starten Shells. CI-Runner führen Interpreter aus. SREs debuggen unter Druck. Wenn jede ausgehende Shell-Verbindung kritisch ist, überlebt die Regel nicht lange.
Arbeite mit Stufen. Hoch für Shells als Kinder exponierter Services. Mittel für ungewöhnliches Shell-Networking auf Servern. Niedrig auf Entwickler-Workstations, außer Ziel, Parent-Prozess oder Kommandozeile sind klar schmutzig.
Die brauchbare Erkennung ist keine einzelne Signatur. Sie ist ein kleiner Graph: Parent, Kommandozeile, Benutzer, Ziel, Workload-Rolle, Uhrzeit und ob dieser Host so etwas schon einmal getan hat.