Introduction

On the 7th of February, Microsoft announced an impending change to its ubiquitous suite of Office apps. In Microsoft’s own words: “VBA macros obtained from the internet will now be blocked by default”. The change is expected to begin rolling out in early April.

Technically speaking, VBA macros were already “blocked by default” before. Upon opening a document containing such a macro, the user would be greeted with the following prompt:

And upon clicking this single button, Macros would be enabled. Following this change, for files that originated in the internet, the user would instead see this prompt:

The “learn more” button leads to a short article where Microsoft explains to the end user that macros “are often used by people with bad intentions to distribute malware to unsuspecting victims” and “aren’t required for everyday use like reading or editing a document in Word or using Excel workbooks”. Most importantly, the article stresses, “no legitimate company will make you open an Excel file to cancel an order and you don’t need macros just to read a document in Word”.

After all these admonitions, if the user is still interested in running the offending document macros, Microsoft provides a 4-step process under a collapsible. The process involves manually saving the file to the hard drive, then digging inside the file properties and explicitly clicking a checkmark box titled “unblock”.

The Rise, and Fall, and Rise, of VBA Malware

This decision did not come about in a vacuum. Starting in the early 2010s, macros in MS-Word documents slowly gained ground and eventually became the most popular vector of infection for the average cybercriminal peddling commodity malware. This rise in popularity was preceded by a long and unusual history: in fact, like the cure for scurvy, VBA malware had to be discovered twice – having been forgotten and become lost to history after the first time. 

The first load-bearing document was a proof-of-concept created all the way back in 1994, during the stone age of POGs, Power Rangers, the Clinton Administration and dial-up internet. Up until then, it was common knowledge that to get your computer infected with a virus, you needed to run an executable file. Joel McNamara, a researcher, created a proof of concept that broke this mold: the first document macro virus, which he called DMV. He kept this innovation secret.

Not long after, in 1995, an unknown inventor replicated the feat with “Concept”, a macro virus that ran so rampant that by late 1997 it reportedly accounted for half of all virus infections, and infamously made it to Microsoft-issued utility CDs and press releases. “Concept” was thankfully harmless; it just generated a strange dialogue box and, hidden in its code, contained a poignant message: “that’s enough to prove my point”. This outbreak probed McNamara to come out of hiding and publish his findings (a manifesto he published on the subject, “Yes, you can spread a virus with a data file”, has been preserved online).

Figure 1. Piece of source code from “Concept” worm.

With the success of Concept, it was only a matter of time until someone would wield this new-found weapon to do something more destructive. Such was the case with the Melissa Worm, an overblown sleazy prank by Some Dude from New Jersey who in 1999 created a self-replicating word macro – coupled to a document which ostensibly contained a list of pornographic site logins and passwords – and unleashed this creation on the unsuspecting patrons of the Usenet newsgroup alt.sex. Upon activation, the virus emailed itself to the first 50 people in the victim’s contact list. This generated enough traffic to grind networks and web services to a halt, eventually causing a reported $1.1 billion in damages. The virus creator gained nothing from this entire ordeal except probably a huge, idiotic grin, which must have gone away when he was apprehended and sentenced to 20 months in federal prison.

Figure 2. A rare photograph of the Melissa Worm in the wild (1999, colorized)

This was the peak of the first VBA malware golden era. Following the turn of the millennium, VBA malware quickly declined in popularity. Cybercrime turned a corner and became a profitable industry, rather than an arena for pranksters to show off their m4d sk1llz and obtain bragging rights; and cybercriminals quickly found out that, strictly speaking, with VBA macros you can’t record victim keystrokes, intercept traffic or steal juicy credit card details. The functionality just isn’t there. 

The final nail in the coffin came in 2010, when Microsoft introduced “Protected View”. This is that yellow ribbon you saw earlier which warned that the document “might be unsafe” and required users to click “enable editing” in order to run the macro. What is VBA good for, anyway, cybercriminals thought to themselves – we have to convince victims to press a yellow button that says “enable editing”, and if we manage that, we can make their machine pop up a funny dialogue box? Thus began the long, supreme, and still-ongoing reign of C language as the de-facto standard tool of creating malware. For a few years, VBA malware faded into almost-total obscurity.

The end? Unfortunately not.

Several factors conspired to bring VBA malware back from the brink of extinction. First, basic security awareness among the average user improved somewhat. By 2012, even the most technophobic user had had it drilled into their heads twenty thousand times that they shouldn’t just run executable files they got in the mail. This pressed cybercriminals into a disadvantageous position, enough that they eventually began pondering, actually, why can’t we make VBA malware work?

Figure 3. This infamous application (frog.exe) is the way many users found out about the dangers of wild executables the hard way. 

Following a moment’s thought, they realized that while you can’t write complex code that intercepts victim web traffic in VBA, there is no actual need to do that. Just make the document a thin application that fetches the main C-written binary from an attacker-controlled server, then executes it. Once this insight was obtained, attackers were left to contend with one final snug – that “enable editing” ribbon.

Some turned to common vulnerabilities to bridge that gap. CVE-2010-1900, CVE-2010-3217, CVE-2012-0182, and others became common tools of the trade that completed an infection chain the moment a victim opened a malicious document with a vulnerable version of MS-Word, with no need for any further user interaction. This tried and true method sadly remains with us to this day, but still, for some cybercriminals, it didn’t feel like enough. After all, a vulnerability is either publicly known and therefore potentially patched on the victim machine, or not publicly known (0-day) and therefore so costly to procure that the typical malicious campaign won’t even cover the expense. Cybercriminals tossed and turned in their sleep, dreaming of a golden vulnerability that can’t be patched. Unfortunately for us all, they found it.

CVE-0

In 2011, Kevin Liston posted the following to the SANS institute’s Infosec Handlers Diary Blog:

This is of course tongue-in-cheek, but has a certain terrifying truth to it. At some point, it finally occurred to cybercriminals that they could possibly get users to click the “enable editing” button by asking nicely. They then tentatively sent emails to potential victims containing images like this one, which have since become iconic:

Figure 4. Some of us occasionally see this image in our sleep.

And users took the bait by the tens of thousands. You can “educate” and admonish them as much as you like: in the moment of truth, when they are sent what appears to be an invoice or urgent court summons, many will see all the dialogue boxes and meek yellow-colored warnings as annoying obstacles to be cast away with prejudice. A new golden age of VBA malware had come.

Playing Whack-a-Maldoc

The deluge of documents with CVE-0 exploits was not only alarming, but also uniquely annoying. The field of information security is full of difficult, intractable problems – and these documents have the nerve to barge into the malware landscape shouting “hello yes, I am here to manipulate users to run malicious code”. They are capital-O Obvious. You know them when you see them, and usually the verdict takes less than half a second – and that’s with your squishy, puny human brain. We have computers that can process gigabytes of throughput per second. How is this even a problem?

With this in mind, since early 2015, Check Point Research has conducted the OSEF project (Office Social Engineering Finder) to automatically collect, catalog and block the increasing deluge of these documents. While this is not the place to go on about OSEF at length, we would be remiss not to briefly go over its findings. In total we came across hundreds of thousands of malicious documents, mostly downloaders for the Emotet malware, many of which had 0 detections at VirusTotal at the time of discovery. Really, if we started telling strange OSEF stories, we wouldn’t stop. Probably the most outrageous incident involved an apparent spear-phishing attempt targeted at users of Check Point Capsule docs, which made us lose our collective composure until we realized it was actually a mock malicious document from our very own CSA course that an errant student had decided to upload to VirusTotal – our own inside joke had gone full circle for us to find. 

Figure 5. Telling victims to “enable editing” is an art, and the second golden age of VBA malware was blessed with some true artists.

Most importantly, we ran into ample evidence that many cybercriminals knew what we were doing. Many of the “enable macros” images were subtly tampered with, just enough that an OCR engine failed to parse them properly, while they still appeared perfectly normal to the human eye. For instance, this completely readable image:

Produced the following marbles-in-mouth output when put through an OCR engine:

To counter this, we began to pre-process incoming images – converting to grayscale, applying threshold effects, and so on. We also allowed some “fudge factor” in the input (so that a slightly mis-parsed “enable adiling” would still match). Jointly, these two measures caused significant improvement in the detection rate. We were amused to note that to make the attack work while bypassing our scrutiny, attackers found themselves trying to create an image that humans could parse successfully, but automated algorithms could not – in other words, a CAPTCHA. We took some heart in the knowledge that, given what we know about the state of the art, this was probably a losing game for them.

Figure 6. Seems legit.

So that’s all well and good, but back to the original question: if these documents are so easy to identify, how come they are still such a widely-spread pestilence? The answer is multi-layered and complicated, and we won’t bore you with an elaborate flow-chart of every single possible mitigation and why it’s only a partial solution. Instead we’ll cut straight to the final, most fundamental issue: What about 17-year-old Jessica, who has no firewall, no CISO and no security policy – just a free antivirus? The manipulation isn’t obvious to her. Her free antivirus doesn’t feature sandbox emulation, and its static signature matching probably won’t detect the malicious document on its own. So how can we protect her? It seems clear there is only one universal and effective point of intervention: some piece of software involved with the infection chain should sound the warning, such as MS-Word or MS-Windows. At this point, you might notice that all these effective points of intervention have a common factor among them. To put it bluntly, it was up to Microsoft to fix this, and they finally did, so good on them.

Figure 7. The Microsoft intervention, as we had envisioned it in the 2019 talk “Disable ‘Enable Macros’: Shutting Down Social Engineering with OCR”. Sometimes dreams do come true.

How do I Protect Myself / My Organization from this Threat?

Again, the mitigation Microsoft introduced here is aimed at helping the average user, not the hyper-security-aware. Advice for the infosec-savvy has been the same for a while now, and mostly boils down to the warning in the image above. If you need to worry about a whole organization of potential targets, the option to block these macros via site-wide security policy has existed for a long time now, and the nearest security vendor is – of course! – always glad to assist further. Sandbox emulation, especially, is a great tool for detecting these download-and-execute macro documents early. Alternatively, some security solutions will pulverize incoming documents and rip out the macros before they ever reach the targeted user. Ask your security vendor about these features, which are also available in Check Point’s Threat Emulation and Threat Extraction products.

Is it Over? Are We safe?

We wouldn’t fault the reader for doubting that this single mitigation, of coloring a strip red and making the user jump through some scary “Are You Sure” hoops, would really eliminate the threat. If the lucrative industry that sprung around these documents has any say in the matter, it would surely rather find twenty different bypasses for the mitigation and carry on as before.

There’s a strain of infosec thought which states that mitigations are fundamentally useless. There is always a bypass, and there will always be a sufficiently well-motivated and well-equipped threat actor to make use of it. The industry invented hash detections and got polymorphic malware; invented DEP and got ROP. According to this school of thought we shouldn’t rejoice here, but rather wearily ask ourselves, “what are we going to get this time”.

While tempted by this cynicism, we’re not so sure we agree with it fully. Some of you may remember Dton, the prolific Nigerian spammer whose escapades we detailed in this blog, and who raked in an exorbitant profit mass-sending people the exact low-tier VBA malware described above. Dton raged and seethed with every single penny out his pocket that had to be spent on packers, VMs, Trojans and other tools of the trade; can you imagine his face after being told that actually, vanilla VBA malware doesn’t work anymore, and he has to pay an additional $300 fee for an annual subscription to ‘MS Document Macro Block Bypasser Plus’? For the Dtons of the world, maybe this extra hassle is the final straw that makes some of them say “forget it, I’ll apply to be a sysadmin”. We can only hope.

 

Check Point’s Threat Emulation and Threat Extraction provides protection against any weaponized documents