No Agent, No Problem: Discovering Remote EDR

No Agent, No Problem: Discovering Remote EDR

Speakers: Jonathan Johnson, Principal Windows Product Researcher, Huntress

Conference: SAINTCON

YouTube: https://www.youtube.com/watch?v=x5GeJWfcKqs

Overview

In the SAINTCON talk "No Agent, No Problem: Discovering Remote EDR," Jonathan Johnson, a Principal Windows Product Researcher at Huntress, unveiled groundbreaking research demonstrating the capability to build a fully functional, agentless Endpoint Detection and Response (EDR) solution leveraging only built-in Windows features. The presentation meticulously details how Event Tracing for Windows (ETW), in conjunction with the Performance Logs and Alerts (PLA) protocol and its underlying DCOM interfaces, can be manipulated to remotely enumerate, create, and control ETW trace sessions across a network. This innovative approach challenges conventional EDR deployment models, offering a stealthy and resource-efficient method for telemetry collection.

Johnson's work is profoundly significant for both offensive and defensive security practitioners. For defenders, it presents a compelling case for implementing EDR capabilities in environments where traditional agent deployment is impractical, such as air-gapped networks (given SMB access), legacy systems, or resource-constrained servers. It also highlights potential blind spots in existing EDR solutions that rely solely on local agent telemetry. From an offensive perspective, understanding this mechanism allows adversaries to collect reconnaissance data, blend into target environments, and potentially hide their own activities by manipulating or creating stealthy traces. The research underscores the enduring power and often-underestimated versatility of native Windows functionalities when combined with a deep understanding of their underlying architecture.

Background

▶ Watch: Speaker intro and initial ETW research problem (0:00)

The genesis of this research stemmed from Johnson's work on his .NET tool, ETW Inspector, designed to enumerate and manage ETW components. A critical limitation he encountered was the inability to see which providers were being consumed by existing ETW trace sessions, a capability that the native Microsoft tool Logman possessed. Intrigued by this discrepancy, Johnson embarked on a reverse engineering journey, disassembling Logman with IDA Pro to uncover its secrets.

His initial analysis of Logman quickly revealed calls to CoCreateInstance, a tell-tale sign of Component Object Model (COM) instantiation. This discovery indicated that Logman wasn't merely interacting with simple Win32 APIs but delving into a more complex, object-oriented framework. Further investigation led him to an intriguing COM interface: IDataCollectorSet. This interface, he observed, offered methods not only for enumeration but also for setting, adding, and removing data collector objects. What truly piqued his interest, however, were the Query and Commit methods within IDataCollectorSet, which included a server parameter. This parameter immediately signaled that the interface was a Distributed Component Object Model (DCOM) interface, meaning it could instantiate and interact with objects remotely across machines. This was a pivotal realization, as it suggested the historical limitation of local-only ETW trace sessions might be circumventable.

This revelation led Johnson to the Performance Logs and Alerts (PLA) protocol, a collection of DCOM interfaces upon which IDataCollectorSet is the primary interface for development. A Data Collector Set emerged as the central entity within PLA. It functions as a comprehensive configuration container, defining where a data collector object runs (the host), where logs are written, its execution schedule, the credentials under which it operates, and, crucially, which specific data collectors it employs. Johnson identified five distinct data collector types, each backed by its own interface, all deriving from the base IDataCollector interface. Of particular interest were the ITraceDataCollector for interacting with ETW trace sessions and the IConfigurationDataCollector, which surprisingly allowed for pulling files, querying the registry, and running WMI commands remotely. While the APITraceDataCollector seemed promising, it was found to be non-functional on Windows 10 and later versions.

To fully grasp the implications, Johnson provided a concise primer on Event Tracing for Windows (ETW). ETW is a high-performance, low-overhead telemetry mechanism built into Windows, used for logging activity from both user-mode and kernel-mode components. Originally designed for debugging, it has evolved into a critical component for security monitoring, with many modern EDRs leveraging it as a primary data source. ETW operates through four core components:

1. Provider: The application or system component that emits events, adhering to a defined schema (e.g., .NET Runtime, Threat Intelligence ETW Provider).
2. Event Trace Session: Records events from providers and stores them in a buffer.
3. Consumer: An application that takes these events and processes them.
4. Controller: An application that manages trace sessions (starts, stops, modifies configurations).

ETW trace sessions themselves come in different types:

• Trace Log: Events are written from a trace buffer to a binary log file (.ETL). This is the default for tools like Logman.
• Real Time: Events are delivered directly to a trace consumer in real time, common for EDRs.
• Buffered: Events are retained in buffers but not written to a file or delivered directly, making them inaccessible for remote collection.

Johnson's initial focus, driven by the need for remote collection, gravitated towards the Trace Log type, with the challenge of making it near real-time.

Key Findings

▶ Watch: Realizing DCOM allows remote object instantiation (4:00)

Johnson’s deep dive into PLA and DCOM yielded several critical findings that collectively enable the concept of a remote, agentless EDR:

1. Remote ETW Trace Enumeration: The IDataCollectorSetCollection::GetDataCollectorSets method, when invoked with the server parameter, successfully enumerates ETW trace sessions on remote machines. This was a significant breakthrough, proving that the DCOM interfaces could indeed bridge the local-remote gap for ETW.

1. Namespace-Based "Hiding" of Traces: A crucial discovery related to enumeration was Logman's default behavior. While Logman could enumerate trace sessions, it primarily queried the "session" namespace. Johnson found that Data Collector Sets created via PLA interfaces often resided in the "service" namespace. This meant that traces created through these DCOM interfaces were effectively "hidden" from standard Logman queries unless explicitly specified. This insight allowed Johnson to enhance his ETW Inspector tool to query all namespaces, providing a more comprehensive view of active traces than Logman could offer by default.

1. Remote ETW Trace Creation and Control: Beyond enumeration, Johnson uncovered that the IDataCollectorSet::Commit method, also supporting the server parameter, allowed for the remote creation, modification, starting, and stopping of Data Collector Sets. This was the most impactful finding, demonstrating full programmatic control over remote ETW sessions. This meant an attacker or defender could initiate new ETW traces on a target machine without any local agent.

1. Leveraging XML Templates for Configuration: Manually configuring complex ETW trace sessions through numerous COM interface methods proved tedious. Johnson realized that Perfmon, a native Windows tool built on top of PLA, could export Data Collector Set configurations as XML files. This provided an elegant solution: create a desired trace configuration in Perfmon, export its XML, then modify and use this XML template with IDataCollectorSet::SetXml and IDataCollectorSet::Commit to deploy traces dynamically and remotely. This drastically simplified the process of setting up complex trace configurations.

1. Privilege Requirements: For remote creation and control, administrative privileges on the target machine were required. While Microsoft documentation suggested that users in the "Performance Log Users" group might have sufficient permissions to schedule data collector types locally and remotely, Johnson's testing consistently resulted in "Access Denied" errors. Ultimately, an administrator account was necessary for successful remote operations, aligning with the privilege requirements for creating local ETW sessions via Logman.

These findings collectively established the technical feasibility of Johnson's "no agent, no problem" premise, laying the groundwork for sophisticated remote telemetry collection.

Technical Deep Dive

▶ Watch: Understanding Performance Logs and Alerts (PLA) (4:40)

The core technical innovation lies in the exploitation of DCOM (Distributed Component Object Model) interfaces within the Performance Logs and Alerts (PLA) protocol. DCOM extends COM to support objects distributed across networked machines, enabling remote procedure calls and object instantiation. Johnson's research hinges on the IDataCollectorSet interface, which acts as the primary programmatic entry point for interacting with PLA.

A Data Collector Set is a logical container that orchestrates various Data Collectors. These collectors are specific types of monitoring agents, each with a dedicated interface:

• ITraceDataCollector: This is the most relevant interface for ETW. It allows for the configuration and management of ETW trace sessions, including specifying providers, session names, session types (e.g., Trace Log, Real Time), buffer sizes, and flush timers.
• IConfigurationDataCollector: This versatile interface enables the collection of configuration data. It can query registry values, execute WMI queries, and, notably, transfer files from the remote machine to the local machine over SMB. While not directly for ETW, its remote capabilities significantly enhance the reconnaissance and data exfiltration potential of this method.
• APITraceDataCollector: Designed for API call tracing, this interface was found to be deprecated or non-functional on Windows 10 and newer, limiting its utility.

The process for remote ETW trace creation and management involves several key steps:

1. Configuration Template Generation: Instead of programmatically building complex ITraceDataCollector configurations through numerous COM method calls, Johnson leveraged Perfmon. Perfmon, being built on PLA, can define elaborate Data Collector Sets, including multiple ETW providers, logging options, and schedules. Crucially, Perfmon allows exporting these configurations as an XML template. This XML encapsulates all the necessary parameters for the IDataCollectorSet.

1. XML-Based Remote Deployment: The exported XML template serves as the foundation. The IDataCollectorSet::SetXml method accepts this XML string, parsing it to configure the Data Collector Set object. Dynamic elements, such as the output log file path, session name, and flush timer, can be programmatically modified either within the XML string before passing it to SetXml or by invoking specific IDataCollectorSet methods after SetXml but before Commit.

1. Remote Commitment and Control: The IDataCollectorSet::Commit method is the lynchpin for remote deployment. It takes a server parameter, allowing the specified Data Collector Set configuration (derived from the XML and any subsequent modifications) to be committed to the remote machine. Once committed, the trace session can be started and stopped using methods like IDataCollectorSet::Start and IDataCollectorSet::Stop, again with the server parameter.

1. Near Real-Time Collection with Trace Log: To achieve near real-time telemetry, Johnson ingeniously combined the Trace Log session type with specific configurations:

• Flush Timer: The ITraceDataCollector interface allows setting a flush timer. By configuring this to a low interval (e.g., 1-2 seconds), the ETW buffer is frequently flushed to the .ETL log file on the remote machine.
• Circular Logging: Using a circular log file prevents the log from growing indefinitely. Once the maximum size is reached, new events overwrite the oldest ones. This ensures continuous logging without exhausting disk space.
• SMB Transfer: The flushed .ETL files are then transferred from the remote machine to the local machine (the "EDR" host) over SMB (Server Message Block). This requires appropriate network access and administrative privileges for file sharing.

1. Parsing and Analysis: Once transferred, the .ETL files are parsed locally. Johnson's Johnmon Light tool includes functionality to read and interpret these events, effectively streaming them to a local display (e.g., Event Viewer) for analysis.

The "hiding" aspect observed with Logman stems from its default query behavior. Logman query typically targets the "session" namespace, whereas Data Collector Sets created via PLA interfaces often reside in the "service" namespace. This means a standard Logman query would not reveal these traces, providing a degree of operational stealth. Johnson's enhanced ETW Inspector tool, by querying all namespaces, overcomes this limitation, offering a more complete picture of active ETW sessions.

In essence, this technical architecture transforms the remote machine into a temporary, self-configuring ETW logger, pushing its telemetry back to the central monitoring station without requiring any pre-installed agent software.

Demo / Proof of Concept

▶ Watch: Data Collector Set: PLA's primary configuration entity (5:20)

Jonathan Johnson demonstrated the practical application of his research through a custom tool named Johnmon Light. This tool embodies the principles of remote, agentless EDR by orchestrating the creation and management of ETW trace sessions on target machines from a central console.

The demonstration showcased Johnmon Light running on a "W Server," acting as the central EDR station. This server was configured to target two remote hosts, "Asgard" and "Wakanda." The Johnmon Light utility takes a configuration file (JSON) as input. This configuration file dynamically specifies:

• The path to the base XML template for the Data Collector Set (typically generated via Perfmon).
• The desired path for the .ETL log file on the remote machine.
• The root path for log storage.
• The administrative credentials required for remote interaction.
• A list of target workstation names (e.g., Asgard, Wakanda).

Upon execution, Johnmon Light initiates the remote trace sessions on the specified hosts. The video demonstration clearly illustrated the process: after starting Johnmon Light, the tool successfully established trace sessions on the remote machines. Crucially, the events collected by these remote traces were then streamed back to the "W Server" and displayed in its local Event Viewer in near real-time. The events shown included process creation events (specifically mentioning DPI, likely for process information), and other valuable telemetry.

To further illustrate the detection capabilities, Johnson presented several compelling examples of Johnmon Light in action:

1. Detecting Malicious .NET Activity: On one remote machine, the adversary simulated running Rubious (a popular Kerberos attack tool) to execute a Kerberos command. Johnmon Light, consuming events from the .NET ETW provider on the remote machine, successfully captured and displayed this activity on the central server. This highlights the ability to detect sophisticated attacks that might otherwise be missed without an agent.
2. Monitoring WMI Persistence: The tool was shown to detect the creation of WMI event subscription consumers. This is a common technique for persistence, and Johnmon Light's ability to pull this telemetry remotely offers critical visibility into potential backdoor mechanisms.
3. RPC Call Monitoring (DCsync): A particularly advanced detection demonstrated was the ability to monitor RPC (Remote Procedure Call) events. Specifically, Johnmon Light captured events related to the MSDRSR interface and the GetNCChanges method string. This corresponds to the DCsync attack, where an attacker requests domain controller replication data. Detecting this remotely, without an agent, is a significant win for threat detection.

The architectural flow of Johnmon Light can be summarized as:

• It takes an XML trace provider template and a JSON configuration.
• It creates Data Collector Sets on the specified remote machines.
• It establishes the ETW trace sessions, configured for Trace Log type with a short flush timer and circular logging.
• It continuously transfers the flushed .ETL files via SMB.
• It then streams and parses these events, displaying them in the local Event Viewer for analysis.

Johnson emphasized that while Johnmon Light is a proof-of-concept, it showcases the immense potential for building robust remote security solutions. It can gather telemetry from virtually any ETW provider, limited only by privilege requirements (e.g., kernel-mode providers requiring Protected Process Light (PPL), which would still necessitate a local agent with PPL access). The demo conclusively proved that a rich array of security-relevant events—such as process creation, file operations, registry changes, .NET activity, and critical RPC calls—can be collected from remote endpoints without deploying any software agent, offering a powerful new paradigm for EDR.

Defensive Implications

▶ Watch: Uncovering powerful remote data collector capabilities (6:50)

The research presented by Jonathan Johnson has profound implications for defensive security strategies, particularly in challenging environments. The ability to deploy a remote, agentless EDR offers several advantages and necessitates new considerations for defenders:

1. Agentless EDR for Specialized Environments: This approach is invaluable for environments where traditional EDR agent deployment is difficult or impossible. This includes:

• Air-gapped networks: If SMB is available for log transfer, telemetry can be collected without introducing new software.
• Legacy systems: Older operating systems or critical infrastructure that cannot support modern EDR agents.
• Resource-constrained servers: ETW is a high-performance, low-overhead mechanism, making it suitable for servers where CPU and memory usage must be minimized.
• Cloud environments: For ephemeral instances or specific server roles where agent installation is cumbersome.

1. Enhanced Threat Detection and Visibility: By leveraging built-in ETW providers, defenders can gain deep visibility into a wide range of activities:

• Process Creation: Monitor for suspicious executable launches, unusual parent-child relationships.
• File and Registry Operations: Detect unauthorized modifications, malware drops, and persistence mechanisms.
• .NET Activity: Crucial for identifying attacks leveraging .NET frameworks, such as Rubious for Kerberos attacks.
• WMI Event Subscriptions: A key indicator of persistence and lateral movement.
• RPC Events: Detect highly sensitive actions like DCsync attacks, which signal domain compromise.

This method allows for the collection of telemetry that might otherwise be overlooked by traditional log collection methods (like Windows Event Logs alone).

1. Augmenting Existing Security Solutions: The data collected via remote ETW can be integrated with existing Security Information and Event Management (SIEM) systems, such as Microsoft Sentinel. Johnson demonstrated the feasibility of parsing these remote ETW events and joining them with other security logs (e.g., Windows Security Events from a Windows Event Forwarder) to create richer, more correlated detections. This provides a holistic view of security posture without requiring agents on every machine.

1. Identifying Stealthy Traces: Johnson's discovery that Logman doesn't query all ETW namespaces by default is a critical insight for defenders. Adversaries could potentially leverage PLA/DCOM to create "hidden" ETW traces for their own reconnaissance or data collection, circumventing standard Logman enumeration. Defenders should be aware of this blind spot and use tools like ETW Inspector or Johnmon Light to scan all namespaces (service, session, autologger, etc.) for unauthorized or suspicious ETW activity.

1. Hardening and Monitoring: To counter this technique, organizations should:

• Strictly manage administrative privileges: Since remote trace creation requires admin access, limiting and monitoring administrative accounts is paramount.
• Monitor DCOM activity: Unusual DCOM traffic, especially to critical servers, could indicate malicious activity.
• Secure SMB: As log files are transferred via SMB, ensuring SMB security (e.g., signing, encryption, restricted access) is essential to prevent interception or tampering.
• Baseline ETW activity: Establish a baseline of legitimate ETW traces on critical systems to more easily spot anomalies.

While the technique requires administrative privileges, its agentless nature means it can bypass EDRs that rely on specific agent processes or kernel hooks for telemetry. This makes it a powerful tool for incident response (e.g., quickly collecting forensic data from a compromised machine without installing new software) and for closing visibility gaps in complex enterprise environments. The research provides a compelling argument for a deeper understanding of native Windows telemetry sources beyond traditional event logs.

Key Takeaways

• Remote ETW is Feasible via DCOM: Windows Performance Logs and Alerts (PLA) protocol, leveraging DCOM interfaces like IDataCollectorSet, enables remote enumeration, creation, and control of ETW trace sessions without a local agent.
• Agentless EDR is a Reality: Tools like Johnmon Light demonstrate that a robust, near real-time EDR solution can be built using only built-in Windows features, providing critical telemetry from remote endpoints.
• Logman Has Blind Spots: Standard Logman queries often miss ETW traces residing in namespaces other than "session" (e.g., "service"), creating potential opportunities for "hidden" malicious traces.
• Perfmon for XML Templates: Native Perfmon can be used to easily generate XML configuration templates for complex ETW traces, simplifying the remote deployment process.
• Administrative Privileges Required: While powerful, remote ETW trace creation and control necessitate administrative privileges on the target machine.
• Dual-Use for Offensive & Defensive Security: This technique is valuable for offensive operations (reconnaissance, blending in, stealthy data collection) and highly effective for defensive purposes (agentless monitoring, threat detection, incident response, augmenting existing SIEMs).

About the Speaker(s)

Jonathan Johnson is a Principal Windows Product Researcher at Huntress, where his work focuses on enhancing their Windows EDR products. His research interests lie in the intricate world of Windows internals, reverse engineering, and the extraction of various telemetry components. Outside of his professional pursuits, Jonathan enjoys overlanding, practicing Jiu-Jitsu, and playing golf.