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