 Hi, everybody. Welcome to do it yourself, cellular intrusion detection. My name is Sherry Davidoff. This is David Harrison, Randy Price, and Scott Fretheim. We're from LMG security. So if your cell phone were hacked, how would you know about it? Probably half of you today in this room have cell phones that are hacked, but you can't tell. You can pick it up, you can look at it. The video that you see on the screen here, and I don't know why it's not displaying rate resolution. Sorry about that. The video you display on the screen here is showing us a video of a cell phone that's infected with the Android Stealth malware. So what you see is sending data out to the Netherlands every five minutes or every 15 minutes, depending on whether or not it actually gets a response from the command and control server. And if you were a user looking at this phone, you would never know about it. There has been an explosion of mobile malware in recent years. I don't know if you've seen the Juniper paper on mobile threats. It was really good. Very interesting. And Juniper estimates that the number of mobile malware samples has increased 614 percent between March 2012 and March 2013. And it makes sense because when you think about it, these are just teeny tiny little computers that you're walking around with. They can record you. They can track you wherever you go. They can do anything that you can do with your cell phone if they get infected. This is a screenshot of Tigerbot. Tigerbot came out a couple years ago and it can record the surrounding audio in the room. It can also track your GPS location and send it back to an attacker. I think it's really cool and sort of scary where this is going because you can have botnets of infected computers, of course, on normal LANs. And soon we're also going to see botnets of infected smartphones. When they came out with us, the storm malware, attackers can actually segment that malware into different nodes. So you have nodes communicating with different encryption keys. So if you have 10 infected systems inside one LAN and 20 infected systems inside another LAN, they're communicating peer to peer with different encryption keys. And that means that an attacker, if they want to, can sell them off separately. Similarly, with smartphones, attackers will be able to identify mobile devices that are infected. They'll be able to tell what physical area they're in and segment them into different botnets for resale. So you could say, I have 10 devices, 10 infected bots inside this Department of Defense building. I have 20 infected bots inside HackMe Inc. How much do you want for them? Maybe they're worth different amounts to different attackers. Mobile malware can record surrounding audio. It can track you wherever you go. It can intercept text messages. It can send out your contacts list to the attacker, which is something we're going to show you later today. And in doing so, they get more lists of people to attack the same way that spam works with normal email. We're probably going to see a lot more text spam the same way we see email spam. It can, of course, capture your passwords and keystrokes and control your phone or tablet in the same way you can. This is a chart that we made using the Argus tool of the phone home traffic for an infected black hole exploit kit. This was an infected laptop. And each one of those bars represents a time that it communicated outbound to the attacker's system. So this was over a 24-hour period. All the normal windows traffic has been pulled out. And you can see it phoning home to systems. Actually, I think first it phoned home to Ohio. And then it switched IP addresses. You can see that little blip there. And it started talking to another system in Taiwan. The same thing happens with smartphones. The Android styles malware by default phones home, or at least a sample we were analyzing, phoned home every 15 minutes. So you would see a chart that looks very similar to this with your smartphone. And, of course, the user would never be able to tell. Now on LANs, enterprise security professionals have the option of inspecting network traffic. They can make charts like that. So even if there's no host-based antivirus installed on a laptop, we can still tell if a certain laptop is infected based on the patterns of traffic that it's creating on the network. We don't have that same option with cellular devices that are physically within our enterprises. And that means that people could be sitting in meetings, having their audio recorded, or just have devices that have corporate information on them. Or even in your home environment, this is also true. You might be sitting around having your audio recorded and never know it. Or having your activity tracked. And you don't have the ability to inspect your traffic to tell if some third party, whether it's an attacker, whether it's the government, is collecting information from your device and sending it outbound. The problem is that cellular traffic is invisible to the key stakeholders who really care about those devices the most. One of the folks in our last talk asked if Verizon could tell if their phone was infected. And probably they could if they were inspecting that traffic, but they don't have the resources to be able to chase down every single infected phone. Nobody cares about your smartphone as much as you do, unfortunately. So what is the solution? We propose a cellular intrusion detection system. Within the past few years, companies have started selling these little femto cells, basically miniature base stations that are designed to allow you to create stronger cell signals in places where you might not otherwise have them. They're being marketed to home users, so you can get one of these, plug it into the wall in your house, your cell phone connects to it, and then it routes that traffic across the internet back to your cell phone provider's network. In this case, we were playing around with the Verizon Samsung femto cells. They're fairly inexpensive. This entire project to build a cellular intrusion detection system costs $285. We used both the Samsung SCS2U01 and SCS26UC4 devices and it would probably work on other models as well. Our goal is to enable defenders and people like you and me to be able to detect when our cell phone is being hacked and when third parties are monitoring our traffic. So we gained root on the commercial femto cell, the Verizon femto cell, and then we modified the Linux open source software on it so that it started exporting traffic. And David will go into this in more detail in a few minutes. Then we sent it off to a separate system which embarrassingly only cost us $44 on eBay. It was an old Dell OptiFlex. That system happened to be running, was running Snort, and we created custom Snort signatures so that we infected, when we infected a phone with the Android Stell's malware, Snort would actually detect it and alert upon it. So our roadmap for today, number one, we're going to step through the femto cell modification process and show you how we did it so you can do it yourself. We're going to show you examples of cellular traffic. We learned some interesting stuff from poking around. We're going to do a demonstration in which we actually boot up the femto cell and show you how it gets modified in real time. And then we're going to show you a little video of our experiment in which we infected a phone with the Android Stell's malware, captured the traffic, and then used the Snort IDS to alert on malicious traffic. So you'll see those alerts pop up. Then we're going to do a detailed walk through of the Android Stell's malware and show you how it communicates. And finally Scott and Randy Price did the device forensic analysis so she'll show how it corroborated with the network forensics. And Scott Fretheim is going to show you how he took over the Android Stell's malware and controlled it. So we got a lot to cram in here. There's also a detailed white paper that we put up. It's 77 pages, lots of information for you afterwards. LMGsecurity.com slash blog. So who are we? We are LMG Security. We're a security consulting and research firm. We kind of support our research habit by consulting. We do penetration testing, vulnerability assessments, digital forensics and more. We also teach the Black Hat Network Forensics class and that's part of where the idea for this project was born because we thought to ourselves a couple years ago, hey, mobile network forensics, that's the wave of the future. Let's just grab some packet captures on cellular networks and start studying them and write a class about it. And it turned out it wasn't so easy. It's actually hard, really hard to get access to this stuff. If you have $300,000 to spend, you can probably get some telecommunications equipment, but that's not really an option for most of us out there. Our core project team, myself, I'm the founder and senior security consultant and the author of network forensics tracking hackers through cyberspace. David is our lead research scientist. Randy is our certified forensic examiner and Scott is the head of our penetration testing team. I really want to give a big shout out today to ISEC partners. Thank you guys so much for lending us some of your hardware to use for this demo. We really appreciate it. So here's the parts list. This is all you need to make your own cellular intrusion detection system. First, you need a FEMTO cell. You can get it used. The one that we used as an example was $200 even on eBay. We had a Dell OptiPlex GX260. It was also used. It cost $44 including shipping. Obviously if you want to, you can get some beefier hardware, but that was totally fine for our purposes. We have a hub. A hub is really nice to have in our lab. It's a real hub. It's an old hub. More valuable to us than switches because it makes sniffing on the wire a lot easier. We have an FTDI friend from Adafruit and that lets you connect to the console port on the FEMTO cell and then a couple of cables. So that's it. And some magic, which we'll talk about today. So a little introduction to the Android's Dell's malware, which is what we're going to focus on. It came to public attention in March of this year, so just a few months ago. And it's distributed by spam, spam email. So people click on a link. The one that Dell Secureworks wrote their research paper on was an IRS spam. Once you click on the link, so it's distributed through the same channels as some other malware. Normally they use the black hole exploit kit to infect systems, but that doesn't work on Android devices. So in this case, they're using a fake Flash Player update. And people fall for this all the time. You click on the link. It says, sorry, you need a new version of Adobe Flash Player in order to read this file. And then it shoots you to a page that looks like an Adobe page. And the user just sort of walks through the installation for the attacker. Stells is capable of monitoring SMS messages and also filtering and intercepting SMS messages. This isn't surprising because ever since banks started coming out with out of band authentication, like you go to log in to your bank's website and then sometimes it will send you a pin to your phone, right? So if an attacker has, an attacker can insert information into that web page as they're doing a man in the browser attack and also ask you for your phone number. And when they do that, you type in your username, you type in your password, you type in your phone number, they hack your phone. And then from that point on, they filter messages going to your phone. So they can grab those pins as the banks send them to you. So there's direct financial incentive for attackers to be targeting your phones and linking them with your PCs. And the benefit that they gain from actually filtering messages so that you can't see some of them is that you won't know if somebody is trying to, if someone is trying to get into your bank account because it would be kind of funny for you to see all of a sudden a text message with the pin for your bank when you weren't actually trying to log in. So they filter that so that you can't see it. It can make phone calls and it can send SMS messages to premium numbers. Again, direct financial incentive for the attacker. And as we'll see later, it can also update itself. So any behavior that we don't see in it right now, they could totally add tomorrow. The behavior of this malware could completely change overnight if someone wanted it to. This is our RF shielded cage. As we were doing this research, we really wanted to do it right. And so we consulted with legal counsel extensively. And we also wanted to make sure that no one else's cell signals could possibly be captured as we were taking these packet captures. This device is something we normally use in our cell phone forensics lab. We have the only RF shielded cell lab, cell forensics lab in the state of Montana. It includes AV so you can actually see into the box, which is kind of cool. And you can record it. So David, do you want to talk about the ports? So yeah, let's talk a little bit about all the stuff you see up here on stage. So the RF shielded cage here, we're using, as we said, out of an abundance of caution so we don't end up accidentally capturing your traffic. Now, these FEMTA cells can be configured to only connect to certain phones. But in addition, we wanted something that was an absolute guarantee that we wouldn't accidentally get someone else's traffic that wasn't ours. So on the side of this box here, you can see there's a number of configurable ports. The first of which is currently set to be a Ethernet jack, a filtered Ethernet jack for the backhaul to Verizon's network. We then have, sorry, we then have a USB port that connects to the FTDI friend that's inside that we will use for serial communication. We also added on the instructions and with the help of the manufacturer, Ramsey, added a SMB connector so that we can route GPS in. One of the requirements is, and one of the challenges of doing this demo inside of the middle of a hotel is that you need GPS lock in order for the FEMTA cell to boot up. So we had to run a GPS signal inside the cage. Let's see. So what's our setup look like inside here? This is the other side of the exact other side of those ports. We've got that GPS antenna, the Ethernet cable, and the cable running to the USB cable running to the FTDI friend, which then has a little hack together custom breakout to a HDMI cable where Samsung put the serial console on two pins of an HDMI port that's in the bottom of the thing. You can also see we have power and such in here. Let's see. So cellular intrusion detection. This wasn't originally, like when we set out to do this project, we were looking at network forensics, like, hey, let's see what we can see about the cellular network. And it quickly became this big project to even get access to it. So as soon as we did get access, we said, okay, what can we do? And we thought, here's something, cool, let's set up a cellular IDS. We can hook it up to snort. This is just going to be regular internet traffic at some level, we assumed at least at the time. Let's hook it up to snort and see what snort can find if it can see malware and see command and control traffic. So when we first got root access on this thing, which we'll step through how we got root access here in a minute, we just hooked up TCP dump to it, because it actually has a copy of TCP dump. The box itself, the femtocell itself runs a version of Linux called Montevista. And so we're like, okay, let's capture some traffic. Turns out that, of course, everything is encrypted using an IP sec tunnel back to Verizon's core network. And just running TCP dump just gets us a whole bunch of, you can see the IS camp and the DNS. So not too useful to us. So does that backwards a little bit? How do we get root access and console? On the bottom, there's a HDMI port. It has 3.3 volt console access on pins 16 and 17. We hooked that up to an FTDI friend from Adafruit. Just an adapter for USB. It looks like $15 part or something. But the thing was I got really antsy while we were waiting for the shipping for this. And this was right after DEF CON last year. So I just grabbed my badge from last year and since it had an FTDI connector on it, I just ended up using that one. It's a little bit of a hack together solution, but I thought you'd enjoy that. So as soon as we got console access, we find, oh, their first layer on here of the stack is a Uboot bootloader. Samsung has done a little bit to modify the Uboot bootloader. They have published their source code since it's GPL licensed. You can go to their website and download it. And in the old versions, and old being this time last year, up through like January or February of this year, all you had to do to interrupt the boot process was instead of hit any key, you would type SYS return. And the thing is the code for that was in Samsung's published source code. And we actually didn't figure that out. That was another gentleman who I'm spacing his name, but it's in our white paper linked to his blog post about it. So we took that and okay, we've got root access. So then we just did init equals bnsh is to get root access. And then we stepped through the boot up process manually since the init scripts don't run. We then started looking at the networking connections. We saw there's DHCP going on, there's the VPN tunnel I talked about a little bit ago. And it has IP tables. It's using that to filter out certain so that only Verizon addresses can connect to some of the services. But we're like hey, since we saw it, TCP dump wasn't working, let's see if we can get access through IP tables. So that was a good enough idea. But the problem was that what's on there is very bare bones implementation of IP tables 137. No NFQ, no T command, no way to copy off and route traffic. There's not even a logging facility built in. It's an embedded system. It's not that surprising. So we went back to Samsung source code again. And so we really want to use NFQ. We grabbed the source code from their site. However, it doesn't want to compile with modern versions of GCC. So it's really picky about only compiling with Montevista's ARM tool chain. Now that encountered the next problem, which was that Montevista doesn't openly, despite everything being GPL license, they don't openly distribute that. They only distribute their tool chain as such to vendors and their direct customers. However, one of the customers is Texas Instruments, who makes the OMAP series of boards, which often use Montevista Linux. So the OMAP, I think it's L137 development board, uses the same version of Montevista Linux as this does. The chipset in here is actually an OMAP 1710, which is a very similar Texas Instruments related board. So if you go to the TI website, you can grab the tool chain for Montevista Linux. We use that to then build the kernel modules for NFQ and all of its dependencies, like contract and such. So we got all those binaries. What NFQ does, if you're not familiar with it, it pulls packets out, route them with a rule in IP tables, send them to Q0 or Q1. Then you have a user space program, pull off the first one in the Q market and do whatever you want to with it. You can modify it, send it back. In this case, we're just marking it as accept this packet, sending it back and then sending a copy of it out to standard out, which we'll then type to Netcat and do fun stuff with here in a minute. So, oh yes, here's all that stuff I was just talking about, got ahead of myself. Kernel modules, IP tables. So we just compiled statically for ARM that just pulls those, the packets out of the queue, sends them off. This is an ARM 926EJ processor. What we did for cross, rather than dealing with cross compilers was just started up a Debian ARM emulator in Keemew. We found that to be much simpler solution for compiling binaries because you don't want to cross compiling makes my head hurt sometimes. So, the Netcat, we wanted to get traffic off of this thing as quickly as possible. It doesn't have much power. It's a pain to work with. Word to the wise, if you do this, there is, by default, control C is not bound to sig term. Do not run ping. At least not without account flag or something, or you will have to reboot the whole thing. So, I was like, oh my God, I really want to get off of here as fast as possible, send it to Netcat, and we'll do the rest of our processing on some other system, and originally that old Dell Optiplex. So, we can see on the other end, we set up just a Netcat listener, which pipes to that small, pretty small Python program that leverages Skape and libpcap to just take the raw stream because NFQ exports as hexadecimal stream and convert that into a pcap, which we then write to a file. And, hey, lo and behold, we had working traffic. And then we looked at that traffic. Let's let Sherry talk about that. It took us about 10 months to get to this point where we had traffic. We were a little bit slowed down. We started the project in August, and by February, we had accomplished a lot of things, and we started to enter and start collecting packets when Samsung upgraded the software. And we had to actually break back into the system in order to regain access. And we did figure out how to do that, but it took us a little time. So by the time we were actually able to inspect cellular traffic, it was around May. And when we finally got it, it was beautiful. You can see here this is just the basics. It's all IPv4. There's 82. 0.4% of the bytes were UDP. And then you see normal traffic that you might expect for managing a remote system. So NTP, SNMP, DNS, ICMP, that kind of stuff. You scroll down okay, you start to see TCP that's 0.21%. I was pretty intrigued to see some clear text FTP traffic and then we start getting into the madness, the mirror world. There's GRE, so that's used to tunnel layer 2 PPP traffic from the FEMTO cell over to Verizon's core network. And then you see UDP in IPv4 in PPP in GRE. Okay, I can handle that. Here's the next screen. So we have TCP within IPv4 within PPP within GRE. And this is where your web traffic lives right around here. In some cases, Wireshark can actually dissect that far and can pull out some of the higher layer traffic. And then we go down here. You see TCP in IPv4 in PPP in TCP in IPv4 in PPP in GRE in IPv4 in PPP in GRE in IPv4. And we're not done. I don't know how far this rabbit hole goes. It just kept going and going and going. So David didn't believe that this was actually real. I just figured it with some kind of a bug in Wireshark. Yeah, so he made me go find some of these packets. Here's an example. This is data in TCP in IPv4 in PPP in TCP in IPv4 in PPP in data in IPv4 in a frame. Keep in mind this is before it gets stuffed into an IPsec tunnel and sent across back to Verizon. Yeah. And I know the ISAC partners guys were tethering all of this over another phone also. Sounds like Dr. Seuss. Yep. Here's an example of the FTP traffic that we saw. It seems to be used for routine, and we're not going to dig into this but it seems to be used for routine communications between the FEMTO cell and Verizon. So it'll go out and this is all automated. It'll enter a password to an FTP server and pull down some configuration files, for example. So I just thought that was kind of neat to see the reconstructed stream here. The phone does mobile handset authentication using PPP chat. It's a challenge authentication response protocol and we were able to write snort signatures based on that. So that means that any time the phone joins the FEMTO cell, we have a little snort alert that pops up. The string that the Verizon network responds with is welcome to the Samsung, BSS, something, something. So you can tell as soon as there's a new device connected to your FEMTO cell, which is kind of handy especially if you do end up pulling this on your home network or on an enterprise network. And you can restrict it also so that it only connects to specific phones as well. Which I would recommend doing if you're inspecting traffic, of course. So we also wrote a custom CDMA-2000 protocol disector and CDMA-2000 of course is extremely complicated. And our efforts in this respect were hampered by the fact that Verizon didn't seem to be using the latest version of the standard so we had to go digging through and figure out exactly which version of the standard it was using. This is an example of the CDMA protocol disector dissecting an A8 setup A9. So that's used to set up interfaces which are used to transfer user data. And this is available on Sourceforge. As soon as we get to a clean network so probably tomorrow when one of us is home we'll upload this stuff. We ended up examining the Android data traffic most of all and that's because the malware that we're using, Android.Stells actually transmits signals back to the attacker over HTTP. So we've got that HTTP traffic and analyze it and figure out how the bot was working. There were two kinds of GRE packets that we saw and Wireshark was dissecting them differently. This was a default version of Wireshark. There was GRE type 8881 which is not the one I like. It is a CDMA-2000 A10 unstructured byte stream packet and this was used for outgoing HTTP requests. Wireshark didn't dissect this at a very high level. However, there were also GRE 88D2 packets which were used for incoming HTTP requests and Wireshark did decode more. It could get all the way up to TCP so it got IP and then TCP. It still didn't get the HTTP in most cases but what that meant was that when we looked at this first in Wireshark we saw incoming TCP segments and there was no matching outgoing TCP segment until we started dissecting it again. I think I have to step down. Sorry, sound engineer. Can everyone hear me? Here you see GRE type 8881 packet and you can see that Wireshark only dissects as far as that PPP. It doesn't dissect the IP or the TCP so we started looking a little further and you see here that 4500 right? Anybody in our network class, our network forensics class know what the 4500 is? This should... Yeah, it's the start of an IP packet. That 4 represents the version number so in this case it's IPv4 you're probably only going to see either 4 or 6 there. The 5 represents the length of the IPv4 header, the number of 32-bit words so in this case that's a 20 by IP header which is very common because that's the default. Here's the type of service field which you see 00. Anytime you start looking at this IP packet and dig a little further and that's what we did and we saw that indeed it was you could actually see the source IP address the destination IP address you could see the port for a ninja duck what is hex 50? What's that in decimal? 80, awesome. Hey David can you give that guy a ninja duck? Okay so there actually was traffic in here that should be dissected I'm not sure why Wireshark can't pick up on it and then here's the 88D2 packets and you see it gets further there's the point to point protocol there's the IPv4 so it actually got it this time and then there's the TCP segment right here and you can see inside there's actually HTTP traffic inside of that right here HTTP and higher layer stuff it didn't get that far with the 88D2 traffic but it was useful that it could at least dissect as far as the TCP segment. So here are some threat indicators that Dell Secureworks put together for the Android Stells Mauer you can see that it so Android.Stells has specific command and control servers that are known there's 31.170 something something that's a server in the United States actually and then the other one 95 is a server in the Netherlands there's also a file name that Android.Stells is typically distributed flash player and there's two domains that are in common use right now the freeiz.com one and the androidflashplayer.net.ua one so those are things that we incorporated into our snort alerts here's some snort alerts that we used to detect activity with the Android Stells Mauer this one possible CNC server traffic we put the IP addresses in here but you can't just look for an IP address the way you normally would look in an IP packet and snort because of course snort can't dissect all those crazy layers you actually just have to look at it as a hexadecimal string which we did as you can see right here so hopefully that's going to pop up in the content of a packet it doesn't always sometimes it's going to be fragmented across multiple packets but we found that this actually worked most of the time same thing here you see detecting domains again we have to look for it as a string in the packet and because these are longer they're more likely to cross multiple packets we saw in particular we would see DNS DNS responses containing these domains but usually the DNS requests the domain was broken up across two packets so Wireshack would show you that there had been a DNS sorry snort would show that there had been alert on the response and not on the request and then if you want to detect the binary of course we could take a snippet of the binary itself and have snort alert that worked really well so you can see before a user even infects themselves you can see when they're downloading that flash player update so now we're going to do a little demonstration in our lab I was the attacker and the attacker can be any phone in this case it was just an AT&T smartphone that we used to differentiate from our Verizon phone and with the AT&T smartphone we sent a nasty text message and David was the victim so the victim of course was a Verizon Android smartphone because we wanted it to be infected so now let's switch over to our box this is the boot up part of the demo we're going to do the boot up part of the demo that is it we need our lab codes hold on safety first that's mine button this thing someone's trying to sabotage me sorry for switching again audio engineer I know that's a pain I used to do that for a living so alright as soon as you okay yeah we have this here up on the screen and I'm actually going to restart this don't worry we're not setting this one up it's not going to capture traffic so if you've got an Android phone out there don't worry so as soon as we plug it in here we're going to see the on and I don't know if you can see it on the screen but the uboot boot loader that's been modified by Samsung here and we've already set it to drop us into the command prompt and let's see so if you would type so on and boot yes so on and boot is a command that they added because the chipset on there uses the NAND flash memory that's proprietary to Samsung they added in support for that here we see we've now dropped into a root shell but very little setup because we didn't actually run the init scripts so now we're running the init scripts now we're running all these init scripts most of this is standard stuff there's a couple at the end there that we're not running the app that actually starts up the functionality for the cellular traffic and so we're choosing because we have a couple of things to do before we actually run that one of the other little things that's a quirk of this system is not everything's accessible until you run some of those scripts because the way on and works split up into a whole bunch of different locks and lock devices extract rfs.sh yeah and what we have to end up doing is mounting those devices and then merging that and sim linking them to the places they're supposed to be in the file system so for instance slash ubin contains lots of the actual cell phone functionality but that's not mounted until you run some of these init scripts rfs.sh so let's see what are we seeing here so now we're running our final init scripts here and then we're going to set up networking and the reason we set up networking is because we have to download those extra binaries that we've compiled for this system and need to copy over fortunately there are some standard tools, ftp is on here so we're going to use that to connect the address of this guy right here um going to say cd over to where our binaries are and the binaries we're downloading are the config or the kernel modules the packet capture little compiled binary that hooks into nfq and a binary for netcap that's really all we need to move over script there will make the rest of this easier so we don't have to keep copying and pasting every single command so we're going to run that script it is going to print all the commands we would run so you can see them we're in Zmodinger kernel modules we put all the kernel modules in order is important here if you do those out of order prerequisites won't work we're going to start the vpn back to Verizon's network this just runs these two binaries here the ssh and the vpn binary are something Samsung put on there they just automatically configure a connection back to Verizon and this usually takes a couple minutes it actually sets up tears down grabs like ntp and then tears down again and then sets up its final connection so next so then we kill the vpn and we kill the ssh and then we start the netcat listener on the sids so at this point we're waiting for that traffic to be shipped over and as soon as I hit over the traffic that's being collected from the femto cell is going to start being sent over to the sids so press enter to start exporting packets to the sids and there we go we add a whole bunch of here's the IP tables rules it's really important to put in accept rules for that netcat tunnel otherwise you're going to be capturing the capture that you send out and you end up with little like nasty little recursive loop in an infinite sized file pretty quick so then you hit enter to actually start the gps and the call routing functionality and as we were testing the system of course we wouldn't always want to start the call routing functionality right away sometimes we were just working on the underlying system and it can take a few minutes for that piece of it to start but you see right here are if you look at the size of the pcap that's being captured that's increasing and that's what you want to see when you make a call it's going to be added to that pcap file and it can take up to 30 minutes it requires a correct gps lock and it requires an internet connection that it likes so it can establish a good VPN connection and then it will sit and think for like sometimes 30 minutes an hour before it will actually have the connection all set up so then once you have that packet capture file set up you can use this tail command and pipe that directly into snort so snort is reading from that pcap file in real time and we've uploaded the rules that we want on there and you can see it loading commencing packet processing that means we're all good so now we're going to switch over to a little video where we show you us actually infecting the phone we were hoping to do this here but we've had some video issues so we're just going to talk you through it so you just watched us start up snort and here's what our screen looks like KBM, that would help good so you've just watched us start up snort and here's what the full screen looks like in the top left you can see snort running that second window down there is actually the serial connection to the console port on the femto cell here if I hit play you'll start to see the file size of that increase over time and then we have our netcat listener down there now this is a phone starting up inside our cage right here so this is recorded using that audio visual device and this is David compressed for time this is David, our victim clicking or starting up the phone we're also watching for snort alerts as they come in and you'll see as the phone starts up boom right there our snort alert tells us hey welcome to welcome to the network basically we know that there's a new phone on the network so jumping ahead a little bit we got a text message David you got a text message someone says hey check this out it was sneakynet.com and we're going to go for David he's tricked into clicking on the link it looks like this person was a little more creative that actually said I'll go back to second so this attacker was more creative it said would you like some candy and David wanted some candy I love candy and as soon as he clicked on that and the malware started downloading you see boom android stels known malware binary snippet so it detected that binary just based on the binary traffic now the user installs it it always boggles my mind that this works so consistently but you know users know they have to download and install their updates we try to trade them and here's David installing the update now it warns you that this malware wants a lot of permissions permissions to make phone calls permissions to send and receive text messages whatever who actually reads all that stuff the application is installed and funny we got this little message that says your android version does not support this update setup is cancelled so the user will say dammit sorry darn it and I guess flash player hasn't actually been installed so the application which appeared briefly on the desktop actually disappears but it is still running as we're going to see from the command and control traffic I believe it takes was it 60 seconds for the first connection back to cnc so here in a minute there you go possible cnc server traffic so to the user to the user it doesn't look like anything has happened but here you see possible cnc server traffic and it's talking to that system in the united states 31.170.161.216 and here we also see a post from the infected client that's because android stels communicates using HTTP post messages and we found some unique strings that allow us to tell specifically when it's an android stels post we're going to show those here in a few minutes and I believe we're seeing multiple copies of the traffic just because of the way that we're sniffing so that's something that we might want to work on so that we're only seeing one copy but we are sniffing on all the interfaces on the device okay that phone is just sitting there and every 15 minutes it sends a command outbound but the first thing that happens is it sends that post command to 31 that system in the united states and it got a response saying okay change the cnc server address so next you see it start talking to a different server that 95 ip address right here that's based in the netherlands and that 95 ip address said sms filters so whatever sms traffic was being filtered so that the user couldn't see it it's removing those filters so now the user can actually see all of the traffic that's nice and then you saw a weight 900 we saw a weight 900 command from our cnc server right here that's 900 seconds or 15 minutes so then we let this run for two days and what we found was every 15 minutes like clockwork it was sending that post command out and automatically the server would respond back and say okay wait another 900 seconds so not a whole lot was happening right there until we started taking over and actually intercepting things any questions on the demo so far anything you want to add question oh good there's a question some of its traffic uses also some sms messages which will not get routed over wi-fi and that's true of a couple of different bots there's some that use exclusively sms for the cnc this one you would still see like these http posts yeah you would still see that over wi-fi okay so let's dig into stealths in a little more detail and walk through this a little more slowly so here you see the text message we sent hey check this out and here's welcome to Sneaky Net would you like some candy we just saw that and unfortunately David clicked on the link got his phone infected and we saw this this first alert in there it went by pretty quick there was an alert on the malware file name flashplayer.android.update.apk because it appeared in that website so if you have users in your environment or if you yourself are on your home network you could see this alert pop up before you're even infected and here's the I think I'm going to have to pop down there again so I can see this sorry sound guys alright so here you see the android file name it's actually part of the get request right here the http get so it's buried in there and it's cool because you can see Wireshark didn't dissect this again because it's probably one of the 8881 gerry packets but you can see the 4500 the ip address the 0050 which means it's port 80 and that correlates with the girl flashplayer.android.update.apk the second snort alert that popped up was an alert on the malware binary snippet the first 42 bytes so after that get request happened we saw the first 42 bytes come up and that came up multiple times actually here it is in Wireshark now because this was coming the other way this was an inbound instead of an outbound http message Wireshark actually dissected it to a much greater level we actually see the ip there we actually see the tcp there it didn't get the http but you can see here the start of the android stels malware binary that pk that indicates it's a windows executable file so then you saw the flash player with the nice flash player icon that means it's safe and really from adobe downloaded onto the phone and david used the package installer to install it here's a clearer version of what it was trying to do do we want to allow this application to see our messages read your contact information we'll show you how we controlled it to send out our contact information it had full internet access it had access to the storage on the smartphone services that cost you money so it can call premium numbers and it can send text messages to premium numbers and it can read the phone status application installed here's what it looked like when it was first installed on the desktop then we got this message that said your android version does not support this update set up it's cancelled and then boom that was gone but as you saw it was still running in the background your mic's not on david no no go ahead honestly i think they gave up at this point the malware authors they're like oh they're pwned now we don't have to make it look pretty screen with text at that point yeah okay so again the user cannot tell that the phone is infected this is invisible to the end user and while this is going on we saw the possible CNC server traffic and we were alerting on that IP address just presenting itself as a string inside the inside a packet here you can see here you can see a DNS response before it starts talking to that CNC server the first time it has to do a DNS request for the domain and then it's going to get a DNS response in the request the domain was broken up in the response it wasn't so we saw the alert on the response and it's kind of interesting that Wireshark actually does dissect this properly so we see PPP and then IP and then UDP and then it did get the highest layer protocol DNS so a challenge to the audience is to call dissectors that's totally worth it and we saw the earlier DNS request did not here's the fragmentation right there there's the domain and you can see it's cutoff .fr the rest is in the next packet okay so here's an HTTP post this HTTP post message is the actual STELS command and control traffic this is what the phone home message looks like to the attacker server in the Netherlands so you can see here PPP Wireshark didn't dissect it but you can see post slash data .php this post message was broken up across 23 packets and I had to reassemble them manually which was a real pain here's the first half of it it's pretty long it has that unique multi-part boundary right here aab03x and that's pretty easy to stick that into snort it sends the IMEI the IMSI so you can tell the phone's number from the post to the attacker and the attacker can tell that information about the phone, the version what time it thinks it is also the name bot ID and some other stuff in there Samsung the manufacturer so it sends a bunch of information about the bot sends a bunch of information about itself to the attacker every 15 minutes or however long the attacker tells it and we can see that happening here snort alerted on it successfully I alerted on the string bot ID I also alerted on that unique multi-part boundary in an HTTP post here's the server's response so the server is going to get this post message and start sending commands in response it's a very simple thing there's no authentication here between the infected bot and the server we've seen now we're more complex and we're sophisticated since 1999 when I think it was the Babylonia worm came out we've had authentication so here IP, TCP, HTTP Wireshark actually got the HTTP this time this is an incoming message from the attacker's server in the Netherlands and here's if you reassemble it here's what it looks like remove all SMS filters true okay wait 60 so it's telling it only wait 60 seconds and talk to me again and then it changed the server address so that's kind of cool Scott will talk to you a little bit more about it it can send lots of other commands as well pretty much anything in that let's see I have a list here pretty much anything in this list send SMS the server can tell to send an SMS message it can tell to delete an SMS message it can tell to open a URL send a contact list out to the attacker so it can read all of your contacts or just update itself make call is the last one it can make phone calls without you knowing about it where were we okay so remove all SMS filters we put some of those commands into Snort and Snort will alert individually on each of the commands so you'll have a log of exactly what your malware was doing if you set it up this way and then again after it received that change of server we then saw a DNS query and response for the new server name corresponding alert to go along with it so the bot sent a post to the new server then over in the Netherlands and it received a new response this time that second server said remove all SMS filters true wait 900 so instead of telling it wait 60 seconds the new server said wait 900 seconds every 15 minutes this would still be pretty easy to see if you were watching your traffic in an enterprise every 15 minutes is still pretty noisy on the network wait a month and it wouldn't phone back for a month and that would be a lot harder to detect so here's a screenshot our cellular intrusion detection system CIDS was successful we alerted on the initial infection we alerted on every phone home that the bot made to the attacker and you can use this same method to detect infected smartphones in your environment whether you're at home or whether you're at work and now Randy Price is going to talk about the device forensic analysis so the question is were we able to see SMS messages and dissect them and set up a fake SMS server we do have SMS traffic I'm sorry a fake CMC server we do have SMS traffic we haven't really had too much time to play with it but that is definitely the next step that we're going to be poking around with when we get home I'm hoping Tom Ritter will lend us his SMS disector the thing about the SMS is that it's not encrypted but it's encoded it's like reverse 7 byte or something don't quote me on that but as far as the CNC we'll get to that in just a second after capturing traffic from the infected phones we conducted device forensic analysis the forensic analysis cooperated findings from our network forensic analysis we took a physical extraction of the Samsung illusion with the celibate you fed after the phone had been infected in the testing lab please note that the okay please note is that better okay please note that the the infecting and the extraction were performed with an RF shielded test enclosure which is shown here okay the celibate physical analyzer was used to analyze the extraction the malware scanner identified potentially malicious files which are shown here the celibate malware scanner identified all of the suspicious files as android trojan fake app K we recovered each of the files and took the SHA-1 cryptographic checksums we confirmed that these SHA-1 sums matched the cryptographic checksums for the android stels malware reported in the Dell Secureworks stels android trojan malware analysis report we found a file called stels settings XML which appeared to contain malware configuration settings as you can see from the configuration file each bot is assigned a bot ID this allows the bot herder to manage the bots under their control the server listed is the command control server that instructs the bot where to phone home to the period value of 300 seconds or 5 minutes is the initial phone home interval this tells the bot to phone home every 5 minutes good morning DEF CON I'm super stoked to see so many guys out here for 10 a.m. on a Saturday I'm going to hop down here I like to walk around and use my laser what's that there you go, stronger ones alright so because of the research that Randy did with the UFED we were able to determine the way that stels is communicating back to its command control server we knew the address of the command control server so we also knew what we were looking for so let's be a man in the middle when we want to do a man in the middle attack against us I had to set up a proxy so we could tunnel the traffic back through there so enter my favorite tool for doing web testing burp suite professional to set this up we had to tunnel all the traffic as I said through burp suite we were really looking at that port 80 traffic that I was getting all the packets I decided to root the android device that we were using when I do mobile application penetration testing I usually take a rooted device just in order to get all the SSL encrypted packets as well because I wasn't sure perhaps stels is using two forms of communication we just weren't seeing that encrypted portion of that doing that on an android phone is kind of interesting you have to install your own root certificate authority to the device itself but to do that you have to do even more work so you have to use an outdated version of open SSL I think I was using version 0.98 I think that shipped with the boon 2104 originally which is the virtual machine I set up to do that on you have to create an md5 hash calculation of the subject line of the certificate append a dot zero to that and then install that into the several files down in the system directory of the android device and to do that you have to have root on the device once I had root I remounted slash system as read write and then install that certificate to the correct place and now we can see all the traffic running through that phone no matter if it's a web application, if it's a you know just a mobile banking app I can see all the traffic running through and actually intercept that using my proxy in this case I didn't have to end up doing that all the traffic was going over port 80 http completely unencrypted and let's take a look here we turn on so what I saw was what you had alluded to here we see remove all sms filters true so it's not listening on that it's using the http method it's saying wait 60 so it's telling it to wait 60 seconds before calling back and we're seeing it set the command and control server here so I got to thinking well I wonder if it's going to be this easy all I had to do was replace the command and control server with a server that I own and now my device is going to be calling back to me so I did that wait 60 I still sent the remove all sms filters true and then I decided to wait 60 seconds sure enough it worked and now it's calling back to me instead of the actual cnc server now the server that I set up didn't actually send commands or do any control stuff it would just get a 404 error when the bot actually received that 404 error it does a time out and then you have to wait 5 minutes until you can actually start communicating with it again so I was like well this is kind of troublesome research so instead I just continue to keep intercepting all of the requests and telling it to wait 60 or wait 5 or wait 30 depending on what I was trying to do I did find out that when I tried to set it to wait 2, wait 5 seconds it would start going so fast that it would eventually time out and then it would wait between 5 and 15 minutes before calling out again so that was even less helpful you can also adjust it for more extended periods of time if you want to take a break and go out to lunch you find that pretty helpful so controlling stealths I wanted to see if we could actually tell it to export that contact list from the device and sure enough you can I just had to send contact list true wait 60 seconds and 60 seconds later we see it send out that contact information as you can see at the bottom of the page here I actually got all the phone numbers off of that device and you can read that it sent it right back to the attacker over here and had I not changed that command control server the attacker now has all the contacts in my device and they're probably now going to use those contacts to infect more phones I find this to be really helpful say if you're an enterprise environment I don't know how many of you have to manage IT where you're from but if you have a device on your network you know it's infected because we have a cellular IDS now it's not always easy to find that device and on top of that you may have a BYOD policy where you've got employees coming in to do it to clean that malware off using this method we never even touch the device and we actually protect that user by cutting off the head of the snake so to speak if the attacker is no longer communicating with that device the attacker is not going to be able to steal that data this buys us a lot of time to actually track that device down get the appropriate permission and get that virus cleaned off of there pretty much concludes our presentation as you saw we were able to infect an android phone with stels just as a demonstration of the virus in a control channel so both pieces of that and no agent was actually needed on the device in order to do this we could have shut this down remotely without installing anything this was all for $285 and a little bit of pixie dust which you guys have now and of course if you wanted to get a beefier server you certainly could again here's that parts list all you need is a femto cell some kind of system whether it's a laptop or whatever it is a hub or switch and then some cables thank you all so much we're going to take questions if anyone wants to see the demo a little bit closer up what room are we going to be in afterwards we're going to tear down and then we're going to move somewhere else so feel free to come visit us LMGsecurity.com