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

contact@drivebadger.com

Drive Badger is able to automatically detect and decrypt Apple FileVault-encrypted APFS partitions, using either user password, or recovery key.

How to provide decryption keys?

See keys-filevault-demo repository. It contains a sample filevault.keys file.

You can configure multiple such repositories - each such repository should:

  • be cloned to /opt/drivebadger/config/keys-filevault-yourchosenname local directory on your Drive Badger persistent partition
  • contain filevault.keys file with proper contents (see below)

Local directory doesn't need to contain .git subdirectory, in fact it can be just "floating" directory (created by hand or script, without repository). However if it does, then you can update it automatically using /opt/drivebadger/update.sh (in just 1 step for all repositories).

Do you have more information about these keys?

If you have decryption keys associated (directly or indirectly) with particular drive serial numbers, you can save such keys in keys directory.

If you have any additional useful information about particular keys, allowing you to split them in some way (eg. into cities, buildings, floors, company departments, employee specialties) into smaller groups, you can try:

  • split them into separate repositories
  • configure these repositories across many Drive Badger devices, according to your attack plan

filevault.keys file format

filevault.keys file can contain:

  • FileVault recovery keys or user passwords, one per line
  • comments starting from # sign (without leading spaces)
  • empty lines

Example filevault.keys file:

# macbook pro, recovery key
ABCD-1234-5678-90AB-CDEF-1234

# mac mini, user password
MyFancyPassword

How the keys are matched to encrypted partitions

APFS partition has different structure than most other partition types: it has multiple separate filesystems (usually 4 or 5) stored as single partition, with a single UUID. All these filesystems are then mounted and seen as consecutive layers of the same logic filesystem. Drive Badger tries to exfiltrate only 1 or 2 of such filesystems: those containing user data.

Similar to other partition types (except only Bitlocker), APFS partitions are detected by systemd/udevd during system boot phase. Drive Badger relies on that, and just iterates over all detected partition UUIDs, trying to mount and exfiltrate them one by one. For APFS this behavior is however a bit different:

  • first it gets the list of internal filesystems (only ones with user data)
  • then it iterates over them, trying to mount each one:
    • first without password
    • then checking user passwords or recovery keys from filevault.keys files

When a matching key is found, it's saved in keys directory - so it can be easily reused.

From the founder...

Being in IT security business for almost 25 years, I realized, that breaking protections (or preventing it) is becoming less and less important. We are not living in Outlook Express times anymore...
The key point is the ability to keep the privileges permanent, once obtained. This becomes more and more difficult, as IT systems get more and more complicated - and this is exactly the goal of Drive Badger project: to give non-ITSEC people the ability to keep either the privileges, or the outcome of the successful break-in.