Unix-Shell-Ausführung erkennen: Reverse Shells und Webshells unter Linux

Unix-Shell-Ausführung erkennen heißt, den Moment zu sehen, in dem aus einer Schwachstelle ein interaktiver Zugriff wird. Fast jeder Angriff auf ein Linux-System läuft früher oder später durch eine Shell: Sie ist der Interpreter, über den ein Angreifer Befehle absetzt, Werkzeuge nachlädt und sich weiterbewegt. Die gute Nachricht für die Verteidigung ist, dass genau dieser Schritt laut wird, sobald die Prozess-Telemetrie steht. Dieser Beitrag aus der Serie "Angriff erkennen" nimmt die Unix-Shell aus Verteidigersicht auseinander: was der Angreifer tut, welche Logquellen es zeigen, drei Sigma-Regeln, die Härtung, eine Checkliste für die Analyse und der Test. Die Grundlagen zur Telemetrie stehen unter Linux-Sicherheitsmonitoring.

Was der Angreifer tut

So unterschiedlich die Wege auf ein Linux-System sind, am Ende steht fast immer eine Shell. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Shell aus einem Netzwerkdienst. Eine ausgenutzte Web- oder Applikationsschwachstelle bringt den Dienst selbst dazu, eine Shell zu starten. Der Webserver (nginx, Apache, PHP-FPM) oder ein Java-Prozess wird so zum Elternprozess einer sh oder bash - das klassische Webshell- und RCE-Muster.
• Reverse Shell. Statt auf eine eingehende Verbindung zu warten, baut die Shell selbst einen Kanal nach außen auf, oft über die Bash-Builtins auf /dev/tcp oder über netcat, python und perl. So wird eine Firewall umgangen, die nur eingehende Verbindungen blockt.
• Nachladen und Ausführen. Ein Einzeiler lädt ein Skript per curl oder wget und reicht es direkt an eine Shell weiter (curl ... | bash), ohne es auf die Platte zu schreiben. Das vermeidet Dateiartefakte und umgeht einfache Dateiscanner.
• Interaktiv weiterarbeiten. Mit der Shell folgen Aufklärung, Rechteausweitung und Persistenz. Die Schritte danach stehen unter SUID/SGID-Missbrauch, Sudo-Missbrauch und Cron- und systemd-Persistenz.

Der gemeinsame Nenner ist der Shell-Prozess selbst und, bei der Reverse Shell, die ausgehende Verbindung kurz danach. Genau daran setzen die Regeln an.

Welche Logquellen die Technik zeigt

• auditd (die wichtigste Quelle). Eine execve-Regel protokolliert jeden Programmstart. Der SYSCALL-Datensatz nennt den ausführenden Nutzer (uid, auid), den Elternprozess (ppid) und das Programm (exe), der EXECVE-Datensatz die vollständigen Argumente (a0, a1, ...). Eine passende Audit-Regel ist -a always,exit -F arch=b64 -S execve -k exec.
• Sysmon for Linux. Event 1 (Prozesserstellung) liefert Image, CommandLine und ParentImage in einem Datensatz, Event 3 (Netzwerkverbindung) die ausgehende Verbindung einer Reverse Shell samt Zieladresse. Die Event-IDs sind dieselben wie unter Windows.
• journald. Der Dienstkontext hilft bei der Einordnung: der sshd-Login, der eine Sitzung eröffnet, oder der Webserver-Dienst, unter dem die Shell läuft. Die Shell-History (~/.bash_history) ist dagegen keine verlässliche Sicherheitsquelle, weil sie sich leicht abschalten und fälschen lässt.
• Netzwerkseite. Die ausgehende Verbindung einer Reverse Shell wird auch in Zeek oder an der Firewall sichtbar - besonders wertvoll, wenn der Endpunkt kompromittiert ist und seiner eigenen Telemetrie nicht mehr zu trauen ist.

Das Muster im Log

Eine Shell allein ist Alltag - auf einem interaktiven Server laufen ständig welche. Verdächtig wird sie durch Herkunft, Kommandozeile und Kontext. Drei Fragen trennen den Angriff vom Normalbetrieb: Wer ist der Elternprozess? Ein Webserver oder eine Datenbank, die eine Shell startet, hat dafür fast nie einen legitimen Grund. Was steht in der Kommandozeile? Eine Umleitung auf /dev/tcp, ein bash -i ohne Terminal oder eine Pipe von curl sind starke Signale. Gibt es eine TTY? Interaktive Admin-Shells hängen an einem Terminal, Reverse Shells oft nicht. Zusammen mit einer ausgehenden Verbindung unmittelbar nach dem Shell-Start wird aus dem Verdacht ein belastbarer Treffer.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli validiert und nutzen die generische Linux-Logquelle process_creation, die sowohl Sysmon for Linux als auch auditd abdecken. Die erste fängt die Shell aus einem Netzwerkdienst, die zweite die Reverse-Shell-Kommandozeile, die dritte das Nachladen per Pipe. Wie die Regeln ins eigene SIEM übersetzt werden, steht unter Sigma-Regeln.

1. Shell aus einem Netzwerkdienst (T1059.004). Ein Web- oder Applikationsdienst als Elternprozess einer Shell ist das deutlichste Signal. Die Dienstliste wird an die eigene Umgebung angepasst.

title: Unix-Shell von einem Netzwerkdienst gestartet
id: 643bbfc0-11cf-4cfa-be33-3f241c5dfb50
status: experimental
description: Erkennt eine Unix-Shell (sh, bash, dash, zsh), die von einem ins Netz
  exponierten Dienst wie einem Web- oder Applikationsserver gestartet wird. Das ist
  das klassische Muster nach einer ausgenutzten Schwachstelle (Webshell, RCE), bei
  dem der Dienst eine Shell oder einen Reverse-Shell-Prozess startet.
references:
  - https://attack.mitre.org/techniques/T1059/004/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '/nginx'
      - '/apache2'
      - '/httpd'
      - '/php-fpm'
      - '/node'
      - '/java'
  selection_shell:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
  condition: selection_parent and selection_shell
falsepositives:
  - Legitime CGI-Skripte und Admin-Werkzeuge, die bewusst eine Shell aus dem Dienst heraus starten
level: high

2. Reverse-Shell-Muster in der Kommandozeile (T1059.004). Die Umleitung auf /dev/tcp oder /dev/udp und netcat mit Programmausführung sind klassische Reverse-Shell-Signaturen.

title: Reverse-Shell-Muster in einer Unix-Shell-Kommandozeile
id: b707cb4e-e157-4831-827f-97328c74b458
status: experimental
description: Erkennt typische Reverse-Shell-Aufrufe ueber eine Unix-Shell, etwa die
  Umleitung auf /dev/tcp oder /dev/udp oder netcat mit Programmausfuehrung. Solche
  Aufrufe geben einem Angreifer eine interaktive Shell ueber das Netz.
references:
  - https://attack.mitre.org/techniques/T1059/004/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  product: linux
  category: process_creation
detection:
  selection_devtcp:
    CommandLine|contains:
      - '/dev/tcp/'
      - '/dev/udp/'
  selection_nc:
    Image|endswith:
      - '/nc'
      - '/ncat'
      - '/netcat'
    CommandLine|contains:
      - ' -e '
      - ' -c '
  condition: selection_devtcp or selection_nc
falsepositives:
  - Health-Checks und Skripte, die /dev/tcp fuer reine Portpruefungen nutzen
level: high

3. Download direkt an eine Shell weitergereicht (T1059.004). curl oder wget mit einer Pipe an sh oder bash ist das Muster fürs dateilose Nachladen.

title: Heruntergeladenes Skript direkt an eine Shell weitergereicht
id: deee6c1b-673c-4cbd-b28e-7b2815600e67
status: experimental
description: Erkennt das Muster curl oder wget mit einer Pipe an eine Unix-Shell
  (curl ... | bash). Angreifer laden damit ein Skript nach und fuehren es aus, ohne
  es auf die Platte zu schreiben.
references:
  - https://attack.mitre.org/techniques/T1059/004/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  product: linux
  category: process_creation
detection:
  selection_tool:
    CommandLine|contains:
      - 'curl'
      - 'wget'
  selection_pipe:
    CommandLine|contains:
      - '| bash'
      - '| sh'
      - '|bash'
      - '|sh'
  condition: selection_tool and selection_pipe
falsepositives:
  - Installationsskripte, die bewusst per Pipe installieren (z. B. Entwickler-Tooling)
level: medium

Härtung

• Ausgehenden Verkehr begrenzen. Eine strikte Egress-Firewall, die nur benötigte Ziele erlaubt, lässt die meisten Reverse Shells ins Leere laufen. Für Server ist eine Default-Deny-Regel nach außen die wirksamste Einzelmaßnahme.
• Dienste einsperren. AppArmor- oder SELinux-Profile und seccomp verhindern, dass ein Webserver überhaupt eine Shell starten darf. Das schließt das Webshell-Muster an der Wurzel.
• Dienstkonten ohne Shell. Systemkonten bekommen /usr/sbin/nologin als Login-Shell, damit ein gestohlenes Dienstkonto keine interaktive Sitzung eröffnet.
• Minimale Images. In Containern gehören Shell, curl, wget und Compiler nicht ins Laufzeit-Image. Distroless- oder minimale Images und ein read-only Dateisystem nehmen dem Angreifer die Werkzeuge. Mehr unter Container- und Kubernetes-Sicherheit.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einer isolierten VM mit aktivem auditd (execve-Regel) und Sysmon for Linux:

• Für Regel 1 aus einem Testdienst heraus eine Shell starten, etwa ein CGI-Skript, das /bin/sh aufruft. In auditd muss der execve mit dem Dienst als ppid erscheinen, in Sysmon for Linux Event 1 mit dem Dienst als ParentImage.
• Für Regel 2 einen lokalen Listener mit nc -lvnp 4444 starten und von derselben VM aus eine Bash-Reverse-Shell auf 127.0.0.1 öffnen. Die Kommandozeile mit /dev/tcp muss die Regel auslösen, Event 3 die Verbindung zeigen.
• Für Regel 3 ein harmloses curl http://127.0.0.1/test.sh | bash gegen einen lokalen Webserver absetzen und den Treffer prüfen.
• Breiter wird der Test mit den Fällen zu T1059.004 aus Atomic Red Team.

Fehlalarme und Tuning

• Automatisierung und Deployment. Ansible, CI/CD-Runner und Konfigurationswerkzeuge starten regelmäßig Shells, auch aus übergeordneten Diensten. Diese bekannten Eltern-Kind-Paare und Konten als Baseline ausnehmen, statt die Regel zu entschärfen.
• Legitime Installer per Pipe. Manche Entwickler-Tools installieren per curl ... | bash. Solche Fälle gehören nach Host, Konto und Ziel-URL auf eine Ausnahmeliste; auf Produktivservern sollte das Muster aber selten sein.
• Health-Checks auf /dev/tcp. Einige Skripte prüfen damit nur die Erreichbarkeit eines Ports. Sie lassen sich an der fehlenden interaktiven Umleitung und am bekannten Skriptpfad unterscheiden.
• Interaktive Admins. Eine Shell mit TTY aus einer regulären sshd-Sitzung eines bekannten Kontos ist Normalbetrieb. Der Fokus liegt auf Shells ohne TTY, aus Diensten oder mit Netz-Umleitung.

Analysten-Checkliste

• Elternprozess prüfen: Startet ein Webserver, eine Datenbank oder ein anderer Netzwerkdienst die Shell?
• Kommandozeile lesen: /dev/tcp, /dev/udp, bash -i, nc -e oder eine Pipe von curl/wget enthalten?
• Konto bewerten: Läuft die Shell unter einem Dienstkonto (www-data, nobody) statt unter einem Admin? auid mit dem erwarteten Login abgleichen.
• TTY prüfen: Hängt die Shell an einem Terminal oder nicht?
• Netzverbindung korrelieren: Gibt es in Event 3 eine ausgehende Verbindung kurz nach dem Shell-Start? Ziel-IP und Port bewerten.
• Folgeaktivität suchen: Aufklärung, SUID-Aufrufe, sudo oder neue Cron-Einträge im selben Zeitfenster?

Fazit

Die Unix-Shell ist der Dreh- und Angelpunkt fast jedes Linux-Angriffs und zugleich einer der am besten erkennbaren Schritte, sobald die Prozess-Telemetrie steht. Der execve in auditd, Event 1 und Event 3 in Sysmon for Linux und die verräterische Kommandozeile decken die Shell aus einem Dienst, die Reverse Shell und das Nachladen per Pipe ab. Wer diese Ereignisse erfasst, die drei Regeln im Lab prüft und ausgehenden Verkehr konsequent begrenzt, nimmt dem Angreifer sein wichtigstes Werkzeug die Tarnung. Was danach kommt, steht unter SUID/SGID-Missbrauch und Cron- und systemd-Persistenz. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Execution.