[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:10.780]  I am a Principal Security Researcher at Jamf,
[00:10.780 --> 00:14.020]  and also the creator of the Mac security website
[00:14.020 --> 00:16.460]  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:29.180]  First, we're going to detail recent attacks targeting Mac users,
[00:29.180 --> 00:33.020]  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:40.300]  For example, how to extract the embedded macros,
[00:40.300 --> 00:44.140]  and also how to analyze the document payloads.
[00:44.440 --> 00:49.160]  As the current attacks are kind of lame, somewhat constrained,
[00:49.160 --> 00:53.680]  for example, by the sandbox, I wanted to dig into this a little more.
[00:53.680 --> 00:57.100]  And we'll talk today about a new exploit chain
[00:57.100 --> 01:02.740]  that combines what was at the time a handful of zero days
[01:02.740 --> 01:07.480]  to bypass the sandbox and Apple's latest security mechanisms.
[01:07.480 --> 01:09.980]  We'll end by discussing generic methods
[01:09.980 --> 01:12.780]  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:19.560]  We're going to start by looking at recent macro-based attacks
[01:19.560 --> 01:22.020]  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:35.280]  But in short, a macro is embedded executable code
[01:35.280 --> 01:38.040]  in Microsoft Office documents.
[01:38.040 --> 01:40.820]  In other words, it allows one, as I mentioned,
[01:40.820 --> 01:45.180]  to add executable code into a file, into a document.
[01:45.680 --> 01:48.300]  So as we can see on the slide, what I've done
[01:48.300 --> 01:52.480]  is I've inserted a macro into a Word document
[01:52.480 --> 01:55.220]  that will display a pop-up that says,
[01:55.220 --> 01:56.480]  Hello World.
[01:56.560 --> 02:00.920]  Now, we'll talk about this more later in the talk.
[02:00.920 --> 02:05.540]  But since I've placed this code within the auto-open subroutine,
[02:05.540 --> 02:10.120]  if the user has enabled macro, this code will be automatically executed
[02:10.120 --> 02:12.860]  anytime they open the document.
[02:13.840 --> 02:17.120]  Now, from a security point of view, you might be thinking,
[02:17.120 --> 02:19.740]  this sounds like a horrible idea.
[02:19.740 --> 02:21.640]  And you're right.
[02:22.120 --> 02:25.180]  Placing executable code within documents,
[02:25.180 --> 02:30.620]  really just a terrible idea, which attackers have abused for years.
[02:30.620 --> 02:33.600]  In fact, the infamous Melissa virus,
[02:33.600 --> 02:37.200]  which was around all the way back in 1999,
[02:37.200 --> 02:39.540]  you guessed it, was a macro virus.
[02:40.040 --> 02:44.400]  Now, to be fair, Microsoft has added some mitigations,
[02:44.400 --> 02:47.720]  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 --> 02:56.980]  So traditionally, these macro-based attacks
[02:56.980 --> 03:02.540]  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:11.260]  That is, they're not going to work in Apple's Office apps,
[03:11.260 --> 03:13.880]  such as Pages or Numbers.
[03:14.260 --> 03:17.760]  And then Windows computers, especially in the past,
[03:17.760 --> 03:22.000]  were far more prevalent, especially in the enterprise.
[03:22.600 --> 03:24.280]  Now, this is definitely changing.
[03:24.280 --> 03:27.740]  We're seeing a lot more Macs, especially in the startup scene
[03:27.740 --> 03:30.180]  and also in the enterprise as well.
[03:30.680 --> 03:33.200]  And so in short, there are more Macs
[03:33.200 --> 03:36.800]  and a lot of them are running these Microsoft Office products,
[03:36.800 --> 03:40.120]  which means there's just more targets for hackers.
[03:42.000 --> 03:46.780]  So now let's take a look at some recent attacks targeting Mac users,
[03:46.780 --> 03:50.960]  attacks that leverage macro-laced documents.
[03:51.500 --> 03:52.820]  So first in this section,
[03:52.820 --> 03:56.240]  we're going to kind of look at these at a high level.
[03:56.240 --> 03:58.000]  In the next section, though, we're going to dive
[03:58.000 --> 04:01.200]  into discussing exactly how to extract
[04:01.200 --> 04:06.020]  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:11.660]  Here we have a document that appears to be
[04:11.660 --> 04:15.240]  about Trump's unfortunate election victory.
[04:15.740 --> 04:18.440]  If the user, though, went to open this document
[04:18.440 --> 04:22.860]  and clicked allow on the enabled macro alert,
[04:22.860 --> 04:25.820]  the system would become infected because in reality,
[04:25.820 --> 04:29.460]  this was a malicious document containing malicious macros.
[04:31.180 --> 04:36.460]  Moving on to 2018, we have a document that appears to be about Bitcoin,
[04:36.460 --> 04:40.120]  which was a very hot, trendy topic at the time.
[04:40.120 --> 04:45.040]  Again, if the user opens the document and allows macros to run,
[04:45.040 --> 04:47.040]  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 --> 04:54.540]  But the most interesting aspect of this attack
[04:54.540 --> 04:59.480]  was that the embedded exploit code contained the ability
[04:59.480 --> 05:03.260]  to actually bypass Microsoft Office's sandbox.
[05:04.560 --> 05:11.240]  Moving on to 2019, we have a document from the prolific Lazarus APT group,
[05:11.240 --> 05:14.320]  which is normally associated with North Korea.
[05:15.040 --> 05:18.880]  This is interesting because we're actually now seeing APT groups
[05:18.880 --> 05:24.120]  jump on the, hey, let's target macOS via macros bandwagon.
[05:24.120 --> 05:27.420]  Again, if the user opens the document and clicks allow,
[05:27.420 --> 05:29.260]  the system will be owned.
[05:31.260 --> 05:33.260]  All right, so now let's talk about methods
[05:33.260 --> 05:36.240]  of analyzing these malicious documents,
[05:36.240 --> 05:39.940]  showing exactly how to extract embedded macros
[05:39.940 --> 05:43.360]  and how to analyze both the macro code
[05:43.360 --> 05:46.980]  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 --> 05:58.380]  Now, the details of the file format of Microsoft Office documents
[05:58.380 --> 06:01.180]  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:07.940]  Turns out there are some really great tools that are able to,
[06:07.940 --> 06:10.880]  if given a Office document with macros,
[06:10.880 --> 06:12.880]  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:31.000]  And then we execute the OLE VBA command with a dash C parameter,
[06:31.000 --> 06:32.580]  passing in the document,
[06:32.580 --> 06:36.560]  which we suspect has embedded macros that we want to analyze.
[06:36.560 --> 06:40.880]  And the OLE VBA tool will then parse the document
[06:40.880 --> 06:45.140]  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:05.800]  So let's briefly return to the documents
[07:05.800 --> 07:08.960]  that we discussed in the first part of the talk.
[07:08.960 --> 07:10.560]  And for each of these,
[07:10.560 --> 07:15.600]  look at exactly what the malicious macro code is doing.
[07:15.760 --> 07:18.480]  So again, starting at the one from 2018,
[07:18.480 --> 07:22.680]  we can use the OLE VBA tool to extract the macros.
[07:22.680 --> 07:24.400]  And I've cleaned up the macros a little bit
[07:24.400 --> 07:27.000]  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:45.580]  And as its name implies, any code placed within this API
[07:45.580 --> 07:47.880]  will be automatically executed,
[07:47.880 --> 07:52.980]  if and only if the user has enabled macros when opening the document.
[07:53.100 --> 07:57.480]  So if we assume the user has clicked allow to the embedded macros,
[07:57.480 --> 08:00.220]  let's look at what the Fisher subroutine does.
[08:00.220 --> 08:02.360]  Again, as it will be automatically executed
[08:02.360 --> 08:05.280]  each time the document is opened.
[08:06.160 --> 08:10.740]  So the first thing it does is it builds a base 64 encoded string,
[08:10.740 --> 08:14.300]  and then it decodes and executes that via Python.
[08:15.740 --> 08:20.460]  If we manually decode this string, we can see it's Python code,
[08:20.460 --> 08:24.580]  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:29.460]  Well, the first thing it does is it checks
[08:29.460 --> 08:32.600]  to see if popular security products, for example,
[08:32.600 --> 08:34.080]  little snitch is running.
[08:34.080 --> 08:36.860]  And then it downloads a second stage payload
[08:36.860 --> 08:39.920]  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:54.460]  And that's because this payload is actually Empire,
[08:54.460 --> 08:58.120]  which is a well-known open source Python backdoor.
[08:58.400 --> 09:00.160]  Now, you might be wondering, okay,
[09:00.160 --> 09:04.380]  what is it downloading and executing as its second stage payload?
[09:04.740 --> 09:07.980]  Well, unfortunately, the command and control server
[09:07.980 --> 09:10.860]  was offline at the time I did this analysis,
[09:10.860 --> 09:15.220]  but it's likely that it's simply Empire's second stage payload,
[09:15.220 --> 09:19.100]  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:33.540]  Interestingly, this also contains encoded Python
[09:33.880 --> 09:37.480]  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:52.000]  You can either do that via an online site
[09:52.000 --> 09:54.460]  that provides base64 decoding,
[09:54.460 --> 09:58.260]  or I just do it via the command line via a Python shell.
[09:58.640 --> 10:03.000]  Once the code is decoded, again, we can see that on this slide,
[10:03.000 --> 10:05.680]  it connects to an IP address,
[10:05.680 --> 10:09.260]  executes and downloads a second stage payload.
[10:09.700 --> 10:11.640]  Turns out this command and control server
[10:11.640 --> 10:15.320]  was still online during the time of my analysis,
[10:15.320 --> 10:19.880]  so I was actually able to get a copy of this second stage payload,
[10:19.880 --> 10:23.260]  which turned out to be Metasploit's Meterpreter.
[10:23.260 --> 10:27.360]  Again, interesting to see attackers leveraging open source agents
[10:27.360 --> 10:29.240]  in second stage payload.
[10:29.240 --> 10:33.920]  Meterpreter affords remote access of an infected system.
[10:35.320 --> 10:38.220]  Now, if you recall the beginning of the talk,
[10:38.220 --> 10:40.280]  we kind of said that the most interesting thing
[10:40.280 --> 10:42.260]  about this particular document
[10:42.260 --> 10:47.840]  was its ability to escape out of Microsoft Office's sandbox.
[10:47.840 --> 10:52.700]  So recent versions of Office run in a sandbox, which is good,
[10:52.700 --> 10:58.020]  and it means that if code is executed within the context of the process,
[10:58.020 --> 11:01.860]  for example, macro code executing within a Word document,
[11:01.860 --> 11:05.520]  it is highly contained. It's limited by what it can do.
[11:05.520 --> 11:07.460]  It's still in the sandbox.
[11:07.540 --> 11:10.140]  So it can't do things like persist the backdoor
[11:10.140 --> 11:12.580]  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:19.440]  However, Mac security researcher Adam Chester
[11:19.440 --> 11:22.360]  found a very neat way to escape the sandbox
[11:22.360 --> 11:27.900]  and posted a guest blog about this on my Mac security website, Objective-C.
[11:28.040 --> 11:33.680]  In short, we found that Microsoft Office had a sandbox exception
[11:34.000 --> 11:36.600]  that was based on a faulty regX
[11:36.600 --> 11:41.960]  that would allow sandbox code to create a file anywhere on the system.
[11:41.960 --> 11:45.540]  So what Adam was able to do was, via macro code
[11:45.540 --> 11:48.380]  running in the context of the sandbox,
[11:48.380 --> 11:52.620]  create a launch item that on the next login
[11:52.620 --> 11:55.820]  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:04.160]  So I was analyzing this document. 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:11.920]  And it turns out that the attackers had likely also read this blog
[12:11.920 --> 12:17.180]  and took Adam's code for verbatim, 100% copy and paste,
[12:17.180 --> 12:20.160]  and embedded it into their Office document.
[12:20.160 --> 12:23.160]  So this would mean that on unpatched systems,
[12:23.160 --> 12:25.320]  they would be able to break out of the sandbox
[12:25.320 --> 12:28.400]  and cause more havoc, more mayhem.
[12:30.000 --> 12:33.260]  Finally, if we extract the embedded macro code
[12:33.260 --> 12:37.680]  from the Lazarus Group document, we can see it's pretty basic.
[12:37.700 --> 12:41.080]  This case, it's not even encoded. 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:48.440]  That implant is named mt.dat
[12:48.440 --> 12:52.580]  and would give attackers persistent remote access to the system.
[12:52.600 --> 12:56.580]  However, this document did not have any sandbox escape code,
[12:56.580 --> 13:00.060]  which means if it was opened on a recent version of macOS,
[13:00.060 --> 13:02.080]  this part of the attack would fail
[13:02.080 --> 13:04.800]  because you can't obviously persist code
[13:04.800 --> 13:07.380]  from within the context of a sandbox.
[13:09.040 --> 13:13.380]  So that's an overview of recent macro-based attacks against macOS,
[13:13.380 --> 13:19.260]  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:40.940]  First, for any of these attacks, when the user goes to open the document,
[13:40.940 --> 13:45.620]  there's a huge alert warning them that this document contains macros
[13:45.620 --> 13:49.040]  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:04.180]  Also, as Microsoft has now patched Adam's sandbox escape bug,
[14:04.180 --> 14:06.280]  all the attacks remain sandbox.
[14:06.280 --> 14:10.100]  Again, means even if the user does enable the macro code,
[14:10.100 --> 14:12.500]  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:21.200]  And then finally, on macOS Catalina, the most recent version of macOS,
[14:21.200 --> 14:22.900]  Apple has really upped the bar
[14:22.900 --> 14:25.420]  and introduced some new security mechanisms,
[14:25.420 --> 14:29.940]  such as notarization, which means the second stage payloads
[14:29.940 --> 14:35.020]  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:46.340]  Now, whenever companies such as Microsoft or Apple patch stuff
[14:46.340 --> 14:50.220]  or implement new security mechanisms, I like to poke on that
[14:50.700 --> 14:56.160]  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:03.200]  So the exploit starts with a really neat bug
[15:03.200 --> 15:06.660]  that was found a while ago by two security researchers
[15:06.660 --> 15:10.740]  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:19.160]  What these researchers found was that even if macros are turned off,
[15:19.160 --> 15:22.340]  they could create a document that contained macros
[15:22.340 --> 15:25.960]  that would be automatically executed with no alerts,
[15:25.960 --> 15:30.060]  no prompts. 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:42.670]  How old? Like from the 1980s, before I was even born.
[15:43.300 --> 15:47.180]  And they also used a macro language not written in VBA,
[15:47.180 --> 15:52.960]  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:03.940]  So yeah, these old file formats still work even in recent versions,
[16:03.940 --> 16:05.920]  specifically in Excel.
[16:06.760 --> 16:10.520]  So as I mentioned, the researchers found that they could create
[16:10.520 --> 16:16.240]  these XLM macros in these SYLK file formats
[16:16.240 --> 16:18.900]  that would be automatically executed,
[16:18.900 --> 16:23.200]  ironically, if the user had set never run macros to true.
[16:23.700 --> 16:26.460]  So the researchers published some great details
[16:26.460 --> 16:28.980]  about these older formats and some of their findings.
[16:28.980 --> 16:32.020]  So if you're interested, I've posted a link on the slide
[16:32.020 --> 16:34.840]  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:53.180]  Now, the main takeaway from here is that there are no macro alerts,
[16:53.180 --> 16:54.820]  right, no prompts, nothing.
[16:54.820 --> 16:59.680]  Just as soon as the document is opened, CALCulator pops.
[17:01.900 --> 17:04.040]  Now, that's well and good,
[17:04.040 --> 17:08.500]  but as we noted on recent versions of Microsoft Office,
[17:08.500 --> 17:13.520]  the applications are sandboxed, meaning, sure, we can pop CALCulator
[17:13.520 --> 17:18.460]  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:24.680]  This is the point of a sandbox. It contains malicious code,
[17:24.680 --> 17:27.200]  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:47.820]  Instead, they just simply blocked certain locations,
[17:47.820 --> 17:50.460]  such as the launch agent directory,
[17:50.460 --> 17:54.180]  which is where Adam's proof of concept created a launch agent,
[17:54.180 --> 17:56.080]  which on the next login would be executed
[17:56.080 --> 17:59.680]  outside the context of the sandbox.
[18:00.060 --> 18:02.640]  So this means we can create arbitrary files
[18:02.640 --> 18:05.440]  as long as they start with tilde dollar sign,
[18:05.440 --> 18:09.440]  meaning they conform to this faulty regex, almost anywhere.
[18:09.440 --> 18:11.440]  Again, almost anywhere because Microsoft
[18:11.440 --> 18:15.120]  added some specific locations that they blocked.
[18:16.880 --> 18:18.520]  Now, our goal, of course,
[18:18.520 --> 18:20.840]  is to execute something outside the sandbox
[18:20.840 --> 18:24.380]  so we can persist and do evil things.
[18:24.380 --> 18:26.780]  We just noted we can write specially named files
[18:26.780 --> 18:30.300]  to arbitrary locations from macro code
[18:30.300 --> 18:33.200]  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:38.680]  Also, it turns out in the sandbox,
[18:38.680 --> 18:41.260]  we can both download and execute scripts,
[18:41.260 --> 18:44.460]  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:50.500]  They're children of a sandbox process,
[18:50.500 --> 18:53.700]  which means themselves are also sandboxed.
[18:53.700 --> 18:55.780]  But that's still a start, right?
[18:55.780 --> 18:58.500]  We can execute, for example, Python scripts,
[18:58.500 --> 19:01.300]  which gives us a very extensible programming language
[19:01.300 --> 19:03.460]  to perhaps do some sorts of evil things.
[19:05.140 --> 19:07.060]  So via a Python script,
[19:07.060 --> 19:11.800]  which we, again, download and execute within the sandbox,
[19:11.800 --> 19:15.680]  we can create something called a login item.
[19:16.120 --> 19:19.040]  Now, login items are automatically executed
[19:19.040 --> 19:21.620]  the next time the user logs in.
[19:21.640 --> 19:27.320]  And since it started by Mac OS, instead of us via the sandbox,
[19:27.320 --> 19:29.320]  it's not going to be sandbox.
[19:29.380 --> 19:31.200]  So when the user's logging in,
[19:31.200 --> 19:34.200]  Mac OS goes and looks at the register login items
[19:34.200 --> 19:37.120]  and just executes and starts all of them.
[19:37.120 --> 19:41.500]  Again, there's no tie back to the Microsoft Office macro code,
[19:41.500 --> 19:43.280]  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 --> 19:59.280]  And when we look at it in Activity Monitor,
[19:59.280 --> 20:01.780]  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:13.740]  But unfortunately, we run smack into Catalina's new security mechanisms,
[20:13.740 --> 20:18.700]  which are file quarantines and new notarization requirements.
[20:18.700 --> 20:21.300]  In a nutshell, notarization basically says,
[20:21.300 --> 20:24.840]  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:32.460]  So even if we go and persist the back door as a login item,
[20:32.460 --> 20:34.900]  Mac OS will simply refuse to execute it
[20:34.900 --> 20:37.240]  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:55.720]  This is 2020, things look bleak, but we got to stay optimistic,
[20:55.720 --> 20:59.160]  especially when we are looking and developing exploits.
[20:59.160 --> 21:04.360]  Because if, and this is a big if, if we can create a launch agent,
[21:04.360 --> 21:08.480]  we can specify arguments and persist
[21:08.840 --> 21:13.100]  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:26.660]  And then also, if we can specify or persist rather an interactive shell,
[21:26.660 --> 21:29.020]  it's going to be running outside the sandbox,
[21:29.020 --> 21:33.680]  which is going to do things like allow us to remove quarantine attributes,
[21:33.680 --> 21:37.400]  which means that notarization checks will not even be performed.
[21:38.180 --> 21:39.780]  This would be great.
[21:39.780 --> 21:43.680]  But recall that Microsoft's patch for Adam's bug
[21:43.680 --> 21:48.200]  explicitly blocks the creation of launch agents.
[21:48.560 --> 21:49.640]  Bummer.
[21:50.140 --> 21:52.620]  So we kind of have like all these pieces,
[21:52.620 --> 21:55.000]  but we just can't quite put them together.
[21:55.440 --> 21:56.540]  Frustrating.
[21:56.540 --> 22:00.400]  So we can escape the sandbox via a login item,
[22:00.400 --> 22:03.300]  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:19.880]  And sure, we can bypass notarization by the creation of a launch agent,
[22:19.880 --> 22:25.140]  but we can't create one from the sandbox due to Microsoft's partial patch.
[22:25.240 --> 22:28.900]  So in other words, what we need is a way for the system
[22:28.900 --> 22:32.260]  or for an Apple binary with no arguments
[22:32.260 --> 22:36.240]  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:44.640]  What happens if you create a login item
[22:44.640 --> 22:47.320]  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:06.560]  Well, it turns out on login,
[23:06.560 --> 23:09.720]  the file's default handler will be invoked,
[23:09.720 --> 23:13.780]  which for a zip file, macOS will automatically execute
[23:13.780 --> 23:18.060]  the Apple's archive utility to unzip the file.
[23:18.060 --> 23:21.080]  Basically says, okay, this is not an executable,
[23:21.080 --> 23:23.560]  so I'm going to invoke the handler.
[23:23.560 --> 23:27.180]  In this case, it's the archive utility because we persisted a zip file,
[23:27.180 --> 23:29.120]  which will extract that.
[23:29.300 --> 23:32.840]  Now, remember we want to create a launch agent,
[23:32.840 --> 23:36.740]  but due to Microsoft's recent patch,
[23:36.740 --> 23:40.440]  we cannot directly write to the user's launch agent directory.
[23:40.980 --> 23:44.820]  But if it doesn't exist, which on a default version of macOS it does not,
[23:44.820 --> 23:50.320]  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 --> 23:57.360]  So now we can place the zip file in the library directory,
[23:57.360 --> 24:02.020]  and we can persist this as a login item.
[24:02.140 --> 24:03.780]  So we're making progress.
[24:03.780 --> 24:08.340]  So what do we put in the zip file? A directory named launch agents.
[24:08.360 --> 24:11.980]  And in that, a launch agent property list.
[24:12.060 --> 24:15.560]  So now when we persist this zip file as a login item,
[24:15.560 --> 24:20.400]  on next login, the archive utility will automatically be invoked.
[24:20.400 --> 24:23.260]  This is allowed because it's an Apple sign process,
[24:23.260 --> 24:27.060]  and it will run outside the context of the sandbox,
[24:27.060 --> 24:30.700]  which means it can do things like unzip our file
[24:31.220 --> 24:33.200]  and create the launch agent directory
[24:33.200 --> 24:36.400]  and our launch agent property list for us.
[24:37.500 --> 24:41.680]  That is awesome. So this completes the full exploit chain.
[24:41.680 --> 24:46.960]  The user starts by opening this SLK file containing the XLM macro,
[24:46.960 --> 24:49.140]  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:01.840]  On next login, the archive utility will be automatically invoked,
[25:01.840 --> 25:05.220]  and in the background, we'll extract this zip file,
[25:05.220 --> 25:08.540]  thereby creating a launch agent for us.
[25:08.540 --> 25:13.160]  And on next login, the login agent will be automatically executed
[25:13.160 --> 25:17.060]  with our arguments, which we can put in the property list,
[25:17.060 --> 25:21.480]  and we'll execute our bash-based interactive backdoor.
[25:22.620 --> 25:26.400]  So this bash backdoor runs outside the sandbox,
[25:26.400 --> 25:30.300]  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:44.320]  What do we do? Well, we decided to persist something.
[25:44.320 --> 25:47.840]  And I thought it'd be extra funny to persist a repurposed,
[25:47.840 --> 25:51.180]  clearly not notarized version of Wingtail.
[25:51.180 --> 25:53.860]  And you can see on the slide, when I finally got this all working
[25:53.860 --> 25:58.420]  in the Slack channel at work, I was clearly pretty stoked.
[25:59.820 --> 26:03.240]  All right, so let's now talk, kind of shift gears
[26:03.240 --> 26:05.720]  and talk about defending against these attacks
[26:05.720 --> 26:09.400]  and some generic methods of detection.
[26:10.320 --> 26:13.820]  First thing, as a responsible security researcher,
[26:13.820 --> 26:18.020]  I reported all these vulnerabilities to Microsoft and Apple.
[26:18.160 --> 26:20.640]  Microsoft responded and said,
[26:20.640 --> 26:22.880]  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:32.360]  So I have no idea what Microsoft did, no CDE, no bug bounty. Bummer.
[26:32.620 --> 26:37.400]  Apple said, thank you for your report, and then nothing.
[26:38.000 --> 26:41.880]  I waited a long time and checked back in with Apple and said,
[26:41.880 --> 26:46.140]  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 --> 26:57.040]  Let's talk briefly, though, about how to detect this,
[26:57.040 --> 27:01.100]  these attacks and perhaps other Mac malware as well.
[27:01.340 --> 27:04.600]  So the first thing let's talk about is process monitoring,
[27:04.600 --> 27:07.820]  leveraging Apple's new endpoint security framework.
[27:08.360 --> 27:11.160]  It turns out it's pretty easy to create a process monitor
[27:11.160 --> 27:14.560]  to detect something I call suspicious children.
[27:15.120 --> 27:17.560]  Suspicious children processes.
[27:17.560 --> 27:22.300]  As we can see on the slide, we can now detect when an Office application,
[27:22.300 --> 27:28.160]  for example, Excel, spawns a child process that is, well, suspicious.
[27:28.520 --> 27:32.260]  So regardless of the reason, you know, of the exploit,
[27:32.260 --> 27:34.120]  if it was a macro, buffer overflow,
[27:34.120 --> 27:40.660]  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:47.060]  We can also detect a wide range of attacks,
[27:47.060 --> 27:50.100]  including the exploit chain we just talked about this,
[27:50.100 --> 27:53.660]  by monitoring the file system for persistence.
[27:53.660 --> 27:55.780]  Persistence is just the way that malware
[27:55.780 --> 27:58.820]  or perhaps an exploit chain escapes out of the sandbox
[27:59.100 --> 28:01.580]  or ensures that it's automatically re-executed
[28:01.580 --> 28:05.680]  when the system is rebooted or the user re-logs in.
[28:05.680 --> 28:08.420]  So again, we can use Apple's new endpoint security framework
[28:08.420 --> 28:13.580]  and we can monitor for files specifically related for ones to persistence.
[28:13.840 --> 28:15.480]  So here, for example, on the slide,
[28:15.480 --> 28:19.480]  we can detect now that a login item was created
[28:19.480 --> 28:23.200]  that does not point to an application or a binary,
[28:23.200 --> 28:26.040]  which is normally the case when a login item is created,
[28:26.040 --> 28:27.920]  but instead to a zip file.
[28:27.920 --> 28:30.660]  This is a huge red flag and kind of, you know,
[28:30.660 --> 28:34.600]  shows that our exploit is executed.
[28:36.200 --> 28:39.900]  So at Jamf, we implement such monitoring logic
[28:39.900 --> 28:42.480]  in a framework we call MonitorKit.
[28:42.480 --> 28:47.960]  We then feed that monitoring data, as well as our analytics and rules,
[28:47.960 --> 28:51.960]  into Apple's game logic engine for evaluation.
[28:51.960 --> 28:56.160]  This gives us a powerful endpoint detection capability,
[28:56.160 --> 28:59.120]  uniquely tailored for macOS.
[28:59.120 --> 29:02.580]  And kind of neat, not to really brag, but based on our current rules,
[29:02.580 --> 29:05.320]  we were actually able to detect this exploit chain
[29:05.320 --> 29:08.960]  with no a priori knowledge. Pretty neat.
[29:10.000 --> 29:12.820]  All right, so let's wrap everything up.
[29:13.160 --> 29:16.700]  So today we kind of talked about the current state of affairs
[29:16.700 --> 29:19.140]  in the land of macro-based attacks.
[29:19.140 --> 29:22.400]  And we showed that they are becoming more and more popular
[29:22.400 --> 29:26.160]  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:33.460]  However, we should not be lulled into a sense of complacency
[29:33.460 --> 29:35.920]  because we showed it was pretty easy
[29:35.920 --> 29:39.520]  to actually create a zero-click exploit chain
[29:39.520 --> 29:42.820]  that, if the user would open a document,
[29:42.820 --> 29:45.000]  would both escape the sandbox
[29:45.000 --> 29:49.840]  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 --> 29:56.220]  However, we ended by showing that by leveraging
[29:56.220 --> 29:58.920]  Apple's new endpoint security framework,
[29:58.920 --> 30:02.760]  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:26.260]  Today I am announcing my new book,
[30:26.260 --> 30:29.060]  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:37.640]  I've published the first part online at taumm.org,
[30:37.640 --> 30:40.940]  and the rest of the chapters will be published shortly as well.
[30:41.360 --> 30:44.240]  All 100% free. Sharing is caring.
[30:44.260 --> 30:48.060]  So if you're interested in learning more about Mac malware,
[30:48.060 --> 30:51.540]  exploits, persistence, debuggers, disassembling,
[30:51.540 --> 30:53.640]  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.