{
	"id": "723067cb-1e00-41ea-92e7-cbd6018915c5",
	"created_at": "2026-04-06T00:21:45.849013Z",
	"updated_at": "2026-04-10T13:11:21.932905Z",
	"deleted_at": null,
	"sha1_hash": "e4844c90265f19021305b97817290b3d4f80d692",
	"title": "Ten process injection techniques: A technical survey of common and trending process injection techniques",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1764258,
	"plain_text": "Ten process injection techniques: A technical survey of common\r\nand trending process injection techniques\r\nBy ByAshkan Hosseini\r\nPublished: 2017-07-18 · Archived: 2026-04-05 21:18:49 UTC\r\nEditor’s Note: Elastic joined forces with Endgame in October 2019, and has migrated some of the Endgame blog\r\ncontent to elastic.co. See Elastic Security to learn more about our integrated security solutions.\r\nProcess injection is a widespread defense evasion technique employed often within malware and fileless adversary\r\ntradecraft, and entails running custom code within the address space of another process. Process injection\r\nimproves stealth, and some techniques also achieve persistence. Although there are numerous process injection\r\ntechniques, in this blog I present ten techniques seen in the wild that run malware code on behalf of another\r\nprocess. I additionally provide screenshots for many of these techniques to facilitate reverse engineering and\r\nmalware analysis, assisting detection and defense against these common techniques.\r\n1. CLASSIC DLL INJECTION VIA CREATEREMOTETHREAD AND\r\nLOADLIBRARY\r\nThis technique is one of the most common techniques used to inject malware into another process. The malware\r\nwrites the path to its malicious dynamic-link library (DLL) in the virtual address space of another process, and\r\nensures the remote process loads it by creating a remote thread in the target process.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 1 of 24\n\nThe malware first needs to target a process for injection (e.g. svchost.exe). This is usually done by searching\r\nthrough processes by calling a trio of Application Program Interfaces (APIs): CreateToolhelp32Snapshot,\r\nProcess32First, and Process32Next. CreateToolhelp32Snapshot is an API used for enumerating heap or module\r\nstates of a specified process or all processes, and it returns a snapshot. Process32First retrieves information about\r\nthe first process in the snapshot, and then Process32Next is used in a loop to iterate through them. After finding\r\nthe target process, the malware gets the handle of the target process by calling OpenProcess.\r\nAs shown in Figure 1, the malware calls VirtualAllocEx to have a space to write the path to its DLL. The malware\r\nthen calls WriteProcessMemory to write the path in the allocated memory. Finally, to have the code executed in\r\nanother process, the malware calls APIs such as CreateRemoteThread, NtCreateThreadEx, or\r\nRtlCreateUserThread. The latter two are undocumented. However, the general idea is to pass the address of\r\nLoadLibrary to one of these APIs so that a remote process has to execute the DLL on behalf of the malware.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 2 of 24\n\nCreateRemoteThread is tracked and flagged by many security products. Further, it requires a malicious DLL on\r\ndisk which could be detected. Considering that attackers are most commonly injecting code to evade defenses,\r\nsophisticated attackers probably will not use this approach. The screenshot below displays a malware named\r\nRebhip performing this technique.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 3 of 24\n\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 4 of 24\n\nFigure 1: Rebhip worm performing a typical DLL injection\r\nSha256: 07b8f25e7b536f5b6f686c12d04edc37e11347c8acd5c53f98a174723078c365\r\n2. PORTABLE EXECUTABLE INJECTION (PE INJECTION)\r\nInstead of passing the address of the LoadLibrary, malware can copy its malicious code into an existing open\r\nprocess and cause it to execute (either via a small shellcode, or by calling CreateRemoteThread). One advantage\r\nof PE injection over the LoadLibrary technique is that the malware does not have to drop a malicious DLL on the\r\ndisk. Similar to the first technique, the malware allocates memory in a host process (e.g. VirtualAllocEx), and\r\ninstead of writing a “DLL path” it writes its malicious code by calling WriteProcessMemory. However, the\r\nobstacle with this approach is the change of the base address of the copied image. When a malware injects its PE\r\ninto another process it will have a new base address which is unpredictable, requiring it to dynamically recompute\r\nthe fixed addresses of its PE. To overcome this, the malware needs to find its relocation table address in the host\r\nprocess, and resolve the absolute addresses of the copied image by looping through its relocation descriptors.\r\nThis technique is similar to other techniques, such as reflective DLL injection and memory module, since they do\r\nnot drop any files to the disk. However, memory module and reflective DLL injection approaches are even\r\nstealthier. They do not rely on any extra Windows APIs (e.g., CreateRemoteThread or LoadLibrary), because they\r\nload and execute themselves in the memory. Reflective DLL injection works by creating a DLL that maps itself\r\ninto memory when executed, instead of relying on the Window’s loader. Memory Module is similar to Reflective\r\nDLL injection except the injector or loader is responsible for mapping the target DLL into memory instead of the\r\nDLL mapping itself. In a previous blog post, these two in memory approaches were discussed extensively.\r\nWhen analyzing PE injection, it is very common to see loops (usually two “for” loops, one nested in the other),\r\nbefore a call to CreateRemoteThread. This technique is quite popular among crypters (softwares that encrypt and\r\nobfuscate malware). In Figure 2, the sample unit test is taking advantage of this technique. The code has two\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 5 of 24\n\nnested loops to adjust its relocation table that can be seen before the calls to WriteProcessMemory and\r\nCreateRemoteThread. The “and 0x0fff” instruction is also another good indicator, showing that the first 12 bits are\r\nused to get the offset into the virtual address of the containing relocation block. Now that the malware has\r\nrecomputed all the necessary addresses, all it needs to do is pass its starting address to CreateRemoteThread and\r\nhave it executed.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 6 of 24\n\nFigure 2: Example structure of the loops for PE injection prior to calls to CreateRemoteThread\r\nSha256: ce8d7590182db2e51372a4a04d6a0927a65b2640739f9ec01cfd6c143b1110da\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 7 of 24\n\n3. PROCESS HOLLOWING (A.K.A PROCESS REPLACEMENT AND RUNPE)\r\nInstead of injecting code into a host program (e.g., DLL injection), malware can perform a technique known as\r\nprocess hollowing. Process hollowing occurs when a malware unmaps (hollows out) the legitimate code from\r\nmemory of the target process, and overwrites the memory space of the target process (e.g., svchost.exe) with a\r\nmalicious executable.\r\nThe malware first creates a new process to host the malicious code in suspended mode. As shown in Figure 3, this\r\nis done by calling CreateProcess and setting the Process Creation Flag to CREATE_SUSPENDED (0x00000004).\r\nThe primary thread of the new process is created in a suspended state, and does not run until the ResumeThread\r\nfunction is called. Next, the malware needs to swap out the contents of the legitimate file with its malicious\r\npayload. This is done by unmapping the memory of the target process by calling either ZwUnmapViewOfSection\r\nor NtUnmapViewOfSection. These two APIs basically release all memory pointed to by a section. Now that the\r\nmemory is unmapped, the loader performs VirtualAllocEx to allocate new memory for the malware, and uses\r\nWriteProcessMemory to write each of the malware’s sections to the target process space. The malware calls\r\nSetThreadContext to point the entrypoint to a new code section that it has written. At the end, the malware\r\nresumes the suspended thread by calling ResumeThread to take the process out of suspended state.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 8 of 24\n\nFigure 3: Ransom.Cryak performing process hollowing\r\nSha256: eae72d803bf67df22526f50fc7ab84d838efb2865c27aef1a61592b1c520d144\r\n4. THREAD EXECUTION HIJACKING (A.K.A SUSPEND, INJECT, AND\r\nRESUME (SIR))\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 9 of 24\n\nThis technique has some similarities to the process hollowing technique previously discussed. In thread execution\r\nhijacking, malware targets an existing thread of a process and avoids any noisy process or thread creations\r\noperations. Therefore, during analysis you will probably see calls to CreateToolhelp32Snapshot and Thread32First\r\nfollowed by OpenThread.\r\nAfter getting a handle to the target thread, the malware puts the thread into suspended mode by calling\r\nSuspendThread to perform its injection. The malware calls VirtualAllocEx and WriteProcessMemory to allocate\r\nmemory and perform the code injection. The code can contain shellcode, the path to the malicious DLL, and the\r\naddress of LoadLibrary.\r\nFigure 4 illustrates a generic trojan using this technique. In order to hijack the execution of the thread, the\r\nmalware modifies the EIP register (a register that contains the address of the next instruction) of the targeted\r\nthread by calling SetThreadContext. Afterwards, malware resumes the thread to execute the shellcode that it has\r\nwritten to the host process. From the attacker’s perspective, the SIR approach can be problematic because\r\nsuspending and resuming a thread in the middle of a system call can cause the system to crash. To avoid this, a\r\nmore sophisticated malware would resume and retry later if the EIP register is within the range of NTDLL.dll.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 10 of 24\n\nFigure 4: A generic trojan is performing thread execution hijacking\r\nSha256: 787cbc8a6d1bc58ea169e51e1ad029a637f22560660cc129ab8a099a745bd50e\r\n5. HOOK INJECTION VIA SETWINDOWSHOOKEX\r\nHooking is a technique used to intercept function calls. Malware can leverage hooking functionality to have their\r\nmalicious DLL loaded upon an event getting triggered in a specific thread. This is usually done by calling\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 11 of 24\n\nSetWindowsHookEx to install a hook routine into the hook chain. The SetWindowsHookEx function takes four\r\narguments. The first argument is the type of event. The events reflect the range of hook types, and vary from\r\npressing keys on the keyboard (WH_KEYBOARD) to inputs to the mouse (WH_MOUSE), CBT, etc. The second\r\nargument is a pointer to the function the malware wants to invoke upon the event execution.The third argument is\r\na module that contains the function. Thus, it is very common to see calls to LoadLibrary and GetProcAddress\r\nbefore calling SetWindowsHookEx. The last argument to this function is the thread with which the hook\r\nprocedure is to be associated. If this value is set to zero all threads perform the action when the event is triggered.\r\nHowever, malware usually targets one thread for less noise, thus it is also possible to see calls\r\nCreateToolhelp32Snapshot and Thread32Next before SetWindowsHookEx to find and target a single thread. Once\r\nthe DLL is injected, the malware executes its malicious code on behalf of the process that its threadId was passed\r\nto SetWindowsHookEx function. In Figure 5, Locky Ransomware implements this technique.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 12 of 24\n\nFigure 5: Locky Ransomware using hook injection\r\nSha256: 5d6ddb8458ee5ab99f3e7d9a21490ff4e5bc9808e18b9e20b6dc2c5b27927ba1\r\n6. INJECTION AND PERSISTENCE VIA REGISTRY MODIFICATION (E.G.\r\nAPPINIT_DLLS, APPCERTDLLS, IFEO)\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 13 of 24\n\nAppinit_DLL, AppCertDlls, and IFEO (Image File Execution Options) are all registry keys that malware uses for\r\nboth injection and persistence. The entries are located at the following locations:\r\nHKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Appinit_Dlls\r\nHKLM\\Software\\Wow6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Appinit_Dlls\r\nHKLM\\System\\CurrentControlSet\\Control\\Session Manager\\AppCertDlls HKLM\\Software\\Microsoft\\Windows\r\nNT\\currentversion\\image file execution options\r\nAppInit_DLLs\r\nMalware can insert the location of their malicious library under the Appinit_Dlls registry key to have another\r\nprocess load their library. Every library under this registry key is loaded into every process that loads User32.dll.\r\nUser32.dll is a very common library used for storing graphical elements such as dialog boxes. Thus, when a\r\nmalware modifies this subkey, the majority of processes will load the malicious library. Figure 6 demonstrates the\r\ntrojan Ginwui relying on this approach for injection and persistence. It simply opens the Appinit_Dlls registry key\r\nby calling RegCreateKeyEx, and modifies its values by calling RegSetValueEx.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 14 of 24\n\nFigure 6: Ginwui modifying the AppIniti_DLLs registry key\r\nSha256: 9f10ec2786a10971eddc919a5e87a927c652e1655ddbbae72d376856d30fa27c\r\nAppCertDlls\r\nThis approach is very similar to the AppInit_DLLs approach, except that DLLs under this registry key are loaded\r\ninto every process that calls the Win32 API functions CreateProcess, CreateProcessAsUser,\r\nCreateProcessWithLogonW, CreateProcessWithTokenW, and WinExec.\r\nImage File Execution Options (IFEO)\r\nIFEO is typically used for debugging purposes. Developers can set the “Debugger Value” under this registry key\r\nto attach a program to another executable for debugging. Therefore, whenever the executable is launched the\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 15 of 24\n\nprogram that is attached to it will be launched. To use this feature you can simply give the path to the debugger,\r\nand attach it to the executable that you want to analyze. Malware can modify this registry key to inject itself into\r\nthe target executable. In Figure 7, Diztakun trojan implements this technique by modifying the debugger value of\r\nTask Manager.\r\nFigure 7: Diztakun trojan modifying IFEO registry key\r\nSha256: f0089056fc6a314713077273c5910f878813fa750f801dfca4ae7e9d7578a148\r\n7. APC INJECTION AND ATOMBOMBING\r\nMalware can take advantage of Asynchronous Procedure Calls (APC) to force another thread to execute their\r\ncustom code by attaching it to the APC Queue of the target thread. Each thread has a queue of APCs which are\r\nwaiting for execution upon the target thread entering alterable state. A thread enters an alertable state if it calls\r\nSleepEx, SignalObjectAndWait, MsgWaitForMultipleObjectsEx, WaitForMultipleObjectsEx, or\r\nWaitForSingleObjectEx functions. The malware usually looks for any thread that is in an alterable state, and then\r\ncalls OpenThread and QueueUserAPC to queue an APC to a thread. QueueUserAPC takes three arguments: 1) a\r\nhandle to the target thread; 2) a pointer to the function that the malware wants to run; 3) and the parameter that is\r\npassed to the function pointer. In Figure 8, Amanahe malware first calls OpenThread to acquire a handle of\r\nanother thread, and then calls QueueUserAPC with LoadLibraryA as the function pointer to inject its malicious\r\nDLL into another thread.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 16 of 24\n\nAtomBombing is a technique that was first introduced by enSilo research, and then used in Dridex V4. As we\r\ndiscussed in detail in a previous post, the technique also relies on APC injection. However, it uses atom tables for\r\nwriting into memory of another process.\r\nFigure 8: Almanahe performing APC injection\r\nSha256: f74399cc0be275376dad23151e3d0c2e2a1c966e6db6a695a05ec1a30551c0ad\r\n8. EXTRA WINDOW MEMORY INJECTION (EWMI) VIA\r\nSETWINDOWLONG\r\nEWMI relies on injecting into Explorer tray window’s extra window memory, and has been used a few times\r\namong malware families such as Gapz and PowerLoader. When registering a window class, an application can\r\nspecify a number of additional bytes of memory, called extra window memory (EWM). However, there is not\r\nmuch room in EWM. To circumvent this limitation, the malware writes code into a shared section of explorer.exe,\r\nand uses SetWindowLong and SendNotifyMessage to have a function pointer to point to the shellcode, and then\r\nexecute it.\r\nThe malware has two options when it comes to writing into a shared section. It can either create a shared section\r\nand have it mapped both to itself and to another process (e.g., explorer.exe), or it can simply open a shared section\r\nthat already exists. The former has the overhead of allocating heap space and calling NTMapViewOfSection in\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 17 of 24\n\naddition to a few other API calls, so the latter approach is used more often. After malware writes its shellcode in a\r\nshared section, it uses GetWindowLong and SetWindowLong to access and modify the extra window memory of\r\n“Shell_TrayWnd”. GetWindowLong is an API used to retrieve the 32-bit value at the specified offset into the extra\r\nwindow memory of a window class object, and SetWindowLong is used to change values at the specified offset.\r\nBy doing this, the malware can simply change the offset of a function pointer in the window class, and point it to\r\nthe shellcode written to the shared section.\r\nLike most other techniques mentioned above, the malware needs to trigger the code that it has written. In\r\npreviously discussed techniques, malware achieved this by calling APIs such as CreateRemoteThread,\r\nQueueUserAPC, or SetThreadContext. With this approach, the malware instead triggers the injected code by\r\ncalling SendNotifyMessage. Upon execution of SendNotifyMessage, Shell_TrayWnd receives and transfers\r\ncontrol to the address pointed to by the value previously set by SetWindowLong. In Figure 9, a malware named\r\nPowerLoader uses this technique.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 18 of 24\n\nFigure 9: PowerLoader injecting into extra window memory of shell tray window\r\nSha256: 5e56a3c4d4c304ee6278df0b32afb62bd0dd01e2a9894ad007f4cc5f873ab5cf\r\n9. INJECTION USING SHIMS\r\nMicrosoft provides Shims to developers mainly for backward compatibility. Shims allow developers to apply fixes\r\nto their programs without the need of rewriting code. By leveraging shims, developers can tell the operating\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 19 of 24\n\nsystem how to handle their application. Shims are essentially a way of hooking into APIs and targeting specific\r\nexecutables. Malware can take advantage of shims to target an executable for both persistence and injection.\r\nWindows runs the Shim Engine when it loads a binary to check for shimming databases in order to apply the\r\nappropriate fixes.\r\nThere are many fixes that can be applied, but malware’s favorites are the ones that are somewhat security related\r\n(e.g., DisableNX, DisableSEH, InjectDLL, etc). To install a shimming database, malware can deploy various\r\napproaches. For example, one common approach is to simply execute sdbinst.exe, and point it to the malicious sdb\r\nfile. In Figure 10, an adware, “Search Protect by Conduit”, uses a shim for persistence and injection. It performs\r\nan “InjectDLL” shim into Google Chrome to load vc32loader.dll. There are a few existing tools for analyzing sdb\r\nfiles, but for the analysis of the sdb listed below, I used python-sdb.\r\nFigure 10: SDB used by Search Protect for injection purposes\r\nSha256: 6d5048baf2c3bba85adc9ac5ffd96b21c9a27d76003c4aa657157978d7437a20\r\n10. IAT HOOKING AND INLINE HOOKING (A.K.A USERLAND ROOTKITS)\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 20 of 24\n\nIAT hooking and inline hooking are generally known as userland rootkits. IAT hooking is a technique that\r\nmalware uses to change the import address table. When a legitimate application calls an API located in a DLL, the\r\nreplaced function is executed instead of the original one. In contrast, with inline hooking, malware modifies the\r\nAPI function itself. In Figure 11, the malware FinFisher, performs IAT hooking by modifying where the\r\nCreateWindowEx points.\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 21 of 24\n\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 22 of 24\n\nFigure 11: FinFisher performing IAT hooking by changing where CreateWindowEx points to\r\nSha256: f827c92fbe832db3f09f47fe0dcaafd89b40c7064ab90833a1f418f2d1e75e8e\r\nCONCLUSION\r\nIn this post, I covered ten different techniques that malware uses to hide its activity in another process. In general,\r\nmalware either directly injects its shellcode into another process or it forces another process to load its malicious\r\nlibrary. In Table 1, I have classified the various techniques and provided samples to serve as a reference for\r\nobserving each injection technique covered in this post. The figures included throughout the post will help the\r\nresearcher recognize the various techniques when reversing malware.\r\nTable1: Process injection can be done by directly injecting code into another process, or by forcing a DLL to be\r\nloaded into another process\r\nAttackers and researchers regularly discover new techniques to achieve injection and provide stealth. This post\r\ndetailed ten common and emerging techniques, but there are others, such as COM hijacking. Defenders will never\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 23 of 24\n\nbe “done” in their mission to detect and prevent stealthy process injection because adversaries will never stop\r\ninnovating.\r\nAt Endgame, we constantly research advanced stealth techniques and bring protections into our product. We layer\r\ncapabilities which detect malicious DLLs that load on some persistence (like AppInit DLLs, COM Hijacks, and\r\nmore), prevent many forms of code injection in real-time via our patented shellcode injection protection, and\r\ndetect malicious injected payloads running in memory delivered through any of the above techniques through our\r\npatent-pending fileless attack detection techniques. This approach allows our platform to be more effective than\r\nany other product on the market in protecting against code injection, while also maximizing resiliency against\r\nbypass due to emerging code injection techniques.\r\nSource: https://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nhttps://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process\r\nPage 24 of 24",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.elastic.co/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process"
	],
	"report_names": [
		"ten-process-injection-techniques-technical-survey-common-and-trending-process"
	],
	"threat_actors": [],
	"ts_created_at": 1775434905,
	"ts_updated_at": 1775826681,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e4844c90265f19021305b97817290b3d4f80d692.pdf",
		"text": "https://archive.orkl.eu/e4844c90265f19021305b97817290b3d4f80d692.txt",
		"img": "https://archive.orkl.eu/e4844c90265f19021305b97817290b3d4f80d692.jpg"
	}
}