Georgios Karantzas - It's Duck Season: Forensic Detection of BadUsb Attacks

so now going back to the Mediterranean we have a fantastic guest here with us and he is actually a returning visitor so our next speaker was here in the room with us last year actually in 2019 and he decided to come back to besides to leave this time he's a speaker and he's coming to to us all the way from Greece so give a big welcome and a big F haristo to George George thank you so much George the stage is yours here's your clicker and here is your pointer right there you got it great okay uh Georgia one photo for the Press thank you all right okay so give it up for George [Applause]

so let's get started uh what we will discuss today uh is essentially how we can forensically detect bad USB attacks based on behavioral vectors not some kind of hard code identifier uh a couple of things about me I'm a researcher at bitdefender and also I study at the University of Perez so let's proceed what is the bad USB thread model how can someone be attacked by this Vector so everyone attended computer is essentially vulnerable to another temp it's just plug-in plug out that's it endpoint defenses may or may not interfere let's say that you have a rubber ducky or any other but USB let's say representative we will discuss rubber dike is because it's the most

well-known representative of the scene and they will use a well-known malicious parcel payload this will get detected but they may do something that will not get detected so we're not sure about this in our scenario we will study credential dumping and exfiltration uh so uh mainly you can think of it as daily situations that can get really weird this is just the threat model it's quite wide okay so uh what's the Let's do an introduction and uh explain the goals of This research so everything started at the Defcon stores uh obviously I had to spend money somewhere so I decided to buy the several uh gadgets one of them was rubber ducky and essentially I also bought the manual

because this is what hikers do oh okay cool so it was very a very interesting read because uh they explain how the rubber ducky works and they also explain the fact that it started as a way to automate boring sysadmin stuff so uh what caught my interest was the speed they were explaining that uh rubber ducky is designed to work at fast speeds it's a fast typer so I thought oh hey uh isn't that kind of abnormal like how fast would a human type so as I already said uh what we will focus is behavioral uh detection we will try to correlate certain information including speed to identify whether there is a malicious attempt and how are

we gonna do this we're gonna collect information from the Windows operating system so uh I think I have already covered most of this uh for this scope of This research everything we do is postmortem so we can assume that something has happened then we have the logs from some kind of agent running uh essentially we need some minimum cognitive ability we will see that we have a graph at the end of the presentation but uh either a computer or an analyst would need to have some basic cognitive capabilities to understand and correlate information so we will get deep system events and more specifically we will leverage event Racing for Windows and upper filters so a couple of things about the rubber

ducky the rubber ducky is as we said the most common representative of the bad USB scene it's a fast typer it has several cool features and it has evolved uh as the time goes by it's currently you know it's under development so it improves and improves and it introduces several very interesting features like uh vendor ID spoofing so as we said we will focus on Behavior we will not focus on IDs of any kind it has several interfaces um as you can see we have we mentioned a couple of the features it has some exfiltration you can like have some storage in it we don't care that much so uh what would care more is how we are gonna catch it and we're

gonna start with a journey into the operating system uh the limit resources so what is event Racing for Windows I'm pretty sure that uh many of you have faced uh ADR cdrs like it W uh it started as a non-security mechanism it started most Diagnostics mechanism which evolved to be one of the greatest allies of fast Defenders so what you need to know is that it's asynchronous and it's buffer based and we'll see that event Racing for Windows although it has like an extreme amount of telemetry you can ingest uh there are several limitations to it uh it can be actually uh anywhere like you can't get information from the network stock from user mode apps from drivers from the

kernel itself and we have like the sessions which is the glue between providers which is those who create the events and consumers which is uh usually your agent it's buffer based as we already discussed keep this in mind we'll explain what it means in a few seconds so these are the pros and cons we got the vast amount of telemetry we got API monitoring which is something that was impossible due to patch guard we got a pre-structured network monitoring without having to parse uh information from Network filtering driver it's easy to deploy and consume uh sometimes we can also get the call Stacks uh everyone who's in the ndr industry will understand that the call

Stacks are a gold mine for detection so what are the cons it's buffer based buffers May flood and degrade the consumption it's asynchronous so we will see some examples of what this means later on but this essentially means that events May Come unordered they may get flushed and come after a while they won't be synchronous they they won't follow a certain order which is actually pretty bad and it limits what you can do with it especially if you want to do some memory scanning or something so there's a lot of performance overhead it's prone to timing attacks due to a synchronicity mainly you can exploit the fact that timing is inconsistent will show examples right now so let's what I will

do now is explain to you a couple of things that happened to me while I was experimenting I wanted to detect via ADW memory patching and position dependent code or Shell Code if you like so essentially we had logical issues if we did something real fast there was the possibility that the process would die there would be another process created with the same PID reassigned and we would end up with a memory scanning of a legitimate process so we're entirely missing the detection memory processing issues maybe some module gets unloaded maybe something changes in memory it's not guaranteed it will work so there's a performance impact ADW gives you a lot of telemetry but also a lot of performance impact and

also what I didn't mention earlier is that by Design events will be missed what do I mean by that uh in the previous slides you saw a screenshot that screenshot was from MSD and it was essentially Microsoft admitting that events will be lost eventually it's not designed to be foolproof it's not designed to be 100 accurate if you don't consume fast enough for example or if the event is too large it may get dropped it's the whole architecture so also we can have like false positives what I mean by that if interesting for Windows will record everything that happens in the process but imagine this imagine that you have an anti-exploit agent or an ADR agent isn't it going to

do some hooking isn't it going to use sensitive apis uh isn't the windows load they're going to use this kind of apis as much as the overhead is increased the chances of a false positive increase as well so let's move a little faster so ew is not for everything but it actually is something uh that could be of use to us for this experiment it has a lot of settings has a lot of apis uh that deal with it internally uh it's quite complex so Microsoft uh provided us with carb cityw which is a great interface for it and this is how essentially the atw agent I created worked who had some handlers in a

separate namespace we set those handlers from the manager the manager interacts with event Racing for Windows and we have a file logger and we lock the files so let's move forward these are the providers we will use we will get image load events process creation events and PNP devices that are being created so let's move to something else what happens when you press a key on your keyboard uh so a user presses the key there is an interrupt triggered the keyboard controller essentially handles the data [Music] we won't go into much detail with this because they're complex and I want to I want us to focus on uh we don't have much time so I want us to

focus on these specific uh two steps uh at some point the keyboard class driver will create an IRP therapy will be processed between these two there is a routine that will be called and this is what we will hook later on here uh therapy is being processed travels the driver stuck but here is the Casual um completion retina replacement rootkit technique it's the most common way that you would intercept uh this kind of keystrokes but we faced problems with it we wanted something friendlier and more Universal so let's see here's the keyboard stack we will ignore it for the moment and focus on the ups and downs so it's synchronous but it's not PMP aware the

Casual when we're talking about the Casual completion retain hook and uh here is a different approach we will connect we will use connect data to hook a certain routine we will see which one later but it's more PMP aware we're able to use kmdf2 attach to devices Etc there is a higher success rate across machines and it's also synchronous but what do I mean by higher success rate at those machines if you run this one the Casual one on the VM it would work if you would run it on the random physical machine who knows maybe you will get a blue screen this is what I got so we ended up going with this approach

uh here's what the kmdf driver will do the kmdf driver will essentially be registered in the registry as an upper filter driver we will receive PMP callbacks we will create a device we will add our device in the context of that driver as a filter we will config create and config an ioq which will give us essentially a foothold to this ioctl this ioctl is our Gold Mine which will connect which will have this struct connect data and the class service routine which will be called uh so uh actually there will be the key press there will be the ISR and it will be cured this routine will be killed as a DPC to work

it's to transfer data so uh this is our hook and to place our hook we will essentially have the usb hid which will create the CTL uh yeah the IRP and it will travel upwards towards our kbd class Hopper filter and that's the point we will place the hook below is the point where the hook will be called uh so a couple of notes we want to avoid mistakes of the past at some point Microsoft had planted a key loader for uh external USB devices um it was being used by partial Empire at some point I tried using it didn't succeed for some reason maybe it was silent fixed who knows but it was being used as a keylogger and

also there's another incident uh HP was using a driver which was actually keylogger the HP planted the key logger on your machine and they are out that they uh that Telemetry catched through um 380w so you could consume uh thank you CW close 7 for this one if you have been around the rocketab and other forums you probably know him great guy he has helped a lot although he doesn't know it so this is the data we will need to consider the keystrokes and the speed of the keystrokes the processes the images loaded and PNP devices let's see how these start working together these are some sample logs you will see that you this name

it reads atmel and if you take a look at the rubber ducky you will see that this chip has the word Admiral in it so it starts getting fizzy you will say try the usb.6 getting low that what does this mean that somebody plugged the USB device uh you will see after that the partial uh it's totally legit I suppose all these events one after the other it's a little coincidence uh and here is what we would get in a graph because you know an experience forensic analysts would have no problem uh sorting out these logs Etc but we're human we like something more uh friendly towards our cognitive capabilities and something that will help us have a clear

view so what you see here is human typing normal human typing what you see here this peak means that the device was added here you will see suddenly a peak some fast typing then you will see some uh partial activity that partial was launched after the fast typing and this is definitely a human typing impartial right so everyone can understand where this is going so before you ask can't I spread the keystrokes with slips uh could then I just evade the with some proper timing uh yeah the thing is that you would definitely expose yourself because let's consider you're a marketing person or an HR person and someone plugs uh the malicious USB and you see partial

starting typing on its own at a regular speed wouldn't this raise your suspicion the least you could do is just close the window and break the attack so uh this is a possible scenario I'm describing so the gadget has to be fast and it has to be plug-in plug out so can the detection model be automated and made real time maybe have an agent that is need VR for uh in the Rapp for this kind of attacks maybe but you would have a lot of issues to deal with mostly timing issues and how would you process the models how would you design the patterns the malicious patterns how would you detect certain different kinds of Peaks like

what if someone had one Peak one second sleep another Peak still model issues still weird you would need to somehow be able to identify that so uh we finished a bit early uh uh this is pretty much it I will be happy to answer any of your questions uh either here or uh in private after the talk so thank you very much [Applause] thank you George or as we say in Greece something like something like that okay