Menu

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

contact@drivebadger.com

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?

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). 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 using this script.

Sometimes, instead of Active Directory, other "directory services" are used, eg. Apache Directory Studio or 398 Directory Server. However, regardless of chosen system, you can expect that encryption key management process is fully automated. So:

  • you won't find them on paper, or in Excel
  • they are embedded in some database (possibly in encrypted form), and access to them is certainly logged
  • access to them is limited to a very small group of employees

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 above restrictions mean that even if you manage to find an employee with access to such database, and you properly "motivate" him, the very process of acquiring these keys will be either long (to remain unnoticed), or very risky. When planning an attack on a large company, you should consider this problem as one of the biggest threats to the entire plan.

How to recognize the key type?

Currently Drive Badger supports 4 drive encryption schemes - each of them have different looking keys:

  • Bitlocker - uses 2 types of keys: user generated password (known only by the user) and so-called recovery key, which is synchronized with AD, and looks like this: 123456-123456-123456-123456-123456-123456-123456-123456
  • Apple FileVault - just like Bitlocker, uses 2 types of keys: user generated password and recovery key, which looks like this: ABCD-1234-5678-90AB-CDEF-1234
  • VeraCrypt - uses 3 types of keys: user generated password, user supplied file, and their combination (Drive Badger supports passwords only)
  • LUKS - uses 2 types of keys: user generated password and user supplied file, however there are 8 separate key slots (and there can be up to 8 different passwords)

User generated passwords can take many forms. Looking at their content, you can draw some conclusions:

  • August!2021 - such passwords mean 2 things:
    • users are probably forced to change their passwords periodically
    • this user probably uses similar password schemes also for other accounts
  • WAW.1817 - such passwords mean 2 things:
    • this password was probably generated automatically (during Windows installation), not by user
    • individual elements of this password are probably related to natural factors (eg. "WAW" can mean a computer assigned to an employee in Warsaw, and "1817" is probably either a computer serial number assigned by company during installation, or some tax-related registration number, or part of some serial number that can be found on the computer case)
    • therefore, predicting possible passwords for given computer is potentially easy, if you have some knowledge about the company, its practices, hardware, or possibly photos of this computer
  • MyVCBootPassword123 - even without looking at the content of this password, its structure suggests that user avoided special characters to make its manual typing easier (so it's probably used at the level, where pasting password from clipboard is not available, eg. computer boot)
  • R3c0ve4y_p@sSw0rd - if the password is a natural language statement, this statement is most likely true
  • mStVIozEkbCTq1KYqElbkkd3TKQGpRak - long and totally random passwords mean 2 things:
    • that most probably these are not boot-level passwords, at least not for physical machines
    • user probably uses some password manager software

How to determine the real value before buying passwords or recovery keys?

Before you buy passwords or recovery keys, 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?

Remember that serial numbers of hard drives made by different manufacturers have different forms, eg.:

  • WD-WXB1HB4WRMM5 (Western Digital, consumer drives and USB)
  • 3WGMWHCJ (Western Digital, server drives and HGST product line)
  • 5NK0071W (Seagate)
  • S1XWJ1KS928872 (Samsung)
  • 4C530001311104105165 (SanDisk)
  • OCZ-481V7ELJU81890TW (OCZ)
  • P02012409004 (Plextor)

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 (Yubikey, Google Titan etc.)
  • smart cards
  • biometric devices
  • HSM modules
  • 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.

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

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

If you have any keys assigned to particular drives, you can configure them using save-drive-encryption-key.sh script, or directly upload proper files to keys directory.

As for unassigned keys:

  1. Look at their length and structure (see above), split them into recovery keys (Bitlocker and FileVault), and user generated passwords (LUKS, VeraCrypt and possibly other keys/passwords), putting them into separate files.

  2. Take a look at the example configuration repositories. For each separate group of keys, create a new private repository, containing files named:

  3. Think, which key groups can be safely joined on the same Drive Badger devices, without prologing key scanning processes (to reduce the overall cost of devices to buy).

  4. Prepare the appropriate number of Drive Badger devices. Don't forget to install proper key repositories on particular devices.

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.

  4. Drive Badger allows for having up to 8 separate passwords for LUKS-encrypted target partition. It is wise to use a separate password for each drive, or at least for each operator.

Finally, some general tips for choosing the right people:

  • Before you give someone access to sensitive data, think twice, if you really trust them - or, how much do you trust them. If not enough to entrust your freedom - then don't even start discussing such a possibility with them.

  • Read the emergency procedure and make sure, that other involved people also read it, before they get any devices or accesses to anything.