Technique T1055

Process Injection

Process Injection enables adversaries to evade defensive controls by executing potentially suspicious processes in the context of seemingly benign ones.

Pairs with this song


Overall rank


Organizations affected


Confirmed threats


Why do adversaries use Process Injection?

Process Injection is a versatile technique that facilitates a wide range of actions. It’s so versatile, in fact, that MITRE reorganized it into 11 sub-techniques in summer 2020. Red Canary doesn’t currently map a substantial number of detection analytics to any of Process Injection’s sub-techniques. We perform our mapping at the analytic level, which means we’re forecasting what technique an analytic might detect. This works well in general, but it’s very hard to accurately forecast what type of injection might be used in the absence of context. As such, this section will focus on Process Injection generally, rather than its most prevalent sub-techniques.

Process Injection allows adversaries the ability to execute malicious activity by proxy through processes that either have information of value (e.g., lsass.exe) or as a means of blending in with seemingly “normal” processes. In this way, malicious activity—whether an overtly malicious binary or a process that’s been co-opted as such—blends in with routine operating system processes. Process Injection allows payloads to be launched within the memory space of a running process, in many cases without needing to drop any malicious code to disk.

For example, you may be able to build a high-fidelity detection analytic that triggers any time PowerShell makes an external network connection. However, to avoid this method of detection, an adversary might inject their PowerShell process into a browser. In doing so, they’ve taken a potentially suspicious behavior—PowerShell making an external network connection—and replaced it with a seemingly normal behavior—a browser making an external network connection. What was detectable based on process lineage and network connections before Process Injection now relies on a mix of command-line parameters, binary metadata, and reputational scores, to name a few telemetry sources.

In addition to being stealthy, arbitrary code can inherit the privilege level of the process it is injected into and gain access to parts of the operating system that shouldn’t be otherwise available.

How do adversaries use Process Injection?

With 11 sub-techniques, there’s no shortage of ways that an adversary can perform Process Injection. Some standout flavors include:

  • remotely injecting DLLs into running processes
  • injecting into high-reputation, built-in executables such as notepad.exe to make external network connections and later injecting code that performs malicious actions
  • leveraging Microsoft Office applications to create RemoteThread injections into dllhost.exe to conduct attacks with malicious macros in place of spawning suspicious child processes
  • cross-process injection initiated by lsass.exe into taskhost.exe
  • Metasploit injecting itself into processes such as svchost.exe
  • injecting into a browser process to enable snooping on a user’s browsing session, which is a common characteristic of banking and other credential-stealing trojans
  • injecting into lsass.exe to dump memory and extract credentials
  • injecting into browsers to normalize network connections that would seem suspicious if they were initiated by processes other than a browser

Searchprotocolhost.exe is another frequent target of Process Injection. Adversaries take advantage of investigative biases that lead analysts to disregard this built-in, signed, and sufficiently esoteric utility.

Emerging Process Injection tradecraft

We wouldn’t characterize this as an emergent technique necessarily, but widely and openly available malware kits like Cobalt Strike, Metasploit, and other offensive tools have considerably lowered the barrier of entry for adversaries seeking to leverage Process Injection. What once existed mostly in the domain of more capable adversaries has since trickled down to nearly everyone else.



Collection requirements

Process monitoring

Process monitoring is a minimum requirement for reliably detecting Process Injection. Even though injection can be invisible to some forms of process monitoring, the effects of the injection become harder to miss once you compare process behaviors against expected functionality.

API monitoring

If possible, monitor API system calls that include CreateRemoteThread in Windows. This will indicate a process is using the Windows API to inject code into another process. Security teams should monitor for ptrace system calls on Linux as well. Such monitoring would also include data sources that track when a handle to a target process is requested and/or granted, like Sysmon Event ID 10.

Command-line monitoring

Certain endpoint detection and response (EDR) products and Sysmon can provide alerting on suspected Process Injection activity. With either tool, monitoring for suspicious command-line parameters can be an effective way of observing and detecting potential Process Injection at scale. Some tools are purpose-built to have their injection arguments supplied at the command line, like mavinject.exe. So while command-line monitoring can’t catch all forms of injection, it can certainly help.

Detection opportunities

The detection of Process Injection involves hunting for legitimate processes doing unexpected things. This may involve processes making external network connections and writing files or processes spawning with unexpected command-line arguments.

Unusual process behaviors

Some specific patterns of behavior to look out for:

  • a process that appears to be svchost.exe making network connections on tcp/447 and tcp/449, a behavior consistent with TrickBot
  • a process that appears to be notepad.exe making external network connections
  • a process that appears to be mshta.exe calling CreateRemoteThread to inject code
  • a process that appears to be svchost.exe executing without corresponding command lines

Unusual paths and command lines

Some good examples of odd paths or command lines that may indicate injection:

  • rundll32.exe, regasm.exe, regsvr32.exe, regsvcs.exe, svchost.exe, and werfault.exe process executions without command-line options may indicate they are targets of Process Injection.
  • Microsoft processes such as vbc.exe with command lines including /scomma, /shtml, or /stext may indicate the injection of Nirsoft tools for credential access.
  • Linux processes with memfd: in their path indicate they were spawned from code injected into another process.

Injection into LSASS

Since injection into lsass.exe is common, impactful, and frequently suspicious, it deserves to be called out individually. To that point, it would be worth your time to determine and enumerate the processes in your environment that routinely or occasionally obtain a handle to lsass.exe. Any access outside of the baseline should be treated as suspicious. Discerning suspicious from malicious might involve considering the reputation of the unusual process that requested the access to lsass.exe (e.g., powershell.exe process with an unexpected command line, access requests from from an unsigned executable located in a world-writable directory like %APPDATA% or %ProgramData%, etc.).

Weeding out false positives

The analytics that produced the most false positives in our dataset came from looking for CreateRemoteThread calls from any and all processes. Many tools in Windows use Process Injection legitimately for debugging and virtualization. If you want to write analytics around this API call, focus them on unusual source processes, such as Microsoft Office products and tools that commonly deliver first-stage malware like scripts and Mshta.

Further, processes like lsass.exe and svchost.exe are both common targets for Process Injection and common processes in general. As such, baselining normal against abnormal will be an important step in fighting false positives. Consider the following:

  • In some environments, you might be able to reliably detect on specific processes injecting into lsass.exe. However, you might achieve better detection outcomes by correlating cross processes with executing processes, including LOLBINs like MSbuild, PowerShell, Wscript, Cscript, Msiexec, Rundll32, and more
  • Additionally, svchost.exe is a common process targeted for Process Injection. Due to the large volume, taking the approach of identifying known processes that may execute code can help reduce the amount of noise generated


Getting Started With Atomic Red Team

Start testing your defenses against Process Injection using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

View atomic tests for T1055: Process Injection. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using an elevated PowerShell prompt:
mavinject.exe ((Get-Process lsass).Id) /INJECTRUNNING C:\Windows\System32\vbscript.dll

What to expect

mavinject.exe will inject vbscript.dll into the running lsass.exe process using Dynamic-link Library Injection. We chose to use mavinject.exe as an example for its simplicity.

Useful telemetry will include:
Data sourceTelemetry
Data source:

Process monitoring


A mavinject.exe process will start.

Data source:

Process command-line parameters


Command-line logging will capture the context of what is executed.

Data source:

DLL monitoring


vbscript.dll will load in the lsass.exe process.

Data source:

Windows event logs


Event log entries related to obtaining a handle to lsass.exe:

Review and repeat

Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:

  • Were any of your actions detected?
  • Were any of your actions blocked or prevented?
  • Were your actions visible in logs or other defensive telemetry?

Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.

Shane Welcher
Detection Engineer
Shane has a wide range of security experience: data analysis, forensics, debugging malware, penetration testing, and network and system administration. He is passionate about open source projects and was the highest community contributor to the Atomic Red Team GitHub project before joining Red Canary. In his free time, Shane enjoys studying different approaches to exploiting networks and applications, assisting others with open-source SIEM solutions, and traveling.
Shane has a wide range of security experience: data analysis, forensics, debugging malware, penetration testing, and network and system administration. He is passionate about open source projects and was the highest community contributor to the Atomic Red Team GitHub project before joining Red Canary. In his free time, Shane enjoys studying different approaches to exploiting networks and applications, assisting others with open-source SIEM solutions, and traveling.