Code Injection

process hollowing & DLL Injection

DLL Injection

Attacking process can allocate space in a running process, write the DLL file to load in the new space then create a new thread to load the DLL into the running process using the Windows VirtualAllocEx() and CreateRemoteThread() win32 API function calls.

Alternatively, can force a running process to load a malicious DLL by hooking its filter functions using the SetWindowsHookEx() win32 API function.

Typical attack:

OpenProcess() -> VirtualAllocEx() -> WriteProcessMemory() -> CreateRemoteThreat() -> LoadLibraryA() <- C:\evil.dll

Use the Volatility 3 plugins dllist and ldrmodules to look for API information

Remember: we typically see DLLs loaded from \Windows\System32, \Windows\WinSxS or \Program Files\

Legitimately loaded DLLs will be present in: VAD (MappedPath), PEB (InLoadOrderModule (InLoad), InInitializationOrderModule (InInit), InMemoryOrderModule (InMem) LSASS.exe will be missing InInitializedOrder as not intiliased in the same way as DLLs.

There are also lots of special files mapped to including: .fon,.mui,.winmd and .msstyles files. Since not loaded DLLs they are not present in PEB

Some legitimate process unmap DLLs or do not use them - these will be present in the VAD MappedPath but not in the PEB lists.

Atom Bombing

uses the global atom table to write code between the processes

Reflective Loading

Malicious process, creates their own process and inject into it - bypassing a lot of a the win32 API functions. Resulting in code that running that is not registered with any of the host process lists.

Process Hollowing

A legitimate system process is created,in a suspended state. the original executable is de-allocated (unmapped) and the start address is changed to point to a different location hosting malicious code.

When the process is started it executed the code, keeping the process image name, path and command lines unchanged

Advanced injection:

Changing permissions after initial allocation (removing execution rights), changing pointers to execute different code as seen in process hollowing, or patching previously executed code

Reflective Code injection

Inject code without using the windows loader (i.e. LoadLibrary). By excluding LoadLibrary, the code is not registered within any in-memory lists, and is hidden from security and auditing tools.

An additional benefit is by avoiding the LoadLibrary you can use memory-only code it doesn't need to be written to host.

Spotting code injection

1. Look for PAGE_EXECUTE_READWRITE

2. check is the file is mapped to disk (legitimate processes would only be on machine)

3. processes wont be marked as executable if code not on machine

4. check if actual code is present in the memory location (typically a PE:MZ/4d 5a 90 00 or shellcode: x86 PUSH EBP; MOV EBP, ESP & x64 PUSH RBP; PUSH RBX; PUSH RSI; PUSH RDI; PUSH R12; PUSH 13; PUSH R14; PUSH R15 or UVWATAUAVAWH

where to look:

1. Look for DLLs loaded using the Win32 API

2. use malfind or findevil & Look for MZ (or 4d 5a 90 00) in the HEX output malfind has a precondition to check if code is written to disk or injected

Advanced techniques:

• PEB masquerading - Update PEB to change different process name, file path or link/unlink entries in the PEB DLL - can also be used to spoof different name/ location for loaded code

• Header modifications - clearing/ mirroring

• padding shellcode to site past the first 64 bytes (hides from malfind)

• PTE (page table entries) modification - normally through use of winAPI NtProtectVirtualMemory - allows attacker to allocate memory with READWRITE permissions and copy code to the location then switch to READ_EXECUTE (VAD tree only uses the permissions when first starting the process but can be compared within the PEB)