Beschleunigung der APT-Angriffsbestätigung durch Angriffserkennung, Workflows und Agenten-Builder

9:15 AM: Das Nicht-Ereignis - Eine Schlagzeile platzt herein: "Chrysalis Backdoor: Ein tiefer Einblick in Lotus Blossom." Ihr CISO sendet eine Slack-Nachricht: „Sind wir betroffen?“

In einem traditionellen SOC würden Sie Ihren gesamten Vormittag mit einer manuellen Hektik verbringen – Dutzende von Warnmeldungen durchforsten, Abfragen schreiben, VirusTotal manuell überprüfen und Indexmuster vergleichen, um eine Zeitleiste zu erstellen, in der Hoffnung, nichts zu übersehen.

In einem Agentic SOC ist die Arbeit jedoch bereits erledigt. Attack Discovery, das stündlich läuft, hatte bereits 5 kritische Warnmeldungen aus über 30 zu einer einzigen Angriffsgeschichte zusammengefasst: "Malware mit DLL Side-Loading Persistency". Diese Entdeckung löste automatisch einen Arbeitsablauf aus, der die Ergebnisse an einen Agenten weiterleitete. Der Agent nutzte seine Tools und verifizierte den Malware-Hash auf VirusTotal, durchsuchte Ihre Protokolle mit ES|QL, überprüfte den Bereitschaftsplan, erstellte einen Fall und richtete einen Slack-Incident-Kanal ein, in dem der diensthabende Analyst bereits hinzugefügt war, und generierte außerdem eine CISO-taugliche Zusammenfassung – all das, bevor Sie sich zum Kaffee hingesetzt hatten.

Sie antworten Ihrem CISO: "Bereits bestätigt und priorisiert." Der Fall ist noch nicht abgeschlossen. Hier ist der Link.

Dieser Beitrag erklärt, wie wir diese Pipeline aufgebaut haben: die Integration von Attack Discovery, Workflows und Agent Builder.

Die Bedrohung: Chrysalis-Hintertür durch Lotus Blossom

Bedrohungsakteurprofil

Kampagnenübersicht

Lotus Blossom hat einen Lieferkettenverstoß bei der Update-Infrastruktur von Notepad++ begangen:

• Angriffsfenster: Juni 2025 – Dezember 2025 (~6 Monate)
• Vektor: Abgekappter Aktualisierungsmechanismus von Notepad++ (WinGUp)
• Methode: Gezielte Umleitung von Zielbenutzern auf schädliche Update-Server
• Nutzlast: Bisher undokumentierte Hintertür „Chrysalis“
• Entdeckung: Rapid7 MDR-Team, veröffentlicht am 02.02.2026

Chrysalis-Hintertürfunktionen

Die Chrysalis-Hintertür ist ein ausgeklügeltes, funktionsreiches Implantat:

• Benutzerdefinierte Verschlüsselung (LCG, FNV-1a-Hashing, MurmurHash)
• Reflektierendes Laden von DLLs
• API-Hashing zur Umgehung
• DLL-Sideloading über eine legitime Bitdefender-Binärdatei (BluetoothService.exe)
• Vollständige Fernzugriffsfunktionen
• Persistente Windows-Dienstinstallation

Angriffskette

[1] INITIAL ACCESS
    └── User executes malicious NSIS installer from Desktop
              ↓
[2] EXECUTION
    └── Installer drops files to hidden AppData folder
        ├── BluetoothService.exe (legitimate binary)
        └── log.dll (malicious Chrysalis loader)
              ↓
[3] PERSISTENCE
    └── BluetoothService.exe registered as Windows service
        └── Runs under SYSTEM context
              ↓
[4] DEFENSE EVASION
    └── DLL sideloading via legitimate signed binary
              ↓
[5] COMMAND & CONTROL
    └── DNS beacon to api[.]skycloudcenter[.]com ✅ CONFIRMED

MITRE ATT&CK-Mapping

Die Herausforderung: Geschwindigkeit vs. Genauigkeit

Wenn Bedrohungsinformationen über eine APT-Kampagne eines Nationalstaats auftauchen, stehen SOC-Teams vor einem brutalen Dilemma:

Tempo: Führungskräfte wollen jetzt Antworten. Sind wir kompromittiert?

Genauigkeit: Analysten benötigen Zeit, um zu recherchieren, zu korrelieren und zu bestätigen, bevor sie eine Entscheidung treffen können.

Herkömmliche Arbeitsabläufe erfordern von Analysten Folgendes:

1. Den Umfang der Analyse und die relevanten Suchkriterien festlegen
2. Manuelle Suche nach IOCs in verschiedenen Datenquellen
3. Korrelieren Sie Warnmeldungen, die sich über Tage oder Wochen erstrecken können.
4. Ergebnisse anhand von Bedrohungsdaten validieren
5. Erstellen Sie den Angriffszeitplan
6. Eskalieren Sie mit Zuversicht

Dieser Prozess kann Stunden bis Tage dauern, in denen ein aktiver Angreifer Daten exfiltrieren oder sich seitlich ausbreiten kann.

Die Lösung: Angriffserkennung + Workflows + Agenten-Builder

Der KI-gestützte Automatisierungs-Stack von Elastic Security wandelt diesen Workflow von der manuellen Suche zur automatisierten Bestätigung um. Bevor wir uns jedoch mit dem konkreten Aufbau befassen, ist es wichtig zu verstehen, wie die einzelnen Bausteine zusammenpassen.

Agenten & Workflows: Zwei Einstiegspunkte, eine zusammensetzbare Architektur

Agent Builder bietet Ihnen zwei Grundelemente, die zusammenarbeiten:

• Agenten bilden die Aufklärungsebene. Sie überlegen sich eine Aufgabe, entscheiden, welche Hilfsmittel sie einsetzen, und passen ihre Vorgehensweise an die gefundenen Erkenntnisse an. Ein Agent kann Suchwerkzeuge, MCP-Werkzeuge und – ganz entscheidend – Workflows als Werkzeuge aufrufen.
• Arbeitsabläufe bilden die Strukturebene. Es handelt sich um deterministische Pipelines: Die Schritte werden der Reihe nach, zuverlässig und wiederholbar ausgeführt. Jeder Schritt in einem Workflow kann optional ein Agentenschritt sein, wodurch die Fähigkeit entsteht, während der Pipeline Schlussfolgerungen zu ziehen.

Die beiden sind vollständig kombinierbar. Ein Workflow kann einen Agenten aufrufen. Ein Agent kann einen Workflow aufrufen. Ein Agentenschritt innerhalb eines Workflows kann einen anderen Workflow aufrufen. Alle Verbindungen sind optional, sodass Sie sie je nach Problemstellung individuell kombinieren können.

Das ist es, was die Architektur so leistungsstark macht: Agenten argumentieren und entscheiden; Arbeitsabläufe werden ausgeführt und koordiniert. Für unser Chrysalis-Angriffsszenario haben wir beides verwendet.

Unser Flow

Der Fluss:

1. Viele Warnmeldungen → Angriffserkennung verknüpft unterschiedliche Warnmeldungen zu einer einzigen Angriffsübersicht.
2. Angriffserkennung → Generiert eine Warnung, die den Workflow auslöst.
3. Workflow → Ruft Agent Builder auf, um die Ergebnisse der Angriffserkennung zu analysieren
4. Agent Builder → Aufrufe Anreicherungs-Workflows (VirusTotal, Threat Intel, ES|QL-Abfragen)
5. Agent Builder ruft einen Workflow auf → Agent Builder fährt mit den Maßnahmen zur Reaktion auf Vorfälle fort und ruft dabei den Workflow als Werkzeug auf (Fallaktionen, Host isolieren, Team benachrichtigen)

Schritt 1: Angriffserkennung deckt die Bedrohung auf

Attack Discovery nutzt LLMs, um Sicherheitswarnungen zu analysieren und Angriffsmuster zu identifizieren. Im Gegensatz zur herkömmlichen Alarmgruppierung versteht es die semantischen Beziehungen zwischen den Alarmen.

Die Alarmwarteschlange: Die Suche nach der Nadel im Heuhaufen

So sieht die Realität für einen SOC-Analysten aus. Sie öffnen die Warnseite und sehen Dutzende von Warnmeldungen über verschiedene Hosts, Benutzer und Regeln hinweg, Kombinationen davon, unterschiedliche Schweregrade und Typen, viele davon irrelevant.

Dutzende Warnmeldungen. Mehrere Regeln werden ausgelöst. Schweregrade von niedrig bis kritisch. Einige sind der Chrysalis-Angriff. Einige davon sind unabhängige Windows Defender-Ereignisse. Einige davon sind SIEM-Änderungserkennungen aus einem völlig anderen Arbeitsablauf. Es ist schwierig, in diesem Lärmgewirr den koordinierten Angriff zu erkennen.

Was Attack Discovery herausgefunden hat

Attack Discovery analysierte alle diese Warnmeldungen und identifizierte 5 Warnmeldungen , die zu einem einzigen koordinierten Angriff gehörten – sie wurden aus dem Informationsrauschen herausgefiltert und zu einer zusammenhängenden Geschichte verknüpft:

Anstatt 5 einzelne Warnmeldungen anzuzeigen, hat Attack Discovery diese zu einer einzigen Entdeckung zusammengefasst:

Malware mit persistentem DLL-Sideloading

Schädliche ausführbare Datei auf srv-win-defend-01 eskalierte über BluetoothService.exe mit DLL-Seitenladen zu Persistenz

• Host: srv-win-defend-01
• Benutzer: james_spiteri
• Schweregrad: Kritisch
• Angriffskette: Erster Zugriff → Ausführung → Persistenz → Verteidigungsumgehung → C2

Angriffserkennung auch:

• Zuordnung von Warnmeldungen zu MITRE ATT&CK-Taktiken
• Die DLL-Sideloading-Technik wurde identifiziert.
• Der verdächtige Persistenzmechanismus wurde markiert.
• Hervorgehoben wurde der C2-Netzwerkindikator.

Schritt 2: Die geplante Erkennung löst den Workflow aus

Die Angriffserkennung erfordert keinen Klick des Analysten auf eine Schaltfläche. Wir haben es so konfiguriert, dass es stündlich läuft und kontinuierlich die neuesten Warnmeldungen zu koordinierten Angriffen analysiert.

Als unser stündlicher Lauf startete, wurden alle Warnmeldungen der letzten Stunde erfasst, einschließlich der Chrysalis-bezogenen Warnmeldungen, die zwischen den Routineerkennungen verborgen waren, und der DLL-Sideloading-Angriff wurde als Entdeckung aufgedeckt.

Die Verknüpfung eines Workflows als Aktionsschritt der Angriffserkennung bedeutet, dass jedes Mal, wenn die Angriffserkennung einen koordinierten Angriff feststellt, der Workflow automatisch ausgelöst wird.

Doch genau das unterscheidet diesen Ansatz von herkömmlichen SOAR-Playbooks: Der Workflow legt nicht jeden einzelnen Schritt detailliert fest. Es übergibt die gesamte Angriffserkennung an Agent Builder und sagt: „Finden Sie es selbst heraus.“

Workflow-Definition

Dies ist der tatsächliche Arbeitsablauf, den wir verwendet haben, bestehend aus zwei Schritten, das ist alles:

name: Auto Triage AD
description: >-
  Demonstrates the application of AI agents and workflows 
  to enable agentic alert triaging.
enabled: true
tags:
  - Example
  - Agentic Workflow

triggers:
  - type: alert                          # Fires when Attack Discovery generates an alert

steps:
  # Step 1: Hand the attack discovery to the agent with clear instructions
  - name: initial_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        agent_id: <your-agent-id>        # Your custom Hunting Agent
        input: |
          Confirm the attack by searching for behaviour in the logs 
          (all logs which are relevant), always leverage security labs tools, 
          always leverage virustotal if file hashes are available. 
          If this is a true positive, create a case with all the relevant content too.

          {{event|json}}

          Create a slack channel for this incident, check who's on call, 
          add them to it, and send a formatted message with what's happening 
          and next steps. If this is a true positive, create a case with all 
          the relevant content too - add a button to the slack message linking 
          to the case, and another button leading to the result of the attack. 
          Lastly, include a button that will take me to this agent conversation, 
          just replace the conversation ID with the actual one from this conversation 
          (https://<your-kibana-url>/app/agent_builder/conversations/<conversation-id>)

          Change the attack discovery status to acknowledged, or, 
          if false positives, close it.
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

  # Step 2: Follow up to catch anything that didn't complete
  - name: followup_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        conversation_id: "{{ steps.initial_analysis.output.conversation_id }}"
        agent_id: <your-agent-id>
        input: |
          Complete any previous steps which might not have ran successfully. 
          Just in case, the conversation ID is 
          {{ steps.initial_analysis.output.conversation_id }}
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

Warum dieser Arbeitsablauf so kurz ist

Die gesamte Automatisierung besteht aus zwei Schritten:

1. initial_analysisSenden Sie die Angriffserkennung mit natürlichsprachlichen Anweisungen, die beschreiben, was Sie tun möchten, an den Agent Builder.
2. followup_analysisEine Ausfallsicherung, die das vorherige Gespräch fortsetzt und den Agenten auffordert, zu bestätigen, dass alle Aufgaben abgeschlossen wurden. Da Agenten mehrere Tools nacheinander aufrufen und jeder einzelne Tool-Aufruf zu einem Timeout oder einem vorübergehenden Fehler führen kann, stellt dieser Schritt sicher, dass nichts übersehen wird.

Dies ist der grundlegende Wandel: Der Arbeitsablauf ist Auslöser und Sicherheitsnetz; der Agent ist das Gehirn.

Hinter den Kulissen: Wie wir den Threat Hunting Agent erweitert haben

Bevor wir zu den Ergebnissen kommen, lohnt es sich, kurz innezuhalten und zu betrachten, was dies ermöglicht hat. Eine der leistungsstärksten Funktionen von Agent Builder ist die Möglichkeit, bestehende Agenten mit zusätzlichen Tools zu erweitern . Anstatt von Grund auf neu zu entwickeln, haben wir den standardmäßigen Threat Hunting Agent genommen und ihn mit benutzerdefinierten, workflowbasierten Tools ausgestattet, um ihm die spezifischen Funktionen zu verleihen, die für dieses Szenario erforderlich sind.

Was wir hinzugefügt haben

Agent Builder wird mit integrierten Plattformtools wie platform.core.generate_esql und platform.core.product_documentation ausgeliefert. Die wahre Stärke liegt aber darin, eigene Ideen einzubringen. Wir haben den Threat Hunting Agent um Tools aus verschiedenen Kategorien erweitert:

Fünf Spezialwerkzeuge. Das war alles, was nötig war, um den standardmäßigen Hunting Agent so zu gestalten, dass er automatisch Malware überprüft, Protokolle durchsucht, den Bereitschaftsdienstmitarbeiter findet, einen Fall erstellt und einen Vorfallskanal einrichtet – all dies beschleunigt die Erkennung einer potenziellen Bedrohung.

Die Argumentationskette des Agenten

Das Bemerkenswerte daran ist: Angesichts des Angriffserkennungskontexts entschied der Agent automatisch, welche Tools aufgerufen werden sollten und in welcher Reihenfolge. Diese Schritte wurden von keinem Menschen vorgegeben.

Schritt 1: VirusTotal-Abfrage: vt.hash.lookup

• Der erste Schritt des Agenten: Überprüfung des Malware-Hashs.

Schritt 2: ES|QL-Abfrage generieren: platform.core.generate_esql

• Nachdem die Malware bestätigt worden war, suchte der Agent nach allen damit zusammenhängenden Aktivitäten.

Schritt 3: Produktdokumentation: platform.core.product_documentation

• Der Agent nutzte die Dokumentation von Elastic Security, um Behebungsbefehle für die Response Console zu generieren.

Die einzelnen Schritte der Argumentation zeigen, welche Werkzeuge in welcher Reihenfolge aufgerufen wurden, um Transparenz zu gewährleisten.

Zeigt die zusätzliche Argumentationskette: Nachschlagen in der Produktdokumentation, dann Überprüfung der Bereitschaftsdienstplaninformationen, bevor ein Fall mit allen relevanten Informationen erstellt und der diensthabende Analyst über Slack benachrichtigt wird.

Schritt 4: Aktuelle Uhrzeit prüfen: get.time

Schritt 5: Bereitschaftsplan prüfen: check.on.call.schedule

• Der Agent führte eine ES|QL-Abfrage gegen den Index on-call-schedule aus, um den aktuellen Responder zu finden:

Schritt 6: Fall erstellen: create.case

Schritt 7: Slack-Kanal erstellen: create.channel

Warum das wichtig ist

Der Agent hielt sich nicht an ein vorgegebenes Drehbuch. Es überlegte die Situation und entschied:

1. Zuerst überprüfen Sie, ob die Malware echt ist (VirusTotal).
2. Anschließend die Auswirkungen verstehen (ES|QL-Protokollsuche).
3. Anschließend muss die Vorgehensweise zur Behebung des Problems ermittelt werden (Produktdokumentation).
4. Suchen Sie dann die richtige Person, die antworten kann (Bereitschaftsdienstplan).
5. Anschließend werden Tracking-Artefakte (Fälle) erstellt.
6. Abschließend das Team koordinieren (Slack-Kanal).

Das ist der Unterschied zwischen einem Workflow (der einer festen Abfolge folgt) und einem Agenten (der darüber nachdenkt, was als Nächstes zu tun ist). Der Workflow hat den Agenten ausgelöst; den Rest hat der Agent selbst herausgefunden.

Schritt 3: Automatisierte Reaktion auf Vorfälle

Mit einer Bestätigung hoher Zuverlässigkeit läuft der Workflow automatisch ab:

1. Erstellt einen Vorfallsfall

Es wird ein strukturierter Fall erstellt, dem alle relevanten Beweismittel beigefügt sind:

• Ergebnisse der Angriffserkennung
• Ergebnisse der VirusTotal-Analyse
• Übereinstimmungen mit Bedrohungsanalysen
• Agent Builder-Analyse
• Empfohlene Reaktionsmaßnahmen

2. Benachrichtigt das SOC

Eine Slack-Nachricht wird an den richtigen Kanal gesendet, um die Analysten über den kritischen Vorfall zu informieren.

3. Aktiviert Reaktionsaktionen

Der Workflow kann optional automatisierte Reaktionsaktionen auslösen:

• Host-Isolation: Isolieren Sie srv-win-defend-01 über Elastic Defend
• Benutzersperre: Deaktivieren Sie james_spiteri in Active Directory
• Netzwerkblockade: C2-Domäne zur Firewall-Sperrliste hinzufügen
• IOC-Sweep: Flottenweite Suche nach Chrysalis-Indikatoren starten

---

Zeit bis zur Bestätigung: Vorher und nachher

---

Die andere Möglichkeit: Fragen Sie einfach den Agenten.

Alles oben Beschriebene ist die automatisierte Pipeline – Attack Discovery findet die Bedrohung, der Workflow wird ausgelöst, der Agent priorisiert sie und der/die richtige(n) Analyst(en) wird/werden benachrichtigt.

Es gibt aber noch eine andere, ebenso wirkungsvolle Möglichkeit: Gehen Sie direkt zum Agent Builder und stellen Sie Ihre Frage in einfachem Englisch.

Szenario: Sie lesen zuerst von der Bedrohung.

Stellen Sie sich vor, Sie scrollen durch Ihre Threat-Intelligence-Feeds und sehen den Blogbeitrag von Rapid7 über die Chrysalis-Backdoor. Sie wollen einfach nur wissen: Sind wir kompromittiert?

Das war’s. Derselbe Agent erledigt mit denselben Werkzeugen den Rest:

1. Liest den Bedrohungsbericht mithilfe des Tools web.search , um IOCs und TTPs aus dem Rapid7-Blog zu extrahieren.
2. Generiert ES|QL-Abfragen, um in Ihren Datei-, Netzwerk- und Prozessereignisprotokollen nach Chrysalis-Indikatoren zu suchen.
3. Überprüft VirusTotal auf übereinstimmende Dateihashes in Ihrer Umgebung
4. Erstellt eine CISO-gerechte Zusammenfassung mit Ergebnissen, Konfidenzniveau und Handlungsempfehlungen.

Der Agent ruft dieselben Tools auf wie in der automatisierten Pipeline. Der Unterschied liegt im Einstiegspunkt: Anstatt dass eine geplante Angriffserkennung einen Workflow auslöst, haben Sie den Agenten mit einer Frage ausgelöst.

Warum dies die Spielregeln für Analysten verändert

Dies ist der Teil, der leicht zu übersehen, aber von grundlegender Bedeutung ist: Der Analyst musste weder eine einzige Abfragesprache, noch ein Indexmuster oder einen Toolnamen kennen.

Sie haben ES|QL nicht geschrieben. Sie mussten sich nicht merken, wo ihre verschiedenen Daten gespeichert sind. Sie mussten sich weder die VirusTotal-API-Syntax merken noch herausfinden, welchen Threat-Intelligence-Index sie abfragen sollten.

Sie stellten eine Frage in natürlicher Sprache. Der Agent ermittelte den Rest, einschließlich der zu durchsuchenden Indizes, der zu schreibenden Abfragen, der aufzurufenden Tools und der Synthese der Ergebnisse.

Für einen Nachwuchsanalysten, der erst letzten Monat zum Team gestoßen ist, ist das eine bahnbrechende Erfahrung. Für einen erfahrenen Analysten, der diese Tätigkeit seit einem Jahrzehnt ausübt, bedeutet das eine Rückgewinnung von Stunden seines Lebens. Für einen CISO, der einen Statusbericht wünscht, ist die Antwort nur eine Frage entfernt.

Die Hürde für eine effektive Bedrohungsanalyse ist von „Kenntnis von ES|QL- und 47 -Indexmustern“ auf „Kann beschreiben, wonach sie suchen“ gesunken.

Wichtigste Erkenntnisse

1. Die Angriffserkennung nach Zeitplan bedeutet, dass Ihnen keine Angriffe entgehen – sie analysiert kontinuierlich Ihre Warnmeldungen, sodass koordinierte Bedrohungen auch dann aufgedeckt werden, wenn niemand die Warteschlange überwacht.
2. Workflows orchestrieren die Reaktion, indem sie bei Entdeckungen ausgelöst werden, Agenten aufrufen und Aktionen ausführen.
3. Mit Agent Builder können Sie Agenten nach Ihren Bedürfnissen erstellen oder erweitern – egal ob Sie von Grund auf neu beginnen oder einem bestehenden Agenten benutzerdefinierte Tools hinzufügen, Sie gestalten die Funktionen so, dass sie zu Ihrer Umgebung passen.
4. Agenten denken nach, Arbeitsabläufe werden ausgeführt – der Agent hat selbstständig entschieden, VirusTotal aufzurufen, Protokolle zu durchsuchen, den Bereitschaftsplan zu überprüfen und einen Slack-Kanal zu erstellen. Diese Abfolge wurde von keinem Menschen entworfen.
5. Zwei Einstiegspunkte, gleiche Leistungsfähigkeit – die automatisierte Pipeline und die Chat-Oberfläche nutzen denselben Agenten und dieselben Tools. Ob eine geplante Erkennung den Auslöser bildet oder ein Analyst eine Frage stellt, das Ergebnis ist dasselbe.
6. Natürliche Sprache ist die neue Abfragesprache – Analysten müssen weder ES|QL, Indexmuster noch die API-Syntax kennen. Sie beschreiben, wonach sie suchen, und der Makler kümmert sich um den Rest.

Die Chrysalis-Hintertürkampagne zeigt, warum das so wichtig ist. Wenn staatliche Akteure Ihre Lieferkette kompromittieren und sich innerhalb von 4 Sekunden dauerhaft etablieren können, benötigen Sie Abwehrmechanismen, die mit dieser Geschwindigkeit mithalten können – sei es eine automatisierte Pipeline, die im Schlaf läuft, oder ein direktes Gespräch mit einem Agenten, wenn Sie die Bedrohung als Erster entdecken.