 Right. Hello everyone. Uh, thank you for, for coming to our talk on, uh, remote physical access attacks via USB. Uh, just in case you're in the wrong room, that's the, the bottom line up front. We're gonna be talking about an end-to-end attack, implementation of a USB implant. That's the trendy thing to call it these days. Uh, that provides remote access to even devices that, that are air-gapped. So it doesn't use the, the host network. Um, and so the, the important things there are no network interfaces required. Uh, it's gonna be very difficult for forensic tools to pick the stuff we're doing up. Uh, and we're gonna release the tool set and some open hardware so that you guys can, can play with it too. Alright, anyone want to walk out after that? Okay. So we're from a company called SensePost. Uh, we've got an office in, in South Africa and London. We came all the way from South Africa. It's a long flight. Uh, we're predominantly a penetration testing. Thank you. Sorry. We're predominantly a penetration testing company. Uh, so that's the angle we're coming from in this talk. And, and we do some other things. Started nearly 17 years ago in a bedroom in Pretoria, South Africa. It's a picture of said bedroom. Um, and Rogan is the primary researcher on this. He did a lot of the, most of the heavy lifting. Um, is that show? Yeah, it's all on there. So if you want to shout at anyone, please shout at him. But if he's not listening, you can shout at me. Uh, I'm at Syng on Twitter and Rogan is at Rogan Doors on Twitter. Alright, so one of the really difficult things in security, particularly on the defensive side, is coming up with a realistic threat model. So this is Jeremy Meeks. He was a, a felon whose mug shot ended up going viral and he got a modeling contract afterwards. So you get it. It's a threat model. Okay? No, okay. I'm, I'm a dad now. I'm allowed to make dad jokes. So what, I think what happens a lot of the time when you're on the defensive side is there's all sorts of things you need to prioritize your spend. There's lots of vendor marketing. Uh, there's branded bugs. There's people who come give talks at DEF CON. Um, and, and you've got to try and figure out where you're going to spend your, your time. And I think a lot of the time in information security, uh, people are walking down a dark alley worried about pianos falling on their head rather than somebody coming to mug them. And so what I think a pentester's job is, is to realistically emulate actual bad guy attacks. So things real bad guys are doing that will affect an organization. I mean it's, it's really cool when we come up with super interesting creative attacks. But if we're not also coming up with attacks that real bad guys are using, that's going to be a problem. And so that's, that's one of the reasons why we wanted to do this work. And so given I'm talking about real bad guys, let's start talking about some real bad guys. So if the NSA is targeting you then they're, for all intents and purposes, one of your bad guys. Um, probably difficult bad guys to deal with. But in 2000, 2008, it's not when this was released. This was part of the Snowden docs. Um, it was pointed out that NSA had this, this capability which was a miniaturized USB device. It had its own RF protocol, uh, that could have cons off the host and, and you could get remote control of hosts with this hardware implant. And so this is what the NSA was doing circa 2008. If we consider those guys the Apex predators, you know, probably 2008 they were, they were leading the pack with this stuff. But then about three years ago, we, um, were called in to help with a, a crime that was ongoing at a series of financial institutions back in South Africa. And the same sort of attack repeated itself in, in the UK as well. And what this attack was, was they were using simple physical hardware to bypass the software controls in place. Um, so the first thing were hardware key loggers in the bottom left hand corner. Uh, they would pay people to put these down. They'd get a password for somebody who could make a transaction. And they'd get a password for somebody who could approve a transaction. The thing in the top right is a, is a hard, hard drive imaging tool. They would pay somebody to go image hard drives. And these guys were so technically unsophisticated, they would buy computers that were the same color as the computer that had been imaged. Because they thought that was the relevant hardware characteristic. And then they would pay someone to put that, that box in the middle down, it's called a, a pocket port. And that basically provides a VPN into the internal network. So now they've got creds, they've got the bank software, and they've got remote access. And none of it was particularly litax. These were criminals paying people, it's kind of the way crimes worked for, for a long time. And they were wildly successful. We were talking hundreds of millions of rands, which is about two dollars. Um, you guys laugh, it hurts us. Um, that, that were taken from, from all of these financial institutions. And so we were left wondering if you've got the apex predator over here using hardware bypasses of software controls. And you've got criminals who are like color matching their computers, um, being wildly successful at actually stealing money doing it. We can hypothesize this probably a swath of things in between where people are using a similar kind of attack, hard, hardware bypasses of software security. But, um, in, in different ways. And so that tells us real criminals are doing this, maybe this is something we should look at in more detail and stop writing it off as, well if you've got physical access, the game's lost. And so when you look at the way your average, like our average client, corporate defends against USB threats. It's mostly worries about malware, mostly dropped from mass storage devices, or unauthorized networking. Something like a 3G device or a Wi-Fi card bypassing the firewall. And so those are the sorts of restrictions you see in place. But the USB standard allows for vastly more sorts of devices. Um, and as hardware is getting smaller and smaller, there's vastly more things you can do with those devices. Um, and we think that there's ways that you can, the tax we're gonna show today, there's ways that you can get remote compromises of machines via USB that doesn't hit any of those protections. So specifically the objectives of our work were, were sixfold. The first is we wanted to have a usable end to end attack. So something we could use in our engagements to demonstrate this risk to our customers, but then also something that you guys can use to demonstrate this risk. Um, so we didn't want to demonstrate one or two concepts, we wanted the whole thing to work from plug-in to remote shell. We wanted to be able to remotely trigger this stuff at times of our choosing. We didn't want to have to deal with finicky random delays from when you plug it in to when it fires and make sure the screensaver's not getting in the way. We wanted to avoid obvious USB vectors. So we didn't want to have USB mass storage dropping malware. We didn't want to have malware that was really easy to spot by AV. We wanted to be as automated as possible. Now we're talking USB so obviously at some point somebody needs to plug something into a computer. Um, but beyond that, we didn't want to have to be fiddling with things. Must be automated. Then this was quite an important design goal for us. We wanted to use a COVID backchannel. And that's fancy words for it mustn't be a network card. So we'll get into it in more detail, but we use innocuous looking USB devices, text printers, sound cards, um, and in this particular thing, generic HID device to do a bunch of our comms and Rogan's going to get into that in more detail. And then we wanted to limit the, the forensic impact of this. So because we're using hardware devices, we could put a bunch of the heavy lifting on there rather than having to stick it in malware that's executing on the host. And so naturally because we're using our own RF backchannel, it's not going through the, the network of the, the target device or the target organization. So things like fire eyes and IDS's, um, that would normally monitor network comms, looking for C2 comms, things like that, they're not going to come into play. We also don't have to deal with the vagaries of proxy access that might be in play at various organizations. And, and then the, the second thing is most of the, the payloads that we're running are really small, simple stub things that don't look particularly dangerous. Now of course AV could always take the stuff we released today and develop signatures for that as is they want. But we can very quickly change these simple payloads to avoid that. And they're kind of stuck in a game of, of false positive matching on very simple USB devices that have all sorts of, of other uses. So that was a big, these were the, the main six objectives we were going for with this work. So like everybody, we've built, um, on the shoulders of giants. Um, we're obviously not the first people to come up with a lot of these ideas. Um, a lot of, um, prior art exists. Uh, in particular, um, Adrian Crenshaw was plug and pray from 2010 or 2009. Um, his malicious USB devices, he did a, some, some really good work there. Um, Hack 5's Rubber Ducky's also been around for a long time. So the, the concept of a malicious head device is not new. What we'd like to show is that we can take it a step further, um, than other people have done so far and hopefully show something novel that, uh, that you guys will appreciate. Um, other prior art, uh, the face down supports, um, devices from Travis Goodspeed and Sergio Bratis, um, have shown that there's a lot of, uh, capability in the, in the USB, um, classes. Um, the NSA play sets turnip school was a, a really good introduction to, um, some embedded USB devices that was a, uh, a start at emulating the, uh, the cottonmouth devices, the NSA things. Um, Sammy Cankar has done the USB drive by, which is a keyboard and mouse device that will execute keyboard, keystrokes and mouse movements on a script. Um, and then recently released at, uh, Hack in the Box in Amsterdam, um, Sinhun Han's Iron Head did some very similar things to what we're going to show you today. Um, but that was released after our DEF CON submission. So, so the hardware that we're using, or that we use to prototype this is a device from a company in China called April Brother. Um, it's called the Cactus Micro Revision 2 and it has an ESP8266 Wi-Fi microcontroller on it as well as an ATMEGA, an, uh, ATML, ATMEGA 32U4 AVR processor on it. And the reason this was important for us, the Wi-Fi gives us a COMS channel and the, uh, the AVR processor gives us the USB capabilities. So the, the combination of the two was critical to, to pulling this off. Um, it has some problems obviously. The, the device itself is really, really small so which is obviously a good thing but it has a micro USB connector on it which is not particularly good when you're trying to make it look like a flash drive. So for those in the back, this is what it looks like. Um, so it's compact enough to be a flash drive. You can put it into a, into a casing but it needed the, the USB A connector. Um, some advantages though, it's cheap. Um, they were going for around 11 dollars when I bought, when I bought mine. Um, and it's got the, the, the basic capabilities that we need, the Wi-Fi and the USB, um, capabilities. So we had some custom boards made up, um, to address those shortcomings that we identified. Um, most importantly the USB A connector but also, um, we added some storage capability, um, micro SD slot so we can put some storage on it. If we want to make it show up as a flash storage device we can or store data on it for exfiltration. Um, but we also connected a few of the other, uh, lines between the two microprocessors so that we can use some of the other capabilities that exist. So there's the, the finished device, both sides, um, and in a casing. So it's pretty innocuous, looks exactly like a flash drive. There is nothing really that distinguishes it otherwise. Okay so let me run you through the flow of how the device actually works. On one side we've got the attacker and on the other side we've got our target. The attacker connects to the ESP device, the ESP processor which is running ESP link firmware with some modifications. Uh, and that connection happens over Wi-Fi. Which means that the attacker can use a lot of standardized tools. It's a, an interface that everybody has capability to interact with. The ESP link then interacts with the AVR processor and I just want to point out that um, these are both on the same board. It's shown separately because they're two separate controllers, two separate microcontrollers, but they're actually on that same board. Disconnected via a serial link, a UART. The AVR processor is using the Lufa framework which is a um, a software package for the, the AVR processor that allows it to show up or to emulate a variety of different USB devices. And that is how the AVR processor then appears to our victim once it's plugged in. So the first problem that we ran into was well we need to get keystrokes to come out of the USB interface and be seen by the victim. So I started off by looking at what the actual bytes are that are needed to send those characters. And you need to send seven bytes and character A is byte three, etc, etc. And I wrote a program on my PC that would connect to the ESP over Wi-Fi and send those bytes that needed to come out the other side. But that ran into a problem and you know things like dealing with alt tabs and control alt deletes, etc, etc, made life pretty difficult for me. And then I realized that well hold on a second, this is actually a solved problem. What I'm really talking about is VNC. VNC has been doing network keystrokes and mass movements for years and years. So in order to, to take advantage of that, I then implemented a VNC server in the ESP microcontroller. Turns out that the VNC protocol is pretty simple if you can ignore all of the graphical compression and that side of things. So the ESP then passes those keystrokes down to the AVR. The AVR emits those keystrokes as USB keystroke events and mass movements as required. The other aspect of the, of the AVR is that it can provide multiple interfaces simultaneously using what's known as a composite device. So while it's being a keyboard and a mouse, it can also provide additional channels. We looked at using some, you know, pure keyboard and mass coms, thinking that we could extract data using the keyboard LEDs, the scroll lock and the num lock and the caps lock LEDs because that's a reverse channel that's available to a keyboard. And then we discovered that that's not novel. Somebody's already done that in 2012 and they managed to get a whopping 1.25 bytes per second. So we reckon that wasn't good enough and explored some other alternatives. Other alternatives that we, that we considered were devices such as text only printers, things like sound cards, MIDI devices, which all have default class drivers in most operating systems that you're interested in. They'll automatically be recognized and it makes it really, really easy for an attacker to connect a device and not have to worry about loading driver software or anything like that. No prompts show up on the victim. You simply plug it in, Windows recognizes it and you're good to go. Another aspect of what we implemented, we realized that as a, as a keyboard and a mouse, it doesn't actually give you any particular elevated access. It's just a keyboard. So one thing that we realized is that we can only launch our attack when the screen is unlocked. One thought that we came up with was then to implement an automated mouse jiggler. So all it does is it moves the mouse periodically every couple of seconds, one pixel to the left, one pixel to the right. So your mouse doesn't move around, but it stops the screensaver from kicking in. And it works pretty well if you only do one pixel, it doesn't actually disturb the screensaver if it's already kicked in. So if the machine's gone to sleep and you plug this in, the device will stay asleep and the screensaver will stay active. As soon as somebody unlocks the screensaver, though, the mouse jiggler will stop it from reactivating. Turned out pretty well. Okay. So having implemented the keystroke channel, we then realized that we needed to have a, this additional pipe. So we've launched our, our basic exploit and now we need to have this back channel communications and in order to do that we used, for this particular exploit or demonstration, we used a generic hid class. What's great about that is that you plug it in, Windows recognizes it and you've got permission to access it. There's no administrative privileges required in order to access the generic hid device. So the process goes like this. We use a scripted VNC tool to type out our stage zero attack. Our stage zero attack then is, as minimal as possible, the bare minimum code that we could arrive at that would open up that generic hid interface and then read more data from that, the secondary stage or a stage one. Some of the problems we ran into, well obviously we want this to be as stealthy as possible so we don't want somebody sitting there to suddenly see code being typed into their machine. So the first thing we did was we configured it, the code we ran, set the foreground text to be the same color as the background and then clear the screen. So you get a blank screen just showing up on your PC. Well, it's not great but that only happens for a few seconds. Shortly after that, we move the screen, sorry, we move the window off the screen. So in order to still receive keystrokes we can't minimize the window but we can move it off screen to position 2000, 2000, that's off most people's screens and it can continue to receive keystrokes even when it's no longer visible. It does still remain in the task bar however because it has to in order to receive those keystrokes. The last thing we do once we've finished executing our payload is to make that window disappear from the task bar. From start to finish, the process takes about three seconds before the text becomes invisible, about five seconds before it disappears off the window and 13 seconds in total for it to disappear from the task bar. So that's pretty quick. Averaging between 60 and 90 characters per second for our typing. Once our stage naught payload is running, we then send a stage one. It's a very simple payload but it can be as complex as you want it to be. The stage zero simply reads a two byte length and then that many bytes of power shell to execute. So some examples of a stage one we have. One that spawns a command shell which we'll show you. We've got another one that takes a screenshot of the victim's desktop and sends it back as a JPEG. And we've got some other payloads that we're still playing with that we'd love to show you if you're interested after the talk because I think we're going to run out of time. So like Rogan was saying, one of the big problems with this is you need to make sure that that initial typed payload is as stealthy as possible. And I think we've come up with some fairly decent optimizations that mean we can type an incredibly small payload. So our sneakiest payload is about just less than a thousand characters and which can be typed pretty quickly. And we can do a bunch of optimizations beforehand to hide it plus I think it's pretty cool that it reads from the HID device. You don't have to rely on sort of fragile typing to get the thing across. We tried some other things so we ran into some issues with alternative keyboard layouts. So we were using a UK keyboard layout versus a USA keyboard layout and different characters come through differently particularly when you're typing sort of semi-advanced PowerShell code. One of the easy solutions would be to Bay 64 encode that. But those of you who've played with things like Empire or PowerShell's Bay 64 encoding that ends up like over doubling the size of the characters required because of the way it does the Bay 64 encoding. So we had to keep it as small and as sneaky as possible. We also tried some other interesting things which we thought were quite clever but they didn't work out so well. Because we're typing we could technically use tab completion from PowerShell. So we were able to implement a payload that uses tab completion as much as possible which saved us I think a total of 12 characters. Wasn't really worth the effort. But with the code that we released we're going to release a simple little PowerShell minifier. So those of you who are trying to get smaller PowerShell exploits into smaller buffers that might be helpful for some of you. So some of the other problems, some of the other problems we ran into were flow control issues. So the process of developing this was one of pretty much pulling my hair out to be quite honest. You start off with the attackers machine which is a multi gigahertz desktop. You're talking to an 80 megahertz 32 bit processor dealing with the Wi-Fi stuff which is then talking down to an 8 megahertz 8 bit processor with a few bytes of RAM and so on. Um and then ultimately talking to another multiple gigahertz processor. So it was it became quite a problem of making sure that while you're sending the data at full speed from the attackers machine to the ESP the ESP then has the ability to say whoa slow down I can only send data so fast to the AVR again only send it so fast to the to the victim's PC and then again in the same in the reverse direction from the victim back across all of these different disparate capabilities. Some of the problems um that we ran into the ESP's got 128 byte FIFO uh buffer so you fill the buffer and then the AVR goes okay enough but it's filled it again by the time the AVR has read all that that data and you end up running over the edge of the buffer and uh jumping off into no man's land. Some of the problems though you're debugging so you've got no um you know no screens or anything like that to see what's actually happening. You're trying to infer behavior based on like a light flashing or something along those lines. So it became kind of an exercise in in whack-a-mole trying to figure out you know exactly where all of this was going wrong. And especially when it came to debugging the ESP its behavior if you got anything wrong is to reboot. The watchdog timer kicks in and everything goes away. While it's got uh debug capabilities um the ESP link firmware in particular gives you a very nice uh debug window that you can access using an HTTP server once it reboots that data's gone. So in order to successfully debug it what I ended up doing was putting two USB to serial adapters monitoring the lines between the ESP and the AVR so that any debugging output I would just send from one processor to the other monitor it with the um with the two USB serial adapters and then I could finally start to figure out uh where I was going wrong. And then a final problem that uh that I needed to be able to to solve was the orchestration of all the components. You've got your VNC script sending keystrokes um you've got your stage one being sent over telnet uh and you need to make sure that stage zero is completed before stage one starts pro trying to be processed and then any subsequent stages. So it became um a little bit of a a dance if you like. Making sure that all the moving pieces were moving in the right time and in the right direction. And so the the bits Rogan doesn't tell you about he says he lost a bunch of hair but include things like uh three o'clock yesterday night as he's trying to develop one more thing. Dancing around the room thinking something's one or only to have it fall over and to return to his chair in disappointment. Um and so the the thing that this made clear to us in developing it is that in the the world of PCs and mobile phones as as attackers or even just normal users we used to the idea that there's these really robust well tested frameworks stacks libraries. But the second you move to little pieces of shitty hardware that are this big um you end up in a dark world of pain fear and loathing. Um and so the the move from the theoretical to the actual implementation with this is it is quite a long path particularly as you move across all of these different layers. I'm sure there are embedded hardware programmers who would look at the code and laugh and laugh and laugh. Um but it's not like you can have just one area of of specialization in this. You're moving from USB to Wi-Fi to Telnet to VNC to PowerShell and really is a a cross functional thing. And so we weren't able to find any live chickens in in Las Vegas um and we haven't sacrificed anything to the demo God. Um and we're going to try and show you a video demo. We're going to try and show a live demo later on but we thought let's have at least one thing which works before we march off in chain. So this is a video of said demo and on the board it's not showing up is it? Alright so that's your right hand side is the attacker and the left hand side is the victim. So the the victim machine is a bog standard Windows 8 uh default configuration other than having installed antivirus. There's no network connection available. So the thing is air gapped for all intents and purposes. And then probably the longest part of setting up this machine was downloading the bloatware that is McAfee. Um for it to give us a little green icon saying we're secure and we updated it last night. So we've got the latest and greatest protections there. Now we mentioned that it's got a mouse jiggler to stop the screensaver. And so you can see the screensaver is set to time out after one minute. And the really cool thing about this implementation of the mouse jiggler that we found is that most operating systems smooth the the output. So you don't see the mouse moving at all. So even though it's moving the mouse one pixel right and left you just don't see anything. So if everyone could brace themselves we're now going to spend a minute watching time tick on that clock. No not really. Uh so if we fast forward a minute uh Rogan and I sat there staring at the screen waiting for that that clock to tick. It's really just a show that after a minute the screensaver doesn't engage. So the user's gotten up they went to get some coffee trusting that their screensaver would kick in. It doesn't and we're now free to to launch our payload. Alright so we then moved to the attackers machine. Now obviously we're displaying these side by side. They're not going to be physically next to each other. There would be a wifi connection between the attacker and the the little device. And so we we run our attack which just pipes everything to that we're trying to do. And so here you can see it running the it popped up start run, typed in PowerShell brought up a PowerShell window and you can see in a couple of seconds it's hidden the text. So that's the first attempt at sneakiness. So user doesn't see a bunch of strange hieroglyphs flying across their screen. And then after a couple more seconds we move that window off of the screen. But keyboard input is still going into that window. If we'd hidden the window the keyboard input wouldn't go there. But you can see it's still in the task bar. Eventually after it's put in enough to start reading from the HID device we don't need the keyboard input anymore. And we can hide that window put into a proper background process. You see then on the right it says sending two five six eight bytes. That's the second stage that Rogan was talking about. And this one we're just sending the simple command shell that can speak the HID protocol that we developed. And it gives us a DOS shell back over wifi. And so we can run the latest thing we could think of calc.exe. If only my mother got this applause every time she ran calc. And then of course our trusty multi-year multi-user Maccafi license has done its job and told us the computer is secure. And don't really blame antivirus we developed this so that it's inherently not something that's going to be picked up by by those sorts of things. All right let's see if we can go back here. So that was the the basic demo. I think we're doing kind of a right on time we'll see. So defenses are kind of hard for this. Now if we're completely honest about this if you calculate the CVSS score this comes to like a five at a max because it requires physical access. But the problem with this is it's it's a very difficult problem to fix. So the the immediate and obvious solution is going epoxy or USB ports. But that's that's not a particularly practical solution. We've seen organizations that have GPOs in place that will prevent changes to their USB devices. So practically the way that manifests is you unplug your keyboard and you can't plug it back in again. I mean you can physically plug it in again but it doesn't show up. An IT guy needs to come out and type in an admin password. So those of you who run organizations that have service desks will know that that's that's probably so impractical that you'll have a large part of the user base just skipping it. Mostly executives right they'll get so mad about it they'll shout at IT and then they'll get bypassed. And so that's the the one set of defenses they're kind of uncomfortable. The stuff that you often see proposed in response to for example USB hit hit attacks in general is that we need some kind of USB authorization framework. But it's actually a really difficult problem to do. So what that would look like is you can imagine there's some kind of crypto chip in your USB devices. You know mouse your keyboard that has got some kind of signed key that means it's allowed to run on on the device. But I mean that if you look at the response to Microsoft's changes to driver side signing recently the barriers to entry then for your average hardware manufacturer get much higher and it's going to push up the cost. And even if you do all of that there's nothing really stopping us from just hooking into a legitimate keyboard signed thing to do some of these things. And so now you've got to start having like temperproof hardware and TPM chips and an entire PKI and all to try and make it much harder to plug a keyboard or a mouse in. This is an inherently difficult problem to solve. And so we're in the uncomfortable position of what are we going to write in pentest reports if we use these things. And that's kind of the point is we see real bad guys doing it from the NSA to gone variety criminals. Why don't we have an ability to detect hardware key loggers in software. This has got to be a problem that that we need to solve now. I mean hardware key loggers are using real attacks all the time. And so yeah unfortunately the defenses are really uncomfortable and hopefully will people will apply some some smart thought here and those will get a bit better. Alright so that's kind of the end but um Rogan has a polar neck and he thought he would try a Jobsian Jobsian one more thing. So going to try a live demo which is definitely not going to work. I'm just managing expectations here. Alright so let's move all the windows around. So what Rogan spent time doing last night instead of working on slides. Well let me let me leave it to you. So what I was working on last night was trying to get some integration with Metasploit framework. And I was successful in getting a shell. Uh staged shell. So Shigataka and I staged shell sent over the head interface to uh to the victim machine and running there talking back again across the head interface to an MSF console running on the attackers machine. And in order to do that um I implemented a TCP proxy that would accept a TCP connection on port 65535 to local host and then relay any connection or any data across the head interface. Nice thing about uh using local host is that your local host, your windows firewalls et cetera don't pop up any alerts for listening sockets. If you're listening on a public IP address or a public interface, a publicly accessible interface, whatever uh shall we say externally accessible interface, your firewall will pop up and say do you want to allow this um application to listen. But if it's on local host only the assumption by the firewall is that this is legit. It's an inter process communication and nothing to worry about. So on the left we have our victim, make sure our USB device is connected. So what Rogan did which I think is pretty cool is he built a little TCP proxy that would then bind to local host and so the PowerShell would invoke this thing on the the host. So that means is uh payloads which talk TCP or HTTP can now talk the HID protocol without needing to be rewritten to use the HID protocol. And so what that's one of the ways you can then use something like like meterpreter. Um and the disadvantage is it's slightly less stealthy. You're gonna have a socket on local host 65535 running as a proxy. But the plus side is you can more rapidly integrate other payloads you know your favorite um favorite malware to use this this local stealthy comms. So one of the things uh we are looking at is doing a proper integration uh into meterpreter um build a proper HID payload or HID um transport and get that uh to work natively without the TCP proxy as uh the TCP proxy does have its advantages in terms of easy implementation of additional payloads. So sacrifices done. Let's see. So this is real time this is live um gives you a real indication of how long it really takes. And so if you look on the bottom right actually maybe I should zoom in on that. You'll notice that the L host is 127.0.0.1. So this isn't going over over some local local network. Unfortunately sacrifice not accepted. I did have it working um uh ciao. Yeah alright well that was the least exciting demo of the day. Alright does anyone have any questions? Um we're gonna release the code shortly after this. You can get it on github.com slash sense post. Thanks for your time. Is there any way to detect uh that the mouse track has moved uh moved um remotely? So the question is is there a way to detect whether the mouse is moving remotely? So like the mouse jiggler specifically. Uh so not really uh to answer the question uh not really there's no feedback mechanism for a mouse. Keyboard's got a feedback mechanism with the USB uh sorry with the toggle LEDs. Mass has got no feedback mechanism so you won't get anything over the USB connection unless you've already got some code running on the device itself. You'd have to be in front of the victim's machine in order to see that the key that you're not going to see the mouse moving. This was part of it. It's moving one pixel which is actually indistinguishable. The operating system doesn't actually move the cursor at all. Um so even if you were there you wouldn't actually see the mouse moving. All you would see is that the screen saver doesn't activate. From the mouse itself you cannot query for the current x y position on it? No. Okay. You you you well in PowerShell you can. The operating system knows what the mouse point is x y is. A mouse simply emits I moved left, I moved right. So you've you the mouse itself has no idea. How quickly could you recharacterize the keyboard you're impersonating? For example uh from a corporate client point of view you might have the domain white listing a short list of USB devices. So their classic design for the keyboard or the classic design for the mouse that goes into an entire fleet purchased set of laptops or desktops and you don't start out with the same uh keyboard identification like you're not an HP for example. Right. Okay. So we're emulating emulating a standard keyboard uh obviously different keyboards have got different uh USB descriptors so given a particular keyboard that we want to copy copy the descriptor and then make sure you behave the same way. Not particularly difficult. It's probably under a day's worth of effort. Awesome talk guys. Looking forward to see the code when it's released. Uh could you say a few words about what individual people could do to prevent this on their machines not GPO solutions for enterprises but private people running I don't know Windows versions that might have some hardening features that you can use to prevent this. Um so this is what we're saying is a really difficult thing to do. If you if you implement the GPOs it makes it really difficult to use your machine. You want to plug in a flash drive denied. You want to plug in a keyboard denied. Uh you know IT has to connect over the network and authorize it. Um and that leads to all sorts of um you know impediments to actually getting your work done. Okay we're done. We can talk. We talk outside. Thanks very much.