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 worksLateral 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 TransferFiles 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 machineOn 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 SMBA 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 hostThe 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 hostThe 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 hostWe 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 sharesThe 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 hostAnother 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 folderBelow 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 TasksAdversaries 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 hostOf 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 hostOn 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 hostDecoding 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 RegistryAdversaries 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 utilityWe 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 hostNote 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 hostIf 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 hostAdversaries 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 Ho