Automatisierung von GOAD und Live Malware Labs

Einleitung: Der Bedarf an einem skalierbaren, automatisierten Simulationsbereich

Im modernen Sicherheitsbetrieb ist die Erkennungstechnik keine Disziplin mehr, die man einmal einrichtet und dann vergisst. Die zentrale Herausforderung für jedes Sicherheitsteam – und die Frage, die dem gesamten Purple-Team-Ansatz zugrunde liegt – ist einfach: Woher wissen Sie, ob Ihre Erkennungsregeln tatsächlich funktionieren? Die kontinuierliche Überprüfung der Erkennungslogik anhand eines sich ständig verändernden Angreifer-Werkzeugkastens ist heute eine grundlegende Voraussetzung.

Die größte Hürde bei diesem Vorhaben war wohl immer die Einrichtung des Labors. Die manuelle Bereitstellung einer Active Directory-Gesamtstruktur mit mehreren Domänen, deren Konfiguration mit spezifischen Schwachstellen und die Bereitstellung einer separaten, abgeschlossenen Malware-Analyseumgebung ist ein komplexer und zeitaufwändiger Prozess. Diese sich wiederholenden Einrichtungsarbeiten belasten die wertvollste Ressource eines Unternehmens erheblich: die Zeit seiner leitenden Sicherheitsanalysten. In den Diskussionen der Community wird diese Frustration deutlich, wobei die vielen Stunden hervorgehoben werden, die für die manuelle Einrichtung verloren gehen, bevor überhaupt ein einziger Test durchgeführt werden kann.

Dieser Blog beschreibt eine moderne Lösung, die diesen Engpass beseitigt, indem sie eine schnelle Infrastrukturautomatisierung mit einer einheitlichen Sicherheitsanalyseplattform kombiniert. Die Lösung nutzt zwei Schlüsselkomponenten:

1. Ludus: Ein Open-Source-Automatisierungs-Overlay, das komplexe, aus mehreren VMs bestehende Cyber-Umgebungen mit einem einzigen Befehl bereitstellt und konfiguriert.
2. Elastic SecurityDie Plattform vereint Security Information and Event Management (SIEM), eXtended Detection and Response (XDR) und Cloud-Sicherheit und bietet eine konsolidierte Lösung zur Erfassung, Erkennung und Reaktion auf Bedrohungen . Es bietet die "grenzenlose Sichtbarkeit", die erforderlich ist, um jede Aktion innerhalb der simulierten Umgebung zu beobachten.

Ziel dieses Leitfadens ist es, eine definitive, schrittweise Anleitung zum Aufbau dieses integrierten Systems zu liefern. Es wird gezeigt, wie man von langsamen, manuellen und uneinheitlichen Labortests zu einem kontinuierlichen, automatisierten und skalierbaren Workflow für die Erkennung und Entwicklung über das hinauskommt, was Elastic Cortado bietet.

Die Lösungsarchitektur: Ludus + Elastic

Diese Architektur stellt eine hochpräzise Simulation eines modernen hybriden Unternehmens dar. Die Ludus-Produktreihe fungiert als „On-Premise“- oder IaaS-Rechenzentrum, während die Elastic Cloud-Bereitstellung den „SaaS“-Sicherheitsstack darstellt. Dieses Modell bildet die hybriden und Multi-Cloud-Umgebungen, die Elastic Security schützen soll, perfekt ab, wodurch die Architektur des Tests genauso wertvoll ist wie die Angriffe selbst.

Der Build besteht aus folgenden Kernkomponenten.

Komponente 1: Die Stiftung (Ludus)

Ludus dient als Infrastructure-as-a-Service (IaaS)-Schicht. Es wurde für den Betrieb unter Proxmox 8/9 oder Debian 12/13 entwickelt und verwendet YAML-Konfigurationsdateien zur Definition komplexer virtueller Netzwerke. Es unterstützt bis zu 255 verschiedene VLANs. Im Hintergrund nutzt Ludus Packer und Ansible, um die Vorlagen für virtuelle Maschinen aus dieser einen Datei zu erstellen, zu konfigurieren und bereitzustellen.
Lesen und befolgen Sie die Installationsschritte und Hardwarevoraussetzungen in der Ludus -Schnellstartanleitung.

Komponente 2: Die Ziele (Die Labore)

Dieser Leitfaden vereint zwei unterschiedliche Ludus-Umgebungen zu einem einzigen, umfassenden Testbereich, um ein breiteres Spektrum an Bedrohungen zu testen:

• Game of Active Directory (GOAD) Ein eigens dafür eingerichtetes Active Directory-Labor, das von Sicherheitsforschern bei Orange Cyberdefense entwickelt wurde. Es ist mit den spezifischen Fehlkonfigurationen und Schwachstellen vorkonfiguriert, die erforderlich sind, um gängige identitätsbasierte Angriffspfade wie Kerberoasting, NTLM Relay und den Missbrauch von Active Directory Certificate Services (ADCS) zu simulieren.
• XZbot Malware-LaborEine Malware-Umgebung mit hohem Risiko und hoher Genauigkeit . Dieses Labor enthält die tatsächliche, funktionsfähige Hintertür CVE-2024-3094. Dies bietet einen perfekten, modernen Testfall für einen ausgeklügelten Angriff auf die Software-Lieferkette.

Wichtiger Haftungsausschluss

Der Umgang mit aktiver Malware, selbst zu Forschungszwecken, kann gegen die Richtlinien zur akzeptablen Nutzung (Acceptable Use Policies, AUPs) von Internetdienstanbietern oder Cloud-Anbietern verstoßen. Stellen Sie sicher, dass Sie die Infrastruktur besitzen (Ludus ist lokal installiert) und dass Ihr vorgelagerter Internetdienstanbieter solche Forschung zulässt, oder leiten Sie den Datenverkehr über ein VPN.

Komponente 3: Das Sensornetz (Elastischer Agent & Verteidigung)

Um Transparenz zu gewährleisten, wird jede virtuelle Maschine der Ludus-Reihe in den Laboren von GOAD und XZbot mit Elastic Agent ausgestattet, einem einzigen, einheitlichen Agenten für die Datenerfassung und den Schutz (über Elastic Defend).

Diese Instrumentierung wird über die Ansible-Rolle badsectorlabs/ludus_elastic_agent automatisiert. Diese Rolle ist der entscheidende Dreh- und Angelpunkt, der programmatisch die Infrastrukturbereitstellungsphase (Ludus/Ansible) mit der Sicherheitsinstrumentierungsphase (Elastic) verbindet und so einen echten „Infrastructure-as-Code“-Workflow ermöglicht.

Entscheidend ist, dass die Elastic Agent-Richtlinie mit der Elastic Defend- Integration konfiguriert wird. Dadurch wird der Agent von einem einfachen Protokollsammler zu einer vollwertigen Endpoint Detection & Response (EDR)/eXtended Detection & Response (XDR)-Lösung weiterentwickelt, die hostbasierte Erkennungen (einschließlich Machine Learning (ML)-gesteuerter Malware- und Ransomware-Erkennung) sowie die für die Erkennung unerlässliche tiefe Telemetrie auf Kernel-Ebene bietet.

Hinweis: Für den in diesem Blog beschriebenen Purple-Team-Ansatz müssen die Richtlinien auf den Erkennungsmodus eingestellt werden.

Komponente 4: Das Gehirn (Elastisch Cloud-gehostet / Elastisch Serverlos)

Sämtliche Sicherheitstelemetriedaten und Warnmeldungen der Elastic Agents der Ludus-Produktreihe werden an eine zentrale Elastic Cloud Hosted (ECH) - oder Elastic Serverless- Bereitstellung gestreamt. Hier entfaltet die einheitliche Plattform ihre analytische Stärke. Die Nutzung einer Cloud-nativen Plattform dient nicht nur dem Hosting; sie ermöglicht den Zugriff auf die fortschrittlichsten und leistungssteigernden Funktionen von Elastic, darunter Attack Discovery und der KI-Assistent. Klicken Sie hier, um eine Testversion von Elastic Cloud zu starten.

Das untenstehende Diagramm bietet einen Überblick über den Aufbau, der auf dem GOAD-Labor basiert.

Phase 1: Bau und Instrumentierung des Schießstandes

Dieser Abschnitt bietet eine technische Schritt-für-Schritt-Anleitung zur Konfiguration und Bereitstellung des automatisierten Schießstandes. Der Prozess folgt einem klaren „Infrastructure-as-Code“-Modell (IaC), bei dem die Sicherheitsinstrumentierung zusammen mit der Infrastruktur selbst definiert wird, um eine konsistente und wiederholbare Überwachung für jede Bereitstellung zu gewährleisten. Die Elastic Cloud-Instanz und ihre Konfigurationen können mit dem Elastic Cloud und Elastic Stack Terraform-Provider für ein vollständiges IaC-Modell der Produktreihe und des SIEM verwaltet werden.

3.1 Konfigurieren der Elastic Agent Policy (in Kibana)

Vor der Durchführung der Ludus-Bereichsbereitstellung muss die Agentenrichtlinie in der Elastic Cloud-Instanz erstellt werden. Diese Richtlinie ist die Grundlage für die leistungsstarke EDR/XDR-Telemetrie.

Der operative Ablauf gestaltet sich wie folgt:

1. Melden Sie sich bei der Elastic Cloud (ECH) oder Elastic Serverless Kibana-Instanz an.
2. Navigieren Sie zu Verwaltung > Flotte.
3. Erstellen Sie eine neue Agentenrichtlinie (z. B. „ludus-range-policy“). Die Rolle ludus_elastic_agent registriert Agents in die Richtlinie, die Sie in Ihrer VM-weiten Anpassung angeben, oder in die Standardrichtlinie, die mit der globalen Variable verknüpft ist.
4. Fügen Sie dieser Richtlinie die Elastic Defend- Integration hinzu .
5. Konfigurieren Sie die Elastic Defend-Integration so, dass sie im Erkennungsmodus ausgeführt wird. Dadurch wird die gesamte Palette der EDR-Telemetriedaten aktiviert.
6. Speichern Sie die Police und klicken Sie auf „Agent hinzufügen“. Dadurch werden das Registrierungstoken (für ludus_elastic_enrollment_token) und die Fleet-Server-URL (für ludus_elastic_fleet_server) bereitgestellt, die für die Datei ludus.yml benötigt werden.
7. (Optional) Wiederholen Sie die Schritte 3-6, um benutzerdefinierte Richtlinien zu erstellen, die auf die Funktionen und Fähigkeiten des Hosts für die VM-Ebenenanpassung von Richtlinien abgestimmt sind.

Sobald diese Richtlinie erstellt und das Token in die Datei ludus.yml eingefügt wurde, wird durch Ausführen von Ludus range deploy der vollständige, automatisierte Workflow ausgeführt. Ludus provisioniert die VMs, und Ansible installiert den Elastic Agent, der sich dann bei Fleet registriert und automatisch die Richtlinie herunterlädt, die die Elastic Defend-Integration enthält. Dadurch wird eine umfassende EDR-Telemetrie – Ereignisse auf Kernel-Ebene, Datei-, Netzwerk- und Registrierungsebene – vom Zeitpunkt der Einrichtung des Labors an bereitgestellt.

3.2 Die Ludus YAML-Konfiguration (ludus.yml)

Ludus stellt hier die Schritte zur Bereitstellung des GOAD-Bereichs bereit. Die Konfiguration für den Bereich wird in der Konfigurationsdatei ludus.yml gespeichert. Für den GOAD-Bereich befindet er sich in ad/GOAD/providers/ludus/config.yml.
Die vollständige Konfiguration im Anhang ist ein Beispiel, das auf einer Beispielkonfiguration basiert, die ein komplettes GOAD-Labor (auf VLAN 10) mit dem XZbot-Labor (auf VLAN 20) zusammenführt.

Um während der Installation eine angepasste Version bereitzustellen, aktualisieren Sie die Datei ad/GOAD/providers/ludus/config.yml , bevor Sie das Skript goad.sh in Schritt 2 ausführen.

git clone https://github.com/Orange-Cyberdefense/GOAD.git
cd GOAD
sudo apt install python3.11-venv
export LUDUS_API_KEY='myapikey'  # put your Ludus admin api key here nano ad/GOAD/providers/ludus/config.yml # customize the configuration here
./goad.sh -p ludus
GOAD/ludus/local > check
GOAD/ludus/local > set_lab GOAD # GOAD/GOAD-Light/NHA/SCCM
GOAD/ludus/local > install

Zur Anpassung des Bereichs können zwei wichtige Konfigurationsoptionen verwendet werden:

1. Globale Variablen: Um die Konfiguration zu vereinfachen und Wiederholungen zu vermeiden, werden die Elastic Agent-Variablen einmalig auf oberster Ebene in einem globalen Ansible.vars-Block definiert und von allen VMs geerbt.

   Das Registrierungstoken bestimmt die verwendete Elastic-Agent-Richtlinie.

# ludus.yml
---
# --- GLOBAL ANSIBLE VARS (Simplification) ---
# Define Elastic agent vars once and apply globally
global_role_vars:
  ludus_elastic_fleet_server: "<your-fleet.example.com:443>" # Use 443 for cloud
  ludus_elastic_enrollment_token: "<your_enrollment_token>"
  ludus_elastic_agent_version: "9.2.1"

2. Variablen auf VM-Ebene: Die Elastic Agent-Variablen können auf VM-Ebene konfiguriert werden, um die angewendete Richtlinie anzupassen. Diese können mit der globalen Variable kombiniert werden, zum Beispiel, indem die Agentenversion und fleet_server über globale Variablen festgelegt werden und die Registrierungstoken auf VM-Ebene festgelegt werden, um VMs unterschiedliche Richtlinien zuzuweisen.

# --- VM DEFINITIONS ---
vms:
  # --- GOAD LAB (VLAN 10) ---
  - name: "{{ range_id }}-GOAD-DC01"
    hostname: "{{ range_id }}-DC01"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 10
    ram_gb: 4
    cpus: 2
    windows: { sysprep: true }
    ansible:
      roles:
        - badsectorlabs.ludus_elastic_agent
      role_vars:
        ludus_elastic_enrollment_token: "<your_enrollment_token>" # different token for different policies
  # (Definitions for GOAD-DC02, GOAD-DC03, GOAD-SRV02, GOAD-SRV03 
  #  would follow, all inheriting the global ansible vars)

Automatisierung der Bereitstellung elastischer Agenten

Der obige Ausschnitt aus der ludus.yml-Datei veranschaulicht die Automatisierung. Durch Hinzufügen der Rolle badsectorlabs.ludus_elastic_agent zum Abschnitt ansible.roles jeder VM-Definition installiert und konfiguriert Ludus den Agenten automatisch während der Bereitstellung.

Diese einzelne Ansible-Rolle ist mit allen Betriebssystemen in unserem heterogenen Labor kompatibel, einschließlich Windows (für GOAD), Kali und Debian (für XZbot).

Wie im vereinfachten YAML-Code dargestellt, übergibt der ansible.vars-Block auf oberster Ebene die kritischen Parameter an die Rolle:

• ludus_elastic_fleet_server: Die Fleet-Server-URL und der Port für Ihre Elastic Cloud-Bereitstellung (z. B. your-fleet.example.com:443).
• ludus_elastic_enrollment_token: Das Token, mit dem der Agent registriert wird.
  Das vollständige Beispiel setzt das ludus_elastic_enrollment_token auf VM-Ebene, um die Möglichkeit der Verwendung unterschiedlicher Richtlinien zu demonstrieren.
• ludus_elastic_agent_version: Die spezifische Agentenversion, die installiert werden soll (z. B. 9.2.1).

Hinweis: Auf dem Kali-Host wird zusätzlich Elastic Defend zur Überwachung des Angreiferverhaltens eingesetzt. Dies ist in einem realen Szenario nicht möglich.

Sicherheit geht vor: Isolation, OPSEC und Live-Malware

Dieser Abschnitt enthält eine wichtige Sicherheits- und Betriebssicherheitswarnung (OPSEC). Diese Konfiguration birgt ein erhebliches, nicht unerhebliches Risiko, das professionell gemanagt werden muss.

4.1 Die Bedrohung: Dies ist keine Simulation

Es muss unmissverständlich klargestellt werden: Die Ludus XZbot Lab-Anleitung und die zugehörige Ansible-Rolle installieren die tatsächliche, funktionsfähige CVE-2024-3094-Hintertür. Dies ist kein harmloser, simulierter Code. In der Dokumentation des Labors heißt es: „Achtung: Diese Rolle enthält (absichtlich) Schadsoftware.“

Obwohl es als „passive Hintertür“ bezeichnet wird (was bedeutet, dass ein Angreifer sie aktiv auslösen muss), stellt jede virtuelle Maschine, auf der dieser Code mit einer offenen Internetverbindung läuft, ein katastrophales Risiko dar. Es könnte gescannt, von unbekannten Akteuren ausgenutzt oder als Ausgangspunkt für Angriffe auf andere Netzwerke verwendet werden.

4.2 Der Widerspruch: Isolation vs. Cloud-Konnektivität

Diese Architektur erzeugt einen direkten und kritischen operativen Konflikt:

1. Anforderung 1 (Sicherheit): Das Malware-Labor muss vom öffentlichen Internet isoliert sein, um eine Kompromittierung oder einen Ausbruch zu verhindern.
2. Anforderung 2 (Funktion): Der Elastic Agent muss über eine ausgehende Internetverbindung verfügen, um die Elastic Cloud Hosted / Elastic Serverless Endpunkte für die Registrierung und das Datenstreaming zu erreichen.

Ein unerfahrener Benutzer würde hier scheitern, entweder indem er sein infiziertes Labor der Öffentlichkeit preisgibt oder indem er es so vollständig isoliert, dass keine Sicherheitstelemetriedaten erfasst werden können.

4.3 Die Lösung: Nadelloch-Ausgang über den Ludus-Testmodus

Der Konflikt wird mithilfe des in Ludus integrierten „ Testmodus “ gelöst, der eine detaillierte Kontrolle über den Netzwerkausgang ermöglicht. Diese Funktion wird für den Pinhole-Ausgang verwendet, der die Agentensteuerung, Telemetrie und Protokollausgabe ermöglicht.

# 1. Start the isolated testing session
ludus testing start # Note external DNS resolvers may also need to be added # ludus testing allow -i 1.1.1.1,8.8.8.8

# 2. Allow Elastic Fleet Server (Control Plane)
# Replace <id> with your specific deployment ID # Note the endpoint will differ based on the cloud providers
ludus testing allow -d <your-deployment-id>.fleet.us-central1.gcp.cloud.es.io

# 3. Allow Elasticsearch Ingest (Data Plane) # Note the endpoint will differ based on the cloud providers
ludus testing allow -d <your-deployment-id>.es.us-central1.gcp.cloud.es.io

Diese Konfiguration bietet eine Lösung auf Expertenniveau: Die Malware wird sicher eingedämmt, während dem Elastic Agent nur die minimale Konnektivität gewährt wird, die erforderlich ist, um Richtlinienaktualisierungen vorzunehmen (über die Kommunikation mit dem fleet -Endpunkt) und Daten aufzunehmen (über die Kommunikation mit dem ES -Endpunkt).

4.4 Zugriff auf den Bereich im Testmodus (WireGuard)

Sobald der Testmodus aktiviert ist, schlägt das Standard-Routing fehl. Sie können nicht einfach per SSH von Ihrem lokalen Netzwerk aus auf Ihre Kali-VM zugreifen, da der Router den Datenverkehr blockiert. Ludus bietet einen Out-of-Band-Managementkanal über WireGuard.

Ludus konfiguriert eine WireGuard-Schnittstelle (wg0) auf der Router-VM (198.51.100.1) und weist Ihnen eine statische Client-IP-Adresse zu (z. B. 198.51.100.2).

• Permanente Zulassungsregeln: Die Firewall-Konfiguration des Routers enthält spezifische Regeln in der LUDUS_DEFAULTS-Kette. Diese Regeln akzeptieren ausdrücklich Datenverkehr, der aus dem WireGuard-Subnetz (198.51.100.0/24) stammt oder für dieses bestimmt ist.
• Priorität: Da diese Regeln in der LUDUS_DEFAULTS-Kette existieren, überschreiben sie die vom Testmodus angewendeten DROP-Regeln.

So stellen Sie die Verbindung her:

1. Erstellen Sie Ihre Konfiguration: ludus user wireguard > ludus.conf
2. Importieren Sie dies in Ihren lokalen WireGuard-Client und aktivieren Sie den Tunnel.
3. Stellen Sie über den Tunnel eine direkte Verbindung zu den privaten IPs Ihrer VMs her (z. B. 10.10.10.11).

Phase 2: Ausführung der Angriffe

Nachdem die hochauflösende, vollständig instrumentierte Teststrecke aufgebaut ist, kann die Phase des „Red Teams“ beginnen. Dies beinhaltet das Einloggen in eine dedizierte Angreifer-VM (wie die mitgelieferte Kali-VM oder eine remnux-analyzer-VM) und die Ausführung der Angriffe. Diese Aktivität erzeugt die umfangreichen, bösartigen Telemetriedaten, die Elastic Defend erfassen wird.

Dieser kombinierte Bereich ermöglicht das Testen von Abwehrmechanismen gegen die beiden dominanten Bedrohungsvektoren auf Makroebene: identitätsbasierte „Living-off-the-Land“-Angriffe (LotL) und auf Schwachstellen basierende Lieferkettenangriffe.

5.1 Active Directory-Simulation (GOAD)

• Erster Zugriff (Credential Stuffing)
  1. Der Angreifer zielt auf den äußeren Perimeter. Mithilfe einer Liste kompromittierter Zugangsdaten führen Sie einen Password-Stuffing-Angriff gegen die Essos.local-Domäne durch. Die Anmeldeinformationen für den Benutzer khal.drogo wurden erfolgreich validiert.
  2. Beispielwerkzeug: kerbrute oder smartbrute
  3. Ergebnis: Gültige Anmeldeinformationen für einen Domänenbenutzer mit geringen Berechtigungen.
• Rechteausweitung (PrintNightmare)
  1. khal.drogo hat eingeschränkte Rechte. Um sich Zugang zum CastelBlack-Server zu verschaffen, nutzen Sie PrintNightmare (CVE-2021-34527) aus. Diese Sicherheitslücke im Windows-Druckwarteschlangendienst ermöglicht es jedem authentifizierten Benutzer, einen bösartigen Druckertreiber zu installieren. Sie laden einen Treiber hoch, der dem System einen neuen lokalen Administratorbenutzer hinzufügt.
  2. Beispieltool: CVE-2021-34527.py Exploit-Skript
  3. Ergebnis: Lokaler SYSTEM-Zugriff auf CastelBlack.
• Anmeldeinformationsabfrage (DCSync-Vorbereitung)
  1. Sie arbeiten nun als SYSTEM/Admin auf CastelBlack und überprüfen den Rechner auf zwischengespeicherte Anmeldeinformationen. Sie verwenden den Befehl secretsdump von Impacket, um Hashes aus der SAM-Datenbank und dem LSASS-Speicher zu extrahieren. Sie entdecken den NTLM-Hash für das integrierte Administratorkonto, der von einer vorherigen Supportsitzung im Speicher verblieben ist.
  2. Beispieltool: impacket-secretsdump
  3. Ergebnis: NTLM-Hash eines Domänenadministrators oder eines Kontos mit hohen Berechtigungen.
• Kerberoasting
  1. Mit gültigen Domänenanmeldeinformationen wechseln Sie zum internen Netzwerk. Sie fordern Kerberos-Servicetickets (TGS) für Service Principal Names (SPNs) in der Umgebung an. Sie wählen das MSSQLSvc-Konto aus. Sie nehmen das verschlüsselte Ticket offline und knacken es, um das Klartextpasswort für das SQL-Dienstkonto aufzudecken.
  2. Beispieltool: Rubeus oder GetUserSPNs.py
  3. Ergebnis: Klartextpasswort für das MSSQL-Dienstkonto.
• MSSQL-Angriffe
  1. Sie verwenden die erbeuteten SQL-Zugangsdaten, um sich direkt am Braavos SQL Server zu authentifizieren. Da das Dienstkonto über Sysadmin-Rechte verfügt, missbrauchen Sie die gespeicherte Prozedur xp_cmdshell. Diese Funktion ermöglicht es Ihnen, direkt aus einer SQL-Abfrage eine Windows-Befehlsshell zu starten und Ihnen so effektiv die Ausführung von Remote-Code (RCE) auf dem Datenbankserver zu ermöglichen.
  2. Beispieltool: mssqlclient.py
  3. Ergebnis: Remote Code Execution (RCE) auf dem Datenbankserver.
• Persistenz (Geplante Aufgabe)
  1. Um sicherzustellen, dass Sie den Zugriff nicht verlieren, falls sich das SQL-Passwort ändert, richten Sie Persistenz ein. Sie erstellen eine geplante Windows-Aufgabe auf dem kompromittierten SQL-Server. Diese Aufgabe ist so konfiguriert, dass sie täglich eine Beacon-Binärdatei ausführt, die als SYSTEM ausgeführt wird.
  2. Beispieltool: schtasks.exe oder PowerShell
  3. Ergebnis: Langfristige Persistenz.

5.2 Malware-Labor-Simulation (XZbot)

• Schritt 7: Neuausrichtung der Lieferkette (XZ-Hintertür)
• Gleichzeitig greifen Sie die Linux-Infrastruktur in der DMZ an. Sie lösen die vorinstallierte XZ-Backdoor (CVE-2024-3094) auf der xz-backdoor-dect VM aus. Durch Manipulation des SSH-Handshakes mit einem bestimmten kryptografischen Schlüssel wird die Authentifizierung vollständig umgangen und Befehle als Root ausgeführt, ohne dass Standard-SSH-Protokolle hinterlassen werden.
• Tool: xzbot
• Ergebnis: Root-Zugriff auf die Linux-Infrastruktur durch Kompromittierung der Lieferkette.
• Der Angreifer verwendet den im Ludus-Labor bereitgestellten xzbot-Client.
• Von der Angreifer-VM aus wird folgender Befehl ausgeführt, um die Hintertür auf dem anfälligen Debian-Host zu aktivieren:
  xzbot --ssh-addr '10.XXX:22' -cmd 'setsid sh -c "echo test"' 2>&1
• Diese Aktion führt dazu, dass der sshd-Prozess auf dem Zielsystem anomal eine Shell startet und den Befehl als Root ausführt, wodurch ein eindeutiger Beweis für die Ausführung entsteht.

Phase 3: Einheitliche Erkennung und Untersuchung mit elastischer Sicherheit

Das ist die Belohnung für das "Blaue Team". Die in Phase 2 generierten Telemetriedaten und Warnmeldungen stehen nun zur Analyse innerhalb der einheitlichen Elastic Security-Plattform zur Verfügung.

6.1 Das „leistungsstarke SIEM“: Zentralisierte Transparenz und vordefinierte Erkennungsfunktionen

Die Stärke des Elastic SIEM liegt nicht nur in seiner Fähigkeit, Protokolle passiv zu sammeln. Seine Stärke liegt in der aktiven Analyse der von Elastic Defend bereitgestellten, tiefgreifenden Kontextdaten. Die „Complete Endpoint Visibility“ von Defend bietet nicht nur grundlegende Protokolle, sondern auch Telemetriedaten auf Kernel-Ebene – Prozesserstellungen, Dateimodifikationen, Netzwerkverbindungen und Registry-Änderungen.

Diese umfangreichen Daten, die alle auf das Elastic Common Schema (ECS) normalisiert sind, speisen die umfangreiche Bibliothek von Elastic mit über 1500 vorgefertigten, MITRE-abgebildeten Erkennungsregeln. Diese Regeln werden vom Team der Elastic Security Labs erforscht, entwickelt und gepflegt und bieten somit einen sofort einsatzbereiten Erkennungsnutzen.

Die Ludus-Produktpalette dient als perfekte Plattform zur Bestätigung dieses Wertes. Die in Phase 2 durchgeführten Angriffe sind nicht theoretischer Natur; sie sind direkt auf spezifische erwartete Artefakte („Smoking gun“) abgebildet. Im Beispiel werden bewusst vorgefertigte und benutzerdefinierte Regeln kombiniert, um auf bestimmte Verhaltensweisen aufmerksam zu machen.

Hinweis: Die Regeln zur Erkennung elastischer Elemente sind offen und transparent. Die Logik können Sie einsehen, dazu beitragen oder Probleme direkt auf (https://github.com/elastic/detection-rules) melden.

6.2 Vertiefung: Prozessketten mit dem Ereignisanalysator verfolgen

Die beiden Labore (GOAD und XZbot) bieten eine perfekte Gelegenheit, die spezialisierten Untersuchungswerkzeuge von Elastic einzusetzen. Die Benutzeroberfläche des Event Analyzers ist so konzipiert, dass sie die Komplexität von JSON-Protokollen in ein kognitives Modell abstrahiert, das der Denkweise von Sicherheitsanalysten entspricht: Prozessketten. Die Benutzeroberfläche besteht aus drei primären Interaktionsbereichen: der grafischen Arbeitsfläche, dem Detailbereich und der Zeitleistenintegration.

Was sehen wir?

Die grafische Leinwand (Der Prozessbaum)

Die zentrale Ansicht ist ein gerichteter azyklischer Graph, wobei:

• Knoten (Würfel): Jeder Würfel repräsentiert die Ausführung eines einzelnen Prozesses. Die Visualisierung unterscheidet zwischen dem "Anker"-Ereignis (hervorgehoben durch einen blauen Halo) und dem umgebenden Kontext.
• Kanten (Linien): Linien stellen die Eltern-Kind-Beziehung dar. Die Richtung ist implizit (von oben nach unten oder von links nach rechts) und zeigt den Ablauf der Ausführung an.
• Visuelle Kennzeichnung: Knoten sind keine statischen Symbole, sondern dynamische Indikatoren.
  • Warnsymbole: Wenn ein bestimmter Prozess eine Erkennungsregel auslöst (z. B. „Malware erkannt“), erscheint ein farbiges Symbol auf dem Würfel. Dadurch kann ein Analyst sofort erkennen, welcher Schritt in der Kette von der Erkennungs-Engine beanstandet wurde.
  • Benutzerkontext: Visuelle Hinweise können anzeigen, ob ein Prozess den Benutzerkontext geändert hat (z. B. von einem lokalen Benutzer zu SYSTEM), was auf eine Rechteausweitung hindeutet.

Das Detailpanel (Forensische Metadaten)

Durch Klicken auf einen beliebigen Knoten wird das Detailfenster geöffnet, das normalerweise von rechts hereinschiebt. Dieses Bedienfeld ist die primäre Quelle für die detaillierte Darstellung dessen, was Sie sehen können. Es legt Felder offen, die für die Verifizierung entscheidend sind:

• Befehlszeilenargumente: Dies ist wohl das wertvollste forensische Artefakt überhaupt. Der Analyzer zeigt die vollständige Zeichenkette an und legt dabei Flags, Skripte und kodierte Nutzdaten offen (z. B. powershell.exe -w hidden -enc Base64).
• Prozesspfad und Hash: Der vollständige Dateipfad hilft bei der Identifizierung von Identitätsdiebstahl (z. B. wenn svchost.exe von C:\Temp statt von C:\Windows\System32 ausgeführt wird). Dateihashes (MD5, SHA-1, SHA-256) werden zum Abgleich mit Bedrohungsdaten bereitgestellt.
• Informationen zum Unterzeichner: Informationen über die digitale Signatur der Binärdatei helfen dabei, zwischen vertrauenswürdigen Microsoft-Binärdateien und unsignierter Malware zu unterscheiden.
• Zählung verwandter Ereignisse: Anstatt den Graphen mit Tausenden von Dateimodifikationen zu überladen, zeigt der Knoten zusammenfassende Statistiken an (z. B. „15 Dateiereignisse“, „3 Netzwerkverbindungen“). Durch Anklicken dieser Statistiken gelangt man in der Regel zu einer Listenansicht oder einer Zeitleiste dieser spezifischen Aktionen.

Die zeitliche Dimension (Zeitfilter)

Ein entscheidender, oft übersehener Aspekt des Analysators ist sein Umgang mit der Zeit. Angriffe können lange „Verweilzeiten“ haben. Ein übergeordneter Prozess könnte bereits vor Wochen gestartet worden sein (z. B. ein legitimer Dienst), während der bösartige untergeordnete Prozess erst heute entstanden ist. Der Analyzer beinhaltet einen Zeitschieber, mit dem der Analyst das Abfragefenster vergrößern kann. Standardmäßig wird nur ein kleiner Bereich um die Warnung herum betrachtet. Durch die Erweiterung dieses Bereichs kann das Diagramm jedoch auch auf die Datenebenen „Warm“ oder „Cold“ zurückgreifen, um den übergeordneten, langlaufenden Prozess zu finden.

Wie funktionieren diese Abfragen?

Die operative Leistungsfähigkeit des Event Analyzers nutzt das Elastic Common Schema (ECS). In einer heterogenen Sicherheitsumgebung stammen die Protokolle aus verschiedenen Quellen – Windows-Endpunkten, Linux-Servern, Netzwerk-Firewalls und Cloud-Dienstanbietern – jede mit einer eigenen Taxonomie. Ein CrowdStrike-Agent könnte eine Prozess-ID als TargetProcessId bezeichnen, während ein Sysmon-Ereignis ProcessId verwendet. Ohne Normalisierung ist es algorithmisch unmöglich, diese Ereignisse zu einer einzigen Kette zusammenzufassen.
ECS löst dieses Problem durch die Durchsetzung einer strikten Feldhierarchie. Der Ereignisanalysator verwendet spezifische, hochpräzise ECS-Felder, um den visuellen Graphen zu erstellen:

• process.entity_id: Dies ist der Grundpfeiler der Logik des Analysators. Betriebssysteme recyceln Prozess-IDs (PIDs). Eine PID von 1234 könnte zu svchost.exe unter 09:00 und malware.exe unter 14:00 gehören. Die Verwendung von PID für langfristige historische Analysen führt zu Kollisionen, die den visuellen Graphen verfälschen und unzusammenhängende Ereignisse miteinander verknüpfen. Die process.entity_id ist eine eindeutige Zeichenkette, die vom Elastic Agent (oder ECS-kompatiblen Beats) generiert wird und eindeutig im Index gespeichert wird. Dadurch wird sichergestellt, dass der Graph unabhängig von der PID-Wiederverwendung eine eindeutige Ausführungsinstanz darstellt.
• process.parent.entity_id: Dieses Feld stellt die gerichtete Kante zwischen den Knoten her. Durch rekursives Abfragen von Ereignissen, bei denen die process.entity_id eines Ereignisses mit der process.parent.entity_id eines anderen Ereignisses übereinstimmt, rekonstruiert der Analyzer die Abstammungslinie.

Ereignissequenz: In Umgebungen mit hoher Geschwindigkeit ist die Reihenfolge der Ereignisse (z. B. ob die Dateiänderung vor oder nach der Netzwerkverbindung stattfand) von entscheidender Bedeutung. Mithilfe von ECS-Zeitstempeln und Sequenznummern kann der Analyzer Ereignisse innerhalb der visuellen Knotendetails chronologisch ordnen.

6.3 Vertiefung: Rekonstruktion der Benutzeraktivität mit dem Session Viewer

Für den XZbot (Linux)-Angriff ist der Session Viewer das überlegene Werkzeug. Es wurde speziell für die „Überwachung und Untersuchung der Sitzungsaktivität auf Linux-Infrastrukturen“ entwickelt.

Wenn die Warnung „Potenzielle Ausführung über XZBackdoor“ ausgelöst wird, untersucht der Analyst den zugehörigen sshd-Prozess. Der Session Viewer präsentiert ein „gut lesbares Format, das vom Terminal inspiriert ist“. Es rekonstruiert die Sitzung des Angreifers und zeigt den sshd-Prozess sowie seinen anomalen Kindprozess (sh) an.

Darüber hinaus zeigt es den exakten Befehl an, der ausgeführt wurde (sh -c setsid sh -c "usermod -aG sudo sysadmin_backup"), und kann sogar die Ausgabe dieses Befehls anzeigen. Dies ist der endgültige „Beweis“, der dem Analysten in einfachem, für Menschen lesbarem Text präsentiert wird und ihm somit ermöglicht, die TTY-Sitzung des Angreifers im Nachhinein anzusehen.

Was sehen wir?

Die Benutzeroberfläche des Session Viewers wurde speziell entwickelt, um die Lücke zwischen abstrakter Log-Analyse und der gewohnten Terminal-Erfahrung eines Linux-Administrators zu schließen. Im Gegensatz zum Event Analyzer, der sich auf Malware-Prozessketten konzentriert, bietet der Session Viewer eine zeitlich geordnete, baumbasierte Visualisierung, die den linearen Ablauf einer Shell-Sitzung rekonstruiert.

Prozessbaum und Zeitleiste

Das zentrale Element der Ansicht ist ein gerichteter azyklischer Graph (DAG), der als hierarchische Liste dargestellt wird.

• Vertikaler Ablauf: Der Session Viewer ordnet Prozesse vertikal an und ahmt so den Ablauf einer Terminalverlaufsdatei nach, wobei die Hierarchie erhalten bleibt. Kindprozesse sind relativ zu ihren Eltern eingerückt. Dies ermöglicht es einem Analysten, sofort zwischen einem direkt vom Benutzer ausgeführten Befehl (z. B. curl) und einem durch die Ausführung eines Skripts erzeugten Prozess (z. B. curl innerhalb eines setup.sh-Skripts) zu unterscheiden.
• Ausführlicher Modus: Über einen Schalter können Analysten zwischen einer gefilterten Ansicht (die die wichtigsten Benutzeraktivitäten anzeigt) und dem „Ausführlichen Modus“ umschalten. Wenn dieser Modus aktiviert ist, werden typischerweise störungsanfällige Ereignisse wie Shell-Startskripte (Ausführung der .bashrc-Datei), Shell-Vervollständigungshilfen und durch integrierte Befehle verursachte Forks sichtbar. Dies ist von entscheidender Bedeutung für die Erkennung von Persistenzmechanismen, die in Profilskripten versteckt sind.

Visuelle Kennzeichnung und Indikatoren

Die Benutzeroberfläche verwendet ein ausgeklügeltes System von Symbolen und Badges, um sofortigen Kontext zu liefern, ohne dass der Analyst jeden einzelnen Knotenpunkt aufsuchen muss. Diese visuellen Hinweise sind für eine schnelle Triage unerlässlich.

Visuelle Indikatoren im Elastic Session Viewer

Terminalausgabeansicht

Wenn man mit dem Mauszeiger über die Schaltfläche „Terminalausgabe“ eines Prozessknotens fährt, wird ein Symbol angezeigt, das die Größe der erfassten Ausgabe angibt. Durch Klicken auf diese Schaltfläche wird die Terminalausgabeansicht geöffnet, in der die process.io.text-Daten angezeigt werden. Dies ist der entscheidende Beweis bei Linux-Untersuchungen.

• Wiedergabefunktion: Sie ermöglicht es dem Analysten, genau das zu sehen, was der Benutzer gesehen hat. Wenn ein Angreifer den Befehl cat /etc/passwd ausführt, zeigt der Prozessbaum die Ausführung an; die Terminalausgabe zeigt den Inhalt der Datei passwd so an, wie er dem Angreifer angezeigt wurde.
• Eingaberekonstruktion: Da der Viewer die TTY-Ein-/Ausgabe erfasst, erfasst er nicht nur die Befehlsausführung, sondern auch die Eingabe. Dadurch können Rücktaste-Eingaben, Tippfehler und Korrekturen (z. B. die Eingabe von sdo [Rücktaste] sudo) aufgedeckt werden, die starke Verhaltensindikatoren für einen menschlichen Angreifer und nicht für ein automatisiertes Skript darstellen.

Der elastische Vorteil: KI-gestützte automatisierte Jagd

Der in Phase 3 beschriebene Prozess ist ein Beispiel für eine leistungsstarke, analysegesteuerte Untersuchung. Der Hauptvorteil von Elastic Cloud Hosted (ECH) oder Elastic Serverless besteht jedoch im programmatischen Zugriff auf einen integrierten Generative AI-Stack. Dieser Stack hebt den Prozess von der manuellen Korrelation auf die KI-gesteuerte automatisierte Suche.

Hinweis: Die KI-Funktionen von Elastic funktionieren sowohl mit den standardmäßig verfügbaren Elastic Managed LLMs als auch mit LLMs von Drittanbietern, die mithilfe eines der verfügbaren Konnektoren konfiguriert wurden.

7.1 Von Warnmeldungen zu Angriffen: Automatisierte Korrelation mit der Angriffserkennung

Die GOAD + XZbot-Labore werden mehrere separate Warnmeldungen generieren, wie in der obigen Tabelle dargestellt. Ein junger Analyst würde mit einer Reihe von Warnmeldungen konfrontiert: Mögliches Kerberoasting, Verdächtige Zertifikatsanforderung und Mögliche XZBackdoor und müsste diesen komplexen, domänenübergreifenden Angriff manuell "zusammenfügen".

Dieses Problem wird durch Attack Discovery gelöst. Diese GenAI-Funktion, die in den Enterprise- und Serverless-Tarifen verfügbar ist, „ermöglicht eine vollautomatisierte Bedrohungssuche in großem Umfang“. Die KI analysiert jede Warnung, um versteckte Bedrohungen aufzudecken, und korreliert automatisch die unterschiedlichen Signale aus dem Ludus-Labor zu einer einzigen, hochpräzisen „Angriffs“-Untersuchung.

Der Hauptnutzen der Angriffserkennung für einen forensischen Analysten liegt in der Zeitersparnis. Es automatisiert die "mentale Verknüpfung", die die Analyse der ersten und zweiten Ebene definiert.

Dekonstruktion des „mentalen Zusammennähens“

Betrachten wir eine Beispieluntersuchung ohne Angriffserkennung.

1. Auslöser: Sie sehen eine Warnung: „Verdächtige PowerShell-Ausführung“.
2. Anfrage: Sie wechseln zur Host-Timeline.
3. Scan: Sie scrollen 15 Minuten zurück. Sie sehen ein „Datei-Download“-Ereignis.
4. Hypothese: „Möglicherweise hat der Benutzer eine fehlerhafte Datei heruntergeladen, die PowerShell gestartet hat.“
5. Überprüfung: Sie überprüfen den Dateinamen. Es handelt sich um invoice.js.
6. Fazit: „Bestätigter Malware-Download.“

Dieser Prozess dauert je nach Können und Vertrautheit des Analysten mit der Umgebung zwischen 10 und 30 Minuten. Attack Discovery führt diese gesamte Sequenz in Sekundenschnelle aus. Es prüft die PowerShell-Warnung, erkennt das Dateidownload-Ereignis im zugehörigen Kontext und zeigt eine Meldung an, die besagt: „Benutzer hat ein verdächtiges PowerShell-Skript ausgeführt, das wahrscheinlich aus der heruntergeladenen Datei 'invoice.js' stammt.“

Diese Funktion umfasst die Datenpersistenz (Ergebnisse werden zur Nachverfolgung gespeichert) und die Planung und Aktionen (sie läuft automatisch und kann Reaktionen oder nachfolgende Elastic Workflows auslösen), wodurch das SOC von einer reaktiven zu einer proaktiven Haltung übergeht.

Beispiel

In unserem Beispiel werden mit dem Auftreten des Angriffs Warnmeldungen angezeigt. Anstatt die Warnmeldungen einzeln zu priorisieren, nutzen wir Attack Discovery zur Priorisierung.
Die mittlere Zeit bis zur Triage wird auf Sekunden verkürzt, und die 2 -Angriffe werden schnell identifiziert.

7.2 Beschleunigung der Triage mit dem KI-Assistenten

Der Elastic Security Assistant nutzt generative KI, um Ihnen beim Auffinden, Beheben und Verstehen von Sicherheitsbedrohungen zu helfen. Es funktioniert direkt innerhalb von Elastic Security. Die Interaktion erfolgt über eine Chat-Oberfläche, um Warnmeldungen zu untersuchen und Code zu schreiben.

Sobald Attack Discovery in unserem Beispiel einen korrelierten Angriff identifiziert hat, verwenden wir den KI-Assistenten zur Untersuchung. Der Assistent bietet zwei Hauptfunktionen:

1. Untersuchungen in natürlicher Sprache: Der Analyst kann Fragen in einfacher Sprache stellen wie: „Fassen Sie diesen Angriff zusammen“ oder „Welche MITRE-Taktik wendet man bei diesem Prozess an?“. „Was ist der Druckspooler?“ oder „Geben Sie einige Lösungsvorschläge.“

2. Agentischer Query-Validierungs-Workflow: Diese fortschrittliche Funktion ermöglicht es der KI , „maßgeschneiderte, validierte ES|QL-Abfragen zu generieren“. Ein Analyst kann beispielsweise fragen: „Finde alle Netzwerkverbindungen des Hosts, der an der XZbot-Warnung beteiligt ist.“ Der Assistent erstellt, validiert und korrigiert die Abfrage selbstständig , bevor er sie anzeigt. Dadurch wird der Einstieg in die anspruchsvolle Bedrohungsanalyse deutlich vereinfacht.
   

Funktionsweise

Der Assistent verbindet Ihren Elastic Stack mit einem LLM Ihrer Wahl (z. B. GPT-5, Claude, Gemini). Es verwendet Retrieval Augmented Generation (RAG), um relevante Daten – Protokolle, Warnmeldungen und interne Dokumentation – aus Ihrer Umgebung abzurufen. Sie können es so konfigurieren, dass sensible Felder (personenbezogene Daten oder Host-/IP-Metadaten) anonymisiert werden, bevor die Eingabeaufforderung an das Modell gesendet wird. Dadurch wird sichergestellt, dass Ihre Daten privat bleiben, während das Modell die Verhaltensmuster analysiert.

7.3 Intelligente Automatisierung mit elastischen Arbeitsabläufen

Die oben beschriebenen Angriffe erzeugen komplexe, mehrstufige Warnmeldungen. Die manuelle Bearbeitung ist langsam. Elastic hat dieses Problem durch die Übernahme von Keep, einer Open-Source-AIOps- und Alarmmanagement-Plattform, gelöst. In Elastic 9.3 ist diese Technologie in der Technical Preview als Elastic Workflows direkt in Kibana integriert.

Was sind Workflows?

Elastic Workflows ist eine in die Elasticsearch-Plattform integrierte Automatisierungs-Engine. Sie definieren Workflows in YAML – was sie auslöst, welche Schritte sie durchführen, welche Aktionen sie ausführen – und die Plattform kümmert sich um die Ausführung. Ein Workflow kann Ihre Umgebung abfragen, Sicherheitsdaten transformieren und anreichern, basierend auf Bedingungen verzweigen, externe APIs aufrufen und sich über bereits konfigurierte Konnektoren in Dienste wie Slack, Jira, PagerDuty und mehr integrieren. Workflows können auch KI-Agenten aufrufen, um komplexe Untersuchungen durchzuführen und anschließend auf Grundlage der Erkenntnisse des Agenten mit entsprechenden Maßnahmen fortzufahren. Elastic Workflows kombiniert skriptbasierte Automatisierung mit KI-gestützter Argumentation nativ in Ihrem SIEM-System, wo sich Ihre Sicherheitsdaten bereits befinden.

So funktioniert es: Der „Alert Aggregator & Workflow Engine“

Workflows bilden die Middleware-Schicht zwischen Erkennung und Behebung und funktionieren über drei Hauptmechanismen:

• Multi-Source-Ingestion: Workflows gehen über Elastic hinaus. Zusätzliche Daten zur Anreicherung, Analyse oder ersten Sichtung einbeziehen.
• Workflow-as-Code (YAML): Workflows werden in YAML-Dateien definiert. Dies ermöglicht es Teams, ihre Verfahren zur Reaktion auf Sicherheitsvorfälle als Code versionieren zu können.
• Die Workflow-Engine: Wenn in Elastic (oder einem externen Tool) eine Warnung ausgelöst wird, führt die Workflow-Engine eine Reihe von Schritten aus:
  1. Anreicherung: Abfrage einer API (wie VirusTotal oder Active Directory), um Kontextinformationen hinzuzufügen.
  2. Logik: Verwendung von if/else-Anweisungen zur Bestimmung des Schweregrades.
  3. Aktion: Senden einer Slack-Nachricht, Erstellen eines Jira-Tickets oder Auslösen einer Elastic Defend-Reaktionsaktion.

Betrachten wir einen beispielhaften Alarm- und Aktionsablauf.

• Auslöser: Sie verknüpfen den Workflow mit einer bestimmten Regel, z. B. „Alarm bei Schadsoftwareerkennung“.
• Schritte: Sie definieren eine Abfolge von Aktionen.
  1. Triage (Agentic): Leiten Sie die Warnung an den KI-Assistenten weiter. Stellen Sie sich die Frage: „Wie würden wir auf die unten stehende Warnung reagieren und diese beheben?“
  2. Anreichern: Die Antwort des KI-Assistenten als Notiz an die Benachrichtigung anhängen.
  3. Antwort: Erstellen Sie einen Fall mit einem Link zur Warnmeldung.

Beispiel

In unserem Beispiel haben wir Benachrichtigungen, die unseren Workflow auslösen – Benachrichtigungsanreicherung und Fallerstellung.
Wir werden den Prozess auch direkt über die Workflows-Benutzeroberfläche auslösen, um die verschiedenen Schritte zu demonstrieren.

• Der Alarmkontext wird als Eingabe für den Sicherheits-KI-Assistenten bereitgestellt.
• Die Antwort wird als Hinweis zu den Sicherheitswarnungen hinzugefügt.
• Es wird ein Fall mit Metadaten aus der Warnung erstellt (Zeitstempel, Schweregrad, Regelname und Warnungsgrund).
• Dem Fall wird als Kommentar ein Link zu diesem Fall hinzugefügt. Hinweis: Dies wird im GIF nicht angezeigt.

Fazit: Von der manuellen Einrichtung zur kontinuierlichen Emulation

Dieser Blog hat einen vollständigen Entwurf für einen fortschrittlichen, skalierbaren und vor allem sicheren Simulationsbereich geliefert.

1. Wir haben Folgendes aufgebaut: Ein komplexer Multi-Lab-Bereich (GOAD + XZbot) wurde mit einem einzigen Befehl über Ludus in Betrieb genommen.
2. Wir haben die gesamte Produktpalette nahtlos mit Elastic Agent und Defend im Rahmen der automatisierten Bereitstellung mithilfe der Ansible-Rolle ludus_elastic_agent instrumentiert.
3. Wir haben Folgendes erreicht: Der kritische Konflikt zwischen Malware-Isolation und Cloud-Agent-Konnektivität wurde mithilfe der granularen „OPSEC“-Netzwerkkontrollen von Ludus gelöst.
4. Wir haben es validiert: Die Leistungsfähigkeit der SIEM-Funktionen der Plattform wurde durch die Validierung der vorkonfigurierten, sofort einsatzbereiten Erkennungsregeln von Elastic gegen bekannte, schädliche Angriffe unter Beweis gestellt.
5. Wir haben Folgendes untersucht: Mithilfe der spezialisierten Untersuchungswerkzeuge Event Analyzer und Session Viewer wurden die genauen Angriffspfade sowohl auf Windows- als auch auf Linux-Hosts nachverfolgt.
6. Wir haben automatisiert: Der „Kraftverstärker“ des GenAI-Stacks von Elastic wurde demonstriert, wobei Attack Discovery automatisch unterschiedliche Warnmeldungen zu einem einzigen Angriff korrelierte und der KI-Assistent die abschließende Untersuchung beschleunigte.
7. Unsere Antwort: Die Leistungsfähigkeit von Elastic Workflows bietet das Gehirn und die Automatisierung für komplexe Reaktionsmaßnahmen und Abläufe zur Behebung von Mängeln.

Diese Architektur ist kein Einzelfall. Es handelt sich um einen Entwurf für eine kontinuierliche Erkennungs-Engineering-Pipeline. Es "modernisiert die Sicherheitsoperationen", indem es Purple Teams in die Lage versetzt, ihre Verteidigungssysteme nach Bedarf abzubauen, neu aufzubauen und erneut zu testen, wodurch sichergestellt wird, dass sich ihre Erkennungsstrategie genauso schnell weiterentwickelt wie die Bedrohungen.

Gehen Sie den nächsten Schritt: Aktivieren Sie Ihr Sicherheitsteam

Die in diesem Blog vorgestellte Architektur ist mehr als eine technische Übung; sie ist ein Entwurf für die kontinuierliche Sicherheitsvalidierung. Durch die Kombination dieses automatisierten Bereichs mit der einheitlichen SIEM- und XDR-Plattform von Elastic können Sie von periodischen Tests zu einem Zustand ständiger Bereitschaft übergehen.

Wir laden Sie ein, Ihre eigene Testphase zu starten, diesen Leitfaden zu nutzen, um die Plattform anhand realer Bedrohungen zu testen und zu bewerten, und Ihrem Sicherheitsteam die Werkzeuge an die Hand zu geben, um dem Angreifer immer einen Schritt voraus zu sein.

Nutzen Sie ein anderes SIEM-System?

Kein Problem. Sie können Elastic Serverless nutzen und Ihr bestehendes SIEM erweitern, um dann alle oben genannten Erkenntnisse zu gewinnen, während Sie die zugrunde liegenden Daten Ihres nativen SIEM verwenden. Starten Sie noch heute mit einer Elastic Serverless-Bereitstellung. Das Elastic AI SOC Engine (EASE) -Paket stellt diese KI-gestützten Funktionen bereit und ermöglicht es Unternehmen, vor der vollständigen Migration schnell leistungsstarke Analysetools und eine KI-Ebene auf ihre bestehenden Tools aufzusetzen.

Anhang

Beispiel Volles Sortiment

Hinweis: Das Kali VM VLAN befindet sich außerhalb der GOAD- und XZ-Backdoor-Hosts, um ein segmentiertes Netzwerk oder einen entfernten Angreifer zu simulieren. Das Kali VM VLAN kann auf 10/20 geändert werden, um Szenarien eines „angenommenen Sicherheitsverstoßes“ oder eines internen Angriffs zu simulieren.

global_role_vars:
  ludus_elastic_fleet_server: "https://<fleet_domain>:<fleet_port>" #443 by default for cloud   ## Note on prem fleet server defaults to 8220
  ludus_elastic_agent_version: "9.2.1"
ludus:
  - vm_name: "{{ range_id }}-GOAD-DC01"
    hostname: "{{ range_id }}-DC01"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 10
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:           # Any values in this array will be added to DNS for the range and return an A record for this VM's IP
      - sevenkingdoms.local
      - kingslanding.sevenkingdoms.local
      - kingslanding
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-DC02"
    hostname: "{{ range_id }}-DC02"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 11
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - winterfell.north.sevenkingdoms.local
      - north.sevenkingdoms.local
      - winterfell
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-DC03"
    hostname: "{{ range_id }}-DC03"
    template: win2016-server-x64-template
    vlan: 10
    ip_last_octet: 12
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - essos.local
      - meereen.essos.local
      - meereen
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-SRV02"
    hostname: "{{ range_id }}-SRV02"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 22
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - castelblack.north.sevenkingdoms.local
      - castelblack
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-SRV03"
    hostname: "{{ range_id }}-SRV03"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 23
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - braavos.essos.local
      - braavos
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<your_enrollment>"
  - vm_name: "{{ range_id }}-xz-backdoor-dect"
    hostname: "{{ range_id }}-xz-backdoor-dect"
    template: debian-12-x64-server-template
    vlan: 20
    ip_last_octet: 1
    ram_gb: 2
    cpus: 2
    linux:
      packages: # You can define packages to install on Linux hosts
        - ca-certificates
        - netcat-openbsd
        - net-tools
    roles:
      - badsectorlabs.ludus_xz_backdoor
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_xz_backdoor_install_xzbot: true
      ludus_xz_backdoor_install_backdoor: true
      ludus_elastic_enrollment_token: "<linux_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-kali"
    hostname: "{{ range_id }}-kali"
    template: kali-x64-desktop-template
    vlan: 50
    ip_last_octet: 99
    ram_gb: 8
    cpus: 4
    linux: true
    testing:
      snapshot: false # Snapshot this VM going into testing, and revert it coming out of testing. Default: true
      block_internet: false # Allow internet access for Kali, default is true
    roles:
      - badsectorlabs.ludus_xz_backdoor
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_xz_backdoor_install_xzbot: true
      ludus_elastic_enrollment_token: "<linux_policy_enrollment_token>"

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.