Erklären Sie Reverse Shells im Vergleich zu Bind Shells und wann Sie welche wählen würden.
Kurzantwort
Eine Bind Shell öffnet einen lauschenden Port auf dem Ziel und wartet, dass Sie sich verbinden. Eine Reverse Shell lässt das Ziel ausgehend zu einem von Ihnen kontrollierten Listener verbinden. Reverse Shells gewinnen meist, weil ausgehender Verkehr eingehende Firewall-Regeln und NAT umgeht.
Nachdem Sie Codeausführung erlangt haben, brauchen Sie einen interaktiven Kanal zurück zum Ziel. Die beiden klassischen Modelle unterscheiden sich darin, welche Seite die TCP-Verbindung initiiert, und dieses eine Detail entscheidet, welches in echten Netzwerken tatsächlich funktioniert.
Bind Shell
Bei einer Bind Shell öffnet die Payload auf dem Ziel einen lauschenden Socket auf einem Port und wartet. Der Angreifer verbindet sich dann zu diesem Port, um eine Shell zu erhalten.
- Richtung: Angreifer verbindet sich zum Ziel.
- Problem: Eingehende Verbindungen zum Ziel werden meist von Perimeter-Firewalls und NAT blockiert. Ein Opfer hinter NAT ist aus dem Internet typischerweise gar nicht erreichbar, und eingehende Ports sind das Erste, was Firewalls verwerfen.
- Bind Shells sind vor allem in einem flachen internen Netzwerk nützlich, in dem Sie bereits direkte Erreichbarkeit haben.
Reverse Shell
Bei einer Reverse Shell betreibt der Angreifer einen Listener, und die Payload auf dem Ziel stellt eine ausgehende Verbindung dorthin her.
- Richtung: Ziel verbindet sich nach außen zum Angreifer.
- Vorteil: Ausgehender Verkehr ist weit großzügiger. Die meisten Netzwerke erlauben Hosts ausgehende Verbindungen (besonders auf 80/443), und NAT erledigt den Rückweg automatisch. Deshalb sind Reverse Shells der Standard in echten Einsätzen.
- Um sich einzufügen, lassen Tester den Callback oft über gängige Ports laufen und hüllen ihn sogar in TLS.
Der Haken: Egress-Filterung
Ein ausgereiftes Netzwerk beschränkt auch ausgehenden Verkehr. Ist nur geproxyter Web-Verkehr nach außen erlaubt, stirbt eine naive Reverse Shell zu Port 4444. Tester passen sich an, indem sie über 443 zurückrufen, durch den Proxy tunneln oder DNS-/ICMP-/HTTPS-C2-Kanäle nutzen.
Worauf Interviewer achten
Dass Sie korrekt angeben, wer die Verbindung initiiert, dass Sie wegen Firewalls und NAT standardmäßig zu Reverse Shells greifen und dass Sie Egress-Filterung als die reale Einschränkung verstehen — Bonuspunkte für die Erwähnung von TTY-Stabilisierung und dem Einfügen in 443.
Wahrscheinliche Anschlussfragen
- Warum bricht Egress-Filterung manchmal trotzdem eine Reverse Shell, und wie passen Sie sich an?
- Wie würden Sie eine rohe Reverse Shell zu einem voll interaktiven TTY stabilisieren und aufwerten?
- Was ist für einen Verteidiger der beste Erkennungspunkt für jeden Typ?