Process Injection Attack: Avoid the Alert!

Why do modern EDRs sometimes fail to flag malicious payloads, forcing SOC analysts to hunt for anomalies deep within memory? The answer lies in the technical nuances of Process Injection (MITRE ATT&CK T1055) and how malware evades user-mode hooks.

What is it & Why does it matter?

Instead of spawning a new, suspicious executable—which easily triggers security alerts—the attacker injects their malicious code or shellcode directly into the memory address space of a legitimate, trusted running process (such as explorer.exe or svchost.exe).

By doing this, the malware masks its malicious behavior under the guise of a trusted operating system process. This serves as a primary mechanism for Defense Evasion and, in many cases, Privilege Escalation.

The Traditional Workflow vs. Evasion Mechanics

In a classic injection scenario, an operator executes a predictable sequence of Win32 APIs: OpenProcess \(\rightarrow\) VirtualAllocEx \(\rightarrow\) WriteProcessMemory \(\rightarrow\) CreateRemoteThread.

However, modern Detection Engineering easily catches this because security tools monitor these specific API calls. To bypass this, sophisticated malware shifts tactics:

• Avoiding RWX Memory: Allocating memory with PAGE_EXECUTE_READWRITE (0x40) is an immediate red flag for EDR memory scanners. Advanced threat actors allocate space using PAGE_READWRITE (0x04), write the shellcode, and then use VirtualProtectEx to flip the permissions to PAGE_EXECUTE_READ (0x20) right before execution.

• Direct Syscalls: Legacy AV/EDR solutions monitor user-mode APIs by hooking functions inside kernel32.dll or ntdll.dll. To blindfold these hooks, malware circumvents high-level APIs entirely. It loads the appropriate system call number into the EAX register and executes the syscall assembly instruction directly, invoking underlying native APIs like NtAllocateVirtualMemory and NtWriteVirtualMemory.

Anatomy of an Advanced Sub-Technique: Process Hollowing (T1055.012)

Instead of just creating a thread in a running process, a threat actor can spawn a legitimate system binary (like svchost.exe) in a CREATE_SUSPENDED state.

1. The malware queries the target's Process Environment Block (PEB) to locate the image base address.

2. It unmaps (hollows out) the legitimate executable memory using NtUnmapViewOfSection.

3. It allocates new memory space, copies its own malicious PE payload into the hollowed structure, and updates the thread context (SetThreadContext) to point to the new EntryPoint.

4. Finally, it calls ResumeThread. To the OS and basic monitoring tools, the process looks entirely legitimate.

Advanced SOC Hunting & Detection Strategies

When user-mode hooks are bypassed via direct syscalls, a SOC cannot rely solely on process creation event logs. Defense must move to the kernel level:

• Unbacked Threads: Hunt for threads whose instruction pointers point to MEM_PRIVATE memory regions rather than a legitimate, disk-backed DLL (e.g., checking for threads executing out of memory areas not associated with a mapped image).

• Kernel Callbacks & ETW: Rely on telemetry generated by Event Tracing for Windows (ETW) (specifically the Microsoft-Windows-Threat-Intelligence provider) or kernel-level callbacks like PsSetCreateThreadNotifyRoutine. When NtCreateThreadEx is called cross-process, the kernel still sees it, regardless of user-mode syscall unhooking tricks.

• Sysmon Event ID 8 (CreateRemoteThread): Monitor instances where the SourceImage is a non-system binary (e.g., a binary running from \AppData\Local\) but the TargetImage is a critical system process like lsass.exe or spoolsv.exe.