Ransomed challenge
Introducation
in this article, we will see how to solve the Ransomed challenge
and learn the process malware analysts use to unpack malware that uses a custom packer.
Question(1)
I want to teach you how to examine malware’s hash in this question. So we open malware with the PeStudio tool and check the md5 hash, and we can see the results in the next figure.
Question(2)
In this question, I want to teach you how to identify malware is packed or not. so I will open malware with the detect it easy
tool and identify that malware is packed from its entropy value, and we can see the results in the next figure.
Question(3)
in this question, I want to learn how to identify the sections and examine them to discover some other indicators that malware is packed so that we will use the PE file tool, and I am using a common tool in this point called “Pestudio” tool. After opening the malware with this tool and going to the section table, we can see that the section number is (4), and we can see that in the next figure.
Question(4)
In this question, we want to identify that malware is packed in a specific section. so I asked the people about the .text section and its entropy to see that malware is packed in this section, and we can see that in the next figure (4)
Question(5)
When malware allocates a region of memory to write the shellcode into it, it uses a common technique, called “Stack String,” to obfuscate the strings and hide them so utility such as “strings” can not get any important strings.
Question(6)
In this question, I want to tell people about the common API used to allocate a region of memory in unpacking malware, so malware here uses the “VirtualAlloc” to allocate a region of memory. We can see that if we set a breakpoint in the command line of the debugger and run malware with F9.
Question(7)
in this question, after allocating a region of memory, we can select the first bytes into the region of memory and follow them in the memory map, and we can see the protection is “ERW,” and we can see that in the next figure
Question(8)
After malware allocates a region of memory, we can see that the malware writes the shellcode into this region of memory. After that, malware stores the start address into dword ptr ss: [ebp-4]
and use the assembly instruction jmp dword ptr ss: [ebp-4]
to transfer the execution to shellcode.
Question(9)
In this question, I want to use a different way to see Resolved APIs
the first thing dump the shellcode from the allocated region of memory and use scdbg
emulator and load the shellcode into it, and after that, select the option find such
. The emulator will ask you about indexes. Enter the index of shellcode to see Resolved APIs.
The second way, we need to debug the code in the debugger to see that malware loads the library and resolve the APIs from its library.
Question(10)
In this question, we want to calculate the APIs resolved from the kernal32.dll library, and the easy way uses scdbg. It arranges each library and its APIs that are resolved from it.
Question(11)
In this question, I want to ensure that people use a debugger and execute the code line by line, and after calling RigisterClassA
, we can see that malware obfuscates two strings, and we can see that in the next figure.
Question(12)
when the malware creates a process, we can see the dwCreationFalg and get its value in hex
.
Question(13)
From the dwCreationFalg, we can identify that malware creates a process in suspended mode. And after that, use some APIs and write the code with WriteProcessMemory. The final malware uses ResumeThread to execute malicious code, and we can see that malware uses the Process Hollowing technique to inject code into the suspended process.
Question(14)
we can see that malware writes the malicious code with WriteProcessMemory API