Unemployfuscation
Unemployfuscation
This is a repost of my original article on https://blog.grumpygoose.io for archiving purposes*
In a continuation of Grumpy Goose Labs coverage of KVM over IP devices by Jim. Today, Blue Teamer, we’re covering detection capabilities of obfuscated PiKVM and TinyPilot devices.
You saw Jim explain how popular these devices are becoming and the existential threat these devices have against organizations that do not permit their usage. Specifically, relying on the end user to have some level of self awareness of Cyber Security best practices both at work and at home. It’s only gotten more popular…
PiKVM Trend Graph on Shodan.io
TinyPilot Trend Graph on Shodan.io
The PiKVM and TinyPilot are remarkable Raspberry Pi-based devices with extensive potential, widely appreciated by digital nomads and technology enthusiasts alike. However, there is a significant concern: North Korean state-sponsored threat actors share a similar enthusiasm for leveraging such technologies. As you can see from Palo Alto Unit 42’s report
This very much impacts how Blue Teamer’s, Human Resources, and your Marriage respond to the fact that you’re using one. I’ve lost so much sleep due to investigations, relating to unauthorized use of these devices on company workstations, resulting in termination.
Enough doom and gloom…Lets get to the goods, how do you detect Obfuscated TinyPilot/PiKVM devices? In my examples I will keep it rather Endpoint Detection and Response (EDR) vendor focused to CrowdStrike. I’m sorry for hurting those that do not use CrowdStrike or no longer use CrowdStrike as of 19 July 2024.
During my review of USB events associated with the connection of an obfuscated PiKVM or TinyPilot to a workstation, I noted a recurring pattern in the event_simpleName labeled “DcUsbConfigurationDescriptor”.
This descriptor provides detailed information about the device’s capabilities and functionalities, such as power requirements and supported interfaces.
This event included a field named “ConfigurationDescriptorName”, which consistently displayed the following for Raspberry Pi based HID devices:
PiKVM:
"Config 1: PiKVM device"
TinyPilot:
"Config 1: ECM device"
While the “DcUsbConfigurationDescriptor” event log does not provide an immediate or obvious link to the corresponding USB Connection event, this relationship can be established by leveraging the DeviceDescriptorSetHash and aid fields.
DeviceDescriptorSetHash is a unique identifier generated by hashing specific attributes of a USB device. These attributes typically include the device’s vendor ID, product ID, and serial number. Please know that this hash can be shared across multiple devices if the configuration is the same. It does not imply that it’s the same physical KVM device.
“AID” stands for “Agent ID.” This unique identifier is assigned to each endpoint where the Falcon sensor is installed,
These identifiers allow for effective correlation across the unique “DcUsb*” events that occur during the USB connection and disconnection process. I’m a visual person, so lets look at excessive usage of arrows…
On the left you have the DcUsbConfigurationDescriptor event and on the right you have the DcUsbDeviceConnected event. The device has been obfuscated and any environmental related details REDACTED or randomized (for security purposes). You can observe that the two events tie together well using the AID and DeviceDescriptorSetHash, allowing you to identify if the device is obfuscated or stock. This should adjust your Policy Enforcement Posture hopefully; if all the other indicators and interviews prove to be innocent in nature.
It is worth noting that we’ve seen the “Config 1:*” numeric value change, so in our query you’ll see /Config [0–9]: */i
An example query you can run within CrowdStrike is:
#event_simpleName = "DcUsbConfigurationDescriptor" OR #event_simpleName = "DcUsbHIDDescriptor" OR #event_simpleName = "DcUsbDeviceConnected"
| join({#event_simpleName = "DcUsbConfigurationDescriptor" ConfigurationDescriptorName=/Config [0-9]: */i}, field=DeviceDescriptorSetHash, key=DeviceDescriptorSetHash)
| (#event_simpleName = "DcUsbDeviceConnected" OR #event_simpleName = "DcUsbConfigurationDescriptor")
| groupby(field=[DeviceDescriptorSetHash], function=[collect([ComputerName, aid, ConfigurationDescriptorName, DeviceManufacturer, DeviceProduct, DeviceSerialNumber, DevicePropertyDeviceDescription, #event_simpleName]), selectLast([@timestamp])])
| table([@timestamp, ComputerName, aid, ConfigurationDescriptorName, DeviceManufacturer, DeviceProduct, DeviceSerialNumber, DevicePropertyDeviceDescription, DeviceDescriptorSetHash,#event_simpleName])
While this is typically high fidelity, you’ll need to use your noodle to ascertain if the device identified is a PiKVM, TinyPilot, or some hacked together maybe Raspberry Pi based HID device.
Another thing to consider, while looking at the raw event log of DcUsbConfigurationDescriptor:
{
"event_simpleName": "DcUsbConfigurationDescriptor",
"ConfigurationDescriptorValue": "1",
"ConfigurationDescriptorAttributes": "128",
"ConfigStateHash": "1263837413",
"DeviceDescriptorUniqueIdentifier": "9ecffe5d6eb2255177e1d503abb374f314f384a3378121c81f41e3bf7bf3a343",
"aip": "REDACTED",
"ConfigurationDescriptorName": "Config 1: PiKVM device",
"DeviceTimeStamp": "REDACTED",
"DeviceDescriptorSetHash": "b3bed53b9e5cefd52a5485d5acb89ce5a3909f1eb0065de0bd8ad5ecf7d33fbd",
"ConfigBuild": "REDACTED",
"ConfigurationDescriptorNumInterfaces": "2",
"event_platform": "Win",
"ConfigurationDescriptorMaxPowerDraw": "125",
"Entitlements": "15",
"name": "DcUsbConfigurationDescriptorV2",
"EventOrigin": "17",
"id": "REDACTED",
"EffectiveTransmissionClass": "2",
"aid": "de66a33bfceaabf46ba4ddbebefb8beb",
"timestamp": "REDACTED",
"cid": "REDACTED"
}
ConfigurationDescriptorNumInterfaces announces how many Interfaces the USB device is supporting:
"ConfigurationDescriptorNumInterfaces": "2",
ConfigurationDescriptorMaxPowerDraw also provides the power draw (in milliamps or “mA”) the device will need.
"ConfigurationDescriptorMaxPowerDraw": "125",
Please note that USB 2.0 specification maximum for a single device is 500 milliamps and USB 3.x devices can request up to 900 milliamps.
Combining these two values with crazy device types that should never have (for example) 5 interfaces or need 250 mA’s… can lead to some unique finds.
Other things to look for could be the HDMI connection itself, you can run the following powershell query (via RTR to the endpoint) to look for this:
Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorID
This should output something similar to:
WmiMonitorID (InstanceName = "DISPLAY\LNX7770\REDACTED")
Specifically we’re looking for “LNX777#.” This being the indicator for a Linux Monitor, which the PiKVM and TinyPilot default to for the HDMI connection.
However.gif, this can be obfuscated and should only be used to validate what parts of the device connection events are or are not obfuscated.
Please don’t use a PiKVM/TinyPilot on your work computer. You will probably get terminated. Just know, I @wav3@infosec.exchange">still love you.
저는 북한의 바비큐보다 남한의 바비큐를 더 좋아합니다.