Menu

Drive Badger: open source platform for covert data exfiltration operations, ranging from small computers to big servers.

contact@drivebadger.com

While Drive Badger's main functionality is data exfiltration, it is also able to make changes to the copied filesystem: create files or directories, write data into them, rename, delete etc. This feature is called filesystem injection and is done by "injectors". See injectors-playground repository for example scripts.

Injectors

Injectors are simple scripts (working in similar way to hooks), located inside /opt/drivebadger/injectors directory, that are executed:

  • after completing data exfiltration from given partition (or network share), and
  • after remounting it to read-write mode (if possible)

Injector is a directory containing injector.sh script, and possibly other files (eg. photos to copy to particular drive). The script receives the path to mounted partition as $1 argument and can do anything within this path. However there are some limitations:

  • there is no "undo" operation
  • filesystem ACLs are disabled (not enforcing anything, and also impossible to edit)
  • filesystem is mounted in case-sensitive mode, even NTFS (so eg. C:\Windows and C:\WINDOWS are not the same)
  • advanced OS-specific features (eg. NTFS Alternate Data Streams are inaccessible)

Is write access always possible?

No. Injectors are run on "best effort" basis - so write may succeed, but if not, it is not considered as hard error.

Injectors may not be run at all, or may fail, in many circumstances:

  1. Read-only FUSE driver - eg. drivers for Apple filesystems are read-only.
  2. Read-only underlying storage:
    • CD/DVD
    • USB drive set to read-only mode
    • NFS share exported in read-only or partially read-only mode
  3. mount operation in rw mode fails for any other reason - eg. NTFS partitions after unclean shutdown can be mounted in read-only mode without errors, but fail to mount in read-write mode.
  4. Too much data on exfiltrated partition - exfiltration stopped by user before injection attempt.

Data exfiltration and injection general flow

Drive Badger processes all partitions in particular order:

  1. Mounts partition as read-only.
  2. Processes hooks.
  3. Performs actual data exfiltration (rsync).
  4. Unmounts partition.
  5. If any injector script is found:
    • mounts partition once again as read-write
    • runs chosen injector script
    • unmounts it again

Exception: VeraCrypt system partitions are opened in read-write mode from the beginning, and then exfiltrated and injected in a single run.

Order of choosing injector to run

Injectors are selected by get-injector-script.sh script. It implements the following logic:

  1. Check for injector specific to partition UUID. If not exist, then...
  2. Check for injector specific to filesystem/encryption/share type and drive serial number. If not exist, then...
  3. Check for injector specific to filesystem/encryption/share type.

And only the first (best matched) injector is executed.

This means that:

  1. UUID-based injectors are the best choice, since they're executed against only one specific partition.

  2. Injectors specific to drive serial number are executed against all partitions on given drive. For example, typical Linux box contains at least 2 ext4 partitions: / and /boot, and optionally more: /home, /var, /tmp and so on. So, such injectors need to implement checking for additional conditions, before attempting to make any changes.

  3. Injectors specific only to filesystem/encryption/share type should be used only in special circumstances and with caution, since they can easily cause irreparable damage. In general, such injectors are meant to run in environment, that is seen for the first time (without any previous exfiltration or other research).

Injectors and drive encryption

Injectors works with encrypted drives with some limitations:

  1. Bitlocker and VeraCrypt partitions can't be matched by UUID.
  2. bitlocker, veracrypt and luks encryption types overwrite filesystem types:
    • ext4 partitions encrypted by LUKS can only be matched by luks type, not ext4
    • similar for NTFS: bitlocker, veracrypt instead of ntfs

Examples

injectors-playground repository contains several examples of simple injectors, that check for existence of particular directory to make sure, that they process correct partition, and then create a simple text file.

Amongst them, there are a bit more interesting examples: