Malware analysis writeup: Heodo (2/2)Freiburg, Germany
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
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.
PeView to look more into the different
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.
|virtual size||size of raw data|
|.text||4280 (0x10b8)||4608 (0x1200)|
|.data||70580 (0x113b4)||70656 (0x11400)|
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 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.
Further investigation using
revealed that it renamed itself to
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
I continued my analysis by reviewing the diff of the Windows registry created
Regshot as depicted in
Figure 3 (Right-click > “View image” to display the image in full size).
I discovered two interesting facts about the program:
it creates a service called
hotspotsel.exethat is supposed to “copy user certificates and root certificates from smart cards […]”. The service is persistent and survives reboots based on the
sc queryoutput shown in Figure 4.
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.
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 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
netcat on different ports in the Linux VM as well.
I executed the
71.exe program in the Windows 7 VM again. In
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
POST requests in the different
netcat I had started before. There is an
example in Figure 5.
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.
I noted the IP addresses and ports printed in the different
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:
- it is a variant of Emotet. I did not expect to analyse one of the most prevalent malware as a first!
- 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.
- 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.
- Exchanges are encrypted with RSA. That is probably why I could not read anything after having decoded the base64-URL-encoded HTTP bodies.
- 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).
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
VBoxTray.exe as depicted in Figure 6. This is the list of all the running
processes in the Windows VM!
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
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.
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.
- I analyzed a malware with various techniques.
- I discovered that this malware was a well-known malware named Heodo.