Deep Dive into the M00nD3V Logger

ThreatLabz observed a multifunctional information-stealing trojan named "M00nD3V Logger'' that is being dropped by a multistage loader. Due to its multiple stealing features, M00nD3V Logger has gradually gained popularity on hacking forums. 

Recently, Blueliv published a blog discussing the relationship of M00nD3V with the HawkEye stealer, along with information about the bad actor selling M00nD3V. 

Aside from keystroke logging, the M00nD3V Logger has the ability to steal confidential information, such as browser passwords, FTP client passwords, email client passwords, DynDNS credentials, JDownloader credentials; capture Windows keystrokes; and gain access to the webcam and hook the clipboard. In all, it has the ability to steal passwords from 42 applications.

M00nD3V Logger is also equipped with other major functionality, including a botkiller, an antivirus killer, communicating over SMTP/FTP/proxy, downloading additional plugins, and the BouncyCastle crypto package. These mechanisms makes this logger unique and popular on hacking forums.

Figure 1: An image from the owner account.

Delivery mechanism

During our research, we found M00nD3V was delivered via spam mail or through a compromised website that drops a payload on the victim's machine. One such spam mail claims to be from "Hyundai Heavy Industries Co., Ltd" regarding a bid on a project for Qatargas. The spam mail includes ZIP attachments that contain malicious executables.

Figure 2: Spam mail.

 

Figure 3: M00nD3V Logger subscription and payment method pages.

In this blog, we will provide a detailed technical analysis of commercial M00nD3V Logger malware.

Technical analysis

• dab9565e03fae2c5c18c9071a713153a - Parent File (.Net)
  • e9cf47f3b0750dd0ee1ca30ea9861cc9 - Loader (.Net)
    • bf8801bcd5a196744ccd0f863f84df71 - Final Payload (.Net)

Delivering malware without triggering any suspicious activity while blending into an existing benign Windows process makes detection a bit harder. Here, the M00nD3V malware does one such trick to deliver its payload without getting easily noticed.

Figure 4: The M00nD3V malware register running with RegAsm.exe - Microsoft utility.

Figure 4 shows the post execution of the malware. In case of an allowlisted application, the endpoint antivirus will not trigger any malicious activity. Hence, the malware can do its job on the fly without getting caught. The malware also runs by elevating its own privileges.

Unpacking routine

The malware unpacks the encrypted payload using multibyte XOR decryption. While unpacking, the malware also uses null bytes in the XOR key. Hence, a few bytes are not actually ciphered.

First layer decryption

The hardcoded pass variable "zvjzpeuCFasb" is used as a key. When converted to Unicode string, the same pass variable is: "z\x00v\x00j\x00z\x00p\x00e\x00u\x00C\x00F\x00a\x00s\x00b\x00".  

The key length is 24 bytes. 

Figure 5: First-level decryption using multibyte XOR.

Even though key length is 24, the malware uses only the first 16 bytes to decrypt the resource section of the encrypted data. The above decryption routine results in a .NET PE file. In this dumped file, there is also a similar XOR routine to decrypt the data but with a different key to run the final payload.

Second layer decryption

Here, the hardcoded pass variable "WcqqicsgTUaj" is used as a key. When converted to Unicode string, the same pas variable is: "W\x00c\x00q\x00q\x00i\x00c\x00s\x00g\x00T\x00U\x00a\x00j\x00".

We have written a Python script to decrypt the encrypted payload, which can be found in Appendix I and Appendix II.

Payload analysis

StubConfig Class contains the configuration details - some of them are initialized with Base64 values while others are hardcoded.

Figure 6: StubConfig details.

Before starting to log user data, the M00nD3V Logger initializes its configuration. The initialization phase includes several checks, such as an anti-debugger, a bot killer, an antivirus killer, and more. Figure 7 shows the initialization module.

Figure 7: Initialization phase

Initialization details:

• DependencyLoader - Downloads the DLL from m00nd3v[.]com/M00nD3v/Decryption/BouncyCastle[.]Crypto.dll and loads it in memory.
• ExecutionDelay - Sleeps for 5,000 milliseconds before executing.
• SingleInstance - Checks to see if a single instance is running or not by checking for the hardcoded mutex value {99ed2fc7-0fdc-42ef-8b82-78d1c7c554e3} and sets a flag accordingly. If an app is running with the same mutex, then the loader exits from environment.
• DecryptCredential - Uses the Rijndael256 algorithm to decrypt the Stub configuration values [cipher data is Base64 encoded value and key is hardcoded mutex value] and set them to their respective variables, as show in Figure 8.

Figure 8: The decrypt credential. 

• Persistence - Copies the parent file to AppData directory and begins the startup entry [SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run].
• AntiDebugger - Checks to see if any of the following processes are running: SbieDll.dll, Wireshark, Winsock Packet Editor. If any are found, the malware terminates.

 Figure 9: AntiDebugger checks during the initialization process.

• Antivirus killer - Uses Image File Execution Options (IFEO) to interfere with the executables shown in Figure 10. By modifying the registry entry  [Software\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\], the malware attaches rundll32.exe as debugger to each of the executables. This way, it disables all the listed applications to run.

Figure 10: Application list

• Process elevation - As shown in Figure 11, the malware contains a process elevation module, which is responsible for elevating the privilege of the malware executable. The malware sets the security identifier type as "WorldSid" with AceQualifier AccessDenied. It is applicable to the "Everyone" group, so if anyone attempts to kill the process, it won't be allowed to terminate.

Figure 11: Process elevation.

• Bot killer - Scans all running processes and Windows Startup registry entries [ \\Run\\ and \\RunOnce\\ ], then passes the file location path to module IsFileMalicious() to tag either the process or file as malicious and delete it accordingly. [Note: In case of a running process, it additionally checks for each process window visibility property. If it is set to false, then it is tagged as malicious.]
  • Figure 12 shows the checks used inside IsFileMalicious(). Here, ‘fileloc’ is the full path of the file or process.

Figure 12: Malicious checks of the file.

Before starting to log the stored credentials and other personal data, it checks whether the malware was previously installed or not on the victim's machine by looking for a specific file name with a combination of Processor Id and Volume Serial Number in the temp directory. If the file is not present, then it creates and writes Rijndael256 encrypted data, which is a combination of the current executable path and the hardcoded StubConfigEncryptionKey, and then shows a fake message box to fool the victim.

Figure 13: The Rijndael256 key.

The malware has three kinds of communication methods to send logged data: SMTP, FTP, and proxy. But this stub is configured to use only and send data over SMTP only.

Before starting any logging functionality, it checks whether the respective logging functionality variable is set in the Stub config entry or not. If the value is not set in config, then it won't execute the "keystroke functionality". As shown in Figure 14, the Stub is configured to execute the keystroke but not the webcam as the webcam value is not assigned. 

Figure 14: Stub configuration.

The Stub starts its core stealing functionality by sending full victim machine information, as shown in Figure 15, to the attacker over SMTP port 587

Figure 15: Basic machine information sent to the attacker.

Network communication

Via SMTP

The malware communicates with the attacker over SMTP using port 587.

The malware crafts an email with the captured details shown in Figure 16 and sends it to the attacker. The attackers use "smtp.privateemail.com" service to transfer the captured data.

Figure 16: Information sent via SMTP.

The LogTypeName mentioned below is used to tag the data to inform the attacker what module it is running currently. 

Figure 17: Log type.

Via FTP

While uploading data over FTP, it first converts plain text data to bytes and creates FTP requests by configuring all the FTP request fields (i.e., ftp_host, credentials, method). The value for all these fields is set from the Stub configuration class. The FTP method used to upload files is "STOR".

Figure 18: Communication via FTP.

Via proxy  

The malware sets the proxy URL from the config class and uploads the below-mentioned data using the POST method.

Figure 19: Communication via proxy.

The values encrypted with Rijndael256 where the key is the Proxy Key, which is configured in the Stub config class.

Each stealing module runs independently with individual threads, as shown in Figure 20.

Figure 20: The core modules.

Password stealer: M00nD3V Logger has the capability to steal passwords and cookies from all possible browsers and email clients, as well as FTP clients.

Interestingly, the malware has three separate classes named "ChromiumProvider", "MailProvider", and "MozillaProvider" as shown in Figure 21. Each provider has a functionality to retrieve and decrypt the password for the application that is assigned to that provider.

Figure 21: Provider list.

The malware first tries to decrypt the password with the data protection APT (DPAPI) library. But if it isn't successful, then it attempts to decrypt the passwords using "BouncyCastle", which the malware downloaded from "m00nd3v.]com/]M00nD3v/Decryption/BouncyCastle.Crypto.dll". It includes "GcmBlockCipher" and "AeadParameters" classes, whose instances help the malware decrypt the final password.

 

Figure 22: The BouncyCastle code. 

The collected passwords are sent to the attacker over SMTP.

Figure 23: The collected passwords sent over SMTP.

Webcam

The malware has the capability to secretly access the device's webcam and capture the image. The malware copies the captured image onto the clipboard, extracts the image from clipboard, then saves it in the temp directory. To send stolen images over SMTP, it reads the image path and attaches the .bmp image as an email attachment with a personalize the subject line, such as "Dear M00nD3v user Please find the attachment of Webcam. Regards M00nD3v"

Figure 24: The webcam module.

Similarly, the other modules named keystrokes, clipboard, and screen sender, execute with individual threads and send stolen data to the attacker, then sleep for some period of time before repeating the same stealing process.

Figure 24: The Zscaler Cloud Sandbox report for the M00nD3V Logger.

 

The following is the advanced threat protection signature released for detecting the malware:

Win32.Backdoor.M00nD3v

 

MITRE ATT&CK™ tactic and technique mapping

T1503	Credentials from Web Browsers
T1112	Modify Registry
T1060	Persistence
T1057	Process Discovery
T1105	Remote File Copy
T1497	Defense Evasion, Discovery
T1083	File and Directory Discovery
T1089	Disabling Security Tools
T1055	Process Injection
T1548	Abuse Elevation Control Mechanism
T1115	Clipboard Data
T1113	Screen Capture
T1125	Video Capture
T1056	Input Capture
T1048	Exfiltration Over Alternative Protocol
T1183	Image File Execution Options Injection

 

IOCs:

dab9565e03fae2c5c18c9071a713153a - Parent File (.Net)

e9cf47f3b0750dd0ee1ca30ea9861cc9 - Loader (.Net)

bf8801bcd5a196744ccd0f863f84df71  - Final Payload

C&C:

m00nd3v[.]com

Appendix I : 

Python Script to decrypt first level decryption:

file=open('enc.bin','rb')

cont=file.read()

file.close()

xor_key="z\x00v\x00j\x00z\x00p\x00e\x00u\x00C\x00"

fl=''

index=0

for i in range(len(cont)):

    fl+=chr(ord(cont[i])^ord(xor_key[index%16]))  #Malware doesn’t use full key

    index+=1

hexval=[]

for i in fl:

    temp=hex(ord(i))

    temp=temp[2:]

    if len(temp) !=2:

        temp='0'+temp

    hexval.append(temp)

hexva=("".join(hexval))

import binascii

binstr=binascii.unhexlify(hexva)

f=open('fixed','wb')

f.write(binstr)

f.close()

 

Appendix II : 

Python script to decrypt second level decryption:

file=open('enc2.bin','rb')

cont=file.read()

file.close()

xor_key="W\x00c\x00q\x00q\x00i\x00c\x00s

\x00g\x00T\x00U\x00a\x00j\x00"

xor_key=xor_key[0:16]

fl=''

index=0

for i in range(len(cont)):

    fl+=chr(ord(cont[i])^ord(xor_key[index%16]))   #Malware doesn’t use full key

    index+=1

hexval=[]

for i in fl:

    temp=hex(ord(i))

    temp=temp[2:]

    if len(temp) !=2:

        temp='0'+temp

    hexval.append(temp)

hexva=("".join(hexval))

import binascii

binstr=binascii.unhexlify(hexva)

f=open('fixed2','wb')

f.write(binstr)

f.close()