Configuring encryption keys

I want to attack company X, and I already have a list of ~5000 recovery keys for encrypted drives in employees' computers, bought from IT employee. What should I do next?

Legal aspects

Just for sure: do you represent the eligible entity? Please read this page, before you go any further.

Required equipment

Exfiltrating so many computers is a big challenge. And it requires a plan. Make sure that you read also this page, about gathering information and calculating drive capacities required for a successful attack. And here you can find our curated list of recommended drive models for your particular needs.

Drive encryption

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. 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).

How companies store encryption keys and how to obtain them?

Companies that manage hunders or even thousands of computers, are generally trying to automate as much work as possible - this includes encryption key management. Mostly they use Microsoft Active Directory (so called "domain" or "Windows domain"), often combined with Azure AD (for integration with web services like Microsoft 365) and/or self-management tools like ManageEngine, access management tools like CyberArk and so on.

Active Directory environment is the most obvious place to store recovery keys for Bitlocker encrypted drives (keys are replicated to AD DS automatically, when deploying new computers). Such keys can be later found in ntds.dit file, which is replicated to all Domain Controller servers (which usually don't have their drives encrypted).

Most companies, if they have any electronic registries of drive encryption passwords:

• store recovery keys (if possible for given encryption scheme) rather than user generated passwords (as it is harder for user to break something, and due to privacy reasons)
• store them along with references to computer serial number (factory generated, or provided by local IT departments - eg. Dell Asset Tag), rather than drive serial number

IT departments responsible for storing such data may be called Helpdesk, Service Desk, IT Support, Shared Services Center etc., depending on the philosophy, around which that particular company is built (eg. ITIL, ISO/IEC 27001 etc.).

The most obvious registry of Bitlocker recovery keys, is Microsoft Active Directory environment, particularly ntds.dit file. It can be found on all Domain Controller servers, and since it's the master database of the whole AD environment, it is protected from direct access and thus stealing it too quickly. However, obtaining this file is not impossible, eg. you can recover it from Volume Shadow Copy. And when you got a copy of ntds.dit file, you can extract Bitlocker FVE passwords use this script.

Lists directly containing drive serial numbers are very rare (maybe except some servicing protocols etc.) - however if the company is buying branded IT equipment (eg. Dell, HP, possibly others), then invoices can contain the most important serial numbers for each bought equipment part.

Looking at these passwords

Currently Drive Badger supports the following drive encryption schemes:

• Bitlocker - with recovery keys looking like this: 123456-123456-123456-123456-123456-123456-123456-123456
• Apple FileVault - with recovery keys looking like this: ABCD-1234-5678-90AB-CDEF-1234, or user generated passwords
• VeraCrypt - with user generated passwords
• LUKS - with user generated passwords

User generated passwords can take many forms, eg.:

• August!2021 - such patterns mean, that users are probably forced to change their passwords periodically
• MyVCBootPassword123
• R3c0ve4y_p@sSw0rd
• mStVIozEkbCTq1KYqElbkkd3TKQGpRak - long and totally random passwords mean, that most probably these are not boot-level passwords, at least not for physical machines

What data do you have exactly?

When buying drive encryption keys (passwords), you need to verify 3 aspects:

1. Do these passwords match any of Drive Badger's supported encryption schemes and partition types? If not - such passwords will be useless for Drive Badger, or possibly will require implementation of some custom logic.

2. How these passwords look like? And what additional data do you have with them? For example:

   • do they look like Bitlocker or Apple FileVault recovery keys? (see above)
   • do they look like user generated passwords?
   • do they look like PIN codes?
   • do they have any references to file names or device serial numbers? or just references, without actual passwords?

Bitlocker or Apple FileVault recovery keys are the best option: they are generated once and stay unchanged forever - unlike user generated passwords, which are changed sometimes.

Drive Badger doesn't support any external authentication hardware yet:

• TPM modules
• U2F dongles
• smart cards
• biometric devices
• keyfiles combined with passwords

PIN codes often mean, that real encryption keys are stored in TPM hardware module - so Drive Badger won't be able to use them.

3. Are these passwords assigned to particular computers or drives, or is it just the raw list of passwords?

If you have only passwords, then Drive Badger will need to check all of them on each computer separately. Once found, password will be assigned to encrypted drive, but again, on each Drive Badger drive separately. This is perfectly fine, if you have eg. 10 or 30 passwords. But if you have eg. 1600 passwords to check against 1600 devices, it starts to be painful.

How do companies store this kind of data

The last resort

If you don't have enough data to assign each password to particular drive, you can still try to reduce the number of passwords to search on each exfiltrated computer, by breaking the big list into smaller pieces using the information that you have - not into individual computers, but into:

• professions
• departments
• buildings (or cities)
• computer brands
• dates when these computers were bought or serviced (or are scheduled for replacement)
• individual configurations or computer stores (eg. some computer store gets only smallest computer configurations from vendors, and replaces RAM and SSD with some particular brand)
• and so on

Then instead of having eg. 5240 unknown Bitlocker passwords, you can have:

• 21 passwords for VIP computers
• 48 passwords for administration users across all buildings (these would be hard for further splitting, but you will probably exfiltrate mostly just 1-2 computers at single location, so it shouldn't be a problem)
• 24 passwords for HR/payroll computers
• 74 passwords for HR/soft computers, including 18 in a single room, and 56 "HR Business Partners" across all buildings and departments (again 1-2 computers at single location, so scanning ~50 passwords on each computer shouldn't be a problem)
• 173 passwords for software developers, including 96 hired before 2019 with older generation laptops, and 77 since 2019 (this is too many for effective attack, so keep looking for more information that would allow further splitting)
• etc.

In general, the more details you get about your target company before the attack, the shorter passwords lists to scan on each computer.

Structuring and uploading keys

When you reach to the point, when you have all available knowledge about obtained encryption keys, it's time to configure them on Drive Badger devices.

According to this article, Drive Badger supports 2 types of keys: assigned to drives, and unassigned. Let's start wth these.

Check the list and, looking at their length and structure, split them into Bitlocker, FileVault, LUKS, VeraCrypt, and possibly other keys/passwords, putting them into proper files - of course not literally into just 4 files, but as many files as you need, according to the above breakdown:

• bitlocker.keys
• filevault.keys
• veracrypt.keys
• luks.keys

Next, you should put these files into Git repositories:

• create as many private Git repositories as required (one file per repository, and follow the structure of demo repositories linked above)
• using /opt/drivebadger/internal/git/key.sh script create ssh keys named after created repositories
• register generated public keys as deployment keys for associated repositories
• look at the end of /opt/drivebadger/internal/git/pull.sh script, at first git pull command (with variables):
  • assemble the similar git clone commands for your repositories
  • clone them into /opt/drivebadger/config directory on all your Drive Badger devices

Once done properly, you'll be able to pull all future changes just by executing /opt/drivebadger/update.sh script. You can test it now by executing it and:

• if it asks you for password, or print something like "Permission denied", then you did something wrong with deployment key(s)
• it it just prints "Already up to date." for each repository, your Drive Badger device is ready

Protections against untrustworthy attack operators

Choosing the right people for the attack operator role is beyond the scope of this page. However, the below advices can help you reduce impact of choosing the wrong person:

1. You can split your key lists into any number of individual repositories you want - for example you can split all Bitlocker keys into separate bitlocker.keys files for each building and floor. This way, attack operator assigned to floors 7 and 8 will receive Drive Badger devices with deployed only "his" keys, instead of all.

2. It is wise to register separate Git deployment keys for each Drive Badger device - this way you will be able to "disconnect" any device from future updates in case when it falls into the wrong hands.

3. Finally, you can totally skip the deployment using Git repositories and write your own process oF deploying particular keys to particular devices - just make sure to visit this page to see, what configuration files do you need, and how they should be organized.