Event ID: 5— Let’s Defend

Trigger Rule: SOC102 — Proxy — Suspicious URL Detected

4 min readJun 2, 2022

--

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: 198.100.45.154
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.

Record showing that the URL is needed used to host malware

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.

Network log generated around the same time as the SOC alert was created

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.

Logs of the process that ran of the MikeComputer host

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

We can see that the maldoc was indeed a recognized malicious document

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.

List of processes spawned by the maldoc on the host

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.

Surricata alerts that identified the network traffic as malicious

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

Network log confirming contact with the C2 server

Detailed network log confirming contact with the C2 server

Thus, we can confirm this was a real infection using a maldoc, possibly Emotet. Now, we can work on closing the alert.

Step 1

We have collected all the data we are asked here

Collect all the data needed for the SOC case

Step 2

We have analyzed the network logs

Search the network logs for the malicious traffic that we have collected till now

Step 3

We have the analysis of the URL and we know it’s malicious

From the analysis of the URL in the alert and all the other URLs in the analysis, we know it’s malicious

Step 4

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.