{
	"id": "73bcdd40-24bb-4fcd-bca4-a96b2f2555ed",
	"created_at": "2026-04-06T00:15:27.300125Z",
	"updated_at": "2026-04-10T03:20:43.539774Z",
	"deleted_at": null,
	"sha1_hash": "aa26e82fafd4cb5e4078479478df647d5e191aeb",
	"title": "PowerLoader Injection – Something truly amazing",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 193532,
	"plain_text": "PowerLoader Injection – Something truly amazing\r\nBy Marcus Hutchins\r\nPublished: 2013-08-13 · Archived: 2026-04-05 17:54:21 UTC\r\nI’m not dead\r\nIt has been a while since i wrote an article (I’ve been pretty busy in real life), so I decided to get writing. This\r\narticle will probably only make sense to people from a malware research / programming background, but to\r\ncompensate i will be posting a fairly non technical article in the near future.\r\nI will be talking about the infamous injection method from PowerLoader 2.0, which has been seen in many\r\ndifferent malware families such as: Carberp, Redyms and Gapz. Recently, after looking at the difference between\r\n0vercl0ck’s proof of concept and the real deal, a friend asked me “Why does PowerLoader go to all the trouble of\r\nusing ROP chains instead of just executing the shellcode like 0vercl0ck does.”, I already had a perfect idea of\r\nwhy, but decided to do some digging and answer the question “How?”, this digging resulted in me finding\r\nsomething that truly impressed me, (I try not to admire the work of criminals as i don’t want to seem like a\r\npsychopath 😉 ). I would have written this article sooner, but i was totally unaware that no blogs had really gone\r\ninto depth on this method, i like to be unique!\r\nThe Purpose\r\nMost antiviruses don’t treat all processes the same, a known “trusted” process is usually far less likely to flag up\r\nany warnings from the antivirus. In this case, the goal of malware is to inject code into one of these “trusted”\r\nprocesses in order to run with less risk of detection. Of course antiviruses will attempt to catch injection too, so\r\nthe challenge is for malware to find a way into the trusted process without being detected.\r\nIn order to give a better idea of the stealthiness of PowerLoader I have listed below some common telltale signs of\r\na malicious process attempting to inject.\r\n(The following only apply to a process trying to perform any of these actions on another process)\r\nAllocating heap space\r\nCreating threads\r\nOverwriting process/module memory\r\nManipulating thread context\r\nQueuing asynchronous procedure calls (APCs)\r\nProactive antiviruses will check for processes trying to perform these actions and could likely result in the user\r\nbeing alerted to a malicious process. The aim of PowerLoader is to subvert this, (which seems to be a success as it\r\nis not picked up by antiviruses, and does not cross off anything on the list).\r\nWriting the code to explorer\r\nhttps://www.malwaretech.com/2013/08/powerloader-injection-something-truly.html\r\nPage 1 of 7\n\nIn the case of PowerLoader, the trusted process targeted is explorer. I won’t be putting any images/reversed code\r\nfor this part as it has already been well documented by ESET.\r\nPowerLoader gets the malicious code into the process by opening an existing, shared section already mapped into\r\nexplorer, removing the need to allocate heap space or overwrite process memory. PowerLoader then proceeds to\r\nmap the shellcode onto the end of the chosen section. Below is a list of targeted shared sections.\r\nBaseNamedObjectsShimSharedMemory\r\nBaseNamedObjectswindows_shell_global_counters\r\nBaseNamedObjectsMSCTF.Shared.SFM.MIH\r\nBaseNamedObjectsMSCTF.Shared.SFM.AMF\r\nBaseNamedObjectsUrlZonesSM_Administrator\r\nBaseNamedObjectsUrlZonesSM_SYSTEM\r\nExecuting the code\r\nIn order to execute the remote code without creating a thread, PowerLoader uses a little trick with the explorer\r\ntray window procedure. By opening “Shell_TrayWnd” and calling SetWindowLong, PowerLoader is able to set a\r\nvariable used by the window procedure to point to a specific address in its shellcode. Here PowerLoader sets the\r\naddress to a pointer to a pointer to KiUserApcDispatcher, whereas 0vercl0ck’s code will just set it to a pointer to a\r\npointer to the payload (which resides in a shared section).\r\nWhen SendNotifyMessage is called by the malware, the window\r\nprocedure inside explorer is triggered and this is what happens.\r\n \r\nFigure 1: A snippet from the\r\nWindow Procedure\r\nNow this code is simple, it will perform a double indirection that will result in the address pointed to by the\r\npointer that was set using SetWindowLong, being executed.\r\nThis is where PowerLoader differs from 0vercl0ck’s version. The instruction “call dword ptr eax” will read the\r\nvalue pointed to by EAX and then call it. The read part won’t trigger DEP (Data Execution Prevention), if the\r\nsection is not executable (in later versions of windows it is execute-protected), however if EAX points to an\r\naddress inside the section, DEP will be triggered. Because the sections protection is only set to Read/Write in later\r\nversions of windows, 0vercl0ck’s code will likely trigger DEP and crash explorer, however, because\r\nPowerLoader’s pointer points to KiUserApcDispatcher (resides in ntdll), DEP is not triggered.\r\nWell how does one get from KiUserApcDispatcher to code execution, without executing the non-executable\r\nshellcode, I hear you ask?\r\nROP Chains, Unicorns, and Rainbows\r\nhttps://www.malwaretech.com/2013/08/powerloader-injection-something-truly.html\r\nPage 2 of 7\n\nThis part greatly interested me, partly because I have never seen a ROP chain in the wild before but mainly\r\nbecause it is the most advanced injection method I have ever come across. In order to understand how\r\nPowerLoader gets from KiUserApcDispatcher, to shellcode execution, we need to do some disassembling.\r\nIn Figure 1, we see the Window Procedure pushing ESI onto the stack, then calling KiUserApcDispatcher. It is\r\nimportant to remember ESI contains the address (held in the shellcode) of the pointer to the KiUserApcDispatcher\r\npointer.\r\nSo let’s see dissasemble KiUserApcDispatcher. |\r\n | |—| |\r\nFigure 2: KiUserApcDispatcher |\r\nPay attention to the first 3 instructions. “lea edi, [esp+10h]” is loading the last parameter into the EDI register. If\r\nyou remember in Figure 1, the last parameter pushed to the stack was ESI, which contains an address within the\r\nshellcode. Next it pops the return address into the EAX and then calls it, this results in execution being transferred\r\nback to the Window Procedure.\r\nSo really nothing has happened here, We’ve just set the EDI to an address inside the shellcode and then gone back\r\nto where we came from. So in order to see what happens next, we are going to have to dig deeper. Here is some\r\nmore of the Window Procedure. |\r\nhttps://www.malwaretech.com/2013/08/powerloader-injection-something-truly.html\r\nPage 3 of 7\n\n| |—| |\r\nFigure 3: More of the Window Procedure shown in Figure 1 |\r\nNow in this disassembly we need to pay attention to the instructions underlined in red and orange, the blue box is\r\nthe code we already discussed (executes KiUserApcDispatcher and sets EDI to ESI), the rest of the code can be\r\nignored. As you can see, the function makes 2 more calls (EAX+8, followed by EAX+4), if you remember earlier,\r\nEAX is an address in the shellcode, so the next call is to the address 8 Bytes below.\r\nLet’s take a look at the shellcode shall we? |\r\n | |—| | Figure 4: A\r\nsmall snippet from the shellcode |\r\nWhen SetWindowLong was called by PowerLoader it set the ESI (Blue Box Figure 3) to 00100E0C (Which holds\r\nthe address 00100E20), The code then performs and indirection and EAX ends up pointing to\r\nKiUserApcDispatchPtr (00100E20). Using some very basic maths, EAX+8 points to 00100E28 and EAX+4 to\r\n00100E24.\r\nWhat are 00100E28 \u0026 00100E24? When the shellcode was made during runtime, PowerLoader searched for some\r\nbyte sequences in explorer using ReadProcessMemory, then stored the addresses of those sequences in the\r\nhttps://www.malwaretech.com/2013/08/powerloader-injection-something-truly.html\r\nPage 4 of 7\n\nshellcode. The sequences are instruction within the executable regions of explorer’s memory, their purpose is to\r\nperform certain operations as PowerLoader can’t execute any of its own code yet, due to the section being\r\nexecute-protected. 00100E28 points to some code in explorer that executes the instruction “STD” followed by\r\n“RET”, As a result the instruction underlined in red will result in the direction flag being set and execution being\r\nreturned to the Window Procedure.\r\nUntil now, nothing makes any sense at all. We’ve set the ESI to an address in the shellcode (Figure 1), we’ve set\r\nthe EDI to an address on the stack (Figure2), and we’ve set the direction flag. What happens next makes sense of\r\nit all. EAX+4 is called from the window procedure, as we established EAX+4 is a pointer in our shellcode, but\r\nwhat does it point to? Again, we need to do some disassembling. |\r\n| |—| | Figure 4: A random function in shell32.dll |\r\nRemember i said PowerLoader scanned some byte sequences in explorer? Well these bytes were found, in this\r\ncase inside some random shell32 function (it doesn’t matter). Now the pointer doesn’t point to the start of the\r\nfunction, it points somewhere in the middle, as a result, only the bytes in the red box are executed. It should\r\nbecome apparent what is happening. The instruction “REP MOVSD” will move ECX (0x94) bytes from the\r\naddress in ESI to the address in EDI. Earlier the code managed to use code within explorer to set the ESI to the\r\nshellcode address, the EDI to an address on the stack, then Set the direction flag to 1. Because of this, the\r\nshellcode starting at address 00100E0C will be copied to the stack backwards (The copying will start at the\r\naddress in ESI, copy a DWORD, then subtract the address by 4 and repeat. (Remember: because all addresses\r\npoints to executable code within explorer address space, and they are called using a pointer, no code in the\r\nshellcode is actually executed, thus resulting in no nasty DEP errors.)\r\nThis is where things start to heat up, PowerLoader has just used code located within explorer to overwrite some of\r\nthe stack with some shellcode, which means although still incapable of directly executing its own code,\r\nPowerLoader has control over return addresses and stack based parameters.\r\nhttps://www.malwaretech.com/2013/08/powerloader-injection-something-truly.html\r\nPage 5 of 7\n\nLet’s have a look at the code that was copied. | |\r\n|—| | Figure 5: The ROP Shellcode that is written to the stack |\r\nOnce the code copying the ROP Shellcode to the stack is done, it hits the ret instruction, but because the stack has\r\nbeen overwritten, it instead ends up executing code pointed to by the ROP Shellcode, Each bit of code has a ret\r\ninstruction which causes the next ROP gadget to be executed. I stepped through in a debugger, below i have made\r\na list of the ROP Gadgets in order of execution, each line is a different gadget.\r\n1. Direction Flag Clear\r\n2. Pop 0x70 into EAX\r\n3. Call _alloca_probe\r\n4. WriteProcessMemory\r\n5. Pop the address of ntdll!atan into EAX\r\n6. Jmp to EAX\r\nSome things to note:\r\nThe _alloca_probe function is undocumented but I believe it takes the value in EAX and check that the\r\nstack can hold that many items, if not it triggers the guard page to allocate more stack space (0x70 is in\r\nEAX)\r\nThe parameters for WriteProcessMemory are at address 00090DA0, these parameters cause\r\nWriteProcessMemory to read the shellcode from the shared section, then write it over ntdll!atan which we\r\ncan assume isn’t used by explorer.\r\nhttps://www.malwaretech.com/2013/08/powerloader-injection-something-truly.html\r\nPage 6 of 7\n\nFinally the last instruction jumps to ntdll!atan and the code begins execution.\r\nTLDR / Recap\r\nPowerLoader bypasses the execution protection on the shared sections, by using code found inside explorer to\r\ncopy a ROP Chain to the stack, then uses the ROP Chain to manipulate the call stack into causing Explorer to call\r\nWriteProcessMemory and overwrite an unused function in ntdll with some shellcode to complete the injection. ##\r\nConclusion\r\nSo there we have it, from non-executable section to shellcode execution by using explorer’s own code against\r\nitself. I’ll try and get a new article up soon, sorry for the inactivity \u003c3\r\nSource: https://www.malwaretech.com/2013/08/powerloader-injection-something-truly.html\r\nhttps://www.malwaretech.com/2013/08/powerloader-injection-something-truly.html\r\nPage 7 of 7\n\nWhen SetWindowLong the address 00100E20), was The called by PowerLoader code then performs it set the ESI and indirection (Blue Box Figure and EAX ends 3) to 00100E0C up pointing to (Which holds\nKiUserApcDispatchPtr (00100E20). Using some very basic maths, EAX+8 points to 00100E28 and EAX+4 to\n00100E24.      \nWhat are 00100E28 \u0026 00100E24? When the shellcode was made during runtime, PowerLoader searched for some\nbyte sequences in explorer using ReadProcessMemory, then stored the addresses of those sequences in the\n   Page 4 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://www.malwaretech.com/2013/08/powerloader-injection-something-truly.html"
	],
	"report_names": [
		"powerloader-injection-something-truly.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434527,
	"ts_updated_at": 1775791243,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/aa26e82fafd4cb5e4078479478df647d5e191aeb.pdf",
		"text": "https://archive.orkl.eu/aa26e82fafd4cb5e4078479478df647d5e191aeb.txt",
		"img": "https://archive.orkl.eu/aa26e82fafd4cb5e4078479478df647d5e191aeb.jpg"
	}
}