�Ӱɴ�ý

is one of the most common attack tactics that attackers use once they're inside an organization. Leveraging lateral movement techniques allows attackers to move laterally across the organization, deepening their compromise. Common lateral movement techniques include Remote Desktop Protocol (RDP), remote COM object activation (DCOM), PowerShell Remoting, Remote Services & Scheduled Tasks, and SMB. Due to the frequency that lateral movement occurs, �Ӱɴ�ý’ EDR product found the need to create visibility into lateral movement techniques. 

At �Ӱɴ�ý, we don't believe in “chasing” every technique. We want to build features that impact our customers and give our SOC team the appropriate visibility to identify maliciousness, while keeping the collection noise low. To help with this, we implement a layered approach to both telemetry collection and detection capabilities. The implementation for lateral movement was no different. In this write-up, we explain how we're approaching lateral movement from a collection and a detection standpoint. First, let’s dive into how we built the feature. 

Building the feature

Remote interaction with a host is very common within organizations. This is because administrators need to be able to access a resource remotely or manage a machine’s settings/updates/etc. Due to this need, there are default ways that make machines accessible by users, by which attackers like to take advantage.

Historically, insight into this activity has come by way of collecting information on the client side (where the code execution came from). This can be done by tracking processes that have a network connection or that create a network connection to some random IP/host. Due to false positives, we didn’t implement this approach, so we decided to break lateral movement into “action pillars”—essentially, pillars where different actions take place. Once we did that, we could identify where we wanted to collect telemetry and if that collection held value. 

After some research, we decided that when lateral movement is performed, there are four main steps:

1. Initial Code Execution (Source Machine)
2. Transport (WinRM, DCOM (DCE/RPC), RDP)
3. Remote Authentication (Remote Machine)
4. Remote Code Execution (Remote Machine)
   

After organizing the data into these pillars, we saw significant value in focusing on remote authentication and remote execution, especially when combining both into a single event for our Detection Engineers and SOC analysts. Doing so allows us to: 

1. See who logged in to the remote machine
2. See the logon type that was leveraged
1. This helps us with false positives and identify what transport was used
3. What was executed
1. Track the user’s code execution
2. Helps tune false positives (due to things like RMMs)

Let’s look at a lateral movement scenario and what the �Ӱɴ�ý EDR would and wouldn’t collect: 

Leveraging DCOM applications has always been an attacker's favorite when attempting lateral movement. Back in 2017,  wrote a around leveraging the MMC20.Application COM Object for lateral movement. Let’s use this as an example of the visibility we'd have if this activity was triggered. But first, let’s build the scenario: 

1. There are two machines, where the client (Machine 1) doesn’t have the �Ӱɴ�ý EDR installed, while the target machine (Machine 2) does. 

2. Attacker has valid credentials of a user (thor) that can access Machine 2.

3. Attacker leverages the MMC20.Application COM object to laterally move and execute an encoded PowerShell command that reaches out to an IP to download a file.

In this scenario, we'd see: 

1. Attacker’s authentication to Machine 2
2. The execution of the PowerShell encoded command and other process-based executions that are tied to that user’s authenticated logon session 

The value of this approach is we can now track user code execution as they live in that logon session, not just the lateral movement attempt. Meaning that if an attacker is launching a bunch of processes, we would see them, whether it's the first process they launched or the tenth.

This is just one example of the insight we have now that we approach lateral movement this way. Here are some other noted examples: 

1. WMI Execution over DCOM

2. WMI Execution over WinRM

3. PowerShell Remoting

4. DCOM Object Activation (ex. MMC COM Object)

5. Process Execution over RDP

6. Headless RDP Execution

When bringing these two pillars together, we noticed not only how prevalent lateral movement was happening in cases like ransomware, but how this telemetry actually allows us to see some initial access execution as well. This next section goes over some of the malicious activity we’ve seen since implementing this capability which has led to quicker classification and response. 

Detection wins

With this new feature, we can leverage the following from the lateral movement data: 

• Source IP Address

• Source Port

• Source Hostname

• Logon Type

• Logon Id
  

Authentication focus

We can zoom in on the authentication aspect of lateral movement to find process execution that can be more accurately classified as malicious due to the additional data. For example, processes executed via RDP logon from a Public IP address rather than a Private IP address.

Real-world scenario 

�Ӱɴ�ý observed an SQL Admin user executing malicious commands remotely on an SQL server. This activity comes from a host without the �Ӱɴ�ý agent installed. Next, the threat actor was seen trying to enable RDP connections via the registry in order to log into the affected server via RDP.

Ransomware precursor focus

Next, we can target key ransomware precursors that are also often run by administrators and can be problematic to identify malicious use.

However, leveraging the new data, we can target the following activity being done remotely with better accuracy.

• Enumeration

• Killing security tooling processes

• Stopping/disabling core services (webservers, databases, hypervisors, etc.)

• Deleting shadow copies

• Clearing logs
  

Real-world scenario 

A series of suspicious activities, likely precursors to a ransomware attack, were observed across at least two hosts (Host A and Host B). The activity centered around logins from the IP address associated with known malicious hostnames.

• Initial compromise indicators: Brute-forcing attempts were logged on Host A. Subsequently, a user logged into Host A from the suspicious IP/hostname.

• Malicious actions on Host A: The user then proceeded to delete shadow copies and dump sensitive system files (registry hives, ntds.dit) to a common staging directory (C:\Users\Public\Music).

• Lateral movement and activity on Host B: Multiple users were observed logging into Host B from the same (internal) IP address and associated hostnames over several weeks. One user was later seen running commands on Host B after the critical actions on Host A.

The observed pattern of activity—credential compromise, deletion of backups, and exfiltration/staging of sensitive data—strongly suggests an attacker preparing to deploy ransomware. Using logon data and other detections, �Ӱɴ�ý identified and reported the malicious activity prior to execution of any ransomware.

Protocol abuse focus

Last, we honed in on the most common lateral movement techniques, which leverage transport methods such as WinRM, DCOM, and RDP. This allows us to find typical attacker tradecraft and tools that execute in this manner, which is not commonly used legitimately. 

Hacking tools that are commonly used in the wild include the following.

• Impacket

• CrackMapExec

• NetExec

• GoExec
  

Real-world scenario

�Ӱɴ�ý observed user SYSTEM executing malicious commands to dump the LSASS process to harvest credentials via ���ܲԻ����32.������loading cmsvcs.dll. This activity stemmed from mmc.exe (Microsoft Management Console), which leverages DCOM as the transport protocol. This is common among tools like Impacket’s  Python class or NetExec’s  Python class.

Conclusion

As we continue to build the �Ӱɴ�ý EDR, we want to implement features and capabilities that provide value to our customers and our analysts. We do this by identifying which attacks our customers are most likely to get hit with, breaking down the attack and identifying telemetry, and then building an event that is useful to our detection analysts so that they can create detections and analysts so they can classify effectively. 

This approach enables us to create higher-fidelity detections to convey lateral movement happening in conjunction with remote execution. Through this lateral movement visibility, we hope to continue to find maliciousness sooner and more comprehensively for our partners.