Data Exfiltration via PoE

If the news from the last 10 years has taught me anything, its that the lengths attackers go to for data exfiltration, and the complexity, has increased significantly. It wasn't that long ago I recall watching a demonstration on how OpenWRT could be configured to blink an LED faster than the human eye can see, yet perceivable to a sensor at the end of a pair of binoculars / telescope (allowing data to be exfiltrated providing you can see the device).

After working on a few PoE devices at home while reading about how Ubiquiti now supports PoE+++ (not a ratified standard at present), the 100 watts of power delivery got me thinking not only about what devices could be powered by it (including charging laptops at a fast-enough rate), but if the technology could be used as a form of data exfiltration in air-gapped environments.

After giving it some thought, I figure there are two possible ways this could be attempted (though realistically its around how it would be detected):

Rapid fluctuations of power consumption allowing transformer harmonics to be detected
Rapid fluctuations of power consumption allowing input power spikes (detected externally)

The first approach would come down to how the switch / injector handles rapid fluctuations in power requirements for a device, and how good the power circuit is (especially at tolerating the increases / isolating any RF output from a switch-mode power supply). In principal, your exfiltration code would spike the CPU load across all cores at a very rapid rate, causing the power input to spike faster than we would detect (including while looking at system utilisation etc).

This could be thought of as a car engine revving itself to different RPM's incredibly fast, with nobody realising that there is an actual pattern to it. I can't remember the example (it may have been on Top Gear), but someone once demonstrated the ECU of a car getting the engine to play a tune by revving as required. Speed this up to the point where humans can't differentiate (not easy on a car), and you get the idea.

Data can be encoded in many ways, ranging from the tried-and-tested morse code through QAM (a staple in WiFi). Forward Error Correction (FEC) is also a thing, allowing resiliency information to be added into a stream to allow repairing corrupt bytes at the receiving end. Tweaks on the above could provide a way of handling the load-based spikes that aren't attributed to the exfiltration.

To make it more interesting (and viable, not only for this approach but leading into the next), its commonplace for organisations to have multiple devices that leverage PoE (VoIP phones as an example), and typically all of these devices are time-synced via NTP down to the millisecond. If multiple devices were taken control of, and with some form of communication between them, power usage could be spiked on all devices at the same time. This would make it significantly easier to detect from an RF perspective (assuming the harmonics generated from each are the same).

Leading on from the above (when many devices, likely thousands are at play) comes the ability to detect this externally (where power goes into a building). Depending on how power is fed into a building / how many phases of power there are / if UPS's are used / if they are line-interactive or always-on / if PDU's are smoothing outputs / what the total power usage day-to-day is, it gets interesting.

If you could spike the power usage of CCTV cameras (as an example) which are known to be very power-hungry given the recent inclusion of AI detection on-device, that could be the difference between 5 watts and 50 watts (depending on the camera). If you had 100 of these cameras (not unreasonable for a large site), that is the difference between 500 watts and 5,000 watts (5kW). Assuming the devices were time-synced and all spiked at the same time when exfiltrating a payload, that type of spike might be detectable where the power enters the building.

Speaking of CCTV cameras, that gets even more complex / risky for two reasons. Not only are they typically fitted to the outside of a building (which makes it easier to detect RF emissions if their CPU load is spiking, regardless of PoE), but those with IR lights could replicate that original OpenWRT video from years past. As infrared can't be seen by humans (aside from some light-bleed typically showing as red on the cameras), if you can oscillate the state of the light fast enough even a typical camera without an IR filter wouldn't show any indication of it switching on/off at speed.

Going further down this rabbit hole, non-PoE cameras that are linked via Coax cable still have out-of-band management to allow a DVR to configure the settings. What's to say that a compromised DVR (as that would, at least in a business setting, have network connectivity) couldn't trigger the cameras to ramp their load / signal via their IR lights? This way, the perceived safety of using non-PoE devices is a falsehood, leaving you at the mercy of the CCTV vendor (and their competency of security).

So where does this leave us? Personally, it leaves me questioning if secure buildings monitor their RF emissions / power usage to the extent where rapid fluctuations aren't considered noise and are verified accordingly.