This post was originally published here by Brandon Baxter.
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.
Hypothesis:
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.
Pivot Point:
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).
Investigation
We’ll off by using the Sqrrl detections 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 (118.184.176.15 and 64.71.35.47) 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. The logon type 5 would make more sense since Zeus injects code into legitimate services (known as process hollowing) and restarts them on infection.
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 118.184.176.15. We can get additional context from this IP by drilling down on the IP and checking the proxy logs associated with it.
The BlueCoat proxy logs show five network sessions and the domains hxxp://9991[.]com (the referrer) and mtzlplk[.]3322[.]org. Two different file types were seen being requested; a JavaScript file (c2_dropkit.js) and a rar file (bin2.rar).
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 strings.
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:
U3845@DOM1
U3845
U4345 – failed attempt
MUS05
DESKTOP-2R8TU4K\demo
Administrator@DOM1
Hosts Involved:
C395
C586
C706
C9825
C586
IP’s Involved:
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 – (no hostname given) – MUS05 (Beaconing) – Found from similar user agent string from beaconing activity
C2:
118.184.176.15 (China)
42.62.30.180 (China)
84.41.184.94 (Netherlands)
1.187.125.251 (India)
1.52.188.119 (Vietnam)
URLs associated with incident:
hxxp://mtzlplk[.]3322[.]org/c2_dropkit[.]js
hxxp://mtzlplk.3322p.]org/bin2.rar
hxxp://9991[.]com/time[.]txt
hxxp://9991[.]com/day_data/20150128[.]js
hxxp://9991[.]com/c2_dropkit[.]js
hxxp://bruha[.]ru/c2_dropkit[.]js
hxxp://vqpydhheirk2i[.]com/c2_dropkit[.]js
File Path:
c:\windows\systemapps\microsoft.microsoftedge_8wekyb3d8bbwe\4vnrye74vmugh.php
c:\windows\systemapps\microsoft.microsoftedge_8wekyb3d8bbwe\skype.exe
c:\program files\ccleaner\ccleaner64.exe
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.
You can also drill down on methods for hunting for lateral movement in this hunt tutorial by security expert Ryan Nolette and our recent collaborative webinar with Carbon Black.
Photo:TechRepublic
