 Alright Aloha and welcome to my talk. Uh today we're going to be talking about harnessing weapons of Mac destruction. My name is Patrick. I am a security researcher at Jamf. Uh previously I was a co-founder at 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 people's malware for our own surreptitious purposes. We'll start by showing why this is rather an excellent idea and then show exactly how to repurpose various Mac malware samples. Of course we want our repurposed samples to remain undetected both by Apple's built in malware mitigations and third party AV products so we'll address that as well. Finally we'll end by covering various generic ma- methods to detect these repurposed uh creations because really our ultimate goal is to ensure that Mac users remain protected. So let's dive in. So here we have a diagrammatic overview that conceptually explains the repurposing process. So imagine that spy A has developed some neat uh sophisticated uh fully featured malware and has deployed it to various targets, right? Infected various systems around the world. Spy B somehow captures this malware. Uh perhaps either in transit or pulls it off an infected system. Spy B then will take this malware sample to her lab and then repurpose it. So what do we mean when we talk about repurposing? Well we'll get into this more shortly but basically we're talking about reconfiguring a piece of existing malware so that you can use it for your own surreptitious purposes. So for example we can see on the slide once spy B has repurposed the malware she can now redeploy that against new targets and instead of beaconing back to spy A's infrastructure for tasking it'll talk to her new infrastructure instead. Now you might be thinking okay this seems like a reasonably neat idea but why? And we'll talk about two reasons that hopefully show that we should really be asking why not. So first there are incredibly well funded uh incredibly well resourced uh very motivated hackers, APT groups and three lever three letter government agencies that are creating some incredible malware. Uh this malware is fully featured and has the benefit of being fully tested a lot of times already even tested in the wild. Now I'm rather lazy I would rather be sleeping on the beach or surfing or doing yoga so I figured why not let these groups create this incredible malware and then we can just repurpose it for our own missions. The idea is to let those with more time resources and money do all the hard work. Secondly if our repurposed creations that we redeploy get captured it's very likely that they will be misattributed back to the original authors not to us. This is great. Now you might be thinking okay Patrick if this is such an amazing idea why aren't people already doing this? Well the answer is they are. Now I can't comment specifically on this but leak slide uh 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 APHT 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. Are you looking for an interactive backdoor, perhaps a piece of rent somewhere, cryptocurrency miner, take your pick. And then maybe attribution is important to you. 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. In terms of purpose or as we mentioned the main goal is to figure out things like if it has any remote access, right? If it's talking to a 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 back door or an 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 can 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 we'll 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 back door which supports a myriad of remotely taskable capabilities which really makes it the perfect candidate for us to repurpose. As we'll see we can very trivially repurpose this malware and then that gives us access to a proven fully featured back door that we can utilize for our own subversive purposes. Fruit Fly is actually written as a pearl script though it's highly obfuscated. If we take a peek at the back door we can see logic that processes command line arguments that is to say the script will check if it's been invoked with certain command line arguments, parameters or flags. Turns out it's looking for a port or a port and IP combo of the command and control server to connect to. So this means if we specify our own via the command line we don't actually have to modify the pearl script or the malware binary itself. So what we can do is we can persist this 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 back door to connect to our custom command and control server right because we can specify in the command line we can now push that out, give the address of our own server and the malware when it runs will connect directly back to us instead of the hackers original servers. But to deploy this we need an installer. Good news previously I wrote one that's available on Payspin 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 gonna do a live demo now. Live demos are always risky and actually we're gonna run this on my laptop. This is my own personal developer laptop. Not gonna run this in a VM because again I 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 gonna do is we're gonna 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 thirteen 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 two. Execute that. We give it a parameter of zero saying we want a full screen capture. And this will tell the malware which has been deployed to my personal system now to please take a screenshot and send it back to the 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 miner 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 miner 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 amiss. 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. Finder window. First I want to show you the repurposed malware it's kind of application bundle. We can see this is an app and within the app there is this script file. There's the original Firefox. This is the one that 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. 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 right 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 KeyRanger. KeyRanger 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.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 attacker's command and control server expecting a response consisting of a 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. 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 text file and then serve that up via Netcat. So here's a demo of KeyRanger 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. 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 provided our own decryption instructions. So here I've said hey, you know, sorry about losing all your files, send me buckets of money and I will decrypt them for you. It's actually kind of mean, you know, maybe don't do that. The last sample I want to talk about repurposing is called Wintail. Now Wintail 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 piece of this attack was the Maurer's infection vector. And the way it was able to infect fully patched Mac systems while it was by leveraging a legitimate functionality of Mac OS by abusing something called custom URL schemes. Now I've written a long detailed blog that really dives into the technical underpinnings of this. But in a nutshell, on Mac OS, as soon as an application 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. 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 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 webpage that auto downloads a zip file containing a malicious application. As we mentioned, 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 webpage can then make a request to that now registered custom URL which will cause the application to be launched. Now there will be a pop-up or two, but the average user probably is going to click through these. So here's a demo of the repurpose 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 pop-up. Again, if the user clicks through which some percentage of users will fall for, we can see that now the malware has been automatically and persistently installed. Again, since this is a logic flaw, there's nothing really for Apple to patch. So this still works on the latest version of Mac OS. So now we've repurposed the exploit. Let's talk about repurposing the malware because 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 always 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 runtime to intercept the decrypted addresses of the command and control server before the malware uses them to connect out. So let's look a little closer about how we accomplish this. Again, the goal is for us to specify our own command and control servers so that the malware connects back to our infrastructure. So our dynamic library has now been loaded into the address space of the malware. What we can do is we can swizzle or swap out the malware's decryption routine. It's a method named 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 runtime will actually now call our method in our library. What our method now does is calls into the original decryption routine. And I have no idea what the decryption algorithm is or how it works and frankly I don't care. But what I can do is since it's swizzled and passing through us, I can see the results of that encryption. So if the original decryption method returns the decrypted addresses of the command and control servers, I can just return my own command and control server back into the malware's logic. So this dynamically gives us the ability to transparently swap out the decrypted command and control servers with our own. And the malware is none the wiser. Now I added some debug messages to the library so if we execute this now repurposed malware, we can see and watch this at runtime and view the addresses of the command and control servers being swapped out. So at the bottom of the screen, 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 back door 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 back door is to collect and exfiltrate files. So let's add this first to our custom command and control server. Files are exfiltrated via post requests. So we simply write a few lines of code in Python to handle this saving off each file the malware sends to us from the infected host. So here's a demo now of our custom command and control server receiving exfiltrated files from the attacker. On the left you can see the network requests coming in and on the right all our command and control server does is write these out to the file system. This means we now support the ability to respond to the malware as it exfiltrates all sorts of files off infected hosts. Let's also extend our custom 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 then the second request we need to respond with the actual bytes of the file we want to download. The malware will then save that to the file we specify and then unzip that and execute that. Now again we only need a few lines of code in Python. We can leverage a lot of built in Python libraries to do this. 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've 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 infinitely 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 gonna happen is the malware is going to connect out to us make the should I self-delete command a request. We're gonna respond with one which will cause the implant to uninstall itself and then terminate. So we can see it disappear and then it stops beaconing because obviously it's just self-deleted. Alright so we've showed exactly how to repurpose a myriad of Mac malware. We talked about 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. Uh 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 uh 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 a 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 uh here we have two instances of key ranger. Again it was distributed in this infected transmission BitTorrent client. On the left we have the original sample. This is the hacker's sample. And on the right we have the repurposed sample that's gonna talk to our own command and control servers to get the encryption key. And then also it has that one byte modification to bypass X-Protect. So we're gonna launch both of them. We're gonna 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 gonna say hey this is downloaded from the internet. Are you sure you wanna 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 signed. 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'll automatically removes it. Now unlike X-Protect its 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 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 and recall it's a pearl script. I ran it through a free online pearl obfuscator which caused detections on virus total to drop all the way to zero. Now that works but you might want to use more sophisticated capabilities 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 gave 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'll 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 in 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 and 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 repurposed 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 persists. Next up is mic and webcam access. A lot of Mac malware accesses the webcam or the mic to spot to spy on the users of an infected system. So to detect this subversive activity we can register with macOS. It turns out there is a callback you can register that anytime anybody accesses either the mic or the webcam you will programmatically get notification of that fact. So this will allow us to detect malware even something like fruit fly which we've repurposed or an exploit like zoom anytime it accesses the mic or the camera. Next up we have key logger detection. A malware often times tries to capture your keystrokes to steal things like passwords and credit card information. On macOS 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 macOS 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 I was 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 ObjectiveC.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 say. So using this system we can generically and rather trivially detect all the repurpose malware we talked about today. So for example, Wintail. 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 Wintail 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 runtime 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 to 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 really attending. I really appreciate it.