Just for sure: do you represent the eligible entity? Please read this page, before you go any further.
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 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).
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:
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.
Currently Drive Badger supports 4 drive encryption schemes - each of them have different looking keys:
User generated passwords can take many forms. Looking at their content, you can draw some conclusions:
August!2021- such passwords mean 2 things:
WAW.1817- such passwords mean 2 things:
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:
Before you buy passwords or recovery keys, you need to verify 3 aspects:
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.
How these passwords look like? And what additional data do you have with them? For example:
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)
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:
PIN codes often mean, that real encryption keys are stored in TPM hardware module - so Drive Badger won't be able to use them.
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.
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:
Then instead of having eg. 5240 unknown Bitlocker passwords, you can have:
In general, the more details you get about your target company before the attack, the shorter passwords lists to scan on each computer.
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:
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.
Take a look at the example configuration repositories. For each separate group of keys, create a new private repository, containing files named:
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).
Prepare the appropriate number of Drive Badger devices. Don't forget to install proper key repositories on particular devices.
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:
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.
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.
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.
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.