Process Injections

Windows

Most information is taken from here, but more visualisation is added. The screenshots from IDA Pro are also copied from that blog post.

Classic

This one is one of the simplest to explain and not that simple to actually use in a real attack (see Caveats). A malicious DLL’s path is copied in the memory space of a legitimate running process to be loaded in runtime.

Below is the anatomy of this function call.

Here is a scheme of the sick process address space layout in RAM when this shit happens:

And this is approximately what you’d see in IDA Pro, if you had an appropriate sample utilising this technique:

Caveats

There are two main problems:

• Most of the defense tools start barking when they hear the CreateRemoteThread() call.
• The attacker needs to have this mal.dll on disk prior to attack.

PE Injection

A malicious dll itself copied in the memory space of a running legitimate process.

This is the chain of function calls needed for this attack.

Below is the anatomy of the CreateRemoteThread function call needed for this attack to work

Below is the memory layout of the sick process.

And this is what you’d see in IDA Pro if you had a sample using this technique.

Caveats

СreateRemoteThread() and LoadLibrary() are not stealthy

Process Hollowing

Already loaded good process is fully overwritten with something not that good.

This is the chain of function calls needed for this attack.

Below is the memory layout of the sick process.

And this is what you’d see in IDA Pro if you had a sample using this technique.

Pros And Cons

➕ No need to have mal.dll on disk

➖ CreateRemoteThread()andLoadLibrary()` are loud

SIR (Suspend, Inject, Resume)

EIP register’s value of a running thread is substituted. This is the chain of function calls needed for this attack.

Below is the memory layout of the sick process.

And this is what you’d see in IDA Pro if you had a sample using this technique.

Pros And Cons

➕ Not as noisy since there is no process created. All the perversion is done with the already running one.

➖ If the process is suspended due to a system call, the program will crash. For this case Trojans that are a little smarter can check EIP value and postpone the inject if its value is in the ntdll.dll’s address range.

Hook 🪝

Uses SetWindowsHookEx() API function.

Call interception.

This is the chain of function calls needed for this attack.

Below is the memory layout of the sick process.

Below is the anatomy of the SetWindowHookEx() function call needed for this attack to work.

And this is what you’d see in IDA Pro if you had a sample using this technique.

Registry poisoning

Using the registry to inject.

These are the keys that can be used for injection.

• Upon User32.dll load mal.dll will be loaded:

  • HKLM/Software/Microsoft/WindowsNT/CurrentVersion/Windows/Appinit_Dlls
  • HKLM/Software/Wow6432Node/Microsoft/WindowsNT/CurrentVersion/Windows/Appinit_Dlls

• Whenever CreateProcess(), CreateProcessAsUser(), CreateProcessWithLogonW(),

  CreateProcessWithTokenW(), WinExec() are called, mal.dll will be called

  • HKLM/System/CurrentControlSet/Control/Session Manager/AppCertDlls

• IFEO - usually used to attach a debugger. The value of the “Debugger Value” is changed.

• HKLM/Software/Wow6432Node/Microsoft/WindowsNT/CurrentVersion/image file execution options

Below is the memory layout of the sick process.

Below is the anatomy of the XXXXXXXXXXXXXXXX function call needed for this attack to work

And this is what you’d see in IDA Pro if you had a sample using this technique.

Pros And Cons

➕ The very process of injection is stealthy.

➖ However,mal.dll needs to be present on disk.

➖ There are “smithereens” left in the registry that can be a good lead in an investigation.

APC

This is the chain of function calls needed for this attack.

Below is the memory layout of the sick process.

Below is the anatomy of the XXXXXXXXXXXXXXXX function call needed for this attack to work.

How this attack actually work (visualised):

And this is what you’d see in IDA Pro if you had a sample using this technique.

EWMI with SetWindowLong()

Extra Window Memory Injection. Ok, hold my beer 🍻, this one is a little tough for 11:14 in the evening. explorer.exe process has some shared memory, that can be used by other processes. Neat, right? What other process have this “feature”? Let’s keep this information roasting for a while. There are two ways of using this bug feature: decently creating a shared region (using NTMapViewOfSection for allocating heap section) or leeching off on another one’s. Guess which one is the prefered one for the attackers 😉?

There is another feature, not explorer.exe specific: GUI applications when creating a window have some additional 40 bytes for each window in the window class structure, where they can put anything 40 bytes long (properties, function pointers). Originally, these bytes were designed to store some window specific info, i.e. colors, menu items I guess. However, one can write a pointer in this space to point to somewhere else: either in this very process (which is quite useless for an attacker) or in some shared region (let’s stop the information in the above paragraph roasting).

And finally, there is this Shell_TrayWnd. Remember, the panel on the bottom on Windows? How do these pretty cute icons get into the tray? That’s the class responsible for this magic 🪄. As any other window, it also has its own additional 40 bytes for each instance and these bytes can be retrieved and set with GetWindowLong and SetWindowLong.

Now, let’s assemble it all together. How does this work from a malicious point of view. To actually make this pointer work, one would have to call SetWindowLong (to set the value pointing to some shared memory with shellcode 🐚 in it) and SendNotifyMessage (to trigger it).

This is the chain of function calls needed for this attack.

Below is the memory layout of the sick process.

Below is the anatomy of the XXXXXXXXXXXXXXXX function call needed for this attack to work

And this is what you’d see in IDA Pro if you had a sample using this technique.

Examples

Gapz and PowerLoader

SHIMS

Favourite and the most useful for malware: DisableNX, DisableSEH, InjectDLL.

This is the chain of function calls needed for this attack.

Below is the memory layout of the sick process.

Below is the anatomy of the XXXXXXXXXXXX function call needed for this attack to work

And this is what you’d see in IDA Pro if you had a sample using this technique.

Examples

Adware, “Search Protect by Conduit”.

🛠 Tools

python-sdb

Userland rootkit

Rootkits are usually associated with the kernel space, however, there are also userland rootkits out there. There are two main techniques known: IAT and inline.

When IAT hooking technique is used, malware changes the import address table. This way when a good application calls some function from this tampered DLL, the replaced function is executed instead.

With inline hooking malware modifies the function’s body itself.

This is the chain of function calls needed for this attack.

Below is the memory layout of the sick process.

Below is the anatomy of the XXXX function call needed for this attack to work

And this is what you’d see in IDA Pro if you had a sample using this technique.

Examples

Tools 🧰

Malfind Volatility

https://www.linkedin.com/pulse/process-injection-detection-malfind-britton-manahan/

Injected Code Hunter Tool

Same mechanics as with malfind but on a live system. https://github.com/intelliroot-tech/InjectedCodeHunter https://www.intelliroot.com/resource_library/tools/injectedcodehunter

Hollows Hunter

❗️ Windows PE only https://github.com/hasherezade/hollows_hunter

References

Ten Process Injection Techniques: A Technical Survey Of Common And Trending Process Injection Techniques: https://www.endgame.com/blog/technical-blog/ten-process-injection-techniques-technical-survey-common-and-trending-process

TOREAD

https://i.blackhat.com/USA-19/Thursday/us-19-Kotler-Process-Injection-Techniques-Gotta-Catch-Them-All.pdf