 I guess there's no goon introducing us, so we'll have to do everything ourselves. All right, so I'm Dennis. A lot of you guys know me. Yay for Houston. And all of you know me from my previous talk. I talked about access control systems. So this is going to be my second time speaking. I work for Lars Consulting. I'm an adversarial engineer, my best, my most favorite title yet. I'm also, since I'm from Houston, I'm a founder of Houston Locksport or Lockpicking Club. And Houston Air and Hackers Anonymous, just a bunch of us hanging out, drinking beers, and doing micro talks in Houston. So, ooh, what have we got here? Libations for your talk. Oh, thank you so much. Round of applause for Kyle. Yay. Ooh, that's good. All right, and so I'm Tim. I'm a Red Team Manager for Lars, which means I don't know what to call Dennis employee, but more of a team lead consultant, that sort of thing. This is my 10th year as a DEFCON Goon, so I'm eligible for retirement now, which is always fun. Yeah, woo. I'm also a former CCDC team coach for a group of college students through CCDC. I don't know if y'all are familiar with that program. I'll see you guys in the back. And also, and I'm also a former CTF participant for DEFCON. I did that two years in a row. I also ran the wireless contest for a couple of years. So I've kind of been around. I've done a little bit of everything. This is also my second DEFCON talk. So what we're going to talk about is sticky keys. If I say sticky keys, does everybody in here know what we're talking about? That's how you get into your computer. Exactly right. So if you Google for how to reset Windows passwords, like eight of the top 10 links on Google are pages that tell you, reboot off of your rescue CD, go in, copy, cmd.exe, overset, hc.exe, reboot at the login prompt, press shift five times, use net user, change your password, close the window, log in, and you're done. There's only one or two of those sites that actually says clean up after yourself when you're done. So there's a lot of boxes out there that still have cmd replacing set hc, and these boxes are just kind of ripe for the picking. So it was used as a persistence mechanism, like there's a kernel-ownage blog on it. There's several different places that tell you how to do this. And with this though, so there's no event logs that are generated whenever you actually execute this backdoor. So there's no trace that you press shift five times and you get a command prompt because it's pre-authentication. So there's two ways that you can go about backdooring a Windows box with this method. One of them is the binary replacement, actually replacing any of the pre-authentication accessibility tools with cmd, or you can set the image file execution option, registry debugger key to be cmd.dx. And so whenever you access any of the accessibility tools for Windows, you get a command prompt running as system pre-authentication. So here's a list of the accessibility tools that are available pre-authentication. You've got the binary on the left, the description of what the tool actually does in the middle, and on the right, you've got how you actually access that. And so that's gonna come in important later whenever we actually start talking about the tool. But Microsoft does have some limitations on what binaries you can replace any of the accessibility tools with. So the first limitation is you have to have elevated access on the box. You're gonna have to have administrator system to begin with. So we're not actually exploiting the box and we're not actually placing a backdoor. We're just taking advantage of a backdoor that somebody else has already put on the box. The binary must be digitally signed. This is Microsoft restriction for that. The binary must exist in system 32 and it must be on the Windows protected file list. And so if you've ever ran system file checker and it goes back and says, hey look, these binaries have been replaced or there's something wrong with them and it fixes them, that's the Windows protected file list. And you can get a list of those from Microsoft's website. But so you can't just use any old binary. You have to use something that meets those criteria and CM2DXE meets all three of those criteria. And so we were working with an incident response team in an organization and they had uncovered via the file system side of things several boxes that had this persistence mechanism put in place. And so it was more than likely a systems administrator could have been a rogue admin, could have been some APT group that was in the environment. Don't know how they actually got there, but we wanted something to where we could scan for this from the network side. So we started, well let me back up a little bit. The problem with looking for binaries that have been replaced on the disk is you don't actually catch the image file execution option unless you're sweeping the registry as well. You're gonna miss any unmanaged boxes. So boxes that the group doesn't have administrative access on. You're gonna miss any boxes that they don't have administrative privileges. And so we had a need for a network based scanner. We started looking into writing our own using Java RDP or looking at Python and had a bunch of problems and just a hate for Java that we couldn't get over. So we ran across Zach Grace's proof of concept script, Sticky Key Hunter. Sticky Key Hunter was a great starting point for us. It gave us a decent framework for how we wanted to kind of implement our script, but his script was similar to the peeping Tom program. If any of you are pen testers and you've seen peeping Tom, it scrapes a bunch of websites and we'll take screenshots of them and then give you a page that you can just scroll through looking at them. And so if you're talking about a large organization with anywhere from 20 to 100,000 endpoints, that's a lot of screenshots just to scroll through looking for a command prompt. So we wanted a way to automate some of that for us. And so Zach's script also in the to-dos had automatic command prompt detection and then multi-threading to make a script faster. It took about 25 to 30 seconds per host and we did some optimizations on that. All right, so we started with the Sticky Key Hunter script that Tim talked about and we went into it, we wanted to help improve it and help kind of complete its to-do items and what ended up happening is I spent way too much time on it just seeing things that I wanted to do differently and so we ended up more than double the lines of code of what originally was and we implemented a lot of performance improvements, some error handling to help with if hosts go down or whatever, lots of detailed logging to help with reporting and as well as it's now parallelized so it'll scan more than one host at a time and that dramatically improves the time it takes to scan a list, a range of hosts or IPs and it also automatically alerts on command prompts on hosts that thinks it actually found a command prompt on and so you don't have to scroll through thousands and thousands of screenshots and of course it's in Bash so it's tailored toward Linux, we programmed this on Kali Linux, all the tools you'll need is available for Kali so that's our script, so let me demo this for you. I'm gonna start by demoing what Tim talked about, what the sticky key's vulnerability is so I'm gonna remote desktop into a computer and just show you what happens is you're gonna see a Windows login prompt and we're not gonna put in any credentials, we're just gonna be presented with that login prompt and this computer is vulnerable to the sticky key backdoor so all we do is press shift five times, I'm gonna do this, there you go and then now you see we have a command prompt and because this is spawning from winlogon.exe you can see who am I, we are system, the highest level access you can get on that computer and so that's just a method of persistence, a backdoor that lots of people do and so our script, let's go back to the PowerPoint here, our script automates searching for that, automates actually scanning for that vulnerability, you'll see here, let's press play carefully, does that work? Okay, so it's going, so you'll see it's named banana.sh when we recorded this, I had no idea what to name it so Tim and I settled on banana but now it's sticky key slayer, so. But you can see, I told it to do eight threads at a time, it's doing a list of 20-something hosts and it's going through each one, it's establishing a connection to it, it's taking screenshot, hitting shift five times as well as other keyboard shortcuts, taking another screenshot and then comparing the amount of black pixels that are on the screen and it'll alert, okay, I found a lot of black pixels, it's within this range of this percentage and this percentage, I think you have a command prompt and once it's done, you can see the logging there, I hope the text is not too small, you can look through the screenshots and you see the screenshots of all the hosts that don't have a command prompt and in that discovered folder that I'm going to click on in a second, you'll see all the hosts that actually have a command prompt and you can see them in there, there's one of them. So to reiterate, there's a sticky key slayer, that's the real name, specified dash jh for the number of jobs, demo host is just a list of targets line by line and then you get the screenshots for all the computers and in a discover folder, there's the ones that actually have command prompt and there it is and those are computers we have full system level remote code execution on without any work using someone else's back door. So free money. So tool usage, so I mean that's the tool, that's the gist of it, it's like 360 lines of code but that's all it does, sticky key, excuse me, tool usage, sticky key slayer.sh So there's a few parameters that you can choose, you can do dash v for verbose, it does output some information to you but you can make it more verbose if you want to maybe something's wrong or you just want more information. You can specify the number of jobs, it defaults one job at a time but you can give it as much as you want, as much as your CPU can handle. Don't try 1000 because it will crash but I've had success on a Cali VM running on a MacBook Pro about 24 and that'll scan about 22,000 hosts in about three hours. So that's pretty good. Timeout, you guys are familiar with the concept of timeout, it'll try a certain job for a certain amount of time before it just errors out. You can specify that timeout, it defaults to 30 seconds and then target list. You can either give it a single target, an IP or a host or a FQDN or you can give it a list of hosts and that's the money right there. You can give it a list of 20,000 hosts, let it run, go home, come back and get all these, get hundreds of, sorry, 20,000 screenshots when you come back. So some limitations to the tool. It does tie up the computer you're using. As you can see, it was popping up a bunch of remote desktop windows so it's kind of hard to use it. When you're, it's hard to use a computer when you're using the script. So have a VM dedicated just to that for that time. And as well as we, when Tim and I were doing some scans and some other IP addresses with their permission, Wink, we found that the majority of them, majority of the backdoors were cmd.exe, however, there were a few that were something else like Task Manager or MMC or something custom and our script, of course, doesn't detect those because it's looking for a certain amount of black pixels. So maybe in the future, Tim and I are kind of working on how we're gonna engineer that, like detecting any anomalous behavior, not just cmd, statistics. All right, so based on Dennis and I's assessments and then based on some assessments from some other friends and other things, we've probably scanned about half a million boxes. We've turned these over to some large organizations for internal scanning and there's a pretty decent success rate internally for some of the environments that we were in, but we decided to turn around and look at a large business class ISP. I went to show Dan, did a search for business ISP and then port 3389 got a list of boxes that were exposed, that were exposing RDP to the internet and there were about 100,000 or so roughly in that list. We had 570 system shells by the time the scan was done. It took about six or eight hours to scan that large of an IP space. So that was one out of, the real statistic was like one out of 173 boxes, one out of 175 makes a great round number for it, but that was far more boxes than we thought we're actually going to be vulnerable to a backdoor that's been around for years. I mean, our first step into this was this is going to be stupid, nobody's ever going to do this and it turns out this is happening all over the place. So by looking at the domain names on the login screen, there's educational institutions, there's law offices, manufacturing facilities, hospitals, pretty much any vertical that you can think of have free system shells on their boxes. So if you step into an assessment or an environment if you're doing an external test and they have RDP enabled, hey, take a shot, it may work. If you're internal, that's even better because you may find one or two servers, but those one or two servers you've got a system shell on that you can now run MimiCats or go from there with absolutely no logging. By the way, that's 570 plus shells we got like with no work required. How was that not worth a round of applause? Woo! So now we got to talk about what matters most, right? The recommendations, the remediation, the prevention detection. So we've worked a lot on the remediation side of this. So we came up with a few techniques, a few just ways to help mitigate this. So if you do find one of these, one of your boxes in your environment are vulnerable to this back door, there are a few things you can do. You can delete the executable. If there's, if CMD was replaced, assethc.exe or any one of those other accessibility tools, you can just simply delete them. They're not totally necessary to make a computer function and your computer will eventually in an update or when it does an integrity check, it'll replace those files back to where it would be. If you don't want to delete them, you can force an integrity check. You can use sfc.exe, which is system file checker that's built into Windows. And what that'll do is that'll scan all the Windows protected files in which all of these are Windows protected files and it'll check, are these the files that they're supposed to be? If not, it'll replace them back to what they're supposed to be. So you can run fsc scan now, you can specify to do your entire drive or specific files. If this was done through the registry method using the debugger to make it run, you can simply delete that registry key. That key does not need to be there. Delete the whole key for sethc.exe or utilman or whatever. And one thing I like to inform people is that I really feel that they should treat this as an indicator of compromise. If they find, if you guys find this back to where in your environment, it's going to be one of two things. It's going to be someone subverted processes and put this back to where in for whatever reason. Maybe it's just a simple reason they want it to get in in case something goes wrong or maybe it's they want it to get in when they get fired. So there's that. And then there's also, if it's not that reason, it's an indicator of compromise. Maybe there is an intrusion in your network previously, some malware or APT as they call it or some threat actor. Oh great, someone laughed at APT. I laugh too every time. Someone did this. This is a known method of persistence. I mean, this is my top method. When I go to CCDC, I played against that guy over there. We wrecked them with just cmd.exe backdoor because they took a snapshot of their VMs before, after we already implemented this backdoor. So we were able to get in every time. So treat this as an indicator of compromise because it's serious, it doesn't just happen. Now going into the prevention and detection phase, okay the simple protection, simple way to protect against this is restrict local admin of course. You need to be local admin to replace these files. So restricting that is important. It helps resolve a lot of issues including this. Full disk encryption, that'll help prevent if someone were to steal a laptop and get access to content to the hard drive and replace the files that way. Full disk encryption will help protect against that. My favorite method of, it doesn't really protect against it. It protects against the exploitation of it is network level authentication for remote desktop. Network level authentication, when that's enabled, it requires valid credentials before a console is ever presented to the user. So our scripts wouldn't work unless we had valid credentials. So enabling NLA across the entire environment is a valid protection against exploitation of this. Against remote exploitation. End point monitoring, we've seen a lot of success with end point monitoring. You can monitor a few things, one of them being monitor when the file is replaced. If the file is something what it's not supposed to be, alert on that. You can also alert on if CMD ever spawns from the WinLogOn process, as a child of the WinLogOn process, that's not normal. I mean in my experience, it's usually not normal. So you can flag on that as well. And then NetFlow analysis. Simply look at, are there hosts, is there one host or a few hosts in the environment that are just spraying RDP, port 3389 everywhere? If so, maybe you should look into that. So, oh by the way, Tim made this for me, it's great. This is, what do you call it? What do you call it? Conquest, the ears of your enemies. The ears of my enemy. The rumor has it, these are all the shift keys that we've broken over time from exploiting them. So we just took them off and Tim made them into a necklace. So I'm gonna wear it. Um, what's this guy? So, a little treat for you guys. The code is, has been released as of an hour ago. So it's on my GitHub, sticky key, excuse me, sticky key slayer, what are you laughing at? Sticky key slayer. It's up there, I put a lot of documentation, hopefully it's easy to read and easy to use. I recommend if you guys work for a big company or a small company, download it, look at the code so you know I'm not doing anything malicious. Don't just download any code and run it, but you can if you want, I don't care. Run this in your environment and just see, you'll be surprised how many you'll see out there. There hasn't been any environment yet that we've scanned and haven't at least found one. So try it, look into it and see what you can get. So yeah, my codes on GitHub, I encourage you guys to contribute to it or at least report any issues you see because I always like to make my stuff work for everyone, so report issues, send us feedback, whatever you want. Slides are also online, demo video is online if you care about it. That's pretty much it, questions. So we've also got a weaponized version of the works that you can just say execute this code as soon as you find a command prompt. So you just set it and forget it and watch the shells rain in. So that's a. I call it raining shells.sh. Question, question over there. Oh. We'll repeat the question. Yeah, yeah. Okay. All right, yeah, that's a good idea. Okay, we'll do that. Okay, questions go up here. So we have three minutes for questions. And then. You need a loud mouth in the back? Yeah, I'm sure you have questions. Okay, go ahead. Is it on? Okay, just tell me, I'll repeat it. All right, so if you use black pixels to determine if you got a command prompt, what did you do to account for the different operating systems? For example, Windows XP has a pure black background and other operating systems might use dark backgrounds. It's the difference between the H-R-DP connection. We take a screenshot and we make a, actually send all the accessibility options. We take a difference, take a second screenshot and it's the difference between the two. It's not just looking for black pixels, it's looking for the different, the difference between them. So if you look at like Dell has their default Windows install has the front end of the Dell bezel on it that's got a lot of black in it. Whenever you actually pop a sticky key shell on it, there's more black on the screen than there was before. And so we're just looking for the difference. It's very simple. It's rudimentary. There's been some work out there in like OpenCV trying to do screenshot detections and other stuff for it. We looked into using OCR in the screen, but we found a lot of boxes in non-native English and I don't know how to do OCR recognition in English and non-English character sets. So about half a million IP addresses that we've scanned with it from us and then other people's engagements. It's great. It's like 99.96% effective in detecting the screenshot every time. There were a couple of false positives, but those false positives were due to broken consoles to where like the top two thirds of the screen was the actual console, the bottom third of the screen would just be black. Thank you. Woo! Yeah, I mean, so to paralyze this, we do use GNU parallel. That's it right, GNU parallel. We use the tool GNU parallel and that just allows the script to spawn itself in multiple processes and just run really, really fast. So it's really cool looking at that tool. Question? Thank you, sirs. Question. Do you have a list of all of the other ones that work? Yeah, we go back to that. Because you said there are other ones, but you only talked about ZHC. There you go. Ha ha ha. Thank you. Okay, so yeah. Ha ha ha. Ha ha ha. So just to reiterate, this is not, so shift five times is only one of the one, two, three, four, five, six, seven. Seven executables that'll work with this. Window key, you will open Utilman on-screen keyboard. There's no keyboard shortcut for that, but there's an option for that. And so they're saying we're done. We have one more minute. Question, one more minute. Yeah, sure. So if you can programmatically scan and detect these things and you can programmatically send keys, you could also in theory programmatically add an option to remove the back door. Or add dash dash evil and add your own implant and then remove that back door. So my goal as a troll was if you just downloaded our code and ran it and said, hey, go ahead and just do this to run SFC slash scan now as the actual weaponized code. And then drop us something in the log file to say, hey, this box had this back door enabled on it, but sorry, you just cleaned it, thanks. Read the code next time. Thank you guys so much. Questions will be out there and we'll slowly move to the bar. Thank you guys so much for coming.