{
	"id": "c4803391-4b04-4fbc-8b68-f9504aa5a76f",
	"created_at": "2026-04-06T01:29:24.21683Z",
	"updated_at": "2026-04-10T03:21:16.201073Z",
	"deleted_at": null,
	"sha1_hash": "dc5707c1fc3058150c08860517d4f325984aa634",
	"title": "Emotet malware analysis. Part 2.",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 709467,
	"plain_text": "Emotet malware analysis. Part 2.\r\nPublished: 2019-04-07 · Archived: 2026-04-06 00:09:17 UTC\r\n=== Apr 7, 2019 ===\r\nThis is the Part 2 of my Emotet analysis. It covers phase 3 of the attack, specifically the PE file which is being\r\ndropped by infected websites, used in Phishing/Spam campaigns. Emotet is an advanced modular Trojan,\r\npredominantly used as Malware Distribution Platform, main goal being systems infection with other types of\r\nmalware.\r\nMore information about phases 1 and 2: HERE\r\nGeneral information.\r\nPhase 3 of this version of Emotet attack is characterized by the new version of executable. Malware authors spent\r\nsome time to make it harder to analyze, by implementing multiple Anti-Debugging techniques, loading Windows\r\nDLLs dynamically, encrypting imported functions names, several unpacking stages, and so on.\r\nFile name Checksum Hosted at\r\nDFDWiz.exe cebb919d8d04f224b78181a4d3f0b10a315ae2f2 hxxp://biederman.net/leslie/lL/\r\nBased on IAT information, there are several Windows DLLs this binary is loading: kernel32.dll , user32.dll ,\r\ngdi32.dll , advapi32.dll , shell32.dll and shlwapi.dll .\r\nAt the first glance, the binary doesn’t import any “red flag” functions, usually used by packers.\r\nLet’s load this sample in IDA and check for any details that can help in upcoming dynamic analysis. From the\r\nmultitude of imported functions, listed in IAT, there are only few used (visible at least). One of them is\r\nhttps://persianov.net/emotet-malware-analysis-part-2\r\nPage 1 of 7\n\nVirtualAlloc , which points to a possible custom packer.\r\nSome other clues showing that this binary is packed are call s to pointers to data segment:\r\nDynamic analysis. Unpacking.\r\nFor the dynamic analysis of this sample, I’m going to use x32dbg . Based on the report from Hybrid Analysis,\r\nlooks like this sample creates 2 new processes, once executed: copy of itself and a second process with a different\r\nhttps://persianov.net/emotet-malware-analysis-part-2\r\nPage 2 of 7\n\nname. This is the packed PE file, which is embedded into the first sample.\r\nMost probably, parent process will call one of the CreateProcess* Windows API functions. Since 2018,\r\nMicrosoft moved some functionality from kernel32.dll and advapi32.dll to new low-level binary, called\r\nkernelbase.dll . If we take a look at CreateProcessA and CreateProcessAsUserA in kernel32.dll, the only\r\nthing we can see are several mov and push instructions, followed by a jump, to kernelbase.dll equivalent\r\nfunction.\r\nFollowing the thread to kernelbase.dll, we see that CreateProcessA function contains a bunch of another push\r\ninstructions followed by a call to CreateProcessInternalA . Same happens for CreateProcessAsUserA .\r\nhttps://persianov.net/emotet-malware-analysis-part-2\r\nPage 3 of 7\n\nTo keep this short, the overall call chain looks like this:\r\n[kernel32.dll] CreateProcessA -\u003e [kernelbase.dll] CreateProcessA -\u003e [kernelbase.dll] CreateProcessInternalA\r\n-\u003e [kernelbase.dll] CreateProcessInternalW\r\nIt means that for any CreateProcess* function call, we’ll get CreateProcessInternalW called right before\r\nprocess creation. If we set a breakpoint at the beginning of this function, we possibly could find the unpacked\r\nbinary, which is going to be injected into the new process. Once we hit the breakpoint, there are 4 memory regions\r\nwith ERW (Execute-Read-Write) flags set. 3/4 are PE files, based on the header.\r\nOnce all of them are dumped and properly aligned, we can proceed with the second phase of analysis.\r\nDynamic analysis. Dumped binaries.\r\nAll 3 exported binaries look the same, even if they have different checksums. IAT table is empty, which means\r\nthat malware loads dependencies in runtime. There are no API function names in binary’s strings, which implies\r\nthat all API function names are encrypted as well as library names.\r\nThe execution starts with 3 function calls.\r\nhttps://persianov.net/emotet-malware-analysis-part-2\r\nPage 4 of 7\n\nFirst 2 functions contain encrypted names of the APIs this sample is going to load dynamically. These functions\r\ncall another one, once all encrypted values are loaded to stack. The sub_401550 looks to be responsible for\r\ndecryption.\r\nSo far, I was able to detect 4 DLLs loaded dynamically by this sample: kernel32.dll , user32.dll ,\r\nntdll.dll , shell32.dll .\r\nIn order to run just one copy of it, this sample checks if a specific MUTEX exists and creates it, if missing.\r\nMUTEX name is: PEMF24 .\r\nhttps://persianov.net/emotet-malware-analysis-part-2\r\nPage 5 of 7\n\nOnce MUTEX is checked/created, malware looks for Windows directory to copy itself there, as well as into\r\n%APPDATA% folder. This time, the new binary is named differently and this name is generated in runtime by\r\nconcatenating 2 strings (in my case it was ipropslide.exe ). All possible strings are stored in memory at some\r\npoint.\r\nOnce the new process is created, it starts looking for host information like Computer Name and Volume info and\r\nC2 communication begins.\r\nAfter some patching during debugging and several failures =)) I was able to get some details about the C2\r\ncommunication part. Sample tries to connect to 3 IP addresses (round robin?)\r\nhttps://persianov.net/emotet-malware-analysis-part-2\r\nPage 6 of 7\n\nIP Address\r\nDestination\r\nPort\r\nProtocol User Agent\r\n45.36.20[.]17 8443 HTTP\r\nMozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;\r\n.NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET\r\nCLR 3.5.21022)\r\n103.39.131[.]88 80 HTTP\r\nMozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;\r\n.NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET\r\nCLR 3.5.21022)\r\n86.239.117[.]57 8090 HTTP\r\nMozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;\r\n.NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET\r\nCLR 3.5.21022)\r\nConclusion.\r\nMalware authors did a good effort in packing this malware and introducing different layers of defence. It wasn’t\r\ntoo difficult to bypass those layers, however taking into consideration how often a new Emotet version is released\r\nand the changes to the binary, the analysis becomes time consuming in the long term. Sending HTTP traffic to\r\nnon-standard destination ports, like 8090 , is not the best way to keep a low profile in a compromised network.\r\nMost businesses have to treat this type of traffic as suspicious nowadays and maintain a clean asset inventory.\r\nSource: https://persianov.net/emotet-malware-analysis-part-2\r\nhttps://persianov.net/emotet-malware-analysis-part-2\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://persianov.net/emotet-malware-analysis-part-2"
	],
	"report_names": [
		"emotet-malware-analysis-part-2"
	],
	"threat_actors": [],
	"ts_created_at": 1775438964,
	"ts_updated_at": 1775791276,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dc5707c1fc3058150c08860517d4f325984aa634.pdf",
		"text": "https://archive.orkl.eu/dc5707c1fc3058150c08860517d4f325984aa634.txt",
		"img": "https://archive.orkl.eu/dc5707c1fc3058150c08860517d4f325984aa634.jpg"
	}
}