Event ID: 5— Let’s Defend
Trigger Rule: SOC102 — Proxy — Suspicious URL Detected
- EventID: 5
- Event Time: Aug. 29, 2020, 10:50 P.M
- Level: Security Analyst
- Source Address: 172.16.17.14
- Source Hostname: MikeComputer
- Destination Address: 22.214.171.124
- Destination Hostname: qstride.com
- Username: Mike01
- Request URL: http[:]//qstride[.]com/img/0/
- User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
- Device Action: Allowed
For this alert we have the destination IP and host-name, thus we can search for the IP, host-name and the URL for possible known malicious hit.
First we can search for that URL in URLHaus and we can get a hit showing the URL multiple malware samples. It was also active during the time we received this alert on our host.
Now that we know this URL is malicious, we need to make sure that the host MikeComputer host did indeed connected to this URL and especially around the time this alert was generated.
And here we get a hit and that too within a reasonable time difference between SOC alert and URL access
From the network log details, we can see that the process that requested this URL was Powershell and was launched from what seems like a maldoc.
Now that we have some data about what processes started this request, we can check for those in the “Process History” of the MikeComputer host dashboard. We can also get the MD5 hashes of the processes.
We can see that the maldoc and the powershell was started during the time of the SOC alert. From the “Command History”, we do see a large Base64 encoded Powershell payload being executed on this host.
Now, we can either decode and reverse-engineer the Powershell payload or we can find the report for this maldoc on Any.Run sandbox. First, we search for that in VirusTotal
Now let’s search for the sample in Any.Run sandbox, and we do find a report for a execution during at the same time we got a SOC alert.
From the report, we can see that the maldoc spawns a Powershell payload and also one of the spawned child processes have been identified as Emotet by the sandbox.
Also from the sandbox, we can see that the URL that popped up in our alert has also been contacted and used to download an executable, which has been identified as Emotet on VirusTotal. We can also multiple IDS alerts relating to downloading executable and Emotet C&C traffic.
If we search for the C&C server IP address on the network log, we can see the C2 IP was contacted by the MikeComputer host
Thus, we can confirm this was a real infection using a maldoc, possibly Emotet. Now, we can work on closing the alert.
We have collected all the data we are asked here
We have analyzed the network logs
We have the analysis of the URL and we know it’s malicious
From the network logs, we know that the URL used to download the malware was accessed and the C2 server was also accessed. Thus, we can mark it as accessed.
Go to the MikeComputer host page and start containment.
Add the available IoCs for the case.
Write a brief note reasoning the analysis.
Now, we close the case and then move to close the alert.
Now that we have closed the alert, we can see how well we analyzed this alert.