Overview

Drive encryption is becoming something more and more common in recent years. Since 2018, when GDPR became enforceable, drive encryption became a de facto standard for laptops and mobile devices, securing corporate data in case of eg. device theft.

Drive Badger supports 4 most important drive encryption schemes (see the below table). Obviously, to exfiltrate data from computer with encrypted drive, you need the encryption key (in most circumstances, either user password, or recovery key). Drive Badger automates storage and management of such keys - but it is up to you to obtain and configure them before the attack (eg. buy them from disgruntled IT employee).

Additionally, Drive Badger ensures operator safety by encrypting its persistent partition (the one on your USB drive, to which exfiltrated files are saved) using LUKS. In case of getting caught, there is no way to distinguish between Drive Badger and ordinary Kali Linux Live drive, or to prove the fact of data exfiltration, until someone knows the proper password.

Supported encryption schemes

Currently Drive Badger supports the following drive encryption schemes and key modes:

Supported partition types and filesystems

Currently Drive Badger supports the following partition types and filesystems for each encryption scheme:

Key storage

Drive Badger uses 2 types of encryption keys:

• keys assigned to given drive (matched by model and serial number)
• unassigned keys

Algorithm of mounting a new drive is very simple:

• get the drive serial number
• load the keys (using get-drive-encryption-keys.sh script), with keys assigned to given drive at the start, and removed from the rest of the list (in case if duplicated)
• iterate keys, until the right key is found
  • if there was a key assigned to this drive, it will be found again at the first try
• when key is found, save it to local file in exfiltration directory, and use save-drive-encryption-key.sh script to assign it to the current drive

Keys assigned to given drive

Such keys are stored in so called "keys directory" - which is simply a directory on persistent partition, that contains multiple files, one per hard drive serial number and encryption scheme, eg. NS11N546911301H05.bitlocker.

Most of such files contain exactly 1 key, which is valid for all encrypted partitions on the same drive. However in some rare scenarios, each partition can be encrypted with different key - then such files contain multiple keys, 1 per line.

Keys directory location

Keys directory location and behaviour differs between Drive Badger and Mobile Badger modes:

Drive Badger

In Drive Badger mode, keys directory location is pointed by script /opt/drivebadger/internal/kali/get-keys-directory.sh - and it is relative to persistent partition mount point, and created automatically if not exists.

Sample file paths:

/run/live/persistence/sda3/.files/.keys/TNS5193TGS38SG.apfs
/run/live/persistence/sda3/.files/.keys/NS11N546911301H05.bitlocker
/run/live/persistence/sda3/.files/.keys/SanDisk_SD9SN8W2T00_19259H456424.veracrypt

Where TNS5193TGS38SG, NS11N546911301H05 and SanDisk_SD9SN8W2T00_19259H456424 are drive serial numbers (depending on various hardware details, this string can contain just the serial number, or serial number prepended by full drive model).

Mobile Badger

Mobile Badger doesn't support target drive encryption, so for operator safety, there are some differences:

• keys directory needs to be created manually on target drive, as .support/.keys, .files/.keys or files/keys subdirectory
• if no such directory is found, then fallback /etc/drivebadger/keys is used
• if you use more than one target drive, you can decide separately for each one, where to to save keys

So the operator can decide, if he wants to keep drive keys on unencrypted target drive, or on (also unencrypted) internal SD card - whichever is easier or more convenient to hide/destroy in an emergency situation.

Unassigned keys

Unassigned keys, are the keys provided in configuration repositories, in /opt/drivebadger/config/keys-*/*.keys files, or more exactly:

• bitlocker.keys files for Bitlocker
• veracrypt.keys files for VeraCrypt
• luks.keys files for LUKS
• filevault.keys files for Apple FileVault

There can be multiple such files - eg. one per department, building storey etc.

Key management scripts

The whole encryption key management is divided into 6 scripts:

get-drive-encryption-keys.sh

This script is responsible for loading all encryption keys, that should be checked for given partition. It gets:

• encryption scheme
• keys directory
• drive model and serial number (as single string)

It should just print keys on console, one per line. Standard order should be:

• first keys assigned to given drive
• then unassigned keys, with assigned keys filtered out (to avoid duplicates)

This script is the best place to implement some custom logic regarding order, in which keys should be checked.

save-drive-encryption-key.sh

This script simply saves given encryption key (when found for the first time) to a proper file in keys directory - so that such key will be found by get-drive-encryption-keys.sh script next time.

get-keys-directory.sh

This script has 2 separate locations:

• /opt/drivebadger/internal/kali/get-keys-directory.sh - for Drive Badger
• /opt/drivebadger/internal/mobile/get-keys-directory.sh - for Mobile Badger

It simply returns the keys directory (see above).

show-key-stats.sh

This script also has 2 separate locations:

• /opt/drivebadger/internal/kali/show-key-stats.sh - for Drive Badger
• /opt/drivebadger/internal/mobile/show-key-stats.sh - for Mobile Badger

It counts all configured keys and shows statistics. Sample output:

encryption mode | keys assigned to drives | repo keys unassigned | common | total repo keys | unique repo keys
--------------------------------------------------------------------------------------------------------------
apfs            | 1                       |                      |        |                 |
bitlocker       | 1                       | 1643                 | 1      | 1644            | 1644
luks            |                         | 22                   |        | 22              | 22
veracrypt       | 8                       | 142                  | 8      | 150             | 150

What can be seen in the following table:

• 1644 Bitlocker keys, 150 VeraCrypt keys and 22 LUKS keys were loaded from configuration repositories
• from the following keys, 8 VeraCrypt keys and 1 Bitlocker key were assigned to drives
• additionally 1 Apple FileVault key was assigned to drive