{
	"id": "9a273892-e882-4651-8055-75551b2ae1b2",
	"created_at": "2026-04-06T00:10:50.697937Z",
	"updated_at": "2026-04-10T13:12:59.427731Z",
	"deleted_at": null,
	"sha1_hash": "29c68c7defa091f2b1f4f3a3c49951235bc0cc27",
	"title": "Smoke Loader - downloader with a smokescreen still alive | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 671973,
	"plain_text": "Smoke Loader - downloader with a smokescreen still alive |\r\nMalwarebytes Labs\r\nBy Malwarebytes Labs\r\nPublished: 2016-08-04 · Archived: 2026-04-05 19:37:42 UTC\r\nThis time we will have a look at another payload from recent RIG EK campaign. It is Smoke Loader (Dofoil), a\r\nbot created several years ago – one of its early versions was advertised on the black market in 2011. Although\r\nthere were some periods of time in which it was not seen for quite a while, it doesn’t seems to plan retirement. The\r\ncurrently captured sample appears to be updated in 2015.\r\nThis small application is used to download other malware. What makes the bot interesting are various tricks that it\r\nuses for deception and self protection.\r\nWe will walk through the used techniques and compare the current sample with the older one (from 2014).\r\nAnalyzed samples\r\nMain focus of this analysis is the below sample, which is dropped by Rig EK:\r\nbce202c021feb61783563e21fc026767 – original sample\r\nd363e8356c82a1043bb300c12c6c7603 – unpacked (Stage#1)\r\n8932d2eacc4dfc7b2f0a94363a854610 – core DLL (Stage#2)\r\nThe above sample downloads: Payload:\r\nf60ba6b9d5285b834d844450b4db11fd   – (it is an IRC bot, C\u0026C: med-global-fox[DOT]com)\r\nUpdated Smoke Loader:\r\nbc305b3260557f2be7f92cbbf9f82975 – original sample\r\nc8ec8ecc47b05074f5136e79b680fe9e – unpacked (Stage#1)\r\n8932d2eacc4dfc7b2f0a94363a854610 – core DLL (Stage#2) – same as the previous sample\r\nDuring the analysis it will be compared against the old sample, first seen in September 2014\r\nefa7f95edacec888f39e5ce0ee675a95 – original sample (distributed via spam)\r\n266319c97292842ce554d53806449dda – unpacked (Stage#1)\r\nc52f0bf75bebf12a2e7a65b8c8af72d4– core DLL (Stage#2)\r\nBehavioral analysis\r\nAfter being deployed, Smoke Loader inject itself into explorer.exe and deletes the original executable. We can see\r\nit making new connections from inside the explorer process.\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 1 of 15\n\nInstallation and updates\r\nSmoke Loader not only installs its original sample but also replaces it with a fresh version, which is downloaded\r\nfrom the C\u0026C  –  path: http:///system32.exe. This trick makes detection more difficult – updated samples are\r\nrepacked by a different crypter, may also have their set of C\u0026Cs changed.\r\nDuring the current analysis, the initial sample of Smoke Loader dropped the following one:\r\nbc305b3260557f2be7f92cbbf9f82975\r\nSample is saved in a hidden subfolder, located in %APPDATA%:\r\nSmoke Loaded adds its current sample and all other downloaded executables to the Windows registry. Names of\r\nthe keys are randomly chosen among the names of existing entries:\r\nThis persistence method is pretty simple (comparing i.e. with Kovter), however there are some countermeasures\r\ntaken against detection of the main module. The timestamp of the dropped executable is changed, so that malware\r\ncannot be found by searching recently modified files. Access to the file is blocked – performing reading or writing\r\noperations on it is not possible.\r\nLoading other executables\r\nDuring its presence in the system it keeps downloading additional modules – “plugins”. First, the downloaded\r\nmodule is saved in %TEMP% under a random name and run. Then, it is moved to %APPDATA%. Below, we can\r\nsee that the payload established connection with its own separate C\u0026C:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 2 of 15\n\nThere is also a script in Autostart for deploying the payload:\r\nThe current sample’s C\u0026C addresses:\r\nsmoktruefalse.com\r\nprince-of-persia24.ru\r\nTraffic is partially encrypted.\r\nIn the examples below, we can see how the bot downloads from the C\u0026C other executables.\r\n1 – Updating the main bot with a new sample of Smoke Loader:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 3 of 15\n\n2 – Downloading the additional payload (“plugin”):\r\nPayload traffic\r\nSmoke Loader deploys the downloaded sample, so after some time we can see traffic generated by\r\nthe payload (connecting to med-global-fox.com). By its characteristics, we can conclude that this\r\ntime the\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 4 of 15\n\nInside\r\nLike most of the malware, Smoke Loader is distributed packed by some\r\nAfter removing the crypter layer, we can see the main Smoke Loader executable. However, more unpacking needs\r\nto be done in order to reach the malicious core. For the sake of convenience, I will refer to the code section of the\r\nunpacked sample as  Stage#1. Its execution starts in the Entry Point of the main executable and its role is to\r\nprovide additional obfuscation. It also serves as a loader for the most important piece: Stage#2 – this is a DLL,\r\nunpacked to a dynamically allocated memory and run from there.\r\nStage#1\r\nInteresting feature of this bot is that often its executables have one section only and no imports. Below you can see\r\nthe visualization of sections layout (Entry Point is marked red):\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 5 of 15\n\nCode at Entry Point is obfuscated and difficult to follow. It contains many redundant jumps, sometimes an address\r\nof a next jump is calculated on the fly – that’s why tools for static analysis cannot resolve them. Also, to make\r\nanalysis more difficult, the code modifies itself during execution.\r\nThe initial routine decrypts selected parts of the code section using XOR with a hardcoded value:\r\nAnd then it it calls it:\r\nThis is not the only way Smoke Loader modifies itself. In the unpacked part, we can see some more tricks. This\r\ncode uses many tiny jumps followed by XOR and LODS instructions to modify and displace code after every few\r\nsteps of execution. In between, junk instructions have been added to make it less readable:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 6 of 15\n\nThe bot loads all the necessary imports by its own. To achieve this goal, it deploys a variant of a popular method:\r\nsearching function handles in the loaded modules by calculating checksum of their names and comparing them\r\nwith hardcoded values. First, a handle to the loaded module is fetched with the help of Process Environment\r\nBlock (PEB)*:\r\nMOV ESI, FS:[30] ; copy to ESI handle to PEB MOV ESI, DS:[ESI+0xC] ; struct _PEB_LDR_DATA *Ldr MOV ES\r\n* read more about it here Below we can see the fragment of code that walks through exported functions of\r\nntdll.dll searching for a handle to the function: ZwAllocateVirtualMemory (using it’s checksum: 0x976055C), and\r\nthen saving the found handle in a variable:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 7 of 15\n\nThanks to this trick Smoke Loader can operate without having any import table. (The same method is utilized by\r\nStage#2 to fill its imports).\r\nThe stored handle is used to make an API call and allocate additional memory:\r\nIn this added memory space, Stage#2 is being unpacked. This new module is a PE file with headers removed (it is\r\na common anti-dumping technique). Below, you can see the part that was erased at the beginning of the file\r\n(marked red):\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 8 of 15\n\nIf we add the missing part, we can parse it as a typical PE file. It turns out to be a DLL exporting one function.\r\nExactly the same technique was used before by older versions of Dofoil. In the past, the name of the module was\r\nStub.dll and the exported function was Works. Now the names are substituted by garbage.\r\nThis piece is loaded by the dedicated function inside Stage#1, that takes care of all the actions typically performed\r\nby the Windows Loader.\r\nFirst the unpacked content is in raw format (Size of Headers: 0x400, File Alignment: 0x200):\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 9 of 15\n\nThen, the same content is realigned to a virtual format (unit size: 0x1000):\r\nAnother subroutine parses and applies relocations. As we can see below, it is a typical relocations table known\r\nfrom PE format. Entries are stored as a continuous array of WORDs:\r\nThe loader processes them one by one. First, it checks if the entry type is “32-bit field” (by TEST EAX,0x3000) –\r\nit is the only format supported in this case. Then, it fetches the relocation offset (AND EAX,0xFFF), gets the\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 10 of 15\n\npointed address and performs calculation – by removing old ImageBase (it’s value is hardcoded) and applying the\r\nnew base – offset to the dynamically allocated memory where the unpacked code was copied).\r\nFinally execution flow can be redirected to the new code. Stage#1 calls the exported function form the Stage#2\r\nDLL with three parameters.The first one is a string, different for each sample (this time it is “00018”):\r\nThe execution of Stage#2 starts inside the dynamically allocated section:\r\nAt this stage we can see some of the strings known from previous editions of Smoke Loader. String “2015” may\r\nsuggest that this version has been written in 2015 (however, compilation timestamp of the sample is more recent:\r\n10-th June 2016).\r\nStage#2\r\nWhile the previous stage was just a preparation, at Stage#2 the malicious functions are deployed. Its\r\nentry lies within the exported function that has the following header:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 11 of 15\n\nint __stdcall Work(char* sample_id, bool do_injection, char* file_path);\r\nBasing on those parameters, the executable recognize its current state and the execution path to\r\nfollow.\r\nBefore executing the real mission, the bot prepares a disguise – injecting its code into a legitimate process –\r\nexplorer.exe (more about it will be explained later). Whether this path should be deployed or not, it is specified by\r\nthe second parameter (denoted as do_injection).\r\nOnce it found the connection working, next it verifies whether or not the application is already running (using the\r\nmutex with a name unique for the particular machine).\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 12 of 15\n\nInjection to svchost.exe was just a fail-safe, and followed more classic way similar to this one. Functions used:\r\nCreateProcessInternalA NtCreateSection NtMapViewOfSection RtlMoveMemory NtUnmapViewOfSection NtQueueA\r\nThe current version dropped that idea in favor for another method (similar to this one) – adding a new section to\r\nthe remote process and copying its own code there. Functions used:\r\nCreateProcessInternalA NtQueryInformationProcess ReadProcessMemory NtCreateSection NtMapViewOfSection\r\nNow the only target of the injection is explorer.exe.\r\nIt patches Entry Point of explorer and adds there a code redirecting to the newly added section. That section\r\ncontains the injected Stage#2 DLL along with a small loader (similar to the one from Stage#1). Again, the loader\r\nprepares Stage#2 and deploys it – this time with different parameters:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 13 of 15\n\nReading the beacon, we can confirm that the currently analyzed version is higher than the previous one. The bot\r\nalso sends its ID, which is generated based on the GUID of particular system and the parameter typical for the\r\nparticular sample (i.e. “00018”).”\u003e\r\nThe program also reports to the C\u0026C if there was attempt to run it more than once (mutex locked):\r\n\"2015#D2C0431D4351DCD46E75D663AA9911B1448D3B2B#00018#6.1#0#0#10001#13#0\"\r\nConclusion\r\nIn the past Smoke Loader was extensively distributed via spam. Now we encountered it carried by an exploit kit.\r\nMany parts of the bot didn’t changed over the years, making this malware easy to identify. It still uses the same set\r\nof environment checks for its defense. Also, it waits for network accessibility in old style. The protocol used for its\r\ncommunication with the C\u0026C is now less descriptive – it doesn’t have so many keywords that identifies its\r\nperformed actions. Like the previous, traffic is encrypted. The core features also stayed the same and the main role\r\nof this malware is to download and deploy other modules.\r\nAppendix\r\nhttp://stopmalvertising.com/rootkits/analysis-of-smoke-loader.html\r\nhttps://blog.fortinet.com/2014/11/12/the-rebirth-of-dofoil\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\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 14 of 15\n\nSource: https://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"MITRE",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/"
	],
	"report_names": [
		"smoke-loader-downloader-with-a-smokescreen-still-alive"
	],
	"threat_actors": [],
	"ts_created_at": 1775434250,
	"ts_updated_at": 1775826779,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/29c68c7defa091f2b1f4f3a3c49951235bc0cc27.pdf",
		"text": "https://archive.orkl.eu/29c68c7defa091f2b1f4f3a3c49951235bc0cc27.txt",
		"img": "https://archive.orkl.eu/29c68c7defa091f2b1f4f3a3c49951235bc0cc27.jpg"
	}
}