Hunting for Lateral Movement using Event Query Language

Lateral Movement describes techniques that adversaries use to pivot through multiple systems and accounts to improve access to an environment and subsequently get closer to their objective. Adversaries might install their own remote access tools to accomplish Lateral Movement, or use stolen credentials with native network and operating system tools that may be stealthier in blending in with normal systems administration activity.

Detecting Lateral Movement behaviors often involves the design of detections at both the source and the target system, as well as the correlation of more than one type of event (such as network events with process execution events) in order to capture the remote execution context.

In this blog, we explore some examples of techniques and leverage the capabilities of Elastic’s Event Query Language (EQL) to design behavioral hunts and detections.

How Lateral Movement works

Lateral Movement is usually composed of the following high-level steps:

Remote authentication to the target host (valid access credentials are required)
Staging the command to execute to the remote host or to another resource accessible by the target host such as internet URL or a Network File Share
Remotely triggering the execution (immediate or scheduled) of the staged program on the target host via accessible remote services and protocols (Service, Task Scheduler, WinRM, WMI, Remote Registry).
Clean up the staged payload and any other relevant artifacts to avoid suspicion (optional)

Note that staging a program (step 2) is not always necessary, as there are usually exposed services that allow for remote interaction with the target host such as PowerShell Remoting and Remote Desktop (RDP).

Lateral Tool Transfer

Files may be copied from one system to another to stage adversary tools or other files over the course of an operation. A commonly abused vector is SMB/Windows Admin Shares via the use of built-in system commands such as copy, move copy-item, and others:

Figure 1: File copy via system command

From the source machine, there are alternative methods of copying the file without having to execute suspicious commands. Still, it’s important to look for low-hanging detection opportunities.

Figure 2 below shows an EQL query that looks for the following behavior that is consistent with an attacker transferring a file to a remote host:

Execution of a command interpreter with a process.args keyword array related to file copy (copy, move) and a hidden file share (prefixed by a $ sign such as c$ admin$)
Staging data from a shadow copy volume (often associated with credential access via staging of NTDS.dit or Registry SAM key to access stored account password hashes)

Figure 2: Hunting EQL for file transfer via hidden file share from source machine

On the target machine, we’ve observed that all files copied via server message block (SMB) are represented by a file creation event by the virtual process System (always has a static process.pid value equal to 4 and represents the Windows kernel code and loaded kernel mode drivers):

Figure 3: File creation event details depicted in Kibana’s Discover view as a result of file transfer over SMB

A file creation event alone is not enough (the System process may create files that are related to local activity) to conclude that this activity pertains to a Lateral Movement attempt. Thus, we need to correlate it with incoming SMB network events by the same process:

Figure 4: Hunting EQL for file transfer via hidden file share from target host

The above query looks for an incoming remote network event to tcp port 445 (SMB) followed by immediate file creation or modification (can be limited to executable file extension to reduce false positives) and both events are performed by the same (process.entity_id) virtual System process.

Figure 5: Detection alert example for Lateral Tool Transfer from target host

The above alert contains details about the file that was copied as well as the source.ip address of the Lateral Movement activity. The same logic triggers on PSExec, a remote execution utility often abused by adversaries for the same purpose:

Figure 6: Lateral Tool Transfer triggering on PSEXEC from target host

We can also leverage EQL correlation to capture instances where a file that was copied via SMB is immediately executed:

Figure 7: Hunting EQL for remote execution via file shares

The above EQL looks for a sequence of events where a file is created/modified by the virtual System process followed by a process event where the process.executable is equal to the file.path. Below is an alert example:

Figure 8: Detection alert for remote execution via file shares from target host

Another example where file transfer over SMB can be abused for remote execution is copying a malicious executable, script, or shortcut to the Startup folder of a target host. This will cause the program referenced to be automatically executed when a user logs in, and in the context of that user:

Figure 9: Hunting EQL for Lateral Movement via startup folder

Below is an example of a detection alert for Lateral Movement via the Startup folder:

Figure 10: Detection alert for Lateral Movement via startup folder

Remotely Scheduled Tasks

Adversaries may leverage scheduled tasks for remote execution — either via built-in system utilities such as schtasks.exe or directly via the Task Scheduler API, which may be stealthier because visibility is limited.

Below is an example of remote task creation via the MoveScheduler penetration testing tool:

Figure 11: Lateral Movement via MoveScheduler

Both schtasks.exe and direct usage of a custom implementation will cause a process to load the Task Scheduler COM API (taskschd.dll), followed by an outbound network connection where both the source.port and the destination.port are equal or greater than RPC dynamic ports (49152 to 65535) and from the same process.entity_id, which can be translated to this EQL query:

Figure 12: Hunting EQL query for outbound task scheduler activity on source host

Of course, matches to this query can be related to scheduled tasks discovery as well. Below is an example of an alert where we can observe the username, source, and destination IP, as well as the process name used to perform a remote task activity:

Figure 13: Detection alert for Lateral Movement via Scheduled Task on source host

On the target host, we can hunt for remote scheduled task creation/modification via two options:

Incoming DCE/RPC (over TCP/IP) network event by the Task Scheduler service (svchost.exe) followed by a file creation of a task XML configuration file (C:\Windows\System32\Tasks\task_filename)
Incoming DCE/RPC (over TCP/IP) network event by the Task Scheduler service (svchost.exe) followed by a registry change of a task cache Action value (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID}\Actions)

Option A provides us with the task name (equal to the file.name of the changed/created file), and Option B provides us with the task action itself (equal to the base64 decoded data of the Action registry value where the task scheduler service caches the task action configuration):

Figure 14: Hunting EQL query for task creation on target host (Option A)

Figure 15: Hunting EQL query for task creation on target host (Option B)

Option B has the advantage of providing details about the task action, which tend to be useful while triaging (set to execute a program from a suspicious path, LOLBAS process, etc.).

Figure 16: Detection alert for Lateral Movement via Scheduled Task on target host

Decoding the registry Action base64 encoded data provides us details about the created task action:

Figure 17: Base64 decoded data of the scheduled task action registry value

Remote Registry

Adversaries may leverage the Remote Registry service for defense evasion or remote execution. One simple scenario is to modify the Run key registry on a remote system to cause the execution of a program upon system startup or user logon:

Figure 18: Remote modification of the Run registry key via reg utility

We can hunt for this behavior from the source machine by looking for the execution of reg.exe with process.args containing \*, but the same action can be achieved via API calls avoiding process .command_line-based detections.

Figure 19: Example of Reg.exe process execution event on source host

Note that Reg.exe is not performing any network connection — instead, it’s the virtual System process that issues an outbound network connection to the target host on port 445 (DCE/RPC over SMB).

On the target host we can see the following sequence of key events:

Incoming network connection on tcp port 445 (DCE/RPC over SMB) by the virtual System process (process.pid equal 4)
RemoteRegistry service process starts (svchost.exe with process.args containing the string RemoteRegistry)
RemoteRegistry service process performs the registry change

Figure 20: Remote Registry-relevant events on target host

The following EQL hunt can be used to correlate (2) and (3) by host.id and process.entity_id of the Remote Registry service:

Figure 21: Hunting EQL to detect Remote Registry modification via Regsvc on target host

If we include (1) in the above sequence to capture the source.ip address, it may trigger on unrelated incoming SMB connections as the only common element between the three events limited to the host.id value.

Figure 22: Detection alert for Remote Registry modification via Regsvc on target host

Adversaries may attempt to achieve the same outcome via the Windows Management Instrumentation (WMI) registry provider (StdReg), which behaves differently:

WMI Service (svchost.exe with process.args containing Winmgmt string) accepts an incoming DCE/RPC (over TCP/IP) network connection where both source.port and the destination.port are greater than or equal to RPC dynamic ports ( 49152 to 65535)
A new instance of the WMI Provider Host (process.name equal to WmiPrvSe.exe with user.name equal to Local Service or user.id equal to S-1-5-19) is started
The started WMI Provider Host loads the registry provider StdProv.dll module
The WMI Provider Host performs the registry change

We can express the correlation of (1), (2) and (4) with the following hunting EQL:

Figure 23: Hunting EQL for Remote Registry modification via Regsvc on target host

If logging of the StdProv.dll module loading is enabled, we can also add (3) to the sequence to reduce potential false positives:

Figure 24: Hunting EQL for Remote Registry modification via Regsvc on target host (library event)

Below an example of a detection alert where we can see the remotely modified registry details and the remote source.ip:

Figure 25: Detection alert for Remote Registry modification via the WMI on target host

Sharp Remote Desktop

SharpRDP is a Lateral Movement tool that leverages the Remote Desktop Protocol (RDP) for authenticated command execution and without the need for graphical interaction.

Once authenticated, SharpRDP sends virtual keystrokes to the remote system via a method called SendKeys to open up a Run dialog on the target host and then enter a specified command, which will be executed on the target host.

The main indicator from the source host is an unusual process (hosting SharpRDP code) loading the Remote Desktop Services ActiveX Client that implements RDP client functionality (MsTscAx.dll) followed by an outbound network connection to RDP tcp port 3389 and both events from the same process.entity_id:

Figure 26: Hunting EQL for suspicious RDP Client

Below an example of results matching our hunting EQL where we can see an unusual process (other than mstsc.exe and similar known RDP clients) loading the Remote Desktop Services ActiveX Client (MsTscAx.dll) as well as the outbound network connection:

Figure 27: Results example for suspicious RDP Client EQL hunt

On the target host, the following key events occur within a one-minute time window:

An incoming network connection is accepted by the RDP service (TermService svchost.exe) on port 3389
Under the RunMRU registry key, a new (or update to an existing) string value is set to cmd, powershell, taskmgr or tsclient (depending on the chosen SharpRDP execution method), which is caused by the typed command in the Run dialog via the SendKeys method
Depending on the execution method, a new process (attacker command) is created with process.parent.name of cmd.exe, powershell.exe, taskmgr.exe, or a random executable running from the tsclient mountpoint (shared drive from the RDP client host with the RDP target server)

For (2), note that when running anything from the Run dialog, a registry entry will be created at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU showing what was entered into the Run dialog box.

The above sequence of events can be expressed with the following EQL:

Figure 28: Hunting EQL for SharpRDP behavior on the target host

Example of a detection alert and its composing event details on the target host:

Figure 29: Detection alert for SharpRDP on target host (TermService network connection)

Figure 30: Detection alert for SharpRDP on target host (RunMRU set to Powershell)

Figure 31: Detection alert for SharpRDP on target host (PowerShell child process)

Wrapping up

Event Query Language (EQL) correlation capabilities enable us to capture complex behavior for a variety of Lateral Movement techniques. The high-level steps are:

Understand the theory and the building blocks of a certain technique (network protocols, loaded modules, services, process names, and arguments)
Identify the key events and their order that compose a certain behavior (both source and target host)
Identify the common values that can be used for correlation (sequences) — identifying more commonalities can reduce false positives
Identify enrichment possibilities , such as extra events in the sequence that can be useful during alert triage
Assess the window of time for correlation — using a shorter time window (for example, 30 seconds instead of 1 second) can reduce false positives, but can also introduce false negatives caused by network latency or slow system
Test using different methods and tools and tune the hunting logic accordingly, or, in some instances, duplicate logic to capture edge cases

Some of the EQL detection rules used as examples can be found in the Elastic detection-rulesrepository:

If you’re new to Elastic Security, you can experience our latest version on Elasticsearch Service on Elastic Cloud.