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:

1. Remote authentication to the target host (valid access credentials are required)  
2. 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
3. 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).
4. 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:

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)

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):

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:

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.  

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:

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

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:

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:

Below is an example of a detection alert for Lateral Movement via the 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:

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:

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

1. 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)
2. 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):

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.).

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

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:

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.

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:

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

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

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.

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

1. 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)
2. 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
3. The started WMI Provider Host loads the registry provider StdProv.dll module
4. The WMI Provider Host performs the registry change

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

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

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

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:

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:

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

1. An incoming network connection is accepted by the RDP service (TermService svchost.exe) on port 3389
2. 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
3. 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:

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

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:

1. Understand the theory and the building blocks of a certain technique (network protocols, loaded modules, services, process names, and arguments)  
2. Identify the key events and their order that compose a certain behavior (both source and target host)
3. Identify the common values that can be used for correlation (sequences) — identifying more commonalities can reduce false positives
4. Identify enrichment possibilities, such as extra events in the sequence that can be useful during alert triage
5. 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
6. 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-rules repository:

• Remote File Copy to a Hidden Share
• Lateral Tool Transfer
• Remote Execution via File Shares
• Lateral Movement via Startup Folder
• Outbound Scheduled Task Activity via PowerShell
• Remote Scheduled Task Creation
• Potential SharpRDP Behavior
• Suspicious RDP ActiveX Client Loaded
• Execution via TSClient Mountpoint

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