0xreizouko's den

DLL Injection#

DLL injection is a form of process injection where a remote process is forced to load a malicious DLL. It works by injection code into a remote process that calls LoadLibrary, hence, forcing the process to load that malicious DLL which calls the DllMain of that malicious DLL with as much access as the compromised process.

The process injection starts by getting a handler to the victim process, The most common way is to use CreateToolhelp32Snapshot, Process32First, and Process32Next to enumerate the process list.

Once the target is found, the launcher retrieves the PID of the target and then uses it to obtain a handle via OpenProcess.

The function CreateRemoteThread used for DLL injection to create and execute a new thread in the remote(target) process. When CreateRemoteThread is used, three parameters are passedhProcess -> process handle obtained with OpenProcess, lpStartAddress -> starting point of the injected thread, lpParameter -> a pointer to a variable to be passed to the thread function.

The starting point might be set to LoadLibrary and the malicious DLL name passed as the argument; this will trigger LoadLibrary to be run in the victim process with a parameter of the malicious DLL causing the DLL to be loaded in the victim process(assuming that LoadLibrary is available in the victim process’s memory space and the malicious library name string exists within that same space).

Authors generally use VirtualAllocEx to create space for the malicious library name string, it allocates space in a remote process if a handle to that process is provided.

The last function required before CreateRemoteThread can be called is WriteProcessMemory. It writes the malicious library name string into the memory space that was allocated using VirtualAllocEx.

Direct Injection#

Direct injection involves allocating and inserting code into the memory space of a remote process. It involves same Windows API calls as DLL injection, but instead it injects the payload into the remote process memory. It’s more flexible than DLL injection but requires a lot of customised code. It can be used to inject compiled code, but more often it’s used to inject shellcode.

It usually employs three functions: VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread. It starts by two calls to VirtualAllocEx and WriteProcessMemory, the first will allocate and write the data used by the remote thread, then the 2nd call will allocated and write the allocate and write the remote thread code. The call to CreateRemoteThread will contain the location of the remote thread code lpStartAddress and the data lpParameter. Direct injection requires the author to be skilled in Assembly or inject a simple shellcode.

In order to analyse remote thread’s code, you may need to dump all memory buffers that occur before calls to WriteProcessMemory, since they usually come in the form of shellcode; this will be further discussed in chapter 19.

Keyloggers Using Hooks#

Hook injection is frequently used in keyloggers by utilising the WH_KEYBOARD or WH_KEYBOARD_LL hook procedure types.

WH_KEYBOARD often will be running in the context of a remote process, but it can also run in the that installed the hook. As for WH_KEYBOARD_LL procedures, the events are sent directly to the process that installed the hook, so it will be running in the context of the process that created it. Using any of these hooks a keylogger can intercept key-strokes and log them to a file.

Using SetWindowsHookEx#

The main function used for Windows hooking is SetWindowsHookEx, it has the following parameters:

• idHook -> Type of hook to install
• lpfn -> Pointer to hook procedure.
• hMod -> Handle to the Dll containing hook procedure defined by lpfn.
• dwThreadId -> Specifies the id of the thread associated with hook procedure if it’s zero, the hook is associated with all existing threads running in the same desktop as the calling thread(0 is mandatory for low-level hooks).

hook procedure is the code that process messages, it must call CallNextHookEx.

Thread Targeting(dwThreadId)#

Malware generally includes instructions for for determining which system thread id to use or target all threads. Loading into all threads is a common behaviour of keyloggers or other software with the goal of message interception. However, loading into all threads can degrade the system and trigger IPS. Loading a single DLL in a remote process is better done by injecting a simple thread to remain stealthy.

Targeting a single thread requires enumerating the processes or run a program if the target is not run. If the hook was done to a common message it may trigger an IPS; so malware will hook with uncommon messages such as WH_CBT.

1
00401100        push    esi
2
00401101        push    edi
3
00401102        push    offset LibFileName ; "hook.dll"
4
00401107        call    LoadLibraryA
5
0040110D        mov     esi, eax
6
0040110F        push    offset ProcName ; "MalwareProc"
7
00401114        push    esi             ; hModule
8
00401115        call    GetProcAddress
9
0040111B        mov     edi, eax
10
0040111D        call    GetNotepadThreadId
11
00401122        push    eax             ; dwThreadId
12
00401123        push    esi             ; hmod
13
00401124        push    edi             ; lpfn
14
00401125        push    WH_CBT   ; idHook
15
00401127        call    SetWindowsHookExA

In this listing a malicious dll is loaded using LoadLibraryA and the malicious procedure is obtained using GetProcAddress, GetNotepadThreadId is a locally defined function that gets dwThreadId for notepad.exe. Finally, a WH_CBT message is sent to the injected notepad.exe. once hook.dll is injected it can execute code while disguised as notedpad.exe. Since MalwareProc calls only CallNextHookEx it shouldn’t interfere with incoming messages, but malware often call LoadingLibrary and UnhookWindowsHookEx in DllMain to ensure that incoming messages are not impacted.

APC injection from User Space#

The thread queues a function to be invoked in another thread using QueueUserAPC. Because a thread must be alertable, malware will look to target threads in processes that are like to be alertable, WaitForSingleObjectEx is the most common call for this technique.

QueueUserAPC call is a request for the thread whose handle is hThread, to run the function defined in pfnAPC with the parameter dwData.

TIP

API calls CreateToolHelp32Snapshot, Process32First, Process32Next may be found during analysis to look for target process, they will often be followed by Thread32First and Thread32Next, which will be also in a loop looking to target a thread contained in target process. Malware Can also use Nt/ZwQuerySystemInformation with SYSTEM_PROCESS_INFORMATION class to find the target process.

1
00401DA9         push    [esp+4+dwThreadId]      ; dwThreadId
2
00401DAD         push    0                       ; bInheritHandle
3
00401DAF         push    10h                     ; dwDesiredAccess
4
00401DB1         call    ds:OpenThread
5
00401DB7         mov     esi, eax
6
00401DB9         test    esi, esi
7
00401DBB         jz      short loc_401DCE
8
00401DBD         push    [esp+4+dwData]          ; dwData = dbnet.dll
9
00401DC1         push    esi                     ; hThread
10
00401DC2         push    ds:LoadLibraryA      ; pfnAPC
11
00401DC8         call    ds:QueueUserAPC

Once a thread is found, the malware uses it to open a handle to the tread OpenThread(4), the malware then is looking to force the thread to load dbnet.dll library(10) as LoadLibraryA is passed to pfnAPC and dbnet.dll is passed as dwData. so it runs LoadLibrary(dbnet.dll).

APC injection from Kernel Space#

There’s no easy way for drivers to execute code in user space. One method is to perform APC injection from kernel space.

A malicious driver can build an APC and dispatch a thread to execute it in a user-mode process (mostly svchost.exe). These APCs mostly contain shellcode.

The driver uses two functions KeInitialiseApc and KeInsertQueueApc to initialise a call to KeInitializeApc, if the sixth parameter (NormalRoutine)(2) non-zero in combination with the seventh-parameter (AcpMode)(1) being set to 1 then we are looking for a user-mode type.

KeInitializeApc initis a KAPC structure which must be passed KeInsertQueueApc to place APC in the queue.

1
000119BD         push    ebx
2
000119BE         push    1
3
000119C0         push    [ebp+arg_4]
4
000119C3         push    ebx
5
000119C4         push    offset sub_11964
6
000119C9         push    2
7
000119CB         push    [ebp+arg_0]
8
000119CE         push    esi
9
000119CF         call    ds:KeInitializeApc
10
000119D5         cmp     edi, ebx
11
000119D7         jz      short loc_119EA
12
000119D9         push    ebx
13
000119DA         push    [ebp+arg_C]
14
000119DD         push    [ebp+arg_8]
15
000119E0         push    esi
16
000119E1         call    edi       ;KeInsertQueueApc