Any malware, trojan, or worm is a potential threat to organizations. Either through targeted or ‘drive-by’ attacks, these tools (make no mistake these are tools for malicious actors) are built with the mission to infect and provide value from a company’s infrastructure and data. Or just wreak havoc.
Emotet has seen a resurgence since its takedown, which to me indicates that the actors feel they have invested a great deal of effort and time into something and still see value in it. They may not be targeting a specific organization with it but maybe take a shotgun approach instead, believing it is more likely to have success. In the end, does it matter whether they spend years targeting the largest organization and have a 100% hit rate or send malware against 100 organizations and only get 2 successful deploys? They will still be able to gain value out of the latter deployment, and it will often be a lower effort for them.
Malware as a Service
What makes this approach even more appealing for the group operating the current version of Emotet is that they are malware-as-a-service. They only need infected systems to allow for the deployment of their customer’s attacks, so the more systems they have, the better off they are. This is why the shotgun approach is going to be the better approach for them. This makes Emotet a thread that every organization should be taken seriously.
With Emotet also being a polymorphic malware (changing its code every time it is called), it is less important to key off of hash values and more important to a behavior detection built in. Additionally, organizations should be deploying defense in depth approach, so having strong spam filtering, email attachment and URL scanning (both reputation and payload detonation), user awareness training, and strong internal network security to assist with minimizing the impact of Emotet in their network.
I would say that SMB organizations are likely at the highest risk, which can be evidenced by the yearly breach reports that show this market to be the most breached.
Emotet’s Recent Move to 64-bit Code
I will preface this as this is my personal conjecture on why the move to 64-bit. When Emotet first emerged, 32-bit systems were still the predominant processor type, so developing for the lowest-level system was the best approach. Now, nearly, if not all, new systems are 64-bit processors and with this are able to handle larger amounts of RAM. So, my thought is that the group behind it made the shift to take advantage of the better processor to deploy and operate the malware on the endpoint more efficiently.
Another aspect to keep in mind is that there has been a recent shift of ransomware to not fully encrypt every file it touches but rather to encrypt sections of the file or bytes of the files on the system. This accomplishes the same goal of making the file unreadable or usable but it is much faster and harder to detect than full encryption. So, could this be another reason for Emotet moving to a 64-bit loader? A stronger shift from just malware-as-a-service to ransomware-as-a-service?
Emotet Shifts to Stealing Credit Cards and Attacking SMBs
As a CISO for a financial service provider in the B2B space that works with a lot of SMB customers, I can see what this shift is about. SMB companies will have a lower investment in security, this is known. It’s just not feasible for a $50M company to have the same level of tools, teams, and capabilities as a $1B company. The short answer is that this makes them more vulnerable and Emotet more likely to gain access and keep access to those systems. This is nothing earth-shattering but shows that the shift is moving to further reestablish the network that was operational before their takedown.
This may also indicate what we have all seen in recent years with attack strategies for malicious actors. Rather than go up against a well-fortified, well-funded security team at a Fortune 100 company, why not target the supply chain? Wouldn’t it be easier to gain access to a much smaller partner that does not have the same level of investment in security, utilize that compromise to then pivot to the fortune 100 that you are targeting? After all, that is what we have seen from the Solarwinds and Kaseya breaches.
As for credit cards, these always hold value on the open market. If Emotet is going to continue to offer up malware-as-a-service in the newest iteration, having credit card stealing capabilities seems like a good solution to have in your product (I say product because it is a product on the black market).
To further this, there are more and more SMB companies that are utilizing credit cards for payments of services, goods, and materials since coming out of COVID. Working capital can be hard for SMB companies to attain to allow them to purchase the goods they need which has driven the market to look towards credit cards to gain the buying power they may need. After all, if the SMB is selling to larger companies, they may be offering their services up on terms, as much as 90-day terms, so they will not have that working capital to get the goods or materials needed to provide the services to the larger organization without some sort of float credit.
Emotet Rapidly Changes Its Configuration
Speaking from the side of someone that is defending against this, configuration changes make it nearly impossible to utilize signature-based detections. I cannot rely on a dirty IP address to tell me that the communication is malicious, I cannot rely on signature-based detections to assist with preventing or stopping the spread.
At this point, I have to rely on behavior and strong security controls in my network and on my systems to help prevent or contain the malware after it has landed. These types of detections are much more reactive and oftentimes require a larger investment in people hours to investigate and determine what a file or system is trying to do. This pulls my team away from other tasks like further securing our environment and, in my opinion, leaves us more susceptible in the future.
“No 100% Surefire Way to Protect Against Emotet”?
A 2019 Kaspersky blog post said that there’s no 100% sure-fire way to protect against Emotet. Is that still true?
Sadly, it is true. But this can be true for almost any malware out there these days. It used to be signature-based detections that provided protection once the malware was known but with the shift to polymorphic, to combat this detective capability, those have fallen by the wayside.
In recent years, threat intelligence has been utilized to help with detection, so keying off of IP addresses, email addresses, etc. but with the new focus on rotating the botnet and email addresses, this has become less effective.
Really, where we are at is that we need to use behavior-based techniques, and utilize email systems that detonate the payloads to determine if they are malicious.
But we are even seeing malware evolve to defeat these controls. Recently, my team and I have discussed an uptick in malware that is designed to detect it running in detonation software (O365 analysis, FireEye tools, etc.) and to change its behavior to avoid detection in these tools. With this being a cat-and-mouse game, as we evolve our detection and defensive capabilities, attackers will shift or evolve to avoid, neutralize, or have their own defensive techniques to be successful.
How Can organizations Defend Against Emotet?
I’ve touched on several possible solutions above, but to summarize: Utilize defense in depth. Utilize email-based security tools and detections to attempt to identify the malware coming in via phishing or spam email. Deploy endpoint detection and response tools that are not just signature-based but also behavior base. Utilize segmentation and network security controls to minimize the spread of the malware once it is in the network. And of course, one of the most important things we can do is improve user education.
