Bangeter 01-basic_malware_techniques_4.2.pdf

Mapped File:

The memory is shareble and represents a file on disk. Mapped files are often resource DLLs and typically contain application data. 

Sharable memory is memory that can be shared with other processes and is backed by RAM or by the paging file.

A heap represents private memory allocated and managed by the user-mode heap manager and typically contains application data. Application memory allocations that use Heap memory include th C runtime malloc library, the C++ new operator, the Windows Heap APIs, and the legacy Global Alloc and LocalAlloc APIs.

The mamged heap represnts private memory that is allocated and managed by the .NET runtime and typically contains application data.

Stack memory is allocated to each thread in a process to store function parametes, local variables and invacation recors

Typically, a fixed amount of Stack memory is allocated and reserved when a thread is created, but only a relatively small amount is committed.

The amount of memory commited within the allocation will grow as need, but will not shrink.

Stack memory is freed when its thread exits.

Private Data memory is memory that is allocated by Virtual Alloc and that is not further handled by the Heap Manager or the .NET runtime, or assigned to the Stoack categroy.

• Private data memory can not be shared with other processes.

Typicaly contians:

• application data
• Process and thread envirnment blocks.

Free memory regions are spaces in the process virtual address space that are not allocated.

Unusable memory, is free memory but cannot be used because of allocation granularity restrictions. (e.g. 64KB or 0x10000)

PE = Portable Executable

Features dynamic linking, symbol exporting/importing.

• .text: Contains the executable code
• .rdata: Holds read-only data that is globally accessible within the program
• .data: Stores global data accessed through the program
• .idata: Sometimes presnte, stores import function informatin; if not present import function information is stored in the .rdata
• .edata: Sometimes present, sotres the export function infromation; if not present export function informatin is stored in the .rdata
• .pdata: Present only in 64-bit executables and stores exception-handeling information.
• .rsrc: Stores resources needed by the executable
• .reloc:Contains information for relocation of library files.

• Kernel code creates process data structures such as EPROCESS, page tables etc...
• The image loader initializes the procesess:
  • virtual address space
  • Provides functionality to load DLLs at runtime

The image loader is user mode code and part of the ntdll.dll, it is the first (user mode) code run when a process starts.

Once loading is done the image loader will transfer exectution to the main image/ the EXEs entry point (which is defined in the PE).

1. Load the main image/EXE
2. Identify the DLLs used by the program (import address table, IAT), as well the DLLs used by those DLLs (IAT of DLLs)
3. Load the DLLs into memory (check if desired imports exist, by looking at the export table)
4. Link the code
5. Optionally, if a DLL cannot be loaded at its preferred position, it needs to be relocated.

• VAD tree (kernel)
• Page tables (kernel)
• PEB (user space)

The VAD tree is a kernel data structure:

• Self balancing binary tree
• lower addresses are to the left, high addresses are to the right.
• The nodes in the tree describe memory allocations.

It is used by the Windows memory manager to keep track of memory allocation in virtual address space of processes.

Create entries in VAD tree with VirtualAlloc() / VirtualAllocEx()

VAD tree also keeps track of:

• Mapped files
• Attribues of memory regoins (r, w, x, etc..)

PEB is in user space, it hold infromation about a process. The information contianed in the PEB is needed by the:

• image loader
• heap manager
• other Windows components that need ta access it from user mode.

The 5 most important fields are:

1. PEB_LDR_DATA
2. RTL_USER_PROCESS_PARAMETERS
3. Process heap
4. GDI shared hanle table
5. RTL_CRITICAL_SECTION

PEB_LDR_DATA structure contains info on loaded DLLs and main executalbe

Window organizes the loaded DLL list in 3 ways. According to the order the DLLs:

• were loaded by the windows loader
• are found in the memory layout
• were initialized

• Process hacker
• Windows Sysinternals
  • process explorer
  • vmmap
  • etc..

• Infection: via exploit / social engineering -> results in dropper executing in memory
• Persistence (optional but typical)
• Launc and hide
  • Application of root-kit / hiding techniques
  • Installation of malicious functionality
• Payload exection
  • Execution of malicous functionality
  • Data theft, data exifltration
  • DDOS
  • Initial pauload may load additional code

• As a process
• As a DLL that is loaded into a process
• Code that is directly injectied into a process
• Kernel code

Dropper: is a malware type where the inital malware executable contains the executable to be installed.

Downloader is a malware type where the inital malware executable downloads the executable to be installed.

• Need to know legitimate processes (-> whitlisting approach)
• Sometimes malware is using process names that are similar to legitimate ones
• Inspect path of executable (from where is the process launched)

• Requires kernel level access
• Process are unlinked from the process list in order to hide a process
• Often kalled DKOM = Direct Kernal Object Manipulation
• Is rare in practice.

DLL injection is done by loading a malicous DLL into a legitimate process.

Reasons DLL injection is done:

1. Hide in victim process, and thus avoud detection
2. Inherit privileges of victim process (eg. to bypase filtering on firewall)
3. Manipulate victim process (eg. infiltrate browser to steal credentials)

1. Process A enables debug prrivilege (SE_DEBUG_PRIVILEGE). 
2. Process A opens a handle to Process B by calling OpenProcess.
3. Process A allocates memory in Proces B using VirtualAllocEx.
4. Process A transfers a string to process B containing the full path to the malicous DLL.
5. Process A calls CreateRemoteThread to start a new thread in Process B that executes the LoadLibrary function.
6. At this point the injection is complete and Process B has loaded the DLL. Process A calls VirtualFree to free the memory containing the DLLs path.
7. Process A calls CloseHandle on Process Bs process to clean up.

...

• Look for loaded DLLs in processes.
• LoadLibrary() function is a legit technique exposed by the image loader for loading DLLs, is not designed for stealth.
• LoadLibrary() creates various artefacts:
  • Entries in the PEB
    • PEB containes 3 double linkded lists of the DLLs loaded in a process.
  • Entires in the VAD

The PEB is stored in the user mode memory of each process. Therefor the PEB can be modified to perform a DLL unlinking.

Detection: The VAD runs in kernel mode and also containes a list off DLLs. So the VAD can be cross referenced with the PEB to see if an unlinking occoured.

• LoadLibrary() in DLL injection leaves traces.
• Code injection avoides using LoadLibrary() by directly injecting the entire malware code from the launcher process into the victim process.

1. Iterate over process list to select victiom process.
   • Some malware injects in all processes it gets access to other malware is more slective.
2. Run OpenProcess() to get handle of victim porcess.
3. Allocate memory in the victim useing VitualAllocEx(). Alocated memory needs to be writable + executable.
4. Inject code using WriteProcessMemory()
5. Use CreateReamoteThread() to start injected code in a seperate thread.

Since LoadLibrary() is not used the steps of the Windows loader need to be performed by the malware:

• Map sections into memory
• Loading of DLLs (DLLs used by the malicious code that arn't already loaded)
• Fill IAT
• Apply relocations

(Relocations con be avouded if so called "shell code" is injected; shell code is position independent code.

Direct code injections don't show up as process or DLLs.

They still leave following traces:

• Memory allocated by VirtualAllocEx() will be tracked in the VAD tree.
• Memory allocated by malware is mostly RWX, which is uncomon and suspicious.

Detecting the process using:

• pslist
• pstree
• psscan

If proces is trying to hide useing DKOM unlinking use:

• psxview

Use dlllist to get full path of the process exe

Traces are left on disk and in autostart mechainsm