 Okay, this one's porn to porn plug. Okay, I hope I said that right. Wesley, let's go. Give me a big hand. Thank you. So how many of y'all out there have been basically emptying the vendor area of all these crazy little devices? Pwn plugs, pineapples, I got to watch my peas. They've got this thing called a rutabaga now. Mini pwners, things like that. How many of y'all are going to be using those for good? How about for evil? All right, so there's definitely some people doing some bad things with these things and that's pretty cool. So what we have here is why those of you who are using these things for good and for evil might want to be a little more careful about when and where you turn these things on and how you use them. So the talk is porn to porn plug. Analyzing and counter-attacking attacker implanted devices. So the idea here is we're going to be breaking things that break things. My name is Wesley McGrew and I am essentially the elder statesman of the Mississippi State contingent here. Effectively I guess DC662. Mississippi State folks, make a little noise. All right, great, cool. So I'm an assistant research professor at Mississippi State University and also ironmcgrewsecurity.com and the McGrew Security Twitter account that you unfollowed last week. So what I do is I break things. I love breaking things and I'm occasionally good at it. So I'm into any kind of vulnerability analysis, any kind of exploit stuff. I don't care what it is, I want to find the problems with it. I'm into reverse engineering. I teach a reverse engineering class at Mississippi State University that went really well in the spring and I've also been involved in the National Forensics Training Center which teaches free digital forensics classes to law enforcement and wounded veterans. Recently I finished my dissertation. So I now have my Ph.D. for those of you who keep bugging me every year at DEF CON to finish that up. So that's prepared me for my new role as the 12th doctor. In the meantime, I'm a professor at Mississippi State University sort of leading the charge on doing some cool offensive breaking things type research. What we're going to be talking about today are attacker implantable devices and this is sort of a term I applied to a wide variety of things. There's a crisis of terminology for these things right now. The traditional name for these are a drop box and unfortunately there's a really bad name collision with that right now. The storage guys kind of took that one from us. But what I'm talking about are all these little kind of all in one embeddable type things that you can buy over there in the vendor area. Things like the PON plug, the power strip, the PON whatever they call that one now. The PON plug R2 that just got released that I haven't had my chance to get a hold of. PON pads. You've got these little TP link router devices like you see in the lower left there that can kind of run stripped down versions of open work. And finally the raspberry pies. So these new arms sort of credit card sized computers are perfect platforms for this sort of activity. So there's basically a PON OS type thing for the raspberry pie. I presume it's probably called the raspberry PON but I can't remember right now. So what these things have in common is they're small and they're what I call attacker implantable. Whether you're a pen tester or an attacker, you can take these and hide them pretty much anywhere in an organization. And you can use that as sort of your end. You can use it to sniff packets. You can use it to launch attacks from. And it's basically do it yourself pivot point in case you suck at fishing and things like that. So these things have applications for both penetration testers and malicious attackers. I'm sure all the folks that sell you these things want you to be a penetration tester but there's also something to be said for somebody maliciously using one of these things. So the question here, or one question if we're a good guy, how do we respond to one of these that we find in our organization? So we find a new toy in our server room that we did not purchase from Pony Express. And how did this get here? And who's running it? And what is it doing to my network? And also for both good and bad guys, what are the implications of there being vulnerabilities in these devices? So if I'm a penetration tester, what does it mean for my penetration testing tools to get attacked and compromised and persistent compromise over a long period of time? If I'm an organization that's found one of these that a malicious attacker has installed, can I counter-attack it? Why not? And assuming all the legal considerations are in order, you know, we don't have the same sort of problems with attribution of attack at this point. It's not like we're counter-attacking some random IP address somewhere else on the Internet and we don't know if that's a hot point or not. If there's a phone plug or some Raspberry Pi plugged up to our network inside our building that we don't know about, well, that's obviously something we can attack. Why not? I say why not? So this slide is basically on identification and I'm not going to go into all the different ways of identifying one of these on your network. Honestly, if you've got proper network access and control and monitoring in place and anything, you should see one of these things pop up the second it starts doing anything kind of noisy. Physically, they're meant to be sort of inconspicuous, but to the trained eye, it's not so much. So you look at these things and those are the two stickers that come with the phone plug one. And one of them has a reference to SSH on it and the other one is a printer power supply and I think that's the best application for the phone plug itself. It looks like a printer power supply, but part of its part number is 1337. So, okay. Actually, none of that look at this picture. I'm not sure what the bar code is. It's probably like for a pack of skittles or something. Who knows? So if you're going to be a pen tester using these things or even better if you're a malicious attacker using these things, print up your own stickers. Get an HP printer power supply and run that off on it. But if you find these things, that's calls for concern. So what do we do? We can respond to it. So the first thing here, and I just love this picture because Riker's hosting this thing. I forgot about that. First thing we want to do is pick this thing apart. What's going on with it? So we want to seize this thing. We want to image it. We want to forensic it. We want to figure out what is it compromised already if we can find that out. We want to attribute this to somebody. Is this somebody inside an organization that's trying to do their own sort of unauthorized pen test, but they've got good intentions? Is it somebody who's managed to sneak in? Do we have a physical security problem now, too? We want to know who's getting this sort of information back. And there's a good chance that with these devices that you can find, you know, where is this thing phoning home? Who's grabbing the data off of it? And it may not be in the logs immediately because these things are small and they're meant to not log a whole lot anyways. So maybe we have to sit there and wait until somebody actually tries to connect to it and get their data off of it. So the challenge here for forensics on these devices is essentially how. We know procedures for pulling the plug on a computer or taking a RAM image and imaging hard drive and things like that on a normal PC or Mac or something like that. But for an embedded device, do we know exactly how we're going to acquire a forensic image of this thing without inadvertently changing evidence or destroying the thing or what have you or breaking it, you know? So that's one concern is how do we do incident response on this? And another is if we decide to, how do we counterattack it? And so obviously if it's sitting in our organization, we can pull the plug on it and after we take our own forensic image of it, we blast your own image out to it that's backdoor to hell and back. And that's not too terribly hard. But what if we want to attack it in place? We don't want to remove power from it. We want to compromise this thing as somebody is using it. And that's the main meat of this talk. And so once we get into this thing, then we can monitor the attacker. We have a better chance at attribution. We have a better chance of determining the motive. I don't know about you, but I mean, it's okay to stop an attack, but I'd rather know who's trying to attack me and what are they trying to get at? What are they after? Because that can help me defend against them in the future. Essentially we can turn this device into a honeypot. It's the vulnerable system that they are in and trying to attack us from and we can monitor their actions from it. So for pen testers, the typical use case for this, there's two different use cases. One is the lazy pen tester who doesn't want to take a flight out and go in person and everything to do an internal behind the firewall pen test. Sends it out and says plug it into the network here, plug it into the network here, and sort of coordinates with the IT staff on this. And so that's one use case for this. And it's all set up, you know, plug in power, plug it in the network, it's ready to go, it phones home, it establishes an SSH connection, whatever. Then you have your nerdy James Bond type payload situation where this is somebody who's a little more sophisticated pen tester and actually has a physical component to his penetration test where he'll go in and he'll drop this device off surreptitiously in a network. And this is the same thing that an attacker is going to do is he wants to place this thing into a position on your network that gives him access without anybody knowing about it. These devices are typically reused from test to test, client to client, I don't know, but they probably emptied your wallet over there at the vendor area when you bought one of these things. So you're not leaving it anywhere permanently probably unless you're very malicious and you're profiting enough from one of these to buy 50 more. And so when you're using this thing, but most pen testers are going to want to pick this thing back up and use it on their next client's engagement. So between these tests, are you wiping it? Do you know how to wipe this thing? It's an embedded device. It's the cleanup procedure on it. It may not be completely obvious as it would be, you know, where you can just blow out a new installation of windows or something. It's probably a little more complex than that. And are you actually bothering to do that from client A to client B? And that, we can use that to our advantage when we attack these. From here on out, I'm basically going to take the stance of an attacker attacking pen testers because, come on, they deserve it, right? All right. So now we're going to put on our black hat. And this is the only free image of a cool looking black hat I could find on the image search. I like this guy. He looks cool. So you put on your black hat and we're going to talk about hacking a pen testers implantable device either in the field or on his bench. So the attack that I'm going to talk about in the PON plug here, it's fine and dandy if you see this on a client network and you can compromise it using this attack. But this attack can also be used if the pen tester is testing the device or provisioning the device for a new test on the bench in his lab getting ready for a penetration test. It's actually might be even a little bit easier due to the way that we do this attack. The benefits of an attacker doing this are great. So the implication of breaking into one of these devices and before I get any further, if you're running a Wi-Fi pineapple, you might want to turn that off here pretty soon unless you want it bricked. Because somebody in here is going to do it. And they're going to do it fast. The implications of owning one of these things is one, we can intercept things. So if a penetration tester is doing the work for you, he's scanning for vulnerability. He's breaking into systems. I don't have to do that now. So I just collect what that penetration tester is doing for me. And we can modify these results. So let's control what gets back to the penetration tester. He popped root on the database server. Cool. Let's not let him know that. And let's keep that for myself. And so we can filter these results. And it never shows up in the report to the client. And everything is cool. Yeah, that database is totally secure. We can camouflage ourselves. Maybe the pen tester sucks and he's not running all the attacks that you want him to run. Well, just launch your own attacks from the device. And the thing is supposed to be launching attacks. So nobody's going to care. And so your attacks are part of the test at this point. And it's also a competitive end tough. You've got a really clever pen tester that leverages some other day. You steal it. And essentially this is the gift that keeps on giving. You can do this again and again as he reuses that device across multiple clients. You can maintain access to these organizations. You can get back into the pen tester's company's network whenever he takes it back home and plugs it up again. Cool stuff. So there's difficulties in preventing this sort of thing. And the reason why these sorts of systems have these vulnerabilities is because they're very small platforms and they're running sort of off the shelf penetration testing tools. These tools are, I mean, attack tools are great. You know, people write, you know, quick Python script to leverage some particular vulnerability or some particular network attack or something like that. And it'll work. And so everybody starts using it. But the problem is as soon as it works, we're very fickle creatures. We get something working and then we move on to the next attack. So we don't exactly, you know, do a whole lot of testing. We don't really think of the attack surface of our tools. So if you think about penetration testing tools, you're connecting to all sorts of services that are not under your control. These services is, you know, implement protocols probably to a level that even your attack tool doesn't fully implement. You're pulling in data from lots of sources. You're parsing that data. You're parsing file formats. So your attack surface is essentially your entire code. If it didn't have to do with processing things from another service, your code wouldn't be doing it. So essentially a vulnerability in any part of your attack tool really opens up for you. Most of these tools are proof of concept tools. And that's always a disclaimer. That's always my disclaimer when I write a security tool is this is a proof of concept. I got it working and then I stopped. And I'm as guilty as this is anybody. So the disclaimer there is don't use this in a production setting. Don't use this in your production malicious attack, your production penetration test unless you fully understand implications of what you're doing and you can control it. But unfortunately these things are open source and folks who put together these small embedded attack appliances will take these open source tools, put them on the devices as is, and wrap a user interface around it and send it out. So there's no, at no point in this process is there any kind of audit of what are the vulnerabilities in these tools. These are very small, weird platforms. I mean arm is getting less and less weird, I guess. But these things are not, you know, these aren't PCs. These are outside of the comfort zone of a lot of the people who are using them. So once you get these tools running on that platform, then you just pray to God and you're like, all right, that's great. Let's just move on and do something else now. When you send these things out there out of your physical control, so obviously unless you're implementing some sort of encrypted file system on this thing and even then how would you do it? I mean, nobody, where's your key? You know, who's going to type in a key on this thing once it's out there? So it's hard to protect this thing once it's out of your physical control. We know, I mean, we have access to a computer, we have access to USB port we're in. And finally like the update procedure for these things. Once they work, they work. The chances of somebody, you know, actually seeking out between tests, the new firmware for their phone plug, the new firmware for their mini pointer or raspberry pointer or whatever, it's very slim. As long as this thing's working and doing the job, there's not a whole lot of chances they're going to think to go out there and look for it. So it needs, if you're going to do something like this, it needs to be an automated update procedure. But you can't have automatic updates on one of these devices out in the field. That'll be a whole new attack surface for me to talk about next year. So these things will run old code. And they'll run old code for a very long time. Security geeks are easy targets. So there's, there's, it's hard. There's another problem. I talked about the problem of the naming scheme for these types of devices, you know, Dropbox being taken. And so I'm going with the wordy attacker implantable devices. There's also a similar semantics problem with doing research on this problem. So if we're talking about finding vulnerabilities in vulnerability analysis software, that's a really tough thing to Google. Finding exploits in, in, in pen testing software, very, not, not exactly the easiest research area, but there's a lot of it out there and there's a lot more that's yet to be found. So I'm not sure who, who is currently working on breaking things that break things, but, but there's a lot left out there. You're already familiar with the million bojillion wire shark vulnerabilities out there. And that's very typical of this genre of software. We're talking about things that implement protocols, parse things, and have a huge attack surface. We have, you know, vulnerability, cross site scripting vulnerabilities in Metasploit. We have some screenshots of the titles of talks that are here at DEFCON and, and, and, and back at Black Hat this past weekend. So the tools that security geeks use are no less vulnerable, are perhaps even more vulnerable than the tools we're attacking because there just hasn't been enough attention and there's not been enough audit on the, on these tools. So the case study for this, and, and I'm picking on the poem plug for this, but honestly these same problems exist in, in other devices. I'll talk about that in a little bit. But, but today we're going to be playing with the poem plug. I have one plugged up underneath the podium here and wired up and everything and hopefully it'll behave itself long enough for a good demo at the end of this. What we have is a discussion of the forensics of it and a demo of a counter attack against this thing or a straight up attack against it depends on how you look at it. So for forensic acquisition of a poem plug, so this is what I do the first time I get a hole of any new devices. I want to know how to perform a forensic analysis of this thing which involves imaging it, which basically gives me something that I can go back to the original state of the device when I screw it up, when I attack it. So, so, so forensic acquisition is always something that I'm interested in. There's explicit detail on the white paper for this. I haven't looked at the DVD, my retina doesn't have a DVD drive on it, but the DVD that came with the conference materials has the white paper for this. It has these slides, it has all the attack code and payloads and all the crap that you need to do this stuff for your own. But the white paper has all the stuff about the forensics of this. So I'm not going to go into all the different U-boot commands and things like that, but the essential step for this is, the essential idea of this is that the, the poem plug, which is based off of the Shiva plug platform, so if you want to play around with these devices you can just buy a little $99 Shiva plug. Honestly nowadays you're better off of like a Raspberry Pi or something, but the idea is this Shiva plug hardware that the poem plug is based on can boot off of a USB drive if you ask it too nicely. Essentially you can grab a Debian image for Shiva plug and which will have everything you need to DD a drive. And more importantly you're not relying on the file system and tools that's already on the poem plug itself. You can, you can boot it up into the serial console, interrupt U-boot, tell it to load a kernel in a file system off the USB drive and go. And it'll boot up into your USB drive instead of the Shiva plug. And so you can play around with some alternate firmware for, for this thing without blowing away the, the base install on it too. But more importantly for forensics is you can DD the root file system once you get in there. Now it's just as, it turns out it's just as well on this device just a copy, you know, from root down since, since for the analysis of it you know the UBI file system that's on these devices and other similar compressed file systems are on a lot of these embedded devices. Our options for forensic analysis on these are kind of limited. So there's lots of compression on these. At any given point you don't necessarily know exactly how much free space you have. It depends on what you're storing really. The, the, the flip side of this for forensics is you can probably forget about recovering deleted files on this thing because the whole thing's part of this sort of compressed image and if you lose chunks of it, you know, you're, you're basically out of luck with the rest of, the rest of it is just noise. So there's really no tools for doing good forensic analysis that I know of it right now for recovering deleted files and things like that. But if you have the file system image which you can then blow out to another phone plug if you wanted to. So that's useful. You can use MTD Utils on, on Linux to, to mount this image and start processing it at the, at the logical file system level. You can go through and look at the files and things. These devices support attached storage and the storage on board most of them is fairly limited. So the nice thing about this is doing forensics on the little small USB drive that's hooked up to this thing. It's going to be a lot easier than doing the, the forensics on the device itself. And, and it's going to be standard procedures. You know, pop the thing out, hook it up to FTK manager through a right blocker if you please. And, and start analyzing. And chances are it's going to be a, a normal-ish file system. It's going to be EXT or FAT32 or something like that. And the cool thing is, is the stuff that's going to be on that, that's going to be the real goods there. That's going to be all your packet data and things like that that aren't necessarily feasible to store on the internal storage. The cool thing about these devices is that anything that's different from the base image, anything that's different from the base image on one of these poem plugs is likely to be of interest to you because it's something that's changed. It's something that's a result of the, the attacker using it or result of the tools that are running on it as a result of network traffic coming into it. So what you can do is you can take that file system that you've acquired and run it through FTK or whatever tools you have for making a known file hash set, hash all the files on the base image. You can download the base images off of Pony Express or whatever. So you have that hash set and you look at this file system and you blow away everything that matches the hashes in there. Well that's, that's, I don't care about that. That's the same as the factory config. Then the files that are left are the files that are going to tell you something. Cool stuff. Now we're going to get into attacking these things. We're going to put our black hat back firmly on and we're going to attack some penetration testers. The particular exploit that we're dealing with here is in the poem plug user interface. So congratulations for those of you who bought a Shiva plug and put the, the, the, the community version, the free version of the poem plug firmware on it. You're not vulnerable to this. This is only in the interface, the web based interface that's on the commercial versions that they, that they sell to you. So this plug UI or opponents, I've seen it called both things in different parts of the documentation. This user interface is a web interface for the commercial version of the poem plug. And it lets you do things like turning on passive recon. So you can sniff HTTP requests, look at the passive OS discovery stuff, set up the reverse tunnels and things like that. And, and so there's, there's all sorts of fun things that this interface can do. They tell you in the documentation to if you're going, when you put this thing into stealth mode, if you're going to have it in stealth mode in an organization, this interface isn't up and going. The problem is, is you can't do some of these cool graphical things. So, you know, a lot of people aren't going to put it in stealth mode. Who cares if it's noisy? Another thing is, is when you're setting it up on the bench back home, back at your lab or whatever, chances are you're going to be using this interface. So, how do we break it? So, we have a bunch of boring vulnerabilities. So yes, I did get a DEF CON talk accepted for cross-site scripting, you know. But these, these are very boring vulnerabilities. They're, they're easy vulnerabilities. So if you're not, if you haven't attacked much, you're going to, you're going to be able to follow this. We have three different vulnerabilities in this. We have some cross-site scripting, boring. We have some cross-site request forgery, that's everywhere. And sort of interesting, we have some command injection so we can run commands on this device. That's kind of cool. But you have to be logged in to do it. So who cares? But if we can bind these X points, let's say we, we'll say our cross-site scripting is, is triggered by an injected packet that we send to this thing. It doesn't have to be directly to it. It can be anything that sniffs. So we, we send a packet to this thing. So that's a cool way of triggering X, X, X. That's cool. Better than, you know, phishing emails or, or links on Twitter and things. What if our XSS payload triggers the cross-site request for, for, the cross-site request forgery vulnerability? So we have a, one page on the interface that's vulnerable to cross-site scripting. That payload hits another page that we can submit forms to on the behalf of our penetration tester. Cool. What does that get us? Well, our cross-site request forgery is in the page that has command injection. So why don't we have our cross-site request forgery vulnerability, our, our payload. Go ahead and inject the command for us on, again, on the behalf of the penetration tester that's logged in. As a result, we get remote route. So cross-site request for, cross-site scripting leading to remote route on this. And you know, it requires a little bit of setup. I mean, it has to be, you know, the star's line, but it's a pretty realistic scenario. And I'm going to make y'all watch that slide again because the animations are cool. Boom. Okay. Thank you. Thank you. It's all down to keynote on that. I didn't, you know, I didn't render that fire myself. So, so here's your, your payload. This is what you send in the exploit package of the device. This is what you're going to pass into, into HPE to get this thing rolling. So this part of it right here just passes the regex to get it, to get it onto the passive recon page. This is what it's looking for in a packet. You know, you might want to make something a little more believable than user agent high. This is the bit that you need to get cross-site scripting going on. Everything inside of that's going to render in the page and we'll see that in a bit. The cross-site request forgery in here, we've got a form in here and you've got a whole bunch of crap to fill out for this form to actually take. But we submit this to the SSH tunnel set up page on the phone plug interface. And it's, it goes ahead and submits it on the penetration tester's behalf. Then finally the command injections in there. And this can be in any field. These same vulnerabilities exist throughout this interface. So, so basically you can mutate this to go to basically any page on the phone plug. So, basically what we have here is the SSH tunnel IP address is now semi-colon, CD user bin, WGIT, my malware, run it, remove it and keep going. So what do we run as a result of this? So we're not, you know, we're not alerting XSS here. We're, we want to do something with this. So there's some proof of concept of, I see my disclaimer proof of concept. Don't run this in the real world or you'll get owned. My proof of concept malware is PONEMON. And it's not specific to this device. You cannot adapt this to anything. It's just a crappy little Python script. But it's a little bit better than alert 1, alert XSS. And then it cleans up a bit after itself. It installs itself into user bin, user S bin. It sets up some persistence in RSE local and CRON and all that crap to make sure that it keeps running. It sets up a log file so that it doesn't run more than once at a time. The PON plug specifically disables the bash history for the root user. I go ahead and re-enable that so I can keep up with command logs. And occasionally it phones home and tries to get more code to run. Because that's awesome. And every so often it gathers a process list, a command history, file listing, a set of network interfaces and connections. All the log files for the most interesting tools in the PONOS. And wraps it up and sends it to my FTP server. So this is something that you can kind of start from on this. So the demo for this, there's everything you need to replicate this on the DVD. You need a floor model or above PON plug, an actual commercial PON plug to replicate this from those guys at the vendor area. Tell them I sent you. Tell them if there's a patch for this to give you the old one so that you can play with this. Or just use an unsuspecting friend or enemies. So we're going to bounce out of here and hopefully this demo will work if not have a recording. All right, so what we have here is, and we'll take you on a tour of the different views here. What we have here is our hapless penetration tester setting this thing up. Over here we have our attacker basically with, you know, where he's launching the attack from and the web server, these hosting the stuff off the FTP and some info on what's going on here. The players that we have here are the PON plug on 10, the pentester slash victim on 15 and the attacker here on 20. And here we have basically a view on the code of the PON mon software in case I want to refer to anything for y'all. What we're going to do, first off, we're going to start up our attacker web server so that we have this. I'm going to show you what's in here right now. The UBI.py now, these UBI file names, since I had to do a bunch of research to figure out what the hell's going on in the UBI file system, I figure adding some more UBI named commands to this operating system is a good way of hiding my malware and that none of it makes sense anyway. We have UBI.py and UBI mount here. UBI.py is the PON mon malware. UBI mount is the file on the web server that PON mon occasionally pulls for new commands and I'll show you what's in that. Okay. You know, classic, you know, bind shell type crap here. We're going to host this web server. If you learn nothing else from this talk, you can set up a web server out of your current directory with just that command. And that's just tons of funds, beat setting up Apache or whatever. Don't, you know, run your blog off of it or anything. But payloads are great. So that just fires you up a web server on port 8000. Cool. Let's see. We're, the PON plug is still awake. That's good. We have our FTP dead drop here where it's going to go. And everything seems fine. So we're going to be the hapless penetration tester again. And we're going to turn on the under plug services here. We're going to turn on the passive recon stuff. Oh dear, we're already, I may have already triggered the vulnerability. That's cool. So he's going to enable this. And we're going to see here in a second whether or not that's actually, so we're enabled. We're going to see over here. It doesn't, it hasn't requested anything yet. So what we're going to do is we're going to, we have our exploit payload there, which I reviewed with you. And just a simple hpn command sends this out. And so there's a, there's a trick to this. We have, we're sending it ten times because it's kind of goofy. The, the passive recon page is pulling from a log file. And unless you send, unless there's a good bit of traffic on the network, it takes a bit for the buffers to flush and for it to actually show up in the page. So I just send it ten times. The exploit is set not to run more than once anyway. Sometimes we'll request two of them, but whatever. So we're going to blast that out. And while that's going, I'm going to set up inspect element on this guy right here so we can see it when it shows up. All right. So let's inspect right here. So what we see here is our, you know, cookie high form, all that crap going on there. So pretty soon we should see a request here and we have. So the cross-site scripting vulnerability has, come on, get me off the blue screen here, unhighlight all. All right. The, the, it has set up a standard reverse SSH shell of get all my crap. And that's scheduled to run every minute. And thankfully it's already run. Sometimes if you hit it wrong, I'd be standing here and have to tell you a joke or something before it actually does anything. But it's gotten the USB UBI mount script for code to run. It's already phoned in with a basically a tarred up image of all the cool crap on the polling plug. And so let's take a look at what we've got here. With the UBI mount, we should have a reverse shell running. So NC 192.168.9.10 on port. I think it was 9,000. Yep. Drum roll please. Root. I've always wanted to do that on stage at DEF CON. All right. So over here at our FTP dead drop, this is actually cool. Who cares about getting root? We want to get stuff. Loot. All right. So what we have here, and this is actually kind of funny, the phone plug isn't so hot on it's a real time clock or anything. So this is time stamped. So with Unix time stamps, and you'll notice I have the underscore and dash here, and I was like fucked up in my script and I have a dash in here also. No, that's a negative time stamp there. So my phone plug is lost at shit and we'll see what it thinks the time is. Oops. What? Oh, what? What's the hell's going on here? Oh, I see. It's already grabbed another one. Okay, we'll grab that one. Implausibly old time stamp 1946. We have defeated the Germans and now we're wrecking shit at Blout Street Park, I guess. So what we have in here, and you couldn't see it from that because it was complaining about the time stamps, is we have a listing of files, interfaces, logs from Metasploit, John Bluetooth, we've got the command histories and things like that on here. And everything on this device runs as root. So the web interface is running as root. So there was nothing to keep us from doing any of this. And that's about it. The whole thing is broken now. And it takes like 10 minutes to get everything back into a good state. So I'm glad that worked. So back to my slides wherever those are. And so for conclusions for this, these attacker and plan devices can provide good counter-intel info. If you found one of these in your organization as a defender, it's a curse, I suppose, depending on what they've already gotten. But you also have, you know that somebody was there that's against you. And also, you've got all the tools in front of you that are necessary to start counter-attacking this thing and doing forensics on it to figure out who is doing this to me and why and what are they after, what have they already got? For those of you who are pen testers out there, for those very few of you who actually said that you're going to use these devices for good, know your tools, test your tools, use them safely. Hell, if you're an attacker, do that. Monitor carefully and clean up between engagements and things like that. You need to be a little more literate with your penetration testing tools than simply using them. You need to understand how they work. You need to maybe even try breaking them every once in a while. And for breaking things, people who break things, pen testing tools make good targets. So with that, I appreciate y'all coming to my talk. There is no Q&A room, so you're just going to have to track me down before I go off and get bored and do something else.