Checking for Injected Code

How to Check

Injected code runs inside a genuine process, so its name, path and signature all look right. What gives it away is memory, whether executable memory that no file on disk backs, a thread that starts there, or an image in memory that differs from its file. On a clean machine code runs from images mapped from files, though .NET and other just-in-time compilers and security products make executable memory of their own. So a hit is a lead to dump and examine, never a verdict on its own. Start with the threads, where each one starts, and which file is mapped there.

What It Shows

Code normally runs from images mapped from files, so executable memory that no file backs, a thread that starts in it, or an image in memory that differs from its file all point to code that did not arrive the normal way. These checks read memory, live or in an image, and the thread records Sysmon and Defender keep. They also flag .NET and other just-in-time code and security products, so dump what they find and check it before calling it injection.

Inside Parts It Reads

This check reads these parts, and each page shows what normal looks like.

Records of One Process Reaching Into Another

When one process reaches into another, these records catch it, each from a different sensor. Sysmon writes events 8 and 25 to Microsoft-Windows-Sysmon/Operational on machines running Sysmon, and Defender writes the DeviceEvents rows on devices onboarded to Defender for Endpoint.

Record	Fields to Read	What It Tells You
Sysmon event 8	`SourceImage, TargetImage, StartAddress, StartModule, StartFunction`	A thread started in another process. Sysmon infers StartModule and StartFunction and can leave them empty when the start lies outside every loaded module, a lead to examine in memory
Sysmon event 25	`Image, Type`	Sysmon saw a process image change in memory, the trace hollowing and similar tampering leave
CreateRemoteThreadApiCall, QueueUserApcRemoteApiCall and NtAllocateVirtualMemoryRemoteApiCall in DeviceEvents	`InitiatingProcessFileName, FileName, ProcessId, InitiatingProcessId`	Defender's records of one process starting a thread in, queuing work to, or allocating memory in another. Microsoft names these action types in the portal's schema reference and in the data catalogue it published with its NL2KQL research, so confirm the one you need on your own tenant

Live and in Memory

Each question has the tools that answer it on a running machine, and in a memory image, a copy of its memory saved to a file.

Is there executable memory that no file backs?
On a Running Machine
- Windows.System.VAD (documentation, opens in a new tab) The memory regions of matching processes, filtered to executable ones with no mapped file, and it can upload them.
- PE-sieve (documentation, opens in a new tab) Scans one process for injected or replaced code, hooks and changes made in memory, and dumps what it finds.
- HollowsHunter (documentation, opens in a new tab) Runs the same scan over every running process.
- Defender for Endpoint live response (documentation, opens in a new tab) processes Lists the process. No built-in command reads its memory regions or threads, so live it reaches them only through a read-only library script you write and start with the run command.
In a Memory Image
- windows.malware.malfind (documentation, opens in a new tab) Private regions, and mapped ones not created as Execute, write copy, that were created executable and writable, or executable with a written page. It shows the first 64 bytes of each.
- windows.vadinfo (documentation, opens in a new tab) Every region with its protection and mapped file, to read a flagged region in its process's context.
- windows.malware.ldrmodules (documentation, opens in a new tab) Every region that starts with an MZ header, private memory included, with whether each loader list holds it and the file behind it. A region in no list and with no file is a lead, while the process's own executable and resource files have ordinary gaps.
Does a thread start in memory no file backs?
On a Running Machine
- Get-InjectedThreadEx (documentation, opens in a new tab) Scans every running thread on one machine for a suspicious start address, such as one in memory no file backs.
- CreateRemoteThreadApiCall (documentation, opens in a new tab) Defender's record of one process starting a thread in another, with both processes named.
In a Memory Image
- windows.malware.suspicious_threads (documentation, opens in a new tab) Flags threads that start in memory no file backs, in a region not created as Execute, write copy as mapped images are, or in a second executable. It checks both start addresses and sees only threads still running.
- windows.threads (documentation, opens in a new tab) Each thread's two start addresses, the kernel's StartAddress and the Win32 start address, with the file mapped at each, so compare the Win32 one, which Sysmon event 8, Process Explorer and Windows.System.Threads show.
Is an image in memory different from its file on disk, or have the Windows functions it calls been changed in memory?
On a Running Machine
- Windows.Memory.Mem2Disk (documentation, opens in a new tab) Compares executables in memory with their files on disk, live and without dumping.
- PE-sieve (documentation, opens in a new tab) Reports the changes made in memory to the modules of the process it scans.
In a Memory Image
- windows.malware.hollowprocesses (documentation, opens in a new tab) Checks each process's executable and DLLs for a replaced image. It skips processes with fewer than three DLLs or five memory regions and does not name the technique.
- windows.malware.processghosting (documentation, opens in a new tab) Processes whose image file is marked for deletion or has no file object, or that map an executable or DLL set to be deleted on close.
- windows.malware.pebmasquerade (documentation, opens in a new tab) Sets the kernel's image name and audit path beside the PEB's, so a PEB that names another file stands out, and you read its two flags together.
- windows.malware.unhooked_system_calls (documentation, opens in a new tab) Compares the ntdll.dll system call stubs across processes to find one that has been changed in memory.
- windows.etwpatch (documentation, opens in a new tab) Looks for the event tracing functions in ntdll.dll or advapi32.dll changed in memory inside a process.
Who holds the process open with the rights to write its memory, and does it connect anywhere its job never needs?
On a Running Machine
- Handle (documentation, opens in a new tab) Its granted-access view shows who holds this process open with the rights to write its memory or start a thread in it.
- Get-NetTCPConnection (documentation, opens in a new tab) Get-NetTCPConnection Lists the connections by owning process, so a connection the process never normally makes stands out.
In a Memory Image
- windows.handles (documentation, opens in a new tab) The handles other processes hold on this one, with the granted access, so a handle that carries write or thread rights is a lead.
- windows.netscan (documentation, opens in a new tab) The connections and listeners tied to the process in the image, to match what a live tool shows.

What It Misses

Every way of looking has gaps, so cover these from another source.

windows.malware.malfind judges a region by the protection it was created with, so it can miss a region whose protection changed later, and it never judges an image region created as Execute, write copy. Pair it with windows.malware.suspicious_threads and Windows.Memory.Mem2Disk, because a clean result never clears a process.
A start address records where a thread began, not what it runs now. A thread whose context was set from another process, or that was handed queued work, keeps a normal start, and Defender's SetThreadContextRemoteApiCall and QueueUserApcRemoteApiCall record those. A thread that ended is gone from memory, kept only by Sysmon event 8 or a Defender record.
Pages saved to the page file are missing from a raw image unless the page file is added, and pages Windows compresses sit in the Memory Compression process, not the one they belong to. A region you cannot read is not proof it was empty.

False Positives

These look odd but are normal, so rule them out before you act.

.NET, Java and other just-in-time compilers write code into memory no file backs, and security products inject into processes to watch them, so compare with a clean machine of the same build before calling it injection.
Packed and copy-protected programs unpack themselves in memory and look injected.
PE-sieve, HollowsHunter and Get-InjectedThreadEx flag legitimate hooks and generated code too, so treat a hit as a region to dump and examine, not a verdict.

Proves These Red Flags

This check is a step in confirming each sign below.

How Malware Hides in a Process: Remote Thread Injection Process Hollowing

Hunt It

The same hunt is written for four tools, so pick the one you use. Defender XDR and Sentinel queries are in KQL, which you paste into Advanced hunting in the Defender portal or into Sentinel's Logs page. Splunk queries are in SPL, for its Search page, and Velociraptor queries are in VQL, which you run as a hunt.

Sees It DirectlyDeviceEvents (CreateRemoteThreadApiCall)

Needs Defender for Endpoint. Microsoft lists DeviceEvents action types in the portal's schema reference and in the data catalogue it published with its NL2KQL research, so confirm this one with DeviceEvents | distinct ActionType before you rely on it. Security products and other legitimate programs start remote threads too, so rare pairs come first, and a hit is a lead to examine in memory.

KQLDefender XDR, Advanced hunting

// One process starting a thread in another (CreateRemoteThreadApiCall), by source and target, rarest pairs firstDeviceEvents| where Timestamp > ago(30d)| where ActionType == "CreateRemoteThreadApiCall" and ProcessId != InitiatingProcessId| summarize Devices = dcount(DeviceId), Threads = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by InitiatingProcessFileName, InitiatingProcessFolderPath, FileName| order by Devices asc, Threads asc