{
	"id": "6cd0245f-fdc2-421d-96d5-6293e8449f98",
	"created_at": "2026-04-06T00:22:02.364825Z",
	"updated_at": "2026-04-10T03:20:42.888598Z",
	"deleted_at": null,
	"sha1_hash": "83481f52a6b2bce97e3ef453960195f55651cd05",
	"title": "EmoCrash: Exploiting a Vulnerability in Emotet Malware for Defense",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 262609,
	"plain_text": "EmoCrash: Exploiting a Vulnerability in Emotet Malware for\r\nDefense\r\nBy Binary Defense\r\nArchived: 2026-04-05 19:20:53 UTC\r\nBy: James Quinn\r\nMost of the vulnerabilities and exploits that you read about are good news for attackers and bad news for the rest\r\nof us. However, it’s important to keep in mind that malware is software that can also have flaws. Just as attackers\r\ncan exploit flaws in legitimate software to cause harm, defenders can also reverse-engineer malware to discover\r\nits vulnerabilities and then exploit those to defeat the malware. The difficulty, of course, is how to share the news\r\nabout the vulnerability with other defenders while keeping it a secret from threat actors so they don’t just patch the\r\nflaw. Researchers at Binary Defense have been doing exactly that since February 6th, and now it is time to share\r\nthe details more publicly.\r\nEmotet is a prolific and highly successful email-based malware, with a primary focus on email theft and loading\r\nadditional malware as a service. Most commonly identified by its three distinct botnets and fairly obfuscated code\r\nflow, Emotet is a unique and persistent threat to organizations of all sizes. \r\nUnique threats require unique solutions, which is why Binary Defense developed a killswitch exploiting a simple\r\nbuffer overflow found in Emotet’s installation process and shared it freely with the infosec community, avoiding\r\npublic channels to ensure maximum uptime of the exploit before the threat actors behind Emotet patched their\r\nmalware to close the vulnerability. This killswitch was alive between Feb 6th, 2020 – Aug 6th, 2020, or 182 days.\r\nclass=\r\nEmotet’s “New” persistence mechanism\r\nIn early February of this year, Emotet released a massive codebase overhaul, changing several of the installation\r\nand persistence mechanisms and introducing a polymorphic state-machine to their code flow. This added a layer of\r\nobfuscation to the loader, making analysis more difficult. One of the key changes was the removal of the word list\r\nand file generation algorithm used by Emotet during previous Emotet installs.\r\nIn its place was a new algorithm that generated a filename to save the malware on each victim system, using a\r\nrandomly chosen exe or dll system filename from the system32 directory. This filename was encrypted (encoded)\r\nwith an exclusive OR (XOR) key and saved into a registry value set to the victim’s volume serial number.\r\nAdditionally, the XOR key was set to the volume serial number in little endian format.  \r\nhttps://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/\r\nPage 1 of 6\n\nFig 1, Emotet installed key\r\nKillswitch, V1\r\nAround 37 hours after Emotet unveiled these changes, Binary Defense threat researcher James Quinn finished the\r\nfirst version of the killswitch/vaccine that eventually became EmoCrash. In the early days of this protection\r\nmethod, the PowerShell script would generate the registry key value for each victim and set the data for each\r\nvalue to null. \r\nWhen Emotet would check Registry for the install marker, it would find the newly-generated null value and\r\ngenerate the exe name “.exe”. It would then search the normal install location for this exe (%AppdataLocal%,\r\nC:WindowsSystem32,C:WindowsSyswow64, based on environment). If it didn’t find it, it would drop a file to the\r\nnormal install location called “.exe”. However, when the malware attempts to execute “.exe”, it would be unable\r\nto run because “.” translates to the current working directory for many operating systems.\r\nWhile this mechanism worked, it was very messy and still allowed Emotet to install—it just prevented Emotet\r\nfrom running successfully and reaching out over the network. Worried about lack of deployment due to the\r\nmessiness of the protection mechanism, and the additional concern that it makes cleanup difficult, Binary Defense\r\ncontinued experimenting with the killswitch, looking for ways to increase its effectiveness.\r\nKillswitch, V2\r\nAround 48 hours after Emotet released the newest loader version, Binary Defense completed the second version of\r\nthe killswitch. This version exploited a simple buffer overflow discovered in Emotet’s installation routine which\r\ncaused Emotet to crash during malware install, but before the malware would drop itself to the normal Emotet\r\ninstall locations, thus completely preventing malware installation. Additionally, two crash logs would appear with\r\nevent ID 1000 and 1001, which could be used to identify endpoints with disabled and dead Emotet binaries after\r\ndeployment of the killswitch (and a computer restart).\r\nhttps://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/\r\nPage 2 of 6\n\nPackaged into a nice usable PowerShell script (which we named EmoCrash), this utility would identify the user’s\r\narchitecture and then generate the corresponding install registry value for the user’s volume serial number. It\r\nwould then generate a buffer of 0x340 (832) bytes, which it would save to the new registry value’s data. \r\nThis tiny data buffer was all that was needed to crash Emotet, and could even be deployed prior to infection (like a\r\nvaccine) or mid-infection (like a killswitch).\r\nExploit Release\r\nWith an incredible amount of coordinating between the Infosec and CERT communities, especially those at Team\r\nCymru who helped immensely with this, Binary Defense began distributing the EmoCrash exploit script to\r\ndefenders around the world on Feb 12, 2020, with strict instructions not to post it publicly. As our goal was to\r\nmaximize the amount of good done by this exploit while also avoiding tipping off the threat actors and allowing\r\nthem to patch their code, Binary Defense set the information disclosure rules to TLP:Green, which limits\r\ndisclosure to non-public channels.\r\nAs we began disclosing the exploit to the community, we received a lot of helpful feedback, including a fix to\r\nsome compatibility issues that arose with Windows 7 deployments, contributed by the CERT at the University of\r\nFrankfurt in Germany. We would like to offer our most sincere thanks and appreciation to the members of the\r\ninformation security community around the world who worked to help keep this killswitch a secret from attackers\r\nwhile widely distributing it to defenders.\r\nEmotet Enters “dev mode”\r\nAround Feb 7th, Emotet entered a period of time where they stopped spamming and began working on developing\r\ntheir malware. This time period stretched from Feb 7 – July 17, 2020. While their spam distribution was\r\ncompletely halted, they were not “inactive” during this time, as they continued to push out a few core binary\r\nupdates and protocol updates. Additionally, Emotet was observed using Trickbot for loads as early as April 2,\r\n2020.\r\nhttps://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/\r\nPage 3 of 6\n\nApril 2020 Update\r\nIn mid April, Emotet released a new protocol change, along with changes to the core binary. One of the key\r\nchanges was the introduction of a new installation method, retiring the Explorer registry key method. Additionally,\r\nthis new update removed the use of concurrency mutexes, possibly in a bid to evade other more public\r\nkillswitches. \r\nWhile the Explorer registry key install method was retired, it was not removed entirely from the code. Instead, the\r\nexplorer registry key was accessed by the malware when it checked to see if there were old installs that needed\r\nremoving. \r\nWhen it accessed this key, EmoCrash still triggered and would crash the malware before it could communicate\r\nout. Unfortunately, this crash would trigger after Emotet had installed itself (including service creation and file\r\ndrop). However, the malware would not connect out and the service would not run. Additionally, as the crash still\r\ntriggered event ID 1000 and 1001, responders were able to easily locate and remove these files. \r\nhttps://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/\r\nPage 4 of 6\n\nFig 2, Conveniently, Emotet would crash right before data stolen was formatted and sent to the C2\r\nMay 2020 – July 17, 2020\r\nWhile Emotet did not return in force until July 17, 2020, Binary Defense received notifications from various\r\norganizations that had deployed EmoCrash and found and mitigated an ongoing Emotet infection. As Emotet was\r\nnot spamming during this time, the loss of entire victim organizations had to have a negative impact on the\r\nbotnet’s operations.\r\nJuly 17 – August 6, 2020\r\nOn July 17, 2020, Emotet finally returned to spamming after their several months-long development period. With\r\nEmoCrash still active at the start of their full return, up until August 6, EmoCrash was able to provide total\r\nprotection from Emotet. \r\nNot bad for a 832-byte buffer!\r\nOn August 6th, a core loader update was sent out which finally removed the vulnerable registry value code,\r\neffectively “killing” EmoCrash.\r\nThank you to the security community\r\nAs stated above, we’d like to offer our sincerest thanks to everyone who worked hard to keep this exploit alive as\r\nlong as possible. A huge thank you to Team Cymru for all the work they did to spread this throughout the\r\ncommunity (while also keeping it off public channels). \r\nJust for fun, I submitted a vulnerability report to MITRE’s CVE program to see if they would assign it a CVE\r\nnumber. It is for the best that it was denied, since public disclosure would have been exactly the opposite of what\r\nwe wanted, but it was fun to get a denial from MITRE about it.\r\nhttps://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/\r\nPage 5 of 6\n\nSource: https://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/\r\nhttps://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/"
	],
	"report_names": [
		"emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense"
	],
	"threat_actors": [],
	"ts_created_at": 1775434922,
	"ts_updated_at": 1775791242,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/83481f52a6b2bce97e3ef453960195f55651cd05.pdf",
		"text": "https://archive.orkl.eu/83481f52a6b2bce97e3ef453960195f55651cd05.txt",
		"img": "https://archive.orkl.eu/83481f52a6b2bce97e3ef453960195f55651cd05.jpg"
	}
}