We have previously analyzed a malware sample claimed to have attacked the Brazilian Justice Court (Check here). After that, a new payload arrived. It is a Windows malware–available on Virustotal (check here)–, such that we are not sure what is its relation with the previous Linux one. Anyway, let’s analyze it!
We first tried, as usual, automated analysis in our sandbox solution. Unfortunately, as for the Linux payload, nothing interesting was found (check report here). So, let’s dig deeper. I will skip some preliminary analysis steps for the sake of simplicity, so I can right now tell you that we discovered that this file is a loader; it does nothing but loading and running an external code.
We can get the loader behavior by looking to the disassembly excerpt shown in the figure below. The malware sample decodes a file content by adding to it the value 0x21, xor-ing it with 0x80, adding the value 0x3, and xor-ing it with 0x80 again. Since the double xor returns the byte to the original value, in the end, the decoder sums 0x24 to the original byte value. But now, from where this encoded data come from? Well, IDA says the config.dat file. This file was unavailable in our sandbox, so this is why automated analysis failed initially.
Since this malware samples depends on an external file which is deleted by the malware itself (see in the figure above), we can’t tell whate happened in the Justice Court’s computers. However, for analysis purposes, we can create our own payload to test with this loader. We decided to create a simple messagebox code to test it, as shown in the figure below.
We can convert this code to a shellcode by looking to the instruction bytes, as shown in the figure below. I’m skipping all the details about how to generate a shellcode, but let me know if you want to learn, maybe I can write about it in the future.
Nice! Now we have a shellcode! But there is still one problem: the shellcode to be embedded in the config.dat file must be subtracted by 0x24, since the the loader adds this value back. If we simply do that to this original shell code, we will have many bytes below 0x24 that would result in zero or negative byte values, thus breaking the shellcode. So, what to do? Let’s encode the shellcode! But, which encode? We need something whose byte values are bigger than 0x24: Printable ASCII characters! Just to be sure it will work, capital chars! And, how to do it? Luckily there is metasploit in the world, see the figure below.
After that, we have a new shellcode, so we can subtract 0x24 and add the result to the config.dat. When we run the original malware having this created payload in the config.dat file, we get:
Enjoy!
