 So thanks for coming out on a Sunday afternoon here at DEF CON and today I'm going to talk a little bit about mouse jigglers and defense and a little bit of offense as well. So what's this talk about anyway? Why should you be here or some of you might be in your hotel room watching this? Mouse jigglers are now a common item in a toolkit for many law enforcement organizations and also for people who like to come and grab your stuff. And if you're using full disk encryption, which you should be using, it's kind of worthless if you're actually logged into your computer. So the other reasons that this might be interesting is if you want to build your own mouse jiggler, it can be kind of fun. Just a little bit about me. This is my seventh DEF CON talk in the last five years. So you've seen me around and you think he looks familiar. Also a funny story. I have a film credit. I'm on IMDB for the DEF CON documentary as the professor. I was in the elevator the other day with someone who is also credit as the student and someone recognizing like you look familiar to me for some reason. So I teach digital forensics and security at a university. That's my day job. Also a harbor hacker. Been known to write a few books. Just released a very small book on Windows forensics. Last year we released a Linux forensics book and a couple of years before that I released this book on hacking with low power devices. So yeah, I mean this is the small book. So what's this talk about? Well, first of all, you don't want to be like this guy. This FBI is knocking on his door. And he's thinking, oh shit, right? So what is he doing? He's running to all of his computers and he's launching a nice little deletion process. He's grabbing drives, throwing them in the toaster. He's putting CDs in the microwave. And here's my favorite part. He's getting these huge magnets and he's deleting his hard drives. And now he pretends like, hey, what's going on guys? So you don't want to be like this guy for a couple of reasons. Number one, what this guy just did is called obstruction of justice. And it kind of gets you into a bad place, right? The other thing is, as much as it looks really cool when you're going across all your hard drives with magnets, it doesn't really work, okay? Those suckers would have to be super powerful. But it's Hollywood. So what is a mouse jiggler anyway? You know, it does sound a little dirty. A lot of people are like, ooh, that sounds like an edgy talk. You're giving this year, Phil. But it's simply something that's used to keep a computer awake and unlocked. It can be used as a prank. Anything can be used as a prank, right? And there are two basic types. You have your software jigglers. That's not what we're going to talk about. And then you have your hardware jigglers. And that's what you've got to be worried about. So I've got a couple of pictures here of two very common mouse jigglers that might be in somebody's toolkit. So we're going to talk about how do you detect these? What sort of things could you do? Just simple stuff in order to defend yourself. So when it comes to detecting a mouse jiggler, you could use a known vendor ID and product ID. Now it turns out there's pretty much one company that makes these. And their vendor ID is 0E90. And their product IDs, the most common ones are 2-8 and 4-5. But honestly, this company makes forensic stuff. So if anything from their company is plugged into your computer, it's probably a good idea to do something about it, all right? You can also detect behavior. What if somebody listens to this talking, they're like, well, I'll just make my own. So we'll talk about how you can detect that. And also you could just do things based on a device class. Any kind of device that could be a jiggler do something. So the easiest detection is detection by a known vid-pid combination, known vendor ID and product ID. So since there's a single manufacturer, this is super easy, right? And the nice thing about it is very quick. You can immediately detect it. Some of the other things we'll talk about are not as quick. You have to analyze stuff for a little bit. It's very easy. And it's definite. You're like, okay, it was definitely one of these devices. It's not like I think it was. So how do we do this? Well, we use UDev rules. How many of you are familiar with UDev rules? All right. Just a few of you. So UDev rules are kind of like the new thing. I see the new thing. They're not super new. I think like in the last 10 years or so. But for Linux, it's been around forever. That's new. And they determine what happens when your new device is attached to your computer. And they have a set of matching conditions. And you can use them to launch various scripts. Now, one caveat is if you launch a script, it should return right away. Otherwise, bad things happen on your computer. You don't want to launch a script that says, let me spend five minutes analyzing this device to figure out if it's a mouse jiggler because you can't install any other USB devices in that time. And it's going to kind of suck. All right. So here's an example of a UDev rule. This one will detect a known mouse jiggler. And if you look at the rules, normally they're set in Etsy UDev rules.d. And you just create a simple text file with a bunch of rules. I believe you have to mark it executable. But other than that, there's no real requirements. Normally we name these rules with a number and then a dash. And then it's name and it should end in dot rules. Now, the reason we use the numbers is these things are executed in alphabetical order. So you might have something that definitely has to run right away or should run after other things. So that's how we handle that. We just use a different number. So in this case, I use 10, which is appropriate for this particular thing. All right. So then here's my rule. My rule just says action double equals add. So a double equals if you've ever programmed in C, C plus plus, etc. You know means this is equal to not please assign something to this. Right. And the same is true with UDev rules. So it says if the action equals add, you just plugged in a device. And the vendor is zero e nine zero, which is the known vendor ID. Then to your list of scripts to run, please add. That's what the run plus equals this. So it says at C UDev scripts lock screen dot sh. Right. So in this case, the first thing I'm going to do is just lock this screen. Right. You know, what was the goal of mouse jiggler? Don't let your screen lock. Right. You plug it into my computer. It instantly locks. Sorry. But now when you change these rules, you have to restart the UDev service. So that's why I have the little notes is don't forget to run pseudo service UDev restart. Right. Let me back up for just one second. So you see here where it says atters with an s ID vendor equals equals zero e nine zero. What that is about is that you can detect the device. Now when you plug in a device, USB devices are layered. Right. There are device. They could be a composite device. And so you say when I add an s to any of these matching items, that means if anywhere in the chain, you know, my parents, anybody has this vendor ID for this device or part of it in this tree structure that's going to get loaded, please match it. Right. So that's why it's important to add the s in there. If anyone's wondering, you can also detect a mouse jiggler based on behavior. So what do they do? They periodically make small mouse movements. Now the prank version, which you can buy doesn't make just small movements. In periodically, it just like it makes your machine unusable. So this is something you can prank your friends with. Although honestly, it's like if you have physical access to your friends machine, there's a lot more fun things you could do, but they do sell this device. I don't think your typical law enforcement person is going to have this in their toolkit because they couldn't use your machine anyway. And then there's a forensic version. The forensic version has a much longer period, usually around half a minute to a minute. Sometimes they're randomized depending which version you buy. So what you can do is you can detect these periodic mouse movements. Now the other thing that's a little bit unusual about these devices is that they normally have no clicks. Right. Why don't they have any clicks because that could screw you up. Right. If you're working on something, if the mouse moves a little bit at whatever, but if the mouse is moving and clicking like you might do in the prank version, that's a problem. So another thing that we can detect normally, these mice are two button mice. So they're two button mice that are not very used to click on anything and they move in predictable ways. So if you think that you might have a mouse jiggler, you should probably immediately apply some sort of benign defense, you know, something like locking your screen. Yeah, it could be a pain if every time you plugged in a possible jiggler, the screen lock, but so what? I mean, that's how often you plug in a mouse or keyboard, things like that, because this will take a couple of minutes. So here's the Udev rule for that. And again, this is another file stored in at C Udev rules dot D. And the action is add again. And it says, Oh, you just add in anything. Right. So I'm going to be super cautious. I'm not going to check the vendor ID or anything like that. I'm just going to say you added something. So please add to your list of things to run this little script. It's a detection script. And I'm going to pass it two parameters, the bus number and the device number. You'll notice that there's also an ampersand added to the end, because I said you shouldn't have long running scripts. And I just said this might take a couple minutes to run, right? So you don't want this running and clogging up your Udev system. So once you've added this simple rule, remember, you need to restart Udev with pseudo service Udev restart. And then you can go on to the script. So that's detection script uses something called USB hid dump. And this will dump hid reports hid if you're not familiar, stands for human interface device. So there are a class of USB device, you have keyboards, you have mice, you have joysticks. Basically, a hid is anything that connects a human to your computer. So this script has to be run with root privileges, which it will be if it's run by the Udev system. And it relies on the no click behavior, among some other things. So here I have a little screenshot. Hopefully, you can kind of see that this is a couple of reports from a mouse, like a proper mouse. And you'll notice that this mouse has I think something like 15 buttons on it, and a couple of axes. In general, normally a mouse report like this will start with a bite or bites for the buttons. So each button gets a bit. So you can have eight buttons per bite, if you will. And then you'll have the various axes. So this is a really nice mouse that has got, you know, scroll bars and all all kinds of stuff on it. So it's a bit longer of a report. So here's the script itself. And it starts out with the standard shebang bin bash just to make sure that it's running the bash shell. And I have I have some stuff in this script that obviously if it's being run as a non interactive process, it's printing stuff to the terminal, which you'll never see. But you can also run it separately. That's just why they're for debugging. So yeah, normally you don't need a usage function in your scripts that run. But so I define a little usage function. And then I check and say, Hey, did you give me enough parameters? Remember, I need the the bus and the device number. And then I first do a check for the standard El Chippo mouse jiggler that Emily it's a two button mouse. So what I do is I look at the address. So I get the address I use printf in order to format that. So you might recognize that statement where I say device address equals, let's see. See if I can successfully cursor over there. Yeah, here. Right. And I'm using a little trick that some of you might be aware of already. In bash shell scripting, you can run any command, and then take the results from that command and use it to set a variable by enclosing that command in parentheses, and proceeding those parentheses with a dollar sign. So here, I've said, please run the command printf. And I have a format string. And that format string just says, please give me zero padded three byte decimal numbers separated by colon. And then I give it dollar sign one and dollar sign two, which were the two arguments passed into the script. And then I get a report, I use that same trick, my dollar sign parentheses, and I call timeout one second. Timeout if you haven't used it, it just runs whatever you give it for how long you say, and then it kills the process. So I run usb hid dump, and I give it that address. And I'll give it another parameter dash es, which says, please give me the streams, not just the descriptors that describe the device. And then I pipe that to eGrip. And I say, hey, did that begin with three bytes of zeros? Or did it not begin with three bytes of zeros? Because it turns out that the cheaper mouse jiggler will give you a lot of null reports, like, yep, didn't click anything, yep, didn't move, right, over and over and over again. Now if you get the fancier one, it doesn't really do that, but it works differently. So I get a bunch of these. And then I check and I say, all right, did I get anything? That's what this first statement says. It says, if that thing wasn't zero, then I'll just echo something that you'll never see unless you run it directly. And then I will start declaring, I declare a couple array variables which you can do in bash. That's where the declare dash a mouse reports, and also not null reports comes in. By the way, just a FYI, you'll notice, I don't know how visible it is here, that those are separated by semicolons. And the reason I did it that way is just to put more than one command on a line so that I could kind of fit it on the screen. Obviously, it's still a little bit smallish, but in the materials on the DVD from Def Con, we have all this stuff. So don't stress too much if you can't read it. So then I get two minutes worth of reports, and I store that in my array. And then I do a little bit of command line kung fu here. And I say, okay, are any of these not null reports? And then I look at that list. And I say, all right, it wasn't null. And there's two reports that are exactly the same. And there's no mouse clicking going on. You pretty much got a mouse jiggler, right? At that point. Now, if you have the slightly fancier one, then I'm going to check for things like a five button mouse, it's five button three axis mouse. And once again, there'll be no clicks, right? So that's kind of a big key. And I will look for the report that corresponds to that. And if I get a bunch of reports that are duplicates, or you know, nobody's ever clicking on anything, then I know that this is a mouse jiggler. Finally, I can do detection based on a device class. So whenever you insert a possible jiggler, I can do something about it. Again, this should be benign, you know, don't start wiping your drive, just because something that might be a jiggler was installed, right? This is really a good idea. Even if you have the other rules in place, you know, you do something simple as, hey, you inserted a USB drive or any USB device, I'm just gonna lock the screen now. I mean, if if I do that, here's the you dev rule where I say, all right, any hidden device. So it's like, all right, you inserted a mouse, a joystick, a keyboard, your screen's gonna lock. So what, right? If it's you, so what, you know your password. You know, by the way, you know, if someone storms into your office, and they're trying to, you know, their first goal is to get you away from your computer, and their second goal is to keep it from going to sleep, right? So that's where their mouse jiggler is gonna come in. But, you know, I think personally, with all the stress of armed people in my office, I would temporarily probably forget my password until all my encryption and deletion scripts completed. That's just me. All right, so this script or this you dev rule is pretty simple. You say, anything that was in the hidden subsystem, go run lock screen. Now when it comes to the scripts themselves, you have to choose your level of paranoia. You know, do you just want to lock the screen? Do you want to encrypt some files? Again, I recommend you use whole disk encryption in general. Do you want to start a secure wipe? Do you want to do some physical destruction? Now there's been some other DEF CON talks in the past, they'll reference later about that. So the first thing I want to talk about is locking your screen from a script. Now this might sound simple, but remember, you have a non interactive process, right? So it's like what screen, right? It doesn't have a screen. And that's kind of an issue. So if you're running various windowing systems, it's going to vary a little bit. So if you're running gnome, you can get the session ID by running bin login control list sessions. And then you can run bin login control lock session with that session ID. If you're running KDE or LXDE, you can look at the display and you can use the X screen saver command. So basically you say, oh, I'm going to log in his root essentially and lock the screen. And in other systems, if you just do su-c and then you run a command, screen lock command, whichever it is, that will work. Now here's another little tip for you if you're kind of new to Linux. Notice that I have display equals colon zero before my command. This is a nice little thing you can do in Linux. So if you want to run a command and you want to change an environment variable just for that command and not in general, you can do this, you can list all the environment variables you want to set before you run your actual command. And it works great. So here's my little lock screen script. In this case, I just put my username in there. You could somehow try to figure out what your username is, but keep it simple, right? This is your computer. You're trying to lock it down. So make it applicable to you. And I'm running actually Ubuntu on the test system that I ran. So it's running genome. And here's the little command. So I run list sessions and I pipe that to grep. I grep for my username and I pipe that to awk. And then I print the first item from that line. And that is my session ID. And then I call lock session with that session ID. And it's very similar for some other windowing systems. So it looks kind of like this. I'm just minding my own business here, working on my little Ubuntu system. And here comes some person and boom, all right. So, you know, that my computer just locked. Now, a little word about this, right? My computer just locked. It's encrypting files in the background. Don't be stupid. All right, don't have a little graphic going, ha, ha, ha, ha. I'm like deleting shit or encrypting files, right? That's kind of a bad idea, right? You don't want to alert people as to what you just did. Or I'm sorry, what they just did because did you touch that computer? No, you're not like that first guy from the movie, that was from the movie The Core actually. But you know, that wasn't you. You're forensic tech. I don't know what he did. Not my problem. I was nowhere near it. You know, things happen. Oh, I forgot about that script. Yeah, we have that safeguard. Sorry. All right, so encrypting stuff. If you want to encrypt your sensitive files, again, you should be using whole disk encryption. You have a couple of options. You can use GPG, which is GNU Privacy Guard. It's the same thing as PGP, but open. You can use OpenSSL. You can use Bcrypt and C Crypt. And you can also use random encryption keys, right? So you might temporarily forget your password if people ask you. And then if they say, well, what did you use to encrypt this file or set of files? If you can honestly say, I don't know. I don't know the key. I'm sorry, you can't chorus me to give you something I don't know. So talk a little bit about generating random keys and somewhat securely storing them. I mean, obviously, if you want to stash this key somewhere, it could be discoverable. So, you know, I'll give you some general ideas. Don't don't be the guy that does the exact thing I'm going to show you in this talk, right? It's kind of like I taught a pen testing class a couple of years ago, and I had some students in the class and they're like, I ran all these commands to and, you know, encode my stuff from Metasploit and Dave Kennedy's Metasploit book, and AVG found it every freaking time. I'm like, they read that book too, you know. Alright, so here's how you can use GPG. And again, I have a little usage statement, and it will take a directory. And for everything in that directory, it's going to use for to loop through everything. And it's going to say, hey, is this file already encrypted? Does it have a GPG extension? So that's what you see going on here. Let's see if I there it goes. So here I'm saying, alright, if you get the file name, get the base name, base file, oops, sorry. Base file is a command or base name is a command that will get you just the file name, like it could have a huge path on the front of it and you strip that off. And then you can use base file and then pound pound dot. That is a construct where you can take that name that shell variable base file and get just the extension off of it. So it's kind of a cool little trip. And then I check and I say, alright, has this thing? Oh, this is the wrong script. They're all about the same, right? So if it doesn't have a GPG extension, then I'm going to echo my password and pipe that to GPG and give it a passphrase which is in file descriptor zero, which is standard in. And I'm going to say, please use symmetric encryption using that key. And here's the file name. And then as soon as I'm done, I'm going to remove the file. So I'm going to remove the original file that is. And that's pretty much it. Open SSL, very similar. Just a different command. And I'm looking for E and C as the extension. Now here, I'm going to use AES 256 CBC, which how many people went to Hacker Jeopardy last night? How many of you were sober enough to remember what CBC stands for? Alright, you can look it up later. Alright, it was actually in a question. Or I guess I didn't answer technically. You can also use Ccrypt. Ccrypt, you pretty much want to use that little trick where you set an environment variable. So I set my environment variable jiggly equal to whatever your password is. And then I call CC encrypt on and I give it dash capital E in that environment variable. And then my file name. So if I want to randomly encrypt stuff, I can get a random password. Well, there's a lot of different ways you can get a random password. This is just one. So we use our old friend DD. If you do any forensics, you probably know about DD. Love or hate it. It's very easy to use. My input file in this case is dev u random. u random is better than random. It's more cryptographically sound. And I give it a block size of one and a count of 128. So it says, please go to random you you random that is and give me 128 random numbers. And then I'll pipe that to base 64. And that's my new password. Right. So if I want to get my files back, I have to find a place to put this password. So some suggestions again, don't do exactly what I'm going to do here. The middle of a log file, some obscure log file that nobody's probably going to look at, you know, don't make it a juicy system log that they're going to look at because they're trying to figure out what's going on your system. Some random file. You can also use a random sector on the desk including something that's unallocated. You can also use slack space in your files. And whatever you do, securely delete your script. When you're done, you know, don't just like, Hey, I did all this awesome stuff and I stashed it here and I didn't delete the script that stashes that there. So someone might find that. So here's a simple example of doing a random encryption, you know, I get the password using DD. And then I go and encrypt stuff. And then when I'm done, I'm going to securely delete my files. So speaking of securely deleting files, you can use the secure delete package. And it comes with SRM. It's like RM but secure as fill for filling things with zeros or random stuff. And swap, which will nuke your swap partition or file. Some common options dash D says ignored the dot files, the dot and dot dot files, which is probably a good thing dash F is for fast. I don't recommend you use that because you know, fast says don't use you random. If you're really in a hurry, like if you have a lot of files, maybe, maybe it's not such a bad thing, dash L lessen your security. Sounds like an option you don't want to use dash R will recursively delete subdirectories. Yes, please. Please delete everything in the directory that I set up verbose. You're running the script. I don't know why you'd want that. And dash Z will zero out things on the last right. So it looks like it's empty space. So here's a pretty simple delete script, where I'm going to go to the directory that you told me to burn. And first, I'm going to use a swap to kill anything in the swap file. Then I'm going to burn your files using a for loop going through that directory. And then I'm going to use S fill to get rid of the directory itself. And then I'm going to hit the swap again, and I'm going to shut down the system. Right? So what if I want to wipe the whole disk? I'm just like, I don't, I don't ever want to see this stuff again. There you can get your data from dev zero or random or you random. Now if you use you random for this process, it's going to be slow. Now one thing I should say, yes, it's possible that if you have a government that's going after you, if you overwrite your disk a few times, they can get it back. If they have specialized equipment, and they're willing to spend, you know, a million dollars to get your hard drive back. So choose your level paranoia here. Might take a little while. So if you're going to do this, I recommend you delete the important stuff first. So if you're going to wipe a partition, it helps to have more than one partition because you can't really do this on a mounted partition. Right? So you got to unmount it first. And here's just a couple of ways that you could do that. Physical destruction, our favorite, right? There's a lot of things you could do. Charge capacitors, you could charge up some capacitors that are just going to fry some circuits. If you give them the command to discharge, there's always pyrotechnics. Hopefully you don't start fire. Destructive edges, you know, things that might explosively go through your hard disk platters, things like that. There's been some past DEFCON talks. There was one DEFCON 19 called That's How I Lost My Eye and then aptly named last year, How I Lost My Other Eye. Both very good talks. I recommend you go out to YouTube and watch those. Alright, and the last thing I wanted to talk about really briefly is how you could make your own mouse jiggler. Now, I'll preface this by saying, you probably don't want to. You can buy a mouse jiggler for 20 bucks. So what's the point in building one? Yeah, unless you just want to do it for education. If you did want to make one, I would probably use the FTDI VNC2 micro controller. FTDI, if you don't know them, they make USB stuff. So if you had an older Arduino, you would have an FTDI chip that would do the USB to serial conversions for you. There's cables. If you do any hardware debugging, you probably have one of their cables that use stuff like that. Couple years ago, they came out with a micro controller that was really good at USB stuff. It's kind of like an Arduino, but it's also supports two USB devices and or hosts. So if you want to decode your own mouse jiggler, you basically have to create a USB HID device and send some commands. So creating a USB HID is like this. You have to create a HID descriptor. This describes that device and the kinds of reports that it sends. As noted in the slide, I have shamelessly taken this from John Hyde's USB design by example book. So here's an example of a mouse descriptor and it talks about what are the minimums and maximums for each of the ranges? Does it have this many buttons or that many buttons? What are the reports look like? So that's what this is about. You can send some commands. So you send HID reports to the host. Again, the cheapo ones have like a two button mouse with two axes. So it sends a three byte report. You could do something a little bit longer if you wanted. And you can add other axes. It doesn't really matter what you do. So if you made your own, you could make it a little bit harder to detect. First thing I do is not use either FTDI's vid and PID or actually they're vid. You can set your own PID or the one in the commercial mouse jigglers. Just pick something random. You can also randomize the inputs a little bit better than some of these doing. Do that and you could also randomize the interval. It's not periodic and it's not super easy to detect. And if you're doing this yourself, you're probably doing this as a prank anyway. So you could add a little keystrokes here and there. If you wanted to add a keyboard to your device, you would use something like this as the USB HID keyboard descriptor. Again, this is shamelessly ripped off from John Hyde's book, which by the way, this book you can download for free if you go to FTDIchip.com and just search for USB designed by example. You will see this block. It's freely available with example code and all of that. If you do decide to send some keystrokes, something you should be aware of, that you're not using ASCII codes, you're sending key codes, which are different. So you'll have to map those. You can press multiple keys at once. You can make things happen like, oh, I don't know, you want to lock their screen or things like that. The other thing is, yeah, you can have those keys set to specific values, but if you're just messing with somebody, do you really care what they are? Just randomize it. Just send random junk on that. You can get more details at talk I did last year. It was called One Device to Pwn Them All. I actually went through making a scriptable HID keyboard and some attacks and things that you could do with that. Some other ideas. You can convert that annoying device into a key logger pretty easily if you bother to make one. And you could combine that homemade jiggler functionality with some stuff I talked about last year. All right. So with that, if you have any questions, you can always hit me up on Twitter at P-Polstra. I'm also the handsome guy. You might see sporting a deer stalker hat at a conference. You can also catch me at Bloomcon, a little plug. It's a conference we started this year. It's going to happen next year, March 24th and 25th. We're over in Bloomsburg, Pennsylvania. I know most of you are like, where? But we're a couple hours from Philly, New York City, D.C., and all that. So it's a good time. But with that, if you do have any questions, I was told to ask people to come up to the mics so that they could be heard in the recordings. And it might have some free stuff to give away if you have a good question to say. Wow. There they go. Would it be possible to design the scripts that when a mouse jiggler is plugged in, depending on the design of them, it rewrites the firmware so then any other computer put into it would lock those computers too? Okay. So you're saying somebody inserts a mouse jiggler and you want to infect the mouse jiggler? Yeah. I can't think of a mechanism where that would work. I'm not going to say it's impossible, but I'm going to say probably fairly difficult. Any other questions? Does it work for only one computer or the entire network? Okay. So you could deploy these scripts on your entire network if that's the question you're asking. She just answered my question. Okay. Have you thought about detecting the mouse jiggler and then putting this into a log file which then gets deployed to the other computers so if you detect one that took a couple of minutes the other ones will then immediately detect it. I haven't thought about that but that is a good idea. I think that's a mouse jiggler worthy question. Yes sir. Yes there is certainly with Apple computers because Apple computers are sort of running Linux, right? They're running a different variant of Unix in that family tree. Windows, I'm not going to say it's impossible. I'm just going to say I don't know how to do it because I don't use Windows, right? Windows is great for hacking on and doing forensics on but actually my latest book is about doing forensics on Windows subjects from Linux where you get real power so it's basically a little plug from my book. It's how you can do this without spending $10,000 on top of it. So like using all the free open source stuff in Linux to do that. Alright and I'm getting a sign that I'm done so thank you very much.