 Aloha and welcome to my talk on offensive malware analysis. My name is Patrick. I am the chief security researcher at SINAC. SINAC does crowd source vulnerability discovery with vetted security researchers. If you're interested in getting paid to find bugs in our customers' apps and websites, check out SINAC.com or come chat with me. So today we're going to start by looking at an interesting piece of malware called fruit fly. We're then going to talk about some monitoring tools and capabilities I wrote from 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 fruit fly comprehensively but do so in a rather efficient way. So traditionally when you analyze the malware, you use disassemblers and debuggers. I want to 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. And 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 fruit fly. 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 out 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 fruit fly was discovered in January. Initially it was undetected by antivirus engines on virus total. 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, its persistence techniques, and also some of its 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 a pirated or trojan application. Today we're going to be looking at variant B. A friend 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 virus total with the name of FPS odd, which is designed to mimic a common flash player. And like variant A, its main component was an obfuscated Perl script. It's kind of odd. As I mentioned, we want to build a custom command control server, but 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 their names and descriptions in the table on the slide. Now, these aren't the core of the malware per se. They're rather helper functions. But what they can do is provide insight, especially into the protocol of the malware, which is essential for us to understand. So for example, the G subroutine sends data back to the command and control server. So if 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 comma nine, we know it expects nine additional bytes that we must send from our command and control server. Now after the subroutines, the malware decodes some strings, which turn out to be the addresses of both the primary and the backup command and control servers. The easiest way to analyze these and decode these was just to step over them in a debugger. I didn'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 it's 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 command and control server. So this greatly facilitates analysis. It also hides its process by just changing args of zero. This will fool tools like PS. And then finally decodes some binary data which turns out to be an embedded mock-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 username. 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. Okay. So now we know the address of the command and control servers and actually determine 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 the 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 no insight into what that command actually did. So what do we want to monitor? Well, pretty much everything. A given command might create files, write files. It might spawn off processes, execute shell commands, might interact with a mouse and keyboard, or send interesting data back via the network. So we should monitor for all the events so that when we task the malware, we can determine what it's doing via this simple tasking. So let's take a closer look at each of these now. We'll start with network monitoring. MacOS, this is pretty easy to do. You can use TCP dump or Wireshark. We'll talk about tasking a little bit shortly, but at the bottom of the slide, you can see the Wireshark capture when 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. This is basically how we reveal the capability via this network monitor. Next up, we have file monitoring. We can use the built-in FS usage utility. This is a MacOS 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 MacO binary. And we can see from the file monitor, it's saved to slash temp slash client. So now we can grab that binary and do some analysis. But we'll see we actually don't have to fully reverse engineer this because we'll reveal its capabilities just via tasking. Next up is process monitoring. Again, this is important because I assume the malware will probably spawn off other processes or executed other shell commands. Since detrace 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. So for example, here we can see that when we task the 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. We 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. Nothing too exciting here, but baby steps. So again, what does the malware send when it originally checks in? Well, we can triage the malicious Perl script, and we can see it sending things like a version string, the host name, and the username. 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's 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 two, no idea. So what I did for each command is I would basically triage the command with the goal of understanding its protocol to 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 11. We can see it expects no additional address or bytes from the command and control server, but then it 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 sending back its custom current working directory. 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. And again, when I began tasking the malware, I really had no idea what these commands actually did. So the first command is command number two. If we look at the 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 mock obinary, and then invokes the G subroutine to send the response some information back to the server. So now we know to understand the protocol. We know it 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 malware command number two, and for the second byte, we just send it a zero. And via the file mod, we can see it dropping that embedded mock obinary, and then via the process monitoring, 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 on the file command, and it turns out then it's 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 two is the screenshot utility, screen capture. And again, we determine this 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 a zero and it sent me back this nice color PNG. But we have the ability to task the malware. So instead of having to spend time to reverse engineer it, let's just keep tasking command number two 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 it a one for that second byte, it gives us back a low res black and white PNG, while a 10 gives us a low res color JPEG image. All right, onto command number eight. Again, we triage the command. We see it expects an additional nine bytes. And again, drops and execs that embedded mock obinery. 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 nine bytes, just send zero, one, two, three, four, five, six, we can see the mouse sniffer registers event. It moves to the XY 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? Gets a little more excited. Okay, so what about that second byte? Again, we didn't know what it was, but we now know the eight bytes after that are XY coordinates. So again, we can just task the malware, varying this second byte. And we can see as it shows on the table in the slide, this is a sub command. It basically tells the malware what type of mouse command to do. Left click, right 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. So 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 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 sub routine which drops and executes the embedded mock O binary. The file mod and process monitor show this happen, 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 key down 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 up event. So this allows the attacker to remotely type on the infected host. So again, on the slide, we're going to send it a command to type an 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. 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, etc. 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 giveaway for what that the system is infected. All right, 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 decrypted some backup command and control servers, and guess what? They were available for registration. So I hopped online, registered the URLs of these backup command and control servers, pointed them to my custom command and control server, and immediately 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 coupled with an IP address gives us a very good pretty accurate way to identify victims. For example, if I was infected, you'd see an IP address in Hawaii. You would see username Patrick and the host name be Patrick Wardle's Mac book because by default Mac uses the first and last names for the host names. So I looked into who these victims were, geolocation and their names, and it turned out the vast majority of them were in the U.S. And also they appeared to be just normal everyday people. So this was interesting because again we have a piece of malware that looks like it has surveillance type of capabilities, for example webcam capture, etc. But it's 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 kind of people. It's going to be targeting like defense contractors and military organizations. So unfortunately what this means is this malware was designed to basically spy on everyday people and families. And that's kind of what I saw by looking at the victims. So I contacted law enforcement and that's progressing. Alright, so let's wrap this all 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. We then tasked the malware and then we observed the malware's response to fully reveal its capabilities. Along the way we wrote some cool monitoring tools for macOS that again will be open source and posted online. And the end result is we had a full analysis of fruit fly 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 we're closely with law enforcement because unfortunately it looks like this malware was designed with a very kind of creepy perverse end goal which you know it's rather shitty. We could also though hijacked all those victims. I always joke and I probably shouldn't say this but you know all those connections were you know computers in Russia or China I might have contracted 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. 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 five if not ten 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 you know install the latest patches run the latest version of Mac OS but 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. One for example is called block block monitors persistence locations would have 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 had then turned on the malware to turn on the webcam to spy on the user perhaps when they were walking around their bedroom in their underwear or less when the user came back to the computer even if the hacker turned off the webcam oversight would have alerted the user saying hey just 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 this should be out in a few weeks. And again 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. All right so that's a wrap thanks again for attending my talk again if you're interested in being you know basically a paid security researcher to find vulnerabilities in you know Cinex customers check out Cinex.com. So 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