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 possibilities of performing various attacks looking for weakness's with the clients configuration under the users context could be a serious concern. What if the user context included admin rights? Now Google 'Rubber Ducky payloads' or 'Powershell Empire'and you get the idea. 

There is 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.

Lets 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 the problems is that the client trusts HID's without question. VID\PID filtering is circumventable with spoofing the Class or Hardware ID of an approved keyboard or device. 

The obvious place to start, 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. Then for a USB Pen and it failed to trigger the scheduled task. The Kernel-PnP only generates logs on first use, the Pi Zero was generating errors and wasn't installing its drivers correctly, further investigation yielded very little.

 

Next stop the 'Advanced Audit Policy'. 

This 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.

 

For testing a local scheduled task was created and will 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).

The only setting that is a must is '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, logon 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 companies data. Repeat for each device listed.

The results, 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 my, or maybe I failed to ask the correct question....

Now some bad news before progressing, neither PowerShell or 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.

 

There's a couple of minor issues that require resolving otherwise it runs the risk of annoying the users. 

 

However enabling 'Audit PNP Activity' in Advanced Auditing and creating a trigger on 6414 does protect against keyboard attacks on an unlocked desktop. 

As well enabling the above the following should be considered as part of the defense 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