124 lines
4.4 KiB
Markdown
124 lines
4.4 KiB
Markdown
# Processes
|
||
|
||
- Malware will often exploit other processes on the system
|
||
- Either already running, or by running them
|
||
- It does this to hide its activity
|
||
|
||
### Process Injection
|
||
|
||
- With process injection, malware injects its own code into a running process
|
||
- Malware execution then is not (easily) visible from outside
|
||
- Malware also gains privileges of the process it is injected into
|
||
- Common example is `DLL` injection
|
||
|
||
#### DLL Injection
|
||
|
||
- Code for the malware is contained within a `.dll` file
|
||
- Malware arranges for this `.dll` file to be loaded into the target process
|
||
- Causes malware code to be executed
|
||
|
||
##### Steps for DLL Injection
|
||
|
||
- Call `OpenProcess()` to get a `HANDLE` for the process
|
||
- Use `VirtualAllocEx()` to allocate memory inside the process
|
||
- Use `WriteProcessMemory()` to copy path to `DLL` into the process
|
||
- Use `CreateRemoteThread()` to create a new thread in the process
|
||
- Start `LoadLibrary()` as the thread routine
|
||
- Pass the address of the `DLL` path as data to the thread
|
||
|
||
#### Direct Injection
|
||
|
||
- Related technique
|
||
- Inject code directly rather than path to `DLL`
|
||
- Use `VirtualAllocEx()` to allocate memory
|
||
- Need to ensure it’s marked as executable
|
||
- `WriteProcessMemory()` used to copy over code
|
||
- `CreateRemoteThread()` used to start code
|
||
- Harder to write code for direct injection
|
||
- Code isn’t loaded, so will need to find address of API functions itself
|
||
|
||
#### Non-traditional Loading
|
||
|
||
- Malware code isn’t always loaded in traditional fashion
|
||
- Could be delivered by making use of an exploit, or process injection
|
||
- Would be delivered as a small chunk of raw machine code
|
||
- Not loaded in the traditional sense
|
||
- No relocation, no dynamic linking
|
||
- Just a raw blob of code that starts executing
|
||
- Even the address is essentially random
|
||
- This is known as **shell-code**
|
||
- Code knows where the stack is (using `ESP`)
|
||
- Can use this to create structures or store strings, by pushing the relevant values and capturing the address
|
||
- This code has a problem
|
||
- To do anything, the program is going to need to make Windows API calls
|
||
- Windows API calls are normally made by making indirect calls to the relevant implementation in the `DLL`
|
||
- Normally Windows links the calls to the `DLL`s at load time but the malware code wasn’t ‘loaded’
|
||
- The malware code does not know where the `DLL`s have been loaded into memory
|
||
|
||
##### Finding API Routines
|
||
|
||
- Possible to load and call `DLL` programmatically using `LoadLibrary`/`GetProcAddress`
|
||
- But even this requires us to know where those API functions are loaded
|
||
- Need to be able to find the address of (at least) these functions manually
|
||
- Possible to walk the data structures that Windows uses internally to find where the `DLL`s have been loaded into memory
|
||
- Once we find `KERNAL32.DLL`, we can walk the PE file structure, and find the address of `LoadLibrary` and `GetProcAddress`
|
||
- Can then use `LoadLibrary` and `GetProcAddress` to obtain access to other API functions
|
||
|
||
#### Thread Information Block
|
||
|
||
- Every thread on a Windows program has an associated TIB
|
||
|
||
- This is pointed to by the `FS` segment register
|
||
|
||
- This contains details about the current thread
|
||
|
||
- Including a pointer to the **Process Environment Block** (at an offset of `0x30`)
|
||
|
||
- `mov eax, fs:[0x30]`
|
||
|
||
- Example:
|
||
|
||
```c
|
||
PEB *GetPEB()
|
||
{
|
||
_asm mov eax, fs:[0x30]
|
||
}
|
||
```
|
||
|
||
#### Modules List
|
||
|
||
- `PEB_LDR_DATA` structure points to a linked list containing each module
|
||
|
||
- List entry contains the module’s filename
|
||
- And the base address of where it’s been loaded
|
||
- Points to the start of the DOS file header
|
||
- Can search this linked list until we find the `DLL` of interest
|
||
|
||
- Example:
|
||
|
||
```c
|
||
typedef struct _LDR_DATA_TABLE_ENTRY {
|
||
PVOID Reserved1[2];
|
||
LIST_ENTRY InMemoryOrderLinks;
|
||
PVOID Reserved2[2];
|
||
PVOID DllBase;
|
||
PVOID EntryPoint;
|
||
PVOID Reserved3;
|
||
UNICODE_STRING FullDllName;
|
||
BYTE Reserved4[8];
|
||
PVOID Reserved5[3];
|
||
union {
|
||
ULONG CheckSum;
|
||
PVOID Reserved6;
|
||
};
|
||
ULONG TimeDateStamp;
|
||
} LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY;
|
||
```
|
||
|
||
##### Process Hollowing
|
||
|
||
- Here a normal program is loaded using `CreateProcess`
|
||
- But it is created in a suspended state using the `CREATE_SUSPEND` flag
|
||
- Original code is removed, and malware code is copied in
|
||
- Look out for calls to `ZuUnmapViewOfSection`, `SetThreadContext` and `ResumeThread`
|