Most of the HDDCryptor samples I saw weren’t packed, but I found one sample that at first sight didn’t look suspicious, however, if we look carefully, there are clues of malicious code activity.
The main function code looks like this:
We can see that there are a lot of calls to functions like tan()/cos()/pow()/sin()/ceil() that at the very beginning don’t give any suspicion of being malicious code, however, by looking at the imports something call out attention:
I put a breakpoint on the first reference to the GetProcAddress function and started tracing the code (some “Integer Division by Zero” exception are generated but just pass it with SHIFT+F9):
This routine just calls GetProcAddress to get all the necessary functions to do the dirty work. For example, the first function it gets is CreateProcess:
Immediately, it use it to create a child process:
Then, it continues by getting the context of the recently created process:
This way, it obtains the PEB address from the process:
and then, by calling ReadProcessMemory to read the PEB structure, it gets the base address of the created process:
After that, it calls VirtualQueryEx to get information about its sections:
After this, the packer overwrites the original PE header of the process, allocates some memory in it, it writes the new ImageBase on its PEB and finally, it writes the actual ransomware code trough a single WriteProcessMemory call:
The “Buffer” parameter has a pointer to a full decrypted PE with the actual ransomware code:
At this point, we can use PE Tools or VSD in order to dump the full memory region and obtain the unpacked binary.
Analyzed sample hashes: