Author’s note: this report was written by me for Practical Malware Analysis (CAP6137 spring 2016) at UF. It’s written in a role-playing fasion.

Our team at Skynth Security has discovered and analyzed a new ransomware sample categorized as W32.VeryBadNews!Ransom. Upon execution, it changes the desktop background to an extortion image asking for money and it encodes important user files with a fixed Xor key. It logs all encoded files and pops up a notable message in notepad: “Very bad news”.

Unlike more sophisticated ransomware, this malware does not actually encrypt files in a cryptographically sound way. Nor does it randomly generate a key or public-private keypair for per computer encryption. It uses a fixed Xor key that is used for encrypting and decrypting all files.

The best part is that the malware author included a routine for decrypting the file system as well. Using the command line argument rafgapnkucmghgklmgtiftqgtswqtrim, the malware will read the CryptoLogFile and decrypt any file path present in there.

There are no significant obfuscation methods besides some strange repeating strings. The binary is quite easy to read and is not packed. It is apparent that is traversing the file system due to the imports FindFirstFileA, FindNextFileA, and GetLogicalDrives.

If this were to be accurately detected, a host check for the creation of either C:\Windows\CryptLogFile.txt or C:\Ïðî÷òè Ìåíÿ - êàê ðàñøèôðîâàòü ôàéëû.txt would be sufficient.

# Tools Used

• PEiD
• PEView
• IDA Pro Free
• OllyDBG 2.0

## Packing Investigation

The program is not packed in any way. There are some strange strings (“mmmmmm…mmmmm”, “zipeeeeeeee…eee”) in the file, but these are most likely manual obfuscation by the malware author. There are no references to LoadLibrary or GetProcAddress, nor are there any strings referencing these library functions. This would imply that there is no runtime loading of functions or libraries. With this in mind, we can be sure that the Import Address Table (IAT) is intact and contains all of the actual imports.

We used PEiD to do a typical packer scan using the “aggressive” option. No packer were found. An entropy check was also performed and it appears that the file does not have an entropy value typical of packed files. Finally, the Entry Point was manually inspected using Ida Pro and there didn’t appear to be any stub or loader to unpack the rest of the file.

## Compilation Date

This program was compiled on Friday 22:10:159 UTC, 10/09/2009 as shown by PEView’s output

This compilation date could be used to correlate infection rates across the globe and help narrow down the place of origin.

## Program Subsystem

The program subsystem is Windows 32 GUI. This means no console window will be automatically spawned and associated with the process. Also, just because it is a “Win32 GUI” program doesn’t mean that it has to use a GUI. In this case, it merely spawns in the background, performs work and exits.

## Program Imports

### USER32.DLL

• SystemParametersInfoA - used to set the desktop background

### KERNEL32.DLL

• CreateFileA - used to open files for reading or writing
• DeleteFileA - used to clean up malware created files, such as the CryptoLog
• FindFirstFileA - used to recursively enumerate files
• FindNextFileA - same as above
• GetLogicalDrives - used to enumerate all system drives (A:\ to Z:) for victim files
• ReadFile - used to read in victim files for encoding or decoding
• WriteFile - used to write out encoded and decoded files. Also used for writing out the background.bmp hidden resource
• GetWindowsDirectoryA - used to get the windows directory in a portable way
• GetCommandLineA - this Win32 GUI program appears to take in command line arguments

### SHELL32.DLL

• ShellExecuteA - used to execute open the “Very Bad News” text file and to delete the current executable when disinfecting the system

## Strings

• 00403005 - open // used by ShellExecute when opening the .TXT
• 0040300C - TMP // references the TMP environment variable
• 00403010 - \CryptLogFile.txt // the list of encrypted files
• 00403022 - \wallpaper.bmp // the background extorsion image that is set as the background
• 00403058 - 1:<non-printable>.txt // the name of the “very bad news file”
• 00403070 - rafgapnkucmghgklmgtiftqgtswqtrim // the hidden decryption trigger string
• 00403095 - .doc.xlsdocxxlsx.db.mp3.waw.jpgjpeg.txt.rtf.pdf.rar.zip // the list of file extensions searched for by the ransomware
• 0040310D - Very bad news… // the famous indicator string
• 0040330D - ComSpec // the environment variable used to get a path the the terminal for execution
• 00403315 - /c del » NUL // argument to a launched cmd.exe script

• Identify the program section(s) and possible contents.

• .text - contains malware code in its entirety
• .rdata - contains the IAT and all other import information
• .data - contains the malware strings and other byte buffers
• .rsrc - contains the program’s Icons. There is also a “hidden” resource, which is a bitmap image appended to the end of the original executable. This is not visible from PEView.

## File Encryption

An investigation of the file encryption and decryption routines reveals that the malware is merely Xor encoding file contents using a fixed 16 byte Xor key: 0C9h, 93h, 6Bh, 0CAh, 0DFh, 0BFh, 0C0h, 61h, 46h, 49h, 33h, 47h, 46h, 0AEh, 8Fh, 0CCh. This is not encryption and is a far cry from the “AES-256 encryption” mentioned in the desktop background.

This encryption can be easily reversed by merely re-xor’ing the encoded files. A simple decryption program could be written in a few lines. Luckily, the malware author(s) were nice enough to already provide this functionality.

## Notable Functions

• sub_401000 - void EncryptDrive(LPSTR driveBase)
• sub_401263 - void XorGlobalData()
• sub_40140D - void DecryptFilesAndCleanup()

# Dynamic Analysis

Regshot was not used as extensive static analysis was done with IDA Pro. OllyDBG was the sole tool used to run the malware and change its execution state.

## Notable Behavior

Upon execution, the desktop background changes to a message asking for “100\$” to be sent to an email address. It says all of the system’s files are now encrypted. At the same time a notepad window with “Very bad news” written writen in it (and a strange title) pops up. Upon inspection of a planted .TXT file, it appears to now be “encrypted”.

From this point on, nothing further happens and the malware exits.

## Network Usage

The malware does not use any network based functionality. It relies off of the user to manually send money to the malware authors and for the malware author’s to manually remove the infection. Quite primitive compared to sophisticated ransomware.

## Registry Usage

The malware is not persistent and does not modify the registry in any way.

## Changed Files

The malware creates three key files:

• The background image in the temp directory C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\background.bmp
• The crypto log in C:\Windows\CryptLogFile.txt
• The “very bad news” file in the primary drive (usually C:\)

It also “encrypts” all files on every drive matching these file types: .doc, .xls, .docx, .xlsx, .db, .mp3, .waw, .jpg, .jpeg, .txt, .rtf, .pdf, .rar, and .zip

The files are changed in-place. They are completely read in, xor encoded with a fixed key, and rewritten back to disk.

## Process Creation

This malware starts notepad.exe through the use of ShellExecute when initially run. This pops up a message to the user that the malware has “very bad news”. Additionaly, when the malware cleanup routine is executed, it launches a command shell to delete itself. It gets a path to the command shell using the ComSpec environment variable.

# Indicators of Compromise

There are no network based indicators of compromise beyond watching the malware be downloaded or an email being sent to the provided email addresses (zanoza@safe-mail.net or tooter@safe-mail.net).

There are quite a few unique host based indicators. The ransomware enumerates and interacts with all drives and all files of the types listed in the “Notable Behavior” section. This is quite noisy and could possible detected by endpoint protection.

Some more concrete host-based indicators would be the creations of the “very bad news” file or the CryptLogFile. Checks for the files C:\Windows\CryptLogFile.txt and C:\Ïðî÷òè Ìåíÿ - êàê ðàñøèôðîâàòü ôàéëû.txt would yield very accurate host based detection.

# Disinfection and Remediation

Disinfection of this malware is quite simple as it proves the disinfection function within the executable. Once a computer is infected, the malware stores a log file of all the infected files. This allows the malware to decrypt the affected files once the malware owner receives payment. Fortunately, no payment is necessary as there is merely a hardcoded string required to be passed as a command line argument in order to decrypt the files. The malware exe should be called with the first argument being rafgapnkucmghgklmgtiftqgtswqtrim instead of the path to the actual exe file. This will only work if the CryptLogFile doesn’t already exist.

Also, a special trick could be used that is less reliable, but would work even if the CryptLogFile was removed. If the files are in an encoded state, reinfecting the machine would “undo” the infection due to the properties of the Xor encryption used by the malware. The issue with this method is that any new files that were created after the initial infection will be encrypted, while the old files will be decrypted.

Author’s note: no online resources were used when writing this report