It’s time to secure Microsoft Office

This week in the office my systems have blocked 150,000 malicious Office documents. All have Office macros attached, or OLE objects. The 90s never finished as attackers learn to automate attacks using Office and old technology. If anything is a sign that the security industry needs to shift up a gear, this is it.

What’s more is these attacks work. Left is my own research, where I’ve been intercepting a Dridex supernode and mapping live infections in the UK — to the left is the UK alone during lunchtime in one day on one botnet. Tools like Dridex can man-in-the-middle attack secure banking solutions, allowing attackers to transfer money out of bank accounts hidden behind two factor authentication — including smart cards — by putting the attackers inside your browser.

If all that stands between your internal network and an attacker is trusting antivirus software to work and the user not clicking “Enable macros”, you’ve got a big problem.

“What the ‘Enable macros’ option should say”

Let’s do something about this

First of all, if you think disabling all macros across the company isn’t practical, congratulations — you’re probably paying attention to what your users do. It’s true, lots of organisations rely on legacy code nobody really understands and that’s just the business reality. If you just kill macros one day, Finance will riot.

Sure, you could train you users to sign macros — and if you can do that, go for it. If that would take you months due to reality, read on.

Secure differently.

Dig out this Group Policy setting, under Trust Center:

Set it to “Disable all except digitally signed macros”.

Now have a scout around Trusted Locations:

User Configuration/Administrative Templates/Microsoft Office XXX 20XX/Application Settings/Security/Trust Center/Trusted Locations

Set your shared folder location URL in here, e.g. \\blah.local\public\office

More info is here.

Now instruct your users to make sure all macros are used from shared folders. For finance, they aren’t even going to notice a change. Macros will just work as before on their regular documents.

If Mr. Bad Guy emails Joe in Accounts Payable a Bad File, the macro won’t run. The user won’t even see a prompt to enable the macro, nor can they from the Office options.

But wait — what if they save the dodgy email attachment to the network and open it? Yes, it’s a risk. It’s a much, much smaller risk than before.

Real world experience tells me this is extremely effective, and take about an hour to test and implement in a large enterprise.

Going further — ole ole ole

Regular readers might remember my post about OLE Packager.dll, which allows executable code in Office documents, with no interface way to disable to functionality. This feature is historic, dating back the early 90s, and still exists in the latest Windows and Office versions. Since that post security vendors appear to have done very little — in testing with some leading enterprise grade anti-exploit products, nothing I’ve found so far stops it. Additionally, when saved as .msg and .rtf files they still sail past most cloud based mail filtering companies.

Ultimately I’m confident Microsoft will re-examine the functionality as it is going to be a key battleground in the coming Ransomware Wars(tm)(r).

In the meantime, set the following registry key (it varies slightly for 64 bit Office, by the way) for some protection in Outlook 2000/2003/XP/2010/2013/2016/365:

For other Office applications (yes, you can do the bonkers here in PowerPoint..) try this EMET ASR protection:

<Mitigation Name="ASR" Enabled="true">

Please note that breaks some third party products, e.g. Symantec Enterprise Vault — so you want to test.

If you don’t know what EMET is, it’s worth checking out, and other vendor solutions are available. EMET is also free. It’s particularly good if you don’t have time to patch properly (and before security peeps shout at me that of course organisations patch, the reality is different — for example the latest RAT impacting a wide array of western financial organisations is LatentBot, which is delivered via issues in Office where patches have existed for 6 years — you need multiple layers of security).


Did you know when a user opens an OLE Packager object, Office logs an event?

More events are there, and in Office 2016/365 you get extra snazzy events to play with. Explore.

You can schedule tasks against events in Windows, and then trigger email alerts. I will detail this in a future blog post — aside from alerting against Office you can, for example, trigger email alerts when new services are installed on your servers. This can give you a huge head start to attackers.

Since Windows 7 and Windows Server 2008 it’s also been possible to forward certain events to remote servers, which allows you to form a desktop and server event manager — for free. Checkout WEF.

Finishing up

Your end users are the new DMZ, and it’s way too easy to get there for a bad guy. Much like your network team (if you have one) wouldn’t let you bung an IIS server straight onto the internet, you shouldn’t allow your users to live in the 90s by installing XYZ Antivirus, Office and a firewall. Look at some basic Group Policy, think about maybe EMET and AppLocker, look at 3rd party solutions. If you don’t, you might as well plug those IIS servers into your internal network and the interwebs — it’s probably less risky nowadays.

Microsoft have done some amazing work in the past ten years around security technology in the OS — I encourage you to check out Windows 10, for example — but there’s still work to be done. And that includes by you, fellow person.

Talk soon.