WEBVTT 00:00.600 --> 00:04.740 Aloha, and welcome to my talk, Office Drama on macOS. 00:05.680 --> 00:07.400 My name is Patrick Wardle. 00:07.400 --> 00:16.460 I am a Principal Security Researcher at Jamf, and also the creator of the Mac security website and tool suite, Objective-C. 00:17.980 --> 00:24.240 So today we're going to be talking about malicious office documents on macOS. 00:24.300 --> 00:33.020 First, we're going to detail recent attacks targeting Mac users, attacks that leverage macro-laced documents. 00:33.120 --> 00:36.640 Then we'll discuss methods of analyzing these attacks. 00:36.640 --> 00:44.140 For example, how to extract the embedded macros, and also how to analyze the document payloads. 00:44.440 --> 00:53.680 As the current attacks are kind of lame, somewhat constrained, for example, by the sandbox, I wanted to dig into this a little more. 00:53.680 --> 01:07.480 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. 01:07.480 --> 01:12.780 We'll end by discussing generic methods to detect and thwart some of these attacks. 01:14.000 --> 01:16.300 All right, so let's dive in. 01:16.300 --> 01:22.020 We're going to start by looking at recent macro-based attacks targeting Mac users. 01:22.840 --> 01:26.320 Now, first, you might be wondering, what is a macro? 01:26.320 --> 01:31.340 Well, I've added the official Microsoft documentation on the slide. 01:31.340 --> 01:38.040 But in short, a macro is embedded executable code in Microsoft Office documents. 01:38.040 --> 01:45.180 In other words, it allows one, as I mentioned, to add executable code into a file, into a document. 01:45.680 --> 01:56.480 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. 01:56.560 --> 02:00.920 Now, we'll talk about this more later in the talk. 02:00.920 --> 02:12.860 But since I've placed this code within the auto-open subroutine, if the user has enabled macro, this code will be automatically executed anytime they open the document. 02:13.840 --> 02:19.740 Now, from a security point of view, you might be thinking, this sounds like a horrible idea. 02:19.740 --> 02:21.640 And you're right. 02:22.120 --> 02:30.620 Placing executable code within documents, really just a terrible idea, which attackers have abused for years. 02:30.620 --> 02:39.540 In fact, the infamous Melissa virus, which was around all the way back in 1999, you guessed it, was a macro virus. 02:40.040 --> 02:47.720 Now, to be fair, Microsoft has added some mitigations, for example, alerts and sandboxing. 02:47.720 --> 02:52.080 But as we'll see, this has not fully mitigated the threat. 02:54.900 --> 03:02.540 So traditionally, these macro-based attacks have targeted Microsoft Windows systems due to two main reasons. 03:02.800 --> 03:08.520 First, macros are a Microsoft creation and only work in Microsoft products. 03:08.520 --> 03:13.880 That is, they're not going to work in Apple's Office apps, such as Pages or Numbers. 03:14.260 --> 03:22.000 And then Windows computers, especially in the past, were far more prevalent, especially in the enterprise. 03:22.600 --> 03:24.280 Now, this is definitely changing. 03:24.280 --> 03:30.180 We're seeing a lot more Macs, especially in the startup scene and also in the enterprise as well. 03:30.680 --> 03:40.120 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. 03:42.000 --> 03:50.960 So now let's take a look at some recent attacks targeting Mac users, attacks that leverage macro-laced documents. 03:51.500 --> 03:56.240 So first in this section, we're going to kind of look at these at a high level. 03:56.240 --> 04:06.020 In the next section, though, we're going to dive into discussing exactly how to extract and analyze the payload of these malicious documents. 04:06.020 --> 04:08.740 So we're going to start in 2017. 04:08.740 --> 04:15.240 Here we have a document that appears to be about Trump's unfortunate election victory. 04:15.740 --> 04:29.460 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. 04:31.180 --> 04:40.120 Moving on to 2018, we have a document that appears to be about Bitcoin, which was a very hot, trendy topic at the time. 04:40.120 --> 04:47.040 Again, if the user opens the document and allows macros to run, the system is owned. 04:47.040 --> 04:51.480 Now this document is interesting, and we'll dig into this more shortly. 04:51.480 --> 05:03.260 But the most interesting aspect of this attack was that the embedded exploit code contained the ability to actually bypass Microsoft Office's sandbox. 05:04.560 --> 05:14.320 Moving on to 2019, we have a document from the prolific Lazarus APT group, which is normally associated with North Korea. 05:15.040 --> 05:24.120 This is interesting because we're actually now seeing APT groups jump on the, hey, let's target macOS via macros bandwagon. 05:24.120 --> 05:29.260 Again, if the user opens the document and clicks allow, the system will be owned. 05:31.260 --> 05:46.980 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. 05:48.060 --> 05:52.860 First, we need to be able to extract the embedded macro code. 05:53.220 --> 06:01.180 Now, the details of the file format of Microsoft Office documents is kind of beyond the scope of this talk. 06:01.180 --> 06:04.540 But the good news is you really don't have to even worry about that. 06:04.540 --> 06:12.880 Turns out there are some really great tools that are able to, if given a Office document with macros, contributely extract those macros. 06:12.880 --> 06:15.140 And that's really basically all we care about. 06:15.520 --> 06:20.360 My favorite is a tool suite called OLE Tools from GitHub. 06:20.360 --> 06:25.120 So we can see on the slide, we downloaded the package and installed it. 06:25.120 --> 06:36.560 And then we execute the OLE VBA command with a dash C parameter, passing in the document, which we suspect has embedded macros that we want to analyze. 06:36.560 --> 06:45.140 And the OLE VBA tool will then parse the document and dump any embedded macros to standard out. 06:45.240 --> 06:49.010 There's also various online sites where you can upload a document. 06:49.860 --> 06:54.180 The website will then do the analysis and extract any macro code. 06:56.130 --> 07:02.480 Now, we want to understand exactly what these malicious macros are doing. 07:02.480 --> 07:08.960 So let's briefly return to the documents that we discussed in the first part of the talk. 07:08.960 --> 07:15.600 And for each of these, look at exactly what the malicious macro code is doing. 07:15.760 --> 07:22.680 So again, starting at the one from 2018, we can use the OLE VBA tool to extract the macros. 07:22.680 --> 07:27.000 And I've cleaned up the macros a little bit and placed them on the screen. 07:27.160 --> 07:31.680 So we can see on the slide, there is a subroutine called Fisher. 07:32.480 --> 07:36.060 That is invoked via the auto open method. 07:36.060 --> 07:39.740 The auto open method is a Microsoft API. 07:39.780 --> 07:52.980 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. 07:53.100 --> 08:00.220 So if we assume the user has clicked allow to the embedded macros, let's look at what the Fisher subroutine does. 08:00.220 --> 08:05.280 Again, as it will be automatically executed each time the document is opened. 08:06.160 --> 08:14.300 So the first thing it does is it builds a base 64 encoded string, and then it decodes and executes that via Python. 08:15.740 --> 08:24.580 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. 08:24.580 --> 08:26.860 So what is this Python code does? 08:26.860 --> 08:34.080 Well, the first thing it does is it checks to see if popular security products, for example, little snitch is running. 08:34.080 --> 08:39.920 And then it downloads a second stage payload from securitychecking.org. 08:39.980 --> 08:44.980 It then decrypts this payload using RC4 and executes this. 08:45.540 --> 08:48.240 Now, this code might look familiar. 08:48.240 --> 08:50.860 You spend a lot of time kind of looking at these attacks. 08:50.860 --> 08:58.120 And that's because this payload is actually Empire, which is a well-known open source Python backdoor. 08:58.400 --> 09:04.380 Now, you might be wondering, okay, what is it downloading and executing as its second stage payload? 09:04.740 --> 09:19.100 Well, unfortunately, the command and control server was offline at the time I did this analysis, but it's likely that it's simply Empire's second stage payload, which gives attackers full access over the infected system. 09:20.700 --> 09:22.960 Moving on to the Bitcoin document. 09:22.960 --> 09:25.360 Again, this one was from 2018. 09:25.580 --> 09:30.620 Using the OLE VBA tool, we can, again, extract the embedded macros. 09:30.620 --> 09:37.480 Interestingly, this also contains encoded Python and what appears to be an embedded property list. 09:37.520 --> 09:38.760 That's interesting. 09:39.780 --> 09:42.380 So let's take a closer look. 09:42.660 --> 09:45.220 First thing we do is we decode the Python. 09:45.220 --> 09:49.560 Since it's base64 encoded, it's very trivial to do. 09:49.560 --> 09:58.260 You can either do that via an online site that provides base64 decoding, or I just do it via the command line via a Python shell. 09:58.640 --> 10:09.260 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. 10:09.700 --> 10:23.260 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 Meterpreter. 10:23.260 --> 10:29.240 Again, interesting to see attackers leveraging open source agents in second stage payload. 10:29.240 --> 10:33.920 Meterpreter affords remote access of an infected system. 10:35.320 --> 10:47.840 Now, if you recall 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. 10:47.840 --> 11:03.840 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. 11:03.840 --> 11:05.520 It's limited by what it can do. 11:05.520 --> 11:07.460 It's still in the sandbox. 11:07.540 --> 11:12.580 So it can't do things like persist the backdoor or even access the user's files. 11:12.580 --> 11:15.340 From a security point of view, this is very good. 11:16.200 --> 11:27.900 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. 11:28.040 --> 11:41.960 In short, we found that Microsoft Office had a sandbox exception that was based on a faulty regX that would allow sandbox code to create a file anywhere on the system. 11:41.960 --> 11:55.820 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. 11:55.820 --> 12:00.260 And he used a property list in order to do that. 12:00.700 --> 12:02.060 So I was analyzing this document. 12:02.060 --> 12:04.160 I said, okay, this code looks very familiar. 12:04.160 --> 12:07.700 And I read Adam's blog and posted it on my site. 12:07.700 --> 12:20.160 And it turns out that the attackers had likely also read this blog and took Adam's code for verbatim, 100% copy and paste, and embedded it into their Office document. 12:20.160 --> 12:28.400 So this would mean that on unpatched systems, they would be able to break out of the sandbox and cause more havoc, more mayhem. 12:30.000 --> 12:37.680 Finally, if we extract the embedded macro code from the Lazarus Group document, we can see it's pretty basic. 12:37.700 --> 12:39.560 This case, it's not even encoded. 12:39.600 --> 12:41.080 So what does it do? 12:41.080 --> 12:45.900 Well, it simply downloads and executes a second stage persistent implant. 12:45.900 --> 12:52.580 That implant is named mt.dat and would give attackers persistent remote access to the system. 12:52.600 --> 13:07.380 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. 13:09.040 --> 13:19.260 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. 13:19.500 --> 13:24.900 Now let's talk about a new zero-click macro-based exploit chain. 13:26.120 --> 13:29.060 And you might be wondering, why should we do this? 13:29.160 --> 13:34.140 Well, all current macro-based attacks, in my opinion, are super lame. 13:34.300 --> 13:36.360 Let's list the ways. 13:36.360 --> 13:49.040 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. 13:49.100 --> 13:51.780 The user basically has to click enable. 13:51.800 --> 13:55.820 Most won't, which means these attacks will fail immediately out of the box. 13:55.820 --> 13:58.620 Macro code will never even be run. 13:58.780 --> 14:06.280 Also, as Microsoft has now patched Adam's sandbox escape bug, all the attacks remain sandbox. 14:06.280 --> 14:12.500 Again, means even if the user does enable the macro code, they're incredibly limited about what they can do. 14:12.500 --> 14:15.980 They can't persist code or access user files. 14:16.260 --> 14:35.020 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. 14:35.280 --> 14:39.840 So again, the current attacks, my opinion, basically useless. 14:41.580 --> 14:56.160 Now, 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. 14:56.160 --> 15:01.180 So let's walk through now this kind of zero-click exploit chain. 15:01.420 --> 15:10.740 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. 15:10.740 --> 15:13.380 So this first bug is not mine. 15:13.680 --> 15:27.180 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. 15:28.400 --> 15:30.060 That's hot. 15:30.620 --> 15:31.840 How do they do this? 15:31.840 --> 15:38.080 By abusing a incredibly old Microsoft file format called SYLK files. 15:38.080 --> 15:38.820 How old? 15:38.820 --> 15:42.670 Like from the 1980s, before I was even born. 15:43.300 --> 15:52.960 And they also used a macro language not written in VBA, but something called XLM, not XML, XLM. 15:52.960 --> 15:58.280 Now, Microsoft loves to support old file formats for compatibility reasons. 15:58.280 --> 16:05.920 So yeah, these old file formats still work even in recent versions, specifically in Excel. 16:06.760 --> 16:23.200 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. 16:23.700 --> 16:28.980 So the researchers published some great details about these older formats and some of their findings. 16:28.980 --> 16:34.840 So if you're interested, I've posted a link on the slide to their very thorough technical write-ups. 16:36.100 --> 16:40.860 So what I did was I created a simple proof of concept based on their code. 16:40.860 --> 16:44.480 We'll see a malicious document is downloaded from the internet. 16:44.480 --> 16:47.860 And when it is opened, CALC is automatically executed. 16:48.900 --> 16:54.820 Now, the main takeaway from here is that there are no macro alerts, right, no prompts, nothing. 16:54.820 --> 16:59.680 Just as soon as the document is opened, CALCulator pops. 17:01.900 --> 17:18.460 Now, 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. 17:18.460 --> 17:20.840 We can't access the user's files. 17:20.840 --> 17:22.980 This is the point of a sandbox. 17:22.980 --> 17:27.200 It contains malicious code, even if such code finds a way to execute. 17:27.540 --> 17:33.640 So, in short, we need a new sandbox escape in order to do any real damage. 17:34.180 --> 17:38.800 So I started by looking at Microsoft's patch for Adam's bug. 17:39.100 --> 17:43.800 And I noticed that they actually didn't fix the faulty regex. 17:43.800 --> 17:59.680 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. 18:00.060 --> 18:09.440 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. 18:09.440 --> 18:15.120 Again, almost anywhere because Microsoft added some specific locations that they blocked. 18:16.880 --> 18:24.380 Now, our goal, of course, is to execute something outside the sandbox so we can persist and do evil things. 18:24.380 --> 18:33.200 We just noted we can write specially named files to arbitrary locations from macro code that's running within the context of the sandbox. 18:33.200 --> 18:35.700 As Microsoft didn't fully patch that. 18:36.080 --> 18:44.460 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. 18:44.460 --> 18:48.380 Now, these scripts themselves will be sandboxed, right? 18:48.380 --> 18:53.700 They're children of a sandbox process, which means themselves are also sandboxed. 18:53.700 --> 18:55.780 But that's still a start, right? 18:55.780 --> 19:03.460 We can execute, for example, Python scripts, which gives us a very extensible programming language to perhaps do some sorts of evil things. 19:05.140 --> 19:15.680 So via a Python script, which we, again, download and execute within the sandbox, we can create something called a login item. 19:16.120 --> 19:21.620 Now, login items are automatically executed the next time the user logs in. 19:21.640 --> 19:29.320 And since it started by Mac OS, instead of us via the sandbox, it's not going to be sandbox. 19:29.380 --> 19:37.120 So when the user's logging in, Mac OS goes and looks at the register login items and just executes and starts all of them. 19:37.120 --> 19:43.280 Again, there's no tie back to the Microsoft Office macro code, the sandbox, nothing. 19:43.360 --> 19:47.660 So that means this will be executed outside the context of the sandbox. 19:48.040 --> 19:51.640 To confirm, we can persist terminal.app. 19:51.640 --> 19:55.920 Sure enough, when we re-log in, terminal is executed. 19:55.920 --> 20:01.780 And when we look at it in Activity Monitor, we can see that it runs outside the sandbox. 20:03.240 --> 20:05.220 So this is good, right? 20:05.220 --> 20:07.700 We now have a way to bypass the sandbox. 20:07.700 --> 20:18.700 But unfortunately, we run smack into Catalina's new security mechanisms, which are file quarantines and new notarization requirements. 20:18.700 --> 20:24.840 In a nutshell, notarization basically says, hey, Apple has to bless the file before it's run. 20:24.840 --> 20:28.120 Obviously, Apple's not going to bless our back door. 20:28.120 --> 20:37.240 So even if we go and persist the back door as a login item, Mac OS will simply refuse to execute it because, unfortunately, it is not blessed. 20:37.240 --> 20:38.560 It is not notarized. 20:39.880 --> 20:41.840 This is a bummer. 20:42.180 --> 20:43.680 And so what do we do, right? 20:43.680 --> 20:48.020 We got to figure out a way to bypass now quarantine and notarization. 20:48.640 --> 20:51.980 Now, hope is not lost, right? 20:52.200 --> 20:59.160 This is 2020, things look bleak, but we got to stay optimistic, especially when we are looking and developing exploits. 20:59.160 --> 21:13.100 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. 21:13.820 --> 21:17.520 Now, this is a big if, but again, there's a few kind of takeaways here. 21:17.520 --> 21:20.180 First, being able to specify arguments is huge. 21:20.740 --> 21:37.400 And then also, if we can specify or persist rather an interactive shell, it's going to be running outside the sandbox, which is going to do things like allow us to remove quarantine attributes, which means that notarization checks will not even be performed. 21:38.180 --> 21:39.780 This would be great. 21:39.780 --> 21:48.200 But recall that Microsoft's patch for Adam's bug explicitly blocks the creation of launch agents. 21:48.560 --> 21:49.640 Bummer. 21:50.140 --> 21:55.000 So we kind of have like all these pieces, but we just can't quite put them together. 21:55.440 --> 21:56.540 Frustrating. 21:56.540 --> 22:03.300 So we can escape the sandbox via a login item, but login items can't take arguments. 22:03.300 --> 22:08.060 And they also can't be a random binary because notarization will block it. 22:08.060 --> 22:12.640 So in other words, all we can do is persist an Apple binary. 22:12.640 --> 22:14.980 Again, with no arguments. 22:15.080 --> 22:25.140 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. 22:25.240 --> 22:36.240 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. 22:37.860 --> 22:40.040 This is where things get beautiful. 22:40.060 --> 22:42.320 So I had a random idea. 22:42.320 --> 22:47.320 What happens if you create a login item that is not a binary or an application? 22:47.320 --> 22:50.580 Like, what happens if you persist a zip file? 22:50.580 --> 22:52.500 How does the system handle that? 22:52.500 --> 22:55.400 Again, recall we can create these login items from the sandbox. 22:55.400 --> 22:58.260 They can't take arguments and they can't be random binaries. 22:58.260 --> 23:03.420 But what happens if we persist a zip file, right? 23:03.560 --> 23:18.060 Well, it turns out on login, the file's default handler will be invoked, which for a zip file, macOS will automatically execute the Apple's archive utility to unzip the file. 23:18.060 --> 23:23.560 Basically says, okay, this is not an executable, so I'm going to invoke the handler. 23:23.560 --> 23:29.120 In this case, it's the archive utility because we persisted a zip file, which will extract that. 23:29.300 --> 23:40.440 Now, remember we want to create a launch agent, but due to Microsoft's recent patch, we cannot directly write to the user's launch agent directory. 23:40.980 --> 23:50.320 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. 23:50.320 --> 23:53.120 This is allowed from the sandbox. 23:53.720 --> 24:02.020 So now we can place the zip file in the library directory, and we can persist this as a login item. 24:02.140 --> 24:03.780 So we're making progress. 24:03.780 --> 24:05.260 So what do we put in the zip file? 24:05.260 --> 24:08.340 A directory named launch agents. 24:08.360 --> 24:11.980 And in that, a launch agent property list. 24:12.060 --> 24:20.400 So now when we persist this zip file as a login item, on next login, the archive utility will automatically be invoked. 24:20.400 --> 24:36.400 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. 24:37.500 --> 24:39.080 That is awesome. 24:39.080 --> 24:41.680 So this completes the full exploit chain. 24:41.680 --> 24:49.140 The user starts by opening this SLK file containing the XLM macro, which will execute automatically. 24:49.140 --> 24:51.780 Again, no alert, so just open the document. 24:52.580 --> 24:58.680 This downloads and persists the specially crafted zip file as a login item. 24:58.680 --> 25:08.540 On next login, the archive utility will be automatically invoked, and in the background, we'll extract this zip file, thereby creating a launch agent for us. 25:08.540 --> 25:21.480 And on next login, the login agent will be automatically executed with our arguments, which we can put in the property list, and we'll execute our bash-based interactive backdoor. 25:22.620 --> 25:30.300 So this bash backdoor runs outside the sandbox, meaning it can download and unquarantine files. 25:30.300 --> 25:35.640 Unquarantine files are not constrained by Apple's notarization requirements. 25:35.640 --> 25:39.820 So we have this interactive shell outside of the sandbox. 25:40.220 --> 25:41.560 What do we do? 25:41.560 --> 25:44.320 Well, we decided to persist something. 25:44.320 --> 25:51.180 And I thought it'd be extra funny to persist a repurposed, clearly not notarized version of Wingtail. 25:51.180 --> 25:58.420 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. 25:59.820 --> 26:09.400 All right, so let's now talk, kind of shift gears and talk about defending against these attacks and some generic methods of detection. 26:10.320 --> 26:18.020 First thing, as a responsible security researcher, I reported all these vulnerabilities to Microsoft and Apple. 26:18.160 --> 26:22.880 Microsoft responded and said, this is a known issue on the Apple side. 26:22.880 --> 26:26.400 And I was like, well, yeah, because I told Apple as well. 26:26.400 --> 26:31.600 So I have no idea what Microsoft did, no CDE, no bug bounty. 26:31.600 --> 26:32.360 Bummer. 26:32.620 --> 26:37.400 Apple said, thank you for your report, and then nothing. 26:38.000 --> 26:46.140 I waited a long time and checked back in with Apple and said, oh, yeah, we patched that back in, you know, 10.15.3. 26:46.140 --> 26:51.520 Again, no CDE, no bug bounty, classic Cupertino. 26:53.600 --> 27:01.100 Let's talk briefly, though, about how to detect this, these attacks and perhaps other Mac malware as well. 27:01.340 --> 27:07.820 So the first thing let's talk about is process monitoring, leveraging Apple's new endpoint security framework. 27:08.360 --> 27:14.560 It turns out it's pretty easy to create a process monitor to detect something I call suspicious children. 27:15.120 --> 27:17.560 Suspicious children processes. 27:17.560 --> 27:28.160 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. 27:28.520 --> 27:40.660 So regardless of the reason, you know, of the exploit, if it was a macro, buffer overflow, if you see Excel spawning curl and then Python, you know, that's bad news. 27:40.660 --> 27:42.780 Something is amiss. 27:44.340 --> 27:53.660 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. 27:53.660 --> 28:05.680 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. 28:05.680 --> 28:13.580 So again, we can use Apple's new endpoint security framework and we can monitor for files specifically related for ones to persistence. 28:13.840 --> 28:27.920 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. 28:27.920 --> 28:34.600 This is a huge red flag and kind of, you know, shows that our exploit is executed. 28:36.200 --> 28:42.480 So at Jamf, we implement such monitoring logic in a framework we call MonitorKit. 28:42.480 --> 28:51.960 We then feed that monitoring data, as well as our analytics and rules, into Apple's game logic engine for evaluation. 28:51.960 --> 28:59.120 This gives us a powerful endpoint detection capability, uniquely tailored for macOS. 28:59.120 --> 29:07.560 And kind of neat, not to really brag, but based on our current rules, we were actually able to detect this exploit chain with no a priori knowledge. 29:08.000 --> 29:08.960 Pretty neat. 29:10.000 --> 29:12.820 All right, so let's wrap everything up. 29:13.160 --> 29:19.140 So today we kind of talked about the current state of affairs in the land of macro-based attacks. 29:19.140 --> 29:26.160 And we showed that they are becoming more and more popular in the sense of targeting specifically macOS users. 29:26.160 --> 29:30.020 But luckily, current attacks are rather light. 29:30.020 --> 29:49.840 However, we should not be lulled into a sense of complacency because we showed it was 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. 29:49.840 --> 29:54.160 Again, at the time, on a fully patched macOS system. 29:54.280 --> 30:02.760 However, we ended by showing that by leveraging Apple's new endpoint security framework, we can generically detect these and other attacks. 30:03.680 --> 30:07.080 I really want to thank a variety of people. 30:07.080 --> 30:10.560 First and foremost, you all for virtually attending my talk. 30:10.560 --> 30:12.520 Hope you're all staying safe and healthy. 30:12.640 --> 30:16.520 Also to Jamf for putting up with my many shenanigans. 30:16.660 --> 30:20.860 And also all the amazing companies that support Objective-C. 30:21.860 --> 30:23.740 Oh, and one more thing. 30:23.740 --> 30:29.060 Today I am announcing my new book, The Art of Mac Malware Analysis. 30:29.060 --> 30:32.020 My dog is very excited about it as well. 30:32.480 --> 30:40.940 I've published the first part online at taumm.org, and the rest of the chapters will be published shortly as well. 30:41.360 --> 30:43.020 All 100% free. 30:43.020 --> 30:44.240 Sharing is caring. 30:44.260 --> 30:53.640 So if you're interested in learning more about Mac malware, exploits, persistence, debuggers, disassembling, check out the site. 30:54.280 --> 30:55.920 So again, that is a wrap. 30:55.920 --> 30:58.060 Thank you so much for attending my talk.