We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Universal Serial aBUSe

00:00

Formal Metadata

Title
Universal Serial aBUSe
Title of Series
Number of Parts
93
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
In this talk, we’ll cover some novel USB-level attacks, that can provide remote command and control of, even air-gapped machines, with a minimal forensic footprint, and release an open-source toolset using freely available hardware. In 2000, Microsoft published its 10 Immutable laws of security [1]. One of which was “if a bad guy has unrestricted access to your computer, it’s not your computer anymore.” This has been robustly demonstrated over the years. Examples include numerous DMA-access attacks against interfaces such as firewire [2], PCMCIA and thunderbolt [3] as well as USB-based attacks including simple in-line key loggers, “evil maid” attacks [4] and malicious firmware [5]. Despite these warnings, groups such as the NSA were still able to use physical access to bypass software controls with toolsets such as COTTONMOUTH [6]. Likewise, criminals have been able to defraud banks with a handful of simple hardware tricks [7]. While some progress has been made to secure some devices against some threats, such as the use of full disc encryption, or the impact of Apple’s secure enclave in the physical security of the iPhone [8], most laptops and desktops remain vulnerable to attacks via physical interfaces. In our experience, organizations merely view USB devices as a channel for malware or unsanctioned communications, and rely on protections placed elsewhere in their defensive stack to deal with them, but few deal with the risk the USB interface presents directly. There are many scenarios where gaining physical access to hosts is plausible [9], and having done so can provide access to “chewy” internal networks [10] ripe for lateral movement. While most people are familiar with USB devices, many don’t realize the extent to which the USB standard allows seemingly innocuous devices to have multiple personalities. There has been an extensive amount of research into malicious USB devices, such as TURNIPSCHOOL [15], GoodFET/Facedancer [16], Shikra [17], Rubber Ducky [11], USBdriveby [12] and BadUSB [5]. However, none of these implement an end-to-end attack either because that was not their intention, they only focus on a part of the attack or the project was never completed. Additionally, existing attacks are predominantly “send only” with no built-in bidirectional communications. They usually rely on the executed payload and the host’s networks for any advanced remote access. Thus, these payloads can leave a significant forensic footprint in the form of network communications and on-host behaviors, and leave them vulnerable to anti-malware controls. Numerous companies are improving toolsets to detect such attacks [13][14]. Lastly, these attacks are often “spray and pray”, unable to account for variations in the user’s behavior or computer setup. Our approach is to create a stealthy bi-directional channel between the host and device, with remote connectivity via 3G/Wi-Fi/Bluetooth and offload the complexity to our hardware, leaving a small simple stub to run on the host. This talk will discuss the process of creating a set of malicious USB devices using low cost hardware. The design and toolkit will be released during the talk. Bios: Rogan Dawes is a senior researcher at SensePost and has been hacking since 1998, which, coincidentally, is also the time he settled on a final wardrobe. He used the time he saved on choosing outfits to live up to his colleague’s frequent joke that he has an offline copy of the Internet in his head. Rogan spent many years building web application assessment tools, and is credited as having built one of the first and most widely used intercepting proxies; WebScarab. In recent years, Rogan has turned his attentions towards hardware hacking; and these days many suspect him to be at least part cyborg. A good conversation starter is to ask him where he keeps his JTAG header. Dominic White is the CTO of SensePost, an information security company based in South Africa and London. He has worked in the industry for 12 years. He tweets as @singe.
33
35
ImplementationRemote Access ServiceInterface (computing)Computer networkComputer hardwareSoftwareCASE <Informatik>Right angleRemote procedure callImplementationPhysicalismSet (mathematics)Line (geometry)
Hacker (term)Software testingAngleOffice suiteTwitter
Hausdorff spaceProcess (computing)EmulatorSoftware bugSoftware testingEndliche ModelltheorieReal numberSelf-organizationMultiplication signQuicksortInformation securityDesign by contractDisk read-and-write headInformationMeeting/Interview
Product (business)Computer hardwareStructural loadPolar coordinate systemSoftwareComputer networkVideo GenieSineConnected spaceKeyboard shortcutCommunications protocolMereologyRemote administrationComputerComputer hardware
Different (Kate Ryan album)Game theorySoftwareSimilarity (geometry)Proxy serverComputer hardwareRemote procedure callMultiplication signGraph coloringGame controllerComputerCharacteristic polynomialInformation securityCuboidNP-hardMedical imagingHard disk driveDatabase transactionRight angleQuicksortPasswordSeries (mathematics)Greatest element
QuicksortComputer hardwareAverageClient (computing)AuthorizationData storage deviceFirewall (computing)Computer networkPlastikkarteMalwareVirtual machineStandard deviationRemote procedure callMass storageObject (grammar)Computer animation
Large eddy simulationDemosceneElectronic signatureProxy serverSoftware developerPoint (geometry)WordVector spaceSelf-organizationIntrusion detection systemPlastikkarteComputer iconComputer wormSound cardObject (grammar)Multiplication signScreensaverSoftwareMalwareQuicksortGame theoryComputer hardwareMatching (graph theory)Gastropod shellPosition operatorMass storageGeneric programmingComputer forensicsComputer animation
Social classHacker (term)Disk read-and-write headScripting languageCuboidGoodness of fitComputer hardwareExistenceGame controllerMultiplication signKeyboard shortcutComputer animation
MicrocontrollerFamilyRevision controlCoprocessorFlash memoryCombinational logicPrototypeComputer hardwareCASE <Informatik>Data mining
Data storage deviceLine (geometry)Flash memoryMicroprocessorWhiteboard
Human resource management systemFlash memoryCoprocessorModulare ProgrammierungLink (knot theory)Software frameworkWhiteboardDataflowLinker (computing)Different (Kate Ryan album)Connected spaceStandard deviationVariety (linguistics)FirmwareGame controllerSerial portMicrocontroller
Computer programVideo gameAreaServer (computing)MicrocontrollerMassOrder (biology)Communications protocolSoftwareData compressionGame controllerComputer animation
Reverse engineeringPixelKeyboard shortcutRight angleAuditory maskingSound cardDevice driverWindowTouchscreen2 (number)ScreensaverVirtual machineGame controllerSocial classBit rateExterior algebraDefault (computer science)Interface (computing)SoftwarePhysical systemEvent horizonSpherical capMassNumberMIDIGoodness of fitComputer animation
WindowTelecommunicationOrder (biology)Social classProcess (computing)Computer animation
Level (video gaming)Level (video gaming)WindowOrder (biology)TouchscreenProcess (computing)Graph coloringType theoryComputer wormVirtual machineGeneric programmingCodeTotal S.A.2 (number)Maxima and minimaDreizehnScripting languageAverage
TelnetLevel (video gaming)Data typeLarge eddy simulationComputer wormLengthLevel (video gaming)Multiplication signGastropod shellCausalityPower (physics)
Large eddy simulationMathematical optimizationComputer wormArithmetic meanType theory
Exterior algebraKeyboard shortcutDifferent (Kate Ryan album)Power (physics)Gastropod shellCodeCodierung <Programmierung>Quicksort
Type theoryComplete metric spaceTotal S.A.Computer wormCodeBuffer solutionCoprocessorGame controllerVirtual machineMultiplicationProcess (computing)Dataflow32-bitBit
Level (video gaming)Multiplication signWindowTelnetSerial portServer (computing)Order (biology)Line (geometry)Link (knot theory)Adaptive behaviorBuffer solutionTouchscreenMultiplicationDirection (geometry)CoprocessorVirtual machineFunction (mathematics)Component-based software engineeringScripting languageFirmwareMetropolitan area networkFigurate number
ImplementationPolar coordinate systemSharewareGodVideoconferencingCodeAreaComputer hardwareChainBitExistential quantificationLevel (video gaming)Library (computing)Computer programSoftware frameworkStack (abstract data type)Functional (mathematics)Mobile WebTelnetDirection (geometry)
Computer networkRight angleVirtual machineSoftwareConnected spaceWindowDefault (computer science)MereologyComputer iconComputer animation
ScreensaverScreensaverFunction (mathematics)PixelPhysical systemImplementationRight angleTouchscreenVirtual machineComputer wormConnected spaceSmoothing
WindowTouchscreen2 (number)outputWindowKeyboard shortcutGastropod shellProcess (computing)Multiplication signProper mapComputerRight angleDensity of statesAntivirus softwareCalculusMehrplatzsystemCommunications protocol
SharewareQuicksortRight angleSharewareMultiplication signSelf-organizationKey (cryptography)Software frameworkCryptographyMathematicsProcess (computing)System administratorBitOperating systemDependent and independent variablesAuthorizationPasswordService (economics)Variety (linguistics)Set (mathematics)NP-hardKeyboard shortcutMaxima and minimaSoftwareTraffic reportingComputer hardwareMereologyPoint (geometry)Device driverSign (mathematics)Position operatorType theorySoftware testingVapor barrierAverageProof theoryReflektor <Informatik>
Expected valueSharewareProcess (computing)Multiplication signWindowMetasploit-FrameworkDisk read-and-write headGastropod shellProxy serverConnected spaceVirtual machineOrder (biology)Slide ruleFirewall (computing)INTEGRALVideo game consoleMereologySocket-SchnittstelleComputer animation
Firewall (computing)IP addressInterprozesskommunikationCartesian coordinate systemLocal ringSource code
Communications protocolProxy serverKeyboard shortcutComputer wormBookmark (World Wide Web)Network socketLocal ring
Real-time operating systemComputer wormMalwareImplementationProxy serverProper mapINTEGRALAdditionPrice indexTerm (mathematics)Computer animation
Gastropod shellIn-System-ProgrammierungCodierung <Programmierung>Level (video gaming)Reverse engineeringComputer wormHaar measureLocal area networkRight angleJSONSource code
Direct numerical simulationSharewareCodeKey (cryptography)PixelVirtual machineOrder (biology)Ocean currentPosition operatorCursor (computers)Query languageConnected spaceKeyboard shortcutPoint (geometry)View (database)MassClient (computing)Public domainElectronic mailing listPhysical systemOperator (mathematics)Different (Kate Ryan album)WordEnterprise architectureSystem identificationEntire functionPurchasingFeedbackLaptopQuicksortSet (mathematics)Operating systemTrailRevision controlScreensaverFlash memoryMereologyWindowRight angleMultiplication signPartial derivativeLatent heatComputer animation
Transcript: English(auto-generated)
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? K, 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, 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 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 mugshot ended up going viral and he got a modelling contract afterwards. So you get a threat model.
Eh? Nah, okay. 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 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 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 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'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, it 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, 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 3 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 keyloggers 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 that 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 Lee Tax. 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 there's probably a swathe of things in between, where people are using a similar kind of attack, hardware bypasses of
software security, but, um, 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 wifi 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, the attacks that 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 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 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 making 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, uh, malware that, 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. 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. And 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, 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 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 back channel, 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 release today and develop signatures for that as is they want. But we can very quickly change these simple payloads to avoid that and they'd kind of be 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 main six objectives we were going for with this work. So, like everybody, we built, um, on the shoulders of giants. Um, we were 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 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 dancer boards, um, devices from
Travis Goodspeed and Sergey Bratis, um, have shown that there's a lot of, uh, capability in the, in the USB, um, classes. Um, the NSA playsets 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, Sami 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, Seung Hoon Han's Iron Head did some similar things to what we're going to 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 wifi microcontroller on it, as well as an Atmega, an, uh, Atmel Atmega 32U4 AVR processor on it. Um, so,
the reason this was important for us, the wifi gives us a comms 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 could 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 when I bought, when I bought mine, um, and it's got the, the basic capabilities that we need, the wifi 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, a
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 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's talk about
the, 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 wifi, 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. And 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 loofer framework, which is a, um, a, a, a, a, a, a, a, a
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 of the USB interface and be seen by the victim. And so I started off by looking at what the actual bytes are that are needed to send those
characters. And you need to send 7 bytes and character A is byte 3, 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, 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 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, um,
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, thinking that we could extract data using the keyboard LEDs, the scroll lock and the, 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 reckoned that wasn't good enough and, uh, explored some other alternatives. Um, other alternatives that we, that we considered were, um, devices such as, uh, text only printers, um, 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, 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 screen saver from kicking
in. And it works pretty well if you only do one pixel, it doesn't actually disturb the screen saver 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 screen saver will stay active. As soon as somebody unlocks the screen saver 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 back channel communications and in order to do that we used, for this particular exploit, uh, 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, 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 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, 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 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 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 two thousand, two thousand. 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
payload is to make that window disappear from the taskbar. From start to finish we process takes about three seconds before the, um, the text becomes invisible, about five seconds before it disappears off the window and thirteen seconds in total for it to
disappear from the taskbar. So that's pretty quick. It's averaging between sixty and ninety 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. Um, one that spawns a command shell which we'll show you. Um, 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 cause I think we're gonna 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 as stealthy 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 to, to get the thing across. Um,
we tried some other things so we ran into some issues with alternative keyboard layouts. Uh, so we were 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 size 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 gonna 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 pro- 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 hair out, um, to be quite honest. You start off with the attacker's machine which is a multi-gigahertz desktop. You're talking to an 80 megahertz 32 bit processor dealing with 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 attacker's 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 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, the problems though, you're debugging so you've got no, um, 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 won 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'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, 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 WiFi 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, 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
imagined that it's got a mouse jiggler to stop the screen saver. And so you can see the screen saver's set to time out after one 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. 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 gonna 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 screen saver doesn't engage. So the user's gotten up, they went to get some coffee, trusting that their screen saver 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 gonna 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 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 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 and put it into a proper background process. You'll see
then on the right it says sending 2568 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 over wifi. Um, and so we can run the latest thing we could think of, calc dot exe.
If only my mother got this applause every time she ran calc. And then of course, our
trusty multi-year, multi-user McAfee 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. Alright, let's see if we can go back here. So that was the, the basic demo. I think we're doing 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 5 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 going epoxy or 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 IT 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 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, 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
side, signing recently, uh, the barriers to entry then for your average hardware manufacturer gets much higher and it's gonna 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 gotta 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 gonna write in pen test reports if we use these 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 keyloggers in software? Um, this, this has gotta be a problem that, that we need to solve now. I mean hardware keyloggers are using 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 polo neck and he thought he would try a Jobzian, Jobzian one more thing. So we're gonna try a live demo which is definitely not
gonna 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, 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, a staged shell, so Shigata Ganai staged shell, sent over the hit
interface to, uh, to the victim machine and running there, talking back again across the hit interface to an MSF console running on the attacker's machine. And in order to do that, um, I implemented a TCP proxy that would accept a TCP connection on part of the
network, port 65535 to local host and then relay any connection or any data across the hit 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? But if it's on local
host only, the assumption by the firewall is that this is legit. It's an interprocess communication and nothing to worry about. So, on the left we have our victim. Make sure
our USB device is connected. So what, 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 what 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. Um, and so what, that's one of the ways you can then use something like,
like Maturpreter, um, and the disadvantage is it's slightly less stealthy. You're going to have a socket on local host 65535 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, uh, we are
looking at is doing a proper integration, uh, into Maturpreter, 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, 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.
Unfortunately. Sacrifice not accepted. I did have it working, um, but yeah. Yep, alright, well that was the least exciting demo of the day. Alright, does anyone have any
questions? Um, we're going to 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, uh, moved, um, remotely? Sorry, so the question was, is there a way to detect whether the mouse is moving remotely? So like the mouse jiggler, specifically. Oh, not really, to answer the question. Uh, not really. There's no
feedback mechanism for a mouse. Keyboard's got a feedback mechanism with the, 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 the
key, the, 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 XY position on it? No. Okay. You, you, you,
well, in partial 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 their classic design for the keyboard or the classic 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 em- 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 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 you were 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 know, you want to plug in a flash connection, 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 can talk outside. Thanks very much.