When an incident or threat occurs on our networks today one of the more plaguing questions that comes up is “How can I leverage the tools I have to gain more contextual details and find the root cause”? This is a difficult question to answer. All vendors and devices have their areas in which they excel. Today I’d like to focus on utilizing a Dell SonicWALL to leverage better Forensic Analysis for an occurrence.
Recently an employee was leveraging Daemon Tools for mounting ISOs and setting up lab environments. Daemon Tools is a free virtual drive and optical disc authoring program for Windows and Mac OS. While there are other options, this is a widely used tool because of its free nature. While using Daemon the employee was prompted to update the software. Thinking this is a trusted tool used daily, not many questions were asked and the employee agreed to pull down an update. When Daemon reached out for an update it hit a mirror hosted on mountspace.com. Unfortunately this redirected to another site disc-tools.com where a malware wrapped EXE was pulled down.
Lucky for us, we have a SonicWALL on the edge that recognized and blocked this threat. Let’s dig in and see how we got to the root cause using our SonicWALL and favorite Flow Analyzer:
Once the employee reach out to the mirror to pull down the software update our SonicWALL kicked out an alert about blocking a known virus. Lucky in this particular the virus had a known signature in the code that the SonicWALL recognized via a static list and blocked. This isn’t always the case. To learn more about SonicWALLs threat detection take a look at Dell’s Annual Threat Report.
When a threat is blocked SonicWALL kicks out an alert, let’s take a look:
As you can see from the alert we have a decent amount of information to start investigating. We know the time the incident occurred, the source IP, the destination IP and the type of threat was detected and blocked.
Now that we have a starting block, let’s begin digging in. In this case I’d like to start by using our FlowPro to investigate the DNS traffic. I’ll start by building a report in our Flow Analyzer looking for DNS Text from our Source IP:
From here we can correlate to the actual URL that was hit. We can do this by again using our SonicWALL which fortunately exports full length URL string. Let’s look at the URL being hit:
From here we can now see the full length URL that triggered out alert. It’s important to note as well that all the reports we’re looking at are run at a very isolate time frame of when the SonicWALL blocked the threat. Generally ~5 minutes before to ~10 minutes after. You’ll also note that in the URL we can see the mirror hosted on mountspace.com. After that is the URL we were redirected to, https://ns-us7.disc.tools.com. At the very end of that URL is the executable we were trying to pull down that unfortunately was wrapped in malware.
At this point we’ve gained a lot of ground. We know when the threat occurred, we know it was block (thankfully) and we know where the threat came from. Now we have to tackle the biggest question of who done it!
To get this last important detail it will require username reporting. This can be accomplished by integrating with your Active Directory or Cisco ISE database. This will open up the ability to run User Name by IP reports. To learn more about integrating with AD or ISE look at this blog written by Austin.
Simply switching my report type to a Source Report > User Name by IP I can now find not only the machine used to pull down the malware wrapped executable, but also the username logged in!
This is great information, this allows me to then talk to the end user and find out exactly what had happened at that time. In turn this is how we found that they were attempting to update. What’s even scarier here is that both users had admin accounts! In hindsight this could have been much worse. Nonetheless, even when a threat is blocked on the edge and never makes it into your network it’s still crucial to investigate the event to better inform those involved.