At the end of July we reported how Emotet was making a big comeback, but as we just found out it could have happened long before that. Researchers at Binary Defense spotted a flaw that allowed them to activate a kill switch to prevent the malware from infecting systems for at least six months.
It’s a peculiar, but refreshing situation as James Quinn explained: “Just as attackers can exploit flaws in legitimate software to cause harm, defenders can also reverse-engineer malware to discover its vulnerabilities and then exploit those to defeat the malware. The difficulty, of course, is how to share the news about the vulnerability with other defenders while keeping it a secret from threat actors so they don’t just patch the flaw. Researchers at Binary Defense have been doing exactly that since February 6th, and now it is time to share the details more publicly”.
The Emotet kill switch exploited a simple buffer overflow found in Emotet’s installation process. Once developed it was shared freely with the infosec community, avoiding public channels to ensure maximum uptime of the exploit before the threat actors behind Emotet patched their malware to close the vulnerability.
This kill switch was alive between Feb 6th, 2020 – Aug 6th, 2020, or 182 days.
New features and new problems
Emotet, born as a banking trojan, appeared in the wild for the first time in 2014, and has evolved over time to become a true multi-function criminal framework.
Before its temporary disappearance, it certainly represented one of the main threats in 2018, in 2019 and in the first months of 2020 at the very beginning of the COVID-19 pandemic (and now we know why it stopped for a while!).
In early February of this year, Emotet released a massive codebase overhaul, changing several of the installation and persistence mechanisms and introducing a polymorphic state-machine to their code flow. This added a layer of obfuscation to the loader, making analysis more difficult. One of the key changes was the removal of the word list and file generation algorithm used by Emotet during previous Emotet installs.
The change in itself was straight-forward: it encrypted the filename with an XOR key that was then saved to the Windows registry value set to the victim’s volume serial number.
Kill switch V1 and V2
Around 37 hours after Emotet unveiled these changes, Binary Defense threat researcher James Quinn finished the first version of the killswitch/vaccine that eventually became EmoCrash. In the early days of this protection method, the PowerShell script would generate the registry key value for each victim and set the data for each value to null.
When Emotet would check Registry for the install marker, it would find the newly-generated null value and generate the exe name “.exe”. It would then search the normal install location for this exe (%AppdataLocal%, C:\Windows\System32,C:\Windows\Syswow64, based on environment). If it didn’t find it, it would drop a file to the normal install location called “.exe”. However, when the malware attempts to execute “.exe”, it would be unable to run because “.” translates to the current working directory for many operating systems.
While this mechanism worked, it was very messy and still allowed Emotet to install—it just prevented Emotet from running successfully and reaching out over the network. Worried about lack of deployment due to the messiness of the protection mechanism, and the additional concern that it makes cleanup difficult, Binary Defense continued experimenting with the killswitch, looking for ways to increase its effectiveness.
Around 48 hours after Emotet released the newest loader version, Binary Defense completed the second version of the killswitch. This version exploited a simple buffer overflow discovered in Emotet’s installation routine which caused Emotet to crash during malware install, but before the malware would drop itself to the normal Emotet install locations, thus completely preventing malware installation. Additionally, two crash logs would appear with event ID 1000 and 1001, which could be used to identify endpoints with disabled and dead Emotet binaries after deployment of the killswitch (and a computer restart).
Packaged into a nice usable PowerShell script (which we named EmoCrash), this utility would identify the user’s architecture and then generate the corresponding install registry value for the user’s volume serial number. It would then generate a buffer of 0x340 (832) bytes, which it would save to the new registry value’s data.
This tiny data buffer was all that was needed to crash Emotet, and could even be deployed prior to infection (like a vaccine) or mid-infection (like a killswitch).
End of the line
Last july, Emotet finally returned to spamming after their several months-long development period.
With EmoCrash still active at the start of their full return, up until August 6, EmoCrash was able to provide total protection from Emotet.
As Quinn said: “Not bad for a 832-byte buffer!”