Identifying Code injection

Common uses:

VirtualAllocEx('bytes','pid') and CreateRemoteThread() SetWindowsHookEx() Reflective injection loads code without registering with host process PowerShell-Based reflective injection is very common

Want to use win32Api to load a dynamic link library (DLL):

1. loadLibraryA("C:\windows\win.dll") = converted "C:\windows\win.dll" to bytes e.g. 0x3000000

2. VritualAllocEx('0x3000000,'1000') PID of process ID to inject = 1000

3. CreateRemoteThread(LoadLibraryA(0x3000000))

Reflective injection - not visible in ProcHacker:

1. Execute Malware

2. VirtualAllocEx('5mb','pid') 5mb = sive of evil.bin

3. inject Evil.bin

PAGE_EXECUTE_READWRITE

Vol.py:

# look for indicators of PAGE_EXECUTE_READWRITE:
vol.py -f device.img wndows.malfind.Malfind --dump -o output-malfiles/
# Look for the loaded DLLs 
vol.py -f device.img wndows.ldrmodule.LdrModule

look for:

# PE
MZ / 0x4d5a
# UVWATAUAVAWH = 55 56 57 41 54 41 55 41 56 41 57 48
push    rbp
push    rsi
push    rdi
push    r12
push    r13
push    r14
push    r15

# 32 / x86 - assembly code 
push    ebp
mov     ebp, esp
sub     esp, 0x1a8

# 64 - x64 - push of register
push    rbp
push    rbx
push    rsi
push    rdi
push    r12
push    r13
push    r14
push    r15

Ways to obfuscate:

New forms of injection are designed to defeat detection:

• Header modification, clearing and mirroring

• permissions modifications

Process hollowing:

each process is represented by an EPROCESS block. This block has a link to a Process Environment Block (PEB), which among other things, contains three doubly linked lists for tracking a process’s loaded DLLs. In most cases, these lists contain the same data, just ordered in different ways. The three lists are Process Hollowing:

• InLoadOrderModule List

• InInitializationOrderModule List

• InMemoryOrderModule List

Unlinking a DLL from one or more of these lists is a simple means for malware to hide injected DLLs. There is no disruption to the process execution, but any tools used to view the loaded DLLs (like the Volatility plugin DLL list or the system Task Manager and command line tools) will not show the unlinked DLL. Because the PEB is a userland data structure, unlinking only requires Administrator credentials, not System or kernel access.

Two suspicious regions identified within lsass.exe

• Memory section 0x80000 is not present in any of the three PEB lists and not mapped to disk (sign of code injection)

• Memory section 0x1000000 should be the executable, but is not mapped to disk (sign of process hollowing)