Comment on page
Common API used in Malware
- GetAsyncKeyState() -- Key logging
- SetWindowsHookEx -- Key logging
- GetForeGroundWindow -- Get running window name (or the website from a browser)
- LoadLibrary() -- Import library
- GetProcAddress() -- Import library
- CreateToolhelp32Snapshot() -- List running processes
- GetDC() -- Screenshot
- BitBlt() -- Screenshot
- InternetOpen(), InternetOpenUrl(), InternetReadFile(), InternetWriteFile() -- Access the Internet
- FindResource(), LoadResource(), LockResource() -- Access resources of the executable
Execute an arbitrary DLL inside another process
- 1.Locate the process to inject the malicious DLL: CreateToolhelp32Snapshot, Process32First, Process32Next
- 2.Open the process: GetModuleHandle, GetProcAddress, OpenProcess
- 3.Write the path to the DLL inside the process: VirtualAllocEx, WriteProcessMemory
- 4.Create a thread in the process that will load the malicious DLL: CreateRemoteThread, LoadLibrary
Other functions to use: NTCreateThreadEx, RtlCreateUserThread
Load a malicious DLL without calling normal Windows API calls. The DLL is mapped inside a process, it will resolve the import addresses, fix the relocations and call the DllMain function.
Find a thread from a process and make it load a malicious DLL
- 1.Find a target thread: CreateToolhelp32Snapshot, Thread32First, Thread32Next
- 2.Open the thread: OpenThread
- 3.Suspend the thread: SuspendThread
- 4.Write the path to the malicious DLL inside the victim process: VirtualAllocEx, WriteProcessMemory
- 5.Resume the thread loading the library: ResumeThread
Portable Execution Injection: The executable will be written in the memory of the victim process and it will be executed from there.
The malware will unmap the legitimate code from memory of the process and load a malicious binary
- 1.Create a new process: CreateProcess
- 2.Unmap the memory: ZwUnmapViewOfSection, NtUnmapViewOfSection
- 3.Write the malicious binary in the process memory: VirtualAllocEc, WriteProcessMemory
- 4.Set the entrypoint and execute: SetThreadContext, ResumeThread
- The SSDT (System Service Descriptor Table) points to kernel functions (ntoskrnl.exe) or GUI driver (win32k.sys) so user processes can call these functions.
- A rootkit may modify these pointer to addresses that he controls
- IRP (I/O Request Packets) transmit pieces of data from one component to another. Almost everything in the kernel uses IRPs and each device object has its own function table that can be hooked: DKOM (Direct Kernel Object Manipulation)
- The IAT (Import Address Table) is useful to resolve dependencies. It's possible to hook this table in order to hijack the code that will be called.
- EAT (Export Address Table) Hooks. This hooks can be done from userland. The goal is to hook exported functions by DLLs.
- Inline Hooks: This type are difficult to achieve. This involve modifying the code of the functions itself. Maybe by putting a jump at the begging of this.