Threat Hunting for Lateral Movement
Lateral movement is a key step that attackers use in targeting and exploiting your network. In this post, we’ll walk through how to identify pivot points of data when hunting for lateral moment when hunting with Sqrrl.
We’ll look for instances where multiple users are logged onto an end-user workstation simultaneously or within a relatively short period of time, where the same user account is logged onto more than one host, or where a network login references a non-domain account on the target system.
Determining the closest time around when you think the incident occurred (time-based) or possibly identifying a key file that might have been used in the activity in question (file-based).
We’ll by using the Sqrrl detection tool bar and change the filter to “Lateral movement.” This will use risk factors in determining possible lateral movement using Windows event logs 4624 (successful) or 4625 (failed logon). We can start our hypothesis by looking at anomalous activity using the visualization of the Sqrrl threat hunting platform.
From this visualization, you can see some quick references to what user accounts are authenticating to workstations. One account U3845@DOM1 is seen with successful logon events to two different workstations, and one account (U4325@DOM1) has a failed attempt. Starting with the account U3845@DOM1, we will determine what workstations this account is authenticing to.
We have two different workstations (C706 and C395) with the same account being used on both of endpoints. The Logon Type 5 indicates that this was a service starting. These Windows events meet some of the criteria of our hypothesis but we need to get additional context from the Windows event logs for each workstation.
Drilling down on the first workstation C395, we see multiple accounts being used which is interesting, but we notice a suspicious process (4vnrye74vmugh.php) running on the endpoint along with two others (ccleaner64.exe and skype.exe). Here we are going to pivot (file-based) to the process to determine what exactly this process is doing.
Drilling down on the process, we immediately get a good visualization on some key components of our investigation. The process is establishing network connections with two unknown IPs (126.96.36.199 and 188.8.131.52) and three other workstations are running the same process. We also see some other accounts being used by the process which is odd.
We get a lot more context on this activity by drilling down on the Carbon Black logs to see what events are associated with this process. This process is showing up on two different threat feeds (abusech-zeus and the Facebook Threat Exchange) within Carbon Black Response. Based on one of these feeds, we can determine that this process is associated with the banking trojan Zeus or one of the many variants.
Let’s determine the scope of the incident based on the processes found running on the host and collect additional IOCs.
Hostnames with the running process 4vnrye74vmugh.php, ccleaner64.exe, and skype.exe:
- C395 – 10.1.2.225
- C586 – 10.1.5.114
- DESKTOP-2R8TU4K – IP was missing
The beaconing IP from the malicious process was 184.108.40.206. We can get additional context from this IP by drilling down on the IP and checking the proxy logs associated with it.
Filtering on the account U3845, we see additional malicious domains associated with the account. bruha[.]ru and vqpydhheirk2i[.]com are seen to be connected with the original beaconing traffic and we have additional pivot points based on an unusual user agent string found in the proxy logs. Sqrrl has a good blog on hunting for user agent strings found here. This could kick-off additional hunts in the future for this type of unique user agent string.
For this hunt, we are going to pivot back to our Windows event logs to determine the scope of lateral movement found within the environment. By drilling down on the successful and failed logon attempts, we’re presented with a visualization that helps the analyst determine the scope of the incident.
When pulling the Windows logs from the endpoint and analyzing them, we start to see a slightly different picture than before. The analyst can infer that C395 was not the original point of impact, but C706 was based on the Windows logs. We can also prove our hypothesis by comparing the logon times for the account U3835@DOM1 and determining that the account was used simultaneously on multiple workstations. The attacker moved laterally to establish a footprint on the network in the event one of the workstations was discovered and cleaned. This increases the chances of the attacker to have a persistence backdoor on the network to achieve their objective of stealing information.
IOC’s found in hunt
User accounts involved:
U4345 – failed attempt
10.1.33.234 – C706 (Initial Lateral Movement)
10.10.1.2 – C395 (Lateral Movement + Beaconing)
10.1.5.114 – C586 (lateral Movement + Beaconing)
10.10.1.4 – C9825 (lateral Movement + Beaconing)
10.1.23.137 – C2450 (lateral Movement + Beaconing)
10.106.248.216 – MUS05 (Beaconing) – Found from similar user agent string from beaconing activity
URLs associated with incident:
So, given the IOCs that were found during this hunt, we can conclude that this was a successful hunt. However, even if we didn’t find anything, the point of a hunt isn’t to a true positive malicious event every time, but instead it is to validate a hypothesis, to answer a question with a definitive yes or no. If you’d like to learn more about processes for hunting for lateral movement, be sure to check out this webinar.