Ducky USB - Indicators of Compromise (IOCs)
-
Upload
brent-muir -
Category
Technology
-
view
1.533 -
download
9
description
Transcript of Ducky USB - Indicators of Compromise (IOCs)
DUCKY USB
A brief paper on the Ducky USB pentest device; indicators of
compromise on a system and risk mitigation from this attack vector.
INDICATORS OF
COMPROMISE
BRENT MUIR
2014
Brent MUIR
1
Table of Contents Introduction .................................................................................................................................................. 2
Installation IOCs ............................................................................................................................................ 4
Fragments of the payload ........................................................................................................................... 12
Risk Mitigation ............................................................................................................................................ 14
Tools required to replicate my findings ...................................................................................................... 15
Further information .................................................................................................................................... 15
Brent MUIR
2
Introduction
A couple of weeks ago an enquiry came in from a colleague at an EU CERT regarding Indicators
of Compromise (IOCs) of Ducky USBs used on Windows operating systems.
Now a lot has been written lately about flashing the firmware of USB devices to function as
malicious actors (keyboards, other HIDs, etc). Probably due to the increased exposure of
BadUSB at BlackHat earlier this year.
The Ducky USB is a little bit different from the BadUSB methodology, most notably the BadUSB
repurposes commodity USB thumb drives by flashing the firmware with different Vendor IDs
(VIDs) & Product IDs (PIDs) to emulate a different hardware (HW) device, such as a Human
Interface Device (HID). I myself have done the same in the past to circumvent SanDisk
SecureAccess encryption.
Now the Ducky isn't your average USB thumb drive, although it is designed to look (&
sometimes function) just like one. The Ducky is actually running an ATMEL processor and it is
designed for professional penetration testing (pentest) activities. As well as the processor it
utilises Micro SD storage as a cheap and convenient way to update the payloads.
Ducky USB (https://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe#photo-3)
Brent MUIR
3
It has the ability to emulate any VID or PID that you wish, whilst also deploying a payload. The
payload can be written by the user whilst there are many more that can be downloaded from
various forums across the internet. The firmware on the Ducky can also be flashed as per the
user's requirements, and this is the first point I raised.
Out of the box the Ducky firmware is set to only show up as a Human Interface Device (HID), a
keyboard if you will, which is then designed to "type" your payload. As such this default
firmware will not create any USB mass storage device entries on a computer, because it hasn't
been setup to do so.
That does not mean that there will not be evidentiary fragments left behind. No, in fact there
are various entries that get created every time you plug any HW into your Windows computer.
These will obviously vary depending on what VID & PID the user has selected. It is wise to check
the registry as well as the event logs. There may also be evidence left behind from running a
payload, but again this will be dependent on which payload has been set to run.
As I mentioned to my colleague, the Ducky does not have to show up as a mass storage device,
but this option is available. In fact the firmware I run on my Ducky allows this functionality. An
example of a firmware offering this functionality is “Twin Duck”. This popular firmware allows
for a keyboard HID as well as a mass storage device and will produce entries in the following
Windows OS artefacts (amongst others) during installation...
Brent MUIR
4
Installation IOCs
The first place to look for any evidentiary fragments is in the Windows Registry. Any time a
piece of HW or SW is installed on a system the configuration settings are tracked in the
Windows Registry.
The first key that caught my eye was the following, as it uses a rather obscure service known as
Microsoft Composite Device System Driver or “usbccgp”,
HKLM\SYSTEM\ControlSet001\ENUM\USB\Vid_XXXX&Pid_YYYY. As you can see in the
screenshot below the Service is listed as "usbccgp" and LocationInformation value is "HID
Keyboard & MSC".
Windows Registry Key - HKLM\SYSTEM\ControlSet001\ENUM\USB\
This entry, with its dual purpose of HID keyboard and MSC raises the first flag of suspicion. The
Brent MUIR
5
Microsoft Service "usbccgp" is another suspicious flag as is it rarely used by HW devices.
There were also 2 other entries with the same VID & PID (as above), in the same key,
HKLM\SYSTEM\ControlSet001\ENUM\USB\, with the same naming convention but ending in
"&MI_00" and "&MI_01". The LocationInformation value will be same as above, however one
of these entries will have the Service listed as "HidUsb" while the other will have "USBSTOR".
The presence of these entries will also assist in cutting the wheat from the chafe in the registry,
so to speak.
Again, a lot of this depends on the VID & PID specified by the user who configured the Ducky,
but for a lot of the firmwares they will show up as an ATMEL device. For example the below
registry entry shows us that an ATMEL device was installed as a USB mass storage device on the
computer (again the same VID & PID as above).
HKLM\SYSTEM\ControlSet001\ENUM\USBSTOR\Disk&Ven_ATMEL&Prod_xxxxx
Windows Registry Key - HKLM\SYSTEM\ControlSet001\ENUM\USBSTOR\
Brent MUIR
6
An entry in the USBSTOR key will only show up if the Ducky firmware is set to act as a mass
storage device.
Another good registry key to look out for when determining if a Ducky was used on your system
is HKLM\SYSTEM\ControlSet001\HID\Vid_XXXX&Pid_YYYY&MI_0x. The presence of this key,
along with the matching values from the VID & PID above, is an easy way to tell that a device
was plugged into the machine that acted as both a USB HID & mass storage device. Again this
should raise some flags.
Windows Registry Key - HKLM\SYSTEM\ControlSet001\HID\
As you recall the Microsoft USB composite service "usbccgp" was utilized with this Ducky
firmware when the device is first plugged in. Check the following registry key,
HKLM\SYSTEM\ControlSet001\Services\usbccgp\Enum, as it is unlikely that you will have too
many devices listed in there - that's if you have the key listed at all!
This key will show VID & PID of any composite device installed on the system, but it appears to
Brent MUIR
7
get flushed quite quickly, in fact as soon as I removed the Ducky from my testing environment
the entry was gone.
Windows Registry Key - HKLM\SYSTEM\ControlSet001\Services\usbccgp\Enum
Apart from Windows registry entries there are other fragments they may point to the Ducky
being used on a system. One such fragment will be located in the following file
C:\Windows\inf\usb.PNF or C:\Windows\inf\usb.INF.
This file details USB devices that were installed on the machine, in particular HW PIDs & VIDs as
well as drivers that were installed. Remember, if a device with a new VID & PID is added to a
Windows computer it will need to be installed, even if it just uses the default Microsoft drivers,
and therefore an entry will be logged in the above file.
Similar entries can also be located in the file System Log file located in this directory,
C:\Windows\system32\config\system.log.
Brent MUIR
8
All of the above artefacts hold true for Windows XP, Vista, Windows 7, Windows 8/8.1 and
Server 2012/R2. But there are also additional evidentiary fragments left behind on the later
operating systems; Windows 7, Windows 8/8.1 & Server 2012/R2 machines. One such place to
check is in the newer format Event Logs (EVTX), as they contain a wealth of information. The
EVTX logs are located in the following directory:
C:\Windows\system32\winevt\Logs\
Some of the EVTX files which will contain relevant fragments are:
Microsoft-Windows-Kernel-PnP%4Configuration.evtx
Logged Source EventID Categ. Level Keywords User Computer Opcode Offset Addl data
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnPConfig
2 None Info n/a SYSTEM Info 24488 EventGuid={CE7BB282-F3BF-
47E8-A2D2-87F4F6739945} ContainerId={40640BFB-2739-
11E4-93EE-80276FE349} DeviceInstanceId=USB\VID_03EB
&PID_2422\5&35f564d4&0&2 PropertyKeyGuid={A45C254E-
DF1C-4EFD-8020-67D146A850E0} PropertyKeyPid=2
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnPConfig
2 None Info n/a SYSTEM Info 24690 EventGuid={CE7BB282-F3BF-47E8-A2D2-87F4F6739945}
ContainerId={40640BFB-2739-11E4-93EE-80276FE349}
DeviceInstanceId=USB\VID_03EB&PID_2422\5&35f564d4&0&2
PropertyKeyGuid={540B947E-8B40-45BC-A8A2-6AB894CBDA2}
PropertyKeyPid=4
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnPConfig
2 None Info n/a SYSTEM Info 24898 EventGuid={CE7BB282-F3BF-
47E8-A2D2-87F4F6739945} ContainerId={40640BFB-2739-
11E4-93EE-80276FE349} DeviceInstanceId=USB\VID_03EB
&PID_2422\5&35f564d4&0&2 PropertyKeyGuid={A45C254E-
DF1C-4EFD-8020-67D146A850E0} PropertyKeyPid=12
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnPConfig
1 None Info n/a SYSTEM Info 24AA0 EventGuid={37E7572E-D68E-
40E4-9DB3-595E8638955F}
ContainerId={40640BFB-2739-11E4-93EE-80276FE349}
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnPConfig
4 None Info n/a SYSTEM Info 24C40 EventGuid={F31C59D3-1A18-
4B62-BBBF-944309BE344} DeviceInterfaceId=\\?\USB#VID_0
3EB&PID_2422#5&35f564d4&0&2#{a5dcbf10-6530-11d2-901f-
00c04fb951ed}
InterfaceClassGuid={A5DCBF10-6530-11D2-901F-0C04FB951ED}
Brent MUIR
9
• Microsoft-Windows-Kernel-PnPConfig%4Configuration.evtx
Logged Source EventID Categ. Level Keywords User Computer Opcode Offset Addl data
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnP
400 None Info n/a SYSTEM Info F2D8 DeviceInstanceID=USB\VID_03EB
&PID_2422\5&35f564d4&0&2 DriverName=usb.inf
ClassGUID={36FC9E60-C465-11CF-8056-4445535400}
DriverDate=06/21/2006 DriverVersion=6.2.9200.16384
DriverProvider=Microsoft DriverInbox=true
DriverSection=Composite.Dev.NT DriverRank=00FF2003
MatchingDeviceID=USB\COMPOSIT
E OutrankedDrivers= DeviceUpdated=false
Status=00000000
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnP
410 None Info n/a SYSTEM Info F578 DeviceInstanceID=USB\VID_03EB&PID_2422\5&35f564d4&0&2
DriverName=usb.inf ClassGUID={36FC9E60-C465-
11CF-8056-4445535400} ServiceName=usbccgp
LowerFilters= UpperFilters=
Problem=00000000 Status=00000000
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnP
400 None Info n/a SYSTEM Info F788 DeviceInstanceID=USB\VID_03EB
&PID_2422&MI_00\6&1447f2a1&0&0000 DriverName=usbstor.inf
ClassGUID={36FC9E60-C465-11CF-8056-4445535400}
DriverDate=06/21/2006 DriverVersion=6.2.9200.16384
DriverProvider=Microsoft
DriverInbox=true DriverSection=USBSTOR_BULK.NT
DriverRank=00FF2000 MatchingDeviceID=USB\Class_08&
SubClass_06&Prot_50 OutrankedDrivers=
DeviceUpdated=false Status=00000000
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnP
400 None Info n/a SYSTEM Info FA68 DeviceInstanceID=USB\VID_03EB
&PID_2422&MI_01\6&1447f2a1&0
&0001 DriverName=input.inf ClassGUID={745A17A0-74D3-
11D0-B6FE-0A0C9F57DA} DriverDate=06/21/2006
DriverVersion=6.2.9200.16384 DriverProvider=Microsoft
DriverInbox=true DriverSection=HID_Inst.NT
DriverRank=00FF3202 MatchingDeviceID=USB\Class_03
OutrankedDrivers= DeviceUpdated=false
Status=00000000
19/08/2014
10:42:07
+10
Microsoft-
Windows-
Kernel-
PnP
410 None Info n/a SYSTEM Info FD10 DeviceInstanceID=USB\VID_03EB
&PID_2422&MI_00\6&1447f2a1&0&0000 DriverName=usbstor.inf
ClassGUID={36FC9E60-C465-11CF-8056-4445535400}
ServiceName=USBSTOR LowerFilters= UpperFilters=
Problem=00000000 Status=00000000
Brent MUIR
10
Microsoft-Windows-DeviceSetupManage%4Admin.evtx
Logged Source EventID Categ. Level Keywords User Computer Opcode Offset Addl data
19/08/2014
10:42:08
+10
Microsoft-Windows-
DeviceSetupManager
112 None Info n/a SYSTEM Info 5B668 Prop_DeviceName=HID Keyboard and
MSC Prop_ContainerId={
40640BFB-2739-11E4-93EE-
80276FE349} Prop_TaskCount=9
Prop_PropertyCount
=34 Prop_WorkTime_Mill
iSeconds=79
19/08/2014
10:42:10
+10
Microsoft-Windows-
DeviceSetupManager
112 None Info n/a SYSTEM Info 5B840 Prop_DeviceName=HID Keyboard and
MSC Prop_ContainerId={
40640BFB-2739-11E4-93EE-
80276FE349}
Prop_TaskCount=1 Prop_PropertyCount
=6 Prop_WorkTime_Mill
iSeconds=0
19/08/2014
10:42:11
+10
Microsoft-Windows-
DeviceSetupManager
112 None Info n/a SYSTEM Info 5BA18 Prop_DeviceName=HID Keyboard and
MSC Prop_ContainerId={
40640BFB-2739-
11E4-93EE-80276FE349}
Prop_TaskCount=2 Prop_PropertyCount
=34 Prop_WorkTime_Mill
iSeconds=12
19/08/2014
10:42:12
+10
Microsoft-Windows-
DeviceSetupManager
112 None Info n/a SYSTEM Info 5BBF0 Prop_DeviceName=HID Keyboard and
MSC
Prop_ContainerId={40640BFB-2739-
11E4-93EE-80276FE349}
Prop_TaskCount=1 Prop_PropertyCount
=6 Prop_WorkTime_Mill
iSeconds=0
Brent MUIR
11
System.evtx
Logged Source EventID Categ. Level Keywords User Computer Opcode Offset Addl data
19/08/2014
10:42:09
+10
Microsoft-
Windows-
DriverFrameworks-
UserMode
10000 48 Info n/a SYSTEM Start 9E278 <UMDFDeviceInstallBegin
version="1.11.0" xmlns:auto-
ns2="http://schemas.microsoft.com
/win/2004/08/events"
xmlns="http://ww
w.microsoft.com/DriverFrameworks/
UserMode/Event"> <DeviceId>WPDB
USENUMROOT\UMB\2&37C186B&0&
STORAGE#VOLUME#_??_USBSTOR#
DISK&VEN_ATMEL&PROD_DUCKY_S
TORAGE&REV_1.00#7&2D8FF6D9&0
#</DeviceId></UMDFDeviceInstallB
egin>
19/08/2014
10:42:09
+10
Microsoft-
Windows-
DriverFrameworks-
UserMode
10002 48 Info n/a SYSTEM Info 9E890 <UMDFServiceInst
all upgrade="true" xmlns:auto-
ns2="http://schemas.microsoft.com
/win/2004/08/events"
xmlns="http://www.microsoft.com/D
riverFrameworks/
UserMode/Event"> <Service
clsid="{112DE495-AC4C-46F8-B663-
6A4266C53313}" name="WpdFs"><
/Service> <MinimumFxVersi
on>1.11.0</MinimumFxVersion></U
MDFServiceInstall>
19/08/2014
10:42:09
+10
Service Control
Manager
7036 None Info n/a WIN-
V1334APEBF1
Info 9EBF8 param1=Windows Driver Foundation
- User-mode Driver Framework
param2=running 770075006400660
07300760063002F0034000000
The setupapi.dev.log file (located at C:\Windows\setupapi.dev.log) also contains a log of the
drivers that are used by the Ducky device when it was first installed.
Brent MUIR
12
Fragments of the payload
Another colleague asked about the potential for fragments of a Ducky payload to remain on a
compromised system, or even on the Ducky device itself. A lot of the Ducky payloads exploit
PowerShell scripts (which is installed by default in these later Windows Operations Systems).
Therefore the first place I suggest to check is in the PowerShell EVTX log.
Other areas on the computer include prefetch files (.pf), Windows ShellBags MRU, LNK
(shortcuts) and the like.
For example the following registry key stores any commands that utilise the Windows key + R
(as in run) - HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. This
registry key may hold fragments of the payload deployed.
Windows Registry Key - HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
Brent MUIR
13
As for the Ducky itself it all depends on a number of things:
1. Was the Ducky configured to store any files on a mass storage partition of the device
once the payload has run?
2. Does the user securely wipe the storage partition on the Ducky in-between
deployments?
Given the fact that the Ducky USB is not a commodity device, it is highly likely that the owner
would want to retain the device once the payload has deployed (most payloads take less than a
minute to run). However this would be dependent on the risk involved and how it was
deployed, e.g. if “found” in the car park of an organisation.
One of the popular payloads uses the Twin Duck firmware along with Mimikatz to dump SAM
passwords via PowerShell and store them on the Ducky in a text file. In this case if the Ducky
user doesn't wipe this mass storage partition then there will likely be evidentiary fragments
pointing to previous deployments.
Example Output of Mimikatz
Brent MUIR
14
Risk Mitigation
Although the Ducky often uses signed Microsoft drivers, which are based on the VID & PID
selected by the user of the device, there are ways to limit your exposure to these risks. The
easiest is to set adequate Security & Group policies on your domain, ensuring that only system
Administrator accounts have the appropriate rights to install new HW.
It is important to note that a lot of these policies are based on VID & PID of devices, but as you
know the Ducky can be flashed to use any combination that it likes, therefore it is important to
block not based on VID & PID but globally for all HW devices.
The other obvious requirement of the Ducky is physical access to your machine, and to a USB
port on that machine. Physical machine hardening is often an overlooked step in the realm of
information security, but it is an easy step to take; remember that if you don’t need it, disable it
by default.
Brent MUIR
15
Tools required to replicate my findings
• A Ducky USB
• RegShot
• CaptureBat
• I recommend doing this in a VM (your malware analysis lab is fine) as you can restore to
a snapshot as required.
Further information
http://blog.gentilkiwi.com/mimikatz
http://blogs.catapultsystems.com/IT/archive/2010/02/07/windows-7-restricting-and-securing-
usb-storage-devices.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539234%28v=vs.85%29.aspx
http://technet.microsoft.com/en-us/library/dd346764.aspx
http://technet.microsoft.com/en-us/magazine/2007.06.grouppolicy.aspx
http://www.slideshare.net/bsmuir/sandisk-secureaccess-encryption-forensic-processing-usb-
flashing
http://www.windowsecurity.com/articles-tutorials/authentication_and_encryption/Control-
USB-Devices-Group-Policy.html
https://forums.hak5.org/index.php?/topic/28162-firmware-introducing-twin-duck/
https://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe
https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil
http://regshot.sourceforge.net/
https://www.honeynet.org/node/315