top of page

P4WNP1, Rubber Ducky, BadUSB vs Windows 

 

In the previous article, it was demonstrated that a Pi Zero acting as a keyboard can steal the documents from an unlocked client. This was a simple but effective demo, the possibility of performing various attacks looking for weaknesses with the client configuration under the user's context could be a serious concern.  Now Google 'Rubber Ducky payloads' or 'Powershell Empire' and you get the idea. 

​

Here's a simple question 'Is it possible to defend against HID attacks?'

​

The simple answer is 'yes', instruct your users and yourself to never walk away from the client without locking the desktop, easy, all sorted and the end of the article.........

 

In the real world, in a busy office with many distractions its not so easy to remember.

​

Let's ask the question again, is it possible to protect against HID attacks when the client is unlocked? 

​

The answer is fairly surprising, Google informs me that there's very little to prevent these types of attacks in the real world, without investing in expensive 3rd party software. Requirements by the business to allow usb devices etc potentially weaken the 3rd party software capabilities. One of the problems is that the client trusts HID's without question. VID\PID filtering is circumventable by spoofing the Class or Hardware ID of an approved keyboard or device. 

​

The obvious place to start, are the event logs and the Kernel-PnP logs with events 400, 410,411 and 430. Looks perfect, full of events from my testing of the Pi Zero. Now what to do about those events, a scheduled task that triggers locking the desktop. This was too easy and I should have realised......Testing against the Pi Zero would indeed lock the desktop. Now for a USB Pen and it failed to trigger the scheduled task. The Kernel-PnP only generates logs on first use, and the Pi Zero was generating errors and wasn't installing its drivers correctly, further investigation yielded very little.

 

Next stop, the 'Advanced Audit Policy'. 

​

Again looks promising 'Audit PNP Activity', 

After enabling for both 'Success' and 'Failure' in Group Policy, gpupdate /force and hey presto, events 6416 are being created when a USB device is inserted.

 

Create a local scheduled task to execute on various 'on-event id's and under the context of the user.

Create the 'on event' triggers for:

​

Security EventID 6416

Security EventID 6420 (optional)

Security EventID 6422 (optional)

​

Kernel-Pnp > Device Configuraton EventID 400 (optional)

Kernel-Pnp > Device Configuraton EventID 410  (optional)

Kernel-Pnp > Device Configuraton EventID 430  (optional)

​

Create the following action:

​

Program/Script: 'rundll32.exe'

Arguments: 'user32.dll,LockWorkStation' (case sensitive).

​

Set 'Start the task only if the computer is on AC power', ensure its unchecked so the task runs whilst on battery.

 

Now for testing of the on-event scheduled task against the following devices:

​

  • Pi Zero P4wnP1 alao

  • Rubber Ducky

  • Bash Bunny

  • Lan Turtle

  • Samsung T5 External SSD

  • Various USB Devices

  • Micro SD

​

The test is simple, login as a user, domain or local and insert a usb device. If the device is detected then the desktop will lock and the attack prevented, saving the user embarrassment and the company's data. Repeat for each device listed.

​

The result, each of the listed devices locked the desktop, its then possible to prevent the HID attacks against an unlocked client, a positive result. Google you failed me, or maybe I failed to ask the correct question....

​

Now some bad news before progressing, neither PowerShell nor GPO Preferences support creating scheduled tasks based on 'on-event' triggers. Deployment in an enterprise will require ConfigMgr or something similar.

​

And some more bad news, the HP Network MFD triggers 6416 events advertising itself as a usb device on the network, this locked my desktop numerous times.

​

Finally, logging on too quickly after a reboot almost instantly locks the desktop. A small pause at the logon screen is needed before entering your credentials.

​

However enabling 'Audit PNP Activity' in Advanced Auditing and creating a trigger on 6414 does protect against keyboard attacks on an unlocked desktop, it's annoying, especially to the user and soon to be an angry user.
​
Alternatively, the following should be considered as part of the defence in depth.

​

  • User education

  • Disable the Run Command

  • Disable PowerShell

  • Enable VID\PID filtering

  • Forced encryption of USB devices

  • Monitoring USB and Powershell activity

  • Disable USB Devices in Bios

  • Invest in a 3rd party security product

  • Separate accounts for admin privileges, preventing UAC

​

​

​

​

​

bottom of page