Harnessing Weapons of Mac Destruction
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Wardle, Patrick
Whenever a new Mac malware specimen is uncovered, it provides a unique insight into the offensive Mac capabilities of hackers or nation-state adversaries. Better yet, such discoveries provide fully-functional capabilities that may be weaponized for our own surreptitious purposes! I mean, life is short, why write your own? We'll begin this talk by discussing the methodology of subverting existing malware for "personal use", highlighting both the challenges and benefits of such an approach. Next, we'll walk-thru the weaponization of various Mac malware specimens, including an interactive backdoor, a file-exfiltration implant, ransomware, and yes, even adware. Customizations include various runtime binary modifications that will coerce such malware to accept tasking from our own C&C servers, and/or automatically perform actions on our behalf. Of course, in their pristine state, such samples are currently detected by AV products. As such we'll also walk-thru subtle modifications that will ensure our modified tools remains undetected by traditional detection approaches. In conclusion, we'll highlight novel heuristic methods that can generically detect such threats to ensure Mac users remain protected even from such weaponized threats.
 Alright Aloha and welcome to my talk. Today we're going to be talking about harnessing weapons of Mac destruction. My name is Patrick. I am a security researcher at Jamf. Previously I was a co-founder at Digital Security and I'm also the creator of the Mac security website and tool suite objective C. So today we're going to be talking about repurposing other peoples 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 repurpose 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 methods to detect these repurposed 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 sophisticated fully featured malware and has deployed it to various targets, right, infected various systems around the world. Spy B somehow captures this malware 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, incredibly well resourced, very motivated hackers, APT groups and three letter government agencies that are creating some incredible malware. 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 the answer is they are. Now I can't comment specifically on this but leak slides appear to indicate that the NSA has had this capability for a while. 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 APGT group already exists. So imagine you're in the NSA you hack a high value target and you find out someone else is already there. Obviously you don't want to 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 going to 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 going to have a binary image. So we'll have to reverse engineer the malware at the binary level. This is kind of 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 source code 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 generally known malware it's likely that Apple or AV products already have detection signatures for this. So 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 given 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 backdoor, perhaps a piece of ransomware, 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 gets caught it will be likely misattributed to them. So on my website objectivec.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. And the main goal is to figure out things like 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 a 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 embedded 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 control. This means now when we take this malware and redeploy it the malware will be can connect back to our infrastructure and be ready for tasking. Now as I mentioned if the malware is a backdoor or implant and expects to talk to a command and control server well if we're repurposing it we're going to 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 its remote capabilities. Now such a custom command and control server really doesn't have to be anything incredibly fancy. We 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. In a previous demo we talked about creating 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 going to start with a sample called Fruit Fly. Fruit Fly is a rather unique piece of Mac malware. It was originally developed over 15 years ago remaining in the wild and only very recently became detected. It's a fully featured backdoor 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 backdoor that we can utilize for our own subversive purposes. Fruit Fly is actually written as a Perl script though it's highly obfuscated. If we take a peek at the backdoor 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 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 malware, Fruit Fly, as a launch agent and 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 backdoor 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 hackers original servers. But to deploy this we need an installer. Good news previously I wrote one that's available on paceman 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 and covered in the wild. Finally as I had previously written a custom command and control server to analyze the sample we can just review this. So we're going to do a live demo now. Live demos are always risky and actually we're going to run this on my laptop. This is my own personal developer laptop. Not going to run this in a VM. Because again I want to 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 going to do is we're going to run the command and control server. This is listening for connections and then we're going to execute the malware 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 13 this will tell us where the malware is installed. We can see it's running out of users Patrick FPS odd. We can also do things like take a screenshot that is command number 2. Excee that. We give it a parameter of 0 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 command and control server. So we can kill the server and we can open the screenshot and we can see yeah it took a tire screenshot of the desktop. Okay so that's fruit fly. Now let's talk about repurposing a cryptocurrency minor because maybe you want to 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 creative update. This cryptocurrency minor was spread via Trojanized applications and then spread via the popular third party application website Macupdate.com. If we mount the malicious disk image that contains one of these Trojanized applications and reverse engineer the applications 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 disassembler 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. And this is so the user who has downloaded this infected Trojanized application doesn't think anything is a mess. We can then see in the script it beacons out or connects out to a download server to download a zip archive named mdworker.zip. And then extracts this archive and persistently install 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 fruit fly 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 the second piece. Next we tweak the script so instead it utilizes the zip archive we just added. Finally we repackage everything up and we're ready to go. So we're going to do live demo number two. First I want to show you the repurposed malware 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 signed Mozilla. If we pop over here though we'll see that this is what the user downloads and expects to run. So what we can do is we're going to run this. This has been reconfigured again I'm 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 going to run this Firefox pops up everything looks great the user is stoked they've got this great browser. Now if we pop back to a terminal window behind the screens I 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 going to execute the miner named MD worker but we have repurposed it so it's instead is going to send all the results of the cryptocurrency mining operations to me. Sweet. Awesome. Alright well since we're talking about making money we all love to do that. Perhaps you want to deploy some ransomware without spending time writing your own. So now we'll walk through exactly how to repurpose key ranger. Key ranger was the first fully functional in the wild ransomware targeting macOS. Hackers infected the popular bit torrent client transmission on the legitimate applications website. This means that if users went to the transmission website to download the bit torrent 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 it turns out it's not a document it's really a mock-o binary. So what this mock-o binary does is first sleeps for a few days and then it connects out to the attackers 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 user's files and then displays the decryption instructions that demand a ransom. Pretty standard ransomware functionality. So let's talk about repurposing this ranger. First we're going to 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, knock out the call to the sleep function. Pretty easy to do. And modify the addresses of the servers that the ransomware contacts for the public 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. Pretty easy, right? And here for testing purposes we just set them to localhost 127.0.0.1. Now we also need a server because the ransomware is going to 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 RSA key and decryption instructions and package that up to an attacks file and then serve that up via Netcat. So here's a demo of key ranger that's now been repurposed. We'll see in the terminal window this is our server. Again it's just Netcat serving up the encryption key and the decryption instructions. The malware has been repurposed though to talk to this command and control server, 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 going to 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 is going to be like, crap this sucks how do I get my files decrypted. They're going to open the readme.decrypt file and you can now see we've 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. This is actually kind of mean, you know, maybe don't do that. Uh, the last sample I want to talk about repurposing is called windtail. Now windtail is a lovely backdoor written by a rather sophisticated APT group. Here we'll repurpose both their exploit and their own backdoor to use for our own missions, our offensive cyber surreptitious processes. Now one of the most interesting pieces 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 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 is 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 web page, 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 JavaScript which makes a request to that now registered custom URL scheme to launch the malicious application. In terms of the back door, so 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 flux2key.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 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 in ditto command and then 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 every time the malware starts up, it connects to the attacker's 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 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 popup or two but the average user probably is going to click through these. So here's a demo of the repurposed exploit that will drop and persist Wintail. We can see the page has downloaded the application and then we made that second request. There was a popup. 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 it doesn't really help us if we are spreading 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 servers 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 all the load a dynamic library and then once our library is running in the process address space of the malware we can basically modify the malware at run time 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 UPE. 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 C run time 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 execute this now repurposed malware we can see and watch this at run time and view the addresses of the command and control servers being swapped out. So at the bottom of the screen 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 in the malware that's trying to connect out so we basically just drop that and return our own. Again this ensures now that the backdoor will always communicate with our servers instead of the original APT groups. Now we still have to write a command and control server 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 wind tail backdoor 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 command and control server for this wind tail 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 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. You can leverage a lot of built in Python libraries to do this. And once we do that we then have the ability to task the implant. So let's watch this in action. We're going to see the malware connecting out to our command and control servers because we swapped out those addresses. And what we'll do is we'll have it download and execute the 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 infinitimately extensible. Finally let's add the ability to our custom command and control server so we can support the self-delete command. Because at some point you know if the FBI comes knocking on your door it 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 of the application originally tries to mimic a PowerPoint documentation. Kind of sticks out but this is in kind of a hidden system directory. What's going to happen is the malware is going to connect out to us, make the should I self-delete command a request. We're going to 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 backdoors, 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 macOS and third party AV products likely will block or detect these unless we do something about it. So first up let's talk about macOS' built in malware mitigations such as X protect, the malware removal tool and code signing 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, that would kind of suck. So let's start with X protect. X protect is a simple signature AV, simple signature based AV scanner that's built into all recent versions of macOS. It's 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 X protect dot yara, we can see various yara signatures to detect common pieces of Mac malware. For example key ranger the malware we just talked about repurposing. Now at digital we wrote a simple utility called UX protect that allows you to explore these signatures via the UI as well as at any time basically scan arbitrary files against these built in signatures. Now since X protect is purely a signature based detection mechanism it is incredibly trivial to bypass. So let's take a closer look at the signature for key ranger. 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 will 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 X protect signature. Demo time here we have two instances of key ranger again it was distributed in this infected transmission bit torrent client. On the left we have the original sample this is the hackers sample and on the right we have the repurposed sample that's going to talk to our own command and control servers to get the encryption key and then also it has that one byte modification to bypass X protect. So we're going to launch both of them we're going to see the original one is detected by X protect and blocked there's no option to run it the user has to click cancel. If we execute the second one it's going to say hey this is downloaded from the internet are you sure you want to run that user clicks yes the ransomware is now able to persistently install on the user system and immediately starts encrypting all their files. Woo! But wait there's more. 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 wind tails the wind tail binary and the original code signing certificate has been revoked by Apple proper. This means even if we repurpose this and 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 se so we can simply remove the code signing certificate and then either distribute the repurposed malware unsigned or re-sign it with another legit developer code signing certificate which is pretty easy to get. So to unsign it Apple actually provides a utility called code sign there's 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 revoked code signing certificate. And then as I mentioned we can just deploy it as is unsigned or if we want to get a little more fancy we can re-sign it again using the code sign utility passing in the dash S flag. This means the re-signed wind tail will now no longer be blocked by macOS. Finally we have MRT this is Apple's malware removal tool it's another built in AV like tool that ships with all versions of macOS. It's similar to X protect but scans malware that may be already on the system and if it detects it it will automatically remove it. Now unlike X protect it's signatures are directly embedded in its binary kind of interesting and as an interesting aside Apple also uses MRT to remove legitimate software it deems unsafe such as the recent zoom application that had some vulnerable components. So giving a lot of power to Apple here for them to arbitrary remove files from your system. Now since MRT like X protect uses signatures it's 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 fruit fly which makes us wonder is this going to detect our repurposed fruit fly malware. Well if we examine the embedded MRT fruit fly signature we can see it's detecting fruit fly based on both the path of the malware and its 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 want to 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 going to dive into it a ton but suffice to say a traditional AV products that largely rely on signatures which is pretty much the norm especially on MacOS are equally trivial to bypass. For example I took fruit fly, recall it's a pearl script, I ran it through a free online pearl obvious skater 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 especially for the binary based malware so you can do things like pack them, use a custom encryptor or even in memory execution. Now I'll give a talk a few years ago about these techniques. I recommend checking that out because that can ensure that even if the user has a third party AV product installed on their system it will be unlikely to detect your repurposed malware creation. Now for Mac users this kind of sucks right? We showed that advanced adversaries are already using repurposed malware samples and that is actually not that difficult to do. Oftentimes we just have to switch a few bytes or change the command line arguments and now you 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 MacOS or those provided by third party AV products fail to detect these repurposed threats. This is my opinion is rather lame because if you think about it this repurposed malware is basically an exact copy of the original known malware. We've really just slightly reconfigured it. So I want to end this talk, kind of switch gears, we'll put on our white hats now and talk about how to generically detect such threats. So first this is a well-known fact that I hopefully just illustrated 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 functionalities its 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. A repurposed backdoor 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 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 want to take a closer look at it. So here for example we can now alert and generically detect when wind tail either the original or the repurpose item persist. Next up is mic and webcam access. A lot of Mac malware accesses the webcam or the mic 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 call back 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 fruit fly which we repurposed or an exploit like zoom anytime it accesses the mic or the camera. Next up we have key logger detection. Mower oftentimes tries to capture your keystrokes 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 anytime a new event tap is installed. This allows us to very trivially detect key loggers even if they have been repurposed. We talked a lot about fruit fly. This is one of the more sophisticated feature complete malware. One of the neat features that 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 as the creator of Objective C. This is my kind of personal Mac security web page. But the main goal of Objective C is to provide free and largely open source security tools for end users who are using Macs. 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 C dot com. Now a downside of these tools is they're all separate, right? There's an individual key logger detector, there's an individual firewall, there's not like an all in one solution. So when I started working at digital we decided to combine these into a single all in one tool. 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 note you can use these in other security tools as well. So this is not specific to our product per se. So using this system we can generically and rather trivially detect all the repurposed malware we talked about today. So for example, wind tail. We can detect its 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 request from a website. So detecting the combination of those events gives us a generic capability. Both against wind tail or any other malware that utilizes this same infection vector. Similarly we can detect fruit fly 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 fruit fly is already running on the system. We can also detect this by observing run time behaviors. For example fruit fly 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 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. We can look at them either cumulatively. We see one or two. We might want to 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 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 3.0. Some of you are aware Objective by the Sea is a MAC security conference that I organize each year. This year it will be back in Hawaii so if you want an excuse for your company to send you to Hawaii in February go to ObjectiveSea.com. Well that is a wrap. I want to 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 want to come up and chat and talk nerdy about MAC stuff. So again thank you though for attending I really appreciate it.
 Alright Aloha and welcome to my talk. Today we're going to be talking about harnessing  weapons of Mac destruction. My name is Patrick. I am a security researcher at Jamf. Previously  I was a co-founder at Digital Security and I'm also the creator of the Mac security website  and tool suite objective C. So today we're going to be talking about repurposing other  peoples 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 repurpose 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 methods to detect these repurposed 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 sophisticated fully featured malware and has deployed it to various  targets, right, infected various systems around the world. Spy B somehow captures this malware  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, incredibly well resourced, very motivated hackers,  APT groups and three letter government agencies that are creating some incredible malware. 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 the answer is they are. Now I can't comment specifically on this but  leak slides appear to indicate that the NSA has had this capability for a while. 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 APGT group already exists. So imagine you're in  the NSA you hack a high value target and you find out someone else is already there. Obviously  you don't want to 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 going to 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 going to  have a binary image. So we'll have to reverse engineer the malware at the binary level. This is  kind of 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 source code 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 generally known malware it's likely that  Apple or AV products already have detection signatures for this. So 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 given 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 backdoor, perhaps a piece of  ransomware, 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 gets caught it will be likely misattributed to them. So on  my website objectivec.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. And the main goal is to figure out things like 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 a 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 embedded 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 control. This means now when we  take this malware and redeploy it the malware will be can connect back to our infrastructure and be  ready for tasking. Now as I mentioned if the malware is a backdoor or implant and expects to talk to a  command and control server well if we're repurposing it we're going to 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 its remote capabilities. Now such a  custom command and control server really doesn't have to be anything incredibly fancy. We 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. In a previous demo we talked about creating 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 going to start with a sample called Fruit Fly. Fruit Fly is a rather unique piece of  Mac malware. It was originally developed over 15 years ago remaining in the wild and only very  recently became detected. It's a fully featured backdoor 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 backdoor that we can utilize for our own subversive purposes. Fruit Fly is actually written as  a Perl script though it's highly obfuscated. If we take a peek at the backdoor 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 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 malware, Fruit Fly, as a launch agent and 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 backdoor 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 hackers  original servers. But to deploy this we need an installer. Good news previously I wrote one  that's available on paceman 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 and covered in the wild. Finally as I  had previously written a custom command and control server to analyze the sample we can just  review this. So we're going to do a live demo now. Live demos are always risky and actually we're  going to run this on my laptop. This is my own personal developer laptop. Not going to run this  in a VM. Because again I want to 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  going to do is we're going to run the command and control server. This is listening for connections  and then we're going to execute the malware 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 13 this will tell us where the malware is installed. We  can see it's running out of users Patrick FPS odd. We can also do things like take a  screenshot that is command number 2. Excee that. We give it a parameter of 0 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 command and control server. So we can kill the  server and we can open the screenshot and we can see yeah it took a tire screenshot of the  desktop. Okay so that's fruit fly. Now let's talk about repurposing a cryptocurrency minor  because maybe you want to 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 creative update. This cryptocurrency minor was spread via Trojanized applications and  then spread via the popular third party application website Macupdate.com. If we mount the  malicious disk image that contains one of these Trojanized applications and reverse engineer the  applications 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 disassembler 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. And this is so the user who has downloaded this infected  Trojanized application doesn't think anything is a mess. We can then see in the script it beacons out  or connects out to a download server to download a zip archive named mdworker.zip. And then  extracts this archive and persistently install 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 fruit fly 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 the second piece. Next we tweak the script so instead it  utilizes the zip archive we just added. Finally we repackage everything up and we're ready to  go. So we're going to do live demo number two. First I want to show you the repurposed malware  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 signed Mozilla. If we pop over here though we'll  see that this is what the user downloads and expects to run. So what we can do is we're going to  run this. This has been reconfigured again I'm 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 going to run this  Firefox pops up everything looks great the user is stoked they've got this great browser. Now if  we pop back to a terminal window behind the screens I 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 going to execute the miner named MD worker but we have  repurposed it so it's instead is going to send all the results of the cryptocurrency mining  operations to me. Sweet. Awesome. Alright well since we're talking about making money we all  love to do that. Perhaps you want to deploy some ransomware without spending time writing your  own. So now we'll walk through exactly how to repurpose key ranger. Key ranger was the first  fully functional in the wild ransomware targeting macOS. Hackers infected the popular bit  torrent client transmission on the legitimate applications website. This means that if users  went to the transmission website to download the bit torrent 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 it turns  out it's not a document it's really a mock-o binary. So what this mock-o binary does is first  sleeps for a few days and then it connects out to the attackers 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 user's files and then displays the  decryption instructions that demand a ransom. Pretty standard ransomware functionality. So  let's talk about repurposing this ranger. First we're going to 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, knock out the call to the sleep function. Pretty easy to do. And modify the addresses  of the servers that the ransomware contacts for the public 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. Pretty easy, right? And here for testing purposes we just  set them to localhost 127.0.0.1. Now we also need a server because the ransomware is going to  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 RSA key and decryption instructions  and package that up to an attacks file and then serve that up via Netcat. So here's a  demo of key ranger that's now been repurposed. We'll see in the terminal window this is our  server. Again it's just Netcat serving up the encryption key and the decryption instructions.  The malware has been repurposed though to talk to this command and control server, 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 going to 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 is going to be like, crap this  sucks how do I get my files decrypted. They're going to open the readme.decrypt file and you  can now see we've 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.  This is actually kind of mean, you know, maybe don't do that. Uh, the last sample I want to talk  about repurposing is called windtail. Now windtail is a lovely backdoor written by a rather  sophisticated APT group. Here we'll repurpose both their exploit and their own backdoor to use  for our own missions, our offensive cyber surreptitious processes. Now one of the most  interesting pieces 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 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 is 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 web page, 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 JavaScript which makes a request to that now registered custom URL  scheme to launch the malicious application. In terms of the back door, so 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 flux2key.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 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 in ditto  command and then 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  every time the malware starts up, it connects to the attacker's 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 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  popup or two but the average user probably is going to click through these. So here's a demo of  the repurposed exploit that will drop and persist Wintail. We can see the page has downloaded  the application and then we made that second request. There was a popup. 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 it doesn't really help us if  we are spreading 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 servers 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 all the  load a dynamic library and then once our library is running in the process address space of the  malware we can basically modify the malware at run time 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 UPE. 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 C run time 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 execute this now repurposed malware we can see and watch this at run time and  view the addresses of the command and control servers being swapped out. So at the bottom of  the screen 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 in the malware that's trying to connect  out so we basically just drop that and return our own. Again this ensures now that the backdoor  will always communicate with our servers instead of the original APT groups. Now we still have to  write a command and control server 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  wind tail backdoor 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 command and control server for this wind tail 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 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. You can leverage a lot of  built in Python libraries to do this. And once we do that we then have the ability to task the  implant. So let's watch this in action. We're going to see the malware connecting out to our  command and control servers because we swapped out those addresses. And what we'll do is we'll  have it download and execute the 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 infinitimately extensible. Finally let's add the ability to our custom  command and control server so we can support the self-delete command. Because at some point you  know if the FBI comes knocking on your door it 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 of the application originally tries to  mimic a PowerPoint documentation. Kind of sticks out but this is in kind of a hidden system  directory. What's going to happen is the malware is going to connect out to us, make the  should I self-delete command a request. We're going to 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 backdoors, 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 macOS and third party AV products likely  will block or detect these unless we do something about it. So first up let's talk about  macOS' built in malware mitigations such as X protect, the malware removal tool and code  signing 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, that would kind of suck. So let's start with X protect. X protect is a  simple signature AV, simple signature based AV scanner that's built into all recent versions  of macOS. It's 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 X protect dot yara, we  can see various yara signatures to detect common pieces of Mac malware. For example key  ranger the malware we just talked about repurposing. Now at digital we wrote a simple utility  called UX protect that allows you to explore these signatures via the UI as well as at any  time basically scan arbitrary files against these built in signatures. Now since X protect is  purely a signature based detection mechanism it is incredibly trivial to bypass. So let's take a  closer look at the signature for key ranger. 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 will 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 X  protect signature. Demo time here we have two instances of key ranger again it was distributed  in this infected transmission bit torrent client. On the left we have the original sample this is  the hackers sample and on the right we have the repurposed sample that's going to talk to our own  command and control servers to get the encryption key and then also it has that one byte  modification to bypass X protect. So we're going to launch both of them we're going to see the  original one is detected by X protect and blocked there's no option to run it the user has to  click cancel. If we execute the second one it's going to say hey this is downloaded from the  internet are you sure you want to run that user clicks yes the ransomware is now able to  persistently install on the user system and immediately starts encrypting all their files.  Woo! But wait there's more. 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 wind tails the wind tail  binary and the original code signing certificate has been revoked by Apple proper. This means  even if we repurpose this and 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 se so we  can simply remove the code signing certificate and then either distribute the repurposed malware  unsigned or re-sign it with another legit developer code signing certificate which is pretty  easy to get. So to unsign it Apple actually provides a utility called code sign there's 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 revoked code signing certificate. And then as I  mentioned we can just deploy it as is unsigned or if we want to get a little more fancy we can  re-sign it again using the code sign utility passing in the dash S flag. This means the  re-signed wind tail will now no longer be blocked by macOS. Finally we have MRT this is  Apple's malware removal tool it's another built in AV like tool that ships with all versions of  macOS. It's similar to X protect but scans malware that may be already on the system and if it  detects it it will automatically remove it. Now unlike X protect it's signatures are  directly embedded in its binary kind of interesting and as an interesting aside Apple  also uses MRT to remove legitimate software it deems unsafe such as the recent zoom application  that had some vulnerable components. So giving a lot of power to Apple here for them to  arbitrary remove files from your system. Now since MRT like X protect uses signatures it's  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 fruit fly  which makes us wonder is this going to detect our repurposed fruit fly malware. Well if we  examine the embedded MRT fruit fly signature we can see it's detecting fruit fly based on both  the path of the malware and its 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  want to 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 going to dive into it a ton but suffice to say a traditional  AV products that largely rely on signatures which is pretty much the norm especially on MacOS are  equally trivial to bypass. For example I took fruit fly, recall it's a pearl script, I ran it  through a free online pearl obvious skater 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 especially  for the binary based malware so you can do things like pack them, use a custom encryptor or even in  memory execution. Now I'll give a talk a few years ago about these techniques. I recommend  checking that out because that can ensure that even if the user has a third party AV product  installed on their system it will be unlikely to detect your repurposed malware creation. Now  for Mac users this kind of sucks right? We showed that advanced adversaries are already using  repurposed malware samples and that is actually not that difficult to do. Oftentimes we just have  to switch a few bytes or change the command line arguments and now you 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 MacOS or those  provided by third party AV products fail to detect these repurposed threats. This is my  opinion is rather lame because if you think about it this repurposed malware is basically an exact  copy of the original known malware. We've really just slightly reconfigured it. So I want to end  this talk, kind of switch gears, we'll put on our white hats now and talk about how to generically  detect such threats. So first this is a well-known fact that I hopefully just illustrated  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  functionalities its 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. A repurposed backdoor 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 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 want to take a closer look at it. So here for example we can now alert and  generically detect when wind tail either the original or the repurpose item persist. Next up is  mic and webcam access. A lot of Mac malware accesses the webcam or the mic 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 call back 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 fruit fly which we repurposed or an exploit like zoom anytime it  accesses the mic or the camera. Next up we have key logger detection. Mower oftentimes tries to  capture your keystrokes 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 anytime a new event tap is installed. This  allows us to very trivially detect key loggers even if they have been repurposed. We talked a lot  about fruit fly. This is one of the more sophisticated feature complete malware. One of the  neat features that 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 as the creator of Objective C. This is my kind of personal Mac security web  page. But the main goal of Objective C is to provide free and largely open source security  tools for end users who are using Macs. 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 C dot com. Now a  downside of these tools is they're all separate, right? There's an individual key logger  detector, there's an individual firewall, there's not like an all in one solution. So when I  started working at digital we decided to combine these into a single all in one tool. 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 note you  can use these in other security tools as well. So this is not specific to our product per se. So  using this system we can generically and rather trivially detect all the repurposed malware we  talked about today. So for example, wind tail. We can detect its 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 request from a website. So detecting the  combination of those events gives us a generic capability. Both against wind tail or any other  malware that utilizes this same infection vector. Similarly we can detect fruit fly 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 fruit fly is already running on the system. We can also detect this by  observing run time behaviors. For example fruit fly 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 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. We can look at them  either cumulatively. We see one or two. We might want to 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 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 3.0. Some of you are aware Objective by the Sea is a  MAC security conference that I organize each year. This year it will be back in Hawaii so if  you want an excuse for your company to send you to Hawaii in February go to ObjectiveSea.com.  Well that is a wrap. I want to 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 want to come up  and chat and talk nerdy about MAC stuff. So again thank you though for attending I really  appreciate it.
Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_0_95.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_96_947.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_948_1643.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_1644_1691.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_1692_3227.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_3228_4775.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_4776_6479.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_6480_8975.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_8976_9947.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_9948_10187.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_10188_11615.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_11616_12707.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_12708_13787.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_13788_16415.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_16416_17567.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_17568_18983.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_18984_19031.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_19032_20195.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_20196_20531.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_20532_20711.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_20712_20759.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_20760_20831.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_20832_23747.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_23748_25091.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_25092_25979.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_25980_26327.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_26328_26843.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_26844_28259.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_28260_28979.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_28980_30071.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_30072_30575.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_30576_31175.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_31176_32003.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_32004_32123.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_32124_35279.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_35280_37019.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_37020_39035.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_39036_39143.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_39144_39335.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_39336_39767.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_39768_39827.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_39828_43307.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_43308_45131.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_45132_45215.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_45216_45299.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_45300_45731.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_45732_45815.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_45816_46679.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_46680_47063.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_47064_47639.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_47640_47699.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_47700_48443.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_48444_49307.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_49308_49355.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_49356_53087.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_53088_53387.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_53388_54263.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_54264_58643.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_58644_60263.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_60264_61571.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_61572_65063.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_65064_65999.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_66000_67343.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_67344_67391.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_67392_67919.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_67920_70151.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_70152_71951.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_71952_72911.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_72912_73211.png Patrick_Wardle_-_Harnessing_Weapons_of_Mac_Destruc_InL3YA_6P6s_73212_73255.png