>>Aloha and welcome to my talk on offensive malware analysis. My name is Patrick, I am the chief security researcher at Synack. Briefly, Synack does crowdsourced vulnerability discovery with vetted security researchers. So, if you’re interested in getting paid to find bugs in our customers apps and websites uh, check out Synack dot com, or come chat with me. So, today we're going to start by looking at an interesting piece of malware called fruitfly, and we’re then going to talk about some monitoring tools and capabilities I wrote for Mac OS, then how I built a custom command and control server, following this how then I used that server to task the malware, in order for it to reveal its capabilities to me. And then Finally, what happened when I put this command and control server on the internet. So, our goal here is to analyze fruitfly, comprehensively, but do so in a rather efficient way. So, traditionally, when you analyze malware you use disassemblers and debuggers. And with stress these methods definitely work, but they’re kind of slow. Now, I didn’t have access to a command and control server but, I figured if I’d write my own, then be able to task the malware and observe how it responded, I would be able to basically coerce the malware into revealing its capabilities to me, just by asking it the right questions. I thought this would be a lot faster of a technique than spending many hours reverse engineering. So, I mentioned the target is going to be a mac malware specimen named fruitfly. But, before we can build this custom command and control server to task it, we need two things. We first need to figure out the address that the malware is trying to connect to, where it’s looking to connect to for a command and control server. And then, what protocol does it speak? Because this will allow us to create a compatible command and control server, which will then allow us to task the malware. So, fruitfly was discovered in January, uh initially it was undetected by antivirus engines on virus portal. Uh, my good friend Thomas Reed who is here in attendance, an incredible Mac security researcher, did the initial analysis, wrote a great blog, articulating the components of the malware, it’s perses, it’s persistence techniques, and also, some of it’s capabilities. It’s fairly standard, but fully featured Mac backdoor, but it has some interesting interactive capabilities, also the ability to turn on the webcam. Now, we don’t know the infection vector, we never found an installer which is interesting, but perhaps it was via an email attachment or pirated or trojaned application. Today we’re going to be looking at variant b, a friend send me, sent me a hash of this sometime in late January, at the time, variant a was already being detected, but variant b was still undetected. It was submitted to virustotal with the name of fpsaud, which is designed to mimic a common flash player, and like variant a, it’s main component was an obfuscated perl script. That’s kind of odd. As I mentioned, we want to build a custom command and control server. We need the address that the malware tries to connect to and we also need to understand its protocol. So, let’s briefly triage this malicious script, to get this information. So, the first thing we do is we beautify the script, which allows us to read it easier, because it’s now formatted better. We can see it starts with some imports, followed by some subroutines and finally is the main logic of the malware. Briefly, if we look at these subroutines we can see there names and descriptions in the table on the slide. Now, these aren’t the core of the malware per say, they’re rather helper functions. But, what we can do is provide insight especially into the protocol of malware which is essential for us to understand. So, for example, the g subroutine sends data back to the command and control server. So, we see a command invoking the g method, we can determine how many bytes it’s going to send, so then our custom command and control server can handle that response. Similarly, the j subroutine receives some number of bytes from the command and control server. So if we see a command say invoking j, 9, we know it expects 9 additional bytes that we must send form our command and control server. Now after the subroutines the malware decodes some strings which turn out to be the uh addresses of both the primary and the backup command and control server. The easiest way to analyze these and decode these is to step over them in a debugger. Don’t want to spend a ton of time debugging, but again, once I stepped over this and printed out the strings I could see they were URLs and IP addresses, albeit reversed, of both the primary and backup command and control servers. Now, before the malware connects to the command and control server in that main processing block, it does a few other things. It processes some command line arguments which we can see is looking for an IP address or an IP address and port of the command and control server. This is awesome, because it means we can specify our own, for example when we execute the malware in a vm and have it connect to our custom com, command and control server. So this greatly facilitates analysis. It also hides its process by just changing arcs of zero, this will fool tools like ps, and then finally decodes some binary data which turns out to be an embedded mach o binary. Finally we get to the main processing loop and this does two things, it checks in with the custom command and control server, or the command and control server sending some information like the host and user name and then it invokes the j subroutine to receive one byte from the command and control server which it then processes in a massive else if else loop. What this is doing is basically just receiving a numeric command from the command and control server, processing that and then returning the response to the server. Ok, so now we know the address of the command and control servers and actually we determined that the malware will connect out to whatever you specify on the command line. And also we understand the basic protocol. Now, before we start building our custom command and control server though, let’s talk about how we can passively monitor malware. This is important because if we task the malware but we can’t observe what it does if it just sends us back a zero or one, we really have gained to insight in which, into which that command actually did. So, what do we want to monitor? Well, pretty much everything. Uh, a given command might you know create files, write files, it might spawn off processes, execute shell commands, might interact with the mouse and keyboard, or send interesting data back, via the network. We should monitor for all of the events so that when we task for malware, we can determine what its doing via this simple tasking. So let’s take a closer look at each of these now. Uh, we’ll start with network monitoring, back os this is pretty easy to do you can use tcpdump or wireshark uh, we’ll talk about tasking a little bit in um shortly, but at the bottom of the slide you can see the wireshark capture when the, the malware is responding to command number 13. Now originally, I had no idea what command number 13 was, but we’ll see when we task the malware if we look at the network capture, we can see this command returns the location where the malware is installed. So, this is basically how we revealed the capability via this network monitor. Next up, we have file monitoring, we can use the built in fs usage utility, uh this is a mac os utility that allows you to monitor file io events. We’ll see that various commands when you task the malware will cause it to drop or save the embedded mach o binary, you can see from the file monitor its saved to slash tmp slash client. Now we can grab that binary and do some analysis. But, we’ll see we don’t have to actually fully reverse engineer this because we’ll reveal it’s capabilities just via tasking. Next up is process monitoring, again this is important because I assume the malware probably spawned off of other processes or executed other shell commands. Uh, since detritus is neutered on recent versions of mac, there’s no easy good way to do process monitoring user mode, so I wrote an open source free process monitoring library that allows us to see what the malware is doing. For example, here when can see that when we task malware with command number 11 it executes the pwd command to get the current working directory. I also wanted to sniff the mouse and keyboard to look for simulated mouse and keyboard events. I found some old proof of concept code that would intercept and modify mouse and keyboard events, so I updated this, this will be online available for free as well, open source and it allows us now to capture mouse and keyboard events. So, on the slide you can see when I type and move the mouse our sniffer will now detect and log those events. Okay, onto building our custom command and control server. Recall, we can specify the address of the custom command and control server via the command line, and we also understand the protocol of the malware. We know it connects out, sends some client information of the infected host, and then expects a single byte which is the command it will then act upon. So we start by just creating some basic python code, uh we then listen on a port, we then execute the malware in a vm, give it the address of this python custom command and control server, and, we see that the malware connects. Now, nothing too exciting here but, baby steps. So, yeah when does the malware send when it originally checks in? Well, we can triage the malicious perl script, we can see it sending things like version string, the host name and the user name. So now we can extend our custom command and control server to basically parse the format of this data, so when the malware connects, we can dump this client information. Now the meat of the custom command and control server is obviously tasking and handling commands. Turns out there is about 25 commands and a variety of these had subcommands, bringing the total to about 50. So, I built the custom command and control server to support all of these. Now again, it’s important to understand that originally I did not know what these commands actually did, like command number 2, no idea. So, what I did for each command is I would basically triage the command with the goal of understanding its protocol. Did it receive additional bytes from the command and control server, and then what is the format of the response? So here’s a simple example, command number eleven, we can see it res, expects no additional, uh address or bytes from the command and control server. But then responds with a byte and a variable length string. So we can extend our custom command and control server to parse this response and then we can see this is the malware setting back its custom, current working directory. Alright, now we task. So again, we have our monitoring capabilities, and this custom command and control server. Now unfortunately, I don’t have time to go through all the commands but we’ll look at some of the more interesting ones. Again, when I began tasking the malware, I really had no idea what these commands actually did. So, the first command is command number 2. If we look at a malicious perl script, we can see this command via the j subroutine expects an additional byte from the command and control server, it then invokes the v subroutine, to execute the embedded mach o binary, and then invokes the g subroutine to send the response some information back to the server.  So now we know, understand the protocol, we, we know it's requires an additional byte and then it’s going to send us back some variable length data. But again, we have no idea what this command actually does. So we send the, the malware command number 2 and for the second byte we just send it as zero, and via the file mon we can see it dropping that embedded mach o binary and then via the process monitor, we can see it executing that embedded binary as well. Now, via the network capture, we can then send it, we can then see it sending back about a meg of data. So, we extend our custom command and control server to receive this data and drop it or save it to the file system. We can then dump it in a hex editor or run the file command and it turns out then its an image a png file, and when we open it, we can see it's a screen capture of the infected host. So now we know that command number 2 is a screenshot utility, screen capture, and again just via tasking. Now remember though, this command takes a second byte and at the time again I had no idea what this was I had sent it as zero and it sent me this nice color png. But we have the ability to task the malware, so, instead of having to spend time to reverse engineer, let’s just keep tasking command number 2, and change the values of that second parameter. We can see the table contains the results, basically that second byte influences the type and quality of the capture. So, for example, if we send a 1 for that second byte, it gives us back a low res black and white png, while a 10 gives us a low res color jpg image. Alright, onto command number 8, again we triage the command we see it expects an additional 9 bytes, and again drops and execs that embedded mach o binary. In terms of its response though it just sends us back a zero or a one, so unlike the screen capture command we have no insight into what this command does by looking at its response. But, if we task this, send the command number eight and then for the additional 9 bytes just send 0,1,2,3,4,5,6, we can see the mouse sniffer registers event it moves to the x,y coordinate. So, watch closely, we’re going to task the malware with this command and what it’s going to do, it’s going to move the mouse, amazing right? [chuckles] Gets a little more exciting, okay, what about that second byte? Again, we didn’t know what it was but we now know the 8 bytes after that are x,y coordinates. So again, we can just task the malware, varying this second byte, we can see as it shows on the table in the slide, this is a subcommand, it basically tells the malware what type of mouse command to do, left click, double click, right click, drag. This is a really neat capability because it allows the attacker to actually interact with UI elements of the host. For example, security pop-ups, again watch closely, we’re going to task the malware and via the malware dismiss a security prompt. Kind of a neat feature. The final commands we’re going to talk about are 16 and 17. Again, we triage the command, we see that in, it invokes j to get one extra byte from our command and control server. So we know okay, our custom command and control server should send one additional byte. It then executes again the v subroutine which drops and executes the embedded mach o binary, the file mon and process monitor show this happened, uh but most interestingly then, the keyboard sniffer lights up. So for example if we send command number 16, with a value of 65 for the second byte, the keyboard sniffer shows a keydown event for the letter a. If we then execute command number 17, passing in a 65 as well for the second byte we can see it generates a key alphabet. So this allows the hacker to remotely type on the infected host. So again on the slide we’re going to send it a command to type in H and then an I. Okay, so what I did was I repeated this process for all the commands. So this allowed me to understand comprehensively the capabilities of the malware. Right? They say communication is key, apparently, people say this applies to humans, but in this case it also applies to malware as well. So we talked about some of the more interesting commands, but of course the malware supports other interesting commands as well, it allows you to execute system commands, shell commands, process listing, upload files, etcetera. The most interesting one though is the malware actually has the capability to alert the attacker when the user is using the computer. This is a very interesting capability, obviously this malware was designed for interactive operations,  and when you’re doing interactive operations, for example moving the mouse, maybe typing, perhaps turning on the webcam, you obviously don’t want the user to be there because they will observe these very observable actions and this will be a dead give away for what that the system is infected. Alright, so we now have a fully compatible custom command and control server, let’s go hunt some flies. So if you ping the primary command and control servers, they are all offline. But, recall we encrypted some backup command and control servers, and guess what, they were available for registration. So, I hopped on line, registered the URLs of these backup command and control servers, pointed them to my custom command and control server, and immediately hunder, hundreds of infected victims started to connect. And again, recall for each victim the malware when it checks in sends the username and the computer name which when coupled with an IP address gives us a very good, pretty accurate way to identify victims. For example, if I was infected, you would see an IP address in Hawaii, you would see username Patrick and host name be Patrick Wardle’s Macbook cause by default mac uses first and last names for the hostnames. So, I looked into who these victims were, geolocation and there names, and it turned out a vast majority of them were in the U.S. and also, they appear to be just normal everyday people. So, this was interesting, again we have a piece of malware that looks like it has surveillance type of capabilities, uh for example webcam capture etcetera, but its targeting everyday people. Now, everyday people are normally targeted by financially motivated cyber crime malware. And malware that has this more spying capability is usually associated with nation states which are not going to be targeting those kinds of people, it’s going to be targeting like defense contractors and military organizations.So unfortunately, what this means is that this malware was designed to basically spy on everyday people and, and families and that’s kind of what I saw by looking at the data. Uh, so I contacted law enforcement and it's progressing. Alright, so let’s wrap this up.So, today again we illustrated how to fully analyze a fairly complex piece of malware, just by asking the right questions. Again, in three steps, we built a custom command and control server, then tasked the malware, and we reserved the malware’s response to fully reveal its capabilities. Along the way we wrote some cool, uh monitoring tools for mac OS that again will be open source and posted online, and the end result is we had a full analysis of fruitfly variant B. Also then, since we were able to register these custom command and control servers, we were able to uncover a large number of victims and get insight into who these individuals were. Again, worked closely with law enforcement because unfortunately it looks like this malware was designed with a very kind of creepy perverse uh angle which you know is rather s***y. Um we could’ve also though hijacked all of those victims. I always joke, and I probably shouldn’t say this, but you know if all those connections were you know computers in Russia or China, I might have contacted somebody else. Again, this is the power you have with a custom command and control server in that if you can then take over the address of the domain it’s talking to, you can task these computers. I was tempted to, but I did not. Now, people always ask me you know how can you protect against something like this threat. Uh, forensic analysis and also some information we have that I can’t talk about publicly just yet, indicates that this malware has been around for 5, if not 10 years. Really just flying under the radar again targeting families to basically spy on them perhaps via the webcam. So, my response is always you know use best security practices, uh, install the latest patches, run the latest version of Mac OS, also look into perhaps third party security tools. So in my free time I write some free a lot of open source mac security tools, uh one for example is called blockblock, monitors persistence locations will likely detect the malware when it persists. Another one is called oversight that monitors for the webcam and mic, so if this malware had got on the computer, if the hacker and then turned on the malware to turn on the webcam to spy on the user perhaps when they were walking around in their bedroom in their underwear or less, when the user came back to the computer even if the hacker turned off the webcam, a website would have alerted the user saying hey just to let you know some process was using the webcam basically spying on you. And then I’m just releasing a free open source mac os firewall think little snitch but free and open source, uh this should be out in a few weeks and this would have detected when the malware connected out to the internet. So again, I think creating these free third party security utilities that trigger or alert on these more generic actions is a great way to target these threats. Alright, so that’s a wrap uh thanks again for attending my talk, and if you're interested in being you know basically a paid security researcher to find vulnerabilities in you know Synacks customers checkout Synack dot com. I think we have a minute or two for questions, if not I’ll be around here and again thank you so much for attending my talk, I really appreciate it [applause].