 Aloha and welcome to my talk, Office Drama on macOS. My name is Patrick Wardle. I am a principal security researcher at Jamf and also the creator of the Mac security website and tool suite, Objective-C. So today we're gonna be talking about malicious office documents on macOS. First we're going to detail recent attacks targeting Mac users, attacks that leveraged macro laced documents. Then we'll discuss methods of analyzing these attacks. For example, how to extract the embedded macros and also how to analyze the document payloads. As the current attacks are kind of lame, somewhat constrained, for example, by the sandbox, I wanted to dig into this a little more and we'll talk today about a new exploit chain that combines what was at the time a handful of zero days to bypass the sandbox and Apple's latest security mechanisms. We'll end by discussing generic methods to detect and thwart some of these attacks. All right, so let's dive in. We're gonna start by looking at recent macro-based attacks targeting Mac users. Now, first you might be wondering, what is a macro? Well, I've added the official Microsoft documentation on the slide, but in short, a macro is embedded executable code in Microsoft Office documents. In other words, it allows one, as I mentioned, to add executable code into a file, into a document. So as we can see on the slide, what I've done is I've inserted a macro into a Word document that will display a pop-up that says hello world. Now, we'll talk about this more later in the talk, but since I've placed this code within the auto-open subroutine, if the user has enabled macro, this code will be automatically executed any time they open the document. Now, from a security point of view, you might be thinking, this sounds like a horrible idea. And you're right, placing executable code within documents, really just a terrible idea, which attackers have abused for years. In fact, the infamous Melissa virus, which was around all the way back in 1999, you guessed it, was a macro virus. Now, to be fair, Microsoft has added some mitigations, for example, alerts and sandboxing, but as we'll see, this has not fully mitigated the threat. So traditionally, these macro-based attacks have targeted Microsoft Windows systems due to two main reasons. First, macros are a Microsoft creation and only work in Microsoft products. Notice that they're not gonna work in Apple's office apps, such as pages or numbers. And then, Windows computers, especially in the past, were far more prevalent, especially in the enterprise. Now, this is definitely changing. We're seeing a lot more Macs, especially in the startup scene and also in the enterprise as well. And so in short, there are more Macs and a lot of them are running these Microsoft Office products, which means there's just more targets for hackers. So now let's take a look at some recent attacks targeting Mac users, attacks that leverage macro-laced documents. So first, in this section, we're gonna kinda look at these at a high level. In the next section though, we're gonna dive into discussing exactly how to extract and analyze the payload of these malicious documents. So we're gonna start in 2017. Here we have a document that appears to be about Trump's unfortunate election victory. If the user though went to open this document and clicked allow on the enabled macro alert, the system would become infected. Because in reality, this was a malicious document containing malicious macros. Moving on to 2018, we have a document that appears to be about Bitcoin, which was a very hot, trendy topic at the time. Again, if the user opens the document and allows macros to run, the system is owned. Now, this document is interesting and we'll dig into this more shortly, but the most interesting aspect of this attack was that the embedded exploit code contained the ability to actually bypass Microsoft Office's sandbox. Moving on to 2019, we have a document from the prolific Lazarus APT Group, which is normally associated with North Korea. This is interesting because we're actually now seeing APT groups jump on the, hey, let's target macOS via macros bandwagon. Again, if the user opens the document and clicks allow, the system will be owned. All right, so now let's talk about methods of analyzing these malicious documents, showing exactly how to extract embedded macros and how to analyze both the macro code and any embedded payloads. First, we need to be able to extract the embedded macro code. Now, the details of the file format with Microsoft Office documents is kind of beyond the scope of this talk, but the good news is you really don't have to even worry about that. Turns out there are some really great tools that are able to, if given a Office document with macros, contributely extract those macros, and that's really basically all we care about. My favorite is a tool suite called OLE Tools from GitHub. So we can see on the slide, we downloaded the package and installed it, and then we execute the OLE VBA command with the dash C parameter, passing in the document which we suspect has embedded macros that we want to analyze. And the OLE VBA tool will then parse the document and dump any embedded macros to standard out. There's also various online sites where you can upload a document. The website will then do the analysis and extract any macro code. Now, we want to understand exactly what these malicious macros are doing. So let's briefly return to the documents that we discussed in the first part of the talk, and for each of these, look at exactly what the malicious macro code is doing. So again, starting at the one from 2018, we can use the OLE VBA tool to extract the macros. And I've cleaned up the macros a little bit and placed them on the screen. So we can see on the slide, there is a subroutine called Fisher that is invoked via the auto open method. The auto open method is a Microsoft API, and as its name implies, any code placed within this API will be automatically executed if and only if the user has enabled macros when opening the document. So if we assume the user has clicked allow to the embedded macros, let's look at what the Fisher subroutine does. Again, as it'll be automatically executed each time the document is opened. So the first thing it does is it builds a base 64 encoded string, and then it decodes and executes that via Python. If we manually decode this string, we can see it's Python code, which is unsurprising as it's passing it to Python to execute. So what does this Python code does? Well, the first thing it does is it checks to see if popular security products, for example, Little Snitch is running, and then it downloads a second stage payload from securitychecking.org. It then decrypts this payload using RC4 and executes this. Now, this code might look familiar if you spend a lot of time kind of looking at these attacks, and that's because this payload is actually Empire, which is a well-known open source Python backdoor. Now, you might be wondering, okay, what is it downloading and executing as its second stage payload? Well, unfortunately, the command and control server was offline at the time I did this analysis, but it's likely that it simply empires second stage payload, which gives attackers full access over the infected system. Moving on to the Bitcoin document. Again, this one was from 2018. Using the OLE VBA tool, we can again extract the embedded macros. Interestingly, this also contains encoded Python and what appears to be an embedded property list. That's interesting. So let's take a closer look. First thing we do is we decode the Python since it's base 64 encoded. It's very trivial to do. You can either do that via an online site that provides base 64 decoding, or I just do it via the command line via a Python shell. Once the code is decoded, again, we can see that on this slide, it connects to an IP address, executes and downloads a second stage payload. Turns out this command and control server was still online during the time of my analysis, so I was actually able to get a copy of this second stage payload, which turned out to be Metasploit's interpreter. Again, interesting to see attackers leveraging open source agents in second stage payload. Interpreter affords remote access of an infected system. If you're called the beginning of the talk, we kind of said that the most interesting thing about this particular document was its ability to escape out of Microsoft Office's sandbox. So, recent versions of Office run in a sandbox, which is good, and it means that if code is executed within the context of the process, for example, macro code executing within a Word document, it is highly contained. It's limited by what it can do. It's still in the sandbox. So it can't do things like persist the backdoor or even access the user's files. From a security point of view, this is very good. However, Mac security researcher, Adam Chester, found a very neat way to escape the sandbox and posted a guest blog about this on my Mac security website, Objective-C. In short, we found that Microsoft Office had a sandbox exception that was based on a faulty reg X that would allow sandbox code to create a file anywhere on the system. So what Adam was able to do was, via macro code running in the context of the sandbox, create a launch item that on the next login would be executed outside the context of the sandbox. And he used a property list in order to do that. So when I was analyzing this document, I said, okay, this code looks very familiar. And I read Adam's blog and posted it on my site. And it turns out that the attackers had likely also read this blog and took Adam's code for Batem, 100% copy and paste, and embedded it into their office document. So this would mean that on unpatched systems, they would be able to break out of the sandbox and cause more havoc, more mayhem. Finally, if we extract the embedded macro code from the Lazarus group document, we can see it's pretty basic. This case, it's not even included. So what does it do? Well, it simply downloads and executes a second stage persistent implant. That implant is named MT.dat and would give attackers persistent remote access to the system. However, this document did not have any sandbox escape code, which means if it was opened on a recent version of MacOS, this part of the attack would fail because you can't obviously persist code from within the context of a sandbox. So that's an overview of recent macro based attacks against MacOS, which gave us, I think, a pretty thorough understanding of the status quo. Now let's talk about a new zero click macro based exploit chain. And you might be wondering, why should we do this? Well, all current macro based attacks, in my opinion, are super lame. Well, let's list the ways. First, for any of these attacks, when the user goes to open the document, there's a huge alert warning them that this document contains macros and they probably should not allow them. The user basically has to click enable. Most won't, which means these attacks will fail immediately out of the box. Macro code will never even be run. Also, as Microsoft has now patched Adam's sandbox escape bug, all the attacks remain sandbox. Again, it means even if the user does enable the macro code, they're incredibly limited about what they can do. They can't persist code or access user files. And then finally, on macOS Catalina, the most recent version of macOS, Apple has really upped the bar and introduced some new security mechanisms such as notarization, which means the second stage payloads may not necessarily be even allowed to execute by the system. So again, the current attacks, my opinion, basically useless. Whenever companies such as Microsoft or Apple patch stuff or implement new security mechanisms, I like to poke on that because often they do so incorrectly, insufficiently. So let's walk through now this kind of zero-click exploit chain. So the exploit starts with a really neat bug that was found a while ago by two security researchers and then kind of improved upon by other researchers at cert. So this first bug is not mine. What these researchers found was that even if macros are turned off, they could create a document that contained macros that would be automatically executed with no alerts, no prompts. That's hot. How do they do this? By abusing a incredibly old Microsoft file format called SYLK files. How old, like from the 1980s, before I was even born. And they also used a macro language not written in VBA but something called XLM. Not XML, XLM. Now Microsoft loves to support old file formats for compatibility reasons. So yeah, these old four file formats still work even in recent versions, specifically in Excel. So as I mentioned, the researchers found that they could create these XLM macros in these SYLK file formats that would be automatically executed ironically if the user had set never run macros to true. So the researchers published through great details about these older formats and some of their findings. So if you're interested, I posted a link on the slide to their very thorough technical write-ups. So what I did was I created a simple proof of concept based on their code. We'll see a malicious document is downloaded from the internet and when it is opened, Kalk is automatically executed. Now the main takeaway from here is that there are no macro alerts, right? No prompts, nothing. Just as soon as the document is opened, calculator pops. That's well and good, but as we noted on recent versions of Microsoft Office, the applications are sandboxed, meaning sure we can pop calculator and that's neat for a demo, but we can't persist the backdoor, we can't access the user's files. This is the point of the sandbox. It contains malicious code, even if such code finds a way to execute. So in short, we need a new sandbox escape in order to do any real damage. So I started by looking at Microsoft's patch for Adam's bug and I noticed that they actually didn't fix the faulty regex. Instead they just simply blocked certain locations such as the launch agent directory, which is where Adam's proof of concept created a launch agent, which on the next login would be executed outside the context of the sandbox. So this means we can create arbitrary files as long as they start with tilde dollar sign, meaning they conform to this faulty regex almost anywhere. Again, almost anywhere because Microsoft added some specific locations that they blocked. Now our goal of course is to execute something outside the sandbox so we can persist and do evil things. We just noted we can write specially named files to arbitrary locations from macro code that's running within the context of the sandbox as Microsoft didn't fully patch that. Also it turns out in the sandbox we can both download and execute scripts as we can see in the process monitor on the slide. Now these scripts themselves will be sandboxed, they're children of a sandbox process which means themselves are also sandboxed but that's still a start. We can execute, for example, Python scripts which gives us a very extensible programming language to perhaps do some sorts of evil things. So via a Python script which we again download and execute within the sandbox we can create something called a login item. Now login items are automatically executed the next time the user logs in and since it started by macOS instead of us via the sandbox it's not gonna be sandbox. So when the user's logging in, macOS goes and looks at the register login items and just executes and starts all of them. Again, there's no tie back to the Microsoft Office, macro code, sandbox, nothing. So that means this will be executed outside the context of the sandbox. To confirm we can persist terminal.app, sure enough when we re-log in terminal is executed and if we look at it in activity monitor we can see that it runs outside the sandbox. So this is good, right? We now have a way to bypass the sandbox but unfortunately we run smack into Catalina's new security mechanisms which are file quarantines and new notarization requirements. And a nutshell notarization basically says hey, Apple has to bless the file before it's run. Obviously Apple's not gonna bless our back door. So even if we go and persist the back door as a login item, macOS will simply refuse to execute it because unfortunately it is not blessed. It is not notarized. Ugh, this is a bummer. And so what do we do, right? We gotta figure out a way to bypass now quarantine and notarization. Now hope is not lost, right? This is 2020, things look bleak but we gotta stay optimistic especially when we are looking and developing exploits. Because if, and this is a big if, if we can create a launch agent, we can specify arguments and persist a persistent interactive non-sandbox reverse shell via bash. Now this is a big if but again there's a few kind of takeaways here. First being able to specify arguments is huge. And then also if we can specify or persist rather an interactive shell it's gonna be running outside the sandbox which is gonna do things like allow us to remove quarantine attributes which means that notarization checks will not even be performed. This would be great. But recall that Microsoft's patch for Adam's bug explicitly blocks the creation of launch agents. Bummer. So we kinda have like all these pieces but we just can't quite put them together. Frustrating. So we can escape the sandbox via a login item but login items can't take arguments and they also can't be a random binary because notarization will block it. So in other words, all we can do is persist an Apple binary. Again with no arguments. And sure we can bypass notarization by the creation of a launch agent but we can't create one from the sandbox due to Microsoft's partial patch. So in other words, what we need is a way for the system or for an Apple binary with no arguments is to create a launch agent for us. This is where things get beautiful. So I had a random idea. What happens if you create a login item that is not a binary or an application? Like what happens if you persist a zip file? How does the system handle that? Again recall we can create these login items from the sandbox. It can't take arguments and it can't be random binaries but what happens if we persist a zip file, right? Well turns out on login, the files default handler will be invoked which for a zip file, macOS will automatically execute the Apple's archive utility to unzip file. Basically says, okay this is not an executable so I'm gonna invoke the handler and in this case it's the archive utility because we persisted a zip file which will extract that. Now remember we wanna create a launch agent but due to Microsoft's recent patch, we cannot directly write to the user's launch agent directory. But if it doesn't exist which on a default version of macOS it does not, we can drop the zip file one directory up in the user's library directory. This is allowed from the sandbox. So now we can place the zip file in the library directory and we can persist this as a login item. So we're making progress. So what do we put in the zip file? A directory named launch agents and in that a launch agent property list. So now when we persist this zip file as a login item on next login the archive utility will automatically be invoked. This is allowed because it's an Apple sign process and it will run outside the context of the sandbox which means it can do things like unzip our file and create the launch agent directory and our launch agent property list for us. That is awesome. So this completes the full exploit chain. The user starts by opening this SLK file containing the XLM macro which will execute automatically. Again, no alert, just open the document. This downloads and persists the specially crafted zip file as a login item. On next login the archive utility will be automatically invoked and in the background will extract this zip file thereby creating a launch agent for us. And on next login the login agent will be automatically executed with our arguments which we can put in the property list and will execute our bash-based interactive backdoor. So this batch backdoor runs outside the sandbox meaning it can download and unquarantine files. Unquarantine files are not constrained by Apple's notarization requirements. So we have this interactive shell outside of the sandbox. What do we do? Well, we decided to persist something and I thought it'd be extra funny to persist a repurposed, clearly not notarized version of Windail. And you can see on the slide when I finally got this all working in the Slack channel at work I was clearly pretty stoked. All right, so let's now talk kind of shift gears and talk about defending against these attacks and some generic methods of... First thing, as a responsible security researcher I reported all these vulnerabilities to Microsoft and Apple. Microsoft responded and said this is a known issue on the Apple side. And I was like, well, yeah, because I told Apple as well. So I have no idea what Microsoft did. No CVE, no bug bounty, bummer. Apple said, thank you for your reports and then nothing. I waited a long time and checked back in with Apple and they said, oh yeah, we patched that back in 10.15.3. Again, no CVE, no bug bounty, classic Cupertino. Let's talk briefly though about how to detect this. These attacks and perhaps other Mac malware as well. So the first thing let's talk about is process monitoring leveraging Apple's new endpoint security framework. Turns out it's pretty easy to create a process monitor to detect something I call suspicious children. Suspicious children processes. As we can see on the slide, we can now detect when an office application, for example, Excel spawns a child process that is, well, suspicious. So regardless of the reason of the exploit, if it was a macro, buffer overflow, if you see Excel spawning curl and then Python, that's bad news, something is amiss. We can also detect a wide range of attacks including the exploit chain we just talked about this by monitoring the file system for persistence. Persistence is just the way that malware or perhaps an exploit chain escapes out of the sandbox or ensures that it's automatically re-executed when the system is rebooted or the user re-logs in. So again, we can use Apple's new endpoint security framework and we can monitor for files, specifically related for ones to persistence. So here, for example, on the slide, we can detect now that a login item was created that does not point to an application or a binary, which is normally the case when a login item is created, but instead to a zip file. This is a huge red flag and kind of shows that our exploit is execute. So at Jamf, we implement such monitoring logic in a framework we call monitor kit. We then feed that monitoring data as well as our analytics and rules into Apple's game logic engine for evaluation. This gives us a powerful endpoint detection capability uniquely tailored for macOS. And kind of neat, not to really brag, but based on our current rules, we are actually able to detect this exploit chain with no a priori knowledge. Pretty neat. All right, so let's wrap everything up. So today we kind of talked about the current state of affairs in the land of macro-based attacks. And we showed that they are becoming more and more popular in the sense of targeting specifically macOS users, but luckily current attacks are rather late. However, we should not be lulled into a sense of complacency because we showed us pretty easy to actually create a zero-click exploit chain that if the user would open a document would both escape the sandbox and bypass all of Apple's recent security mechanisms. Again, at the time on a fully-patched macOS system. However, we ended by showing that by leveraging Apple's new endpoint security framework, we can generically detect these and other. I really wanna thank a variety of people, first and foremost, you all for virtually attending my talk. Hope you're all staying safe and healthy. Also to Jamf for putting up with my many shenanigans and also all the amazing companies that support Objective-C. Oh, and one more thing. Today I am announcing my new book, The Art of Mac Malware Analysis. My dog is very excited about it as well. I've published the first part online at taumm.org and the rest of the chapters will be published shortly as well, all 100% free. Sharing is caring. So if you're interested in learning more about Mac malware, exploits, persistence, debuggers, this assembling, check out the site. So again, that is a wrap. Thank you so much for attending my talk.