Malware analysis writeup: Heodo (2/2)

This is Part 2 of a malware analysis I did last week. This time, it was not an exercise!

In Part 1, I described how I extracted a PowerShell script executed by a VBA macro hidden in a Word document. At the end, I was able to download the program that was supposed to be downloaded by the PowerShell script. In the sequel, I am going to describe the analysis of this program named 71.exe.

First look

I uploaded the program to VirusTotal again and found out that it was already known. Looking at the report, it did not look like the executable was packed, but entropy was still quite high. This happens when a program embeds some content, like other DLLs, executables, etc.

The first thing that struck me was the use of the following functions:

CADeleteCA
CAEnumFirstCA
CAEnumNextCA
CACloseCA
CACloseCertType

I thought that this malware was maybe installing/replacing a rogue certificate somehow. From VirusTotal, that’s all I could gather so I decided to boot a Windows 7 VM and started a static analysis.

Post-mortem: once again, I neglected the VirusTotal report. I did not pay enough attention to the antivirus reports, which led to extra work to find what this program was all about. In addition to that, my lack of experience made me think about a small-ish malware and I never thought that it could be a very complex and well-known malware.

Static analysis

I started by running strings on the 71.exe file. I found some function names and a lot of garbage but nothing really obvious. Using PeID, I could not find evidences of a packer, same with DIE.

I used PeView to look more into the different sections and did not spot any big problem (again, based on my knowledge). Virtual and raw sizes looked similar and section names were not weird. I concluded that the program was likely decoding its instructions at runtime.

Post-mortem: I might have missed something though, but at the time, that’s all I could gather.

Given that I was stuck and could not find more useful information about this executable, I decided to switch to dynamic analysis 👻

Dynamic analysis

Dynamic analysis is any examination performed after executing malware.
– In Practical Malware Analysis, Chapter 3

In a Windows 7 32-bit VM, I started a few tools and then executed the malicious program in order to analyze its behavior 💣 After a few seconds, the program disappeared as shown in Figure 1. I already saw this behavior during a previous analysis, so I made a copy of the program before running it.

Figure 1: the program disappears shortly after being executed

Procmon

Further investigation using Procmon revealed that it renamed itself to C:\Windows\System32\hotspotsel.exe (cf. Figure 2). Given that this path was not present in the strings output, I had the confirmation that the program was decrypting its instructions at runtime and only loaded information in memory when needed. This seems to be a common protection against malware analysts. That was quite unexpected given that its Downloader (cf. Part 1) was pretty easy to reverse.

Figure 2: SetRenameInformationFile call captured by Procmon

Regshot

I continued my analysis by reviewing the diff of the Windows registry created with Regshot as depicted in Figure 3 (Right-click > “View image” to display the image in full size).

Figure 3: A diff of the registry created with Regshot

I discovered two interesting facts about the program:

1. it creates a service called hotspotsel.exe that is supposed to “copy user certificates and root certificates from smart cards […]”. The service is persistent and survives reboots based on the sc query output shown in Figure 4.

   Figure 4: The output of service control

2. it turns on a feature called WPAD. Googling this term revealed that this Windows feature was a known vulnerability.

With the second fact combined to the references to the CA* functions, I really thought that this program was trying to get access to secure exchanges (HTTPS) but I was only guessing.

Process Explorer

Looking at Process Explorer, I could confirm that the service was running and I discovered that it was started with a command line argument. I supposed that the presence of the argument started the program in a “service” mode instead of trying to install itself as a service (like when I executed the program manually).

The printable strings retrieved from the running service memory were not super helpful unfortunately. I could find the service name (hostspotsel) as well as the fully qualified path to the executable and the name of the computer followed by 6 characters, but nothing else.

Last thing I discovered was a bunch of network calls with what seemed random IP addresses and different ports such as: 80, 8080, 443, 465, 22, etc. The Windows VM was fully isolated during this analysis phase, so all requests failed and I could not gather new information. It was time to perform a network analysis.

Network analysis

Network analysis is still dynamic analysis but focused on network activities.

In order to do that, I recreated a new lab containing a Windows 7 VM as well as a REMnux (Linux) VM, both in the same VirtualBox “internal network”. I configured the Linux VM so that it catches all TCP/IP packets, no matter the destination IPs. In the Windows VM, I set the gateway IP to the Linux IP. I had noted some destination ports before so I started a bunch of netcat on different ports in the Linux VM as well.

I executed the 71.exe program in the Windows 7 VM again. In Process Explorer, I saw that some network calls were ESTABLISHED, which meant that the malware was able to connect to its servers. That’s what the malware thought though, because it actually connected to the Linux VM, which received a bunch of HTTP POST requests in the different netcat I had started before. There is an example in Figure 5.

Figure 5: A POST HTTP request captured by netcat listening on port 8080

For each request, the HTTP body was base64-URL-encoded. I tried to decode some of these bodies but none was readable. The content was probably encrypted first and then encoded with base64.

Hello, Heodo

I noted the IP addresses and ports printed in the different netcat outputs, and I used Google again to get more information. I found that one IP address was referenced as a C2 server of a famous botnet called… Heodo. I put a name on this malware, finally!

I then gathered more information about Heodo:

1. it is a variant of Emotet. I did not expect to analyse one of the most prevalent malware as a first!
2. This malware is often distributed via emails using an attachment (like a Word document) that contains a malicious PowerShell script to download and install it.
3. Once the malware is installed, it tries to reach a C2 server from a list. That’s exactly what I noticed during my network analysis, cool.
4. Exchanges are encrypted with RSA. That is probably why I could not read anything after having decoded the base64-URL-encoded HTTP bodies.
5. When the malware tries to phone home for the first time, it collects and sends data to the C2 server, which might respond differently depending on what is sent. For example, it sends the computer name followed by some information about the CPU and the list of running processes. If this list contains a malware analysis tool, it will not send a new program but either nothing or itself.

Even though most of my findings matched the characteristics of Heodo/Emotet, I was not 100% sure that the program I was analyzing was Heodo/Emotet. C2 servers might be compromised by more than one bad actor, so we cannot only infer the malware based on the IPs it interacts with (I think).

Debugger

I decided to attach the Ollydbg debugger to the running service (hotspotsel.exe) to see if I could learn something new. I only used this debugger twice before and during guided exercises so I did not really know what I was doing -__-

I decided to pause the execution when a connection was established (this can be seen in Process Explorer). I tried to find ASCII strings and eventually found an IP address. This IP address also appeared in one of the netcat outputs on the Linux VM. I told the debugger to find the IP address in the memory dump and manually reviewed what was there before and after this point. I found a long list of process names, including OLLYDBG.EXE and VBoxTray.exe as depicted in Figure 6. This is the list of all the running processes in the Windows VM!

Figure 6: The Ollydbg window with a list of processes (in the blue rectangle)

I was also able to find a few more IP addresses in the memory dump and the computer name again, followed by the same characters I read in Process Explorer before (in the “printable strings”).

These findings validated the 5th item in the previous section: Heodo/Emotet malware send the list of running processes to their C2 servers. That way, C2 servers can detect malware analysts. The program will likely keep sending this list until the C2 server tells it to do something else.

At this point, I was confident and decided to stop my analysis here. I reached my goal: I discovered which malware was installed by the Word document received by my friend.

What’s next?

I found a great deep analysis of an Emotet variant as well as some interesting tools when I was writing this article. It seems possible to patch the malware at runtime to hopefully retrieve other malicious programs. This requires to connect the Windows VM to the Internet, though. In the future, I’d like to perform a similar analysis.

I would also like to see if I can fully reverse the 71.exe program to retrieve the RSA keys, C2 IP addresses and so on (if possible). Reverse engineering is not my best strength though.

Recap’

• I analyzed a malware with various techniques.
• I discovered that this malware was a well-known malware named Heodo.