It all started from a spam campaign. Figure 1 shows a campaign we picked up recently from our spam traps with a suspicious document file attachment. Notice how poor the English is; this shall serve as a sign of warning to the email recipients.
The attachment uses the “.doc” file extension but is actually an RTF (rich text file) file format. The file contains a specially crafted RTF stack overflow exploit. This was determined to be the CVE-2010-3333 that exploits the Microsoft Word RTF parser in handling the “pFragments” shape property. This vulnerability had been patched more than half a decade ago.
As you can see in Figure 2, the exploit and the shellcode were obfuscated to avoid antivirus detection. After extracting, cleaning up and decoding the exploit, I figured out that the shellcode would download and execute a file from the domainvolafile[.]io
The downloaded file is a Microsoft .NET Win32 executable. A quick hex dump preview of the file gave a very interesting clue that I am dealing with a HawkEye keylogger build.
And with a little bit of Google-Fu, the string pointed me to a website which develops this keylogger. In the website, they’ve listed all of its “awesome features”.
In my quick dynamic analysis, the keylogger drops a copy of itself to the Application Data (%appdata%) folder and uses the filename WindowsUpdate.exe. It sets an autorun registry to facilitate persistency in the Windows system even after reboot.
It also drops the following files in the infected system:
- %Temp%\Sysinfo.txt – the dropped malware executable path
- %Appdata%\pid.txt – the malware process ID
- %Appdata%\pidloc.txt – the malware process executable location
I then observed network activity from the keylogger process that tries to obtain the infected system’s external IP address from checkip.dyndns.com. This legitimate website is commonly used by malware to determine the IP address of the infected system.
After a short while, SMTP network activity was observed where the system information of the infected system was sent to the attacker’s email address.
The information may include:
- CPU Name (computer name)
- Local Date and Time
- Installed Language
- OS Installed
- OS Version
- Memory installed
- .Net Framework Installed
- System Privileges
- Default Browser
- Installed Firewall
- Internal IP Address
- External IP Address
- Recovered Email settings and passwords
- Recovered Browser and FTP passwords
As previously mentioned, the keylogger was compiled with Microsoft .NET. So the next thing I did is to decompile the executable. I used an open-source .NET Decompiler called ILSpy to accomplish this task.
I took a closer look in the decompiled source code and compared it to its list of “Awesome Features”. I can confirm that its claim is 100% legit. I found the following features in its code like:
A clipboard stealer/logger.
A browser, FTP, and Mail Client password stealer. It also attempts to steal password manager credentials and Windows keys.
A worm-like USB infection routine that will allow the keylogger to spread to other Windows machine.
It may also target the users of online gaming platform Steam. It deletes the configuration data and login data files so that the user will be forced to login again. This is an opportunity for the keylogger to steal the user’s Steam credentials.
The stolen information including the desktop screenshot are sent to either to the attacker’s email address or FTP server depending on how the keylogger was configured.
The attacker may also configure the keylogger to upload the stolen information through a HTTP tunnel to a PHP host, but the code seems to be voided.
The most interesting part I’ve found in the decompiled code however is a C# constructor named Form1(). This is where the keylogger configuration was stored. But to secure the attacker’s email and FTP credentials, these data were encrypted using Rijndael algorithm and Base64.
As you may know, those encrypted data are not always secure, especially if the decryption routine is in the decompiled source code!
The image below is the “Decrypt” method where it accepts two string parameters: the encryptedBytes and the secretKey. The secret key happens to be a hardcoded string HawkSpySoftwares
As mentioned, the keylogger uses the Rijndael algorithm and the secret key is salted with the Unicode string “099u787978786”, also hardcoded.
Out of curiosity, I copied the decryption part of the code, modified it accordingly and compiled it in MS Visual Studio, and of course the decryption was successful. (sorry, I need to blur the credentials :))
Naturally, I checked out these email inboxes.
They appear to be email accounts on compromised systems. So I’ve checked the email settings, and surprise surprise! The emails sent to this inbox are rerouted automatically to the attacker’s Gmail account. You can see in the screenshot below the consistency of the downloaded keylogger’s filename and the attacker’s Gmail username (Seemaexport….).
Perhaps the attacker knows that the HawkEye keylogger can be easily cracked, and to protect their own email credentials, they’ve hijacked a compromised email account as the initial receiver that eventually forward emails to the attacker’s own email address.
We have reported the compromised email accounts to their rightful owners, in order for them to change their passwords and remove the attacker’s email address from their reroute message settings.
Since this was written, we received similar spam messages with RTF attachments but this time containing the CVE-2012-0158 exploit. The payload is the same keylogger but they have used a different compromised email account as the first receiver of the stolen data .
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.