 Good morning, everyone. Thank you for being here so early to listen to me talk about Microsoft Office of all things. There's a lot to get through and I hope that you learn a lot. But even if you don't, at the very least, I do hope that your budget application for coming to DEFCON was helped by being able to say that you took part in Microsoft Office Shrain. 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, including execute arbitrary code. And that's something as attackers which we can abuse for purposes such as maintaining persistence on compromised workstations. So in terms of the motivations for doing this research, the first one was that Microsoft Office is so ingrained in the workflows of a typical business user that if you compromise a random workstation, you're almost certainly going to come across Microsoft Office. That means if you have 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 that was popularized in the past couple of years, in part by a colleague of mine at MWR Costless, but also around the same time by Matt Nelson, and that was on the topic of office templates. So if anyone isn't familiar with this, essentially 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 open up a document, that reference will actually get followed and that payload, that macro will get executed. Now, these templates are stored in trusted locations. What this means is they're trusted to be exempt from normal macro policy. So even if you disable macros without notification, documents that exist in these folders such as the templates, the VBA, the macros will still get executed. Now, when looking at these, some of them are very clearly 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 which I came across was WLL files. And it turns out that these are basically just DLLs 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 and it turns out that one potential answer for this is that they were actually developed for Office 97. But despite this, they're still supported in modern Office versions. So in terms of for what we need to do, what are these functions that we need to export? It actually doesn't really matter. What you can just do is create a DLL, stick your payload in the DLL main function. 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 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 Word treats WLL files is that it doesn't actually list them as active add-ins. Which is something that those involved in defense should be aware of. I think this potentially could just be because the correct functions are being exported in order for it to identify them. But regardless, it works for the offensive purposes. Excel also has an add-in, Excel. This is considerably more updated. The software development kits were released in 2007, so only 10 years ago. You do have to export the right functions in an Excel add-in. There's one specific function that you have to 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 exporting 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 Excel add-ins. The first is that 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 Excel L. You can call it .txt file, or if you want you can have no extension at all. Excel seems to just fingerprint all the files, see if it understands them, and then will load them anyway. Another thing is there is this particular registry key, which you can see there, and then it has a particular property which you can create called Open. So the value is open and you can have multiple of these open and then an integer. And then the value of this, if you specify the slash R switch and then the absolute path of a Excel L add-in, you can actually load Excel L add-ins from outside the startup trust of the location. And that doesn't give any warning prompts to users. So just a quick demonstration of this. So if we open up Excel, we can see that nothing gets executed. And if we go into the options, go into 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, Microsoft, Excel, Excel star. So we've got this .txt file on the desktop. And if we check that with dependency walker, we can see that it's actually a DLL file because it's exporting a function called Excel auto open. So all we need to do is copy this into the startup location. So if we go into app data, which takes us into the roaming profile, then Microsoft, Excel, Excel star. Copy that in. Excel should load this DLL, which in this case just spawns calc. If we delete that file now, so it shouldn't execute because it's not there. So just to show the registry variant and that there's no sort of security warnings for that, there's this .reg file, which creates the property that we just saw before, the open property slash R and then the absolute path to an Excel file on the desktop. One thing that I forgot to mention was that if you're doing the registry method, file extensions do matter, so it needs to be Excel or DLL. But there we have the registry key being created and then again, when it 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. You open Excel, you open the VBA editor, you stick your macro in. The difference comes when you go to save it. If you drop down the list of supported file types somewhere near the bottom, but not quite, there's actually something called Excel add-in, which has an XLA or XLAN file extension. So if you basically save it as this format, which is just an Excel document without any associated spreadsheets and drop it in the 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, different file extension, same way of creating one differences that you do need to indicate to PowerPoint through a registry edit that it needs to load up. So you create a particular key and that has a couple of properties, first of all to load, you set that to the value of one, which means load at startup, and then you give it the path, which is just a file name, and then PowerPoint will know itself to check in the startup location for a file of that name. Now all of the add-ins that I talked about so far involve basically dropping something into the startup location. Another form of add-in, which is sort of slightly different in terms of the way that you deploy it, is those add-ins which are based on COM. So for anyone that isn't familiar with COM component object model, this was a technology developed in the early 90s by Microsoft, and basically it's to create a sort of a binary interface standard so you can create reusable software components which can be interacted with in a language-independent way. 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. So these are used all over Windows. You know, modern Windows operating systems are still very reliant on COM. These COM objects, and you can use these COM objects as add-ins for office programs. In order to do that, you have to implement a particular software interface called the IDT Extensibility 2 interface, and basically that involves implementing a series of five methods which basically act as event handlers. So one of these, for example, would be on connection, which executes code when 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 add-ins, you can basically create them so they're portable between all office products. You could have one for Outlook, for example, which only executes code when an email is received with a particular string in the body. In terms of the way that we actually go about registering and using these add-ins, once we've created them, 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 tools such as RegASM, which requires administrative rights. Basically the reason for that is because these tools apply directly to the place in HKEY classes route 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, which actually gets synchronized when you log out, and one of those highest HKEY current users we obviously have right 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 called in conspicuous.com.in.connect, and that has a subkey CLSID with a default value of a GUID, and that GUID has its own key in the green section with various bits of information associated with it, and it's not important really to understand what all of them are for our understanding, but this line here is particularly important code base as that points to the file on disk, which is actually implementing this COM object. So we've got a name that's associated with a GUID, and that GUID is somehow mapped to the file on disk but 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 where we can basically just say use this friendly name, and then Windows does the mapping back to the actual COM object on disk. So this way we can, using COM objects, we can create a cross application add-ins, which are very portable and don't require administrative rights. Another form of add-in based on COM is for the VBA editor. So these are add-ins which don't execute when you open a document, but they execute when you open the VBA editor. So whenever somebody comes to look at the VBA code itself at the macros or edit them, that's when it gets executed. So it gets executed when the VBA editor loads. It doesn't really have a huge application, but it's perhaps one of my favorites. The way that you register these is basically the same as what I just discussed. You register it with Windows, like the first two boxes, and then it's only the application-specific bit at the end, which is different. So in this case, creating a key which has 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 the VBA editor starts up. Another form of add-in is now sort of specific to Microsoft Excel, is called the automation add-ins. So if you open up Excel now and you look at the list of supported add-ins, you'll see that it distinguishes between COM add-ins and automation add-ins, but really, automation add-ins are also based on COM. The difference is that they don't implement the IDT extensibility to interface. I should have mentioned as well that the VBE add-in also implements the IDT extensibility to interface, so the COM add-ins and the VBE add-ins are kind of more or less the same thing, whereas this, automation add-ins for Excel are slightly different because you don't need to implement that interface. Basically, you just define public functions in the COM object, and those public functions become user-defined functions within Excel, so you could have a formulae, for example, which is equals calc and it spawns calc or injects 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 for Windows. The difference is when it comes to the application-specific bit, again, we see a reappearance of the open registry key property. Only this time, we're using the slash A switch, and then we're giving the name of the COM object, and then Windows sorts everything else out for us. A lot of the stuff that I've talked about so far is using technologies that have been around for a while. 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. It's just, I guess, you create the templates in Visual Studio. It's a bit of a strange name. Basically, this is a cross-application add-in, which is supposed to be a replacement for COM add-ins. There's a few differences, but I guess the main one is that it sort of simplifies the IDT extensibility to interface, so instead of having to implement five methods, you only have to implement two. But there's problems with using it for offensive purposes, namely that you need a specific runtime, a special runtime in order to use these add-ins, and also they're quite noisy when you install them. The thing which Microsoft seems to be really 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 Windows, but you can have it for Macs or mobile devices. I haven't really looked at this, and it's certainly an interesting research project if anybody wants to look at it, but very briefly looking at the API documentation, there doesn't seem to be any immediately obvious way of executing operating system commands or indeed anything sort of more interesting than that, such as interacting with operating system APIs. In terms of defending against these add-ins, it's very easy for COM automation and 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. So in this case, you can actually require that add-ins be signed by a trusted publisher. However, if you do this, I highly recommend that you also click the box which says disable notification for unsigned add-ins because if you just require that add-ins be signed, users can still actually click through that and load the add-ins. So it's basically you need to click these two sort of options at the top. Despite the name of WLL, XLL and VBA add-ins, disabling add-ins doesn't actually work for these, so they still execute for some reason. So you have to take a different approach in terms of prevention and detection. So the first 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 administrators only have access. So you're maintaining administrative control over that area and low privilege users can't write into it. But also improving detective capability. So monitoring the 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 XLL, it doesn't matter what extensions that you're using. So don't just simply look for particular extensions. Really it's any files that are in those folders. I've mentioned various registraries during the course of this talk. Monitoring these locations in particular, the sort of the registry key property open, that's a big one and it's used quite widely. And then basic EDR stuff, you know looking at process relationships and so on. In conclusion, so this talk was about looking at the attack surface of Microsoft Office, how there's many legitimate means of extending its functionality and executing arbitrary code, which we can abuse for the purposes of persistence. And pretty much all, in fact all of the techniques that I've talked about today don't require administrative rights. Which is of course sort of the key situation for persistence techniques. My Twitter account is at www.william.store.nulles. If you want to follow me please do. I will look at posting the slides online in the coming days or weeks. Thank you very much.