notes/docs/lectures/malware/08_processes.md

Processes

• Malware will often exploit other processes on the system
• Either already running, or by running them
• It does this to hide it’s 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 its 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 alywas 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 APU calls are normally made by making indirect calls to relevant implementation in the DLL
  • Normally Windows links the calls to the DLLs at load time but the malware code wasn’t ‘loaded’
  • The malware code does not know where the DLLs 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 DLLs 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]

  • 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 its been loaded
    • Points to the start of the DOS file header
  • Can search this linked list until we find the DLL of interest

• 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