Published on August 19th, 2020 📆 | 8572 Views ⚑0
EmoCrash Exploit Helped Slow the Spread of Emotet for Months
Every once in a while, the good folks win. This is one of those times.
For the better part of six years, the Emotet trojan has been running rampant through corporate networks and individual machines alike, stealing banking and email credentials and serving as a platform for installing other malware on demand. Emotet has the power of three separate botnets behind it and has been a constant, persistent threat since it debuted in 2014. The malware receives regular updates to fix problems and add functionality and researchers have been looking for ways to halt or at least slow Emotet’s infections. In February, researchers at Binary Defense noticed a change in Emotet that had been part of a code update, a change that gave them the opening they needed to develop a method that prevented the malware from executing on target computers.
As part of the February update, the Emotet authors included a new algorithm that would choose a random executable or DLL file name from the system32 directory as the name under which Emotet was saved on each infected system. After the filename was XOR-encoded, it was saved to a registry value that is identical to the machine’s volume serial number. This was a small change, but an important one. James Quinn, a researcher at Binary Defense, developed a PowerShell script that generated the registry key value for each newly infected machine and then set the value for that data to null. As a result, Emotet would not be able to execute and connect to external C2 servers.
“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:WindowsSystem32,C:WindowsSyswow64, 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,” Quinn said in a post explaining the development of the killswitch, which was dubbed EmoCrash.
The method was effective, but somewhat crude, as it still allowed Emotet to be installed on a machine. So Quinn kept working on the problem, looking for a better way. A couple of days after the Emotet update in early February, he noticed a buffer overflow in the code and thought he might have found a way to stop Emotet, at least for a while.
“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),” Quinn wrote.
After he discovered the bug, Quinn messaged his boss, Randy Pargman, a former FBI cybercrime investigator, to determine how they should approach the question of what to do with it.
“He messaged me in the middle of the night, and said, Hey I found a buffer overflow in the Emotet code. Then he asked, Can we use it? And I had to say I don’t know,” Pargman, senior director of threat hunting and counterintelligence at Binary Defense, said in an interview.
“The real takeaway is the infosec community working together like this can do great things.”