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't tell. The screen here, 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 stels malware so what you see is sending data out to the
Netherlands every 5 minutes or every 15 minutes. Depending on whether or not it actually gets
a response from the command and control server. 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.
ears. 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% 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 lands. 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 types of
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
and I have 10 infected bots inside this Department of Defense building. I have 20 infected bots
inside Hack Me 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 e-mail. We're probably going to get more lists of
people to attack the same way we see e-mail 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 smart phones. The Android's Dells malware
by default phones home or at least the sample we were analyzing phoned home every 15 minutes. So
you would see a chart that looks very similar to this with your smart phone. And of course, the
user would never be able to tell. Now, I'm going to show you a little bit more of this. This is a
chart that we made. 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 a certain amount of
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 femtocells, basically miniature based
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 femtocells. They're fairly inexpensive. This entire project to build a cellular intrusion
detection system cost $285. We used both the Samsung femtocells and the Verizon femtocells to
test out some 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
femtocell, the Verizon femtocell, 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 when we infected a phone with the Android
stealth malware, Snort would actually detect it and alert upon it.
So our roadmap for today, number one, we're going to step through the FemtoCell 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 FemtoCell 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 stealth malware, captured the traffic, and
then used the Snort output.
Then we're going to do a detailed walk through of the Android stealth 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 is going to show you how he took over
the Android stealth 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 of 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
femtocell. You can get it used. The one that we used as an example was $200 even on eBay. We had a
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 femtocell 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
stealth 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 e-mail. 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 same channels as some other malware. So it's distributed through the same channels as
a 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. Stealth is capable of monitoring SMS messages and
also filtering and intercepting SMS messages. This isn't the best way to do it, but it's a good
way to do it. 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 user name, 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 well. So that's one of the things that Dell Secureworks
does, 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's
trying to ‑‑ if someone's 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 pre‑local users. So if you're trying to log in to your bank, you
can see your phone numbers. You can see the address and phone number. 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 can 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. So we consulted with legal counsel
extensively. And we also wanted to make sure that no one else is self‑subsidizing. So for us, we
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 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? Yeah, let's talk a little bit about all this 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 femtocells 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. You can
see the first of which is currently set to be an Ethernet jack, a filtered Ethernet jack for
the backhaul to Verizon's network. 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 the middle of a hotel is that you need GPS lock in order for the femtocell to boot
up. So we had to run a GPS signal inside the cage. Let's see. So what's our setup look inside
of here? Like inside of here? This is the other side of the exact other side of those ports. We've got that GPS antenna, we have a
the Ethernet cable and the cable running to the USB cable running to the FTDI friend which
then has a little hacked together custom breakout to a HDMI cable where Samsung put the serial
console on two ports of an HDMI or 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. So cellular intrusion detection, this
wasn't originally 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, let's put this
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 Monta Vista. 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, you know, you know, you know, you know, you know,
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 to step backwards a little bit, how do we get root access in console? On the bottom
there's a HDMI port. It has 3.3 volt console access on pins 16 and 17. We hook that up to
an FTDI friend from Adafruit, just an adapter for USB. It's like a $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 hacked together
solution, but I thought you'd enjoy that. So, yeah, I think it's a little bit of a hack together
solution. So as soon as we got console access, we find, oh, their first layer on here of the
stack is a U-boot bootloader. Samsung has done a little bit to modify the U-boot bootloader.
They have published their source code, sends its GPL license, so you can go to their website and
download it. And in the old versions, and old being this time last year, it's a little bit of a
hack. But what you had to do in the 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
S-Y-S return. And the thing is, the code for that was in Samsung's published source code, so
and we actually didn't figure that out. That was another gentleman who I'm kind of familiar with.
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 in it equals bin SH 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 V PN 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 TCP dump wasn't working, let's see if we can get
access through the router, until they make the most of the organization. So we did an
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 Monta Vista's arm
tool chain. Now that encountered the next problem, which was that Monta Vista doesn't openly,
despite everything being GPL licensed, they don't openly destroy IP tables. They don't
distribute that. They only distribute their tool chain and 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 Monta Vista Linux. So the OMAP, I think it's L137 development board,
uses the same version of Monta Vista 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 Monta Vista 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 table, and then it puts them in the
table, send them to Q0 or Q1. Then you have a user space program, pull off the first one in the queue, mark it, do whatever you want to with it. You could 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 will then type to Netcat and do fun stuff with here in a minute.
Thank you.
So, oh, yes, here's all of that stuff I was just talking about. Got ahead of myself. Kernel modules, IP tables. We wrote a little C program that we just then compiled statically for ARM that just pulls those packets out of the queue, sends them off. This is an ARM 926EJ processor. What we did rather than dealing with cross compilers was just
just started up a Debian arm emulator and 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 net cat, 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 this traffic off of here as fast as possible. Send it to net cat and we'll
do the rest of our processing on some other system and originally that old del optiplex. So
we can see on the other end we set up just a net cat listener. We're going to run it on the
other end of the network which pipes to that pretty small Python program that leverages
scapy and libpcap to just take the raw stream because NFQ exports as hexadecimal stream and
convert that into a pcap which we then just 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.
So it took us about ten 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 all
this and we were just about ready to hit 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 we were able to do a lot of
it. And when we finally got it, it was beautiful. So this is the first of four slides that I'm
going to show you of a single Wireshark protocol hierarchy summary. You can see here this is just
the basics. It's all IPv4. There's 82.04% 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 .21%. I was pretty intrigued to see
some clear text FTP traffic in there. 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 femtocell over to
Verizon's core network. And then you see, I don't know if you can see here, UDP in IPv4 in PPP in GRE.
Okay. I can handle that. Here's the next screen. All right. So we have TCP within IPv4, within
PPP within GRE. And this is where your web traffic lives right around here. So we can in some
cases, in some cases Wireshark can actually dissect that far and can pull out some of the higher
layer of traffic. And then we go down here. You see TCP in IPv4 in PPP. And then you see the
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 was some kind of a bug or
something 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
PPP in GRE 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 ISEC partners guys were
tethering all of this over another phone also. So. Yeah. And I know the ISEC partners guys were
tethering all of this over another phone also. So. Yes. 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
stuff too much. It seems to be used for routine communications between the Femtocell and Verizon.
So it will go out and this is all automated. It will 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.
AUDIENCE MEMBER 6.
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 femtocell, 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 femtocell which
is kind of handy, especially if you do end up deploying 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 dissector. 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 back and look at
it, go digging through it, figure out exactly which version of the standard it was using.
This is an example of the CDMA protocol dissector dissecting an A8 set up 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 transfer
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 wanted to be able to pull
out 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 layer. 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 when we looked at this first
in Wireshark, we saw
this and there was no matching outgoing TCP segment until we started dissecting it with
our eyeballs.
So that was a bit of a pain. I think I have to step down to actually be able to point
at things.
Sorry, sound engineer.
.
Okay. So here you see ‑‑ can everyone see? Can everybody see me? You saw me? Can
hear me? Here you see a Jiri 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? 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-byte IP header, which is very common because that's the default. And then here's
the type of service field, which you see 00. So any time you start looking at this hex and you
see a 4500, you should think, aha, maybe that's an 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 actually see the source IP address, the destination IP address.
You could see the port. For a NinjaDuck, what is hex 50? What's that in decimal? 80. Awesome.
Hey, David, can you give that guy a NinjaDuck? Okay. So there actually was traffic in here that
should be dissected. I'm not sure why Wireshark can't pick up on it, but it can't get very far
in that crazy layering scheme. And then here's the 888D2 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 888D2
traffic, but it was useful that it could at least dissect as far as the TCP segment. So here's some
threat indicators that Dell secure works put together from the Android . The
You can see that ‑‑ 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.Android.Update.APK. And there's
two domains that are in common use right now. The freeiz.com one and the AndroidFlashPlayer.Net.UA
one. So those were things that we incorporated into our snort alerts. Here are some snort
alerts that we used to detect activity with the Android.Stells malware. 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 for an IP address in an IP packet in snort because
of course snort can't dissect all those things. You can't just look for an IP address in an
IP packet. 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 can 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 be broken up across multiple packets. We saw, in particular, that there
were DNS responses containing these domains, but usually the DNS requests, the domain was
broken up across two packets. So Wireshark would show you that there had been a DNS ‑‑ I'm
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 on that. And 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. Sad day. Yeah. 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, right?
Yeah, we're going to do the boot up part of the demo.
We need our lab codes. Hold on. Lab codes. Safety first.
That's mine. Who buttoned 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 all right. As soon as you ‑‑ okay, yeah, we have this here
up on the screen. And I'm actually going to restart this femtocell. Don't worry. We're
not going to do that. We're going to do it again. We're not going to do it again. 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 own
and ‑‑ I don't know if you can see it before it scrolled off the screen, but the U-boot
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 ‑‑ going through our
script. Cool. So own and boot? Yes. So own and boot is a command that they added because the
chip set 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 set up,
because we didn't actually run the init scripts. So we're going to have to do this again. So
now ‑‑ So now we're running the init scripts? Yep. 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.
There's one S70 app that actually starts up the functionality for the cellular traffic. And so
we're choosing ‑‑ because we have a couple things to do before we actually run that. One of
the other little things that's a quirk of this system is not everything is accessible until you
run some of those scripts. Because of the way own and works, split up into a whole bunch of
different blocks and block 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 ‑‑ you know, 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 do we see in 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. Yep. Fortunately, there are some, you know, standard tools. FTPs and stuff like that.
CD is on here. So we're going to use that to connect ‑‑ that's the address of this guy right
here. I'm going to say CD over to where our binaries are. And the binaries we're downloading are
the ‑‑ the kernel modules, the packet capture little compiled binary that hooks into NFQ. And
a binary for net cap. That's really all we need to move over. We've also got a script there that
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 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.
Yep. 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, sets up, tears down, grabs like NTP,
and then tears down again and then sets up its final connection. So we're going to go ahead and
go next. So then we kill the VPN and we kill the SSH. Yep. And then we start the net cap
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 a
few things. You know, the first one is that when you start the netcat server, you can accept
rules for that netcat tunnel. Otherwise, you're going to be capturing the capture that you send
out and you end up with like a nasty little recursive loop in an infinite-sized file pretty
quick. Okay. 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.
system. And it can take a few minutes for that piece of it to start. But you see right
here now 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. Yep. So now we're going to switch
over to a little video. I'm going to show you how to do that. I'm going to show you how to do that.
This is 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. Oops. KVM. That
would help. Good. Okay. 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 right now. And you can see that it's
running. That second window down there is actually the serial connection to the console port on the
femtocell. Here, if I hit play, you'll see ‑‑ 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. Compressed for time. This is David, our victim. And this is
KVM. 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 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. So we're going to go ahead and check this out. So we're
going to go ‑‑ poor David. He's tricked into clicking on the link. Now, usually you're going to
see this be a flash player update with the Stealth Mauer. It looks like this person was a little
more creative. That actually said ‑‑ I'll go back a 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 Mauer started downloading, you see, boom, Android
Stealth's known Mauer app. And you can see that the Mauer app is now working. You can see that the
Mauer binary snippet. So it detected that binary just based on the binary traffic. So 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 train them. And here's David
installing the update. Now, it warns you that this Mauer wants a lot of permissions. Permissions
to make phone calls, permissions to send and receive text messages, that kind of stuff.
Whatever. Who actually reads all that stuff? Yeah.
Now the application is installed. And funny, we got this little message that says your
Android version does not support this update. Setup is canceled. So the user will say, damn
it. Sorry, darn it. And I guess Flash Player hasn't actually been installed. So the application,
as we heard 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?
Yeah, 60 seconds for the first connection back to CNC.
Right. So here in a minute, yep, there you go. Right there. Possible CNC server traffic. So
to the user, I'm zooming in here, 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.1 seconds. It's talking to that system in the United States. It's talking to that system in the
United States. 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, might work on so that we're
only seeing one copy. But we are sniffing on all the interfaces on the device. Okay. So here
again, 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 remove 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 wait 900. Let me back up here. We saw a wait 900 command
from our CNC server right here. And then you saw a wait 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 wanted to add? No?
Question? Good. Oh, good. Okay. There's a question. Yes.
If you're not on the cell phone network, you have an Android device that's attached to the
Internet, Wi-Fi, let's say, some of its traffic. It 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 hosts, yeah, you
would still see that over Wi-Fi. Yep. Okay. So let's dig into Stell's in a little more detail and walk
through this a little more slowly. All right. So here you see the text message we sent. Hey, check
this out. SneakyNet.com. And here's welcome to SneakyNet. Would you like some candy? We just saw
that. And unfortunately, David clicked on the link, got his phone infected. And we saw 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. Sorry, sound guys. All right. 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
GRE packets. But you can see the 4500, the IP address, the IP address, the IP address, the IP
address, the 0050, which means it's port 80 and that correlates with the get bad 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
is kind 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's Dells malware binary, that PK that indicates it's a Windows
executable file. So then you saw the FlashPlayer with the nice FlashPlayer icon. That means it's
safe and really from Adobe. Download it onto the phone. And David used the package inside of it. And
here's a clear 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 and ID. Do you want to allow this application to
install? Why, yes, we do. 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. Setup is canceled. 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. They just
put a white 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 ‑‑ you can see the IP address. You can
see a DNS response. So 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. I will
mail you a Ninja Diary. I'm going to show you how to do this. I'm going to show you how to do this.
It's going to suck if you fix these protocol 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 cut off. FR something something. The rest is in the next packet. Okay. So here is
an HTTP post. This HTTP post message is the actual Stealth's command and control traffic. This
is what the phone home message looks like. This is what the phone home message looks like. This
is what it looks like when it's talking to the attacker's server in the Netherlands. So you can
see here PPP, Wireshark didn't dissect it. But you can see post slash data dot 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 alert on. You can just 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. So it sends a bunch of
information about itself. 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 ‑‑ here's the server's response. So the server is going to get this
post message and start sending commands in response. It's just a ‑‑ it's a very simple
thing. We actually ‑‑ there's no authentication here between the infected bot and the
server. We've seen malware more complex and we're seeing it more and more often. So 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 then talk to me again. And then it's telling it to wait
60 seconds. 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 this ‑‑ 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. 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. And we saw a corresponding alert to go along with it. So this is a little bit of a
surprise. 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. But the attacker could tell it wait a
month. And it wouldn't phone back for a month. And that would be a lot harder to do. So this is 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. So now Randy Price is going to talk about the device for
forensic analysis.
.
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 dissector.
The thing about the SMS is that it's there.
It's not encrypted, but it's encoded.
It's like reverse 7-byte or something.
Don't quote me on that, but yeah.
As far as the CNC, we'll get to that in just a second.
Okay.
After capturing traffic from the infected phones,
we conducted device forensic analysis.
The forensic analysis corroborated findings
from our network forensic analysis.
We took a physical extraction of the Samson illusion
with the Cellebrite UFED
after the phone had been infected in the testing lab.
Please note that the...
Okay.
Sorry.
Okay.
Please note...
Is that better?
Okay.
Please note that the infecting and the extraction
were done...
were performed with an RF-shielded test enclosure,
which is shown here.
Okay.
The Cellebrite physical analyzer was used to analyze the extraction.
The malware scanner identified four potentially malicious files,
which are shown here.
The Cellebrite malware scanner identified all of the suspicious files
as Android Trojan fake app cases.
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 Stealth malware reported in the Dell SecureWorks Stealth Android Trojan
malware analysis report.
We found a file called Stealth Settings XML,
which appeared to contain malware configuration settings.
As you can see from the configuration file,
each bot is assigned a specific 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 and control server
that instructs the bot where to phone home to.
The period value of 300 seconds, or five minutes,
is the initial phone home interval.
This tells the bot to phone home every five minutes.
Thank you.
All right.
Good morning, DEF CON.
Good morning.
I'm super stoked to see so many of you 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.
All right.
So because of the research that Randy did with the UFED, and we were able to determine
the way that Stealth is communicating back to its command and control server, we knew
that if we were going to use the UFED, we were going to use the UFED, we were going to use
the command and control server.
So we also knew that, you know, kind of what we were looking for.
So let's be a man in the middle.
When we wanted to do a man in the middle attack against this, 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.
And we were really looking at that port 80 traffic over HTTP.
Just to be sure.
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 Stealth is using,
you know, 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 Ubuntu 10.04 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 .0 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.
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 intercept, of course.
So what I saw was, I'm sure you had alluded to over 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.
Told it to wait 60.
I still sent the remove all SMS filters.
True.
And then I decided to wait.
Got 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 receives that 404 error, it does a timeout.
And then you have to wait five minutes until you can actually start communicating with it again.
So I was like, well, this is kind of troublesome.
It's going to take me way more time to do my research.
So instead, I just continued to keep intercepting all of the requests and telling it to wait 60
or wait five or wait 30, depending on what I was trying to do.
I did find out that when I tried to set it to wait two, wait five seconds, it would start going so fast
that it would eventually time out and then it would wait between five 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 can set an hour.
I found that pretty helpful.
So controlling stealth.
I wanted to see if we could actually tell it to export that data.
So I set that contact list from the device.
And sure enough, you can.
I just had to set 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 of 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 and 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 in an enterprise environment.
I don't know how many of you guys 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 that own their own device.
And now you can't actually gain access to 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.
Nice.
Thank you, Scott.
So that pretty much concludes our presentation.
As you saw, we were able to infect an Android phone with stealth just as a demonstration.
We detected the infection.
And the command and 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 femtocell, some kind of system, whether it's a laptop or a super old Dell Optiplex or whatever it is.
A hub or a 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 be tearing down.
We're going to tear down, and then we're going to move somewhere else.
So feel free to come visit us.
LMGsecurity.com slash blog.
Thank you.