WannaHusky Malware Analysis Report - PMAT Final

In this post is my analysis of a provided sample at the end of my Practical Malware Analysis and Triage course from HuskyHacks / Matt Kiely. The binary is benign and was used to further familiarize myself with the tools and techniques learned throughout the course. I really enjoyed the course and I am currently working towards readying myself for the associated PMRP certification. At the end of the PMAT course, we are challenged to create a report of any of the samples included in the provided course files, and for this I chose the wannaHusky ransomware sample.

Practical Malware Analysis & Triage

Arm yourself with knowledge and bring the fight to the bad guys. Learn the state of the art of malware analysis and reverse engineering.

TCM Security, Inc.Matt Kiely

Ransomware.wannaHusky is a ransomware sample that was created for the purpose of analysis for the PMAT course. It is a Nim-compiled executable built on the x32 Windows architecture. The binary initially checks the user’s home and desktop directories to see if the file ‘cosmo.jpeg’ is present on the desktop before continuing with execution. A successful execution results in the file cosmo.jpeg being encrypted with a custom encryption algorithm and renamed with an appended ‘.WANNAHUSKY’ file extension. Additionally, an image named WANNAHUSKY.jpeg, which serves as a ransom note, is placed on the desktop, and the user’s desktop wallpaper is changed to WANNAHUSKY.jpeg through the execution of a dropped script named ‘ps1.ps1’.

Malware Composition

Ransomware.wannahusky consists of the following components:

Wannahusky.exe

The initial executable that begins the entire execution flow of the malware. This file creates the following files:

• ps1.ps1
• WANNAHUSKY.PNG
• cosmo.WANNAHUSKY

This file executes the following commands:

• tree C:\
• powershell C:/Users/<username>/Desktop/ps1.ps1

The executable has a custom-defined encryption method used to encrypt cosmo.jpeg on the user’s desktop. The initialization vector and the key for the encryption are stored in memory during runtime and subsequently deleted. Following successful execution of the commands, the program deletes the dropped ps1.ps1 file.

Ps1.ps1

A PowerShell script that is written to the desktop. The ps1.ps1 script is intended to change the wallpaper to the ransom note image WANNAHUSKY.PNG also placed on the desktop. The script sets up a custom method in C# to interact with the Windows API. It then defines variables in PowerShell and calls the method, passing the defined variables to set the wallpaper.

VirusTotal Sample Scan Results:

Scan results provide details that this sample does have characteristics that resemble malicious files. The ‘Details’ tab details that this is a 32-bit portable executable compiled using Nim. It shows that the file was created on October 12^th, 2021.

CAPA Results

• MD5: 0287b38f8240a025b30c0a231ea403fc
• SHA1: 691ac1b4b7b494f7b56eff0b48ba3e31a14e0d7d
• SHA256: 3d35cebcf40705c23124fdc4656a7f400a316b8e96f1f9e0c187e82a9d17dca3

When running CAPA on the file, several interesting capabilities were observed, detailing potential behaviors when executed:

• Encryption, encoding, and hashing techniques:
  • Base64
  • HC-128
  • SHA256
• File System manipulation:
  • Read and write functions
• Command execution and process control activity
• Memory manipulation:
  • Potential process injection

PE Studio Analysis

Libraries Referenced

• KERNEL32.dll
• msvcdt.dll

Interesting Imports

The presence of the following imports likely indicates process creation, deletion, or injection activity:

• GetCurrentProcessId
• VirtualAlloc
• VirtualProtect
• GetCurrentProcess
• GetCurrentThreatId
• TerminateProcess
• Sleep
  • May be used as a sandbox evasion technique.
• LoadLibraryA
  • Potentially used for executing other functions via an API, sometimes for obfuscating execution imports.

Flagged Strings

The following strings were flagged as potentially indicative of execution flow:

• DeleteFile
• SetFileAttributes
• GetEnvironmentStrings
• @Desktop\ps1.ps1
• @Desktop\WANNAHUSKY.png
• @Desktop\cosmo.jpeg
• fprintf, fread, fwrite

Analysis in PE studio reveals that this executable likely creates child processes, deletes files, performs cryptographic methods on data, and works with local environment strings. The executable has several interesting strings that will clue us into its execution flow. Using FLOSS and String Sifter did not reveal any new important details of the file.

Upon running the sample, we see a few actions take place after a few seconds: 

We see many environment variables present when the process launches, many not pictured. 

File on desktop cosmo.jpeg gets renamed to cosmo.WANNAHUSKY

There are repeated WriteFile event for the renamed file cosmo.WANNAHUSKY, likely related to the encryption process we can hypothesize exists from the Capa results. We can also observe that the Offset for the file increases by fixed amount 4,096, further strengthening this hypothesis. 

File ps1.ps1 is created on the desktop 

We also see WANNAHUSKY.PNG created on the desktop: 

We then see the powershell script being executed via a call to cmd.exe: 

We then see command tree C:\ executed via a call to cmd.exe: 

We finally see the ps1.ps1 script being deleted due to the FILE_DISPOSITION_DELETE flag being set before a CloseFile operation, which indicates the file is marked for deletion: 

With more context on what the binary does, we can open it within Cutter to analyze the Assembly instructions. The starting point for the binary is mainCRTStartup() which initializes the C runtime environment and is pretty standard for Nim binaries compiled in C. Because we know this binary was compiled with Nim, we look for and find the standard naming convention for the main function NimMainModule00 at 00x0040e042: 

Here we can see several interesting functions we will investigate:

• nosgetCurrentDir00
• nosgetHomeDir00
• wannaHusky_400
• changeBackground__4_200
• nosexecShellCmd04

Looking at nosgetCurrentDir00, we can see the following beginning block:

Here we see a few things happen of note:

• data.00411b43 being pushed into ecx.
• Memory address points towards 00, likely indicating that data is not initialized at this instance.
• Assigning 0x104 (260) to both edx and esi.
• Making space in esp for 32 bytes.

Looking in strings for Windows API call GetCurrentDirectoryW, we see it referenced in module stdlib_winleanDatIniti0000 at 0x00411a12. In Nim, winlean is a small wrapper needed for certain Win API procedures, so that the Nim compiler does not depend on the huge Windows module.

We can see this function being run in the _PreMain module only 2 calls nested prior from the entry point:

These likely initialize the Nim environment and set up system variables, some of which are later passed to the binary to determine where to look for cosmo.jpeg, where to place and delete files, and which user’s Desktop background to change. This explains why we don’t see a direct named system call of GetCurrentDirectoryW within the GetCurrentDirectoryW function, and this is instead referencing the memory location of the GetCurrentDirectoryW likely in data.00411b43.

Looking in the same module we see several other Windows API calls we expect to see in the binary:

The above is interesting, we see the same module nimGetProcAddr08 repeatedly called after a different name for a Windows API function is being moved into edx. This is likely dynamic function resolution. The ecx register is likely holding the base address of the module, probably being kernel32.dll. Looking into the _nimGetProcAddr_08 module we can see that it is being passed values such as lpProcName and hModule to resolve the memory address of the Windows API functions.

Looking back at stdlib_winleanDatIniti0000, it’s likely the functions are being stored in the dword values assigned to eax. We can use this to find the function calls when going back through our main module.

Going back to nosgetCurrentDir00, we can see it call dword [0x424444], which we observed above as being one of the memory locations that a function call is stored into. Based on the name of the function and the name of the module, I am assuming this is GetCurrentDirectoryW being called here. We see functions to create a wide string later in the module, which is likely what the output is being passed into.

Next, we move onto nosgetHomeDir00, being called shortly after the previous module getting the current directory. This begins by calling getEnv__hhED57tMl0Iaa5bOg9cJaig@8. Looking through the execution flow, we can see a call to _getenv:

When looking through the x-refs for this called function, we can see that this is calling getenv from the C runtime imports. This is passed to a copyString function, and then we return to the main module.

From here, we move to analyzing wannaHusky__4JhDTDCSrwYIQ19bJbLaL2w@0, what looks to be the main encryption capabilities of the executable.

In the first block of the function, we see what looks to be normal function initialization activities. 0x41bba0 points to what appears to be an uninitialized memory location, and we see several calls to it throughout the function. We see var_558h set to 0, the data in 0x41bba0 loaded into eax via var_4b4h, and a call to __setjmp3. That last function, imported from the C runtime, we can see called in several other functions via the x-refs and is likely a method to set a save point in the program’s execution flow.

Going forward, we can see a jne instruction after a test of eax looking for 0x40de9c. Based on our basic dynamic analysis, my assumption is this might be checking if cosmo.jpeg is present on the user’s desktop. With this assumption, it is likely that some of the unallocated memory references will contain results of the previous functions that checked the environment variables and current directory.

If eax is not equal to the value of 0x40de9c, we move to these blocks. They look to set up some register values and then test if 0x40da22 is equal to 0x424870. If it isn’t, it adds 18 to the value of eax and stores it in ecx.

Here it looks like we are initializing a new string. After that, we first append the string with the value of 0x424870. We then see another operation moving the data within 0x41a0c8 into edx, then appending it to the newly created string. Looking at the data in 0x41a0c8, we can see it is referencing cosmo.jpeg:

My hypothesis is that this is taking the directory of the user’s desktop and concatenating it with the file name, which will be passed to interact with the file.

Later in the graph flow, we see another string being created in a similar manner, this time without a direct reference to a string we can look at. After the string is created and data is appended to it, we observe a call to readFile__404. This is likely getting passed the file path to check if the file is present. Directly after, we observe 0x41a078 being moved to ecx, that memory location pointing towards the string ‘COSMO’. Looking through the next few blocks in the function, I did not see anything super interesting. It mostly looks like variables being initialized and error checking being processed.

We eventually land at digest_CXo4xdrVR0UXF9aOcb9aJFYg_8. This function looks to break up the passed data into 64-byte chunks, copy chunks into the working buffer, and calls @sha256Transform_BJNBQtWr9bJwzqbyfKXd38Q.

Finally, when this is done looping through the passed data, we move to a call to @finish__x70ALeeaQ1ry9a63hdOCQWA@4 and burnMem__4F@8. The digest function included some XOR operations on the blocked data, so likely the key that was used in the XOR is being deleted from memory in the burnMem function.

Looking back in the main wannaHusky function, further down we see a call to _encrypt__dcoBdmUaaCC9cnR23eFxSLAbcmode shortly followed by the same burnMem__4F@8 function.

Inside the encrypt function, we see some conditional checks and two interesting calls surrounded by a loop:

• encrypt__py6wg79aBw8iTzUm11Z7JOA@20
• inc128__vRz5m42fv3XKwSYgATX55Q@8

The second function call inc128 likely is acting as a counter for how many times this encryption function should loop. The first nested encrypt function appears to contain the logic that encrypts the cosmo.jpeg image file. After some error checking, we can see some XOR operations that are likely encrypting the passed data:

Shortly below this, we see further bit manipulation including shifting, combining values, expansion, and more to further encrypt the passed data. 

It appears this operation on the right loops until the following two conditions are not true:

• At 0x0040c0da, if eax is not above or equal to 0x77
• At 0x0040c108, if it is not zero

After this memory is burned, including the generated key that was used to XOR over the data, we see another call to the same encrypt and burn memory function. It doesn’t look like this is utilizing any new key or data, so my hypothesis is that this is XORing over the same data with the same key as some sort of verification function, as XORing over the data twice with the same key should result in the original data.

After that, we see a call to encode__npLRSgmGJDNX8bfurW5iRw@12. This function, at the very beginning of it, looks to load a data string into eax that we can assume is the encoding character set. After this, the function branches out into several complicated substitution decision trees that I am assuming is converting characters that may have been made invalid due to the encryption scheme into ASCII format. I don’t recognize the encoding scheme from looking at the assembly, but I am assuming Base64 is involved as that was present in the CAPA results.

Following this we see several file handling function calls that look to be dealing with saving the newly encrypted file. 

We can see here the file is likely renamed with the .WANNAHUSKY file extension. 

Just below that, we can see the WANNAHUSKY.png ransom note image being created on the user’s desktop as well. Shortly after, the function exits and returns to the main module.

Moving on to the next interesting function in the main module, changeBackground__4JhDTDCSrwYIQ19bJbLaL2w_2@0, looking in this we know what to expect and look for. Right as the function begins, it moves data.00411ea0 into ecx, and when looking at that location, it contains the code we observed within ps1.ps1 during the basic dynamic analysis section. We can see that string copied via a function, then in the next block, we can see data.00411e80 also copied to a string, which happens to point to ‘ps1.ps1’. We see the writeFile function called after moving two variables to edx and ecx, which looks like the contents and the filename of the created file.

In the next block, we can see instructions for the PowerShell command issued to execute the newly created script.

After this, we have some cleanup operations and we jump to nosremoveFile@4, which is likely the function that deleted the created ps1.ps1 file from the desktop.

After returning back to the main function, we see one more important interaction. The string ‘tree C:\’ is moved into ecx from data.00411e40, then passed to another nosexecShellCmd@4 function to run the command. This concludes the execution flow of the program we know and is also the end of instructions within the main module.

WannaHusky Summary

In conclusion, Ransomware.wannaHusky is a benign ransomware sample designed for analysis. It begins by checking the user’s directories for a specific file and proceeds to encrypt it using a custom algorithm, appending a ".WANNAHUSKY" extension. The malware also drops a ransom note and changes the desktop wallpaper to demand payment. Detailed analysis of the binary reveals various interesting behaviors, such as dynamic Windows API function resolution, file encryption with XOR operations, and process manipulation. Through static and dynamic analysis, including CAPA and PE Studio, we gain insights into the ransomware’s execution flow and encryption techniques.

Execution Flow:

The purpose of this analysis is to prepare myself for TCM Security's Practical Malware Research Professional certification I plan to sit in the next month. I wanted to gain a better understanding and iron out my methodology for examining Windows binaries.

Yara Rule for WannaHusky sample

rule Ransomware_WannaHusky
{
    meta:
        description = "Detects Ransomware.wannaHusky sample"
        author = "tresscross"
        last_modified = "2025-01-05"
        sha256_hash = "3d35cebcf40705c23124fdc4656a7f400a316b8e96f1f9e0c187e82a9d17dca3"
        file_name = "Ransomware.wannahusky.exe"
    
    strings:
        $filename = "cosmo.jpeg" nocase
        $extension = ".WANNAHUSKY" nocase
        $ransom_note = "WANNAHUSKY.jpeg" nocase
        $ps1_script = "ps1.ps1" nocase

    condition:
        (filename or extension or ransom_note or ps1_script)) or
        sha256_hash == "3d35cebcf40705c23124fdc4656a7f400a316b8e96f1f9e0c187e82a9d17dca3"
}