The title of this blog is an inner quandary faced by security analysts every day. Truth be told, it’s an excellent question and—in any given situation—you’ll find that the answer varies. If you’ve been an analyst for a while, perhaps you’d say: I got an alert? That’s easy, investigate it. But, what does that actually mean? The gravity of such a question is worth exploring on a fundamental level.
We have an alert!
When we get an alert, there is logic behind that alert that leads to the output we, as analysts, receive. Sometimes we can see the full logic in front of us, other times we cannot. In this particular case, we can’t see everything, but we are given a decent description of what is happening.
With this information, we can infer that the alert is looking for:
- Excel being the main process
- Launching a program that is considered suspicious
So, let’s dig in!
What is the alert telling me?
To truly understand the purpose of the alert, you have to sit back and observe what is on the screen. Above all else, take note of the facts presented to you before forming hypotheses or assumptions of what may or may not be occurring. What we know (and see) is that excel.exe
is spawning regsvr32.exe
.
Now, let’s take a look at the hash of the file Excel opened and take note of it. Depending on the tooling you have, this would be recorded in a file creation event.
Again, we can see that Excel launched regsvr32.exe
. Is it suspicious, though? There are a couple of things we can do to answer this question. First, we need to understand what regsvr32 is used for and, for that, it’s always best to go straight to the source.
registers .dll files as command components in the registry
Alright, easy enough. This means we have a .dll file being used as a command. Next, we need to examine the command line of regsvr32.exe
to determine if anything funky is going on. We see the command line that follows:
The file name efhj.dll
looks a bit odd. Could it be an acronym? Sure, but we’d definitely need to confirm that. For now, let’s take note of it and move on.
What is of interest?
What is the hash of efhj.dll
? The name itself is interesting, but assessing the hash of the file will prove more fruitful. You can get this data either from the point at which the original file was written to disk or when it was loaded with this regsvr32 command. Additionally, it could be pulled from the device and then you can run an MD5 checksum on it. For the sake of those following along, the hash is: 878e47c8656e53ae8a8a21e927c6f7e0.
While there are other processes that spawn from regsvr32.exe
that could be explored, we need to avoid all rabbit holes (as tempting as it is) and focus on the task at hand: is this a threat we need to take action on?
Determining if it’s a threat
Our methodology is to start with the data points provided in the alert that would be considered an indicator of compromise (IOC). An IOC can be a lot of different things, with some more difficult to identify and act upon than others. The diagram below—also known as The Pyramid of Pain—simplifies this a bit.
You can see the easiest indicators are hashes, IP addresses, and domain names. As you move up the pyramid, it becomes increasingly more difficult to identify and, ultimately, make detections for things like host artifacts, tools, and TTPs.
Speaking of hashes, let’s check to see if the hashes of the executables used are what they actually say they are. Some attackers will name their tools something that looks legitimate, but when searched, the hash will reveal “evil.” So, let’s take a look at regsvr32.exe
.
We like to use VirusTotal for this, but you can also use other public sandboxes such as Malware Bazaar or Triage.
You can see that the file itself is distributed by Microsoft, but that does not mean it can’t be used for evil. Often attackers will leverage the tools that are already on a device to accomplish their goals. So, just because the hash of a file is clean does not mean the activity coming from it is safe. Just like how someone may have a legitimate key to the building but might be using it to do something they shouldn’t.
When we search the hashes for SummerBudget2022.xlsx
and efhj.dll
, the results are pretty telling: 29 vendors flagging the Excel file is bad and 55 flagging the DLL.
If threat, now what?
Now that we know we’re working with a threat, we still have some questions to answer. The first being: Who is behind the threat? We’re not necessarily trying to assign country of origin here (we know attribution analysis takes awhile), but can we trace this to a malware family to gain further insights into the intrusion chain.
VirusTotal can usually provide clues via the detection naming conventions. Looking at the detection tab on VirusTotal for the DLL file, several vendors have detections associated with Emotet. With a number of vendors calling this Emotet, we are inclined to proceed with that as a working hypothesis.
Now that we have an idea of who we’re dealing with, we want to know what we’re dealing with. More specifically, we want to research the behavior of this threat. That is, does it:
- try to steal credentials?
- attempt to drop another payload?
- move laterally?
- all of the above?
What we know—thanks to the Threat Detection Report—is that Emotet is a primary downloader and dropper for additional malware and the typical vector is via phishing. Its primary objective is to steal data and credentials. Armed with this information, we can move to the data to determine if we are seeing any of the said behavior in the environment and respond accordingly.
Response
Response depends on your organization and your role within it. At a very high level, this is the time to scope the threat, contain it, eradicate, and then take any steps needed for recovery.
In this scenario, the first step is to isolate the endpoint that is impacted to avoid any potential spread and—at an organizational level—ban the known IOCs:
SummerBudget2022.xlsx
(b46220104f17a172417a86a9cfc677fe)Efhj.dll
(878e47c8656e53ae8a8a21e927c6f7e0)
Following that, you’ll want to scope this to understand if the same behavior or indicators are on any other devices in the environment. You can leverage those same indicators above to determine if this is happening anywhere else, focusing on the Excel file and the .dll. If you find other endpoints that are affected, isolate them immediately if possible.
Next, you’ll want to clean up the malicious artifacts. You can do this one of two ways: re-image the device (preferred) or do it manually, which would require a full investigation of the endpoint to make sure no artifacts are left behind. This means removing files, deleting registry keys, finding any persistence mechanisms, and killing any malicious processes. While there are use cases for manual clean-up, it’s important to remember that time is of the essence here, so the quicker you can eradicate the threat, the better. Additionally, it is a best practice to rotate affected user credentials, as the goal of Emotet is credential theft.
What if…
If you couldn’t clearly identify this as a threat, you’d need to buckle in, ask some probing questions, and do some further investigation prior to responding.
We aren’t going to dive down the rabbit hole right now, but here are some of the questions we’d ask to gain additional information and context:
- What is the significance of each process that spawned from
regsvr32.exe
? - Where did the suspicious activity happen? (Trace the process tree)
- What is the source of the malicious file?
Answers to the above questions will help inform your next move and pivot your investigation. Additionally—when in doubt—ask yourself “is this normal?” It can be helpful to search an environment for similar behavior over a period of time. This will give you a baseline that will allow you to act accordingly.