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
wanna walk out after that? Yeah. Okay, so we're from a company called SensePost. Uh,
we've got an office in, in South Africa, in London. We came all the way from South Africa. It's a
long flight. Uh, we're predominantly a penetration testing. Oh, 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, does 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 Sinj on Twitter and Rogan is at Rogan Dawes 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 who's mugshot and
ended up going viral and he got a modeling contract afterwards. So you get a threat model.
Eh? 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 DEFCON. 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, I think a pen tester's job is, is to realistically emulate
actual bad guy attacks. So things real bad guys are doing that'll 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, let's, let's, let's, let's, let's, let's, let's, let's, let's, let's, let's, let's, let's,
let's start talking about some real bad guys. So if the NSA's 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 comms off the host, 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, uh, 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 buy, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh,
bypass the software controls in place. Uh, so the first thing were hardware key-loggers in the
bottom left-hand corner and 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 on 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 leet-hacks. These were criminals paying people, it's kind of the way crimes
worked for, for a long time. And they were wildly successful. We're 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 there's probably a
swathe of things in between, where people are using a similar, similar, similar, similar
kind of attack, high, hardware bypasses of software security, but, um, it, 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, 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's 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, uh, the text we're gonna show today, there's ways that you can, uh, you can, uh, do
them, and you can, and you can. It's not, it's not a big deal, it's a pretty big deal to
using our machine that we 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 six-fold.
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. And so we didn't want to demonstrate one or two concepts, we wanted the
whole thing to work from plugin 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. But beyond that we didn't want to have to be fiddling with things.
It must be automated. Then this was quite an important design goal for us. We wanted to use a
covert back channel. And that's fancy words for it mustn't be a network card. So we wanted to
get into it in more detail but we used innocuous looking USB devices. Text printers, sound cards,
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 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 a
our own RF back channel, it's not going through the network of the target device or the target
organization. So things like FireEyes and IDSs 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 then
the second thing is most of the payloads that we're running are really based off of the
different kinds of
stuff that we launched today. So obviously we have umch changes that work with the
userstands. And so we're going to be using relayığınits, which are the?? other dist 108 code lic?
these were 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's Plug and Pray from 2010 or 2009. Um, his malicious USB devices, he did, uh,
some, some really good work there. Um, Hack 5's Rubber Ducky has also been around for a long
time. So, the, the concept of a malicious HID 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
FaceDancer boards, um, devices from Travis Scott, uh, and, uh, uh, uh, uh, uh, uh, uh, uh,
Travis Goodspeed and Sergi Bratus, um, have shown that there's a lot of, uh, capability in
the, in the USB, um, classes. Um, the NSA Playset's 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, Samy Kankar has done the, the USB drive-by, which is a
keyboard and mouse device, uh, 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, Singhun Han's Iron
Head did some very similar things to what we're gonna show you today. Um, but that was released
after our DEFCON 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,
Atmel Atmega 32U4 AVR processor on it. And the reason this was important for us, the Wi-Fi gives
us a COM's channel and the, uh, the AVR traffic. Uh, uh, uh, it's a reason, uh, we didn't need to, uh,
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 that's that's that's
it. 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 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 uh 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 and then I'm going to show you how it works. 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 capabilities to use. So the attacker can use a lot of
things that he needs 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. Just connected via a serial link, a UART. The AVR processor is using the Lufa
framework which is a uh a uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh
software package for the the AVR processor that allows it to show up or to emulate um 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 the 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 wifi and send those bytes that needed to come out the other side. But that ran into a problem and
things like dealing with alt tabs and control alt delete 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 mouse 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 uh 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 mouse movements uh as
required. The other aspect of the um of the AVR is that it can provide multiple uh 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 mouse comms. Um there's a number of different ways that you can use it. There's a number of
different ways that you can use it. We were 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 uh explored some other alternatives. Um other alternatives
that we uh used were the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh
the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh
the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh
the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh
the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh
the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh
the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh
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, um, 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, uh, 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, um,
this additional pipe. So we've launched our, um, our basic exploit, and now we need to have this
backchannel communications. And in order to do that, we used, for this particular exploit, uh, or
demonstration, we used a generic keystroke channel. And, uh, the keystroke channel is, uh, 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, uh, administrative privileges required in order
to access the generic HID device. So the process goes, um, like this. We use a scripted VNC
tool to type out our stage zero attack. Our scripted VNC tool, uh, allows us to type out our stage
zero attack. The stage zero attack, then, is as minimal as possible. The, the bare minimum code
that we could, um, arrive at, that would open up that generic HID interface and then read more
data from that. A 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, well, we,
the, the code we ran, set the foreground text to be the, to be the same color as the background, and
then clear the screen. So you get a clear, a blank screen just showing up on your, 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. And, uh, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we,
can move it 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. Um, and
it can continue to receive keystrokes even when it's no longer visible. It does still remain in
the taskbar, however. Because it has to, in order to receive those keystrokes. The last thing
we do, once we've finished executing our process, is take a look at the key bin now. And that's
payload is to make that window disappear from the taskbar. From start to finish, the- the
process takes about 3 seconds before the, um, the text becomes invisible, about 5 seconds
before it disappears off the window, and 13 seconds in total for it to disappear from the
taskbar. So that's pretty quick. It's averaging between 60 and 90 characters per second for
our typing. Once our stage 0 payload is running, we then send a stage 1. It's a very simple
payload, but it can be as complex as you want it to be. The stage 0 simply reads a 2 byte
length, and then that many bytes of PowerShell to execute. So some examples of a stage 1 we
have, um, one that spawns a command shell, which we'll show you, um, and then the other
one. We've got another one that takes a screenshot of the victim's desktop and sends it back
as a JPEG. Um, and we've got some other payloads that we're still playing with that, um, 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- the big problems with this is you need to make
sure that that initial typed payload is a standard payload. So, um, we've got, um, we've got
to make sure that that initial typed payload is as healthy as possible. Um, and I think we've
come up with some fairly decent optimizations that- that mean we can- we can type an incredibly
small payload. So our- our sneakiest payload is about just less than a thousand characters,
um, which can be typed pretty quickly. Um, and, uh, 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. Um, and, uh, and, uh, and, uh, and, uh, and, uh,
we, we're, we're able to, uh, we're able to, uh, you know, we're able to, um, to get the thing
across. Um, we tried some other things. So, we ran into some issues with alternative keyboard
layouts. Uh, so, we're using a UK keyboard layout versus a- a USA keyboard layout. And
different characters come through differently, particularly when you're typing, sort of,
semi-advanced PowerShell code. One of the- the easy solutions would be to Base 64 encode that,
but those of you who've played with things like Empire or PowerShell's Base 64 encoding, that
ends up, like, over-doubling the site. So, um, uh, you can even have a- it can be read in an sort of, uh, uh, uh,
of the characters required because of the way it does the base 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. Um wasn't really worth the effort. Um 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 be helpful for some of you.
So some of the other prob- uh some of the other problems we ran into were um flow control
issues. So the process of developing this was one of pretty much pulling my head back
and hair out um 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 the
wifi 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 um
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 a 128 byte FIFO uh 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 the problems though you're debugging so you've got no um you know no
screens or anything like that to see what's happening. So you've got no um you know no
data 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 it's 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 uh it's got a lot of
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 would just send it to the other
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 you can start
processing it. So it clings up very quickly as we go along. You remember first after stage two
uh cloud you need to wait, before stage one starts trying to be processed and then any subsequent
stages. So it became um a little bit of um a dance if you like. Uh 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 won and to control
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're 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 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. It 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 gonna try and show you a video demo. We're gonna 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 your 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's set to time out after 1 minute. Um 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. Um so now you're watching your own program as you're using the
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 to 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 move to the attacker's 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 that we're trying to do. And then we run our
machine. 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 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. Um 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 that the keyboard input is still going into that
window. You can see it's still in the taskbar. 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'll see then on the right it says sending two
five six eight bytes. That's the the second stage that Rogan was talking about. And this one we're
just sending the simple command shell. That can speak the the hid protocol that we developed. And
it gives us a a DOS shell back overall. So we can see it's still in the taskbar. We can see it's
a wifi. Um and so we can run the latest thing we could think of. Calc dot exe.
Ah. If only my mother got this applause every time she ran calc. And then of course a trusty
multi-year, multi-user McAfee license has done its job and told us the computer is secure. And
so we 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. Alright 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. Um 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. Um but the problem with this is it's it's a very difficult problem to fix. So the the
immediate and obvious solution is go and epoxy your USB ports. But that's that's not a particularly
practical solution. Uh we've seen organizations that have GPOs in place that will prevent
changes to their 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 I.T.
guy needs to come out and type in an admin password. Uh 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 I.T. and then they'll get bypassed. Um 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, your 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 sign signing recently um the barriers to
entry then for your average user. Um so that's that's that's that's that's that's that's the
problem. So that's the big thing that we've got to work on. And the other thing that we're
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 tamper proof 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 pen test reports if we use these things. And so we're
things. Um and 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? Um this this has got to be a problem that that we need to solve now. I mean
hardware key loggers are used in real attacks all the time. Um and so yeah unfortunately the
defenses are really uncomfortable and hopefully we'll people will apply some some smart
thought here and uh 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 we're
going to try a live demo which is definitely not going to work. I'm just managing
expectations here. Alright so let's let's move all the windows around. So what Rogan spent
time doing last night instead of working on slides. Well list me let me repeat this.
Your're at the table right? Oh you want to talk, okay. So what I was working on last night was
trying to get some integration with medisploit framework and I was successful in
getting a shell uh staged shell so shigat studied a staged shell sent over the hidden
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 your windows firewalls etcetera 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. And then you can
get a message from the person 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 we've got a
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 host. So that
means is payloads which talk TCP or HTTP can now talk the HID protocol without needing to
be rewritten to use the HID protocol. And 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 six five five three five running as a 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 that Rogan
is 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, sacrifice is done. Let's see. So this is real time, this is live, this is a live
um gives you a real indication of how long it really takes.
And 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.
Nope, it died. Unfortunately. Sacrifice not accepted. I did have it working um but yeah.
Yep, alright well that was the least exciting demo of the day.
Thank you. Alright does anyone have any questions?
No? Great. Um we're gonna release the code shortly after this. You can get it on
github.com slash sensepost. Thanks for your time. Is there any way to detect uh that the mouse
track has moved moved uh moved um remotely? Sorry 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 to answer the question. Uh not really there's no feedback on that. It's just a
mechanism for a mouse. Keyboard's got a feedback mechanism with the USB, sorry, with the toggle
LEDs. Mouse 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 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 screensaver doesn't activate. So, from the mouse
itself, you cannot query for the, from the mouse itself, you cannot query for the current XY
position on it? No. Okay. You, you, you can't, you can't, you can't, you can't, you can't
in PowerShell. Well, in PowerShell, you can. The operating system knows what the mouse
pointer's XY is. A mouse simply emits, I moved left, I moved right. So you, you, the mouse
itself has no idea. Uh, how quickly could you re-characterize the keyboard you're
impersonating? For example, uh, from a corporate client point of view, you might have the
domain whitelisting a short list of USB devices. So, they're clashing, they're, they're
clashing design for the keyboard, or the clashing design for the mouse that goes into an
entire fleet purchase 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
emulate, 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. Uh, it's, it's probably under a day's worth of effort.
.
Awesome talk. Awesome talk, guys. Well done. 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 to be, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh,
uh, work with? Or is,s, maybe we can't actually. I didn't mean to rush over this into your
first question. Just do a little, just a little more. Uhm. So the, this is what we were
saying was a really difficult thing to do. I'll, if you, if you implement the GPOs. It makes it
really difficult to use your machine. You know, you want to plug in a flash drive? Denied. You
wanna plug in a keyboard? Denied. Uh, you know, IT has to connect over the network and
authorise 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 can talk outside. Thanks very much.