DEF CON 27 Conference – Patrick Wardle – Harnessing Weapons of Mac Destruction


>>Alright! Aloha and welcome to
my talk. Uh today we’re going to
be talking about Harnessing Weapons of Mac Destruction. My
name is Patrick. I am a security
researcher at Jamf. Uh previously I was a co-founder at
Digita Security. And I’m also
the creator of the Mac security website and tool suite
Objective-See. So today we’re
gonna be talking about repurposing other people’s
malware for our own
surreptitious purposes. We’ll start by showing why this is
rather an excellent idea and
then show exactly how to repurpose various Mac malware
samples. Of course we want our
repurposed samples to remain undetected both by Apple’s
built-in malware mitigations and
third party AV products. So we’ll address that as well.
Finally, we’ll end by covering
various generic may, methods to detect these repurposed uh
creations because really our
ultimate goal is to ensure that Mac users remain protected. So
let’s dive in. So here we have a
diagrammatic overview that conceptually explains the
repurposing process. So imagine
that spy A has developed some neat uh sophisticated uh fully
featured malware and has
deployed it to various targets, right? Infected various systems
around the world. Spy B somehow
captures this malware. Uhh perhaps either in transit or
pulls it off an infected system.
Spy B then will take this malware sample to her lab and
then repurpose it. So what do we
mean when we talk about repurposing? Well we’ll get into
this more shortly but basically
we’re talking about reconfiguring a piece of
existing malware so that you can
use it for your own surreptitious purposes. So for
example we can see on the slide
once spy B has repurposed the malware, she can now redeploy
that against new targets and
instead of beaconing back to spy A’s infrastructure for tasking,
it’ll talk to her new
infrastructure instead. Now you might be thinking, okay, this
seems like a reasonably neat
idea, but why? And we’ll talk about two reasons that hopefully
show that we should really be
asking, why not? So first, there are incredibly well funded uh
incredibly well resourced uh
very motivated hackers, APT groups and three lever, three
letter government agencies that
are creating some incredible malware. Uh this malware is
fully featured and has the
benefit of being fully tested. A lot of times already even tested
in the wild. Now I’m rather
lazy. I would rather be sleeping on the beach or surfing or doing
yoga so I figured why not let
these groups create this incredible malware and then we
can just repurpose it for our
own missions. The idea is to let those with more time, resources
and money do all the hard work.
Secondly if our repurposed creations that we redeploy get
captured, it’s very likely that
they will be misattributed back to the original authors, not to
us. This is great. Now you might
be thinking, okay Patrick, if this is such an amazing idea why
aren’t people already doing
this? Well and the answer is, they are. Now I can’t comment
specifically on this but leaked
slide, uh slides appear to inda, indicate that the NSA has had
this capability for awhile. Also
recent reporting from the New York Times claims that the
Chinese are doing this as well.
Now to these well resourced agencies the benefit of using
repurposed malware is twofold.
First, it allows them to deploy other countries’ malware into
risky environments. For example,
perhaps a target where another agency, another country, another
APT group already exists. So
imagine you’re in the NSA, you ta, you hack a high value
target, you find out, well,
someone else is already there. Obviously you don’t wanna put
your primary implants on that
system. So, if you have a repurposed implant that you can
use, might as well put that
down. Also we already talked about attribution. These
agencies don’t like people to
know what they’re up to, so if they can use repurposed malware,
perhaps this muddles the
attribution picture. Now of course there’s gonna be
challenges to repurposing
malware, if there weren’t, we wouldn’t be talking about it
today. But we’ll see these
challenges are not insurmountable. So, first,
generally speaking, if we
capture a piece of malware to repurpose we’re not going to
have the source code for the
malware. We’re just gonna have a binary image, so we’ll have to
reverse engineer the malware at
the binary level. This is kinda the analysis stage, I like to
call it, and what we’re doing is
we’re trying to figure out and gain an understanding of what
the malware does. Answering
questions such as, how does it persist? How does it install?
And what its capabilities are.
And of course what command and control servers it talks to.
Then with such an understanding
we have to figure out exactly how to patch the malware. Again,
usually we don’t have a source
code the, so this involves patching at the binary level.
Now if the malware talks to a
remote command and control server, which most do, we will
have to figure out how the
malware determines where to get the address of that server. And
then also understand the
protocol so we can create our own command and control server,
so when we redeploy the
repurposed malware we can communicate with our new
infected systems. And then
finally since we are repurposing general known, generally know
malware, it’s likely that Apple
or AV products already have detection signatures for this.
So we have to co, we have to
talk and we have to figure out how to get around that because
obviously, it would be rather
unfortunate if you deployed some repurposed malware only to have
it detected. Now I want to
reiterate that it’s very important to take these
challenges seriously and get
them right because if not, relatively bad things can
happen. Here for example we’ve
attempted to comprehensively repurpose a piece of Mac malware
but it turns out that we forgot
to modify, or patch out, the addresses of the backup command
and control servers. This means
if we deploy what we believe to be a fully repurposed piece of
malware, at some point it may
beacon back to the original hacker’s infrastructure, giving
him or her access to our
infected targets. So obviously this is something we want to be
very aware of and make sure when
we are repurposing these samples, we’re doing it
comprehensively. So now let’s
talk about exactly how to repurpose Mac malware, with the
goal of making their malware,
ours. So the first step is to select a malware specimen. And
that is the sample you want to
repurpose. This is usually based on two criteria. First you
decide what you need the malware
to do. Right? Are you looking for an interactive back door? Uh
perhaps a piece of RAM
somewhere? Cryptocurrency miner? Take your pick. And then maybe
attribution is important to you.
Right? Do you want your repurposed sample to originally
belong to a three letter agency?
A Russian hacking group? So, again, if it get, gets caught
it’ll be likely misattributed to
them. So on my website, Objective-See dot com, I have a
very comprehensive collection of
Mac malware. So that’s a great place to start. And all the
samples we’re talking about
today, that will repurpose, the original specimens are available
for download. Now, once you’ve
selected your malware sample, it’s time to analyze it.
[inaudible] The main goal is to
figure out things like uh, if it has any remote access, right? If
it’s talking to your remote
command and control server, we want to know what that server is
so that in the malware we can
modify it to instead talk to us. If the malware does talk to our
remand, uh, remote command and
control server, we also need to understand the protocol so that
we can task it when it connects
back to us. And, of course, you want to fully understand the
malware’s capability. Both
locally, how does it persist? How does it interact with the
system? And then also, remotely.
What commands can we remotely task the malware with? So once
you have a comprehensive
understanding of the malware, it’s time to actually
reconfigure or repurpose it.
Generally this means we’ll have to patch the malware at the
binary level. So here, for
example, as we can see on the slide, we’ve located the
addresses of the malware’s
remote command and control servers directly imbedded in the
malware’s binary. We can simply
modify these bytes, for example in a Hex editor, to change that
address to point to our own
command and control server. This means now when we take this
malware and redeploy it, the
malware will beacon, connect back to our infrastructure, and
be ready for tasking. Now as I
mentioned, if the malware is a back door or an implant, uh, and
expects to talk to a command and
control server, well if we’re repurposing it, we’re gonna have
to write our own custom command
and control server as well. This will obviously ensure that when
the malware checks in and
connects back to us, we can give it tasking and fully exploit
it’s remote capabilities. Now
such a custom command and control server really doesn’t
have to be anything incredibly
fancy, usually whip up a simple python script. But if you’re
planning on deploying these
repurposed malware samples to many targets you might want
something more comprehensively.
Uh at a previous DefConwe talked about one such custom command
and control server with the goal
of analyzing a sample. Now obviously each specimen you
repurpose is going to be
different in the sense that it likely has a different protocol
and thus will need a custom
command and control server for that specimen, but that paper is
kind of a good place to start.
Alright so now let’s walk through some actual examples
repurposing some Mac malware.
And we’re gonna start with a sample called FruitFly. FruitFly
is a rather unique piece of Mac
malware. It was originally developed over fifteen years ago
uh remaining in the wild and
only very recently became detected. It’s a fully featured
back door, which supports a
myriad of remotely taskable capabilities which really makes
it the perfect candidate for us
to repurpose. As we’ll see we can very trivially repurpose
this malware, and then that
gives us access to a proven, fully featured back door that we
can utilize for our own
subversive purposes. FruitFly is actually written as a perl
script. Though it’s highly
obfuscated, if we take a peek at the back door, we can see logic
that processes command line
arguments. That is to say the script will check if it’s been
invoked with certain command
line arguments, parameters or flags. Turns out it’s looking
for a port or a port and IP
combo of the command and control server to connect to. So this
means if we specify our own via
the command line then we don’t actually have to modify the perl
script or the malware binary
itself. So what we can do is we can persist this, this malware,
FruitFly, uh as a launch agent.
As we can see on the slide we can pass in our address of our
command and control server. So
this means we can trivially repurpose this back door to
connect to our custom command
and control server. Right? Because we can specify in the
command line, we can now push
that out, give the address of our own server and the malware,
when it runs, will connect
directly back to us instead of the hacker’s original servers.
But to deploy this we need an
installer. Good news, previously I wrote one that’s available on
pace/bin. As we can see, it’s
just a few lines of code which persistently installs the
malware in a manner that matches
how it was uncovered in the wild. Finally, as I had
previously written the custom
command and control server to analyze the sample we can just
review this. So, we’re gonna do
a live demo now. Live demos are always risky. And actually we’re
gonna run this on my laptop.
This is my own personal developer laptop. Not gonna run
this in a VM. Because again, I
wanna show you the power of this repurposed malware and once
we’ve repurposed it, it’s
essentially trustworthy. So let’s see this in action. So the
first thing we’re gonna do is
we’re gonna run the command and control server. This is
listening for connections. And
then we are going to execute the malware uh specifically via the
installer, passing in the
address of our command and control server. When we run
this, we can see that the
malware now has connected to our command and control server on
the right. And we see there’s a
myriad of capabilities that we can now task this malware. Again
this is running on my own
personal box. So for example if we execute command number
thirteen, this will tell us
where the malware is installed. We can see it’s running out of
users/patrick/fpsaud. We can
also do things like take a screenshot, that is command
number two. Execute that, we
gave it a parameter of zero saying we want a full screen
capture. And this will tell the
malware, which has been deployed to my personal system now, to
please take a screenshot and
send it back to the commanding control server. So we can kill
the server. And we can open the
screenshot. And we can see, yea, it took an entire screenshot of
the desktop. Okay so that’s
FruitFly. Now let’s talk about repurposing a cryptocurrency
miner because maybe you wanna
make a lot of money mining cryptocurrency on other people’s
computers but you don’t have the
skills, time or resources to write your own. So our target is
called CreativeUpdate. This
cryptocurrency miner was spread via tojan, trojanized
applications and then spread via
the popular third party application website Mac update
dot com. If we mount the
malicious disk image that contains one of these trojanized
applications, and reverse
engineer the application’s main binary, we can see it invoking a
method called execute script
with privs. And if we look at what this method does in a
decompiler or disesembler, we
can see it simply executes a file named script out of the
application’s resource
directory. So if we take a peek at this script, we can see it
first launches the real pristine
copy of the application that it had trojanized. For example,
Firefox. Uh and this is so the
user who has downloaded this infected, trojanized application
doesn’t think anything is amiss.
We can then see in the script it beac, beacons out or connects
out to a download server to
download a zip archive named mdworker dot zip. It then
extracts this archive and
persistently installs something named mdworker. If we look at
the launch agent P list that
persists the malware we can see the path to the persistent
binary, which is that mdworker
binary we just discussed. Also we can see some command line
arguments that are passed into
this binary. If we execute this mdworker binary, it turns out
it’s a legitimate cryptocurrency
miner belonging to a company named Miner Gate. The command
line arguments therefore specify
the miner account. That is where to send the mining results and
the type of cryptocurrency to
mine. So, similar to FruitFly, since the relevant parameters
are passed via the command line,
as say opposed to, directly embedded in the malware’s
binary, it’s trivial to
repurpose this sample. So first we simply modify the property
list, the P list, to specify our
own miner account. And then zip up the malware’s components. Now
instead of having the malware
download that zip from a download server we just add the
archive to the applications
bundle. This is far more simpler and self-contained. It means we
don’t actually need to set up a
remote download server to host this second piece. Next we tweak
the script so instead it
utilizes the zip archive we just added. Finally we repackaged
everything, ope! And we’re ready
to go. So, we’re gonna do live demo number two. Just bring up
finder window. First I wanna
show you the repurposed malware, it’s kind of application bundle.
We can see this is an app and
within the app there is this script file. There’s the
original FireFox, this is the
one that’s signed by mo, Mozilla. Uh if we pop over here
though, we’ll see that this is
what the user downloads and expects to run. So what we’re
gonna do is we’re gonna run
this. This has been reconfigured. Again, I am
running this on my own personal
system. I figured, while I’m up on stage I might as well be
mining some cryptocurrency. So
we’re gonna run this. FireFox pops up, everything looks great,
the user is stoked they’ve got
this great browser. And now if we pop back to a terminal
window, behind the screens, I’m
gonna make this a little bigger. We can see that the malware has
persistently installed itself.
And again if we look at the program arguments, we can see
that it’s gonna execute the
miner named mdworker, but we have repurposed it so instead
it’s gonna send all the results
of the cryptocurrency mining operations to me. Sweet.
Awesome. Alright, well, since
we’re talking about making money, right? We all love to do
that. Uh perhaps you want to
deploy some ransomware without spending time writing your own.
So now we’ll walk through it,
exactly how to repurpose KeRanger. KeRanger was the first
fully functional, in the wild
ransomware targeting Mac OS. Hackers infected the popular
BitTorrent client transmission
on the legitimate application’s website. This means that if
users went to the transmission
website to download the BitTorrent client, inadvertently
they would get the malicious,
infected, trojanized version and become infected. Looking at the
malware’s binary code we can see
it executing something named general dot RTF out of the
application bundle. Though it
appears to be a document, if we examine that file a little
closer, turns out it’s not a
document it’s really a Mach-O binary. So what this Mach-O
binary does is first sleeps for
a few days and then it connects out to the attacker’s command
and control server, expecting a
response consisting of an public RSA encryption key and then
decryption instructions. It then
uses that encryption key to encrypt the users files and then
displays the decryption
instructions that demand a ransom. Pretty standard ransom,
ransomware functionality. So
let’s talk about repurposing this ransomware. First we’re
gonna wait for three days. We’re
kind of in a rush to start encrypting people’s files. So
what we can do is we can just
patch out, nop out the call to the sleep function. Pretty easy
to do. Then we’re gonna modify
the addresses of the servers that the ransomware contacts for
the public uh RSA encryption key
and the decryption instructions. As we can see on the slide these
addresses are directly embedded
in the malware’s binary, so it’s pretty easy for us to hop into a
Hex editor and change them to
the address of our server. Uh, pretty easy, right? And here for
testing purposes we just set
them to local host. One twenty seven dot zero dot zero dot one.
Now we, we also need a server
because the ransomware’s gonna connect out when it’s run.
expecting that encryption key
and decryption instructions. Turns out this is really easy to
do. We can just take our own
public uh RSA key and decryption instructions and package that up
to, in a text file and then
serve that up via netcap. So here’s a demo of KeRanger that’s
now been repurposed. We’ll see
in the terminal window, this is our server, again it’s just a
netcap serving up the encryption
key and the decryption instructions. The malware has
been repurposed though to talk
to this command and control server and not the attacker’s
original one. And then we’ll
start seeing the ransomware immediately start encrypting all
the files on the desktop. Once
the malware has done this, again it’s launched when the user
launched the transmission
application, they’re not gonna be privy to anything going on.
Uh you know the encryption
happens in the background although they might see all
their files being encrypted. So
now when the files are encrypted, the user’s gonna be
like, crap, this sucks, how’d I
get my files decrypted? They’re gonna open the read me dot
decrypt file and you can now
see, we provided our own decryption instructions. So here
I’ve said hey! You know, sorry
about losing all your files, send me buckets of money and I
will decrypt them for you. It’s
actually kind of mean, you know, maybe don’t do that. [speaker
laughs] Uh the last step that I
wanna talk about repurposing is called windtail. Now windtail is
a lovely back door written by a
rather sophisticated APT group. Here we’ll repurpose both their
exploit and their own back door
to use for our own missions, our offensive cyber surreptitious
processes. Now one of the most
interesting piece of this attack was the malware’s infection
vector. And the way it was able
to infect fully patched Mac systems, while it was, by
leveraging a legitimate
functionality of Mac OS by abusing something called custom
URL schemes. Now I’ve written a
long detailed blog that really dives into the technical
underpinnings of this but in a
nutshell on Mac OS as soon as an application in saved to the file
system, even before the user has
run it, Mac OS parses that application. And if that
application supports custom URL
handlers, Mac OS will automatically register it. Once
these custom URL handlers or the
app has been registered you can, for example, from a webpage make
a request to that custom URL
which Mac OS will be happy to now launch. The exploit is
realized in JavaScript uh
basically they have some code to first download a malicious
application that contains a
custom URL scheme. Mac OS registers that and then they
have some second piece of
JavaScrip which makes a request to that now registered custom
URL scheme to launch the
malicious application. In terms of the back door, again this is
the payload of the exploit, they
persist a login item that supports capabilities such as
file collection and
exfiltration. So we fire up a process monitor, as we can see
on the slide, we can observe
what the malware does once it successfully infects the system.
For example we can see it
invoking the built in zip utility. Uh to compress the
files that it has collected for
exfiltration. And then via the built in curl command, it sends
them to the attacker’s remote
command and control server. The back door also supports a file
download capability. So if we
look at the SDF method, a disassembler or decompiler, we
can see it decrypts the
addresses of some embedded command and control servers.
Then it makes a initial request
to get a name for a downloaded file and then makes a second
request to get the actual file
contents from the attacker’s command and control server. If
we use a network monitor we can
see this happening live and as we note on the slide, the
address of the command and
control server is flux two key dot com and just remember this
because we’ll get back to this
in a second. Now once the malware has downloaded the file
from the attacker’s uh remote
command and control server if we look at more disassembly we can
see that it then executes this.
So this is done within the same SDF method. We can see that it
unzips the file it gets from the
attacker’s remote server via the built, built in ditto command
and it executes it via the NS
task API. So, pretty standard built in download and execute
capabilities. Finally the back
door can be remotely uninstalled via self delete logic. So
everytime the malware starts up,
it connects to the attackers command and control
infrastructure and basically
says, should I delete myself? If the command and control server
responds back with a one, the
malware will first delete, uninstall itself and then
terminate. It’s kind of a neat
capability that allows an attacker to remotely disinfect
targets. Alright so now it’s
time to coerce this lovely back door to do our own bidding. So,
first let’s talk about
repurposing the exploit. It’s pretty simple to create a
malicious web page that auto
downloads a zip file containing a malicious application. As we
mentioned, a safari by de,
default will auto expand zip archives so if we place a
malicious application in that
archive that implements some custom URL handlers, Mac OS will
automatically register that even
before the user has run the application. The malicious web
page can then make a request to
that now registered custom URL which will cause the application
to be launched. Now, there will
be a pop up or two, but the average user probably is gonna
click through these. So here’s a
demo of the repurposed exploit that will drop and persist uh
windtail. We can see the page
has downloaded the application and then we made that second
request. There was a pop up.
Again, if the user clicks through, which some percentage
of users will fall for, we can
see that now the malware has been automatically and
persistently installed. Again,
since this is a logic flaw, there’s nothing really for Apple
to patch. So this still works on
the latest version of Mac OS. So now we’ve repurposed the
exploit, let’s talk about
repurposing the malware. Because, doesn’t really help us
if we are sparing their original
malware that still beacons back to the attacker’s command and
control servers. So step one, we
need to modify the embedded command and control server
addresses so that when the
malware is deployed via our repurposed exploit, it connects
to our server so that we can
task it. Unfortunately the embedded addresses of the
malware’s command and control
servers are encrypted. Not to worry. What we can do is we can
coerce the malware to always
load a dynamic library and then once our library is running in
the process address space of the
malware, we can basically modify uh the malware at runtime to
intercept the decrypted
addresses of the command and control server before the
malware uses them to connect
out. So let’s look a little closer about how we accomplish
this. Again the goal is for us
to specify our own command and control servers so that the
malware connects back to our
infrastructure. So our dynamic library has now been loaded into
the address space of the
malware. What we can do is we can swizzle or swap out the
malware’s decryption routine,
it’s a method named yoop. This is accomplished via the rather
powerful method exchange
implementations API. As we see on the slide, once the
decryption function has been
swizzled or swapped out, whenever the malware invokes the
decryption function,
transparently the Objective-See runtime will actually now call
our method in our library. What
our method now does is calls into the original decryption
routine, and I have no idea what
the decryption algorithm is or how it works, and frankly I
don’t care, but what I can do is
since it’s swizzled and passing through us, I can see the
results of that encryption. So
if the original decryption method returns the decrypted
addresses of the command and
control servers, I can just return my own command and
control server back into the
malware’s logic. So this dynamically gives us the ability
to transparently swap out the
decrypted command and control servers with our own. And the
malware is none the wiser. Now I
added some debug messages to the library so if we, if we execute
this now repurposed malware, we
can see and watch this at runtime and view the addresses
of the command and control
servers being swapped out. So at the bottom of the screen, uh in
the terminal output, you can see
that our library which is called through to the original
decryption method has detected
that that response is the command and control server
that’s now decrypted. We don’t
want to return that to the logic and the malware that’s trying to
connect out so we basically just
drop that and return our own. Again this ensures now that the
back door will always
communicate with our servers instead of the original APT
group’s. Now we still have to
write a command and control server. Uh because the malware
will now be connecting back to
us. But we have to be able to talk the protocol so that we can
correctly task it. Now the main
feature of the windtail back door is to collect and
exfiltrate files. So let’s add
this first to our custom command and control server. Files are
exfiltrated via post requests.
So we simply write a few lines of code in python to handle
this, saving off each file the
malware sends to us from the infected host. So here’s a demo
now of our custom command and
control server receiving exfiltrated files from the
attacker. On the left you can
see the network requests coming in and on the right all our
command and control server does
is write these out to the file system. This means we now
support the ability to respond
to the malware as it exfiltrates all sorts of files off infected
hosts. Let’s also extend our
custom com, command and control server for this windtail implant
to support the download and
execute capability. So we noted the malware makes two requests
for this. The first is a request
where the expected response is for the name of the downloaded
file and then the second request
we need to respond with the actual bytes of the file we want
to download. The malware will
then save that to the file we specify, and then unzip that,
and execute that. Now again, we
only need a few lines of code in python. We can leverage a lot of
built in python libraries to do
this. Um and once we do that we then have the ability to task
the implant. So let’s watch this
in action. We’re gonna see the malware connecting out to our
command and control servers
cause we’ve swapped out those addresses and what we’ll do is
we’ll have it download and
execute. You, ubiquitous calculator dot app. So here
comes the connections, we’re
giving it calculator dot app, this could be any binary. And
then the malware will unzip
that, and execute that. Now, armed with this remote download
and execute capability, this
means we can install other tools or even second pieces of
malware. So it really makes this
repurposed implant kind of infinitely uh extensible.
Finally let’s add the ability uh
to our custom command and control servers so we can
support the self delete command.
Ah because at some point, you know, the FBI comes knocking on
your door, might be really nice
to just press a button and have all these infected systems
uninstall themselves. It’s
trivial to support this functionality. Basically when
the malware connects out, checks
in with our server and asks, should I self delete? We just
respond with one. This will tell
the malware to delete and fully uninstall itself. This is
another demo showing this in
action. We can see the persistently installed implant.
It’s that orange logo uh, the
application originally tries to mimic a PowerPoint
documentation. Uh kinda sticks
out, but this is in kind of a, a hidden system directory. Uh,
what’s gonna happen is the
malware’s going to connect out to us, make the should I self
delete command a request, we’re
gonna respond with one which will cause the implant to
uninstall itself, and then
terminate. So we can see it disappear and then it stops
beaconing because obviously it’s
just self deleted. Alright so we’ve showed exactly how to
repurpose a myriad of Mac
malware. We talked about back doors, ransomware,
cryptocurrency miners. Although,
we still need to talk about how to remain undetected. As,
generally speaking, we’re
repurposing known malware which means both Mac OS and third
party AV products likely will
block or detect these. Unless we do something about it. So first
up, let’s talk about Mac OS’s
built in malware mitigations such as XProtect, the malware
removal tool, and code signing
certif, certificate checks. Now at first glance these might seem
somewhat problematic as they may
generically block our repurposed malware on any, or rather, on
all Macs. Again we really need
to talk about bypassing these because if we went to deploy a
nicely repurposed piece of
malware and Apple blocked it, ah that would, that would kinda
suck. So let’s start with
XProtect. XProtect is a simple signature AV, simple signature
based uh AV scanner that’s built
in to all recent versions of Mac OS. Somewhat limited, it only
scans files downloaded by the
user the first time they’re executed. If we look at their
signatures they’re in a file
named XProtect dot yara. We can see various yara signatures to
detect common pieces of Mac
malware. Uh for example KeRanger, the malware we just
talked about repurposing. Now at
Digita we wrote a simple utility called UXProtect that allows you
to explore these signatures via
the UI as well as at any time uh basically scan arbitrary files
against these built in
signatures. Now, since XProtect is purely a signature based
protection mechanism, it is
incredibly trivial to bypass. So let’s take a closer look at the
signature for KeRanger. We can
see it maps to a group of instructions in the malware.
Knowing this, to bypass the
signature, we can simply reorder or modify any of these
instructions. This will change
various bytes which’ll of course cause the signature to no longer
match. So here, for example, we
simply change the number of bytes that may be written to a
buffer from 0X400 to 0X300. Now
this doesn’t impact the malware’s functionality at all,
but as we’ve changed the bytes
that the signature is looking to match on, we’ve completely
thwarted the XProtect signature.
Demo time. Uh here we have two instances of KeRanger, again it
was distributed in this infected
transmission bittorrent client. On the left we have the original
sample, this is the hacker’s
sample, and on the right we have the repurposed sample that’s
gonna talk to our own command
and control servers to get the encryption key. And then also it
has that one byte modification
to bypass XProtect. So we’re gonna launch both of them. We’re
gonna see the original one as
detected by XProtect and blocked. There’s no option to
run it, the user has to click
cancel. If we execute the second one, that’s gonna say hey we
downloaded this from the
internet are you sure you wanna run that? User clicks yes, the
ransomware is now able to
persistently install on the user’s system and immediately
starts encrypting all their
files. Woo [speaker laughs, audience applause] But wait,
there’s more. [applause
continues] Next up we have code signing checks. So most binaries
on Mac OS are code signed.
Signed binaries are not blocked by gatekeeper thus a lot of Mac
malware is now code signed. The
downside from the malware’s point of view is once this
malware is detected, Apple can
simply revoke the code signing certificate, and this means the
malware will not be able to
execute on any other Mac. So here for example we can see we
have windtail’s, the windtail
binary, and the original code signing certificate has been
revoked by Apple Proper. This
means even if we repurpose this in attempt to redeploy this to
new systems it won’t be allowed
to run. Well, the problem is really the revoked certificate.
It’s not the malware per say so
we can simply remove the code signing certificate. And then
either distribute the repurposed
malware unsigned or resign it with another legit developer
code signing certificate. Which
is pretty easy to get. So to unsign it, Apple actually
provides a utility called
codesign that is an undocumented flag dash remove signature. So
if you execute this and point it
at the malware, Apple’s utility will nicely strip off the uh
revoked code signing
certificate. And then as I mentioned we can just deploy it
as is on the side or if we wanna
get a little more fancy we can resign it again using the
codesign utility passing in the
dash S flag. This means the resigned windtail will not no
longer be blocked by Mac OS.
[speaker sniffs] Finally we have MRT. This is Apple’s malware re,
removal tool. It’s another built
in AV like tool that ships with all versions of Mac OS. It’s
similar to XProtect but scans
malware that may be already on the system. And if it detects it
it’ll automatically removes it.
Now, unlike XProtect, it’s signatures are directly embedded
in it’s binary. Kind of
interesting. And as an interesting side Apple also uses
MRT to remove legitimate
software it deems unsafe. Such as the recent uh zoom
application that had some
vulnerable components so. Giving a lot of power to Apple here for
them to arbitrary remove uh
files from your system. Now since MRT, like XProtect uses
signatures, its equally trivial
to bypass. If we dump the MRT binary, because again the
signatures are embedded directly
in that binary, we can see all the signatures including one for
FruitFly. Which makes us wonder
is this going to detect our repurposed FruitFly malware?
Well if we examine the embedded
MRT FruitFly signature we can see it’s detecting FruitFly
based on both the path of the
malware and it’s launch agent P list. This means as long as we
change either the path or the
name of the malware it’s not going to detect it. Like I said,
trivial. Now, I also wanna
briefly mention bypassing third party antivirus products because
you might run into a system
where the user you’re targeting has an antivirus product
installed. Now there’s been a
lot of talk about this so I’m not gonna dive into it a ton,
but suffice to say, uh
traditional AV products that largely rely on signatures,
which is pretty much the norm
especially on Mac OS, are equally trivial to bypass. For
example I took FruitFly, recall
it’s a perl script, I ran it through a free online perl
obfuscator which caused
detections on virus total to drop all the way to zero. Now,
that works, but you might want
to use more sophisticated capabilities uh especially for
the binary based malware. So you
can do things like pack them, use a custom encrypter, or even
in memory execution. I gave a
talk at Black Hat a few years ago about these techniques uh
ch, recommend checking that out
because that can ensure that even if the user has a third
party AV product installed on
their system it’ll be unlikely to detect your repurposed
malware creation. [speaker
sniffs] Now for Mac users, this kinda sucks. Right? We showed
that advanced adversaries are
already using repurposed malware samples and that it’s actually
not that difficult to do. Often
times we just have to switch a few bytes or change the command
line arguments and now, ya know,
power to the people, we have the ability to take these very
sophisticated threats and
redeploy them for our own surreptitious processes. Also
the majority of detections,
those built into Mac OS or those provided by third party AV
products fail to detect these
repurposed threats. This in my opinion is rather la, lame
because if you think about it,
this repurposed malware is basically an exact copy of the
original known malware. We
really just slightly reconfigured it. So I wanna end
this talk, kinda switch gears.
We’ll put on our white hats now and talk about how to
generically detect such, such
threats. So first, and this is a well known fact, that I
hopefully just illustrated, uh
detecting malware based on signatures, bound to fail. So
instead what we need to do is
look for unusual or malicious behaviors. By definition malware
does unusual or abnormal things.
So let’s leverage this fact to discuss generically detecting
even repurposed threats. Because
again, as we just stated, if we are an attacker, repurpose a
known piece of malware the
underlying functionality is it’s behaviors and capabilities
aren’t going to change. That is
to say even a repurposed piece of ransomware is still going to
encrypt all your files. Uh a
repurposed back door is going to persist and then start
exfiltrating your files to a
remote server. So here on the slide, I’ve kind of listed some
um capabilities or some actions
or events that are good to look for and monitor because they may
provide insight into generically
detecting even repurposed malware. So let’s start by
talking about persistence. What
I mean by persistence is the way that malware installs itself so
that it’s automatically
restarted every time the system is rebooted. This is something
the majority of malware, both on
Windows and Mac, strives to achieve. So what we can do is we
can simply monitor the file
system, specifically observing persistence locations and then
if anything modifies those we
can alert the user or assist admin and say hey look something
just persisted, maybe you wanna
take a closer look at it. So here for example we can now
alert and generically detect
when windtail, either the original or repurposed item
persists. Next up is mic and
webcam access. A lot of Mac malware accesses the webcam or
the mic to enspy, to spy on the
users of an infected system. So to detect this subversive
activity, we can register with
Mac OS, it turns out there is a callback you can register that
anytime anybody accesses either
the mic or the webcam, you will programmatically get
notification of that fact. So
this will allow us to detect malware, even something like
FruitFly which we’ve repurposed,
or an exploit like zoom uh anytime it accesses the mic or
the camera. Next up we have
keylogger detection. A malware often times tried to capture
your keystrokes uh to steal
things like passwords and credit card information. On Mac OS the
easiest way to capture
keystrokes is by registering something called an event tap.
What we can do is we can
generically detect these taps by again registering for a dispatch
notification that will be kindly
invoked by the operating system any time a new event tap is
installed. This allows us to
very trivially detect keyloggers even if they have been
repurposed. We talked alot about
FruitFly this is one of the more sophisticated, feature complete
malware. One of the neat
features it has is the ability to remotely interact with the UI
via synthetic or programmatic
mouse and keyboard events. So the attacker can move the mouse,
click on buttons or even send
programmatic keyboard events to an infected system. So this is
something we want to detect
because this isn’t something that should normally be
happening on a Mac system.
Luckily it’s pretty easy to detect. We can install our own
event tap and monitor for mouse
activity. When a mouse click is generated, we can then examine a
variable, a state variable,
which Mac OS sets to one, if the mouse event, the click or the
move, has been programmatically
generated. So this allows us to now generically detect synthetic
clicks even in repurposed
malware. Now at the start of the talk I mentioned uh I was the
creator of Objective-See. It’s
my kind of personal Mac security web page. But the main goal of
Objective-See is to provide free
and largely open source security tools for any users who are
using Macs. Uh many of the
detections we talked about are realized in tools on this site
so if you’re interested in that
hop over to Objective-See dot com. Now, a downside of these
tools is they’re all separate,
right? There’s an individual keylogger detector, there’s an
individual firewall, there’s not
like an all in one solution. So when I started working at Digita
we decided to combine these into
a single all in one tool. Uh and the idea was to monitor the
system and then create rules to
detect unusual behavior. We then took both those pieces and fed
them into Apple’s built in game
logic engine, which would do all the hard work for us, and would
evaluate our rules on top of our
data and spit out a result for us. So now let’s talk about some
of these behavior based
detection rules. And it’s important to know you can use
these in other security tools as
well so this is not specific to our product per say. So using
this system we can generically
and rather trivially detect all the repurposed malware we talked
about today. Uh so for example,
windtail. We can detect it’s exploitation vector by observing
the fact that safari downloads
and then auto extracts an application. That same
application then triggers the
registration of a custom URL handler. And finally, then that
same application is started
automatically via custom URL requests from a website. So
detecting the combination of
those events gives us a generic capability. Both against
windtail or any other malware
that utilizes this same infection vector. Similarly we
can detect FruitFly at install
time by observing various events that cumulatively indicate
something is suspicious or at
least amiss. So here for example we observe the fact that a
hidden non-Apple binary has
persisted as a launch item. There’s no legitimate reason
that this should ever happen. So
that’s really shady. Now imagine that FruitFly is already running
on the system uh we can also
detect this by observing runtime behaviors. For example, FruitFly
does things that are really
shady and suspicious. For example, as we mentioned,
persisting and running a hidden
process. This hidden process in some scenarios will drop an em,
embedded unsigned binary to the
temp directory, execute that and then start capturing or
generating synthetic events.
Clearly this is incredibly shady. Now of course we don’t
have to trigger when all these
events occur. Uh we can look at them either cumulatively, we see
one or two we might wanna take a
closer look at the system because something might be
amiss. So hopefully I’ve
illustrated that by using these behavioral heuristics we can
generically detect even
sophisticated Mac uh threats, even those that have been
repurposed by advanced
adversaries or by Patrick. Now before I end this talk I’m
really excited to announce
Objective by the Sea version three point 0. So if you are
aware, uh Objective by the Sea
is a Mac security conference uh that I organize each year. Uh
this year it’ll be back in
Hawaii so if you want an excuse for your company to send you to
Hawaii in February, go to
Objective-See dot com. Well that is a wrap uh I wanna thank you
all so much for attending my
talk. We have about two minutes for questions and then I will
also be off the side of the
stage if you wanna come up and chat, talk nerdy about Mac
stuff. So again, thank you
though for real, attending, I really appreciate it. [audience
applause]