Archive for the ‘General’ category

Modern encryption tools employ strong encryption with multiple hash iterations, making passwords extremely difficult to break. The November article “What is password recovery and how it is different from password cracking” explains the differences between instantly accessing protected information and attempting to break the original plain-text password. In that article, I briefly mentioned GPU acceleration and distributed attacks as methods to speed up the recovery. In this article, I’ll discuss the two acceleration techniques in more detail.

Why do we need GPU acceleration?

Literally, we need GPU acceleration to break passwords faster. How much faster, exactly, depends on several things: the type of the video card (more on that later), the number of video cards installed, and the algorithm that was used to convert the password into a binary 128-bit or 256-bit encryption key.

If you have not yet read the “What is password recovery and how it is different from password cracking” article, you may want to review it for the basic theory of password cracking. Most types of data protection today implement encryption. The encryption algorithm protects data with a 128-bit or 256-bit Media Encryption Key (MEK, sometimes also referred as a Data Encryption Key, or DEK), which is long enough to make brute-force attacks out of the question.

With the binary media encryption key out of the reach of today’s brute force algorithms, one must target something else instead. The media encryption key itself is either directly produced from the user’s text-based password or encrypted with the user’s text-based password. The majority of plain text passwords have significantly lower entropy compared to 256-bit or even 128-bit media encryption leys.

Recovering the original password is often the only way to access the data. While makers of password recovery tools are trying to break password as fast as possible by trying increasing numbers of password combinations per second, makers of data encryption tools are doing exactly the opposite in order to slow down attacks. This is often achieved by increasing the number of rounds (recursive calculations of a hash function) that is used when processing the user’s input and turning it into an encryption key.

However, there is light at the end of the tunnel. Manufacturers of data protection tools cannot increase the protection indefinitely; there is only so much time the user is willing to wait for a password-protected document to open or an encrypted volume to mount. As a result, manufacturers profile their data protection algorithms so that the data can be accessed in about 0.3 to 1 second on an average (or below-average) system. Particularly important is the fact that all common data protection algorithms only use the system’s central processor (CPU) when it comes to verifying the password. Which brings us to the next point.

What is GPU acceleration and how does it work?

As demonstrated earlier, the speed of a single CPU is not enough to break many types of passwords. With hundreds of thousands or even millions hash iterations used to slow down the recovery, attacks running on a CPU alone can only break the simplest passwords. Additional computation power is urgently needed to break passwords in reasonable time.

At the same time, today’s power-hungry video cards ship hundreds of dedicated high-performance cores working in parallel. High-end and mid-range video cards manufactured by NVIDIA and AMD can render complex 3D scenes in real time; something that a bare CPU would struggle with.

This is how we arrived to the idea of using video cards to accelerate the recovery. GPU acceleration offloads computational-intensive calculations from the computer’s CPU onto the highly scalable video cards. Featuring several hundred GPU cores, a single video card can deliver the speed far exceeding the metrics of a high-end CPU. Depending on which video card is installed and what type of encryption we are dealing with, one can expect the recovery speed to raise some 50 to 250 times faster compared to CPU-only benchmarks.

Asynchronous GPU acceleration

If you have more than one video card installed, Elcomsoft Distributed Password Recovery can use up to 32 dedicated video cards at the same time.

What if those video cards running at different frequencies? Or what if they are different video cards altogether? This is where asynchronous GPU acceleration comes into play. With asynchronous acceleration, the password recovery tool can break jobs into smaller pieces, and feed every piece to a given video card. The asynchronous scheduler does not have to wait for a given part of the job to complete before feeding the next piece in line once one of the video cards finishes its slice.

In layman terms, heterogeneous GPU acceleration allows using multiple video cards of different makes and models, effectively utilizing existing hardware and squeezing the last bit of performance out of every supported component.

EDPR can utilize all GPU cores in mix-and-match scenarios if the video cards are made by different manufacturers. Whether you have a mix of AMD and NVIDIA boards or just want to make use of your computer’s built-in Intel HD Graphics cores, all of these can be used together to speed up the recovery.

How fast is GPU acceleration?

The “how fast…” is a million dollar question. GPU acceleration is only as fast as the video card (or video cards) installed in the computer. However, a video card that is fastest in 3D games or one offering real-time ray tracing is not necessarily the best for password recovery.

Long story short, there are no password recovery algorithms that would utilize the ray tracing acceleration units found in NVIDIA’s RTX series video cards. As a result, a NVIDIA GeForce GTX 1660 Super will break passwords at almost the same rate as a GeForce RTX 2060 Super with nearly double the price.

So how fast is GPU acceleration, exactly? These are the bare numbers:


What do the number mean, and how strong a password can you break with a single GTX 1660? We’ll use a password calculator to estimate the time required to break some types of passwords.

Attacking an encrypted Microsoft Office 2013 document with a single video card results in approximately 2900 passwords per second, or about a million (1044000) password combinations an hour.

A very simple (I would even say, unrealistically simple) password composed of only 5 characters (lower case letters and numbers only) has 60,466,176 possible combinations. Brute-forcing such a simple password with a GPU would only take about 58 hours. This very same password would take about 1.5 years of brute-force attacks using a CPU alone.

A weak password containing 6 characters including lower and upper case letters and numbers (but no special characters) has 56,800,235,584 possible combinations. This password would take 6.3 years to break on a single GPU.

An average password of 7 characters of the same group would take 385 years of brute-force attacks to break.

Distributed computing

385 years sound like an awful lot for a single-GPU attack. In other words, this is not a feasible attack to run. Granted, smart attacks including dictionaries, double dictionaries, prefixes, postfixes, mutations, scripted rules and whatnot do a great job when it comes to breaking passwords of ordinary Joe and Jane. They won’t do such a great job when attacking passwords of a seasoned hacker. In other words, we need more speed.

I already talked about multi-GPU acceleration; let’s do that and build a 4U rack server with as many as 8 GPUs. Great; this server will only take 48 years to break that password instead of 385! The next logical step is adding more of the same servers to the rackmount. If you use Elcomsoft Distributed Password Recovery, you can use up to 10,000 servers to your distributed network.

Cloud attacks

The linear scalability approach works great if you already have a data center equipped with up to date hardware. If, however, you were to build a dedicated data center from scratch, you may be shocked with the final bill. Hardware and maintenance costs, electricity and air-conditioning bills (you’ll have to pay for, and dissipate, some 1500W per computer) will add up quickly.

For those who require the fastest recovery speed without the hassle of building and maintaining a dedicated data center, we recommend considering offloading parts of the load the cloud. Using a cloud service means you’re getting a high-performance distributed network without having to build your own data center.

Using a cloud services (currently, Elcomsoft Distributed Password Recovery supports Amazon and Microsoft Azure clouds) offers a number of benefits over a static infrastructure. You can quickly add computing power on demand by renting additional instances, and quickly scale back once the job is done. With up to 16 GPUs per instance, you can build a network as fast as you need while keeping the costs under control.

Building a distributed cloud network is easier than you might think. Read Breaking Passwords in the Cloud: Using Amazon P2 Instances for details.


Even the fastest distributed network of 10,000 8xGPU computers will choke when trying to brute-force a .docx file protected with a 12-character password such as “JoeSmith1956”. However, this very same password can be broken easily with a simple hybrid attack in less than 2 minutes. This, however, is a very different topic.

Password managers or password reuse? This is the question faced by most consumers. Reusing a password or its minor variations for different accounts has never been a good idea, yet in today’s world of online everything the rate of password reuse reaches astonishing values. Using a password manager helps reduce password reuse, supposedly offering increased security. In this article, we’ll perform forensic analysis of some of the most common password managers.

Reusing Passwords is a Bad Idea

Major hacks and security breaches happen all the time. Occurring quickly one after another, there is little doubt the hackers are using databases of previously harvested passwords in order to try exploiting a variety of online resources. Password reuse is a major contributor to these hacks. After harvesting a single password database, hackers are quick to try stolen account credentials on other resources. Implemented via a botnet, these attacks may not trigger a security warning even if the account is compromised.

Old researches suggest the password reuse rate among user accounts on different services was at least 31 percent just a few years back. Today, the number of online accounts used by an average consumer had grown significantly, which led to severe increase of reused passwords. Recent reports suggest that some 59% of consumers reuse password across a number of different online services. This number can be significantly higher if we count the use of similar passwords.

What do these numbers mean in practice? For every 20 online accounts, an average consumer employs only 7 different passwords. Of these 7 passwords, only 3 are unique. The “different” passwords looks obviously similar. One of the most common behavioral patterns we observed was appending the number of digits and special characters required by a given Web site or resource to the end of the password. As a result, the list of “different” passwords may include simple variations such as password1, password123, Password1$, and so on. These patterns may be easy to detect and exploit during an investigation.

Password Reuse and Computer Forensics

While password reuse is bad for security, allowing hackers quickly attacking a number of services, it can be a blessing for computer forensics. By obtaining the list of passwords, experts may be able to determine a common pattern. This pattern, in turn, enables them building a so-called mask-based attack. Mask-based attacks reduce the number of passwords to try by allowing to specify something that all or most of the user’s password have in common.

As an example, Elcomsoft Distributed Password Recovery that we have updated a few days ago had significantly improved one of the most popular masks. Before we get to that, let us see what some of these passwords have in common:


As you can see, all of these passwords are based on a single key word “password” that may or may not start with a capital “P”. The key word may or may not be followed by a number containing up to 4 digits, that may or may not be followed by a special character. This is a very realistic scenario; the user tries using as simple a password as they can get away with. However, if a security policy enforces the use of a certain number of capital letters, numbers and special characters, the user simply adds them to the end of the password.

In EDPR 4.20, you can use a simple mask like this:


character group ?0: Pp
character group ?1: digits
character group ?2: special symbols

Now, what do the following passwords have in common?


All of these passwords are based on a single dictionary word that start with a small letter, that may or may not be followed by a number containing up to 4 digits, that may or may not be followed by a special character. If you were using an older version of Distributed Password Recovery, you’d have to build a very complex hybrid attack to account for all of these password variations. EDPR 4.20 makes it as simple as this:


character group ?0: digits
character group ?1: special symbols

Now, what if the user had a slightly more complex set of passwords like this:


These passwords are similar to the previous case in being based on a single dictionary word that may or may not be followed by a number containing up to 4 digits, that may or may not be followed by a special character. However, this time around the dictionary word may or may not start with a capital. Do we have a mask for that? Learn by taking a 3-day training course on breaking passwords!

Password Managers

1Password, Dashlane, KeePass and LastPass are the four most popular password managers. Password managers store, manage and (optionally) sync user passwords as well as other sensitive data. Password managers were explicitly designed to mitigate the issue of password reuse, offering the ability to generate, store and use passwords that are truly unique and non-reusable.

A typical password manager keeps all passwords in a database. The database is secured (encrypted) with a master password, and stored either locally or in the cloud. Password managers support both desktop and mobile devices, employing strong encryption to secure access to the password databases.

Notably, the entire password database is usually protected by a single master password. That single master password decrypts and opens all stored passwords.

Since most customers use their mobile devices to access accounts and open documents, password managers are also available on mobile platforms. Touch screens are no physical keyboard, and “motor learning” cannot be used to type complicated passwords; this results in simpler master passwords selected by users who frequently unlock their password vaults on mobile devices. Touch ID or Face ID do help avoid typing in the master password, but authentication with a master password is still required from time to time.

1Password is developed by AgileBits since 2006. This password manager supports Windows, macOS, iOS and Android platforms. The database can be stored locally, in Dropbox or in iCloud. The database is included with iTunes backups and iCloud backups.

LastPass was introduced by Marvasol Inc (acquired by LogMeIn) in 2008. LastPass also supports Windows, macOS, iOS and Android platforms. In addition, LastPass can be installed as a browser extension in many popular browsers. Passwords are synchronized through the LastPass server. In addition to desktop versions, the password database can be also acquired from browser extensions and Android devices.

Dashlane was developed by Dashlane in 2012; it also supports Windows, macOS, iOS and Android. Passwords are synchronized through Dashlane server. The password database can be only acquired from the computer or mobile device via file system extraction.

KeePass is an open-source application with native builds available for Windows only. There are numerous third-party ports for all major desktop and mobile platforms. KeePass offers no backup or synchronization options; the database can be acquired from the local PC or via file system extraction of a mobile device.

As I have already mentioned, password managers store passwords in local databases. These databases can be (and most probably are) encrypted with a single master password. Due to the sensitive nature of the information, the protection is typically very strong to sustain high-performance brute-force attacks. However, many password managers employ different protection settings for the different databases across their apps and plugins. A Windows desktop app would typically carry the strongest protection, while an Android app would use the weakest protection. Some password managers use adaptive protection strength that depends on the measured performance of the particular device.

Either way, using GPU-assisted attacks is a must when attacking password manager databases. The latest version of Elcomsoft Distributed Password Recovery can utilize GPU acceleration to speed up attacks on 1Password, Dashlane, KeePass and LastPass databases encrypted with a master password. The following benchmark demonstrate the performance of the attack on local databases extracted from the corresponding Windows desktop apps of 1Password, Dashlane, KeePass and LastPass:

If you’re confused with benchmark values for the different password managers, this is because they are confusing. Password managers do employ different protection settings in different environments. For example, if we take 1Password, the recovery speed depends on the hashing algorithm (SHA-1, SHA-256, or SHA-512) and the number of iterations. The desktop Windows app supports SHA-512 with a seemingly random number of hash rounds, which is calculated individually based on the performance and some other characteristics of the particular computer; this is to ensure that the password database is opened without a delay. Correspondingly, the speed of the attack falls as the the number of iterations increases. For this reason, the benchmarks for 1Password may look very confusing.

A Word of Caution: a Unique Password Is Not Enough

Even if one used a unique, random password for every online account, this may not be enough to secure online presence. A compromised ‘generic’ email account such as Yahoo! Mail not only enables the attacker to access historic email messages stored in that account, but to request password reset for other accounts registered with that email address. Which accounts exactly? That would be easy to guess by analyzing the user’s email history. A compromised Google Account opens access to the user’s entire digital life from comprehensive location history to – you guessed it! – stored passwords. Compromised Apple and Microsoft accounts lead to similar consequences. As a result, we cannot stress enough the importance of two-factor authentication. We believe no Apple ID, Google Account, Facebook or Microsoft Account should be ever used without two-factor authentication.


ASUSTOR advertises secure AES encryption with a 256-bit key. According to the manufacturer, AES-256 encryption is made available through the entire range of its current NAS devices. Unlike other manufacturers, ASUSTOR is very upfront regarding the type of encryption employed by its NAS devices: “ASUSTOR NAS offers folder based military grade AES 256-bit encryption”. As a result, we’re once again dealing with folder-based encryption running on top of the open-source encrypting file system eCryptfs. We’ve already seen eCryptfs-based encryption in attached storage devices made by Synology and TerraMaster. Does ASUSTOR have any surprises, or will its implementation of folder-based encryption suffer from the many restrictions and limitations? Let’s find out.

Abstract and Summary

ASUSTOR was established as a subsidiary of ASUS, a Taiwanese manufacturer of electronics and computer peripherals. The ASUSTOR name is a combination of “ASUS” and “Storage”. As the name suggests, ASUSTOR manufactures a range of attached storage devices based on ARM64 and Intel processors. ASUSTOR devices run ADM, which in turn is based on the Linux OS.

ASUSTOR implements folder-based AES encryption with a 256-bit key length. The encryption key is produced based on the user-provided password. Users cannot change the encryption key. They are not allowed to change or revoke compromised passwords either. An encryption key file is produced and saved while setting up an encrypted folder. Users can unlock encrypted volumes by either typing the original plain-text password or by uploading the exported encryption key through the ADM user interface. There is no reference to SED (Self Encrypting Drive) support anywhere in the ADM GUI or the official documentation; as a result, we have to conclude that no SED support is available in ASUSTOR consumer NAS models.

ASUSTOR offers sufficient documentation that details the limitations and restrictions of folder-based encryption, and provides several relevant user guides. The company does not attempt to hide or obscure the relevant technical details.

Encrypting existing data: supported. Users can encrypt existing shares containing data.

Decrypting encrypted folders: supported. Users can decrypt encrypted shares.

Revoking compromised keys or changing leaked passwords: not supported. If an encryption key is compromised, users must take the quest of decrypting and re-encrypting the data, which may take many hours or even days.

Encryption key: plain-text password or key file (must be manually exported while the encrypted share is mounted and unlocked).

The original password is used as a Media Encryption Key. The concept of Key Encryption Keys is never utilized here; as a result, users cannot change their encryption password (aside of fully decrypting and re-encrypting the share).

Test Bench

We analyzed an ASUSTOR AS6302T device equipped with an Intel Celeron J3355 Dual-Core CPU and 2GB of RAM. A pair of non-SED WD Red HDD have used to set up the NAS perform the analysis. The NAS was running on the latest version of ADM available at the time of testing.

ASUSTOR NAS: eCryptfs Folder-Based Encryption

ASUSTOR utilizes folder-based encryption based on eCryptfs, an open-source stacked cryptographic file system. Detailed information on eCryptfs is available here. This is the same encryption scheme as used in consumer Synology NAS devices; as a result, ASUSTOR NAS devices have many of the same limitations as Synology devices. Namely, the length of encrypted file names is restricted to 143 Latin characters; storing files with longer file names is not permitted. Using Asian characters makes the possible file names even shorter. Once the encrypted share is created, users cannot change the encryption passphrase.

One limitation that ASUSTOR devices do not have compared to Synology NAS is the ability to use NFS mount for encrypted folders. While Synology explicitly rules out NFS support for encrypted shares, ASUSTOR only has this information in the Knowledge Base: “The encrypted share folder can not be mounted by NFS ( ADM 2.4 or later). The encrypted shared folder used by ADM 2.4 (or later) is eCryptfs, so the NFS mount will not support for encrypted share folder.”


Users can encrypt newly created shares as well as existing shares that already contain data. Folder-based encryption allows users creating multiple shares, each with its own unique password. If there are multiple users, each user can encrypt their home folder with their own password. However, the inability to change the encryption password or to revoke compromised encryption keys makes this approach dubious in the grand scheme of things.

Creating an encrypted share

This is how an encrypted share is created.

Once the user ticks the “Encrypt this shared folder” box, ADM displays a warning message that lists the limitations and restrictions of encrypted shares.

The encryption password may contain 8 to 64 characters.

Users can optionally mount the encrypted folder during startup; this setting can be changed at a later date (which is not a given on some other NAS devices we have tested). If this setting is selected, the encryption key will be stored on the device, which automatically renders any and all protection null and void.

The usual access permissions are configured.

Once created, the encrypted folder is mounted automatically.

Exporting the encryption key

The 32-byte (256-bit) encryption key is automatically exported into a .key file once the user encrypts the folder.

Mounting encrypted shares

The encrypted volumes can be mounted manually or automatically. The “Auto-mount at system startup” setting can be changed at any time by editing the encryption settings.

Mounting encrypted shares through the user interface supports the following two options.

  1. Mounting with the original plain-text password.
  2. Mounting with the exported key file.

Unmounting encrypted shares

Encrypted shares are unmounted automatically once the NAS is powered off or rebooted. Manually unmounting the encrypted share requires accessing the Web UI:

Permanent decryption

ASUSTOR does not utilize the concept of separate Media Encryption and Key Encryption keys. As a result, users cannot change the password or revoke compromised encryption key. In order to do that, users must physically decrypt the entire set of data and re-encrypt it with another password. At very least, ASUSTOR does support the decryption of encrypted shares:

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary encryption keys that are used to encrypt and decrypt the data, and secrets that are used to unlock the encryption keys. This wonderful concept allows many things such as using any one of the several different passwords (or multiple types of authentication credentials, such as a smart card or a password) to unlock encrypted volumes. Sadly, this concept is rarely used by NAS manufacturers. ASUSTOR is no exception; users cannot change the password because the password itself is the Media Encryption Key.

Automatically Mounting Encrypted Folders

If the user had specified that the encrypted volumes are to be mounted automatically, they will be decrypted when the NAS starts up. You may reset the root password in /etc/shadow to gain access to the content of the NAS.

Manually Decrypting Encrypted Shares

Since ASUSTOR utilizes eCryptfs, accessing encrypted folders from another computer is easily available. Please refer to our Synology and TerraMaster guides for detailed instructions and the list of commands.

ADM keeps encrypted files in folders using the following naming convention:


“Test” would be the name of the encrypted share. The encrypted share is mounted as /share/Test

Encrypted share “Test” mounted:

root@Asustor:/volume1/.@encdir/Test # df -h
Filesystem              Size  Used Avail Use% Mounted on
rootfs                  874M   56M  819M   7% /
tmpfs                   914M   20K  914M   1% /tmp
/dev/md0                2.0G  384M  1.5G  21% /volume0
/dev/loop0              951K  9.0K  922K   1% /share
/dev/md1                5.5T  495M  5.5T   1% /volume1
/volume1/.@encdir/Test  5.5T  495M  5.5T   1% /share/Test

Encrypted share unmounted:

root@Asustor:/volume1/.@encdir/Test # df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          874M   56M  819M   7% /
tmpfs           914M   20K  914M   1% /tmp
/dev/md0        2.0G  384M  1.5G  21% /volume0
/dev/loop0      951K  8.0K  923K   1% /share
/dev/md1        5.5T  495M  5.5T   1% /volume1

The encrypted folder was mounted with the following parameters:

/volume1/.@encdir/Test on /volume1/Test type ecryptfs (rw,relatime,ecryptfs_fnek_sig=704b798b4658aa6a,ecryptfs_sig=704b798b4658aa6a,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)
/volume1/.@encdir/Test on /share/Test type ecryptfs (rw,relatime,ecryptfs_fnek_sig=704b798b4658aa6a,ecryptfs_sig=704b798b4658aa6a,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)

To mount the encrypted share, execute the following commands.

Insert the passphrase into the keyring (you will need to provide the encryption passphrase):

ecryptfs-add-passphrase –fnek

Create a folder where you’ll be mounting the encrypted file system to:

mkdir /volume1/Test

Mount the encrypted folder in interactive mode:

mount.ecryptfs /volume1/.@encdir/Test /volume1/Test

While mounting, specify cipher: “aes”, key bytes: “32”, plaintext passthrough: n, filename encryption: y. Confirm filename encryption key by pressing “Enter”.

What Risks Are Covered by ASUSTOR Security Model

Similar to other implementations of NAS encryption, the security model employed by the ASUSTOR is stripped down to the bare essentials. I have the following remarks about the ADM security model.

  1. The possibility to store the encryption key on-device if the user enables the automatic mount option completely negates the protection of folder-based encryption. The lack of SED or full volume encryption makes gaining access to the NAS easy.
  2. This encryption model does not properly protect the data if one needs to send it out for repair/replacement or simply wants to sell the disk. The encryption metadata is duplicated in every file in the encrypted folder. As a result, the attacker can obtain a single file and run a (fast) attack on the encryption key.
  3. Unlike volume encryption schemes, folder-based encryption with encryption metadata duplicated in every file. “eCryptfs stores cryptographic metadata in the header of each file, so that encrypted files can be copied between hosts; the file will be decrypted with the proper key in the Linux kernel keyring.” (source) This makes secure erase of encrypted data impossible. To securely erase data encrypted with eCryptfs, one must either wipe (overwrite) encryption metadata in each and every encrypted file; wipe the full content of every file; or wipe the entire disk.
  4. Neither the encryption nor the password can be changed. Enough said.

Conclusion: ASUSTOR Folder Encryption

When it comes to attached storage encryption, we are still in the Stone Age. The lack of basic features, many of which we accept as a given, makes ASUSTOR encryption barely acceptable by modern standards. The functional restrictions and encryption metadata duplicated in every file makes this type of encryption hardly useful. ADM does not separate Media Encryption Keys and Key Encryption Keys, which makes password changes impossible. Security wise, the data would be impossible to decrypt without knowing (or breaking) the user’s encryption password (or, alternatively, without access to the exported encryption key).

Compared to Synology, ADM offers fewer options for storing and protecting the encryption keys. While Synology offers the ability to store the auto-mount encryption key on the device itself or on a USB drive (the latter using a separate passphrase to protect the key), ADM only offers the first way without any sort of additional protection.

At the same time, ADM encryption implementation is straightforward enough to appeal to some users. However, those same users may be put off by the need of re-entering their encryption password in the Web interface every time they power on or reboot the NAS. Should they opt to automatically mount encrypted shares on startup, they immediately sacrifice the protection.

Modern wireless networks are securely protected with WPA/WPA2. The most frequently used method of securing access to a wireless network is pre-shared passphrase, or, simply put, a text password. The WPA standard enforces the minimum length of 8 characters for all Wi-Fi passwords. Considering the relatively low performance of WPA/WPA2 password attacks, brute force attacks are rarely effective even when performed with a network of GPU-accelerated computers. In this article, I will show how to attack wireless passwords for the purpose of security audit.


First and foremost, you’ll need a WPA/WPA2 handshake dump. This dump is essentially a file you’ll be using in the password recovery app when attacking Wi-Fi passwords. In order to capture the WPA/WPA2 handshake, use the built-in Wi-Fi sniffer in Elcomsoft Wireless Security Auditor.

The traditional approach to capturing a WPA/WPA2 handshake was using a dedicated AirPCap wireless adapter and specialized software. Elcomsoft Wireless Security Auditor takes AirPCap out of the equation, delivering a software-based Wi-Fi sniffing solution that works on regular Wi-Fi adapters. The custom NDIS driver for 32-bit and 64-bit Windows systems is digitally signed by Microsoft, and can be installed on all compatible versions of Windows including the latest builds of Windows 10. With this tool, you can automatically intercept Wi-Fi traffic and launch an attack on selected Wi-Fi networks.

Note: you must install a WinPCap driver to enable Wi-Fi sniffing. A compatible WinPCap driver is provided with Elcomsoft Wireless Security Auditor.

Please refer to Elcomsoft Wireless Security Auditor manual for information on installing WinPCap and NDIS drivers and capturing a WPA/WPA2 handshake.

You can attack passwords within Elcomsoft Wireless Security Auditor for GPU-accelerated recovery, or Elcomsoft Distributed Password Recovery, which can use multiple computers and multiple GPU units to accelerate attacks.

The Attacks

The WPA/WPA2 always consists of at least 8 characters. Even if the password is exactly 8 characters long, can you break it using a brute-force attack? Let’s calculate!

An 8-character password that contains characters from the extended character set (small and capital letters, number and special characters) has 6,634,204,312,890,625 possible combinations. A single NVIDIA Tesla V100 can try as many as about 650,000 WPA/WPA2 passwords per second.

As a result, you’ll need an estimated 323 years to break that password using a single Tesla V100 board. Granted, you can cut this number by utilizing a thousand computers, each with eight V100 boards, and get a much more reasonable estimate, but why would anyone spend that much effort breaking a Wi-Fi network protected with just an 8-character password?

A smarter attack won’t cost you anything, but may result in significantly higher success rate in significantly less time.

Try Phone Numbers First

If you are not auditing a Pentagon network, a good starting point will be the list of local phone numbers. While passwords like these are relatively uncommon, we’ve still seen them in 1 to 3% of the cases. Considering the very short duration of this attack, the list of local phone numbers is totally worth checking.

All-Digit Passwords

A good number of Wi-Fi access points are protected with passwords consisting of exactly 8 digits. While this attack takes longer than trying the list of local phone numbers, it may be worth running depending on your computational resources. A single video card will crunch through these all-digit passwords in under three minutes, making it worth a try.

Targeting the Human Factor

Wi-Fi passwords are meant to be shared and used by a number of people. More often than not, these passwords are made to be easy to memorize and easy to type, especially on mobile devices. As a result, many passwords are based on combinations of one to three dictionary words, some numbers, and very few special characters. In other words, we recommend using automatically adjusted dictionary attacks when auditing Wi-Fi passwords. If a wireless network can withstand a GPU-assisted dictionary attack with mutations during a given timeframe, one can consider the network to be secure.

Leaked passwords

Every year, millions of user accounts are compromised, and millions of passwords are leaked. We strongly recommend obtaining the list of the most commonly used passwords such as the Top 10,000 passwords or Top 10 million passwords, and run a simple, straightforward attack through the dictionary of leaked passwords.

The dictionaries of the most common passwords can be obtained from GitHub.


Wi-Fi passwords frequently contain one or more words in natural language. You can often recover such passwords by running a dictionary attack. A dictionary attack against a Wi-Fi password requires one or several dictionaries; a dictionary of English words is a good starting point, but dictionaries of local languages should not be forgotten.


Users frequently attempt to “secure” a password using a well-known word and applying some modifications. Sometimes, the among of modifications is just enough to pass the enforced security policy. For example: JohnSmith1, J0hnSm1th, Eva-1980, Peter1$ and so on.

To help attacks target passwords selected by average users, we developed an automated mutations engine. The mutations engine automatically alters dictionary words to mimic common patterns. You can easily apply mutations to dictionary words. More time is required when more mutations or higher mutation level are selected.

Elcomsoft Wireless Security Auditor offers a dozen different mutations. Enabling all of these mutations at the same time enormously expands the number of passwords to try, making it difficult or impossible to reach the end of the list in reasonable time. For this reason, we strongly recommend using a reasonable number of mutations and choosing only those mutations that are likely to be used in a given case.

In real life, we’ve witnessed the following three mutations being the most popular:

Case mutation: different variations of uppercase and lowercase characters.

Digit mutation: one or more digits added to the beginning or at the end of the password.

Year mutation: a four-digit year appended to the end of the password.

You can read more about mutations in the Attack Settings and Dictionary Mutations sections of the manual.


Some organizations have strict password security policies requiring the use of a certain number of small characters, capital letters, numbers and special characters. If you know the rules, the mask attack helps you use such policies to your advantage by only checking for passwords that match the known structure.

Note: while the Mutations attack expands the number of passwords to try, Masks do the opposite by skipping checks on passwords that don’t match the set mask.

You can read more about the masks in the Attack Settings.

Combination and Hybrid attacks

In real life, encountering passwords made of a single dictionary word is rare. More often than not, passwords consist of two or three words combined with some numbers and special characters. The Combination and Hybrid attacks target this kind of passwords by allowing you to try passwords made of two words, each of them taken from the dictionary. You can use the same or different dictionaries for the first and second words. We recommend enabling the check for upper-case and lower-case combination, word delimiters and extra mutations.

With the first option, the program will try to capitalize the first letter of each word, i.e. testing all four combinations. The second option (Use word delimiters) allows to set the different characters (like dash and underline, though you can set any other ones as well) to be used between words. Finally, you can apply extra mutations to all resulting passwords (Dictionary mutations options will be used). The program tries to estimate the total number of passwords instantly, but mutations will not be counted.

Hybrid attacks are even more complex, allowing to specify scriptable rules desribing the passwords. Combination and Hybrid attacks are documented in the Attack Settings section of the manual.

Suggested Wi-Fi Password Auditing Workflow

Our suggested workflow for auditing Wi-Fi passwords consists of the following steps.

  1. Prepare the list of local phone numbers and save it as a text-based dictionary file. Run a plain, straightforward, zero-mutation attack through that dictionary.
  2. Try all-digit passwords. Depending on the available computational resources, you may be able to try passwords containing 8 to 10 digits in a matter of minutes. From the technical standpoint, this is considered a brute-force attack configured as follows: minimal password length = 8; maximum password length = 10; character set: 0123456789
  3. Run an attack through the Top 10,000 and Top 10 million password lists. Again, no mutations, just straightforward dictionary attacks.
  4. Run a dictionary attack with mutations (single dictionary).
  5. Optional: run a dictionary attack with masks.
  6. Run a hybrid attack with two dictionaries and mutations (note: the two dictionaries may be the same or different to help you try combinations of two words).

How can you make your system and documents secure? Today, 256-bit AES encryption is offered by everyone and their dog. However, AES encryption does not mean much (or anything at all) when it comes to the real security of your data. Implementing encryption at the right time and in the right spot is no less important than choosing strong encryption credentials and managing the encryption keys.

While the previous part may sound a bit complicated, it all comes down to much simpler things than choosing the strongest encryption algorithm or selecting the length of the encryption key. If you are a Windows user, it all comes down to choosing the optimal data protection strategy for your particular usage scenario; protecting your storage media and the data you keep on them.

Defining your goals

Before you start considering encrypting your hard drives and files, make sure to define your objectives. What information would you like to protect? What threats do you consider important, less important and quite improbable?

Full-disk encryption part I: protecting your boot device

A reliable system protection is impossible without protecting your boot device. An unencrypted boot device (disk C: on most systems) allows for way too many vectors of attack ranging from hibernation and page file analysis to instant extraction of stored passwords from your Web browser vault. In other words, securing your boot device with BitLocker is an absolutely mandatory preliminary step and the most important security layer.

  • Availability: Windows 10 Professional and higher with TPM2.0, Intel PTT or Group Policy edit; all Windows editions for device encryption in thin and light devices meeting minimum requirements.
    • Note: although Windows 10 Home cannot natively create new BitLocker volumes, it can unlock BitLocker encrypted drives with full read-write access
  • Physical access, hard drive only: strong protection
  • Physical access, entire computer: it’s complicated
  • Other users on the same computer: not applicable
  • Malware/ransomware: not applicable
  • Online attacks: not applicable
  • Usage cases: protect data against theft of computer or hard drive; protect data if hard drives are sold or RMA’d; protect data against physical extraction.

If your computer meets the requirements (namely, the presence of a hardware TPM2.0 module or software-based Intel Platform Trust Technology), enabling BitLocker on your computer can be as easy as opening the Control Panel and launching the BitLocker Drive Encryption applet. Note that not all editions of Windows 10 can use BitLocker protection.

We have a comprehensive article on BitLocker protection in our blog, which is highly recommended. Introduction to BitLocker: Protecting Your System Disk

What caveats are there when it comes to securing data against physical extraction? The thing is, while BitLocker is nearly a 100% effective solution for protecting the bare drive, it might not be as secure if the intruder has access to the entire computer with the hard drive installed. Even if your computer is equipped with a TPM2.0/Intel PTT module, Windows will still unlock the encrypted hard drive if Secure Boot conditions are met. This in turn opens numerous vectors of attack that may allow the intruder to intercept the on-the-fly BitLocker encryption key and decrypt the hard drive. These vectors of attack include:

  1. Making a RAM image of a running computer with BitLocker volume(s) mounted. This can be done via a Thunderbolt attack (Windows, by default, does not disable Thunderbolt DMA access when locked) or a cold boot attack.
  2. Breaking or extracting your Windows logon password (e.g. extracting from your Google account, your smartphone, or from another computer you have logged in and synced your data to).
  3. Obtaining your BitLocker Recovery Key from your Microsoft Account or Active Directory.

Advanced users and system administrators can read the following guide to secure their BitLocker volumes: BitLocker recovery guide

Full-disk encryption part II: protecting external storage devices

BitLocker is good not only for protecting your boot device, but for encrypting data on other volumes, built-in and removable. BitLocker protects external storage devices with BitLocker To Go, an encryption algorithm based on a password. In addition to passwords, external drives encrypted with BitLocker To Go have an option to unlock with a smart card on another computer by using BitLocker Drive Encryption in Control Panel. Finally, users can opt to make their encrypted external devices automatically unlock when connected to their (trusted) computer.

  • Availability:
    • Encrypt external devices: Windows 10 Professional and Enterprise
    • Access BitLocker encrypted devices: although Windows 10 Home cannot natively encrypt drives with BitLocker, it can access BitLocker encrypted drives with full read-write access
  • Physical access, device only: protection as strong as your password
  • Physical access, entire computer: it’s complicated (see previous chapter)
    • Note: if you enabled the option “Unlock automatically on this PC”, then effectively no protection
  • Other users on the same computer: strong protection if offline/not mounted
  • Malware/ransomware: strong protection if offline/not mounted
  • Online attacks: strong protection if offline/not mounted
  • Usage cases: protect data stored on external storage devices such as external drive enclosures, USB flash drives etc.

Unlike system drive encryption, BitLocker To Go does not support multifactor authentication. This means you cannot use TPM protection as an additional form of authentication. You can, however, make BitLocker To Go devices unlock automatically when they are inserted in your (trusted) computer, which carries obvious security implications.

Full-disk encryption part III: using third-party crypto containers

I put it here just for the sake of completeness. If you are considering using a crypto-container such as VeraCrypt or PGP, you probably know what it is good for and how to use it. I’ll just add several things that aren’t immediately obvious when you set up encryption. In fact, the two things are so non-obvious that many coach experts have it backwards. (The right way: Choosing the right hashing algorithm – it’s all about slowness).

  • Availability: VeraCrypt is available on most relevant platforms
  • Physical access, hard drive only: very strong protection unless misconfigured
    • Misconfiguration examples: volume stays mounted when computer sleeps or hibernates; volume stays mounted when computer is locked (matter of security vs. convenience); volume unlocked with security key (e.g. USB flash drive) and no password (if USB flash drive is discovered)
  • Physical access, entire computer:
    • volume not mounted at time of analysis: very strong protection
    • volume mounted: very little protection
  • Other users on the same computer
    • volume not mounted at time of analysis: very strong protection
    • volume mounted: very little protection
  • Malware/ransomware: same as above
  • Online attacks: same as above
  • Usage cases: protect data against theft of computer or hard drive; protect data if hard drives are sold or RMA’d; protect data against physical extraction.

The choice of encryption algorithm (spoiler: use AES)

Crypto containers such as VeraCrypt offer the choice of several (actually, multiple) encryption algorithms that range from the industry-standard AES to some quite exotic algorithms such as Serpent or Kuznyechik. For the paranoiacs among us, VeraCrypt offers stacked encryption (e.g. the Serpent(AES) option). The thing is, the choice of an encryption algorithm does not affect the security of your data (unless you pick an algorithm with known or suspected vulnerabilities; finger pointed to Kuznyechik).

The choice of encryption algorithm does not affect the security of your data. A single round AES-256 encryption will be exactly as secure as Serpent(AES) or Serpent(Twofish(AES)). Moreover, the choice of encryption does not even affect the recovery speed (the speed of brute-force attacks on your password)!

Considering that AES is the only hardware-accelerated encryption algorithm in all reasonably modern processors, choosing any encryption algorithm other than AES-256 will unnecessarily slow down your reads and writes (expect a difference of 2 to 3 orders of magnitude in theoretical RAM-to-RAM encryption speeds) without providing any additional security benefit.

If choosing an encryption algorithm other than AES does not affect security, then what does?

The choice of hashing algorithm

When VeraCrypt encrypts (or decrypts) your data, it is using a binary encryption key to perform symmetric cryptographic operations. This media encryption key (MEK) is stored along with the encrypted data. The Media Encryption Key (MEK) is encrypted with a Key Encryption Key (KEK), which, in turn, is the result of multiple (hundreds of thousands) iterative hash operations performed on the user’s password.

In other words, when you type a password, the crypto container will perform a calculation of a certain hash function, and repeat that a 100,000 times or more (in order to deliberately slow down brute-force attacks).

If you want to make your encrypted volume more secure, you can change one of the two things:

  1. Increase the number of hash iterations
  2. Don’t use defaults
  3. Choose a slower hash function

VeraCrypt allows modifying the number of hash iterations by adjusting the PIM (Personal Iterations Multiplier); here is the how-to. The PIM value controls the number of iterations that is used to derive the encryption key from the password that you type. This value can be specified through the password dialog or in the command line. If you don’t manually specify the PIM value, VeraCrypt will use the default number of iterations, which is bad because (2). For SHA-512 or Whirlpool (the two recommended choices), VeraCrypt defaults to Iterations = 15000 + (PIM x 1000).

Why would you want to change the number of hash iterations? Because an attacker will first try to break your password using the defaults. Most tools used by the attackers to brute-force your password will first run the attack using all-defaults: the default encryption algorithm (AES), hash function (SHA-512) and PIM. Changing the PIM value is an easy way to substantially increase security without making your password more complex. Changing the hashing algorithm from default (SHA-512) to Whirlpool also makes sense in this context.

Which brings us to the choice of a hashing algorithm. VeraCrypt offers the choice of SHA-512 (slow, good choice), Whirlpool (slower, even better choice), SHA-256 (slow, but not as slow as SHA-512, use other hash instead), and Streebog (untested). Choosing the right hashing algorithm – it’s all about slowness has some benchmarks and some good explanations; highly recommended. Selecting Whirlpool makes a lot of sense because a) it is slower than SHA-512 (thus will be significantly slower to attack), and b) it is a non-default selection, which significantly increases the complexity of the attack.

File system encryption: when and how to use EFS

If you read the Wikipedia article about Microsoft Encrypting File System (EFS), you’ll get that EFS has been introduced in NTFS 3.0 in order to provides file system level encryption. The article reads: “The technology enables files to be transparently encrypted to protect confidential data from attackers with physical access to the computer.”

While all of that is interesting, neither statement explains who and, most importantly, why should be using EFS, and what exactly the encrypting file system protects against.

  • Availability: all versions and all editions of Windows 10 (and most older versions of Windows)
  • Physical access, hard drive only: as strong as your Windows account password
  • Physical access, entire computer: same as above
  • Other users on the same computer: effective protection
  • Malware/ransomware: not applicable
  • Online attacks: not applicable
  • Usage cases: protect your documents from other users of your computer; an extra layer of security on BitLocker-protected drives; reasonably strong, very easy and fully transparent document encryption on computers where BitLocker is not supported.

What does EFS protect against, and who should be using it?

The purpose of Encrypting File System is protecting your data from users who share your computer. If you have a PC with several users, and each user has their own Windows login (as opposed to sharing a single Windows account), activating EFS encryption is the easiest way to protect your files from being accessed by those other users.

What is the relation between EFS and BitLocker, and which one should you use?

BitLocker protects your entire system volume. Any user who can log in to your computer will unlock the system volume. If a user has administrative privileges (or can escalate a non-admin account by using an exploit), he or she will also gain access to files and documents stored in other users’ accounts on that computer.

Encrypting File System, on the other hand, only protects selected folders. It won’t, for example, protect your instant messenger databases or encrypt your browsing history. It’s mostly just for documents, pictures and videos you keep in your account. However, EFS will effectively protect those files against other users who can log on to your computer, even if they have administrative privileges.

If an attacker got physical access to the computer, BitLocker is the first line of defence. Relying solely on EFS to secure the PC against attacks with physical access is not the best idea.

How does it all work? It’s actually quite simple. Right-click on a file or folder you’d like to encrypt, select Properties and click the Advanced button in the General tab. In the Advanced Attributes dialog select Encrypt contents to secure data and click OK.

This is it. Windows will now encrypt the selected file or folder with your Windows logon credentials. There are no passwords to type and no encryption keys to save.

There is a certain drawback to using EFS encryption. If you ever forget your Windows password and have to reset it from a separate Administrator account (or your domain administrator resets the password for you), the EFS encryption keys will be lost, and you will be unable to decrypt your data without going through the data recovery process with Elcomsoft Advanced EFS Data Recovery. Note that you must recover your Windows password in order to decrypt the files. However, if you simply change your Windows password by following the normal procedure (typing your old password followed by entering the new one), you will be fine.

Document encryption

Encrypting individual documents is an important part of multi-layer security. Microsoft Office apps can use passwords to encrypt the documents’ content. No one without a password should be able to decrypt the document.

  • Availability: all versions of Microsoft Office
  • Security: depends on the version of Microsoft Office, the file format you’re using to save the files and the strength of your password.
  • Physical access, hard drive only: strong protection (with caveats)
  • Physical access, entire computer: strong protection (with caveats)
  • Other users on the same computer: strong protection (with caveats)
  • Other users on your Local Area Network: strong protection (with caveats)
  • Malware/ransomware: content protection. Malware won’t be able to decrypt your files and read your data. However, malware/ransomware can still encrypt your files, effectively locking you out.
  • Online attacks: content protection. Strong protection against unauthorized data access; no protection against unauthorized deletion
  • Usage cases: protect the content of your documents against anyone who does not know the encryption password.
  • How to: Protect a document with a password

A million dollar question: if you are on a local area network, should you use EFS or document encryption to protect documents against other users on the same LAN? In this case, it’s better to use both. EFS will make it impossible to gain access to encrypted files and folders without knowing your Windows account/domain credentials. Password protection of individual documents will make documents difficult to break even if the attacker knows your logon credentials.

The caveats of document encryption

So what exactly does “strong protection (with caveats)” mean? The thing is, your documents are just as secure as the password you use to protect them. If you re-use a password you already stored in your browser cache or in the keychain, extracting that password and decrypting the documents will be a matter of minutes in many types of attacks.

What if you use a cryptographically strong and truly unique password to encrypt documents? Are these documents secure? The thing is, they will be just as secure as the office app permits them to be. In Microsoft Office encryption evolution: from Office 97 to Office 2019 I discussed the encryption algorithms and protection strength of Microsoft Office apps from the early days to the most current release.

Generally speaking, everything before Office 2000 was insecure (no protection). Office 2000, XP and Office 2003 had very weak encryption that can be usually broken in under a day.

Since Office 2007, Microsoft started taking encryption seriously. Office 2010, 2013, 2016, 2019 brought security to the new level, making encrypted documents very secure.

Okay, so you are using the latest Office and selected a strong password; are we secure now? The thing is, you’ll be just as secure as the document format allows. If you are using the newer DOCX/XLSX format (files with .docx / .xlsx extensions), you’re good. If, however, you are saving your documents in “compatibility” mode, you are sacrificing encryption and make your documents as vulnerable as if they were saved by an Office 2003 app.

Best practices:

  1. Use the latest version of Microsoft Office to save documents. If the latest version is not available, use at least Office 2013 (the newer the better).
  2. Never save documents in “compatibility” mode. Make sure that the files are DOCX/XLSX as opposed to DOC/XLS.
  3. Use a unique, cryptographically strong password to encrypt documents. Remember: if the password is broken once (e.g. pulled from your Google account or recovered from a document you accidentally saved in the “compatible” format), it will be used to break everything else, including documents with strong encryption.
  4. If you email an encrypted document, do use a unique, one-time password for that document, and never send both the document and the password in the same email. In fact, you should never send the password by email since that would allow an attacker who gained access to your email account to decrypt the document. Send the document and the password via separate communication channels (e.g. email / text message, chat or phone call).

Protecting backups and archives

Making regular backups is a common wisdom. Protecting those backups is a wisdom much less common. Once you make a backup, make sure to give it as strong a protection as your boot drive.

  1. Store backups on BitLocker-protected media. Even if your backup tool (e.g. the one built into Windows) does not support encryption, at very least your storage media is protected with full-disk encryption. Note: Windows 10 does support the recovery from BitLocker-protected disks. Just create a bootable install image from Microsoft Web site (use “Create Windows 10 installation media”).
  2. If your backup tool supports encryption, it may be a good idea to encrypt your backups (AND store them on a BitLocker-protected media). Note, however, that a backup tool will probably cache (store) your backup password on your computer to automatically encrypt new and incremental backups. For this reason, make sure to have a truly unique, never reused password for encrypting backups.

Individual folders are frequently backed up using common archive tools such as WinZip, 7Zip or WinRar. All of these tools offer the ability to encrypt archives with a password. While the encryption strength is different among the three formats (ZIP, 7Z and RAR), an up to date version of each tool provides adequate protection if you choose a reasonably complex password (e.g. 8 characters or more, combining small and capital letters with numbers and special characters). To achieve the best level of protection, do keep those archives on BitLocker-protected media.

Note that password recovery tools work significantly faster on ZIP/7Z/RAR compared to attacking BitLocker encryption or Office 2013 (and newer) documents. For this reason, never reuse your password, and make sure that your BitLocker media, your documents and your backups/archives use very different passwords (ideally, not based on the same pattern).

More information:

Cloud security: OneDrive Personal Vault

Microsoft started offering an extra layer of security to all users of its cloud storage service in the form of a Personal Vault. OneDrive Personal Vault helps secure your files both on your computer and in the cloud in the event that someone gains access to your account or your device.

Unlike ransomware protection, Personal Vault is available to all users of Microsoft OneDrive and not just to Office 365 subscribers. Technically speaking, Personal Vault is an area in the OneDrive folder on your computer and in the OneDrive cloud storage that features additional protection. You can only access this protected area after passing a strong authentication. If your Microsoft Account is protected with two-factor authentication, you will have to pass the second step of identity verification in addition to typing your Microsoft Account password.

Once configured, Personal Vault must be manually unlocked every time you need access to secured data. To unlock, you must type in your Microsoft Account password and pass the second authentication step if your account has two-factor authentication. Once you’ve finished accessing the data, Personal Vault will automatically relock after a short period of inactivity. Once locked, any files you were using will also lock and require re-authentication to access.

Setting up Personal Vault only takes a few clicks as outlined in Protect your OneDrive files in Personal Vault.

OneDrive Personal Vault is still new; no independent security analysis has been performed until today. In our view, Personal Vault is worth consideration as an extra security layer for some of the most private but rarely accessed types of data. Examples of such data may include BitLocker escrow keys and binary encryption keys, or the list of passwords some users store in encrypted Excel spreadsheets. I personally keep my two-factor authentication secrets (scanned QR codes to initialize the Authenticator app) in the Vault as well.

  • Physical access: unknown (not yet analyzed)
  • Other users on the same computer: strong protection
  • Malware/ransomware: strong protection (unless Personal Vault is unlocked at the time malware is running)
  • Online attacks: as strong as your Microsoft Account security
  • Usage cases: activate to add an extra layer of security for a handful of personal documents, encryption keys, 2fa secrets etc.


Ransomware protection

One of the most important threats not covered by any encryption is the type of malware called ransomware. Ransomware is a type of malware that threatens to either publish the data stolen from the victim or perpetually block access to the victim’s files by encrypting them with a key that is only known to the attacker. The term ‘ransomware’ has emerged from the fact that, on many cases, attackers demand a ransom payment to decrypt data.

Protecting your data against ransomware is a complex topic in itself. However, computer users can choose one or both of the following two defences when it comes to ransomware protection.

Ransomware protection is effective against the following threats.

  • Physical access: no protection
  • Other users on the same computer: no protection
  • Malware/ransomware: effective protection
  • Online attacks: as strong as your cloud account security
  • Usage cases: available automatically to Office 365 subscribers. Available to paid Dropbox users. Automatically protects files stored in OneDrive/Dropbox. Automatic alerts (OneDrive only). Automatic restore (OneDrive only); manual restore (Dropbox).

Use cloud storage with automatic ransomware protection

If you are using Windows 10, most likely you already have a Microsoft Account. The Microsoft Account gives you access to OneDrive, Microsoft’s cloud storage solution. The free tier includes 5 to 15 GB of online storage, while Office 365 subscribers receive the whole terabyte of cloud storage.

Microsoft actively promotes OneDrive Ransomware Protection. OneDrive automatically detects when the files are mass-deleted or mass-edited (such as when ransomware encrypts the entire Documents folder), alerts the user and prompts to restore the known-good snapshot. The File Restore feature is only available to Office 365 subscribers (Home and Personal levels are enough to receive protection).

More information at Ransomware detection and recovering your files.

If you prefer Dropbox to Microsoft OneDrive, Dropbox gets you covered against ransomware attacks, but mostly for higher-level paid tiers. Users of the free Basic tier as well as Plus subscribers can roll back individual encrypted files during the first 30 days after the attack (there will be no warning of mass-deletion of mass-encryption of files coming from the Dropbox app). If you want to roll back the entire Documents folder with Dropbox Rewind, you’ll need to be a paid Plus or Professional tier subscriber.

More information:

Make backup snapshots. Keep backup media offline

Once ransomware is installed on your computer, it will try to encrypt every document that is accessible. The obvious solution is making documents inaccessible by physically disconnecting backup media (such as using 2.5” portable USB drives to back up). In this scenario, you would only connect backup media to your computer when you actually want to make the backup, disconnecting the disk after the backup tool finishes its job. With this approach, even if your computer is attacked by ransomware, your offline backups will not be affected (unless you connected the external drive to the computer at the time the ransomware was installed).

In addition, configure your backup tool to keep snapshots of your data going back as long as permitted by available storage. In our office, an affordable 4TB USB hard drive can keep approximately 30 to 40 full snapshots of the Documents folder; this number becomes significantly larger if you enable incremental backups, with each snapshot saving only

More information:


Thecus has been manufacturing NAS devices for more than 15 years. The company develops an in-house Linux-based NAS OS, the ThecusOS. At this time, the most current version of the OS is ThecusOS 7. Thecus advertises secure data encryption in most of its NAS devices. The company’s volume-based encryption tool allows users to fully encrypt their entire RAID volume, defending essential data in instances of theft of the physical device. We found Thecus’ implementation of encryption somewhat unique. In this research, we’ll verify the manufacturer’s claims and check just how secure is Thecus’ implementation of 256-bit AES encryption.

Abstract and Summary

Thecus uses volume-based 256-bit AES encryption with a single, fixed, unchangeable encryption key. The 3968-byte (31744-bit) encryption key file is generated at the time the user creates a new encrypted volume based on the user’s password (4-16 characters, 0-9, a-z, A-Z only). Creating several encrypted volumes with the same password produces different encryption key files.

The encryption key is stored on an external USB drive (the only, forced option) and does not have any additional protection.

The encrypted volume is automatically unlocked once the user inserts the USB drive that contains the correct encryption key.

The original password the user typed when creating an encrypted volume is never used again, anywhere. Users cannot change the encryption password. Users cannot encrypt existing data. Users cannot permanently decrypt encrypted volumes. Any changes to encryption require deleting and re-creating the volume and filling it up with data. The entire encryption scheme lacks any sort of technical documentation.

The entire protection scheme is completely undocumented. For example, it is not clear what the password is used for since the user never has to type it again (ever) to mount or otherwise access encrypted volumes.

Note: SED is supported by ThecusOS but was not tested in our lab.

Test Bench

We analyzed a Thecus N2810 device based on an Intel Celeron Processor N2810. A non-SED WD Red HDD was used to set up the NAS perform the analysis. The NAS was running on the latest available version of ThecusOS 7.

Volume-Based Encryption

ThecusOS supports volume-based encryption. Unlike folder-based encryption that allows protecting (or not protecting) individual shares, volume-based encryption protects the entire RAID volume. The closest analogy to volume-based encryption would be BitLocker in Microsoft Windows or FileVault 2 in Apple macOS. However, the Thecus implementation is significantly more basic compared to Apple’s or Microsoft’s full-disk encryption tools.


Users can only encrypt newly created, empty RAID volumes (regardless of the number of disks; a single-disk RAID volume can be encrypted just as easily as a volume spanning across multiple physical disks).

Encrypting an existing volume is not possible. One must first remove the volume, create a new one and tick the “Encrypt” box. As a result, encrypting volumes with existing data is not supported.

The first step is creating a new volume:

The optional encryption feature requires a password. The password must be 4 to 16 characters long; character groups 0-9, a-z, A-Z are supported (no special characters and no local characters).

Users don’t have to memorize that password as they’ll never have to type it again to access the encrypted data. Instead, ThecusOS will generate a 3968-byte (31744-bit) encryption key, and store that key on an external USB drive that must be connected to the NAS at the time the encrypted volume is created.

Once the user inserts an external USB drive (e.g. a flash drive) into one of the available USB ports, the NAS saves the encryption key on that drive and creates and mounts the encrypted volume.

Mounting encrypted volumes

The encrypted volumes are mounted automatically when the user inserts a USB drive that contains the volume encryption key into any available USB port on the Thecus NAS. There are no additional prompts, and there is no need to open the Web UI.

The following scenarios are supported.

  1. The NAS is powered on or rebooted; no USB drive containing the encryption key is inserted. In this case, the encrypted volume is locked, and the data is not accessible.
    However, the NAS can still complete the boot sequence as the main OS (and some configuration files) are stored on a small NAND storage chip and not on the hard drive(s).
  2. The NAS is powered on or rebooted; the USB drive containing the encryption key is inserted. In this case, the encrypted volume will be mounted by the time the device completes the boot sequence.
  3. The most interesting scenario is when the NAS is powered on or rebooted without a USB drive inserted, and the user inserts the USB drive containing the encryption key at a later point. In this case, the OS will automatically recognize the USB drive, read the encryption key and automatically mount the encrypted volume.

Locking encrypted volumes

As we figured, encrypted volumes are mounted automatically when the user inserts the correct USB drive. What happens after the USB drive is removed? In this case, the NAS keeps the encrypted volume mounted. The volume remains mounted until the NAS is powered off or rebooted, or until the user manually locks the volume through the Web UI.


If you are used to BitLocker, you probably know it is easily possible to remove the password from an encrypted volume. Interestingly, BitLocker will not decrypt any data that has already been encrypted; instead, it’ll just store the unwrapped encryption key in the volume header, allowing the system to pick up the key and access information without a password. Any new information saved on such BitLocker volumes would be saved unencrypted.

With Thecus, the situation is much simpler. Users cannot remove encryption or permanently decrypt encrypted volumes, period. The only way to permanently decrypt the data is removing the encrypted volume, re-creating the volume without encryption and filling it up with data.

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary keys that are used to actually encrypt and decrypt the data, and user-provided secrets that are used to access the data. In symmetric cryptography, only one unique binary encryption key may be used to encrypt and decrypt the data; this is called the Media Encryption Key (or Data Encryption Key). However, users can unlock encrypted data by using multiple different types of credentials such as plain-text passwords, credentials stored on secure smart cards or TPM modules, binary keys (files) or combinations of thereof. These credentials (Key Encryption Keys) are used to encrypt (wrap) the Media Encryption Key. Multiple different Key Encryption Keys may be used to wrap the same Media Encryption Key, allowing the user to instantly change their plain-text password, add or remove smart cards and other credentials.

ThecusOS 7 does not use the concept of Key Encryption Keys. The user’s original plain-text password is used to produce a single, fixed Media Encryption Key. Neither the password nor the encryption key can be changed after the volume is encrypted.


While users are required to enter a password when encrypting the volume, this password will never be used again anywhere in the ThecusOS interface. I was unable to find any references to this password in the Thecus technical documentation or the online knowledge base. The password is not used to decrypt data or to mount encrypted partitions. Users will never have to type that password again. In other words, the password seems completely redundant in this setup. The lack of a proper explanation, let alone comprehensive technical documentation, makes me shake my head.

ThecusOS produces different encryption keys when creating volumes protected with the same password. This is a good hint that the password is salted with some random data. The lack of proper documentation makes this guess as good as any others.

Thecus and SED Encryption

ThecusOS supports SED (Self-Encrypting Drive) encryption, as seen on the screen shot below.

We have not tested the SED implementation due to the lack of a compatible hard drive. Considering the cost and market positioning of the Thecus N2810, the model is likely to be used with consumer-grade NAS hard drives such as the Western Digital Red or Seagate Ironwolf series, both of which lack the SED support.

What Risks Are Covered by Thecus Security Model

The security model employed by the ThecusOS is stripped down to the bare essentials. I have the following remarks about the Thecus security model.

  1. It is not clear why the system prompts for a password if that password cannot be used to unlock volumes and cannot be changed. If the user’s password is only needed as a random seed of a sort, this must be properly disclosed and documented.
  2. The lack of any sort of technical documentation for the data protection scheme is discouraging. This might be passable for the home user and occasional small office use, but unacceptable for anything beyond that.
  3. The encryption key is stored on a separate USB drive. Users can conveniently insert that USB drive at any time to automatically unlock encrypted volumes. As a result, the entire protection scheme is based exclusively on “something you have”. Anyone who has access to the USB drive holding the encryption key will be able to mount encrypted volumes.

As one can see, it all comes down to whether or not the attacker has access to the USB drive containing the encryption keys.

If the USB encryption key is stored separately of the NAS unit, and the NAS is powered off, the encrypted data is protected against the theft of the hard drives and the theft of the whole NAS unit.

If the attacker has access to both the NAS unit and the USB drive containing the encryption key, the protection is nil.

Conclusion: Thecus Encryption vs. Microsoft BitLocker

When it comes to full-disk encryption, Microsoft BitLocker and Apple FileVault 2 are the first things that come to mind, with TrueCrypt and VeraCrypt being the most popular third-party implementations. Secure encryption, comprehensive key management and multiple methods for encrypting and unlocking volumes are supported by all of these crypto-containers.

When it comes to attached storage encryption, you are welcome back to the Stone Age. A typical NAS advertising 256-bit AES encryption lacks any kind of key management; often to the point the user cannot even change their encryption password without deleting the entire volume, re-creating, re-encrypting and re-filling with data. Many NAS manufacturers have no idea about the existence of separate Media Encryption Keys and Key Encryption Keys, let alone their multiple instances. A typical NAS sold to a home or small office user does not allow encrypting existing data or removing the password from encrypted volumes should you no longer need to protect them.

All of these statements are true for the ThecusOS 7. The lack of even the basic key management, the inability to change the encryption password, and the inability to encrypt or decrypt existing volumes makes Thecus NAS encryption one of the least flexible ever. The protection system lack transparency or any sort of technical documentation. How does the system come up with a 3968-byte encryption key based on the user’s 4 to 16-character password? In a case of data loss, is it possible to decrypt the data with the user’s password instead of the encryption key? Does the key contain the user’s password, the hash of a password, or is it mostly random data? None of these questions have answers in the technical documentation.

At the same time, the encryption implementation is simple and straightforward. Based on a file stored on a removable USB drive, the data would be impossible to decrypt without said USB drive (unless a vulnerability is found). This encryption would likely be sufficient to protect most data stored by home and small office users.

For us, this year has been extremely replete with all sorts of developments in desktop, mobile and cloud forensics. We are proud with our achievements and want to share with you. Let’s have a quick look at what we’ve achieved in the year 2019.

Mobile Forensics: iOS File System Imaging

We started this year by updating Elcomsoft iOS Forensic Toolkit, and by a twist of a fate it became our most developed tool in 2019. The developments went through a number of iterations. The release of unc0ver and Electra jailbreaks enabled Elcomsoft iOS Forensic Toolkit to support physical acquisition for iOS 11.4 and 11.4.1 devices, allowing it to produce file system extraction via jailbreak.

In the meanwhile, we updated Elcomsoft Phone Viewer with support for file system images produced by GrayKey, a popular forensic solution for iOS physical extraction. Analysing GrayKey output with Elcomsoft Phone Viewer became faster and more convenient.

Later in February, Elcomsoft iOS Forensic Toolkit received a major update, adding support for physical acquisition of Apple devices running iOS 12. The tool became capable of extracting the content of the file system and decrypting passwords and authentication credentials stored in the iOS keychain. For the first time, iOS Forensic Toolkit made use of a rootless jailbreak with significantly smaller footprint compared to traditional jailbreaks.

Not long ago, Elcomsoft iOS Forensic Toolkit 5.20 was updated with file system extraction support for select Apple devices running all versions of iOS from iOS 12 to iOS 13.3. Making use of the new future-proof bootrom exploit built into the checkra1n jailbreak, EIFT is able to extract the full file system image, decrypt passwords and authentication credentials stored in the iOS keychain. And finally, the sensational version 5.21 raised a storm of headlines talking about iOS Forensic Toolkit as the ‘New Apple iOS 13.3 Security Threat’. Why? We made the tool support the extraction of iOS keychain from locked and disabled devices in the BPU-mode (Before-first-unlock). The extraction is available on Apple devices built with A7 through A11 generation SoC via the checkra1n jailbreak.

Mobile Forensics: Logical Acquisition

Later on, Elcomsoft Phone Viewer was further updated to recover and display Restrictions and Screen Time passwords when analysing iOS local backups. In addition, version 4.60 became capable of decrypting and displaying conversation histories in Signal, one of the world’s most secure messaging apps. Experts became able to decrypt and analyse Signal communication histories when analysing the results of iOS file system acquisition.

Desktop Forensics and Trainings

In 2019 we’ve also updated Advanced PDF Password Recovery with a new Device Manager, and added support for NVIDIA CUDA 10 and OpenCL graphic cards to Advanced Office Password Recovery. Advanced Intuit Password Recovery added support for Quicken and QuickBooks 2018-2019 covering the changes in data formats and encryption of newest Intuit applications. In addition, the tool enabled GPU acceleration on the latest generation of NVIDIA boards via CUDA 10.

We are proud to say that the many changes we implemented in Elcomsoft Distributed Password Recovery are based on the users’ feedback we received by email and in person, during and after the training sessions. We had several trainings this year in the UK, Northern Ireland and Canada. “Fantastic. Time well spent on the training and on software that will be very useful on cases in the future”, commented Computer Forensic Examiner.

Cloud Forensics

We learned how to extract and decrypt Apple Health data from the cloud – something that Apple won’t provide to the law enforcement when serving legal requests. Health data can serve as essential evidence during investigations. The updated Elcomsoft Phone Viewer can show Apple Health data extracted with Elcomsoft Phone Breaker or available in iOS local backups and file system images.

Very soon Elcomsoft Phone Breaker 9.20 expanded the list of supported data categories, adding iOS Screen Time and Voice Memos. Screen Time passwords and some additional information can be extracted from iCloud along with other synchronized data, while Voice Memos can be extracted from local and cloud backups and iCloud synchronized data.

Skype anyone? In December, Elcomsoft Phone Viewer and Elcomsoft Phone Breaker were updated to extract and display Skype conversation histories.

Desktop Forensics: Disk Encryption

Elcomsoft System Recovery received a major update with enhanced full-disk encryption support. The update made it easy to process full-disk encryption by simply booting from a flash drive. The tool automatically detects full-disk encryption, extracting and saving information required to brute-force passwords to encrypted volumes. In addition, the tool became capable of saving the system’s hibernation file to the flash drive for subsequent extraction of decryption keys for accessing encrypted volumes.

Cloud Forensics: iOS 13 & Authentication Tokens

Elcomsoft Phone Breaker 9.15 added the ability to download iCloud backups created with iPhone and iPad devices running iOS 13 and iPadOS. In addition, the tool became able to extract fully-featured iCloud authentication tokens from macOS computers.

Following this, Elcomsoft Phone Breaker 9.30 delivered a new iCloud downloading engine and low-level access to iCloud Drive data. Thanks to the new iCloud engine, the tool became capable of downloading backups produced by devices running all versions of iOS up to iOS 13.2. While advanced iCloud Drive structure analysis allows users to enable deep, low-level analysis of iCloud Drive secure containers.

Cloud Forensics: Google

Elcomsoft Cloud Explorer 2.20 boosted the number of data types available for acquisition, allowing experts to additionally download a bunch of new types of data. This includes data sources in the Visited tree, Web pages opened on Android devices, requests to Google Assistant in Voice search, Google Lens in Search history, Google Play Books and Google Play Movies & TV.

Challenges in Computer and Mobile Forensics: What to Expect in 2020

The past two years introduced a number of challenges forensic experts have never faced before. In 2018, Apple made it more difficult for the police to safely transport a seized iPhone to the lab by locking the USB port with USB restricted mode, making data preservation a challenge. The release of the A12 platform, also in 2018, made it difficult to unlock iOS devices protected with an unknown password, while this year’s release of iOS 13 rendered unlock boxes useless on iPhones based on the two most recent platforms.

On desktop and especially laptop computers, the widespread use of SSD drives made it impossible to access deleted data due to trim and garbage collection mechanisms. The users’ vastly increased reliance on cloud services and mass migration off the forensically transparent SMS platform towards the use of end-to-end encrypted messaging apps made communications more difficult to intercept and analyze.

Sheer amounts of data are greater than ever, making users rely more on external (attached) storage compared to using internal hard drives. Many attached storage devices are using secure encryption, some of them without even prompting the user. Extracting data from such devices becomes a challenge, while analyzing the huge amounts of information now requires significantly more time and effort.

The number of online accounts used by an average consumer grows steadily year over year. While password reuse and the use of cloud services to store and synchronize passwords makes experts’ jobs easier, the spread of secure, encrypted password management services is turning into a new challenge.

Knowing everyday challenges in desktop and mobile forensics, we can now peek into the future. (more…)

Home users and small offices are served by two major manufacturers of network attached storage devices (NAS): QNAP and Synology, with Western Digital being a distant third. All Qnap and Synology network attached storage models are advertised with support for hardware-accelerated AES encryption. Encrypted NAS devices can be a real roadblock on the way of forensic investigations. In this article, we’ll review the common encryption scenarios used in home and small office models of network attached storage devices made by Synology. (more…)

What can and what cannot be done with an iOS device using Touch ID/Face ID authentication as opposed to knowing the passcode? The differences are huge. For the sake of simplicity, we’ll only cover iOS 12 and 13. If you just want a quick summary, scroll down to the end of the article for a table.


Let’s get it out of the way: everything that’s listed below applies exclusively to AFU (After First Unlock) devices. You cannot use biometrics to unlock an iOS device that’s been restarted or powered on; such devices are in the state known as BFU (Before First Unlock).

BFU, Before First Unlock: The iOS device was restarted or powered off; you powered it on but cannot unlock it because it’s protected with an unknown passcode.

AFU, After First Unlock: The iOS device was unlocked (with a passcode) at least once after it’s been last rebooted or powered on.

Screen Lock: Unlocking the Device

Touch ID or Face ID can be only used to unlock AFU devices. In order to unlock a BFU device, you’ll have to use the passcode. Even if you manage to bypass the lock screen (via an exploit), you won’t be able to access most device data as it will be encrypted. The decryption key is generated when the user first unlocks the device; the key is based on the passcode.