MA Playbook

2022-01-16 2022-01-16 567 words 3 minutes

Contents

This posts contains potentially helpful malware analysis techniques and know-hows and would hopefully be updated constantly 🤞.

PE Extraction

To extract PE files from memory, several methods can be used:

Use Process Hacker to dump memory region into file for analysis in IDA.
Use pd64 to dump modules from a running process.
- This is helpful for modules that are decrypted and loaded during run-time by launchers.
- Should output a perfectly debuggable DLL for analysis.

Shellcode Extraction

Can use x32dbg to debug the executable loading the shellcode.

If shellcode is copied into memory allocated via VirtualAlloc, can breakpoint at VirtualAlloc and return to user code
eax will now hold the address of the newly allocated block of memory
Follow in dump to keep track of memory writes to that location
Executable might eventually write to the allocated memory
- Can be encrypted or not
- View bytes in allocated memory, looking out for strings and known sequences
An indicator that shellcode has finish decrypting/writing, is that the original exe performs a jump or a call to the newly allocated memory

Once confident that the memory contains shellcode, can use process hacker to dump the memory region into a file for analysis.

Can use IDA to statically analyse the shellcode

Shellcode Analysis

Once opened in IDA, there won’t be any imports or APIs visible. The shellcode likely has to do dynamic API resolution. It is handy to keep the debugging session running to have better insights into API resolution and APIs called.

PE Sections

.reloc Section

Full disclosure:
This section is a condensed version of the blog post here. I highly recommend reading the blog post for a clearer picture of what’s going on.

The .reloc section contains a series of blocks containing the IMAGE_BASE_RELOCATION struct.

1
2
3
4
typedef struct _IMAGE_BASE_RELOCATION {
    DWORD   VirtualAddress;
    DWORD   SizeOfBlock;
} IMAGE_BASE_RELOCATION;

The data after the struct is the individual (2-byte) entries.

The VirtualAddress of each block in the section refers to the Relative Virtual Address (RVA) of which, relocation should happen. Each entry after the struct contains the offset from the Virtual Address in which relocation should happen.

Relocation Process:

Delta of preferred load address and actual location is calculated
- Preferred load address can be found in the Image Base field of Optional Headers
Each 2-byte entry is parsed in the following format:
- <type(1 Hex)><offset (3 Hex)>
- 0x3007 -> type: 3, offset: +0x7 of page
- RVA is obtained via VirtualAddress + offset
Go to RVA and retrieve DWORD in little-endian
- This DWORD is the virtual address of which relocation should happen
Take delta calculated in step 1, and add to DWORD
New address is the relocated address

Dynamic Analysis

If malware connects to a C2 IP, can attempt to reroute the traffic via the following command: netsh int ip add address "Loopback" <ip>

All traffic to the IP should now routed to localhost, and a C2 can be mimicked locally.

Noteworthy Points

If malware is a DLL and uses threading, take note that if WinAPIs are called in the thread, it might cause rundll32.exe to exit when the WinAPI is triggered if there is no other instructions making the main thread active.
This is due to the child thread being in a suspended state while the main thread continues execution, eventually coming to an end and exiting. To rectify, suspend rundll32.exe’s thread once in the newly created thread, to prevent the main thread from exiting.