Understanding the File System
Out of the box the emulated "USB Flash Disk" (udisk) feature of the Key Croc is handled automatically. Special care is taken for loot and payload synchronization between the primary partition and the udisk on boot and when entering arming mode. However, if you will be writing advanced payloads which take advantage of the ATTACKMODE STORAGE option, it is important to have a good understanding of the udisk partition and its handling so that file system corruption does not occur.
The Key Croc features an 8 GB SSD containing many partitions. Most notably among them is a 2 GB FAT32 formatted partition mounted at /root/udisk. It is referred to as the USB Flash Disk partition, or simply udisk.
For the sake of simplicity in this guide, we will refer to this partition as the udisk. Likewise, the Key Croc itself is considered the host while the computer that the Key Croc is plugged into is considered the target.
The udisk can either be attached to the host (again, the Key Croc itself) or the target (again, the computer to which the Key Croc is connected). The udisk should not be simultaneously attached to both. This means that if the target can see the "KeyCroc" udisk, then the host should not read or write to this partition in its usual /root/udisk location.
UDISK IN ARMING MODE
When the Key Croc enters arming mode two functions are performed. First, the loot collected in /root/loot will be synchronized with the loot directory on the udisk. Second, the udisk will be attached to the target with the drive label "KeyCroc".
From the drive labeled "KeyCroc" on the target, payloads may be activated by copying them to the payloads directory. Likewise, keystroke logs may be copied from the loot directory.
It is important to "safely eject" the udisk before unplugging the Key Croc from the target.
UDISK IN ATTACK MODE
When the Key Croc boots, it enters Attack Mode by default. In this mode, the udisk is attached to the host. When the Key Croc starts up, payloads are copied from the udisk's payload directory to a cache on the primary partition. Do not live edit these files in attack mode, either by Cloud C2 terminal or SSH. Doing so may cause unexpected results as they relate to MATCH handling. See the section on Interactive Payload Development for further information on that use case.
The udisk partition is formatted in the FAT32 file system for maximum compatibility with various targets (Windows, Mac, Linux, etc) and as such does not allow for some features typically found on Linux filesystems like EXT – for example symlinks.
UDISK IN PAYLOADS
The best practice in terms of saving loot from your payload is to write the file to /root/loot. This directory is synchronized with the udisk when entering Arming Mode.
If a payload is to use the ATTACKMODE STORAGE option – which exposes the udisk to the target – special care should be taken as not to inadvertently read or write to the udisk from the host, either from an activated payload or interactively from a SSH connection or Cloud C2 terminal. To handle this, the udisk command provides options for mounting and unmounting the partition to ensure that this cannot occur.
For example, a payload which uses the udisk for exfiltration may perform the following:
Now obviously this is only for demonstration purposes, and this payload would likely need some delays to actually work. It's also highly obvious and will probably end your pentest very quickly, but it still illustrates the point.
Last updated