This is my first time on stage at DEF CON not rapping so I'm a little bit nervous. This is
anti-forensics AF. When I would see Internet memes that were like that's silly AF or that's
stupid AF, I would read it as like that's silly anti-forensics. My name is Int 80, I'm the
rapper in dual core and this is the fourth anti-forensics talk that I've ever made. This is
the other three are online. I've presented it at Derby Con and stuff like that. So you can
watch them on YouTube. And here's some stuff we're going to talk about today. We're going to
start kind of where I left off with my previous anti-forensics talk and we'll talk about some
self-modifying code in memory for Windows executables. This is like coming from the
context of being an operator and being on a compromised system and you have malware in
place running and you're trying to prevent your malware from being acquired and analyzed.
Then we'll talk about some Android stuff. So I've got some Android forensics research that I've
done with my girlfriend and then also some anti-forensics and I'll probably win the award
for worst Def Con demo ever. And then I have some stuff with SD cards but I'm having display
issues with my Linux laptop. So if we can't get it to work, we will, I don't know, I'll be in
the vendor area afterwards so I'll be happy to show you guys some cool SD card tricks.
So I currently work on a red team and I get shells and write malware for a living and I come from a
reverse engineering background. So I've never done forensics professionally. So don't really take
my word for all of this. I mean it works but I'm not a forensics professional. I've had some
really interesting run ins with law enforcement and three letter agencies and I'd be happy to talk
about my trolling of certain agencies like the FBI and the NSA in some other time when I have a
drink in my hand or something like that. So if you want to find me after the talk, I can tell you
some fun stories. Again, I'm not an expert. I just like to try stupid things on computers and see
what happens. And so your mileage may vary but I'm sure you guys are all way smarter than I am and
can come up with way cooler and more technical things. And then the last part is kind of a
commentary on our current legal system. And I'm going to talk a little bit about the
legal system. Every cool thing I know how to do with computers is illegal. And so I've learned to
do cool things with computers by doing illegal things. So I highly recommend doing illegal
things. All right. Cool. So we've all known for the past like decade or so memory
forensics is the new hotness, right? You can get all the good stuff out of RAM. And so again the
context here is like you're an operator. You're an attacker. You're on a system. You've got a lot of
malware running. You've got an implant. So you've got persistence. But it's expensive to build a
tool chain, right? So you don't want to get your malware caught. You don't want it to be
analyzed. You don't want IOCs to be coming out about your malware. You don't want it to be
detected. So the whole goal is to keep our malware running on a system and thwart either
acquisition and or analysis. And so in the previous talk I've done some tampering for the
acquisition side. And this one we'll look at the analysis side with a little bit of acquisition.
Like I said, cool stuff happens in memory. But we kind of take advantage of this, right? The
analysis tools, they need all of the data about your malware in order to be successful in
analyzing what you've coded. And so we don't need all of those sections once we're loaded in
memory. So we can tamper them or remove them or whatever. And therefore our execution still
continues. We persist as operators on our target environment. But analysts lose and can't
analyze our malware. And so it's great. We can basically just, like I said, either modify or
remove bytes and the analysis tools can't do their job. So this first demo is a POC that I wrote
called the keys are like right next to each other. And it's kind of a throwback to the bash
dot org quote. It's a common typo. The keys are like right next to each other. All right. Here we
go. Okay. Everybody see that okay? Like text is big enough? Cool.
All right. Awesome. All right. So I have a malware sample that I wrote called the keys are
like right next to each other. So it's running. All right. We can see that it's executing.
Everything's good. Let's do an acquisition of memory. So I'm using recall which is an open
source framework published by Google. You can grab it off of their GitHub. First of all, we're
going to do is acquire memory and we're going to put it in this file called lol.afm. So this is a
FF4. And you can name it whatever you want. I just think it's funny so. I should have
like a how to basic video in here somewhere probably. How many people are coming to the
DEF CON party tonight? Awesome. I'll be rapping at 1.30 headlining so I'll see you all
there. How many people have heard the song drink all the booze, hack all the things?
Many times. That is exactly how many album sales we have. Wow. Thank you, guys.
All right. I thought RAM was supposed to be fast. How many people first year at DEF CON?
Nice. Thank you for coming. How many people 24,
year at DEF CON? Nice. Why did I do a 64 bit VM? All right. Well, while that's going,
this is what the malware looks like loaded from disk. This is statically loaded. The keys are
like right next to each other in IDA. You get a nice call graph. You see all the subs. We can
do strings.
All right. We can see all this cool stuff. Everything looks good, right? There's no real
complaints here. But yes. Okay. Cool. We finished our acquisition. So now let's get that
malware. Again, malware is still running. So. All right. All right. All right. All right.
So we run it. It's damn perfect. So we need to land it here. All right. All right. I made another
All right. So this basically gives you, like, an I Python notebook for your work space in
recall. And it's really nice. It's basically Python and you can get tab completion. So let's
dump out this binary. We don't even have to know the PID. We can just say the keys. And oh, my god.
a dump directory. I'll just put it right on the desktop. So it's dumping it out of the
acquired RAM image now. Cool. And so there we go. We got it dumped. PID 4792. Here's our
executable. 4792. Loaded NIDA. Hmm. Doesn't know what to make of it. Guesses
it's an MS-DOS com file. Let's see what it says. That does not look the same. And so you
notice it doesn't even know the segment names. These instructions don't look legit and then we
have just a bunch of bytes. So but now we're still running, right? So what does this look
like on like for the code?
This is C++ file. 63 lines. Not including comments. And or including comments. So all we do is
resolve our way into finding the header in memory. And once we recognize like yep, we found our
header, our executable header. We call virtual protect. So we can set the write bit for
permissions on the page for the header. And then we zero out the memory. With this call to RTL zero
memory. It's been a while. So we have to keep going. So this is a, we have to keep going. So we
basically just memset underneath the hood but what you end up with is losing all of the data
structure about your portable executable at that point, right? The whole thing is gone. We
reset the permissions back with virtual protect and just in this case POC just loops and
that's it. So you know pretty simple but beats the analysis tools so our malware persists
hasn't been analyzed. You know you could go through here and try to like you know hit
C and IDA see if you can figure out like you know is this code? Is this code? Right it's not
data is it code? And maybe get some disassembly of the instructions but it's going to be a
pain in the butt and I also don't know any forensics investigators that even have IDA
installed to begin with. So I don't know. I'm hedging my bets. My threat model looks like
that. Cool. Uh let's see I can actually show you guys the hex editor too. This is
what it looks like in the hex editor. So much zeros. Right where is the original in the hex
editor? Looks like a normal Windows executable file. So pretty neat. But if you want to take this
further you can do some interesting things to throw off the analysis tools right like two of my
friends Richard Wartell from Palo Alto Networks and Craig Smith from OpenGarages independently
suggested to me like rewriting a new PE header. So I don't know if you guys have ever seen
something like tiny PE where you could write like a new executable into like part of the memory
space and uh you know might throw the analysts off by a lot. They'd be like oh it's just tiny
PE even though it's you know a 10K file or something like that. Um you can do uh other
things like uh modify values in the header and uh you can get some interesting results aka
crashes with analysis tools if uh if any of you are so inclined to research that particular
vector. Alright. Uh any any questions on what we did with the keys are like right next to each
other for Windows? Cool. So the whole reason this works is in order to get from on disk to in
memory you need your PE header so you can load and navigate all the data structures and get
everything loaded. Um but once we're in memory we don't need the PE header anymore right? We
don't we don't need to reference back into there uh into that section. We are
code is executing we're good to go. So in this case we just zero the memory and we're still
running. We don't we don't need to reference the section header but the analysis tools failed.
And so in the previous anti-forensics talk I demoed this in Windows XP uh before it was end of
life and here I demoed it in Windows 10. Still works. Uh for completeness in case you guys
want to take pictures of the slides or anything like that I mean I guess they're on the CD too
but I don't know anybody that has a CD drive. By default they're on the CD drive. I don't know
anybody that has a dual core CD's. Uh this is this is what we ran. Alright uh so then
then you know the next question is well will it run in Linux? Usually the question is will it
run Linux but it's an Intel chip so it'll run Linux.
Alright. Alright cool. So uh here I've got uh you know Linux port of the code. Uh the keys
are like right next to each other. We're running. This is just some debugging output.
Alright cool so let's get RAM and Linux.
Sorry I made this talk a bit ago and I'm really forgetful because context switching so I have
all my notes here. Alright. So uh to acquire RAM in Linux uh you know in Windows we use recall,
uh we're gonna use LIME which is an open source tool published by the 504nsx guys. You can
grab this off of GitHub as well and once you build it, it um it shows up as a kernel module. So in
in this case it's this line generic dash KO which matches the version number of your Linux
kernel. And we'll specify a path to dump it out to. So great all we're doing is just loading
this kernel module and it's going to acquire RAM for us. Are you kidding me? Oh maybe I
didn't build it. All right let's build it. I really didn't know what was going to
happen there. All right that one worked. All right so. I'm going to go ahead and
build it. Great we have a memory acquisition. Let's check it out with volatility. Oh god I
hope this works too. All right so. This is a volatility is by the volatility foundation open
source framework written in Python. Does a lot of cool stuff. One thing I'll go over with
more verbosity in the slides is building volatility for.
Your Linux setup. It by default it doesn't come ready to run on Linux. But it's pretty
straightforward to get it to get it going. So let's. Let's take a look at our memory
acquisition here. All right first let's find our PID. These are all just modules that
weren't there before. So we're going to go ahead and create our PID. So we're going to go
ahead and install it. Oh god. Oh there it is. All right. 9801. And just to confirm. Yep we're
still still running. Still doing evil stuff. It's false advertising by the way. It's just
printing. It's pretty evil. Okay. So looks looks like it dumped right. So we're going to go ahead and
install it. Outside of the module modules that it tried to load. Everything else is fine. No
complaints. Right? We're good to go. For 400,000 hex looks like a solid base address for
standard Linux image. So let's take a look. There it is. Okay cool. So here's our process
dumped out of memory. Oh that's weird it's empty. Sweet. We won. Zero file size. Okay. So
couldn't, forensics investigator, can't get our malware out of memory. Good job, us.
Let's take a look at what this one looks like. So it's pretty much the same thing, little
extra debugging output. This code right here, lines 16 through 20 is bad and I should feel
bad. I'm literally like taking a shortcut to, I'm using F scan F and reading out of the
proc maps to find the header in memory. There's probably an actual legit way to do this but I'm
lazy and this worked. Cool, so we find the header just like we did in the Windows version. In
this case instead of virtual protect we call mprotect. Again setting permissions for both
read write, all three, read write and execute. Then we call memset, zero out the
header in memory and call mprotect again to restore the original permissions. So if you caught
this right at the moment that the overwrite was happening it might look weird seeing the header
with all three read write execute permissions but if you catch it afterwards, which you will
maybe, then you'll see it look like normal with only read and execute. And then this is just
more debug output and here we go, just infinitely looping doing evil stuff. So that's all it
takes.
Hack the planet. Cool, so we did get an acquisition with Lime. We didn't tamper the
acquisition too much but we ended up not being able to extract the actual binary with volatility.
So good job. This works for the same reason that the Windows one works. We don't need the
executable header, right? So Windows uses portable executable or PE and Linux uses ELF which I
don't know what it stands for but who cares. And we do the same thing, we zero the header and since
we don't need it once we're in memory, it continues to run but the analysis tools fail. So
this was my, this was my win on the fly. I successfully built Lime with a make command. Good
job me. The real bread and butter here is the insmod. So inserting the kernel module and
pointing it at the output path and giving it the format. This is the volatility stuff. So if you
want to install it straight out of their GitHub. Just do a git clone. Python setup.py install.
Pretty normal. Although I always forget that if I don't do it. Like if I always use pip for a
while. And I'm like wait how do I do this manually? That's why I put that line in there. And
then this is building the Linux profile, right? Like I said, volatility out of the box is not
going to work on a Linux VM or a Linux server but this is the initial setup that I want to use. So
system so you need to build a profile for the actual system that you're going to be
acquiring the RAM from. So you'll go into this tools Linux subdirectory in the volatility
directory, run make and then it will create this module.dwarf file and if you run head
on it the first line you should see should be .debug info and that will tell you that
you did a good job. And I think all of this is in their GitHub anyways.
And then once you've built the module.dwarf file you copy it into the volatility file
system where it wants it and then you can verify that you've got it by running that first
volatility command that I ran and grepping for Linux and that will tell you that you've got a
profile for Linux now. Then we did PS list to find our process ID and then we did proc dump
and that tries to dump out the image of our malware and fails. All right. Android stuff.
Before I get started on the Android stuff I will say that none of this addresses any of the
Qualcomm trust zone issues or like the deriving the hardware encryption key from that. The
premise is in my threat model I'm not going up against somebody that or I'm not going up against
the people that I might be going up against don't care about me enough that they're going to
send my Android device off to Israel for cracking. So. All right. Cool. So also use Tor, use
signal for those that follow the gruck on Twitter. I'm planning Thanksgiving. Use Tor, use
signal. I'm planning Thanksgiving. I'm planning Thanksgiving. I'm planning Thanksgiving. I'm
set first. Mic drop. We're going to have something like toll-free Thanksgiving.
I like that one because I' vaII texture till nuts. The re
tweet in here is I want to eat a pint of Jerry Garcia icecream. Should
I use a bull or not? Use Tor, use signal. This one is selling social security
numbers for Bitcoin. Please contact me on my XMPP we'll discuss further. Use Tor, use signal.
Okay. I'm really sorry. I'm just going to say it. I've had like this research for a while
and really the only reason I made this talk is not the format for screaming goats in slide
transitions was hilarious. So I'm so sorry to everybody. Okay. So this whole
premise of Android stuff is all about using encryption, right? And so to understand why using
encryption is so important for your Android device, we're going to talk about the acquisition
and analysis process of Android forensics first. TLDR, it sucks. Okay. So Android forensics is
not the easiest thing. Anybody here done Android forensics? A few people. Nice. All right. So
this is the way that my girlfriend and I figured out how to do it. If you've got like flashy
hardware and budget and stuff like that, it's probably way easier. But you have all these
like blockers in place that you need to work in order for your kill chain to be successful. So if
you want RAM, you have to be running an Android kernel or a Linux kernel that allows loadable
kernel modules. Because you can use LIME to acquire RAM on Android as well. But all of the Android
devices I looked at, none of them have a kernel that allows loadable kernel modules. Which I
mean, is good. From my personal usage I wouldn't want that, right? So you're probably going to lose
at memory forensics right off the bat. The way we did acquisition was by cross compiling Net Cat
for ARM and then placing it onto the device, which already you're, you know, if you do
traditional forensics, you're only read only, right? Your method is read only. So you're
already writing on to the device that you're going to be doing read-only in. And so you're
read only from. And then there's a bunch of different interfaces that get exposed based on
your build of Android. So in order for successful acquisition of RAM you need the device to be
powered on, the device to be decrypted, unlocked, rooted and USB debugging. That's if you
want a full physical acquisition of the NAND storage. So guess what? If you're encrypted then
you already killed them at the second step. And then if you want RAM acquisition you need
the lovedable kernel modules.
Okay. So this is kind of the verbose like notes on doing Android forensics. Once you've attached
your device to your acquisition machine you can run ADB devices and that will show you a list
of Android devices. You can run the Visible version of the NAND server, the NAND server, the
that are attached. Then once you've got your cross compiled netcat binary, you push it up onto
the Android device, so that's just ADB push. And then you set up a listener. This is like the
weirdest thing I've ever seen in forensics. So you're forwarding all of the acquired data over
a TCP listener on in this case port 4444. And if you're playing a drinking game and you had a
drink on the word four, you'd be in a lot of trouble right there. Then you spawn a shell,
call SU, that's the part of the device being rooted. Copy the netcat binary over into dev NC and
change mode it for executable bits. And then you do a DD. We're all familiar with DD, so
that's fine, nothing crazy there. But you pipe it into netcat over your listener and then you
acquire it over the netcat connection. It's all USB, right? It's not like going out over the
air or anything like that. It just seems like such a weird set up. And then shot to you
55.
56 on it and make a backup copy and shot to you 56 on the backup copy.
Goat simulator. Okay, so one of the weird things that I found, my girlfriend and I found
during our research on Android forensics was you'll find the NAND exposed by different
interfaces. So if you look in partitions, that will tell you where you can acquire from. But
I've seen it under these ones that are listed. Dev block MMC block, dev MTD MTD, dev MTD block,
dev EMMC. And I was being clever there with that C++, no comment. Dad jokes.
That's if you want physical acquisition. If you want your own and then you can get the
want logical acquisition it's way easier. You don't need root necessarily. You can just plug
the device up. You'll need USB debugging enabled but you can just do an ADB pull. There's
like a bunch of facilities that are available via ADB and the Android SDK that you can
acquire data off of a target Android device. I thought the ADB backup one was kind of
interesting because it creates this like jar file and you have to put a pin in for it. If
there's like a pin on the device I think and that then exposes your pin in the bash
history if you were maybe targeting the forensic investigator. I don't know.
More stuff, dump state, like all of these things get you different pieces of data about the
device like radio history, location history, stuff like that. There's also a tool out there
called AFLogical OSE and it's an open source edition. It's pretty nice. Can get you a good
acquisition of data as well. I think there's a law enforcement edition. So if you're
wanted to impersonate a law officer you could try to get a copy of that or be a law
enforcement officer. Didn't even think about that second part. So yeah, so basically like
you know, it takes all that stuff just to get an acquisition. It sucks. And you know, you're
writing a netcat binary onto the device. You have to be able to justify all the changes that
have happened to the device. So it's, you're violating the traditional forensics methodology.
And yeah, all this stuff is easy to do. So yeah, I think that's pretty cool. I think it's a good
a lot of info that comes up about how you can use data science for your device, it's easy to
disrupt. We've got that super long kill chain. If the device powers off, it's over. If it's
encrypted, it's over. If USB debugging is not enabled and you can't get it unlocked, it's
over. That's not even a goat. All right. So use encryption, right? And here's some like example
scenarios that I thought were applicable. So number one, if you're out operating and you're, or
you're freedom fighting as DeGraw calls it. You're not going to bring your personal phone with you.
You're not going to bring your personal device with you. So if you're not operating or getting your
device, right? So you leave it at home. But what if you're out freedom fighting and you get
raided by law enforcement while you're out? You don't want them to acquire all the evidence
off of your device. Also, like, I may or may not know people that build hardware implants
for Android devices and deploy them while operating. And so, you know, if your implant gets
found by a blue team or somebody else that's not meant to find it, you don't want them to
acquire whatever evidence you've acquired while operating. And then how many people here know
CoS? So CoS has a penchant for smashing cell phones. And initially, I put this in as a shrug,
but when I looked at it in the context of Android, it looks like an ASCII CoS throwing a
cell phone on the ground. . All right. Cool. So my thought was if I'm leaving an Android
device somewhere and it's got full disk encryption and it's running and it gets acquired by
somebody that I don't know, I'm going to want to use it. I'm going to want to look at the
don't want to acquire it. All I really need to do is just turn off the device. It's powered
off. Everything is encrypted at rest. I win. Kill chain is broken. Forensic investigator
get nothing. And then, of course, lawyer up and that's after you've deleted Facebook and hit
the gym. Oh, before, actually, while you're up first. Okay, cool. So you have all these
like awesome sensors available to you in your Android device, right? You've got Bluetooth,
cellular, et cetera. So my thought was, you know, you could pair to a Bluetooth device in
your house. And if all of a sudden the device becomes unpaired, turn the phone off. Now it's
encrypted, right? So FBI comes, they put your device in a Faraday bag, you become unpaired or
you go off the cell network, right? Turn the phone off. Encrypted. Set a geofence, if it
wanders outside of the geofence using the GPS, turn it off. Must have walked away on its
own. So, yeah.
Okay.
So I'm just leveraging the facilities available to me in the Android device.
So I wrote this tool called duck the police. And it's just an Android app and I suck at
programming, as you can probably tell from the other source codes. It's not amazing, but it
does turn the phone off. So, yeah. So here's the Android device. I'm going to show you
the first step. So, here's my entry for the worst DEF CON demo ever. So you'll just kind of
have to take my word for it. So I've got my duck the police app here with a dolan icon.
And I select movement and I duck the police. There we go. And I set my phone down, and I pick
it up and it's off and it's encrypted now. So now law enforcement gets no evidence off of my
device. That was the easiest solution I could come up with and like right at the top of my
coding capacity. And this was the only meme I could find that said duck the police on it.
And these were my next best ones.
That one I love because a former co-worker of mine, he was like, oh, yeah, you know, like I can
pick the boots on cars. I can pick the lock on those. He's like, the police charge $125 to take
them off. I charge $75. So much chaos on the internet.
So, yeah, so that's like my Android stuff. And, again, like those are my ideas for
scenarios, but the device turns off and now all of your evidence is encrypted and, again, not
taking into consideration the trust zone and Qualcomm trust zone stuff. All right, so I was
going to play CTF with you guys, but, unfortunately, demo gods are not with me on the
display for my Linux laptop. So I'm happy to demo this. I'm going to be ‑‑ I'm vending with
Hack 5. They're the bros in the vendor area that have the huge pineapple. So if you want to come
by or find me some other time during the conference, I can show you this in person. But
basically this is like some cool stuff that Craig Smith from OpenGraduals put me on to with
SD cards. And this was to prevent me from going too far in the slides before showing the answers.
Whoa! . But basically the CTF setup is I have an SD card in my laptop and
it's got a text file on it and you cat the text file and it says the rules are simple, just add
your name, unmount the SD card, remove it from the laptop, plug it back in and verify that
your name is still there. And what ends up happening is you can, you know, mount the SD card,
write append on to the text file, you mount it, no complaints at all, you remove the SD card,
you put it back in and your name is not there. And so the CTF is like we go back and forth,
like what would you try? Like people are like try like change mode 0000, you know, like all
zeros, no read, no write, no execute bits. That doesn't work. Try change attribute, you know,
make it plus A or plus I. That doesn't work. And so what it is is actually a modification in
working with the firmware on the SD card. So there's an open source tool called SDTool. And
what it can do is lock and unlock the device. And this is aside from the physical lock that's on
the device. And so the rights all happen in memory. So to the underlying OS everything looks
good. Everything is fine. But then below that the firmware to the SD card is not preventing or
is preventing or not allowing the rights on to the actual storage. So as we all say, no logs,
no crime. And so it's pretty neat. There's a couple of caveats. So like if you've got a
USB hub, it may not work. It might expose it as like a mass storage device. But if you have a
direct MMC device, it should work. You might need to go through different SD card cages, but one
of them should work. And example scenarios where I thought this would be good, also like building
your own hardware implants using running off of an SD card. Anybody that's done like Portal of Pi or
anything similar to that, you can do the same since it's Raspberry Pi running off an SD card. And
if you make your like attack infrastructure, attack VMs running off of SD cards, none of your
logs get written to the storage. That's kind of neat. I still don't know what this, what is
that? How many people have seen this ladder goat? Get up there. Oh, you.
Ladder goat. You're so random. This is how you use SD tool. You just basically, once you build it,
point it at the MMC device and then you can get the status or lock and unlock it. Quick note, I
switched my make file to use Clang instead of GCC. GCC gave me errors, but Clang was able to
build okay.
I must have called a thousand times to tell a new story.