{
	"id": "0959fe29-424e-48da-8544-42a933abbb69",
	"created_at": "2026-04-06T00:15:11.030921Z",
	"updated_at": "2026-04-10T03:21:17.512644Z",
	"deleted_at": null,
	"sha1_hash": "8c59f2e7410b0660a0e184acd1cee23162d8e2d1",
	"title": "A coin miner with a \"Heaven's Gate\" | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 334647,
	"plain_text": "A coin miner with a \"Heaven's Gate\" | Malwarebytes Labs\r\nBy hasherezade\r\nPublished: 2018-01-16 · Archived: 2026-04-05 14:52:23 UTC\r\nYou might call the last two years the years of ransomware. Ransomware was, without a doubt, the most popular\r\ntype of malware. But at the end of last year, we started observing that ransomware was losing its popularity to\r\ncoin miners. It is very much possible that this trend will grow as 2018 progresses.\r\nFrom the point of view of the victim, this is a huge relief, because miners are not as much of a threat as\r\nransomware. They slow down the system, yes, but once you get rid of them you can continue using your computer\r\nas before. No data is stolen, or lost as in the case with a ransomware infection.\r\nFrom the point of view of a malware researcher, miners are so far disappointing. They don’t give enough\r\ninteresting material for a deeper analysis, mostly because they are based on well-known open source components\r\nwith little or no obfuscation.\r\nHowever, from time to time, we find coin miners incorporating interesting tricks. In one recent sample, we\r\nobserved a technique called “Heaven’s Gate” that allows the malware to make injections to 64-bit processes from\r\n32-bit loaders. This trick is not new—its introduction is dated to 2009—but it’s curious to see it implemented in\r\nthis new sample captured in wild.\r\nThose who are beginners in malware analysis can read on for a guide about what Heaven’s Gate is and how to\r\napproach analyzing it.\r\nAnalyzed samples\r\n7b3491e0028d443f11989efaeb0fbec2 – dropper #1\r\nThis sample was found in the continuation of the Ngay campaign (more about it here). A background check on\r\nsimilar samples lead me to the article of @_qaz_qaz, who described an earlier campaign with a similar sample.\r\nHowever, his analysis skipped details on the Heaven’s Gate technique.\r\ned575ba72ea8b41ac2c31c8c39ce303b – dropper #2\r\nca54fa2cf8a7e3e2cd457811f336de44 – loader 32-bit (unpacked first stage)\r\nBehavioral analysis\r\nTo observe the mentioned injection, we must run the sample on a 64-bit system. We can see that it runs an instance\r\nof notepad, with parameters typical for mining cryptocurrency:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 1 of 11\n\nLooking at the in-memory strings in ProcessExplorer, we can clearly see that it is not a real notepad running, but\r\nthe xmrig Monero miner:\r\nSo, at this moment we’re confident that the notepad’s image has been replaced in memory, most probably by the\r\nRunPE (Process Hollowing) technique.\r\nThe main dropper is 32-bit, but it injects a payload into a 64-bit notepad:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 2 of 11\n\nThe fun part is that this type of injection is not supported by the official Windows API. We can read/write the\r\nmemory of 32-bit processes from a 64-bit application (using Wow64 API), but not the other way around.\r\nThere are, however, some unofficial solutions to this, such as the technique called “Heaven’s Gate.”\r\nHeaven’s Gate overview\r\nThe Heaven’s Gate technique was first described in 2009, by a hacker nicknamed Roy G. Biv. Later, many\r\nadaptations were created, such as a library Wow64ext  or, basing in it, W64oWoW64. In the blog post from 2015,\r\nAlex Ionescu described mitigations against this technique.\r\nBut let’s have a look at how it works.\r\nRunning 32-bit processes on 64-bit Windows\r\nEvery 32-bit process that runs on a 64-bit version of Windows runs in a special subsystem called WoW64 that\r\nemulates the 32-bit environment. We can explain it as a 32-bit sandbox that is created inside a 64-bit process. So,\r\nfirst the 64-bit environment for the process is created. Then, inside it, the 32-bit environment is created. The\r\napplication is executed in this 32-bit environment and it has no access to the 64-bit part.\r\nIf we scan the 32-bit process from outside, via the 64-bit scanner, we can see that it has inside both 32 and 64\r\nDLLs. Most importantly, it has two versions of NTDLL: 32-bit (loaded from a directory SysWow64) and 64-bit\r\n(loaded from a directory System32):\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 3 of 11\n\nHowever, the 32-bit process itself can’t see the 64-bit part and is limited to using the 32-bit DLLs. To make an\r\ninjection to a 64-bit process, we’d need to use the 64-bit versions of appropriate functions.\r\nCode segments\r\nIn order to access the forbidden part of the environment, we need to understand how the isolation is made. It turns\r\nout that it’s quite simple. The 32- and 64-bit code execution is accessible via a different address of the code\r\nsegment: 32-bit is 0x23 and 64-bit is 0x33.\r\nIf we call an address in a typical way, the mode that is used to interpret it is the one set by default. However, we\r\ncan explicitly request to change it using assembler instructions.\r\nInside the miner: the Heaven’s Gate implementation\r\nI will not do a full analysis of this miner because it has already been described here. Let’s jump directly to the\r\nplace where the fun begins. The malware checks its environment, and if it finds that it’s running on a 64-bit\r\nsystem, it takes a different path to make an injection into a 64-bit process:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 4 of 11\n\nAfter some anti-analysis checks, it creates a new, suspended 64-bit process (in this case, it is a notepad):\r\nThis is the target into which the malicious payload is going to be injected.\r\nAs we discussed before, in order to inject the payload into a 64-bit process, we need to use the appropriate 64-bit\r\nfunctions.\r\nFirst, the loader takes a handle to a 64-bit NTDLL:\r\nWhat happens inside this function get_ntdll requires some deeper explanation. As a reference, we can also\r\nhave a look at the analogical code in the ReWolf’s library.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 5 of 11\n\nTo get access to the 64-bit part of the process environment, we need to manipulate the segments selectors. Let’s\r\nsee how our malware enters the 64-bit mode:\r\nThis code seems to be directly copied from the open source library: https://github.com/rwfpl/rewolf-wow64ext/blob/master/src/internal.h#L26\r\nThe segment selector 0x33 is pushed on the stack. Then, the malware calls the next line: (By this way, the next\r\nline’s address is also pushed on the stack.)\r\nAn address that was pushed is fixed by adding 5 bytes and set after the retf :\r\nAt the end, the instruction RETF is called. RETF is a “far return,” and in contrast to the casual RET, it allows to\r\nspecify not only the address where the execution should return, but also the segment. It takes as arguments two\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 6 of 11\n\nDWORDs from the stack. So, when the RETF is hit, the actual return address is: 0x33:0x402A50 Thanks to the\r\nchanged segment, the code that starts at the specified address is interpreted as 64-bit. So, the code that is visible\r\nunder the debugger as 32-bit…\r\n…is, in reality, 64-bit.\r\nFor the fast switching of those views, I used a feature of PE-bear:\r\nAnd this is how this piece of code looks, if it is interpreted as 64-bit:\r\nSo, the code that is executed here is responsible for moving the content of the R12 register into a variable on the\r\nstack, and then switching back to the 32-bit mode. This is done for the purpose of getting 64bit Thread\r\nEnvironment Block (TEB), from which next we fetch the 64-bit Process Environment Block (PEB) —check the\r\nanalogical code.\r\nThe 64-bit PEB is used as a starting point to search the 64-bit version of NTDLL. This part is implemented in a\r\ncasual way (a “vanilla” implementation of this technique can be found here) using a pointer to the loaded libraries\r\nthat is one of the fields in the PEB structure. So, from PEB we get a field called Ldr :\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 7 of 11\n\nLdr is a structure of the type _PEB_LDR_DATA . It contains an entry called\r\nInMemoryOrderModuleList\r\n:\r\nThis list contains all the loaded DLLs that are present in the memory of the examined process. We browse through\r\nthis list until we find the DLL of our interest that, in this case, is NTDLL. This is exactly what the mentioned\r\nfunction get_ntdll does. In order to find the appropriate name, it calls the following function—denoted as \r\nis_ntdll_lib\r\n—that checks the name of the library character-by-character and compares it with ntdll.dll. It is an equivalent of\r\nthis code.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 8 of 11\n\nIf the name matches, the address to the library is returned in a pair of registers:\r\nOnce we found NTDLL, we just needed to fetch addresses of the appropriate functions. We did this by browsing\r\nthe exports table of the DLL:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 9 of 11\n\nThe following functions are being fetched:\r\nNttUnmapViewOfSection\r\nNtGetContextThread\r\nNtAllocateVirtualMemory\r\nNtReadVirtualMemory\r\nNtWriteVirtualMemory\r\nNtSetContextThread\r\nAs we know, those functions are typical for RunPE technique. First, the\r\nNtUnmapViewOfSection\r\nis used to unmap the original PE file. Then, memory in the remote process is allocated, and the new PE is written.\r\nAt the end, the context of the process is changed to start the execution from the injected module.\r\nThe addresses of the functions are saved and later called (similarly to this code) to manipulate the remote process.\r\nConclusion\r\nSo far, authors of coin miners don’t show a lot of creativity. They achieve their goals by heavily relying on open-source components. The described case also shows this tendency – they made use of a ready made\r\nimplementation.\r\nThe Heaven’s Gate technique has been around for several years. Some malware use it for the purpose of being\r\nstealthy. But in case of this coin miner, authors probably aimed rather to maximize performance by using a\r\npayload version that best fit the target architecture.\r\nAbout the author\r\nUnpacks malware with as much joy as a kid unpacking candies.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 10 of 11\n\nSource: https://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/"
	],
	"report_names": [
		"a-coin-miner-with-a-heavens-gate"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434511,
	"ts_updated_at": 1775791277,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8c59f2e7410b0660a0e184acd1cee23162d8e2d1.pdf",
		"text": "https://archive.orkl.eu/8c59f2e7410b0660a0e184acd1cee23162d8e2d1.txt",
		"img": "https://archive.orkl.eu/8c59f2e7410b0660a0e184acd1cee23162d8e2d1.jpg"
	}
}