>>Good morning everyone, thank you for being here so early to listen to me talk about Microsoft Office of all things. Uh, there’s a lot to get through and I hope that you learn a lot um but even if you don’t at the very least, I do hope that your budget application for coming to Def Con was helped by being able to say you took part in Microsoft Office training. [laughter]


That is a little bit of a joke but at the same time, there’s a lot of truth to that because this talk is effectively about how we as attackers can be better at using Microsoft Office, how there’s a lot of legitimate functionality to extend what Office can do um including execute arbitrary code um and that’s somethings as attackers which we can abuse for uh purposes such as maintaining persistence on compromised work stations.


So, in terms of the motivation for doing this research, ah the first one was that Microsoft Office is so ingrained in the workflows of um a typical business user that if you compromise a random workstation, you’re almost certainly going to come across Micro- across Microsoft Office. That means if you persistence techniques that use Microsoft Office, they’re going to have a very wide application.


Another thing was, I wanted to follow on some research um that was popularized in the past couple of years in part by a colleague of mine at  MWR Costos  um but also um around the same time by Matt Nelson and that was on the topic of Office template. So if anyone isn’t familiar with this, essentially um all documents that you create with Microsoft Office maintain a reference back to their original template and if you put a macro in that original template, when you -op when you open up a document, uh that reference will actually get followed and that um halo, that macro will -will get executed.
Now these templates are stored in trusted locations. Uh what this means is that trusted to be exempt from normal macro policy. So even if you disable macros without notification, um documents that exist in within these folders such as the templates ah the VBA, the macros will still get executed.
Uh, now when looking at these, some of them are very cleared marked as being for the purposes of templates but others are being marked as for startup and that got me wondering “What’s the difference between the two? What does Microsoft want us storing here and how can we potentially use that?”
So one of the things I came across was, Word WLL files um and it turns out these are basically just DLL’s uh which export particular functions which can be used to extend what Word can do. Now if you look online for how to create a WLL file, what do these functions need to be called, do they have to be implemented in a specific way? You won’t actually find a huge amount of information uh and it turns out that one po -potential answer for this is that they were actually developed for Office ’97 um but despite this they still supported in modern office versions.
Um, so in terms of uh for what we need to do, um what, you know what are these functions that we need to export. Ah, it actually doesn’t really matter. What you can just do is create the DLL, uh stick your payload in the DLLmain function, a you don’t actually need to export anything. All you need to do is rename the file extension from a DLL to a WLL so one letter change. Drop that in the startup location for Microsoft Word and uh Word will actually arbitrarily load that DLL for you and you can get code execution that way.
One interesting thing about the way that Microsoft would treat WLL files is that ah it doesn’t actually list them as active add-ins which is something that those involved in defense should be aware of. Um, I think this potentially could just be because um, the correct functions aren’t being exported in order for it to identify it. Um but regardless it –it works for the defense purposes. Excel also has a an add-in, XLL, as is considerably more updated. The software development kits were released in 2007 so only 10 years ago. Um, you do have to export the right functions in an XLL add-in. Um, this one specific function that you have export called Excel Auto Open and when Excel starts up, it will check the startup location for any files in there. It will see if it’s export this function and then it will call that so we can get arbitrary code execution through this way as well. 
 
A couple of curious things about the way that Excel treats XLL add-ins, the first is that um Excel doesn’t seem particularly concerned about file extensions for anything in the startup location so you don’t even need to rename your DLL to an XLL, you can call it a .txt file or if you want, you can have no extension at all. Um, Excel seems to just fingerprint all the files, see if it understands them, and then will um load them up, uh load them anyways. Another thing is there is this particular registry key uh which you can see there and then it has a particular property which you can create um called OPEN. Ah so the value is open and you can have multiple of these open and then an integer um and then the value of this. If you specify the /R switch um and then the absolute path of a XLL add-in um you can actually load XLL add-ins from outside the started trusted location. Um and that doesn’t give any warning prompts to -to users.
So just a quick a demonstration of this. Um, so if we open up Excel we can see that nothing um gets executed. And if we go into the Options going to the Trust Center and look at the trusted location. So we can see for the user startup location, so this is for our user, this doesn’t require any administrative rights, it’s in the roaming profile which is good for persistence in transient environments. Um, Microsoft Excel Excel Start. So we got this .txt file on the desktop and if we check that with Dependency Walker we can see it’s actually a DLL file cause it’s exporting a -a function called Excel AutoOpen, you see that there. So what we need to do is copy this into the startup location. So if we go into AppData which takes us into the roaming profile then Microsoft Excel, Excel Start, copy that in, um it, Excel should load this DLL which in this case um just spawns a count. Um…
[Applause]
So if we, if we delete that file now so it shouldn’t um shouldn’t execute because it’s not there. Ah, so just to show the –the registry variant and the there’s no sort of security warnings for that, there’s this .rec file which creates the property that we just saw before, the open property /R and then the absolute path to an XLL file on the desktop. One thing that I forgot to mention, was that if you’re if you’re doing the registry method file extensions do matter so it needs to be XLL or DLL um but there we have uh the registry key being created and then again when it uh opens it executes. 
So it’s possible to create VBA add-ins as well. So VBA of course is the language of macros. The way that you create them is pretty much the same as the way that you create a macro document. Um, you open Excel, you open the VBA editor, you stick your macro in. Um, the difference comes when you go to save it, um if you drop down the list of supported file types, somewhere near the bottom but not quite, there’s actually something’s called Excel um add-in which has an XLA or XLAM file extension um and if you ah basically save it as this format which is just a an Excel document without any associated spreadsheets, and drop it in the um startup location for Excel, that will get executed when Excel opens in the same way that we’ve just seen.
PowerPoint has the same sort of thing, ah different file extension, same way of creating. Ah, one difference is that you do need to indicate PowerPoint for a registry edit that it needs to load it um so you create a particular key-in that has a couple of properties such as AutoLoad, you set that to a value of 1 which means uh load at startup and then you’d give it a path which is just a file name, um but that um and then PowerPoint will know itself to check in the startup location for a file of that name.
Now a lot of the -or all of the add-ins I talked about so far involve basically dropping something into um the startup location. Another form of add-in which is sort of slightly different in terms of the way that you deploy it uh uh those add-ins which are based on COM. Um so for anyone that  isn’t familiar with COM,  Component Object Model, this was a technology developed in the early 90’s by Microsoft. Ah, and basically it’s to create uh a sort binary interface standard so you can create reusable software components which can be interactive within a language independent way. Um I guess the non-Wikipedia definition is you create something and as long as you know how to interface with it, you don’t really need to know how the innards are implemented. Um so these are used all over Windows um, you know Windows, modern Windows operating systems are still very reliant on COM.
Um, these COM objects and you can use these COM objects as add-ins for um Office programs. In order to do that you have to implement a particular software interface called the IDTExtensibility2 Interface. Ah and basically that involves implementing a series of uh 5 methods which basically act as event handlers. So one of these for example would be um On Connection which executes code when um the COM object is loaded as an add-in into the Office application which is very useful but you could do more interesting things if you wanted to. So for example, because COM , COM add-ins you can basically create them so they’re portable between all Office products. Um you could have one for Outlook for example which only executes code when an email is received, is received with a particular string in the body.
In terms of the way that we actually go about registering them- using these add-ons uh add-ins, once we created them, um it becomes sort of a little bit problematic and sort of a little bit mysterious and I felt that it was best to explain through an example. So for anyone that’s done COM programming before, you’ll note that you sort of register them normally using such tools as Reg ASM ah which requires administrative rights. Uh, basically the reason for that is because these tools write directly to the place in HKey classes root in –in the registry where COM registration information lives. But this information is just derived from other information from part of HKey Current User and HKey Local Machine ah which actually gets synchronized when you lock out. Um and one of those hives, HKey Current Users we, we obviously have um write access to so if we manually register COM objects, we don’t need administrative rights.
So, just to show you a very sort of simplistic example at a very stratospheric level, if you look up at the top here, this is sort of creating a key calling InconspicuousComAddIn dot connect. Um, and that has subkey CLSID with a default value of a GUID. And that GUID has its own key ah in the green section with various bits of information associated with it. Um, and you know not important really to understand what –what all of them are for our understanding but this line here is particularly important Codebase. Ah so that points to um the file on disk which is actually implementing this COM object. So we have a name that’s associated with a GUID and that GUID is somehow mapped to um the –the file on disk which implements it so then we can basically go down to the bottom bit which is the application specific registration so telling the application to use that COM object um where we can basically just say, “Use this friendly name,” um and then Windows does the mapping back to the actual COM object on this. So this way we can uh using COM objects, we can create cross application add-ins um which are very portable and don't require administrative rights.
Another form of add-in ah based on COM is for the VBA editor. So these are add-ins which don't execute when you open a document um but they execute when you open the VBA editor so whenever someone comes to look um at the VBA code itself at the macros, um or edit them, that's when it gets executed. So it gets executed when the VBA editor loads. Um, does it really have a huge application but uh perhaps one of my favorites. Um, the way that you register these is basically the same as what I just discussed. You register it with windows like the first 2 boxes and then it's only the application specific bit at the end which is different. So in this case, um creating a –a key which has this sort of uh the name of the COM object and then it's got various properties associated with it such as load behavior which means load it when um when the VBE editor starts up.
Another form of add-in um is sort of specific to Microsoft Excel is called the Automation add-ins so if you open up Excel now, and you –you look at the support list of supported add-ins, you'll see that  it distinguishes between COM add-ins and automation add-ins ah but really automation add-ins are also based on COM. Um, the difference is that they don't implement the IDTExtensibility2 interface. Um, I should mention as well that uh VBE add-in also implements the IDTExtensibility2 interface so the COM add-ins and the VBE add-ins kind of more or less the same thing whereas this automation add-in say for Excel are slightly different ah because you don't need to implement that interface. Ah, basically you just define um public functions in the COM objects, ah and those public functions become user defined functions within umm Excel so uh you can have a formulae for example which is equals calc and it spawns calc or inject shellcode into the memory of another process or whatever you want it to do.
Again, registration is exactly the same in terms of what you do with Windows. The difference is when it comes to um the application specific bit and again we see a reappearance of the open registry key property only this time we're using the /A switch and then we're giving the uh, the name of the COM object and then Windows sorts everything else out for us.
So a lot of the stuff I've talked about so far is using technologies that have been around for a while, what is Off-, what is Microsoft pushing at the moment in terms of add-ins. One of them is Visual Studio Tools for Office. This, despite the name is not something which is specifically for developers, um it's just I guess you create a template in Visual Studio. It's a bit of a strange name. Um, basically this is a crux application add-in which is supposed to be a –a replacement for COM add-ins. Uh, there's a few differences but I guess the main one is that um the it sort of simplifies the IDTExtensibility2 interface so instead of having to implement 5 methods, you only have to implement 2 um but there's problems with using it for offensive purposes namely that you need a –a specific run time, a special run time in order to use these add-ins. Um, and also they're quite noisy when you install them.
Um, the thing which Microsoft seems to really be pushing at the moment is Web add-ins. And these are really quite interesting because they're based on HTML and Javascript and they can be not just cross application but they can be cross platform so you can have add-ins that work not just on um Windows but you can have it for Macs or mobile devices. Um, I haven't really looked at this and it's certainly an interesting research pro- project if anybody wants to look at it. Um, but very briefly looking at the API documentation, there doesn't seem to be any immediately obvious way of um executing operating system commands or any indeed anything sort of more interesting than that such as interacting with um operating system API's.
In terms of defending against these add-ins, it's very easy for COM automation VSTO you can disable add-ins and that will stop attackers from using them but of course, in many cases that will also stop legitimate organizations that need to use them from using them. Um, so in this case you can actually require that add-ins be um signed by a trusted publisher. However if you do this, I highly recommend that you also click the box which says disable notifications for um unsigned add-ins because if you just require um the add-ins be signed, users can actually still click through that and load the add-ins. Um, so it’s -it's basically you need to click these two sort of um options at the top.
Despite the -the name of WLL, XLL, and VBA add-ins, uh disabling add-ins doesn't actually work for these um so you they still execute for some reason so you have to take a different approach in terms of protect- uh, prevention and uh -uh detection. So the first would recommendation that I would make is to remove the trusted locations if you're not using them or at least relocate the trusted locations to an area where um administrators um only have access so you're maintaining administrative control of that area and low privilege users can't write into it. Um, but also improving detective capabilities so um monitoring those trusted locations for changes so that is looking at what existing files are in there, have these files been modified, what new files are being put in there. Remember with the case of Excel, it doesn't matter um what extensions that you're using so don't just simply look for particular extensions. Really it's -it's any file that uh–that are in those folders.
Um, I mentioned various registry keys during the course of this talk. Um, monitoring these locations in particular the sort of the registry key property open, that's a big one, and it's used quite widely. Uh and then basic EDR stuff, you know looking at process relationships and stuff and so on.
 
Uh, in conclusion, ah so this talk was about looking at the attack surface of Microsoft Office, how there's many legitimate um means of extending its functionality and executing arbitrary code which we can abuse uh for the purposes of persistence. Um, and pretty much all of- in fact all of the –the techniques that I've –I've talked about today don't require administrative rights um, which is um of course sort of uh the key situation for persistence techniques.
My Twitter Account is at William Knowles. Uh, if you want to follow me, please do. Uh, I will look at posting the uh the slides online in the coming days and weeks. Thank you very much.
[Applause]