Macro malware arrived with a bang 21 years ago, and it's still causing problems.
Concept, the first ever virus to spread by infecting Microsoft Office files, turned the anti-virus world on its head overnight when it was shipped by Microsoft on a CD ROM in August 1995.
Up until then the main thing computer users had to worry about was malware hiding in .EXE or .COM executable files, or in the boot sectors of floppy disks. Now you had to be wary of Word documents too, and the risk was heightened when you recognised that exchanging documents in the office was a much more regular behaviour than sharing executable code.
It didn't take long for macro viruses to become the most commonly-encountered type of malware on the planet.
It would be nice to think that in the decades since macro malware has disappeared as a threat, but the truth is that the problem remains as
Microsoft's own research reveals. Indeed, Microsoft claims that 98% of Office-targeted threats use macros.
It's clear that the way forward is to block malicious macros. If you can control the macros you can control the threat.
In March, Microsoft took a positive step in helping enterprises who run Office 2016
block macros from loading in certain high-risk scenarios. And yesterday, Microsoft announced that the feature has
also been made available to companies running Office 2013.
Let's look at a typical attack scenario to see how Office 2016 and Office 2013 can better protect your users.
Imagine one of your users receives an email with a malicious Word document attached. Typically there will be some social engineering at play to trick the user into opening the attachment - in this case the email claims the attachment is an overdue invoice for a recent purchase.
Opening the attachment in Microsoft Word is possible, but because the email has arrived from outside the company the attachment is not inherently trusted. A sandboxed environment known as "Protected view" is used - allowing users to read the document's contents, but disabling macros and other potentially malicious active content. Editing of the document is also disabled.
This, of course, is not going to faze a determined cybercriminal. They have anticipated that their intended target will be defended by Microsoft Office's "Protected view" feature, and have incorporated a message into their document to trick users - via
social engineering again - to "Enable editing" and thus re-enable any malicious macros they have included in their attack.
Contents of this document are protected. To view this content, please click "Enable Editing" from the yellow bar and then click "Enable Content"
In short, the attacker is telling his or her victim to disable Microsoft's built-in defences, giving free reign for the malware to execute.
It's all too easy to imagine many users falling for a trick like this.
However, Office 2016 and now Office 2013 provide an additional layer of protection. Enterprise administrators can roll out group policies which forbid users from enabling macros in Word, Excel, or PowerPoint files originating from outside the company - even if they are duped into trying by a cybercriminal's shenanigans.
BLOCKED CONTENT Macros in this document have been disabled by your enterprise administrator for security reasons.
Although most people will probably barely notice if Word documents and Powerpoint presentations have their macros disabled, it's clear that challenges still arise when it comes to Excel spreadsheets - which can frequently contain legitimate macros, and which may be being frequently received by some departments from parties outside the company.
My advice to Office users is that alongside your conventional layered defences, you should enable all of the Protected View options in the Trust Center and turn on Data Execution Prevention (DEP).
Within businesses you should seriously consider applying a group policy to block macros from running in Office files originating from the internet. Details of how to enforce such a setting through group policy is
explained on Microsoft's website.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc
Save
Save
