Overview

Process injection (T1055) is a technique where adversaries insert and execute arbitrary code within the address space of a running, legitimate process. By hijacking a trusted process, attackers can access its memory, inherit its privileges, and abuse its system or network resources — all while appearing to be benign software.

Every security team must prioritize detection of this technique because it is a cornerstone of post-exploitation tradecraft, used heavily by commodity malware, ransomware operators, and advanced persistent threat (APT) groups alike. Because the malicious code runs under a legitimate process identity, it bypasses many process-allowlist controls and evades endpoint tools that rely solely on process name or hash matching.

Attacker Perspective

After gaining an initial foothold, attackers use process injection to blend malicious activity into trusted processes, escalate privileges, and maintain stealth throughout their operation.

• Reflective DLL Injection via Metasploit/Cobalt Strike: Attackers use migrate or shinject commands to inject a reflective DLL or shellcode directly into a running process like explorer.exe or svchost.exe, inheriting its token and avoiding disk writes.
• Process Hollowing with custom loaders: Malware (e.g., TrickBot, Dridex) spawns a legitimate process such as svchost.exe in a suspended state using CreateProcess with CREATE_SUSPENDED, unmaps its memory, writes malicious code in its place, then resumes execution.
• Linux ptrace injection: On Linux, tools like linux-inject or custom shellcode loaders call ptrace(PTRACE_ATTACH, target_pid) followed by PTRACE_POKETEXT to overwrite a running process’s memory, commonly targeting sshd or application daemons.
• macOS task_for_pid / Dylib injection: Attackers abuse the task_for_pid() Mach API or use DYLD_INSERT_LIBRARIES to inject a malicious dylib into a running process with elevated permissions, a technique observed in macOS adware and spyware families like XCSSET.

Process injection is uniquely attractive to attackers because it provides execution without dropping obvious executables to disk, inherits the privileges and trust context of the host process, and forces defenders to look past simple process-name-based detections.

Detection Strategy

Required Telemetry

• Windows — Sysmon Event ID 8 (CreateRemoteThread): Install Sysmon with a configuration that captures CreateRemoteThread events. This fires when one process creates a thread in another, a primary injection primitive. Deploy via Sysmon config with <CreateRemoteThread onmatch="include"> targeting all processes, or use the SwiftOnSecurity/Sysmon config as a baseline.
• Windows — Sysmon Event ID 10 (ProcessAccess): Captures OpenProcess calls with specific access rights such as PROCESS_VM_WRITE (0x0020), PROCESS_VM_OPERATION (0x0008), and PROCESS_CREATE_THREAD (0x0002). Enable in Sysmon config with <ProcessAccess onmatch="include"> and filter for suspicious granted access masks.
• Windows — Sysmon Event ID 1 (Process Create): Records full command lines and parent-child process relationships. Enable via Sysmon with <ProcessCreate onmatch="include">. Required to detect process hollowing where a legitimate binary is spawned by an unexpected parent.
• Windows — Security Event ID 4688 (Process Creation with command line): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → Success. Also enable command-line capture: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1.
• Windows — Sysmon Event ID 7 (Image Load): Detects DLL loads into processes, useful for catching reflective DLL injection where an unsigned or unexpected DLL appears in a trusted process. Enable with <ImageLoad onmatch="include"> and log unsigned modules in sensitive processes.
• Windows — Sysmon Event ID 17/18 (Pipe Created/Connected): Named pipe events help detect inter-process communication used by post-injection implants (e.g., Cobalt Strike’s default named pipes like \\.\pipe\MSSE-*).
• Windows — ETW (Event Tracing for Windows) via Microsoft-Windows-Threat-Intelligence provider: This kernel-level provider surfaces API calls like VirtualAllocEx, WriteProcessMemory, and NtQueueApcThread that are direct injection primitives. Accessible via EDR tools or custom ETW consumers. No built-in Event ID — requires EDR or tools like SilkETW.
• Linux — Auditd rules for ptrace and process memory access: Add the following rules to /etc/audit/rules.d/injection.rules:
  -a always,exit -F arch=b64 -S ptrace -k process_injection and
  -a always,exit -F arch=b64 -S process_vm_writev -S process_vm_readv -k process_injection. Restart auditd to apply.
• Linux — Auditd for suspicious process execution chains: -a always,exit -F arch=b64 -S execve -k exec_chain to capture all execve calls with full argument logging. Pair with ausearch or forward to SIEM via auditbeat or rsyslog.
• macOS — Endpoint Security Framework (ESF) or OpenBSM audit: Enable BSM auditing with sudo audit -s and configure /etc/security/audit_control to include lo,ad,pc audit classes. ESF-based EDR tools (e.g., Jamf Protect, SentinelOne) natively surface task_for_pid calls and dylib injection events.
• EDR telemetry (cross-platform): Tools such as CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, or Carbon Black provide pre-built detection of injection APIs and are the most reliable data source for this technique. Ensure EDR agents are deployed and reporting to your SIEM via API or connector.

Key Indicators

• CreateRemoteThread into sensitive processes (Sysmon EID 8): In the TargetImage field, look for values such as lsass.exe, explorer.exe, svchost.exe, winlogon.exe, or spoolsv.exe. The SourceImage should be an untrusted or unexpected binary. Flag any event where StartAddress points outside known module ranges (unbacked memory).
• Suspicious ProcessAccess rights mask (Sysmon EID 10): Check the GrantedAccess field. High-risk masks include 0x1F0FFF (all access), 0x1010 (read/write memory), and 0x1F3FFF. Any non-EDR, non-AV process requesting PROCESS_VM_WRITE | PROCESS_CREATE_THREAD against lsass.exe or winlogon.exe is highly suspicious.
• Unsigned or anomalous DLL loaded into trusted process (Sysmon EID 7): In ImageLoaded, flag DLLs where Signed = false and the loading process is svchost.exe, explorer.exe, or a browser. Also flag DLLs loaded from %TEMP%, %APPDATA%, or user-writable paths.
• Process hollowing signature (Sysmon EID 1): Look for svchost.exe, RuntimeBroker.exe, or dllhost.exe spawned by unexpected parents such as cmd.exe, powershell.exe, wscript.exe, or Office applications. Check ParentImage against known-good baselines. Also look for svchost.exe launched without the standard -k argument flag.
• Linux ptrace calls (Auditd): In auditd logs, search for syscall=ptrace with a0=0x10 (PTRACE_ATTACH) or a0=0x4 (PTRACE_POKETEXT) where the calling process is not a known debugger (gdb, strace, lldb). Key fields: comm (process name), pid, ppid.
• Cobalt Strike named pipe indicators (Sysmon EID 17/18): In PipeName, look for patterns like \\.\pipe\MSSE-, \\.\pipe\postex_, \\.\pipe\status_, or short random-looking alphanumeric pipe names created by non-system processes.
• Network connections from unusual process hosts (Sysmon EID 3): If svchost.exe, notepad.exe, calc.exe, or other processes that do not normally communicate externally make outbound connections, flag the event. Key fields: Image, DestinationIp, DestinationPort. Cross-reference destination IPs against threat intelligence feeds.
• macOS DYLD_INSERT_LIBRARIES in process environment: In ESF or OpenBSM logs, check process launch events for the DYLD_INSERT_LIBRARIES environment variable set to a non-system path. This is a reliable indicator of dylib injection attempts.

Detection Logic

Rule 1: Remote Thread Created in Sensitive Process
IF EventID = 8 AND TargetImage IN ["lsass.exe","svchost.exe","explorer.exe","winlogon.exe","spoolsv.exe"] AND SourceImage NOT IN ["known_edr_agent.exe","antivirus.exe","mrt.exe"] THEN alert HIGH

This rule catches the most common injection primitive — creating a remote thread in a high-value process. Expect moderate volume initially; tune down after baselining your EDR and AV processes, which legitimately call CreateRemoteThread. Without exclusions this will fire frequently in the first week of deployment.

Rule 2: Suspicious ProcessAccess to LSASS with Write/Execute Rights
IF EventID = 10 AND TargetImage CONTAINS "lsass.exe" AND GrantedAccess IN ["0x1F0FFF","0x1010","0x1F3FFF","0x143A"] AND SourceImage NOT IN ["lsass.exe","MsMpEng.exe","csrss.exe","wininit.exe"] THEN alert CRITICAL

This targets credential theft and injection into LSASS simultaneously. LSASS is the most abused target for both dumping credentials and injecting implants. This rule should be low volume and nearly every alert warrants investigation. Expect false positives primarily from EDR and backup agents — build your exclusion list from your environment baseline.

Rule 3: Svchost or System Process Spawned by Abnormal Parent
IF EventID = 1 AND Image CONTAINS "svchost.exe" AND ParentImage NOT IN ["services.exe","MsMpEng.exe"] THEN alert HIGH
IF EventID = 1 AND Image IN ["svchost.exe","dllhost.exe","RuntimeBroker.exe"] AND CommandLine NOT CONTAINS "-k" THEN alert HIGH

This detects process hollowing where attackers spawn legitimate system binaries from unexpected parents or without their standard arguments. Should be low volume in a well-baselinded environment. Expect occasional false positives from software installers and some legitimate management tools.

Rule 4: Linux ptrace Attach by Non-Debugger Process
IF auditd.syscall = "ptrace" AND auditd.a0 IN ["0x10","0x4"] AND process.name NOT IN ["gdb","strace","lldb","python","java"] AND user.name NOT IN ["root_debug_accounts"] THEN alert HIGH

This catches ptrace-based injection on Linux, which is a less common but powerful injection method. Volume should be very low in production environments — any alert outside a development or debugging context warrants immediate review. Developers using debuggers in non-standard locations may trigger this; use path-based exclusions where needed.

Tuning Guidance

• EDR and AV agents: Security products legitimately call OpenProcess with high-privilege access masks and create remote threads as part of their monitoring. Identify the exact process names and paths for your EDR (e.g., MsMpEng.exe, SenseCnfg.exe, falcon-sensor) and add them as exclusions with path validation — do not exclude by process name alone, as attackers can copy names. Exclude SourceImage = "C:\Program Files\Windows Defender\MsMpEng.exe" rather than just MsMpEng.exe.
• Software installers and update mechanisms: Legitimate software installers (e.g., Adobe, Java, enterprise deployment tools like SCCM or Tanium) frequently inject into processes or spawn system binaries. Baseline these activities by time-boxing (they occur during maintenance windows) and by parent process. Add ParentImage = "C:\Windows\CCM\CcmExec.exe" exclusions for SCCM-driven deployments.
• Development and debugging tools: On developer workstations, devenv.exe (Visual Studio), gdb, lldb, and WinDbg legitimately attach to processes. Exclude these by host group (developer workstation OU or asset tag) rather than globally, to preserve detection on production servers. Use host.group NOT IN ["dev_workstations"] logic.
• Java and .NET runtimes: JVM and CLR processes regularly inject helper threads and load modules dynamically into other JVM processes, triggering EID 10 and EID 8 alerts. Exclude known Java/CLR process pairs but monitor for Java processes making unexpected network connections post-alert, as this can indicate a legitimate trigger masking real compromise.
• Remote monitoring and management (RMM) tools: Tools like ConnectWise Automate, TeamViewer, and Datto RMM use injection-like techniques for remote session management. Document all approved RMM tools and exclude their signed binaries by hash or certificate thumbprint rather than by name.

When the Alert Fires: Investigation Steps

1. Verify the alert is real by confirming the raw event in the source log. Pull the original Sysmon EID 8 or EID 10 event directly from your SIEM using the event’s unique EventRecordID and confirm all fields (SourceImage, TargetImage, GrantedAccess, timestamps) are intact and not the result of a parsing error or test rule.
2. Identify the affected host and user account, and check privilege level. In your EDR or Active Directory, confirm whether the user account associated with the source process is a standard user, local administrator, or domain administrator — escalate immediately if a privileged account is involved, as blast radius is significantly higher.
3. Pull the full process tree and command-line history for the injecting process. Use Sysmon EID 1 logs or your EDR’s process tree view to trace the source process back to its root parent. Look for LOLBin parents (e.g., powershell.exe, wscript.exe, mshta.exe) or Office applications, which are common initial access vectors that lead to injection.
4. Check for network connections made by the injected (target) process after the injection event. Query Sysmon EID 3 or EDR network telemetry for any outbound connections from TargetImage in the 30 minutes following the injection timestamp. Flag any connections to public IPs, non-standard ports, or domains not present in your DNS baseline — this is the most common sign of an active C2 channel.
5. Search for files written to disk by the injecting or injected process. Use Sysmon EID 11 (FileCreate) or EDR file activity logs filtered by the PIDs of both the source and target process. Pay particular attention to files written to %TEMP%, %APPDATA%, C:\ProgramData, or any world-writable directory — hash any identified files and submit to VirusTotal or your internal sandbox.
6. Look for lateral movement originating from the compromised host after the injection time. Query Windows Security EID 4624 (Logon Type 3 or 10) and EID 4648 (explicit credential use) in your SIEM for any authentication events sourced from the affected host following the injection. Also check for SMB lateral movement via Sysmon EID 3 on port 445 and any new remote service creation (EID 7045) on destination hosts.
7. Search for persistence mechanisms installed on the affected host. Review Sysmon EID 12/13 (Registry modifications) for Run key additions (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), Sysmon EID 11 for new files in startup folders, and Windows Security EID 4698 for new scheduled task creation. On Linux, check /etc/cron*, ~/.bashrc, and systemd unit files for additions made after the injection timestamp.

Response Playbook

Containment

• Isolate the affected host from the network immediately, but leave it powered on. Use your EDR’s network isolation feature (e.g., CrowdStrike’s “Contain Host,” Defender for Endpoint’s “Isolate Device”) rather than physically unplugging the machine — this preserves the live memory state, active processes, and volatile artifacts needed for forensics. Confirm isolation by verifying the host can no longer reach the internet or internal segments while still communicating with the EDR console.
• Disable the affected user account without resetting the password yet. In Active Directory, disable the account via Disable-ADAccount -Identity username or the ADUC console. Do not reset the password immediately — credential analysis may be needed. If the account has active Kerberos tickets, also run klist purge on affected systems or force a domain-wide ticket invalidation if the account is privileged.
• Block identified C2 IPs and domains at the perimeter firewall and DNS resolver. Submit any external IPs or domains identified in step 4 of the investigation to your firewall team for an emergency block. Also add them as sinkhole entries on your internal DNS server and create a proxy block rule if applicable. Document the block with a timestamp and link to the incident ticket.
• Kill the malicious injected process on the host (if EDR isolation is not sufficient). Using your EDR’s remote shell or live response capability, terminate the target process that was injected into using taskkill /PID [pid] /F on Windows or kill -9 [pid] on Linux. Capture a process memory dump first if possible: procdump -ma [pid] C:\forensics\dump.dmp using Sysinternals ProcDump, or gcore [pid] on Linux.
• Revoke active sessions and OAuth tokens for the affected user. In Azure AD / Entra ID, revoke all refresh tokens using Revoke-AzureADUserAllRefreshToken -ObjectId [user_object_id]. For on-prem environments, reset the Kerberos KRBTGT account twice (with a 10-hour replication window between resets) if a domain administrator account was compromised.

Eradication

• Remove all identified persistence mechanisms from the affected host. Delete any malicious scheduled tasks identified in investigation step 7 using schtasks /delete /tn "TaskName" /f. Remove malicious registry Run keys using reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "MaliciousEntry" /f. Remove any new services created by the attacker via sc delete ServiceName.
• Locate and delete all dropped payloads and attacker tools from disk. Using your EDR’s file search or live response, hunt for files with hashes matching those identified during investigation, as well as any files dropped in the paths flagged in step 5. On Windows, also search for LOLBin abuse artifacts such as encoded scripts in %TEMP% or scheduled task XML files in C:\Windows\System32\Tasks.
• Reset credentials for all accounts that executed or were touched by the malicious process. This includes the primary user account, any service accounts the process ran as, and any accounts whose credentials may have been accessible in memory on the host (e.g., accounts that had authenticated sessions open at the time of compromise). Generate new, complex passwords and force re-enrollment of MFA if applicable.
• Check all hosts the affected user or host authenticated to for signs of lateral movement. For each destination identified in investigation step 6, deploy your EDR live response to search for the same IOCs (file hashes, process names, named pipes, registry keys). Run a targeted threat hunt on these hosts before clearing them — attackers frequently stage from one host to another before achieving their objective.
• Rotate any secrets, API keys, or certificates that were accessible from the compromised host. Check for stored credentials in browser profiles, Windows Credential Manager (cmdkey /list), SSH keys in ~/.ssh/, and application configuration files. Rotate any secrets found and audit their usage logs for unauthorized activity during the compromise window.

Recovery

• Re-image the host rather than attempting in-place cleaning if confidence in eradication is low. If the injection led to elevated privileges, if the attacker had persistent access for more than a few hours, or if the process tree indicates sophisticated tooling, re-imaging from a known-good golden image is safer and faster than attempting to clean. Restore from the most recent clean backup and validate the backup integrity before deployment.
• Before reconnecting to the network, verify the host is clean using an offline scan. Boot from a trusted external OS (e.g., WinPE with a freshly updated AV scanner, or a Linux live USB with ClamAV) and scan the system volume. Confirm no persistence mechanisms remain by reviewing all auto-start locations (Run keys, scheduled tasks, services, startup folder) against your baseline.
• Re-enable the user account only after confirming no persistence remains and credentials are reset. Brief the user on what occurred, enforce MFA re-enrollment, and require a password change at next login. Do not re-enable the account on a host that has not been fully remediated or re-imaged.
• Monitor the previously affected host and user account for 72 hours post-remediation. Set up a temporary watch rule in your SIEM specifically targeting the host name and user account for any recurrence of injection-related events, new network connections to external IPs, or re-creation of deleted persistence mechanisms. Assign a senior analyst to review alerts from these entities daily for the monitoring window.
• Document the full attack timeline and conduct a lessons-learned review. Write an incident report capturing the initial vector, injection target, persistence methods, lateral movement scope, and dwell time. Use any new IOCs discovered during the investigation to update your detection rules, threat intelligence blocklists, and hunting queries. Submit novel indicators to your threat intelligence sharing community (e.g., ISAC, MISP) where appropriate.