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
If this were to be accurately detected, a host check for the creation of either
C:\Ïðî÷òè Ìåíÿ - êàê ðàñøèôðîâàòü ôàéëû.txt would be sufficient.
- IDA Pro Free
- OllyDBG 2.0
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
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.
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.
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.
- SystemParametersInfoA - used to set the desktop background
- 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
- GetWindowsDirectoryA - used to get the windows directory in a portable way
- GetCommandLineA - this Win32 GUI program appears to take in command line arguments
- ShellExecuteA - used to execute open the “Very Bad News” text file and to delete the current executable when disinfecting the system
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.
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.
- sub_401000 -
void EncryptDrive(LPSTR driveBase)
- sub_401263 -
- sub_40140D -
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.
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.
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.
The malware is not persistent and does not modify the registry in any way.
The malware creates three key files:
- The background image in the temp directory
- The crypto log in
- 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.
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 (firstname.lastname@example.org or email@example.com).
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:\Ïðî÷òè Ìåíÿ - êàê ðàñøèôðîâàòü ôàéëû.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