# Code Injection

## DLL Injection

Attacking process can allocate space in a running process, write the DLL file to load in the new space then create a new thread to load the DLL into the running process using the Windows `VirtualAllocEx()` and `CreateRemoteThread()` win32 API function calls. 

Alternatively, can force a running process to load a malicious DLL by hooking its **filter** functions using the SetWindowsHookEx() win32 API function. 

Typical attack: 

```powershell
OpenProcess() -> VirtualAllocEx() -> WriteProcessMemory() -> CreateRemoteThreat() -> LoadLibraryA() <- C:\evil.dll
```

Use the [#volatility-3](https://f1rstbyt3.gitbook.io/hacking-notes/dfir/tooling/volatility#volatility-3 "mention") plugins `dllist` and `ldrmodules` to look for API information

**Remember:** *we typically see DLLs loaded from* `\Windows\System32`, `\Windows\WinSxS` or `\Program Files\`

Legitimately loaded DLLs will be present in: VAD (`MappedPath`), PEB (`InLoadOrderModule` (InLoad), `InInitializationOrderModule` (InInit), `InMemoryOrderModule` (InMem)\
`LSASS.exe` will be missing `InInitializedOrder` as not intiliased in the same way as DLLs.&#x20;

There are also lots of special files mapped to including: `.fon`,`.mui`,`.winmd` and `.msstyles` files. Since not loaded DLLs they are not present in PEB

Some legitimate process unmap DLLs or do not use them - these will be present in the VAD `MappedPath` but not in the PEB lists.

#### Atom Bombing

uses the global atom table to write code between the processes

#### Reflective Loading&#x20;

Malicious process, creates their own process and inject into it - bypassing a lot of a the win32 API functions. Resulting in code that running that is not registered with any of the host process lists.

## Process Hollowing

A legitimate system process is created,in a suspended state. the original executable is de-allocated (unmapped) and the start address is changed to point to a different location hosting malicious code.

When the process is started it executed the code, keeping the **process image name, path and command lines unchanged**

**Advanced injection:**&#x20;

Changing permissions after initial allocation (removing execution rights), changing pointers to execute different code as seen in process hollowing, or patching previously executed code

## **Reflective Code injection**

Inject code without using the windows loader (i.e. `LoadLibrary`). By excluding `LoadLibrary`, the code is not registered within any in-memory lists, and is hidden from security and auditing tools.&#x20;

An additional benefit is by avoiding the `LoadLibrary` you can use **memory-only code** it doesn't need to be written to host.

## **Spotting code injection**

1. Look for `PAGE_EXECUTE_READWRITE`
2. check is the file is mapped to disk (legitimate processes would only be on machine)
3. processes wont be marked as executable if code not on machine
4. check if actual code is present in the memory location (typically a PE:`MZ`/`4d 5a 90 00` or shellcode: x86 `PUSH EBP; MOV EBP, ESP` & x64 `PUSH RBP; PUSH RBX; PUSH RSI; PUSH RDI; PUSH R12; PUSH 13; PUSH R14; PUSH R15` or  [`UVWATAUAVAWH`](https://www.hexacorn.com/blog/2013/05/16/uvwatauavawh-meet-the-pushy-string/)

where to look:

1. Look for DLLs loaded using the Win32 API&#x20;
2. use [malfind](https://f1rstbyt3.gitbook.io/hacking-notes/dfir/tooling/volatility#volatility-3) or [findevil](https://f1rstbyt3.gitbook.io/hacking-notes/dfir/memory-analysis/tooling/memprocfs) & Look for `MZ` (or `4d 5a 90 00`) in the HEX output\
   `malfind` has a precondition to check if code is written to disk or injected

### Advanced techniques:

### &#x20;

<figure><img src="https://1422073608-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJ6mTp74lZCen0Sx5qHUb%2Fuploads%2FmK6EoMWnPB61mzR0AFXo%2Fimage.png?alt=media&#x26;token=382b944e-1b6b-4412-b10d-3a8875f15095" alt=""><figcaption></figcaption></figure>

* `PEB` masquerading - Update `PEB` to change different process name, file path or link/unlink entries in the `PEB DLL` - can also be used to spoof different name/ location for loaded code
* Header modifications - clearing/ mirroring&#x20;
* padding shellcode to site past the first 64 bytes (hides from malfind)&#x20;
* PTE (page table entries) modification - normally through use of winAPI `NtProtectVirtualMemory` - allows attacker to allocate memory with `READWRITE` permissions and copy code to the location then switch to `READ_EXECUTE` (**VAD tree only uses the permissions when first starting the process but can be compared within the PEB**) &#x20;