Patrick Wardle: Making the Old, New: repurposing macOS malware
Patrick Wardle speaking at the Jailbreak Brewing Company Security Summit on Friday, October 11, 2019.
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! 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 a crypto-miner. Customizations include various configuration and 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 blocked by macOS and/or detected by AV products. As such we’ll also walk-thru subtle modifications that will ensure our modified specimens 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.
(Source: Jailbreak Brewing Company)
Transcript
Patrick Wardle: [00:00:38:18] Welcome to my talk. We're going to be talking today about repurposing Mac malware. So, as I mentioned, my name is Patrick. I was previously a co-founder of Digita Security; also the creator of the Mac security website and tool suite, Objective-See. I now work for jamf.
Patrick Wardle: [00:00:59:02] So, today we're going to be talking about repurposing other people's Mac malware for our own surreptitious purposes or perhaps our own offensive cyber security operations. We're going to start by showing why this is rather an excellent idea, and then explain and show exactly how to repurpose various pieces of Mac malware. Of course we'll want our repurpose samples to remain undetected by macOS' built-in malware mitigations, so we'll address that as well.
Patrick Wardle: [00:01:32:00] Finally, we'll end by discussing various methods that aim to generically detect these macOS threats both ones that are already out there and the ones we're going to be talking about today because ultimately we want to make sure that Mac users remain secure.
Patrick Wardle: [00:01:50:04] Okay, so let's dive in. So, first here we have a diagrammatic overview that conceptually explains the repurposing process. So, imagine spy "a" or perhaps agency "a" has developed some sophisticated fully-featured Mac malware and has deployed it to various targets. Spy "b" comes along or perhaps agency "b" and somehow captures this malware perhaps either in transit or pulls it off an infected system. Spy "b" then takes this captured malware to her lab and repurposes it.
Patrick Wardle: [00:02:24:20] So, what do we mean by "repurposing"? Well, we'll get to this more in detail shortly but essentially you can think of it as reconfiguring the malware often at the binary level so that you can use it for your own operations. So, for example, as we see on the slide, once the repurposed malware has been redeployed and reconfigured, once it's now infecting new targets it's no longer going to connect back to spy "a"'s infrastructure. Instead, it's now going to be talking to spy "b", so now spy "b" can obviously task these systems.
Patrick Wardle: [00:03:00:15] Now, you might be thinking, "Alright, this seems like a fairly neat idea but why should we do this?", and there's two main reasons that I think we should really be asking instead of why, why not? So, first, if you think about it, and I'm sure many of you are very aware of this fact there are a lot of well funded, well resourced, very motivated APT groups and three-letter agencies that are creating amazing malware that's fully featured and fully tested, sometimes already tested in the wild on, you know foreign systems. Honestly, I'm kind of lazy. I'd rather be drinking beer, surfing, taking a nap than writing malware, so I figured it seems a little more intelligent to simply let those groups create this very sophisticated elegant malware and then let's just go ahead and repurpose it and utilize it for our missions. So, the idea is kind of work smart not hard, right?
Patrick Wardle: [00:03:53:14] Second, if these repurposed malware creations get detected or uncovered, it's very likely they will be mis-attributed back to the original authors which for us is rather lovely. Now, you might be thinking, "Okay, Patrick, this seems like a reasonable idea but you know, if it's such a good idea, why aren't other people already doing it?", and it's a fair question, and the answer is well, they actually are. So, I can't really comment on this per se but there were some leaked slides that appear to show that the N.S.A. has such capabilities. Also, Arecent reporting by the New York Times has indicated the Chinese are doing this as well.
Patrick Wardle: [00:04:32:22] Now, to these very well resourced agencies, the benefit of using this repurposed malware is twofold. So, first, it allows them to deploy other people's malware that's been repurposed into perhaps risky environments. For example, where another actor already exists. So, hypothetically speaking, imagine you're in the National Security Agency, you hack a system and you see another that group is already there. Perhaps it's the Russians, the Chinese, somebody else, maybe another hacking group. Obviously, you don't want to deploy your original custom implants, right? That would just be ridiculous, way too risky. So, instead if you have another country's malware that you've repurposed, and there's really no risk to installing that there, giving you continued access to that system. Also, we mentioned using repurposed malware will kind of muddy the attribution picture and to such agencies that's always a good thing.
Patrick Wardle: [00:05:26:18] Now, of course there's challenges to repurposing other people's malware. If it was trivial we wouldn't be having this presentation and this talk today, but as we'll see these challenges are not insurmountable. So, first, and probably the biggest challenge, is generally speaking you don't have the source code for said malware, right? You're normally just going to have a binary which means you're going to have to reverse engineer the malware at the binary level. During this analysis stage, and we'll kind of walk through this in some example, we're generally just trying to gain a comprehensive understanding of the malware. For example, answering questions such as, "You know, how does it persist?", "What does it do?", "How does it communicate?".
Patrick Wardle: [00:06:08:21] Then, with that understanding, we'll have to go through and reconfigure or repurpose it generally through binary patches which again can be somewhat complex, and you want to make sure you get that right otherwise the malware might crash. Now, if the malware has the ability to talk to a remote system, for example, it might connect out to a kinetic control server for tasking, you're going to have understand the protocol and then also have to write a custom command and control server. So, this is another challenge we have to address.
Patrick Wardle: [00:06:36:01] Then, finally, as we're generally repurposing known malware, it's likely that macOS' built-in malware mitigations and/or third party anti virus products are going to have signatures for these malware samples. So, the challenge therefore is even once we reconfigure these samples is to make sure these modifications, these new versions of the malware remain undetected.
Patrick Wardle: [00:06:59:16] Now, I want to reiterate it's actually rather important to take these challenges seriously and get them right because if not, you know, kind of bad things can happen. So, here, for example, we've attempted to repurpose a piece of malware but it turns out we actually forgot or maybe we didn't uncover the fact that this malware has some embedded backup command and control addresses. Now, if we forget to patch out and modify those, if we deploy this malware believing that's it's been fully reconfigured, at some point it actually might beacon back to the original hackers' infrastructure, their command and control servers which would give them, him or her, access to our new systems. So, obviously that's clearly not ideal.
Patrick Wardle: [00:07:43:06] Another example of a fail, if you're going to use someone else's malware you've got to make it believable. So, here we have a kind of humorous real world example. In this case, the hacker didn't repurpose the malware per se but rather simply planted it to fake attribution. So, then a student who was caught changing her grades could simply claim, "I couldn't have done it because my computer was hacked." However, rather humorously the samples they chose were downloaded from my website and were completely implausible. So, there were two samples on this woman's computer. Again, she claimed that, "It couldn't have been me, it could have been anyone because my computer is fully owned, fully hacked.", but again if we look closer at the pieces of malware on the system, it's clear that they were planted.
Patrick Wardle: [00:08:29:11] So, first was a proven concept piece of Mac malware that actually didn't even run, right? If you execute it, as we can see on the slide it would simply crash. The second piece was an interesting piece of Mac malware that was developed by the Lebanese government to target military and various other high priority targets. Clearly, it would never end up on a student's computer. So, again, the kind of takeaway here is make sure you're also picking samples to repurpose that are somewhat believable.
Patrick Wardle: [00:08:57:01] So, now let's talk about exactly how to repurpose Mac malware with the goal of making other people's malware our own. So, the first step to repurpose a piece of malware is to select the one, the Malware sample you're going to repurpose, and this is usually based on two criteria. So, first, you need to decide what you want your malware specimen to do. You're looking for an interactive backdoor, a piece of ransomware or perhaps a persistent crypto currency miner.
Patrick Wardle: [00:09:32:19] Second, attribution may be important to you. You're looking for a sample that's going to be mis-attributed to a U.S. government agency or perhaps a Russian hacking group. So, on my website, Objective-See.com, there is a very comprehensive collection of Mac malware that's kind of organized by type. I don't have the attribution but that's generally known as well. So, that's a great place to start, and I want to know all the samples we're going to be talking about today and repurposing are available for download as well. So, if you want to go and play around with some of these samples, go grab those.
Patrick Wardle: [00:10:06:22] So, once you've selected a piece of malware to repurpose, as I mentioned kind of the first step is to analyze it. In terms of repurposing or reconfiguring the sample, the main goals of this analysis include things like uncovering any logic that involves remote interactions. For example, you want to figure out if the malware contains an address of a command and control server, and if it then connects to that server for tasking. Because obviously we want to modify those embedded command and control servers, so instead it talks to our systems for tasking. If the malware does talk to one of these systems, you'll also to have to analyze the malware to gain an understanding of its protocol because when it connects now to your command and control server you will have to give it the correct protocol format of the arguments, etcetera, so that you can remotely task it.
Patrick Wardle: [00:10:53:21] And of course you will want to fully understand all its capabilities as well: both local, for example, how it persists, how it interacts with the system, and then also remote capabilities. These are the commands that you can remotely task, right? Does it allow you to take a screen capture or a command, execute a file, ex-filtrate data, etcetera.
Patrick Wardle: [00:11:14:22] Now, once you have a comprehensive understanding of the malware, it's now time to actually reconfigure or repurpose it. Generally, this means we'll have to patch the malware often at the binary level. So, here's kind of a conceptual example. You can see on the slide, we've located the address of the malware's remote command and control server that's been embedded directly in the malware. So, what we can do is we can simply modify these bytes. For example, patch them out in a hex editor and change them to be the address of our own command and control server which means now when we redeploy this now reconfigured piece of malware, for example, to new targets, it will now connect to our command and control server for tasking.
Patrick Wardle: [00:11:58:05] As I mentioned if the malware is a backdoor or an implant that expects to talk to a remote command and control server, once we've repurposed the malware's binary we're going to have to create a custom command and control server. This will ensure that, you know, we can task it once it connects out to us. Now, such a command and control server doesn't have to be anything incredible. I usually just whip up a simple Python script that talks the protocol of the malware but if you were going to be deploying these repurposed malware samples to a large number of systems you might want to create something more comprehensive.
Patrick Wardle: [00:12:34:14] So, a few years ago at DEFCON I gave a talk about creating such a custom command and control server. The purpose of that talk was to show how you could create such a server to actually analyze a piece of malware but it's still a good overview of how you go about creating such a server that can talk to a piece of malware. So, check that out.
Patrick Wardle: [00:12:55:00] So, now it's time to actually look at some specific examples where we will walk through exactly the process of repurposing some Mac malware. We're going to start with Fruitfly. So, Fruitfly was a rather unique interesting piece of Mac malware. It was initially developed over 15 years ago and remained undetected and functional until quite recently. It is, as we can see on the slide, a fully-featured backdoor that supports a myriad of capabilities which makes it actually a really good target for us to repurpose. As we'll see, it's actually very easy to fully reconfigure this malware which then gives us a proven fully-featured backdoor to utilize for our own subversive purposes.
Patrick Wardle: [00:13:41:12] So, Fruitfly was actually written in Perl which is interesting, although it was fairly obfuscated. If we analyze, take a peak at this obfuscated Perl script, we can see that there's logic that is processing command line arguments, and if we dig into that a little more we can see that what it's looking for is either a port or an IPport combination for a commanding control server. So, this means we can simply pass in the other command line the address of our command and control server without actually having to modify any piece of malware. It's awesome.
Patrick Wardle: [00:14:16:00] So, for example, if we persist this malware on a new target on a new system, for example, as a launch agent, we can also pass in now the address of our own custom command and control server in the agent's p-list as we can see on this slide.
Patrick Wardle: [00:14:31:09] So, we can trivially repurpose this backdoor to connect out to our custom command and control server but to deploy this we need an installer as the original malware's installer was actually never uncovered: it was never found. Good news, I previously wrote one. It's available on pastebin and you can see its actually just a few lines of code. All it does is once you have code execution on the system, it persistently installs the malware in a manner that matches exactly how it was uncovered in the wild. Again, it's always good to kind of mimic what the malware originally did mostly for mis-attribution purposes.
Patrick Wardle: [00:15:06:02] Finally, as I had previously written a custom command and control server to analyze the sample, we can actually just re-use that here. So, here's the demo on the right, we have our custom command and control server. We're going to start that up, and it's going to start listening for connections from the repurposed malware sample: from Fruitfly. On the left, we're then going to run the Fruitfly installer which is going to persist and execute this repurposed version of the malware. We're then going to issue the screen capture command from the command and control server and the implant will send us a screen capture.
Patrick Wardle: [00:15:35:16] So, we're going to execute this. Again, we start by launching the command and control server. We install the malware. The malware connects out. We give it the command to capture the screen-shot for us. The malware takes the screen-shot, sends it back to our command and control server, and then on the command and control server we open it just to prove that this successfully worked. So, this is great because now we have a very powerful fully-featured backdoor that performs to our bidding. We really didn't have to do anything other than write a simple installer and a lightweight command and control server. So, again, hopefully this illustrates the power of being able to repurpose other people's malware, right? They did the hard work already.
Patrick Wardle: [00:16:13:08] So, now let's talk about repurposing a crypto currency miner because maybe we like making lots of money and don't want to spend all the time writing our own sampler. So, our target is going to be a piece of Mac malware called CreativeUpdate. It's a crypto currency miner that was spread via Trojanized applications on the popular website Macupdate.com.
Patrick Wardle: [00:16:34:06] So, if we mount the malicious disc image that contains one of these Trojanized applications and reverse the application we can see it invokes a method called "Exec script without privs." and all this method does is execute a file named Script out of the applications resource directory.
Patrick Wardle: [00:16:54:10] So, let's take a peak at this script. We can see it first launches a pristine copy of the application. Here, for example, Firefox, and this is to ensure that the user thinks nothing is amiss, right? They just downloaded what they believe is a pristine copy of Firefox from Macupdate.com. When they double-click on it, it would be weird if Firefox didn't launch. So, that's the first thing this malware does. In the background though, once Firefox is off and running happily, it connects out to a server to download a zip file named, "mdworker.zip" and then it persistently installs something named, "mdworker" out of this downloaded zip archive.
Patrick Wardle: [00:17:31:04] So, if we take a closer look at the launch agent p-list that persists in the malware we can see the path to the persistent binary and the worker, and also some command line arguments that are passed to this binary. Now, if we execute the mdworker, for example, in a virtual machine to see what it does, it turns out it's actually a legitimate crypto currency miner that belongs to a company called Miner Gate. It's really just their command line miner. So, this means then these command line arguments that are passed in to this legitimate miner thereby specify the miner account, that is where to send the mining results to and also the type of the crypto currency to mine.
Patrick Wardle: [00:18:13:00] So, similar to Fruitfly, since the relevant parameters are actually passed in the command line as opposed to being directly embedded into the malware, it's actually very trivial for us to fully repurpose this. So, the first thing we do is we modify the property list and we specify our own miner account. Then we zip up the malware's components. Now, instead of having the malware connect out to a download server to download the zip package, we just add that archive directly to the application's resource bundle. This just makes it more similar, right? You don't have to now stand-up download server it's more self-contained. Next, we tweak the script that it's executed, so instead it utilizes the embedded zip archive as opposed to trying to download it, that we just added to the application's resource and then we re-package everything up so it looks like this beautiful pristine Firefox.dmg disc image.
Patrick Wardle: [00:19:07:17] Demo time, again we're now going to run this re-purposed crypto currency miner. If we execute this, for example, from the command line we are going to see, eventually, yes that Firefox is first launched. You know, so users are going to be none-the-wiser. However, if we pop into a terminal we can see that there is a new launch agent that's just been installed that will persistently execute the crypto currency miner every time the user re-logs in. Again, passing the results of the mining to an account that belongs to me.
Patrick Wardle: [00:19:38:16] So, now we go and we can obviously install this on a large number of machines and retire hopefully soon. Okay, let's talk about money, still you know, it's a fun thing to talk about. So, perhaps you're not super into crypto currency mining but you might be stoked about ransomware. So, let's talk about how we can fairly trivially repurpose an existing piece of ransomware, again without actually spending any time writing it ourselves.
Patrick Wardle: [00:20:05:20] So, here we're going to walk through how to repurpose a piece of Mac malware called KeRanger. So, KeRanger was the first fully functional in the wild piece of ransomware that targeted macOS. What hackers did, rather ingenuously, is they infected the popular transmission BitTorrent client on the application's official website. This means any users who went to download this BitTorrent client would in actuality get a copy of the BitTorrent client that had been Trojanized to pertain this ransomware. So, that sucks for the users, right? They're really not doing anything wrong in this scenario.
Patrick Wardle: [00:20:45:06] If we look at the malware's binary code we can see it executing something called "General.rtf" out of the application bundle. If we look at this it appears perhaps to be a document based on the name and the icon, but if we execute the file command we can actually see it's a Mach-o executable binary.
Patrick Wardle: [00:21:03:07] So, let's take a peak at what this binary does. This is actually the malicious component of the ransomware. First thing it does is it sleeps for three days. Then, it connects out to the hacker's remote command and control server expecting a response consisting of a public RSA encryption key, and then also the instructions for decryption. It then uses that key that it received from the command and control server to encrypt all of the users' files, and then once that is completed it displays the decryption instructions that basically demand a ransom. It's pretty standard ransomware.
Patrick Wardle: [00:21:38:00] So, let's talk about now how we repurpose this ransomware so that we can deploy this in big money off unsuspecting users. So, first thing is, we don't want to wait for three days. We're kind of greedy we're in a hurry. So, what we're going to do is first just patch out the function that calls into the sleep method. So, we can see on the slide there's basically a call to a method called, wait or exit. We just put some instructions here. This means now that we'll just execute over that and the call won't be executed meaning the malware won't actually sleep for three days. Then, what we do is we modify the addresses of the servers that the ransomware connects out to, again for that encryption key and for the decryption instructions. So, we can see on the slide, these addresses are embedded directly in the malware's binary in an unencrypted state. So, very easy for us to pop into a hex editor and just change the bytes to point to our command and control server. In this case we set it to one-27 dot zero dot zero one just for testing purposes, but obviously you can put in any address of whatever command and control server you own or control.
Patrick Wardle: [00:22:43:18] Now, we obviously need a server because now when the repurposed ransomware executes it's going to connect out looking for that encryption key and those decryption instructions. It turns out this is really easy to do. In fact, we can just put this expected response, public RSA key and the decryption instructions into a text file and then serve that up.
Patrick Wardle: [00:23:04:13] So, here we're going to see a demo of this. We'll see that when we execute the reconfigured ransomware, KeRanger. It's now going to connect to our command and control server which we will provide our public RSA encryption key and also our own instructions for decryption. What the malware is going to do is then it's going to encrypt all the files on the system, for example, you can see these PDF documents on the desk-top all being encrypted and then when it's done there is a file on the desk-top that contains the decryption instructions which again we've passed from our command and control server. In this case, it basically says, "Please send Patrick lots of money." Obviously, in a real situation you probably have a Bitcoin address and some more detailed instructions.
Patrick Wardle: [00:23:46:12] Finally, we've got Windtail. Windtail is a very lovely rather delightful fully-featured backdoor that was written by a rather sophisticated APT group. Rather interestingly, it was used in attack to target individuals of a certain middle-eastern government. So, a fairly sophisticated decent piece of Mac malware. We're going to talk about repurposing both the exploit that was used in this attack and also the backdoor. So, one of the most interesting pieces of this malware, besides its targeting, was its exploit and infection vector. It turns out it abuses a legitimate functionality or feature of the macOS operating system known as Custom URL Schemes.
Patrick Wardle: [00:24:29:13] Now, I wrote a detailed blog post about this, so if you want to get super nerdy and in to all the technical details, I recommend checking that out, but in a nutshell on macOS, as soon as an application or an app bundle is saved to the file system, if that application has the ability to handle Custom URLs, macOS will actually parse that application bundle and automatically register the application as a handler for those Custom URLs. There's no user interaction at this point.
Patrick Wardle: [00:24:57:02] Now, once the application has been registered, again kindly by the operating system automatically, it can now be launched via a request to handle that Custom URL, for example, from a browser. So, in the case of these attackers, they realize this exploit in Java Script that was embedded on a malicious website.
Patrick Wardle: [00:25:16:12] In terms of the backdoor, once it's been launched, the exploit, it persists as a log-in item and supports capabilities such as file ex-filtration which makes sense because again it's an implant used by this fairly sophisticated APG group in targeted offensive cyber security operations. So, we execute this malware in a virtual machine and we also run a process monitor we can see that the malware leverages macOS' built-in zip utility to compress files, and then we'll use also the built-in curl command to ex-filtrate these files to the attacker's command and control server. So, this is how it accomplishes the file ex-filtration.
Patrick Wardle: [00:25:58:02] Another feature of this backdoor is that it supports a file download capability. So, if we reverse the malware's binary, as we can see on the slide there's a method called "sdf". Now, what it does is it decrypts the address of an embedded command and control server. Then, makes an initial request to the server to get a name for the downloaded file, and then makes a second request to get the contents of that file to save it to the infected system. Again, if we launch a network monitor and run the malware, for example, on a virtual machine, we can see both these requests, and note the decrypted command and control server address, "flux2key.com" This will come up again shortly.
Patrick Wardle: [00:26:39:16] The backdoor, once it's downloaded this file, will then go ahead and execute it. So, if we continue looking at the decompilation or the disassembly for the sdf method, we can see it first unzips this downloaded file. So, this means it expects it to be a zip archive, and it unzips it into the user's library directory, and it then executes it via the NSTask API.
Patrick Wardle: [00:27:03:17] Finally, the last feature or capability of the malware is self-delete. That can be executed or rather triggered remotely. So, every time the malware starts out, it connects to the embedded command and control server to a certain API endpoint, and if that endpoint returns a one this tells the malware it should uninstall itself and terminate. So, again it's neat to see this remote self-delete capability in the backdoor.
Patrick Wardle: [00:27:28:16] So, now we have a pretty good understanding of the features and capability of this really nice backdoor. So, now let's talk about repurposing it so it will do our bidding. First we're going to talk about repurposing the exploit. Pretty simple to create a malicious web page that auto downloads a zip file containing the malicious application. Since Safari, by default, automatically extracts zip archives, this means the application bundle will now be sitting on the file system, and as we noted when macOS sees an application bundle hit the file system it will automatically parse it, and if that application contains a handler for a Customs URL Scheme it will automatically register it.
Patrick Wardle: [00:28:10:20] So, qw wait a second or two to allow that to happen in the background, and then we trigger the launch of that malware via a Custom URL request. Now, there will be a pop-up or two especially on recent versions of macOS, but if the user clicks "allow" which we all know a large number of users will do, the system will now be fully infected.
Patrick Wardle: [00:28:31:11] -So, here's a demo of the repurposed exploit. In the background, we can see the download of the application. This is a pop-up basically saying, "Do you want to launch the application?", and then the system saying, "Are you really sure you want to launch the application?", and if the user clicks, "Allow", in these pop-ups, the malware will now be persistently installed and the system is now fully compromised, fully infected.
Patrick Wardle: [00:28:55:14] So, now we've talked about how to repurpose the exploit, right? We can use this to deploy our own capabilities, our own payloads. Let's talk about repurposing the Windtail backdoor component. So, the first thing we do is we need to modify the embedded command and control servers as obviously we want the repurposed implant to talk to our servers, right, not the addresses of the original hackers, that would be silly. Unfortunately, though, the addresses are embedded in the binary but in an encrypted manner. So, we can't just pop into a hex editor and patch them out, right? That would be too easy but not to worry. What we can do instead is coerce the malware to always load a dynamic library, and then code within this library can modify the addresses of the command and control servers at run time once the malware has decrypted them but before it has actually used them.
Patrick Wardle: [00:29:48:02] So, let's look a little closer about how we can actually accomplish this. So, once our dynamic library has been loaded, and it will every time the malware is started, we can "swizzle" or swap out the malware's decryption routine which is named "yoop", and this is accomplished by calling in to the rather powerful method exchange implementation API. As we can see on the slide then, once the decryption routine has been swizzled or swapped out, whenever the malware invokes the decryption method transparently, kind of under the hood, the objective C run-time will actually call our method in our library. And what our method does is it calls in to the malware's original decryption routine. We don't really care how this works, but when that original decryption routine returns to us it will hand us a nicely decrypted string. And what we do is we examine the string, and if it belongs or contains the value of a decrypted command and control server, we just basically drop that on the floor and actually return the address of our server, and the malware again is none the wiser. This happens all transparently thanks to the objective C run-time.
Patrick Wardle: [00:30:55:03] So, I added some de-bug messages to this library. So, now if we execute this malware that we are in the process of repurposing, we can watch this run-time decryption and command and control server address swap out. So, specifically at the bottom of the terminal output we can see that our code has detected that the decryption routine has returned the addresses of the malware's actual command and control servers. Again, we just ignore that and instead returning the address of our own. This of course will ensure now that the malware will connect to our servers for remote tasking.
Patrick Wardle: [00:31:31:10] Now, we have to obviously write those command and control servers, right? We have an exploit that we've repurposed. We're deploying this backdoor. We've changed the addresses of the servers but when it connects to us though we've got to be able to talk its protocol so we can give it the right commands in tasking. The main feature of Windtail is file ex-filtration, so that's the first capability we add to our command and control server. It turns out the malware will do this automatically. It has a bunch of file extensions that it looks for: text files, Power-point files, data bases. It scans the entire file system and any files that match those extensions, it will zip up and automatically ex-filtrate those via post requests to whatever command and control server it's configured to talk to. Again, since we've just reconfigured that, that's going to be our server.
Patrick Wardle: [00:32:15:21] So,what we do is we just write some basic Python code that will parse these post requests and save off each file the malware sends us from the infected host.
Patrick Wardle: [00:32:25:07] So, here's a demo of our custom command and control server that's now receiving files ex-filtrated from the repurposed malware. On the left, we can see the incoming post request containing the ex-filtrated files, and on the right we simply save them off to a directory on our command and control server.
Patrick Wardle: [00:32:42:23] Now, let's also extend this malware or rather repurpose it to support the download and execute. So, again we want to add this capability to the custom command and control server that we are in the process of creating. So, we mentioned the malware makes two requests. It first makes a request from the name of the file, that is what it should name the file it's about to download, and then once it has that name, it makes the second request to the command and control server to actually get the files' contents.
Patrick Wardle: [00:33:09:16] So, what we do is we add about ten lines of code to our custom command and control server to handle this. First request, we give it a name, choose whatever, call it "update.zip", and then when it makes that second request we give it the bits, the bytes, whatever we want it to download and then execute.
Patrick Wardle: [00:33:24:03] So, we watch this in action. Again, the malware's going to beacon out to our custom command and control servers because we're swapping out those addresses, and we're just going to have it download and execute the rather ubiquitous calculator app. It's pretty easy to do. We're going to see the calculator pop up, but again this is a really kind of powerful capability because now this means that we can arbitrarily execute other tools or perhaps even another piece of malware. So, we might want to, for example, deploy this malware to a variety of systems and then the certain systems that we ascertain to be very valuable or perhaps safe targets, we might then want to install our own custom implant, and we would then be able to do that via this download and execute functionality built in to intel.
Patrick Wardle: [00:34:09:02] Finally, we also want our custom command and control server to support self-delete command because at some point it might be a really good idea to be able to remotely disinfect the targets you've infected. If you're an individual, maybe the FBI shows up and you want to hit the button, make them all go away, if you were an agency using redeployed malware, you know perhaps that eventually gets detected, really nice to have a Q&D capability. It turns out it's pretty easy to support this capability. Recall the malware, it just connects out to the command and control server, and if a certain API endpoint returns a one, it will delete and then terminate itself.
Patrick Wardle: [00:34:43:22] So, this demo shows us responding to this command. If we look at the slide, that obvious orange icon is actually where the malware persists itself. Now, it's in the user's library directory. The average user is not going to be poking around, so it's rather stealthy-ish. We're going to see that the malware is going to connect out to our command and control server on the bottom. We are going to respond with one which tells the malware to delete itself. So, it disappears from the system and then obviously the malware will stop beaconing because it's just terminated and executed.
Patrick Wardle: [00:35:15:07] So, we've shown exactly how to repurpose a myriad of Mac malware from backdoors, ransomware, even persistent crypto currency miners. However, we need to talk about remaining undetected. As I noted earlier, generally speaking, we are repurposing known malware samples which means macOS, Apple and third party AV products will likely block or detect even our repurposed variants which would be annoying.
Patrick Wardle: [00:35:45:01] So first up, we're going to talk about macOS' built-in mitigations such as XProtect, the malicious malware removal tool (MRT) and code signing certificate requests. At first glance, these might appear problematic for us because they have the ability to generically block all our repurposed malware on any or all Mac systems, right? These are embedded into macOS, so we deploy our repurposed malware and they block it, that's annoying. So, again let's talk about how to bypass that because as I just mentioned it would be kind of sad if Apple blocks our repurposed creations.
Patrick Wardle: [00:36:27:10] So, first up we have XProtect. This is a simple signature-based AB scanner that is actually built into all recent versions of macOS. Yes, macOS has anti virus built in thanks to Apple. Apple doesn't like to talk about it because it means there's Mac malware but it's there. It's rather limited. It only actually scans files that are downloaded by the user the first time they are executed. The detection signatures for this product are located in a system file named, XProtect.yara, and if we take a peak at those we can see one such signature, for example, the one for KeRanger which was the ransomware we talked about earlier.
Patrick Wardle: [00:37:05:14] Since XProtect though is a purely signature-based detection mechanism, it's really rather unsurprisingly very trivial to bypass. So, we take a closer look at that XProtect signature for KeRanger we can actually map that to a group of instructions in the malware. Knowing this, to bypass the signature we can simply modify any of these instructions, right? This will change various bytes which of course will cause the signature to no longer match. So, here, for example, we simply modify the number of bytes that maybe written to a buffer from OX400 to OX300. Now, this clearly doesn't impact the functionality of the malware, but this one byte change will work the XProtect signature meaning our repurposed KeRanger will now no longer be detected.
Patrick Wardle: [00:37:54:21] Demo time, here we have two instances of KeRanger. On the left is the original sample which we first execute. We can see macOS has identified this as KeRanger and doesn't even give you an option to run it. You just click, "Cancel". If you execute the second version, this is the version we modified with this one byte modification, there's going to be alerts saying it's downloaded from the Internet. User clicks, "Allow". It will be able to execute, and in the background we pop open a terminal window, we can see that the ransomware has been executed. It's going to wait, or if we knock that out, it's going to immediately start encrypting files. The end result though, we've very trivially worded the XProtect signature. So, we don't have to worry about that anymore.
Patrick Wardle: [00:38:34:19] Now, let's talk about code signing checks. Most binaries on macOS are code signed. Signed binaries are not blocked by gate-keeper, so a lot of Mac malware is also code signed. A down side at least from the malware or our point of view is once the malware has been detected, if it's signed with a code signing certificate, Apple can simply revoke that certificate which means that malware will no longer run on any new systems. So, here, for example, we can see that Apple rather quickly actually revoked the code signing certificate for Windtail which means that actually Windtail will not run on any other Mac system.
Patrick Wardle: [00:39:11:08] Of course, we don't want our repurposed version or variant of Windtail to be blocked, that would be annoying. If you think about it though, the problem is not the malware per se, it's just the code signing certificate that was used to sign the malware. So, let's just remove it, and then we can either distribute the malware unsigned or perhaps resign it with a "legit" developer code signing certificate. It's pretty easy to get those let's just say. So, to unsign that we can actually use Apple's code sign utility. It turns out there's an undocumented flag '--remove-signature', and if you execute that when in an application it will very nicely strip the code signing certificate and code signing information from that application bundle or binary. Then, we can just resign it, again assuming you have another code signing certificate which you likely will do. Just pass the S flag and this will allow or tell a code sign to simply resign the binary with this note new allowed code signing certificate. Then, this means the resigned Windtail that we've just repurposed will no
longer be blocked by macOS. So, this neatly signs the certificate revocation checks.
Patrick Wardle: [00:40:19:11] Finally, we have MRT, the malware removal tool. This is another Apple created AV-like tool that actually ships with all versions of macOS. So, there's actually two AV products built in to macOS. It's rather similar to XProtect although it scans malware that may already be on the system and then it removes any malware it finds. Unlike XProtect though, the signatures are actually directly embedded into the binary versus in a stand-alone file, and as an interesting aside, Apple also sometimes uses MRT to remove legitimate third party products it deems vulnerable, for example, Zoom, which is a popular third party video chat application that had a remotely exploitable vulnerability.
Patrick Wardle: [00:41:02:09] So, MRT, like XProtect does use signatures which means again it's very easy to bypass. The signatures though as I mentioned are not stand-alone. They're actually directly embedded in the MRT binary. If we run strings or open MRT in a disassembler, it's pretty easy to locate these signatures, for example, we can see that there's a signature for Fruitfly which leads us to wonder, will it detect our repurposed version of this backdoor. Well, if we examine the signature, we can see the way it detects Fruitfly is based on both the path of the malware and the launch agent p-list. Rather humorously, this means if we simply change the name of the malware or the name of the p-list, MRT won't detect this. Like I said, trivial.
Patrick Wardle: [00:41:51:05] I briefly also want to mention bypassing third-party AD products because you might run in to a system that has one of these. Again, since we are repurposing known malware these products may have detection signatures for those binaries. Now, this has been talked about a lot, so I'm not really going to spend too much time but suffice to say especially on macOS those AD products are similarly signature-based which means again very trivial to bypass.
Patrick Wardle: [00:42:19:11] So, for example, I took Fruitfly which recalls written in Perl, ran it through a free on-line Perl obfuscater. This caused all the detections on various tools to go to zero, again, even though this is a known piece of malware. Obviously, there's more sophisticated examples or techniques that will reduce or even fully prevent detection. Things like, using a packer or encrypter, or even executing it directly out of memory. I gave a talk at Black Hat a few years ago about focusing on these techniques specifically in terms of macOS. So, if you're interested in AD detection bypasses, check out that talk.
Patrick Wardle: [00:42:56:17] So, for Mac users this all sucks, right? We've shown that advance adversaries are already utilizing repurposed malware and that it's actually pretty easy, pretty straightforward for anyone else to equally abuse these existing threats. Unfortunately, also the majority of existing tools and capabilities, protection mechanisms especially those that are built directly into macOS may fail to detect these repurposed threats. In my opinion, that's incredibly lame because if we think about it, these repurposed malware samples are basically exact copies of known malware albeit very slightly reconfigured.
Patrick Wardle: [00:43:36:10] So, to end this talk we're going to switch gears. We're going to put on our white hacker hats, kind of look from a defensive point of view and talk about some ideas of how to generically detect even these repurposed threats.
Patrick Wardle: [00:43:50:11] So, first, this is a rather well known fact, detecting malware based on signatures is always going to fail. It's not a very robust approach. So, instead what we should do is we should look for unusual or malicious behaviors. By definition, if we think about it, malware does abnormal things. So, let's leverage this fact with the goal of generically detecting even repurposed threats because again when we or an attacker repurposes a piece of malware we're not really changing its actual capabilities or behaviors. That is to say, the repurposed ransomware is still going to ransom encrypted files, right? The repurposed backdoor is still going to persist and start ex-filtrating files to a command and control server. So, again, we're not changing the capabilities of the malware. So, if we're focusing again on detecting those behaviors versus signatures we'll have a lot more of a powerful detection capability.
Patrick Wardle: [00:44:47:12] So, let's start with talking about detecting persistence as the majority of Mac malware is going to persist and what I mean by persistence in the context of this presentation is a way for the malware to install itself, so it will be automatically re-executed every time the system reboots or the user re-logs in. So, what we can do if we're writing a defensive tool is simply monitor the file system for persistence locations because those are rather small. It's a very finite group. So, here, for example, we can now generically detect when Windtail, either the original or repurposed sample persists.
Patrick Wardle: [00:45:23:08] Next up, we can also detect malicious behaviors or suspicious behaviors such as accessing perhaps the mike or the web cam. A lot of Mac malware accesses the web cam or the mike to spy on users of infected systems, for example, Fruitfly. So, what we can do is we can simply register a call back with the operating system that will kindly be invoked any time anyone accesses this device including malware such as Fruitfly or perhaps even someone trying to exploit Zoom. So, again, macOS has the ability to alert you whenever an application or a binary accesses the mike or the web cam. So, programmatically, we simply subscribe to that notification, and when it triggers or when it fires we can examine what process is trying to access that and then rather easily detect if it's something trusted, for example, Face-time, or something suspicious.
Patrick Wardle: [00:46:15:04] We can also detect key loggers rather generically. Malware often tries to capture key presses to do things like steal your password, credit cards, see who you're chatting with, etcetera, etcetera. So, on macOS the most common way that malware implements key logger capabilities is via something called an "event tap". So, what we can do is we can generically detect these taps by again registering a dispatch notification that will be kindly invoked by the operating system any time a new event tap is installed. This allows us to generically detect key loggers even if they've been repurposed. So, what we do again is we basically tell macOS, "Hey, please let us know any time someone installs a new event tap." MacOS says, "Sure", and then if a piece of malware comes along, even if it's been repurposed and tries to implement some key logging functionality, macOS will detect that a new event tap has been installed; see that we have kindly asked to be alerted, and then will give us or deliver us a notification which again we can examine to see who is installing that event tap, if it's malware or again something perhaps legitimate.
Patrick Wardle: [00:47:24:02] Malware such as Fruitfly which we talked about repurposing also has the ability to remotely interact with the UI via programmatic or "synthetic" clicks, and this is a very powerful capability from the malware's point of view because it allows it to do things like dismiss security and privacy prompts. Luckily, again for us, perhaps you're writing a defensive tool, it's fairly easy to detect synthetic events by actually installing our own event tap and monitoring for mouse clicks. So, when a mouse click is generated, if we've installed an event tap that indicates the operating system that we're interested in modifying or rather examining these mouse movements, the mouse event will be delivered through our event tap allowing us to examine it. One of the nice things about this is there's a flag that is set to zero if the event has been synthetically or programmatically generated.
Patrick Wardle: [00:48:19:17] So, again, this gives us a very powerful fairly trivial way to generically detect synthetic clicks allowing us even to detect repurposed malware that utilizes this functionality.
Patrick Wardle: [00:48:31:06] So, now let's end by briefly looking at how one may actualize these in a comprehensive Mac security product based on these detection mechanisms we've just talked about. And the goal of course is for the generic detection of Mac malware either known specimens that are already out there or repurposed specimens like we talked about today or even complete novel threats that act somewhat similarly behavior-wise. So, one way at Digita, an idea was simply to monitor the system for things like persistence events, mike, web cam activities, right? All the things we just talked about, and then create rules to detect unusual behavior, and then feed both this data that we collected and these rules into Apple's game logic engine. And the idea is Apple's built-in game logic engine is actually very powerful, very efficient at taking in large amounts of data, applying rules on top of that and outputting a result.
Patrick Wardle: [00:49:29:11] So, using this system we can now rather trivially detect all the repurposed malware we created today. So, for example, let's go back to Windtail, we can detect its exploitation vector by observing first and foremost that Safari has downloaded and auto extracted a file. It's not that suspicious but it's--, take a check, right? Maybe an interesting event. We then see that same application triggers the registration of a custom URL handler and then that same application is then automatically started to handle that custom URL event. So, now we have these three related actions that accumulatively gives us a very powerful detection capability that allows for the detection of Windtail's exploitation vector even when it's been repurposed or perhaps utilized by completely separate APT or a hacker group.
Patrick Wardle: [00:50:22:10] Similarly, we can also detect something like Fruitfly at 'install time' by observing events that again accumulatively can indicate something is suspicious. So, here, for example, we observe that a hidden non Apple binary is persistent as a launch item. That's obviously very shady.
Patrick Wardle: [00:50:41:17] Finally, imagine a Fruitfly has already been installed. We can detect it even if it's been repurposed by run-time monitoring looking for activities or behaviors that are rather suspicious or likely malicious. So, for example, Fruitfly does things like running a hidden process, dropping an embedded binary that's unsigned to the tmp directory, and then launching that binary which in turn generates synthetic clicks, right? That's all really, really suspicious. Now, accumulatively, when we see all these events we're very confident that that's at least the piece of malware or binary that should be very closely looked at. However, we don't have to only wait till all those events accumulatively trigger. Instead, we can say, okay, if one or two of them actually occur maybe that warrants a closer look at the binary or a system as a whole.
Patrick Wardle: [00:51:33:08] Again, it's important to note that since we're monitoring for a large number of events and have the ability to write very powerful detection rules, we can now generically detect Mac malware including the repurposed samples we talked about today.
Patrick Wardle: [00:51:47:15] Before I end this talk, just one more thing since you're obviously here all really stoked about--, well perhaps drinking beer--, but also Mac's security topics. I just briefly want to mention the Objective by the sea, the Mac Security Conference. It's going to be held in 2020 in Hawaii, and honestly I really can't think of a better way to spend your company's travel and training budget than going to Hawaii and you know, you could bring the family as well. So, I hope to see you there.
Patrick Wardle: [00:52:14:05] So, that's a wrap. Today, we illustrated exactly how to repurpose malware for our purposes and showed why this is actually a very powerful capability. We also illustrated how the power of heuristic-based detection approach can generically detect these threats. So, if you're writing your own security products, I highly recommend kind of following a similar approach, and don't focus on signatures per se but rather look for the malicious behaviors. That will then allow you to detect existing threats, repurposed threats and even novel or threats that we have not yet seen.
Patrick Wardle: [00:52:48:18] Before I end, I just want to thank you all for attending my talk. Also a big hello to Casey and Tmac. It's pretty awesome that we can have a brewery conference, so I hope I'm invited back next year. So, again, thank you. Let's give a round for Casey and Tom, and all the jamf crew. [APPLAUSE]
Patrick Wardle: [00:53:11:00] So, I think we have a few extra minutes for questions. I'll also be hanging out here drinking beer, so if you want to come and chat, talk to me about this stuff, it's obviously something I'm very passionate about...Remix, awesome. So, questions...no? Awesome, well let's all start drinking. It's Friday, right?
Conference host: [00:53:38:17] Yeah. Thank you, Patrick. [APPLAUSE]