# Can a Windows process check if it has been injected by another process?

There are many tutorials which show how to detect injected code into process memory. However, this generally requires using a debugger.

Is it possible for a process to somehow detect if it has been injected by another process using winapi? If so, how?

More specifically, are there any "fixed/likely" characteristics of injected code? For instance, from this question it appears that injected code can be characterized by always appearing in pages that have the following protection flags set: PAGE_READWRITE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_WRITECOPY and possibly (but unlikely) PAGE_EXECUTE. Can you point out other characteristics of injected code?

• What if the injected code resets the page protection to something less suspicious? – 0xC0000022L Jan 19 '14 at 19:20
• @0xC0000022L could you please give me an example of something less suspicious? – Benny Jan 19 '14 at 19:30

Injected code could represented by, but not limited to:

Remotely created thread could be detected by several techniques:

1. Periodically check if process threads were created by current process using NtQueryProcessInformation.
2. For each thread check if it is running from the address space of the original executable and not from some orphaned memory page:

1. NtQueryInformationThread
2. Set second parameter to ThreadQuerySetWin32StartAddress
3. GetModuleInformation - check if the thread starting address is in the range of each of the loaded modules and those modules are legit (by known list/by path).
4. Check here too.
3. Monitor thread creating API inside current process and also check if the creating PID belong to current process - NtQueryProcessInformation, CreateToolhelp32Snapshot.

4. Monitor memory protection APIs (VirtualProtect) to detect if someone tries to modify your code and then check if that "someone" belongs to legit process address space.
5. By keeping the list of legit loaded modules, one also can check if each thread in process belong to address space of a legit module from the list.
6. Monitor LoadLibrary for a chance someone trying to load unknown module into your process.

1. Check the integrity of your process - look for hot patching of various APIs, depends on the process. Injected code could be triggered by some patch inside current process.

2. Monitor APC creating API (KiUserApcDispatcher) if the target code belongs to current process. OS's APC also could be filtered out.

There are other ways to inject code, even before the legit process will start to run and place its protections - using combination of WriteProcessMemory/GetThreadContext/SetThreadContext which theoretically could bypass all your implemented protections. When your code and injected one are only running in the same ring (user mode), it all goes down to who is gaining control first. Look for code cave method and think for example when malcode is injected into explorer.exe and you are starting your program :-).

Of cause, you can load your driver into kernel, which will give you more solid control over the code injection to your process and a good protection, but that of cause depends on the skills and what you are trying to protect.

• Thanks for your answer. I'm far from being an expert in winapi, therefore, I would really appreciate if you could please add some API keywords, which I can search for, in each of the items of your enumerations from above. For instance, in the second item you mentioned checking for orphaned memory pages. How is that done using winapi? – Benny Jan 19 '14 at 20:29
• in the enumeration above, you say "Monitor ... API ..." for several winapi functions. Do you mean monitoring by hooking those APIs for all running processes, or some other way? – Benny Feb 4 '14 at 14:58
• You can monitor those APIs inside your own process, no need to span on all system. – PhoeniX Feb 5 '14 at 9:09

One way that a process can detect the presence of injected threads is by the use of Thread Local Storage. When a thread is injected, the host's Thread Local Storage callbacks will be called unless the injector takes care to disable that. If the callbacks are called, then the host can query the start address of the new thread and determine if it is within the host's defined code region (which only the host would know) See the Thread Local Storage section in my "Ultimate" Anti-Debugging Tricks paper (http://pferrie.host22.com/papers/antidebug.pdf) for an example of that.

While this does not detect everything (some malware use cavities within the host's existing code section in order to perform the injection), it will certainly catch some things.

However, the short answer to your question is actually "no". There isn't a way for a process to "know" in all cases that something has been injected. It is "yes" for most cases, but not all of them.

• +1 for referring to the awesome Ultiate Anti-Debugging Tricks Paper :) – Stolas Jan 20 '14 at 7:54
• Thanks for the adding this additional was of checking for code injection – Benny Jan 20 '14 at 10:20