Blog Post

Detecting Remote Execution of Staged Binaries

Overview

Execution is a key tactic in the attack lifecycle with several specific techniques in use as documented in the MITRE ATT&CK framework. When it comes to detecting the execution of binaries on systems, Endpoint Detection and Response (EDR) tools get most of the focus, and for good reason. However, EDR tools are often missing or disabled from unmanaged devices or worse analysts have a hard time parsing through too many EDR alerts to find the ones that are most consequential. In this post, we describe ways to detect these remote execution events on the network.

Actions

The execution of a remote file occurs as part of almost all security incidents as a threat actor attempts to compromise remote systems. For this to be achieved, two trackable actions must occur.

  1. The attacker will copy a file to a remote system that’s capable of running a set of instructions. This file can be an exe, dll, bat, hta, cpl, vbs, etc. I will refer to these as, “executables” throughout the blog.
  2. Once the file is staged, it can be executed by either calling it directly or by setting a persistence mechanism that will carry out the execution at a predefined time or interval.

There are several ways to accomplish this but some of the more common ones include:

  • wmic process call create
  • registering a new scheduled task
  • modifying an existing scheduled task
  • creating a new service
  • modifying an existing service

Each one of these generates detectable network traffic that we will dive into in the rest of this blog.

Building a Model to Detect Remote Execution of a Staged Executable

To detect remote execution activity, we need to combine two distinct network activity models. Arista NDR has a preconstructed model filter called model.filter.differentActivityWithinTimeWindow that will allow us to accomplish this.

The purpose of this filter is to group different activities by defined parameters within a specified timeframe. For example, we might look to group activities that occur between the same source and destination systems within a 1-minute time window.

The first activity we want to identify is the transferring of an executable file via SMB.

We are only concerned with SMB “write” file operations, as this indicates a file was pushed to a remote system. We then filter these activities by a regular expression (regex) matching a set of file extensions. Arista NDR has a pre-defined list of these in recipes.files.executables.windows. Lastly, we verify that data was written, so we search for activities where the SMB bytes written value is greater than 0. The result is a model that looks like the following:

activity.smb.type == SMB_FILE_OPERATION
&& activity.smb.file.actions contains "Written"
&& activity.smb.file.name like recipes.files.executables.windows
&& activity.smb.bytes_written > 0)

Now that we have identified the file transfer activity, we build the second model to look for evidence of its remote execution.

WMIC Process Call Create and StartService

Each of these two calls will generate similar network activity. The calling interface is IWbemServices (identified by its UUID 9556dc99-828c-11cf-a37e-00aa003240c7) and one of two execution methods ExecMethod (opnum 24) or ExecMethodAsync (opnum 25) will be called. These ExecMethods execute a CIM method that is implemented by a CIM class or a CIM instance.

This allows us the ability to identify remote process execution across the network.

activity.dcerpc.call.interface.uuid == 9556dc99-828c-11cf-a37e-00aa003240c7
&& activity.dcerpc.call.opnum in [24, 25]

Register a Scheduled Task

When a Windows Scheduled Task is registered over the network it will generate the following DCERPC calling interface ITASKSCHEDULERSERVICE (UUID: 86d35949-83c9-4044-b424-db363231fd0c) and the SchRpcRegisterTask (opnum 1) method that is used to register a task with the server.

This allows us to identify lateral creation of scheduled tasks for privilege escalation and/or to achieve persistence for the threat actor.

activity.dcerpc.call.interface.uuid == 86d35949-83c9-4044-b424-db363231fd0c
&& activity.dcerpc.call.opnum == 1 /* SchRpcRegisterTask */

Windows Service Creation and Change

Newly created Windows Services created over the network generate a DCERPC calling interface IDD_SVCCTL (UUID: 367abb81-9844-35f1-ad32-98f038001003) and the opnum will be either 12, 24, 44 or 45 which are RCreateServiceW, RCreateServiceA, RCreateServiceWOW64A, and RCreateServiceWOW64W respectively.

activity.dcerpc.call.interface.uuid == 367abb81-9844-35f1-ad32-98f038001003
&& activity.dcerpc.call.opnum in [12, 24, 44, 45]

Windows Services that are changed over the network generate DCERPC calling interface IDD_SVCCTL and will be either opnum 23, 36, or 37 which are RChangeServiceConfigA, RChangeServiceConfig2A, or RChangeServiceConfig2W.

activity.dcerpc.call.interface.uuid == 367abb81-9844-35f1-ad32-98f038001003
&& activity.dcerpc.call.opnum in [23, 36, 37]

Each of these is a tactic deployed by threat actors when elevating access, setting persistence mechanisms, and/or looking to remotely execute a file, and to simply the above for model building purposes we wrap each of these into their own recipe.

recipes.protocols.dcerpc.wmi.IWbemServicesExecMethods
|| recipes.protocols.smb.itaskschedulerservice.registertask
|| recipes.protocols.smb.svcctl.createservice
|| recipes.protocols.smb.svcctl.changeservice

Lastly, we want to wrap the two queries with the model.filter.differentActivityWithinTimeWindow filter and ensure we filter on the same source device and destination IP. This means we will see a source device push a file to a remote device, and then call an operation to remotely execute a file on the same remote device, based on the remote device’s IP address. We also specify a timeframe for the two activities which will be 60 seconds in this case. This means the set of activities must have occurred within a 60-second window. This timeframe is customizable and can be set in seconds (s), minutes (m), or hours (h).

let models.execution.remoteExecutionOfStagedBinary =
model
[
(<query_1>),
(<query_2>)
]
(model.filter.differentActivityWithinTimeWindow ["device.guid", "activity.ip.destination"] 60s)

Putting all the pieces together we get a finished model that’s readable and effective.

let models.execution.remoteExecutionOfStagedBinary =
model
[
(
activity.smb.type == SMB_FILE_OPERATION
&& activity.smb.file.actions contains "Written"
&& activity.smb.file.name like recipes.files.executables.windows
&& activity.smb.bytes_written > 0
),
( recipes.protocols.dcerpc.wmi.IWbemServicesExecMethods
|| recipes.protocols.smb.itaskschedulerservice.registertask
|| recipes.protocols.smb.svcctl.createservice
|| recipes.protocols.smb.svcctl.changeservice
)
]
(model.filter.differentActivityWithinTimeWindow ["device.guid", "activity.ip.destination"] 60s)

Detections

In this example, we can see the source device writing DWRCS.exe (Dameware) to the destination system.

The transfer of this binary meets the conditions of our first model (staged binary). We then see subsequent calling interfaces towards IID_SVCCTL to interact with Microsoft’s Service Manager. The calling operations 12 (RCreateServiceW) and 37 (RChangeServiceConfig2W) are seen after the binary is pushed to the destination IP address.

RCreateServiceW is a method that’s used to create a service record in the SCM database. The output of this method is a SC_RPC_HANDLE data type that provides a handle to the newly created service record. The RChangeServiceConfig2W is then used to change the optional configuration parameters of the service. This method takes an input of SC_RPC_HANDLE.

Staged Binaries-A screenshot of a computerDescription automatically generated

Looking at another example we see the SolarWinds agent being pushed to the remote system. We then see subsequent calling interfaces towards IID_SVCCTL to interact with Microsoft’s Service Manager. The calling operations are 12 (RCreateServiceW)

Staged Binaries-A screenshot of a computerDescription automatically generated with medium confidence

Summary

Detecting tactics such as execution and persistence are key to effective incident response and containment. While EDR tools can help with this, given the abundance of unmanaged devices on the modern network, security analysts and incident responders are often blind to this activity. The network can fill this gap and as shown above, identify these activities with high fidelity.

 

Subscribe!

If you liked what you just read, subscribe to hear about our threat research and security analysis.

Patrick Olsen
Patrick Olsen

Director, Awake Labs