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:\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,” 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."
“We first had to make sure that we did no harm because all of these computers that we’re talking about are victims’ computers. We spent a lot of time talking about this internally and then after we shared it with enough people who looked at it and said yeah, this works and it won’t do any harm, we began to share it more broadly.”
Quinn and Pargman and their colleagues shared the new PowerShell script that Quinn developed among the various trust groups they belonged to in the security community and word spread quickly. With a helping hand from Team Cymru and CERT teams in countries around the world, the Emotet exploit was shared widely, but with the caveat that it could not be disclosed publicly to avoid alerting the malware authors. Around the same time, the Emotet authors entered one of their semi-regular quiet periods, in which they stop sending out spam messages with infected attachments. It’s not exactly clear what the group is doing during these shutdowns, but it’s likely that they’re working on upgrades and refinements to the malware. Between Feb. 7 and July 17, the Emotet group was quiet, but the developers were still pushing updates to the malware on existing infected machines.
All the while, Quinn’s EmoCrash exploit was spreading in the defense community and organizations that had been victimized by Emotet were able to deploy it to stop infections. When the malware authors resumed their spam runs on July 17, EmoCrash was still going strong and it wasn’t until an update on Aug. 6 removed the vulnerable code that Quinn’s creation stopped working. Pargman said the change probably wasn’t because the Emotet group discovered the EmoCrash exploit, but was just a result of the continued innovation and work by the malware authors to stay ahead of defenders.
But the fact that EmoCrash remained effective for more than six months is remarkable.
“When it started, we thought a month would be great. Then it got two months, then three and we couldn’t believe it,” Pargman said. “The real takeaway is the infosec community working together like this can do great things by distributing threat intelligence throughout these networks.”