{
	"id": "cb2d7d86-5c7d-48e5-8b71-0879e21fe550",
	"created_at": "2026-04-06T00:22:29.90519Z",
	"updated_at": "2026-04-10T03:21:45.329Z",
	"deleted_at": null,
	"sha1_hash": "1a27b348127a9bb76ff3c76bcec1702f1ae885a8",
	"title": "The state of advanced code injections",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 430903,
	"plain_text": "The state of advanced code injections\r\nArchived: 2026-04-05 16:59:06 UTC\r\nIn the last few years there has been a significant interest in code injection techniques from both attackers and\r\ndefenders. These techniques enable the attacker to execute arbitrary code within the address space of some target\r\nprocess (which is why code injections often are also called process injections), and attackers, both malware and\r\npentesters, increasingly use these techniques to bypass anti-malware systems and endpoint protection systems in\r\norder to execute their payloads. Many of these injection techniques are already described in various blog posts,\r\nsuch as the excellent ones by Endgame here and here, and most recently a large survey was conducted by\r\nresearchers from SafeBreach at the most recent Blackhat event with the content available here. However, many of\r\nthese surveys are closely attached to the core programmatic aspects of the injections, whereas they leave out\r\nelements of why injections are necessarily important and when they are used. In this blog post we will cover the\r\nstate of code injections from a more general setting such as their motivation, some of their technical details as well\r\nas highlight examples of attacks that have used them. Finally, we give a short view into the future.\r\nUnderstanding code injections from beginner to advanced is one of the courses that we offer as part of our\r\nsoftware security training. We currently have a public event scheduled for the upcoming 44CON in London 9th-11th September 2019 and you can find the necessary information here. In this course we will teach you the core of\r\nthese techniques as well as how to develop sophisticated payloads that rely on code injections. Please consider\r\nattending the training and the conference!\r\nMotivation for code injections, for defenders and attackers\r\nIn a general sense, attackers use code injection techniques to mitigate defensive systems. This includes everything\r\nfrom bypassing host-based intrusion prevention systems, evading malware sandboxes and avoiding analysis by\r\nforensic tools. Naturally, malware has used these techniques for quite a while and even in back in 2013 Palo Alto\r\nreported that 13.5% of malware samples used code injections, described in the modern malware review report\r\non page 16 under \"analysis avoidance ''. In their report they also give an interesting insight about the motivation\r\nfor code injections, namely \"Code injection was observed in 13.5 percent of samples. This technique is notable in\r\nparticular because it allows malware to hide within another running process. This has the effect of the malware\r\nout of view if a user checks the task manager and can also foil some attempts at application white-listing on the\r\nhost\". Wayne Low documents even before then, in 2012, the first analysis of the Gapz malware that explicility\r\nused a novel code injection technique that - due to it's novelty - bypassed host-based intrusion prevention systems\r\nhere. Interestingly, the injection that Gapz deployed used techniques and ideas described around a decade earlier\r\ncalled shatter attacks, which was even presented at Blackhat in 2004 here.\r\nIn the years 2013-2019 the amount of code injections has continued to grow. There are currently many reports by\r\nanti-malware companies documenting the code injections in malware and I think it's fair to say that now, when a\r\nnew malware is discovered, it's more often than not the case that it uses code injection techniques. A recent survey\r\nof techniques by SafeBreach documents 14 techniques invented in 2017-2019, and this leaves out 7 shatter-like\r\nattacks that they do not go in details with as well as a whole domain of techniques in the process hollowing space,\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 1 of 10\n\nin which several new variants have been discovered in recent years. Furthermore, malware samples are currently\r\nnot limiting their injection lifecycle to only one injection technique, but a recent report shows that Dridex\r\ncombines five different injection techniques.\r\nCode injections are not only used by malware. Pentesters, and red teams in general, rely on these techniques to\r\ntake control of the systems once they have gotten access to the system. For example, the famous Meterpreter\r\nused by pentesters rely on code injection as well as related techniques, e.g. self-loading DLLs. Shellterpro is\r\nanother well-known pentester tool that is heavily based on code injections. As defensive systems get better,\r\nunderstanding the design space of code injections can significantly enhance the skills of red teamers, as it allows\r\nyou to manually construct payloads and write injection tools that bypass the specific defensive perimeter of your\r\ntarget. An example of custom tools developed for the purposes of penetration testing was given at Blackhat in\r\n2014 here.\r\nBrief overviev of code injection foundations\r\nIn this section we give a brief introduction to some of the more common-known injection techniques.\r\nTraditional remote thread creation\r\nThis is the most well known injection technique and simply achieves execution in the target process by\r\ninstantiating a remote thread. The general procedure is to get access to the target process using OpenProcess ,\r\nallocating memory in the process using VirtualAlloc , writing malicious code to the allocated memory with\r\nWriteProcessMemory and finally having this code execute using CreateRemoteThread . Naturally, there are many\r\nvariations of this injection technique, both in terms of getting access to the remote process, writing memory to the\r\ntargets address space and also initiating execution. For example, instead of opening an existing process, the\r\nmalware can create a new process with CreateProcess and inject its code in this new process or rely on lower-level APIs like NtOpenProcess . The attack can also write to memory using NtWriteVirtualMemory and creating\r\nthe remote thread can be performed with a variety of lower-level APIs like RtlCreateUserThread ,\r\nNtCreateThreadEx and ZwCreateThreadEx . This technique is perhaps the most commonly used by malware and\r\nexample reports include Tinba and Emotet.\r\nIn general, we can construct a similar-looking attack in many ways. The primitive for writing memory to the target\r\nprocess need not be WriteProcessMemory , but can be any way of memory sharing. This includes memory\r\nmapped files by way of APIs like ZwCreateSection and ZwMapViewOfSection and also globally shared memory.\r\nFurthermore, from a programmatic perpective we can also use asynchronous procedure calls rather than explicitly\r\nstarting a new thread in the remote process, which we discuss below.\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 2 of 10\n\nRemote thread creation as decompiled by Ghidra.\r\nRemote thread hijacking\r\nA technique that is closely aligned with creating a remote thread is to hijack a remote thread instead of creating a\r\nnew one in the target process. From a high-level point of view, the difference between this technique and the\r\nprevious one is that the previous technique creates a new thread in the target whereas this technique hijacks\r\nexecution of an exisiting one. One way to do this is to create a new process, by way of CreateProcess , in\r\nsuspended mode and overwrite the entry point of the newly-started process such that it points to our attacker-controlled code instead. This effectively means the CreateRemoteThread call from before gets substituted with\r\nResumeThread . A more aggressive approach is to simply suspend thread execution in the target process and then\r\nsubstitute the thread using SuspendThread . Code execution is then achieved by exchanging the thread context\r\nusing GetThreadContext and SetThreadContext such that the registers of the thread context points to attacker-controlled memory. Naturally, since the thread execution of the target process is suspended it is in many scenarios\r\ndesirable to restore faithful execution in the target process in order for the system to continue execution unnoticed.\r\nThe attacker can also initiate execution of the attacker-controlled memory in the remote process through\r\nasynchronous procedure calls such as QueueUserAPC , NtQueueApcThread , ZwQueueApcThread and\r\nRtlQueueApcWow64Thread . However, one of the drawbacks of doing this, however, is that the remote thread must\r\nbe in an alertable state to trigger the APC.\r\nReflective DLL injection\r\nIn the previous methods we were mainly concerned with how to achieve code execution in the remote process.\r\nHowever, a question that comes up once you achieve code execution is what code to execute. In most cases just\r\nexecuting shellcode doesn't do the job as the attacker desires to have more comprehensive control. Reflective DLL\r\ninjection is a technique that focuses on this aspect of the code-injection design space using a self-loadable DLL\r\nfile. Specifically, reflective DLL injection is a technique that creates a DLL such that the DLL has a minimal\r\nWindows loader as an exported function. When this function is triggered the DLL will load itself inside the\r\nprocess of which it has been written, thus avoiding the need to be loaded from disk by the regular Windows\r\nloader. As such, it is not necessary to, for example, rely on calls like LoadLibrary to load a fully-fledged library\r\ninside the target process. Rather, the attacker can simply allocate space in the remote process, write the raw DLL\r\ncontent there, and then execute the exported function in the DLL itself. Lazarus is an example of malware that\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 3 of 10\n\nuses reflective DLL injection and pentesters published at Blackhat a white paper on a novel packer that uses\r\nreflective DLL injection here.\r\nCustom loading of PE sections in reflective DLL injection. Code for the reflective loader can be\r\nfound here.\r\nProcess hollowing\r\nA technique closely related to hijacking a remote thread is to simply substitute the entire memory of the remote\r\nprocess with attacker-controlled memory. Process hollowing does this. The steps in process hollowing is to create\r\na process in suspended mode, then deallocate the memory of the suspended process (this is where the \"hollow\"\r\ncomes from), write an attacker-controlled image to the target process and then resume execution of the target\r\nprocess. Effectively, the goal is to explicitly hide execution of the malicious code in disguise of a benign process.\r\nProcess hollowing is a commong techniques in malware samples, with an example report found here.\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 4 of 10\n\nUnloading of the main module and then reallocating memory for the new executable in\r\nProcessHollowing. Source code can be found here.\r\nExample of advanced techniques\r\nThe majority of injections observed in the wild are of the types described in the previous section. However,\r\n(mostly) in recent years several novel techniques have been discovered that rely on approaches outside the scope\r\nof the previous techniques. These novel techniques use different API calls to achieve their code injection,\r\nsometimes rely on exploit-like techniques such as return oriented programming and are quite often specific to\r\ncertain target applications. However, on an abstract level they still remain close to our most basic techniques as\r\nthey still have to (1) communicate with the target process; (2) ensure attacker-controlled memory is written to the\r\nprocess and (3) trigger execution of attacker-controlled code in the process. It is important to emphasize in this\r\nblog post we only highlight some examples of these techniques rather than an exhaustive list. In particular, we\r\nhave prioritised selection of techniques that have been documented to be used in attacks.\r\nGhostwriting\r\nThe main idea of GhostWriting is to force the target process to write malicious content in it's address space and\r\nforce this code to be executed without calling any of OpenProcess , VirtualAlloc or CreateRemoteThread , or\r\nsimilar. GhostWriting achieves this by selecting two atomic gadgets (ROP gadgets), one that writes the value of a\r\nregister to an address given by the value of a different register ( mov [reg1], reg2 ) and another gadget that\r\nsimply represents an eternal loop jmp 0x0 . The technique then makes use of SuspendThread ,\r\nGetThreadContext , SetThreadContext and ResumeThread to continuously overwrite memory in the target\r\nprocess. Specifically, it continuously sets the registers such that they overwrite a given address with the desired\r\ncontent, and then jumps to the eternal loop. As SetThreadContext allows the attacker to control the registers it is\r\neasy to overwrite the stack - or any other address in the target process - with whichever content the attacker\r\ndesires. After the mov [reg1], reg2 gadget executes it returns to the eternal loop gadget, and the attacker gains\r\ncontrol over the execution simply by calling SuspendThread , such that the execution does not run in the eternal\r\nloop forever. Rather, the \"eternal loop\" is used as a temporary safe-state for the attacker to ensure consistency in\r\nthe target process. A concrete example of using this is to to create a stackframe to NtProtectVirtualMemory that\r\nsets the necessary permissions for attacker-written shellcode. However, the technique used for achieving write-what-where and execute-on-demand is far more general and can be used to write any type of code to the target,\r\ne.g. a fully functioning PE file.\r\nA quite interesting aspect of GhostWriting is that the technique was first made public in 2007, yet it still remains\r\nlargely one or the more sophisticated techniques. The original blog post explaining the technique is available here.\r\nShellcode written by the original GhostWriting code. The source can be found here.\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 5 of 10\n\nThe main function that GhostWriting uses to continuously write desired content in target process.\r\nBy setting registers in the thread context so they point to selected gadgets GhostWriting maintains\r\ncontrol of the target process.\r\nPowerLoader and PowerLoaderEx\r\nThe idea behind PowerLoad is to abuse shared sections in Windows and overwrite several function pointers inside\r\nexplorer.exe to point to attacker-controlled memory in the shared section. Since this shared section is non\r\nexecutable PowerLoader relies on a ROP chain to execute shellcode within explorer.exe . In more detail,\r\nPowerLoader first gets a handle to a window in explorer.exe . This window contains a pointer to a CTray class\r\nobject, which is used for handling messages sent to the particular window. PowerLoader then uses\r\nSetWindowLongPtr to replace this CTray object, such that it now points to memory in a shared section. Within\r\nthis shared section, PowerLoader writes its malicious code, which is a combination of a ROP chain as well as\r\nshellcode. PowerLoader then triggers the execution of the ROP chain by sending the window a message, using\r\nSendNotifyMessage . The ROP chain then overwrites a function within ntdll called atan with shellcode and\r\ntransfers execution to this shellcode. This technique was first used by the Gapz malware and has since been\r\ngeneralised by researchers from Ensilo, that made the attack non-specific to the shared sections. You can find the\r\nsource code for PowerLoaderEx here\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 6 of 10\n\nMessage handler in explorer that PowerLoader hijacks.\r\nAtomBombing\r\nAtomBombing is another technique that uses ROP chains to get code execution in the remote process.\r\nSpecifically, AtomBombing abuses the global atom table in Windows to share memory between processes and\r\nundocumented asynchronous procedure calls to force the target process into calling various functions on behalf of\r\nthe injecting process. The injecting process writes a ROP chain and shellcode to the global atom table using the\r\nWindows function GlobalAddAtom . The injector then uses NtQueueApcThread to force the injected process to\r\ncall GlobalGetAtomName to store the ROP chain and shellcode inside the target process. To invoke execution, the\r\ninjector again uses NtQueueApcThread to force the injected process to call SetThreadContext to set eip and esp.\r\nEip is set to the address of ZwAllocateVirtualMemory and esp is set to point to the beginning of the ROP chain.\r\nThe injection is, therefore, achieved with a combination of NtQueueApcThread and GlobalAddAtom . An\r\ninteresting aspect of AtomBombing is that not long after the publication of the technique an updated version of the\r\ninfamous Dridex malware was discovered, that had adopted a modified version of the AtomBombing technique,\r\nand this is still being used in 2019.\r\nProcess Doppelganging\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 7 of 10\n\nThe idea behind doppelganging is to improve the limitations of process hollowing, namely how the executable\r\nmemory is written into the target process. Doppelganging achieves this by way of Windows Transactions.\r\nDoppelganging loads a benign executable using CreateTransaction and CreateFileTransacted , but then\r\noverwrites the content of the transacted file with malicious code, using WriteFile . Doppelganging then creates a\r\nsection that holds the tainted transaction, i.e. the transaction that holds the malicious memory, and then performs a\r\nrollback on the transaction. The rollback will undo the changes performed by the transaction, which in\r\nDoppelganging's context is the overwriting of the benign file, so the changes to the benign file won't actually be\r\ncommited to the file system. However, the caveat here is that the content of the section still contains the tainted\r\ncode. Now, doppelganging proceeds to create the target process with the content of the malicious section.\r\nDoppelganging creates the process in a low-level way using NtCreateProcess , and, therefore, has to perform\r\nvarious set-ups for the process to accurately execute, such as setting up process parameters and create the\r\nprocess's main threads. An example of Process Doppelganging in the wild was discovered in early 2018.\r\nEarlybird\r\nEarly bird refers to a technique that performs a somewhat traditional code injection via remote thread instantiation\r\nearly in the process initialisation phase. Specifically, the attacker creates a new process in suspended mode and\r\nthen proceeds to allocate and write memory to the process. In order to trigger execution the malware uses an\r\nasynchronous procedure call and enforces execution of the APC call using the NtTestAlert function. The\r\ntechnique was discussed by researcher from Cyberbit and even though it received its own name, it is closely\r\nrelated to earlier techniques traditional injection. This is also confirmed by the fact that the injection dates back to\r\nat least 2012.\r\nCode snippet of Earlybird injection.\r\nctrl-inject\r\nThe ctrl-c key combination is a well-known pattern for exiting and shutting down applications. The ctrl-inject\r\ninjection technique exploits the underlying features that makes this hotkey possible. Specifically, when a user\r\npresses the ctrl + c keyword in a console application a system process ( csrss.exe ) invokes a function called\r\nCtrlRoutine in a new thread of the given console application. The CtrlRoutine fetches the given handler for\r\nthe control signal (ctrl + c) which contains a function pointer that will be called, which effectively is used to\r\nhandle the signal. In short, the technique overwrites this signal handler with a malicious function pointer, such that\r\nwhenever the signal occurs the malicious handler will be called.\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 8 of 10\n\nThe strengths of ctrl-inject is that the technique does not rely on any function calls like CreateRemoteThread ,\r\nResumeThread or SetThreadContext , but rather triggers execution through the csrss.exe process. The\r\ntechnique that triggers the execution is a simple ctrl-c signal which in many scenarios is considered harmless and\r\nunsuspicious. The drawback of the technique is that it only works with console based applications.\r\nCode that triggers the injection in ctrl-inject. Source code can be found here\r\nPROPagate\r\nThis technique was discovered in late 2017 and uses functionality of window subclassing to gain code execution\r\nin remote processes. Windows subclassing enables programmers to reuse functionality in existing controls by\r\nadding functionality and features to them. Whenever a window is subclassed, the messages to the original window\r\nis intercepted by the subclassing window which executes its own handlers before sending them on to the parent.\r\nYou can read more about subclassing here. Whenever a window is subclassed it gets a new property called either\r\nxSubclassInfo or CC32SubclassInfo and stores the data structures related to these properties in its address space.\r\nThis property points to a data structure inside the subclassed process which contains a function pointer that gets\r\nexecuted in the event of a message being sent to the window. The idea behind PROPagate is then to write a\r\nmalicious data structure inside the remote process and use the SetProp function call to point to this handler. The\r\nattacker then uses SendNotifyMessage to trigger the malicious function handler. Roughly 8 months after the first\r\ndocumentation of PROPagate by Adam, FireEye discovered the RIG Exploit Kit delivering a dropper that used\r\nPROPagate.\r\nThe code that will trigger the PROPagate injection by setting the UxSubclassInfo property within\r\nthe target window to a have a fake handler. Source code can be found here\r\nShatter-style attacks\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 9 of 10\n\nThe final category of code injections that we cover in this course is called Shatter attacks. The basic idea behind\r\nthese injections is to misuse the message-oriented way that windows are architectured within Windows.\r\nSpecifically, whenever applications use windows they control these in a message-oriented ways which is a very\r\nmodular and effective way of managing windows. For example, when a key is pressed a messaged is sent to the\r\ncurrently active window stating this key was pressed. However, the way these messages are handled by the active\r\nwindow is through message handlers, i.e. data structures, and at certain times these can be overwritten with\r\nattacker controlled memory. Since a window can send messages to other windows on the desktop and we can\r\noverwrite memory using previously mentioned primitives, we can start to construct code injections by overwriting\r\nthe message handlers in our target processes and then sending messages that trigger the respective handlers.\r\nShatter attackers were first presented by Chris Paget (Now Kristine Paget) in 2002, however, the technique\r\nremains relevant. Recently, Hexacorn and Odzhan presented seven new ways of doing this.\r\nFuture outlooks\r\nCode injections are continuously being used and there is a trend of increasingly more novel techniques being\r\nresearched by defenders as well. For example, even in 2019 alone modexp has presented at least 15 novel\r\ninjections (many inspired by Hexacorn), and modern malware samples use long chains of code injections to\r\nexecute on the target system, such as the recent Dridex that uses five in total. The novel techniques are much\r\nmore specific than the traditional injection attacks, and are now targeted internal structurse within the target\r\nprocesses rather than relying purely on common APIs. We can safely expect more exploit-like scenarios in the\r\nfuture and also new ways of enforcing process separation. Furthermore, even Academia is now in the field as well,\r\nboth researching how we can use system-wide execution to construct highly sophisticated malware that operates\r\nacross many processes (malwash) and how to generically analyse novel injection techniques. Code injections\r\nare here to stay and the complexity of them will increase. We highly recommend getting started with these\r\ntechniques if you aren't already, and also predict that we will find more defensive tools and techniques being\r\ndeveloped in the near future.\r\nConclusions\r\nCode injections, also known as process injections, is an important topic in terms of post-exploitation strategies.\r\nAttackers, including both malware and pentesters, use these injections to execute code in otherwise benign\r\nprocesses as a way to bypass white-lists deployed by the defense products, e.g. host-based intrusion prevention\r\nand endpoint protection systems. From a defenders point of view we need to ensure our defense systems are aware\r\nof these tricks - and derivates hereof - in order to ensure our automated procedures are sound. Furthermore, from\r\nan attackers point of view, e.g. a pentester, these techniques can be of great benefit in order to secure access to a\r\ntarget machine. In this blog post we gave a motivation for both defenders and attackers on why studying code\r\ninjections is relevant, and also highlighted technical aspects of several code injection techniques and attacks that\r\nuse them.\r\nSource: https://adalogics.com/blog/the-state-of-advanced-code-injections\r\nhttps://adalogics.com/blog/the-state-of-advanced-code-injections\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://adalogics.com/blog/the-state-of-advanced-code-injections"
	],
	"report_names": [
		"the-state-of-advanced-code-injections"
	],
	"threat_actors": [],
	"ts_created_at": 1775434949,
	"ts_updated_at": 1775791305,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1a27b348127a9bb76ff3c76bcec1702f1ae885a8.pdf",
		"text": "https://archive.orkl.eu/1a27b348127a9bb76ff3c76bcec1702f1ae885a8.txt",
		"img": "https://archive.orkl.eu/1a27b348127a9bb76ff3c76bcec1702f1ae885a8.jpg"
	}
}