{
	"id": "cfddb2a8-3d43-44ef-9f1f-379d63653b46",
	"created_at": "2026-04-06T00:21:35.107524Z",
	"updated_at": "2026-04-10T03:28:20.589197Z",
	"deleted_at": null,
	"sha1_hash": "5afd3153e6ad3e89580fb70484f22ecf7e70873d",
	"title": "Emotet: The Tricky Trojan that 'Git Clones' - Check Point Research",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 66873,
	"plain_text": "Emotet: The Tricky Trojan that 'Git Clones' - Check Point\r\nResearch\r\nBy deugenio\r\nPublished: 2018-07-24 · Archived: 2026-04-05 18:30:55 UTC\r\nResearch by: Ofer Caspi, Ben Herzog\r\nThe Emotet Trojan downloader originally debuted in 2014 as a banking Trojan that took an unusual approach to\r\nstealing banking credentials; Instead of hooking per-browser functions in the victim’s web browser process,\r\nEmotet directly hooked network API functions.\r\nFour years have passed since 2014 and Emotet continues to be a point of interest; not many would-be botnets live\r\nto see their fourth birthday. With their ear to the ground on Twitter,  analysts have been rather preoccupied with\r\nEmotet – and for good reason. Despite its age, Emotet is far from just barely alive. It spreads itself abundantly\r\nthrough spam emails, network shares and the Rig Exploit Kit. While some features have stayed constant, during\r\nthe four years of Emotet’s lifecycle, modules have come and gone. Most significantly, the banking module,\r\npreviously the malware’s core functionality, was removed at some point in 2017.\r\nFigure 1: A comparative heat map of Emotet’s impact per country (measured by number of affected\r\norganizations). Red indicates a larger amount of organizations affected.\r\nThere are several things that stand out about Emotet, but foremost among them is its modular structure and\r\ncomplex ecosystem. To have a working business model, it is technically enough to have The C\u0026C server say\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 1 of 10\n\n“here, take this file and execute it”. As a result, it’s not every botnet that bothers to set up an ecosystem of\r\nmodules, let alone one that even has the concept of a “version”. But Emotet does, including a communication\r\nprotocol built on top of Google’s Protobuf, utilizing LZMA compression and built on asymmetric crypto. The\r\nauthors would probably take “over-engineered” as a compliment.\r\nThe use of Protobuf is not an isolated incident. Emotet is uncharacteristically eager to employ third-party open\r\nsource code. Most malware authors just can’t be bothered to do a literature review of existing solutions to their\r\nproblem, and would rather re-invent the wheel. Some authors do admit defeat and incorporate one-or-another\r\npiece of third-party code into their creation, but that’s still nothing compared to the leap made by the Emotet team,\r\nwhose code directory tree literally has an “Open Source” folder in it. Apart from communication protocols\r\nimplemented with Protobuf, Emotet features, for example, web servers written in Libevent and encryption built on\r\ntop of OpenSSL. In the category of conspicuous interest in the open source community, this puts Emotet squarely\r\nahead of the vast majority of malware (and narrowly behind Microsoft).\r\nEmotet is invested in the technical cat-and-mouse game of malware ‘author vs. analyst’ more than could possibly\r\nbe healthy (for either the author or the analyst). Where the GandCrab guys went for banter and spectacle, the\r\nEmotet team went with a grim, humorless determination to use every method they could think of to stick it to the\r\nman with the disassembler.\r\nJust one example — in Code Obfuscation 101 you read about “converting control flow structures into a state\r\nmachine”; it then remains one of those things-that-could-theoretically-be-done, like using difficult opaque\r\npredicates or compiling the malware with The Movfuscator. Emotet goes and actually uses a state machine for its\r\nmain control flow.\r\nFigure 2: Libevent strings from Emotet – or, as we’ve recently taken to calling it, GNU/Emotet.\r\nTechnical Details\r\nMain Module / Dropper\r\nThe main functionality of Emotet’s dropper is three-fold:\r\n1. Update the malware to its latest version.\r\n2. Achieve persistence on the victim system.\r\n3. Download and execute the modules, which serve as the malware’s main payload.\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 2 of 10\n\nBy updating itself with high frequency and constantly rotating its C\u0026C servers, Emotet stays ahead of signature-based AV products and manages to retain the foothold that it has in the botnet arena. This same principle applies to\r\nthe dropper executable itself, hosted on Emotet’s C\u0026C server. Frequently rotating it, and the accompanying\r\nmodules, makes sure that during at least the few following hours, AV signatures will not be able to simply pattern-match the files as malicious, and will have to rely on more advanced and more delicate methods such as ML\r\nengines and behavioral analysis. The dropper is packed, and while it is constantly rotated, most of the\r\nfunctionality stays constant and changes tend to be minor.\r\nAs is standard for malware strains of this type, the Emotet dropper collects information from the infected machine\r\nsuch as the Computer and User name, OS version, and the list of processes running on the victim machine.\r\nOnce all this information is gathered and the malware is updated to its latest version, Emotet sends a request to the\r\nC\u0026C server. Addresses of potential live C\u0026C servers, and the Emotet servers’ RSA public key, are all hard-coded\r\nin the malware executable. The addresses are in plain IP format followed by a port number (somewhat atypically;\r\nmalware authors usually favor domain names). Communication is encrypted with a randomly-generated AES key,\r\nwhich is encrypted using the server public key and appended to the message. This protocol is unusually\r\ncryptographically sound and even a person with full access to the malware sample and a traffic log will be unable\r\nto recover the original communication, unless the original process that spawned the AES key is still running.\r\nAssuming the request successfully goes through, the C\u0026C server responds with an up-to-date list of modules.\r\nUsually during this transaction the infected client will receive between 2 and 5 modules; the exact number\r\ndepends on the information an infected system sends to the C\u0026C. The request method periodically rotates\r\nbetween a GET and a POST, probably as a small gesture to further frustrate attempts to communicate with the\r\nserver directly. When using GET, the request body is instead sent as the cookie header.\r\nAs a part of the request, the infected host will include the current malware file hash; the server uses this\r\ninformation to decide whether the Emotet version that issued the request needs to be updated. If the hash is of an\r\nold version of the malware, a new Emotet version is sent; otherwise, execution proceeds as described above, and\r\nthe modules are executed. When responding, the C\u0026C server uses the same AES key that the client sent originally.\r\nOn a typical malware, these communications would take place over raw TCP or HTTP, and would probably use\r\nGET request parameters or some homebrew format in the request body to transfer information. Encryption or\r\nobfuscation might be used, but the underlying protocol is almost invariably of this “deadline is due tomorrow”\r\nkind. In contrast, Emotet’s messages are constructed and parsed using Protocol Buffers (“ProtoBuf”), Google’s\r\n“language-neutral, platform-neutral, extensible mechanism for serializing structured data”.\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 3 of 10\n\nFigure 3: The latest protobuf definition structure that the malware has been seen to use.\r\nFigure 4: Decompiled code that builds the registration request sent to the C\u0026C server.\r\nFigure 5: Overall structure of the registration request being sent.\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 4 of 10\n\nFigure 6: A sample traffic capture of an Emotet client request and the server response.\r\nEmotet’s Modules\r\nEmotet’s modules have come and gone over the years. The large variety we have observed over time leads us to\r\nthe conclusion that a module may be tailored to the customer, if the price is right. Based on what we know, we\r\nestimate the price of Emotet to be somewhere in the $2000 range.\r\nEmotet’s modules that we’ve seen in the wild so far all share the same general structure: They are DLL files, not\r\npacked but otherwise moderately obfuscated. First, a homebrew Import Table is constructed by dedicated\r\nfunctions comparing against the functions’ hash value by a homebrew hash function. This is similar, but not\r\nidentical, to methods of full dynamic resolution commonly seen in malware, where every call to a function passes\r\nthrough a “filter” which searches for that function by hash. Here, all the functions are resolved first, and the main\r\nflow is reached later. This has the effect of making analysis somewhat less of a hassle. All DLL names, function\r\nnames and other incriminating strings are obfuscated using a simple rotating XOR cipher (the decryption function\r\nfor which is, itself, obfuscated to make it look rather more complicated than it really is).\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 5 of 10\n\nFigure 7: Emotet feeds precomputed function name hash values to its name resolution routine.\r\nOnce function resolution is done, the module typically proceeds to its main functionality. Here the modules can be\r\nseparated, in broad strokes, into two types: the “wrapper” modules and the “original” modules.\r\n“Wrapper” modules are modules that are thin wrappers for ready-made data mining executables courtesy\r\nof Nirsoft. Under this category, one might find a module dedicated to mining credentials stored in the user’s web\r\nbrowser, which is just a thin wrapper for the freeware tool WebBrowserPassView, a whole copy of which is\r\nembedded into the malware (and encrypted using rotating XOR). Similarly, there is an “email credential stealer”\r\nmodule which is a wrapper for MailPassView.\r\nFigure 8: WebBrowserPassView, when not used in headless mode.\r\n“Original” modules have been implemented from scratch by Emotet’s author. Their tactics vary, but our general\r\nimpression is that most of these do not directly subvert / monetize the victim (as do miners, backdoors,\r\nransomware, etc), and are instead aimed at getting more people infected with Emotet. For instance, one of the\r\nmodules uses the deprecated Simple MAPI interface in order to harvest the list of MS-Outlook’s locally stored\r\nemail addresses, which are later used to send Emotet Spam. Even more straightforward is the “Worm” module,\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 6 of 10\n\nwhich has a built-in table of passwords that it uses to try and brute-force accessible SMB shares, so it can infect\r\nmore stations on the LAN with Emotet.\r\nFigure 9: Emotet uses the deprecated Simple MAPI to harvest email addresses.\r\nFigure 10: Emotet’s table of common passwords to try against SMB share accounts.\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 7 of 10\n\nFigure 11: Typical spam message sent by Emotet.\r\nOne last curiosity that we have seen is a rather convoluted module that was linked with the libevent library and\r\nupnp functionality. Upnp was used to enable port forwarding and make the victim machine accessible from the\r\nWAN, whereas Libevent was used to set up a simple server that answers with an “EHLO” to incoming packets.\r\nThis seems to be some sort of PoC or sanity check, checking if the compromised machine has been successfully\r\nmade accessible from the outside, and is available for the C\u0026C to initiate contact with.\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 8 of 10\n\nFigure 12: The single block of actual user-authored functionality in a 672-function module.\r\nSome Samples\r\nDuring our research, we found it difficult to obtain Emotet modules for testing. Few of the (excellent) write-ups\r\non this strain of malware offered access to module hashes, and fewer still had the hashes identified by the module\r\nfunction or were available for download anywhere. Obtaining the modules independently requires direct\r\ncommunication using Emotet’s overwrought communication protocol, and then the modules themselves that you\r\nget are somewhat of a lottery (not to mention that, as described above, if you use an out-of-date executable or\r\nprotocol you get an updated version of Emotet instead of the modules; finding out about that was fun). Therefore,\r\nfor what it is worth, we have uploaded the above-mentioned modules to VirusTotal, and provide their hashes and\r\ndescriptions below. These were retrieved late May 2018. We hope they are of use to you.\r\nsha256 module purpose\r\nd4491f9b885bba06d7ee6e02e6e71272893638bbb92f2c23b9ddf52f8a26a702 Email address harvester\r\n621c0a11ee0100b8fc3190e471ed4936204e897d97394ba9614ec95f1b69c69C Email credential stealer\r\nd7efad30d0a56983fba15f0be28877bd7d55c723388005baa322b94c02540f11 Spam\r\n86cf916c547b6f228b8e7bd4667715db0467c3d141f6226e27025797aeca10ec Browser Credential Stealer\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 9 of 10\n\n022a5dfe18ee332c020a245cac64f4aa4fc5dd528f79923d00d8ffe376fc76da\r\nConnection Verifier /\r\n“EHLO” responder\r\nConclusion\r\nWith its years of experience and sophisticated ecosystem, Emotet seems to be here to stay. Its eagerness to make\r\nuse of open-source libraries, and “do the right thing” in general, is both refreshing and alarming. Easy access to\r\nthird-party libraries is known to be a powerful stimulant for any development process, and discipline in design\r\ndefinitely has its benefits, as well as its pitfalls. Who knows — maybe in a few years we will see enterprise-grade\r\nmalware written in Java which invokes RansomwareResourceMediator.getMediatorInstance() and\r\nMoneroMinerFactory.getAbstractMiner().\r\nDetection\r\nThe following Check Point products detect the Emotet Trojan:\r\nThreatCloud: as Emotet (Emotet.TC)\r\nThreat Emulation: as Worm.Win.Emotet.A or Worm.Win.Emotet.B\r\nSource: https://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nhttps://research.checkpoint.com/emotet-tricky-trojan-git-clones/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://research.checkpoint.com/emotet-tricky-trojan-git-clones/"
	],
	"report_names": [
		"emotet-tricky-trojan-git-clones"
	],
	"threat_actors": [
		{
			"id": "81dde5cc-c29f-430d-8c6e-e5e92d5015e7",
			"created_at": "2022-10-25T16:07:23.704358Z",
			"updated_at": "2026-04-10T02:00:04.718034Z",
			"deleted_at": null,
			"main_name": "Harvester",
			"aliases": [],
			"source_name": "ETDA:Harvester",
			"tools": [
				"Agentemis",
				"Cobalt Strike",
				"CobaltStrike",
				"Graphon",
				"Metasploit",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434895,
	"ts_updated_at": 1775791700,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5afd3153e6ad3e89580fb70484f22ecf7e70873d.pdf",
		"text": "https://archive.orkl.eu/5afd3153e6ad3e89580fb70484f22ecf7e70873d.txt",
		"img": "https://archive.orkl.eu/5afd3153e6ad3e89580fb70484f22ecf7e70873d.jpg"
	}
}