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):
loadLibraryA("C:\windows\win.dll")
= converted "C:\windows\win.dll
" to bytes e.g. 0x3000000VritualAllocEx('0x3000000,'1000')
PID of process ID to inject = 1000CreateRemoteThread(LoadLibraryA(0x3000000))
Reflective injection - not visible in ProcHacker:
Execute Malware
VirtualAllocEx('5mb','pid') 5mb = sive of evil.bin
inject Evil.bin
PAGE_EXECUTE_READWRITE
Vol.py:
look for:
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)
Last updated