This method is extremely useful if the time to analyze a sample is limited, or if there are many of them, without going into the details of how the sample is actually stored.
The idea here is that the original malware usually allocates a big block of memory in order to store the unpacked/decrypted embedded sample. We will cover what happens when this is not the case later.
There are multiple Windows APIs that can be used for allocating memory in user mode. Attackers generally tend to use the following ones:
- VirtualAlloc/VirtualAllocEx
- LocalAlloc
- GlobalAlloc
- HeapAlloc
In kernel mode, there are other functions such as RtlAllocateHeap, ZwAllocateVirtualMemory, and ExAllocatePoolWithTag that can be used in pretty much the same way.
If the sample is written in C, it makes sense to monitor malloc/calloc functions straight away. For C++ malware, we can also monitor the new operator.
As long as we stop at the entry point...