With the current drive of Agents being implemented at an incredible pace and autonomy, and the surge of documented rogue agentic attacks against organizations, I decided to try to see what an Agentic Swarm attack would look like in Splunk. For this purpose, I used STRT's favorite tool, the Splunk Attack Range (Modified local version). I then created an offensive agentic swarm (5) using Hermes and tested a defensive agentic framework I have been developing in my free time (Defensa Azul). I set up a Splunk Attack Range containing a Windows Domain Controller, Windows workstation, and Linux/NGINX server.

For this lab, I collected the following telemetry

The following is the lab environment network breakdown by sever roles (targets) and respective agentic attack flow, identity, objective and specific tasks.

Agent 01: Reconnaissance

Agent 02: Credential Validation and Lateral Movement

Agent 03: Credential Validation and Lateral Movement

Agent 04: Ngnix Web Attack

Agent 05: Linux SSH Takeover

*Agents communicate through `shared_state: dict`, a plain Python dictionary passed to all 5 `ThreadPoolExecutor` threads

The inference engine used for Red Agentic Swarm was Claude Sonnet 5 and DeepSeekv4pro (via Hermes as orchestrator). The following are the highlights and results from the attack runs

• Attack Architecture & Scope: The red team engagements utilized coordinated multi-agent swarms (ranging from 3 to 5 concurrent agents) operating in parallel across Active Directory, Linux SSH, web applications (nginx), and network services.
• Campaign Duration: Active attack windows were highly compressed, running for ~19 seconds during bounded emulation tests and 3 minutes 47 seconds (3m 47s) for the complete 5-agent real-attack campaign.12
• Most Used MITRE ATT&CK Techniques: Brute-force credential access techniques were the most heavily utilized, led by Password Spraying (T1110.003 with 72 events) and Password Guessing (T1110.001 with 58 events), followed by Kerberos Pre-Auth Username Enumeration (T1589.002 with 26 events) and Network Service Discovery (T1046 with 18 events).1
• Attack Outcomes & Success Rate: The real 5-agent attack campaign was completely successful, achieving full Domain Admin takeover (is_domain_admin: true), cracking 3 of 4 valid domain accounts at Password101, dumping 8 NTDS account credentials via DRSUAPI DCSync, establishing lateral SMB sessions, and escalating to root on the Linux server (linux_root: true).13
• Defensive Impact: While bounded research runs used non-destructive simulated_success markers, real attack traffic successfully triggered Defensa Azul active-defense responses, which validated detections and applied temporary, automated Windows Firewall blocks against inbound SMB port 445

The Agentic Defense (Defensa Azul)

Defensa Azul is an experimental, policy-gated active-defense framework designed to detect, analyze, propose, decide, execute, and automatically roll back security responses across enterprise targets. It shifts defensive operations from passive observation to verifiable, temporary, policy-constrained endpoint containment.

Defensive Agents & Actors

Defensa Azul structures its defensive operations across 3 core LLM analyst agents, 5 pipeline decision actors, and 2 endpoint agents:

• Core LLM Analyst Agents (3 total):

  • behavior-analyst: Analyzes telemetry patterns and behavioral anomalies across heterogeneous log sources.
  • exploit-analyst: Evaluates exploit attempts, web probes, and authentication failure patterns to assess threat severity.
  • integrity-analyst: Validates hash-chain integrity (integrity.event_hash) and audit sequences for all incoming and generated defense events.

• Pipeline Decision Actors (2 additional pipeline roles):

  • response-planner: Formulates specific defensive response proposals (e.g., windows_firewall_block, increase_capture) with bounded scope, TTL, and rollback contracts.
  • safety-arbiter (Policy Gate): Acts as the strict decision gate to evaluate proposals against target enforcement policies, allowlists, and safety constraints.

• Endpoint Collection Agents (2 deployed in lab):

  • defensa-windows-agent@win-dc01 & @win-client01: Scheduled task agents on target hosts that poll the gateway for approved actions, execute host changes (e.g., PowerShell New-NetFirewallRule), and enforce automatic rollback upon TTL expiration.

Active Defense Architecture (Defensa Azul)

Defensa Azul operates through a strict 7-stage lifecycle via 5 architect layers:

• Detect: Identify suspicious activity.
• Classify: Determine type, target, and severity.
• Propose: Suggest an action, scope, and duration.
• Decide: Approve or block under policy.
• Act: Execute the approved action.
• Verify: Confirm success and check impact.
• Rollback / Close: Remove temporary controls or close the case.

Figure 04 – Defensa Azul Layers

1. Telemetry Inputs Layer:

• • Swarm Marker Bridge: Converts ground-truth research markers into defense detections.
  • Raw Splunk Bridge: Reads organic telemetry directly from Splunk (Windows Security events 4625/4776, Zeek logs, nginx logs) to emit standard defense.attack.detected events.

1. Defensa Azul Gateway Layer:

• • Central API handling event ingestion (POST /v1/events) and action queueing (GET /v1/actions).
  • Maintains hash-chained audit trails (integrity.sequence and integrity.event_hash) for tamper-evident event logging.

1. Worker and Planner Layer:

• • Uses LLM analyst agents (behavior-analyst, exploit-analyst, integrity-analyst) to evaluate detections and produce response proposals with defined TTLs and expected impacts.

1. Policy Safety Gate (safety-arbiter):

• • Verifies that targets are declared in enforce mode, required evidence IDs exist, confidence levels meet thresholds, and actions are strictly bounded to allowlisted ports/sources.

1. Windows Endpoint Agent Layer:

• • Runs as an opt-in scheduled task on target machines (-EnableBlocking).
  • Polls the gateway via outbound HTTP/HTTPS, executes approved PowerShell rules (New-NetFirewallRule), records action results (defense.action.result), and automatically cleans up rules upon expiration (defense.rollback).

The Data: Attack Outcomes and Defensive Evidence (explained through the 7 stage lifecycle)

The attack runs exercised several objective classes across Windows, Active Directory, web, and Linux targets. The expected defensive signature was activity concentrated within a short time window, spanning discovery, authentication attempts, credential validation, and attempts to gain control of systems.

Why defenders should care: these activities can appear as separate alerts in different monitoring tools. Connecting them helps defenders determine whether reconnaissance is progressing into successful access, which accounts and systems are affected, and where intervention could interrupt further compromise. Timing provides a starting point for correlation; shared source addresses, accounts, targets, and session identifiers provide stronger links.

Expected Defensive Signature

The runs were intended to produce the following related patterns:

These are expected patterns. The evidence below establishes which parts were observed and which require further validation.

Reported Attack Outcomes

The supplied attack-run statuses reported the following results. “Success” here describes the reported objective outcome; it does not mean that the telemetry listed below independently proves every outcome or that every run succeeded.

Observed Evidence and Its Interpretation

The evidence combines Windows security events, web requests, network telemetry, and Defensa Azul’s own processing records. Each source answers a different investigative question.

The listed evidence does not include Linux SSH authentication or session logs, or specific Kerberos/LDAP records. Those parts of the reported outcomes therefore need additional corroboration. Likewise, events occurring in the same run window should be linked through account, host, source, or session details before being presented as one confirmed attack sequence.

Transition to Block Mode

After several attack runs, Defensa Azul was switched to block mode. This marks the transition to evaluating active intervention alongside detection and analysis.

The relevant lifecycle remains:

For defenders, the key question becomes whether an approved action interrupted the relevant attack activity and whether its effect was verified. The block-mode results should connect the triggering evidence to the policy decision, the action taken, the observed outcome, and any rollback or closure.

Switching modes establish the configuration change. Demonstrating successful blocking requires action records and follow-up evidence showing what happened to the targeted activity.

Active Defense

The active defense mechanism was intentionally narrow. It did not try to "take over" the host, patch services, disable accounts, or quarantine entire machines. It applied short-lived Windows Firewall rules scoped to the specific observed attack path.

The active response was:

The bridge-path source became one of the most important findings. The attacker VM was `192.168.1.151`, but the domain controller often saw SMB authentication activity as coming from `192.168.1.67`, the lab host or bridge path. Defensa Azul had to defend based on the telemetry the endpoint observed, not only the network diagram expected.

Campaign timeline

Swarm Objective timeline

Windows Authentication Failures

Ngnix Path Summaries

Zeek Domain Controller Probe Evidence

Zeek SSH check

Defensa Azul (action, event types and outcomes)

Defensa Azul Active Defense

Defensa Azul was switched to block mode during the last attack runs; the blocking needed to be specific and was rolled back after the attack finished. It was never instructed to block completely. The inference agent used was ChatGPT Sol 5.5.

How Agentic Swarm Attacks Differ from Standard Attacks

Although this is a new and developing type of attack, we can certainly pinpoint differences with attacks “before” agentic swarms.

• Parallel Execution vs. Sequential Chains: Standard attack campaigns traditionally follow a linear, step-by-step kill chain (Reconnaissance → Initial Access → Discovery → Credential Access → Lateral Movement → Escalation). In contrast, the agentic swarm executes multiple objective tracks concurrently across distinct target classes (web, Windows endpoints, Active Directory, and Linux servers) within seconds.
• High Coordination Density: Rather than displaying isolated activity or human-paced pivots, an agentic swarm generates a dense, cross-domain telemetry burst originating from a unified source or coordinated campaign window.
• Pre-Coordinated Multi-Target Operations: Instead of probing one host, assessing findings, and manually deciding where to pivot next, independent agents operate in parallel threads (e.g., probing web exploit paths while simultaneously performing Kerberos username enumeration and SMB password spraying).
• Compact Attack Windows: Traditional attacks are often stretched out over hours or days to avoid detection, whereas the automated swarm compressed a full multi-stage domain compromise into under 4 minutes (3m 47s). This does mean agentic swarms can indeed emulate human-like attack patterns and also take longer time to avoid detections.
• Early Campaign Shape Visibility: Because swarm activities occur in a synchronized burst across multiple services (HTTP, DNS, LDAP, SMB, SSH), the overarching campaign signature becomes detectable early through cross-source correlation, even before individual phases achieve confirmed host compromise.