What If: Stealth Malware Communication via Payload Splitting
In the days of old (and in fairness, in some places, today), a common communication vector (for both malware and sneaky VPNs) was that of using ICMP. Leveraging the flexible payload in the request/response allowed data to pass across a network with ease (and in some cases, across the internet). Now, high-cardinality ICMP detection exists (I recall writing detection logic for this many years ago), and deep packet inspection (DPI) tooling can pick it up with relative ease. So how else can hidden communication take place...
For the majority of networks deployed worldwide the maximum transmission unit (MTU) of a network frame is 1500 bytes (or 1492 if you are using PPPoE). This works well for the most part, as cheap network devices are built around this and the limit is well established. Higher MTUs are possible (i.e., jumbo frames), but network equipment has to support this, and >1500 byte frames on a network are easy to spot (not to mention it breaks on networks that don't support it). So if the size of the frame can't be increased without triggering an alarm / sending your network into oblivion, what can be done with the payload instead?
While leveraging IP fragmentation is a tempting proposition (see IP fragmentation), to keep things cleaner there is another approach. What if the payload you thought you were sending per frame actually wasn't? What if your payload was always being split so that one expected frame becomes two, and space in each frame was dedicated to something malicious?
Within the depths of the operating system / networking stack, the data for every connection is sent/received based on a defined standard. Taking an Ethernet frame as an example, the format can be visualised as follows:
| aaaaaaabccccccddddddeeeeffgggggggggggggggggggggghhhh |
Note: Not to scale
a=preamble
b=sfd
c=dest mac
d=src mac
e=vlan tag
f=length
g=payload (actual)
h=crc
An application sends/receives the data it needs, and the OS / network adapter handles the rest for you. Data is passed in the payload field, and the checksum helps keep corruption at bay (mostly). Deviating from this form breaks things in weird and wonderful ways, and is easy to spot from via DPI tooling. Instead, what if the payload space was divided so that there was room for both a genuine payload and a malicious payload?
| aaaaaaabccccccddddddeeeeffgggggggggggggggxxxxxxxhhhh |
Now, extra bits are available for communication between malicious nodes, without breaking Ethernet framing and without using easily detected protocols. Providing the target can differentiate a combined payload from a plain one (possibly using a safe word XOR'd with the MAC address as the footer for the payload as reading the payload in reverse makes it easier to fast-path the data if its a hidden payload), each sent/received frame can be split as required without the user being aware. After all, frames are frames and providing they match the specification, it shouldn't be an issue.
So where does this attack vector fit in to the day-to-day you may ask... As a low-level rootkit, definitely, and potentially also on rogue devices shipped from questionable origins. If you consider actively monitored networks (those without full DPI and stream reassembly validation), the easiest way to spot something malicious to catch it trying to cross the network perimeter (interior or exterior) on a port you don't permit, or to a destination you don't permit. For most organisations, a system trying to communicate to a host on the internet on port 4444 is an immediate red flag (as an example). Even where proxies are used to restrict internet access, a simple header check on the initial connection can be enough to catch out most simple malicious tooling.
With payload splitting this becomes significantly more difficult to detect. The disguised communication between systems can sit beside existing (approved) traffic, with neither the source or destination system aware of the side-channel communication (if its correctly intercepted / removed). Aside from the occasional connection retry from a source (due to it not understanding the initial 'are you compromised' payload footer), this becomes difficult to spot. It's worse when you consider multimedia traffic, as the nature of the data means it inherently contains corrupted video blocks periodically (especially when using lossy transmission), and so even DPI analysis would have a hard time distinguishing a malicious split of the payload with actual video corruption.
Then there are the home devices that are so easily added / trusted to be behaving in a friendly way. Years ago, I recall being concerned at my own IOT devices that would periodically attempt connections to remote servers during the early hours (and not for update checks), and thinking how its so easy to spot given it trips a firewall rule. Now, providing the receiver is already configured to differentiate between genuine / malicious payloads, spotting what other data is leaving the network over an approved connection is more difficult than ever.
Even zero trust can't save you from this...