 Hello everyone and welcome to hunting malicious office macros with myself Antonin Britsky. Thank you very much for being here and for tuning in. Just before I get into the materials of the talk and everything, I just want to call out all the materials, all the slides, all the datasets, the smart configs and everything like that will be available on this GitHub link that's on the slide right now. So quick intro about me. I'm currently with the Sumo logic threat research team previously. I was at the rest consulting. I love purple teaming hunting logs queries, general data nerd anything like that. On Twitter, I'm at Anton loves the NB so just feel free to hit me up anytime. I love talking shop happy to talk to folks and everything like that. So getting into the actual agenda of what we're actually going to be covering today. I wanted to briefly go over why a focus on malicious macros is worth your time. Why it's something that is worth paying attention to worth putting engineering hours into. I also also want to cover baselining. There's a lot of talk about baselining activity on the network, but not a lot of guidance out there on how to actually do it. And what the benefits of doing it are. And the final and kind of longest section of the talk will go over some hunting ideas with particular attention being paid to alerting and detection strategies. So why macros? Why are we looking at macros? So heavily, you know, what's the big deal about this? If we do some number crunching with MITRE attack data, we can see that about half of the tracked threat actor groups out there utilize the T 1024 002 technique, which is malicious file. And if we dug deeper into this, I wouldn't be surprised if even more tracked threat actor groups utilized these malicious macros in one way or another. Another thing that you can do if you want to get a feel for just how often these malicious macros are utilized is to search for the word macros on the DFI report site, which if you haven't checked out, I highly recommend you do so. And you'll see that a lot of intrusion write ups begin with a malicious macro being utilized in one way or another. So given their prevalence in the threat actor space, combined with the fact that a lot of users live in and use macros every day, combined yet again with the fact that these settings are not hardened by default on end user machines. This all creates a dynamic where macros used maliciously begin to pose a lot of risk to your organization or to your clients or what have you. And of course, I do need to mention that, at least at the time that I'm recording this and making these slides, Microsoft is currently backpedaling on some of the planned macro hardening changes, which is obviously unfortunate. So, at this point, you know, we've been kind of scared enough and have decided to do something about this problem. So, so, so where do we start. And the graph on this slides, this slide represents what I think at least is a decent starting point for beginning to wrangle macro visibility. And it should be noted that visibility into macro executions and system hardening done in order to limit unauthorized macros are kind of synonymous. And what I mean by that is that you can't really disable macros for users unless you understand how and where they're being used. So the next step after gaining some visibility into macro executions and by visibility, what I mean here is that this is endpoint level telemetry. So this is process events file network DLL registry events of that nature. And we want to use those events to baseline macro behavior to understand more holistically how macros are behaving in the environment. And that's what I mean by baseline. It means things like process trees, known good locations where macros are executing from what they're doing. So after you've gained some visibility and have started to baseline the behavior and your environment, you can then start to hunt for or alert on suspicious activity. And this could mean dropping over suspicious file, editing suspicious register keys, office binaries connecting to add you odd URLs or abnormal process trees. So rather than just say, you know, go baseline as part of this talk, three different system on configs will be made available in the GitHub repo that was linked earlier in the presentation. And here office watch kind of shows you everything that Susman is able to capture about office products office shush dot XML, then filters those events out so that you can use them to compare and contrast activity. And then office sus dot XML is an include only Susman config that includes kind of suspicious or suspicious adjacent to activity within its configuration file. And the idea here is that you can use these three configurations on a test machine with macros that are benign, but behave suspiciously. So things like macros that call out to your own, you know, kind of like testing C2, or something like the red canary atomic red team framework are really good use cases for this kind of thing. And the idea is that you flip back and forth between the different configurations until you lock in what you think is of no behavior. And then you would add these entries to your main system on config file, or look for that telemetry in your existing tool set. So at this point, we have some visibility into macros. And let's take a look at some really basic log examples from macro executions. And this slide is showing some system events that will tell you that a macro executed, including some suspicious function calls on the top right. And these log examples are great. And the events like look cool. We see an interesting call trace here with some suspicious memory access function calls are interesting. And on the top right we see some registry keys being edited and the bottom we see some suspicious DLLs being loaded. So we have good data and we have good telemetry at this point. So at this point we need to turn this data into something actionable. Something that will give analysts or whoever is looking at this information, good context and insight into what happened on the systems where potentially malicious macros are being executed. And here for the next few slides, I'm using this amazingly useful PowerShell script written by Gregor Historic. And that is linked directly in the slide. I highly recommend you check that out if you work with so small logs, it presents them in a really nice visual. And here we see a super basic example. We were just looking at a macro that is launched from a file share and the macro opens notepad. And I couldn't get the full command line in the slide, but if you were to look at the full command line, it would contain the path from where this particular macro was opened. And the point here is that the point I want to get across is just by using process creation events, we can already see things like where macros are being opened from and what processes they're spawning as well. And these are two key pieces of information when making a determination as to whether a particular macro is malicious or benign. And this process tree on this slide is the exact same macro. However, this one is open directly from a browser instead of a trusted file share. And we can see that again, just by using process creation events, we can already start to discern some macro behavior from something that is probably benign, like opening a macro from an internal file share versus opening a macro from a website of some kind. And you can also use this process information knowing that the macro was open from a website, obviously, to do some pivoting to figure out exactly where a particular macro was downloaded from. And I'll have a little bit more on this in some later slides. Looking at one last process tree, this time the macro was opened as an attachment from outlook. And again, just by using process creation data, we can already tell whether a user opened a macro from a file share as an attachment or from a website of some kind. This is really important information to have when conducting an investigation into macros that you might think are suspicious. So now let's look at some events that occur when a macro is opened from an encrypted zip, which is a really popular delivery method these days. Since time is a factor here and because different applications are involved, it's difficult to reconstruct a process tree out of this. And I know the screenshots are probably a little bit difficult to see, but the main point to get across here is that you're able to extract user behavior from telemetry. And this includes understanding how a user interacted with a potentially malicious office macro. And so far we've only looked at process creation events. So given that, let's broaden our scope a little bit and look at some other interesting event types in the context of office macros. I should have to know and specifically call out here, Event ID 15 versus Mon, which is file stream created. And with this event, you can actually see what processes downloaded a certain file and where that file came from. In this screenshot, you can see that my macro, which was found in the encrypted zip file, was downloaded from ngrok.io, which is a potentially suspicious domain. Another bonus here and some more events that I want to look at in the context of macros. And as I mentioned in the previous slide, if a file is downloaded with a mark of the web, you can see where it's downloaded from. And that's what the screenshot on the left is showing that the one that's marked with a number one. And a full examination of mark of the web behavior is kind of out of the scope for this talk just because I don't have time. However, in a typical scenario, a file with a zone identifier applied is considered a mark of the web file. And a zone ID of three as is shown in the screenshot here means that the file was downloaded from the internet zone. So if the user goes ahead and double clicks on this file, they'll get a smart screen warning pop up and that the users can click through that. However, the events on the right hand side here, the one that's marked with a two. And I should mention that the Sysmon config snippet that is required to generate this event is on the Git repo that was linked earlier. And this event is actually generated when the user right clicks the file with mark of the web applied and clicks on block. So really handy event to have. However, a few gotchas slash caveats. Please consider this event experimental. Also keep in mind that you'll see different pids and different grids. And also keep in mind that the downloading of the file and the removal of that mark of the web by a user can happen hours or even days apart. And that makes these events a little bit difficult to correlate. But in my opinion, I think this event is still worth instrumenting in your environment and worth tinkering with a little bit. So, so far we've looked at isolated events and looking at isolated events in this manner is fantastic. And by now we hopefully have a better feel for what kind of telemetry is available to us in the context of macros. So now let's try to tie this all together into an alerting strategy. And this should be somewhat easier now as we have visibility and base lining in place. And the diagram that you see on the slide. I made it with mermaid JS and the code that's used to generate this diagram is on the GitHub repo as well. Please feel free to use it. If you find a valuable address criteria go nuts. And also please note that not every single factor was added in here just due to space constraints. But the basic idea here is that we want to raise or lower some kind of score within our alerting paradigm. And Alex T area has described this paradigm as hyper or qualifier queries, but different vendors have different names for them. The main goal though is that you want to take a certain factor or behavior, one that you can observe through your logs and use it to either raise or lower a score. And after base lining, when that score moves past a certain threshold that you set, you investigate or you run a playbook a store playbook or what have you. And in this example, we are just raising a score of certain conditions are met, like the macro coming from an encrypted zip, loading calm DLS, generating abnormal system on event he attends or exhibiting beginning behavior or anything like that. So, at this point, we have our we have our baseline and completed we have a grid alerting strategy. And we just need the technical underpinnings and the actual query logic that we're going to use. And that's kind of what I have just displayed on the slide. And I should mention here that the full query is a little big so I can fit it in the screenshot but it's all available on the GitHub repo as well. So let's start with a quick baseline. And in this case, I'm executing a macro from a file share that I already know users open macros from in a legitimate fashion, and this particular macro uses WMI, and it spawns a process. So it performs some suspicious behavior, but the fact that it opens from a file share means that we can trust it just a little bit more. This doesn't mean that we fully exclude it. It just means that we can trust it just a little bit more. And by trusting it a little bit more, we lower the score when we see this particular macro running from my file share or another file share that you trust. And in this example, this baseline macro scores at about 35 points. And I should also note that the scoring here is kind of arbitrary, right? You set all this kind of based on what you're seeing in your environments. So let's compare the baseline macro and the score that it received to some retconary tests. The first test is an OS tap style macro execution. This score is at about a 48. And the score is higher for this particular macro due to it containing a suspicious call trace and spawning the C script process as well. The second macro is a choice flag execution, and this macro scores at about a 58. And here this score is higher due to the command line switches, as well as a command prompt being spawned from Word. And the third and final macro, which is at the bottom of the slide, is an Excel for macro, and this scores at about 60. And this score is higher due to the creation of a VBS file, and as well some suspicious call trace entries as well. And all these macros are scoring at about double our baseline macro. And again, the actual scores and different techniques used in these particular macros kind of matter less than the general dynamic of you have a good baseline of what normal is in your environment and you're alerting on things that deviate from that baseline. WMI techniques that I kind of touched on on the previous slide are worth calling out specifically. They could be pretty dangerous when it comes to macros because they break parent child process relationships and also make confused detection logic. However, DLL or image events, especially when combined with process access events, as well as a careful review of the call trace being generated, will kind of bubble this activity up. And the image on the left is showing WMI PRVSE spawning calculator as opposed to Winward. And we could also see on the right hand side of the slide, WMI PRVSE accessing the memory space of calc.exe with a suspicious function call. And all this information can be correlated back up to Winward, but the process tree will look a little different and will not show calc being spawned from Winward. So it's just something to watch out for. Another technique worth calling out specifically is P-Bit spoofing and similar to WMI, the goal of this particular technique is to break the process relationship chain. And the goal of this particular P-Bit spoofing macro is to make it look like PowerShell spawned from Explorer as opposed to Winward. However, if we look at the process access events and look at the right function calls, we can see the real parent process of PowerShell, which in this case is Winward. So if we see this mismatch between event ID 10 and event ID 1, it may be P-Bit spoofing taking place. And of course, we could add this logic to our qualifier query and score it appropriately. .NET-based macros can also be detected using the methods we've been outlining. So let's look at a few examples and we'll start with Gadget to JavaScript. And this is a really interesting technique that, and this is a super simplified explanation, basically makes it so you can load .NET assemblies from VBA code. I've personally executed this technique in various environments and I've successfully seen it skirt around EDR and other controls. However, with the right visibility in place, we can see our qualifier query lighting up super brightly. And the score that this particular macro is getting is about 139. And if we compare that score of 139 with the score of 35 that our baseline macro got, we could see that suspicious activity is starting to bubble up to the surface here where we could kind of get some visibility into it. And the reason why this particular macro is scoring so high is because of all the suspicious image loads that it has to do in order to perform its functionality. For VSTO plugins, there is a lot happening under the hood when this kind of tradecraft is used. And Daniel Shell has an excellent write-up for this kind of tradecraft that I highly recommend you check out and it's linked on the bottom of the slide. However, from a detection standpoint, in addition to loading a bunch of .NET DLLs, VSTO plugin executions also drop a suspicious file, which is what the screenshot here is showing. And we could see the file being dropped in the middle column. It has a QX1 extension, which is really odd. And we could include all this behavior both in our sysmonka figs and the subsequent qualifier queries. And if you're interested in exploring the telemetry generated by this kind of tradecraft, check out the gist that I linked at the bottom of the slide as well. I have to mention Office Zero Days because of the Folina dumpster fire that happened a few months ago. And I'll mention here that just because an Office Zero Day is out there, that doesn't mean that you're totally blind. And in my experience, the following factors greatly help when dealing with a Zero Day, especially in something like an Office product. The relevant telemetry needs to be generated. In our examples, this means a good working sysmonka fig installed on hosts where offices. Working greatly, this also means looking at events that go beyond your standard process creation events. And this is especially true when dealing with more advanced Office macro tradecraft. The relevant telemetry that's generated also needs to be available. And that is the telemetry needs to be found in a SIM or log analytics platform that allows you to just license the data and build queries. Particularly more advanced data crunching queries like hyper or qualifier or risk-based queries. The telemetry also needs to be flexible. For example, if you test this VSDO tradecraft and you see that a file creation event as we kind of covered in the last slide needs to be added to your sysmonka fig to generate the right logs. How quickly can you roll that out to your fleet? Behavior has to be baselineed. And this means that you generally understand who uses macros and where they're being used from. And finally, a good alerting strategy needs to be put in place. And here I want to argue that the standard kind of alerting paradigm for Office products spawning processes or did X thing is probably not going to be enough for the more advanced Office tradecraft. And I would strongly urge the collection and analysis of additional or more telemetry aimed at Office. So as part of this talk, we covered a lot of alerting strategies, including image load events, process trees, call traces. However, with the rich telemetry that you will hopefully gain after watching this talk, we can do a lot more. And I just wanted to cover some super basic ideas here. The first one being, you know, it's just the first time that the user ran this macro. This can be used in deciding whether a particular macro was malicious or not. Regarding beaconing alerts, beaconing alerts are a little bit tricky at the proxy level or firewall level. However, if you have a telemetry that ties a process to a network connection, I think beaconing detections become more feasible. And here I'm thinking of Suspended Entity 3. And generally speaking, Office products, maybe other than telemetry that they send back to the mothership, usually don't exhibit beaconing behavior. So I think there's quite a bit to explore in this particular area. Regarding DNS, DNS requests made by Office products, I think are gold mine for detection efforts. And these leave threat actors with very little wiggle room in terms of obfuscation, invasions, and things like that. And all this data can be used in your qualifier or hyper or risk-based queries as well. I would really urge you to take a very close look at where Office products are connecting to where they're establishing network connections. They may connect to a lot of Microsoft-owned AP addresses, but typically they do not connect to things like Azure Blob Storage, OneDrive SharePoint, or Azure Public IP Spaces. And here, of course, your mileage may vary because different networks behave in very different ways. The last point there, macros containing zips or macros that are downloaded from Google Drive or untrusted SharePoint sites should be treated with extreme caution. And here a great exercise for defensive teams is to download benign macros from these sites and see if your telemetry allows you to rebuild where a particular macro came from and what that macro does. Try this with macros in zips, macros in ISO files, as well as raw macros. And I'm pretty sure you'll be surprised at how many gaps you have in your telemetry and how difficult it is to rebuild that chain. The last thing I want to mention here is the response portion. And due to time constraints, I just didn't have the time to talk about some of the awesome and amazing response tools that exist in the context of office macros. Things like Velociraptor and tools made by Decalage 2 are very powerful in terms of response, and they allow you to really dig into macro internals from a DFIR standpoint. Here an awesome SOAR playbook would be to take every macro executed in your environment, run it through ViperMonkey, and pipe your results back into your SIN for further analysis. That would be amazing. So to wrap things up, I just want to call out and remind the viewers here that a malicious macro executing in the environment is just one aspect. The fishing email had to land in a mailbox and the macro has to do something after it executed. The threat actor has to perform some kind of subsequent actions. And all these are obviously detection opportunities in addition to the actual malicious macro itself. The second point there, building a good telemetry and detection pipeline is very difficult. It involves a lot of engineering effort, people hours, and it all gets combined with the requirement for a very specialized skill set. However, even if macros are disabled by default tomorrow, I would argue that this effort is still worth it. Office will always be an attractive attack surface just by the nature of how users interact with it and how ubiquitous it is in the workplace. And as we've hopefully seen with the examples presented here, we can get a lot of information from process creation events, particularly process trees. However, you can do a lot more with file creation, image loads, and process access events, especially if combined with network level telemetry. The last point there, a lot of macro tradecraft was crammed into this presentation. However, the macro tradecraft well runs very deep. And if macro executions concern you, I would strongly suggest looking at various hardening options for your endpoints. And this is not just the disabling of macros, but the introduction of deny by default application control as well. And I'll leave it there. Thank you very much for listening, for attending, and have a wonderful day.