1
00:00:00,600 --> 00:00:04,740
Aloha, and welcome to my talk, Office Drama on macOS.

2
00:00:05,680 --> 00:00:07,400
My name is Patrick Wardle.

3
00:00:07,400 --> 00: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.

4
00:00:17,980 --> 00:00:24,240
So today we're going to be talking about malicious office documents on macOS.

5
00:00:24,300 --> 00:00:33,020
First, we're going to detail recent attacks targeting Mac users, attacks that leverage macro-laced documents.

6
00:00:33,120 --> 00:00:36,640
Then we'll discuss methods of analyzing these attacks.

7
00:00:36,640 --> 00:00:44,140
For example, how to extract the embedded macros, and also how to analyze the document payloads.

8
00:00:44,440 --> 00: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.

9
00:00:53,680 --> 00: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.

10
00:01:07,480 --> 00:01:12,780
We'll end by discussing generic methods to detect and thwart some of these attacks.

11
00:01:14,000 --> 00:01:16,300
All right, so let's dive in.

12
00:01:16,300 --> 00:01:22,020
We're going to start by looking at recent macro-based attacks targeting Mac users.

13
00:01:22,840 --> 00:01:26,320
Now, first, you might be wondering, what is a macro?

14
00:01:26,320 --> 00:01:31,340
Well, I've added the official Microsoft documentation on the slide.

15
00:01:31,340 --> 00:01:38,040
But in short, a macro is embedded executable code in Microsoft Office documents.

16
00:01:38,040 --> 00:01:45,180
In other words, it allows one, as I mentioned, to add executable code into a file, into a document.

17
00:01:45,680 --> 00: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.

18
00:01:56,560 --> 00:02:00,920
Now, we'll talk about this more later in the talk.

19
00:02:00,920 --> 00: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.

20
00:02:13,840 --> 00:02:19,740
Now, from a security point of view, you might be thinking, this sounds like a horrible idea.

21
00:02:19,740 --> 00:02:21,640
And you're right.

22
00:02:22,120 --> 00:02:30,620
Placing executable code within documents, really just a terrible idea, which attackers have abused for years.

23
00:02:30,620 --> 00: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.

24
00:02:40,040 --> 00:02:47,720
Now, to be fair, Microsoft has added some mitigations, for example, alerts and sandboxing.

25
00:02:47,720 --> 00:02:52,080
But as we'll see, this has not fully mitigated the threat.

26
00:02:54,900 --> 00:03:02,540
So traditionally, these macro-based attacks have targeted Microsoft Windows systems due to two main reasons.

27
00:03:02,800 --> 00:03:08,520
First, macros are a Microsoft creation and only work in Microsoft products.

28
00:03:08,520 --> 00:03:13,880
That is, they're not going to work in Apple's Office apps, such as Pages or Numbers.

29
00:03:14,260 --> 00:03:22,000
And then Windows computers, especially in the past, were far more prevalent, especially in the enterprise.

30
00:03:22,600 --> 00:03:24,280
Now, this is definitely changing.

31
00:03:24,280 --> 00:03:30,180
We're seeing a lot more Macs, especially in the startup scene and also in the enterprise as well.

32
00:03:30,680 --> 00: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.

33
00:03:42,000 --> 00:03:50,960
So now let's take a look at some recent attacks targeting Mac users, attacks that leverage macro-laced documents.

34
00:03:51,500 --> 00:03:56,240
So first in this section, we're going to kind of look at these at a high level.

35
00:03:56,240 --> 00: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.

36
00:04:06,020 --> 00:04:08,740
So we're going to start in 2017.

37
00:04:08,740 --> 00:04:15,240
Here we have a document that appears to be about Trump's unfortunate election victory.

38
00:04:15,740 --> 00: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.

39
00:04:31,180 --> 00: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.

40
00:04:40,120 --> 00:04:47,040
Again, if the user opens the document and allows macros to run, the system is owned.

41
00:04:47,040 --> 00:04:51,480
Now this document is interesting, and we'll dig into this more shortly.

42
00:04:51,480 --> 00: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.

43
00:05:04,560 --> 00:05:14,320
Moving on to 2019, we have a document from the prolific Lazarus APT group, which is normally associated with North Korea.

44
00:05:15,040 --> 00: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.

45
00:05:24,120 --> 00:05:29,260
Again, if the user opens the document and clicks allow, the system will be owned.

46
00:05:31,260 --> 00: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.

47
00:05:48,060 --> 00:05:52,860
First, we need to be able to extract the embedded macro code.

48
00:05:53,220 --> 00:06:01,180
Now, the details of the file format of Microsoft Office documents is kind of beyond the scope of this talk.

49
00:06:01,180 --> 00:06:04,540
But the good news is you really don't have to even worry about that.

50
00:06:04,540 --> 00: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.

51
00:06:12,880 --> 00:06:15,140
And that's really basically all we care about.

52
00:06:15,520 --> 00:06:20,360
My favorite is a tool suite called OLE Tools from GitHub.

53
00:06:20,360 --> 00:06:25,120
So we can see on the slide, we downloaded the package and installed it.

54
00:06:25,120 --> 00: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.

55
00:06:36,560 --> 00:06:45,140
And the OLE VBA tool will then parse the document and dump any embedded macros to standard out.

56
00:06:45,240 --> 00:06:49,010
There's also various online sites where you can upload a document.

57
00:06:49,860 --> 00:06:54,180
The website will then do the analysis and extract any macro code.

58
00:06:56,130 --> 00:07:02,480
Now, we want to understand exactly what these malicious macros are doing.

59
00:07:02,480 --> 00:07:08,960
So let's briefly return to the documents that we discussed in the first part of the talk.

60
00:07:08,960 --> 00:07:15,600
And for each of these, look at exactly what the malicious macro code is doing.

61
00:07:15,760 --> 00:07:22,680
So again, starting at the one from 2018, we can use the OLE VBA tool to extract the macros.

62
00:07:22,680 --> 00:07:27,000
And I've cleaned up the macros a little bit and placed them on the screen.

63
00:07:27,160 --> 00:07:31,680
So we can see on the slide, there is a subroutine called Fisher.

64
00:07:32,480 --> 00:07:36,060
That is invoked via the auto open method.

65
00:07:36,060 --> 00:07:39,740
The auto open method is a Microsoft API.

66
00:07:39,780 --> 00: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.

67
00:07:53,100 --> 00: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.

68
00:08:00,220 --> 00:08:05,280
Again, as it will be automatically executed each time the document is opened.

69
00:08:06,160 --> 00: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.

70
00:08:15,740 --> 00: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.

71
00:08:24,580 --> 00:08:26,860
So what is this Python code does?

72
00:08:26,860 --> 00:08:34,080
Well, the first thing it does is it checks to see if popular security products, for example, little snitch is running.

73
00:08:34,080 --> 00:08:39,920
And then it downloads a second stage payload from securitychecking.org.

74
00:08:39,980 --> 00:08:44,980
It then decrypts this payload using RC4 and executes this.

75
00:08:45,540 --> 00:08:48,240
Now, this code might look familiar.

76
00:08:48,240 --> 00:08:50,860
You spend a lot of time kind of looking at these attacks.

77
00:08:50,860 --> 00:08:58,120
And that's because this payload is actually Empire, which is a well-known open source Python backdoor.

78
00:08:58,400 --> 00:09:04,380
Now, you might be wondering, okay, what is it downloading and executing as its second stage payload?

79
00:09:04,740 --> 00: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.

80
00:09:20,700 --> 00:09:22,960
Moving on to the Bitcoin document.

81
00:09:22,960 --> 00:09:25,360
Again, this one was from 2018.

82
00:09:25,580 --> 00:09:30,620
Using the OLE VBA tool, we can, again, extract the embedded macros.

83
00:09:30,620 --> 00:09:37,480
Interestingly, this also contains encoded Python and what appears to be an embedded property list.

84
00:09:37,520 --> 00:09:38,760
That's interesting.

85
00:09:39,780 --> 00:09:42,380
So let's take a closer look.

86
00:09:42,660 --> 00:09:45,220
First thing we do is we decode the Python.

87
00:09:45,220 --> 00:09:49,560
Since it's base64 encoded, it's very trivial to do.

88
00:09:49,560 --> 00: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.

89
00:09:58,640 --> 00: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.

90
00:10:09,700 --> 00: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.

91
00:10:23,260 --> 00:10:29,240
Again, interesting to see attackers leveraging open source agents in second stage payload.

92
00:10:29,240 --> 00:10:33,920
Meterpreter affords remote access of an infected system.

93
00:10:35,320 --> 00: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.

94
00:10:47,840 --> 00: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.

95
00:11:03,840 --> 00:11:05,520
It's limited by what it can do.

96
00:11:05,520 --> 00:11:07,460
It's still in the sandbox.

97
00:11:07,540 --> 00:11:12,580
So it can't do things like persist the backdoor or even access the user's files.

98
00:11:12,580 --> 00:11:15,340
From a security point of view, this is very good.

99
00:11:16,200 --> 00: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.

100
00:11:28,040 --> 00: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.

101
00:11:41,960 --> 00: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.

102
00:11:55,820 --> 00:12:00,260
And he used a property list in order to do that.

103
00:12:00,700 --> 00:12:02,060
So I was analyzing this document.

104
00:12:02,060 --> 00:12:04,160
I said, okay, this code looks very familiar.

105
00:12:04,160 --> 00:12:07,700
And I read Adam's blog and posted it on my site.

106
00:12:07,700 --> 00: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.

107
00:12:20,160 --> 00: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.

108
00:12:30,000 --> 00:12:37,680
Finally, if we extract the embedded macro code from the Lazarus Group document, we can see it's pretty basic.

109
00:12:37,700 --> 00:12:39,560
This case, it's not even encoded.

110
00:12:39,600 --> 00:12:41,080
So what does it do?

111
00:12:41,080 --> 00:12:45,900
Well, it simply downloads and executes a second stage persistent implant.

112
00:12:45,900 --> 00:12:52,580
That implant is named mt.dat and would give attackers persistent remote access to the system.

113
00:12:52,600 --> 00: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.

114
00:13:09,040 --> 00: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.

115
00:13:19,500 --> 00:13:24,900
Now let's talk about a new zero-click macro-based exploit chain.

116
00:13:26,120 --> 00:13:29,060
And you might be wondering, why should we do this?

117
00:13:29,160 --> 00:13:34,140
Well, all current macro-based attacks, in my opinion, are super lame.

118
00:13:34,300 --> 00:13:36,360
Let's list the ways.

119
00:13:36,360 --> 00: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.

120
00:13:49,100 --> 00:13:51,780
The user basically has to click enable.

121
00:13:51,800 --> 00:13:55,820
Most won't, which means these attacks will fail immediately out of the box.

122
00:13:55,820 --> 00:13:58,620
Macro code will never even be run.

123
00:13:58,780 --> 00:14:06,280
Also, as Microsoft has now patched Adam's sandbox escape bug, all the attacks remain sandbox.

124
00:14:06,280 --> 00:14:12,500
Again, means even if the user does enable the macro code, they're incredibly limited about what they can do.

125
00:14:12,500 --> 00:14:15,980
They can't persist code or access user files.

126
00:14:16,260 --> 00: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.

127
00:14:35,280 --> 00:14:39,840
So again, the current attacks, my opinion, basically useless.

128
00:14:41,580 --> 00: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.

129
00:14:56,160 --> 00:15:01,180
So let's walk through now this kind of zero-click exploit chain.

130
00:15:01,420 --> 00: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.

131
00:15:10,740 --> 00:15:13,380
So this first bug is not mine.

132
00:15:13,680 --> 00: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.

133
00:15:28,400 --> 00:15:30,060
That's hot.

134
00:15:30,620 --> 00:15:31,840
How do they do this?

135
00:15:31,840 --> 00:15:38,080
By abusing a incredibly old Microsoft file format called SYLK files.

136
00:15:38,080 --> 00:15:38,820
How old?

137
00:15:38,820 --> 00:15:42,670
Like from the 1980s, before I was even born.

138
00:15:43,300 --> 00:15:52,960
And they also used a macro language not written in VBA, but something called XLM, not XML, XLM.

139
00:15:52,960 --> 00:15:58,280
Now, Microsoft loves to support old file formats for compatibility reasons.

140
00:15:58,280 --> 00:16:05,920
So yeah, these old file formats still work even in recent versions, specifically in Excel.

141
00:16:06,760 --> 00: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.

142
00:16:23,700 --> 00:16:28,980
So the researchers published some great details about these older formats and some of their findings.

143
00:16:28,980 --> 00:16:34,840
So if you're interested, I've posted a link on the slide to their very thorough technical write-ups.

144
00:16:36,100 --> 00:16:40,860
So what I did was I created a simple proof of concept based on their code.

145
00:16:40,860 --> 00:16:44,480
We'll see a malicious document is downloaded from the internet.

146
00:16:44,480 --> 00:16:47,860
And when it is opened, CALC is automatically executed.

147
00:16:48,900 --> 00:16:54,820
Now, the main takeaway from here is that there are no macro alerts, right, no prompts, nothing.

148
00:16:54,820 --> 00:16:59,680
Just as soon as the document is opened, CALCulator pops.

149
00:17:01,900 --> 00: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.

150
00:17:18,460 --> 00:17:20,840
We can't access the user's files.

151
00:17:20,840 --> 00:17:22,980
This is the point of a sandbox.

152
00:17:22,980 --> 00:17:27,200
It contains malicious code, even if such code finds a way to execute.

153
00:17:27,540 --> 00:17:33,640
So, in short, we need a new sandbox escape in order to do any real damage.

154
00:17:34,180 --> 00:17:38,800
So I started by looking at Microsoft's patch for Adam's bug.

155
00:17:39,100 --> 00:17:43,800
And I noticed that they actually didn't fix the faulty regex.

156
00:17:43,800 --> 00: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.

157
00:18:00,060 --> 00: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.

158
00:18:09,440 --> 00:18:15,120
Again, almost anywhere because Microsoft added some specific locations that they blocked.

159
00:18:16,880 --> 00:18:24,380
Now, our goal, of course, is to execute something outside the sandbox so we can persist and do evil things.

160
00:18:24,380 --> 00: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.

161
00:18:33,200 --> 00:18:35,700
As Microsoft didn't fully patch that.

162
00:18:36,080 --> 00: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.

163
00:18:44,460 --> 00:18:48,380
Now, these scripts themselves will be sandboxed, right?

164
00:18:48,380 --> 00:18:53,700
They're children of a sandbox process, which means themselves are also sandboxed.

165
00:18:53,700 --> 00:18:55,780
But that's still a start, right?

166
00:18:55,780 --> 00: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.

167
00:19:05,140 --> 00: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.

168
00:19:16,120 --> 00:19:21,620
Now, login items are automatically executed the next time the user logs in.

169
00:19:21,640 --> 00:19:29,320
And since it started by Mac OS, instead of us via the sandbox, it's not going to be sandbox.

170
00:19:29,380 --> 00: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.

171
00:19:37,120 --> 00:19:43,280
Again, there's no tie back to the Microsoft Office macro code, the sandbox, nothing.

172
00:19:43,360 --> 00:19:47,660
So that means this will be executed outside the context of the sandbox.

173
00:19:48,040 --> 00:19:51,640
To confirm, we can persist terminal.app.

174
00:19:51,640 --> 00:19:55,920
Sure enough, when we re-log in, terminal is executed.

175
00:19:55,920 --> 00:20:01,780
And when we look at it in Activity Monitor, we can see that it runs outside the sandbox.

176
00:20:03,240 --> 00:20:05,220
So this is good, right?

177
00:20:05,220 --> 00:20:07,700
We now have a way to bypass the sandbox.

178
00:20:07,700 --> 00:20:18,700
But unfortunately, we run smack into Catalina's new security mechanisms, which are file quarantines and new notarization requirements.

179
00:20:18,700 --> 00:20:24,840
In a nutshell, notarization basically says, hey, Apple has to bless the file before it's run.

180
00:20:24,840 --> 00:20:28,120
Obviously, Apple's not going to bless our back door.

181
00:20:28,120 --> 00: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.

182
00:20:37,240 --> 00:20:38,560
It is not notarized.

183
00:20:39,880 --> 00:20:41,840
This is a bummer.

184
00:20:42,180 --> 00:20:43,680
And so what do we do, right?

185
00:20:43,680 --> 00:20:48,020
We got to figure out a way to bypass now quarantine and notarization.

186
00:20:48,640 --> 00:20:51,980
Now, hope is not lost, right?

187
00:20:52,200 --> 00:20:59,160
This is 2020, things look bleak, but we got to stay optimistic, especially when we are looking and developing exploits.

188
00:20:59,160 --> 00: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.

189
00:21:13,820 --> 00:21:17,520
Now, this is a big if, but again, there's a few kind of takeaways here.

190
00:21:17,520 --> 00:21:20,180
First, being able to specify arguments is huge.

191
00:21:20,740 --> 00: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.

192
00:21:38,180 --> 00:21:39,780
This would be great.

193
00:21:39,780 --> 00:21:48,200
But recall that Microsoft's patch for Adam's bug explicitly blocks the creation of launch agents.

194
00:21:48,560 --> 00:21:49,640
Bummer.

195
00:21:50,140 --> 00:21:55,000
So we kind of have like all these pieces, but we just can't quite put them together.

196
00:21:55,440 --> 00:21:56,540
Frustrating.

197
00:21:56,540 --> 00:22:03,300
So we can escape the sandbox via a login item, but login items can't take arguments.

198
00:22:03,300 --> 00:22:08,060
And they also can't be a random binary because notarization will block it.

199
00:22:08,060 --> 00:22:12,640
So in other words, all we can do is persist an Apple binary.

200
00:22:12,640 --> 00:22:14,980
Again, with no arguments.

201
00:22:15,080 --> 00: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.

202
00:22:25,240 --> 00: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.

203
00:22:37,860 --> 00:22:40,040
This is where things get beautiful.

204
00:22:40,060 --> 00:22:42,320
So I had a random idea.

205
00:22:42,320 --> 00:22:47,320
What happens if you create a login item that is not a binary or an application?

206
00:22:47,320 --> 00:22:50,580
Like, what happens if you persist a zip file?

207
00:22:50,580 --> 00:22:52,500
How does the system handle that?

208
00:22:52,500 --> 00:22:55,400
Again, recall we can create these login items from the sandbox.

209
00:22:55,400 --> 00:22:58,260
They can't take arguments and they can't be random binaries.

210
00:22:58,260 --> 00:23:03,420
But what happens if we persist a zip file, right?

211
00:23:03,560 --> 00: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.

212
00:23:18,060 --> 00:23:23,560
Basically says, okay, this is not an executable, so I'm going to invoke the handler.

213
00:23:23,560 --> 00:23:29,120
In this case, it's the archive utility because we persisted a zip file, which will extract that.

214
00:23:29,300 --> 00: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.

215
00:23:40,980 --> 00: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.

216
00:23:50,320 --> 00:23:53,120
This is allowed from the sandbox.

217
00:23:53,720 --> 00:24:02,020
So now we can place the zip file in the library directory, and we can persist this as a login item.

218
00:24:02,140 --> 00:24:03,780
So we're making progress.

219
00:24:03,780 --> 00:24:05,260
So what do we put in the zip file?

220
00:24:05,260 --> 00:24:08,340
A directory named launch agents.

221
00:24:08,360 --> 00:24:11,980
And in that, a launch agent property list.

222
00:24:12,060 --> 00: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.

223
00:24:20,400 --> 00: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.

224
00:24:37,500 --> 00:24:39,080
That is awesome.

225
00:24:39,080 --> 00:24:41,680
So this completes the full exploit chain.

226
00:24:41,680 --> 00:24:49,140
The user starts by opening this SLK file containing the XLM macro, which will execute automatically.

227
00:24:49,140 --> 00:24:51,780
Again, no alert, so just open the document.

228
00:24:52,580 --> 00:24:58,680
This downloads and persists the specially crafted zip file as a login item.

229
00:24:58,680 --> 00: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.

230
00:25:08,540 --> 00: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.

231
00:25:22,620 --> 00:25:30,300
So this bash backdoor runs outside the sandbox, meaning it can download and unquarantine files.

232
00:25:30,300 --> 00:25:35,640
Unquarantine files are not constrained by Apple's notarization requirements.

233
00:25:35,640 --> 00:25:39,820
So we have this interactive shell outside of the sandbox.

234
00:25:40,220 --> 00:25:41,560
What do we do?

235
00:25:41,560 --> 00:25:44,320
Well, we decided to persist something.

236
00:25:44,320 --> 00:25:51,180
And I thought it'd be extra funny to persist a repurposed, clearly not notarized version of Wingtail.

237
00:25:51,180 --> 00: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.

238
00:25:59,820 --> 00: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.

239
00:26:10,320 --> 00:26:18,020
First thing, as a responsible security researcher, I reported all these vulnerabilities to Microsoft and Apple.

240
00:26:18,160 --> 00:26:22,880
Microsoft responded and said, this is a known issue on the Apple side.

241
00:26:22,880 --> 00:26:26,400
And I was like, well, yeah, because I told Apple as well.

242
00:26:26,400 --> 00:26:31,600
So I have no idea what Microsoft did, no CDE, no bug bounty.

243
00:26:31,600 --> 00:26:32,360
Bummer.

244
00:26:32,620 --> 00:26:37,400
Apple said, thank you for your report, and then nothing.

245
00:26:38,000 --> 00: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.

246
00:26:46,140 --> 00:26:51,520
Again, no CDE, no bug bounty, classic Cupertino.

247
00:26:53,600 --> 00:27:01,100
Let's talk briefly, though, about how to detect this, these attacks and perhaps other Mac malware as well.

248
00:27:01,340 --> 00:27:07,820
So the first thing let's talk about is process monitoring, leveraging Apple's new endpoint security framework.

249
00:27:08,360 --> 00:27:14,560
It turns out it's pretty easy to create a process monitor to detect something I call suspicious children.

250
00:27:15,120 --> 00:27:17,560
Suspicious children processes.

251
00:27:17,560 --> 00: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.

252
00:27:28,520 --> 00: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.

253
00:27:40,660 --> 00:27:42,780
Something is amiss.

254
00:27:44,340 --> 00: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.

255
00:27:53,660 --> 00: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.

256
00:28:05,680 --> 00: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.

257
00:28:13,840 --> 00: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.

258
00:28:27,920 --> 00:28:34,600
This is a huge red flag and kind of, you know, shows that our exploit is executed.

259
00:28:36,200 --> 00:28:42,480
So at Jamf, we implement such monitoring logic in a framework we call MonitorKit.

260
00:28:42,480 --> 00:28:51,960
We then feed that monitoring data, as well as our analytics and rules, into Apple's game logic engine for evaluation.

261
00:28:51,960 --> 00:28:59,120
This gives us a powerful endpoint detection capability, uniquely tailored for macOS.

262
00:28:59,120 --> 00: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.

263
00:29:08,000 --> 00:29:08,960
Pretty neat.

264
00:29:10,000 --> 00:29:12,820
All right, so let's wrap everything up.

265
00:29:13,160 --> 00:29:19,140
So today we kind of talked about the current state of affairs in the land of macro-based attacks.

266
00:29:19,140 --> 00:29:26,160
And we showed that they are becoming more and more popular in the sense of targeting specifically macOS users.

267
00:29:26,160 --> 00:29:30,020
But luckily, current attacks are rather light.

268
00:29:30,020 --> 00: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.

269
00:29:49,840 --> 00:29:54,160
Again, at the time, on a fully patched macOS system.

270
00:29:54,280 --> 00: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.

271
00:30:03,680 --> 00:30:07,080
I really want to thank a variety of people.

272
00:30:07,080 --> 00:30:10,560
First and foremost, you all for virtually attending my talk.

273
00:30:10,560 --> 00:30:12,520
Hope you're all staying safe and healthy.

274
00:30:12,640 --> 00:30:16,520
Also to Jamf for putting up with my many shenanigans.

275
00:30:16,660 --> 00:30:20,860
And also all the amazing companies that support Objective-C.

276
00:30:21,860 --> 00:30:23,740
Oh, and one more thing.

277
00:30:23,740 --> 00:30:29,060
Today I am announcing my new book, The Art of Mac Malware Analysis.

278
00:30:29,060 --> 00:30:32,020
My dog is very excited about it as well.

279
00:30:32,480 --> 00: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.

280
00:30:41,360 --> 00:30:43,020
All 100% free.

281
00:30:43,020 --> 00:30:44,240
Sharing is caring.

282
00:30:44,260 --> 00:30:53,640
So if you're interested in learning more about Mac malware, exploits, persistence, debuggers, disassembling, check out the site.

283
00:30:54,280 --> 00:30:55,920
So again, that is a wrap.

284
00:30:55,920 --> 00:30:58,060
Thank you so much for attending my talk.