Client-side Login Procedures

With protocol analysis, we figure out what data is exchanged between the client and the server for Windows Hello login.
Now we’d like to know where is authentication data stored in the client-side? And how authentication data is used to?
For these, we performed static and dynamic debugging for login-related services on the client-side. Specifically, we focused on the private key, AccountToken, and DeviceToken.

Considerations and Assumptions

Windows Hello related services have a very complicated structure. Microsoft uses next-generation cryptography modules called NGC, which are involved in the encryption. Windows Hello-related services protect and store user’s information and encryption keys using the NGC modules. The modules provide key isolation services so that normal applications do not access sensitive information directly.  The windows login service and the Windows Hello service access keys to perform encryption-related operations through the key isolation services. We tried to figure out how sensitive information is managed and used.

We have some assumptions for the analysis environment. First, the device doesn’t have TPM.  Second, we focus on the case of using a PIN. Even if the user registers a biometric, a PIN must be registered for backup. In other words, no matter what type of login option for Windows Hello is used, the PIN must be registered. Finally, Windows Hello for business is excluded from our work.

Main Target: Private Key

To understand the login process, we targeted the private key, which is a core element of the login process. An analysis of the private key is required because the authentication data stored on the device are verified with the private key during logging in. We divided the analysis of the private key into two parts: 1) the location and the structure of the private key file and 2) protected data that encrypted or decrypted with the private key.

Storage and Components

First, the storage of private key files. The private key is managed by the Microsoft Software Key storage provider. The private key is located in a file in the keys folder and There exist four private keys: %SystemRoot%\ServiceProfiles\LocalService\AppData\Roaming\Microsoft\Crypto\Keys.

The private key files consist of 1) an identifier, 2) a public key,
3) private key properties that are salt and iteration count for encrypting or decrypting the private keys, and 4) a private key that is encrypted with a key derived from a PIN or a seed.
The private keys are encrypted using the AES256 algorithm.

How can derive the key for encrypting the private keys? All four private keys are encrypted with the same algorithm. The keys for encrypting private keys are generated in the following ways.

DK = BcryptDeriveKeyPBKDF2(Encode(PIN/seed), Salt, Iteration)
KEK = SHA-512(Encode(DK))

 First, once a PIN or a seed is encoded and a DK is generated as a function PBKDF2(). The client obtains a key-encryption key by encoding the DK and hashing it with the SHA512 algorithm. With this key-encryption key, the client encrypts or decrypts the private keys.

Usages

Here is how to private keys are used for in two types of Windows Hello login; PC login and service login. We will describe what role each of the four individual keys plays in the login procedures of Windows Hello.

Step ➀, ➁

First, a user enters a PIN and a device decrypts stored private keys. We mentioned that there are four individual keys in the Software Key Storage. The PIN that the user enters for the log in is used as the key to decrypt the first one of four private keys [(1) in the above figure]. The first private key decrypts seeds that encrypted and stored in filesystem managed by the software key storage provider [(2) in the above figure]. Decrypted seeds are finally used as a key to the rest three private keys [(3) in the above figure]. In other words, the user’s PIN is used to decrypt all user’s private keys.

Step ➂-➊, ➃-➊

The next step is how the private keys that decrypted with the PIN are used in the PC login process when using the local account. If the user is not using the Microsoft account, the client decrypts an encrypted PwKey using the second private key [(1) in the above figure]. The PwKey is a key that is used to encrypt a local password. The Encrypted PwKey and the encrypted local password is stored in the local registry, EncryptedPassword. According to the user’s request, the PwKey decrypts the local password [(2) in the above figure]. Consequently, the local password is decrypted with the PIN and used to the NTLM authentication process for PC login.

Step ➂-➋, ➃-➋

Next is about the PC login using the Microsoft account. If the user is using the Microsoft account, the client accesses a CacheData file stored in the Microsoft account folder. In the CacheData file consists of authentication data for PC login. The authentication data is encrypted with an AES algorithm key derived from the third private key. When the user requests the PC login, the authentication data in the CacheData file is decrypted and used the MSDCC2 authentication process for PC login.

Step ➂-➌, ➃-➌

When the user login to any service with Windows Hello as described in the protocol analysis section, the client communicates with the server as mentioned in Analysis of Network Protocol 4) log in to Services with Gesture Section. In this communication, the core packet is the third one; ➂ Authentication Request. Because the ID server authenticates the client through the data transmitted in the third packet.

When logging in to the service, the client signs in the challenge received from the ID server with the fourth private key. The fourth public key is registered to the ID server during the PIN setup phase. The client extracts AccountToken and DeviceToken from the credential storage and sends them to the ID server. The ID server validates these three authentication data. The client receives AccessToken from the server and succeeds in logging in to the service.

The credential is a repository to save authentication data for logging in to websites, applications, and networks. In credential, the user information and tokens are stored as encrypted. And extract by decrypting if necessary. The credential storage is combined with the credential manager and you can find the credential following  path:
%LOCALAPPDATA%\Microsoft\Credentials.

When you decrypt the credential, you can see some information about the account or the device and its token. AccountToken and DeviceToken have an XML encryption format. In the protocol analysis section, I mentioned that the tokens received from the ID server are protected with XML encryption. Once you release the XML encryption of the packet, You can see the tokens inside XML encryption have the form of XML encryption. The client does not decrypt the tokens and keep them encrypted themselves. And the client uses it as tokens when needed.

Windows Hello Migration Attack

Based on the analysis of the protocol and the login procedure, we propose a NEW Windows Hello migration attack.

Attack Overview

The basic concept of Windows Hello is that even if the user’s PIN is leaked, it’s safe if the user doesn’t be stolen the device. This is because of the device stores authentication data for the user. We targeted destroying this basic concept of Windows Hello. To do this, we would like to identify elements that are stored on the user’s device for Windows Hello login, and exploit Microsoft services with an account registered to the victim’s PC on the attacker’s PC.

Effects and Advantages

The implications of a Windows Hello Migration are as follows.
A typical session hijacking attack is performed by obtaining session data, such as cookies or tokens, and deceiving the server through those data. This attack limits affected scope to some services that use the hijacked session data, and the disadvantage is that the attack will not be maintained after the session expires.

On the other hand, the Windows Hello migration attack uses an approach that transfers victim’s authentication data to the Microsoft server and impersonates as the victim. It has an attack effect similar to stealing a Microsoft account. This attack can lead to hijacking all services accessible through Windows Hello. Typical Microsoft services associated with Windows Hello are shown in the figure on the right. Several apps deal with sensitive information that could be a problem in leakages, such as Store, OneDrive, Office, Skype, and Outlook. As services combined in Windows Hello are expected to continually be added in the future, the ripple effects of the attack are expected to increase as well.

This attack can be more effective in the following situations.

Scenario #1: The victim knows the leakage about authentication data for Windows Hello login. And the victim changes or removes the PIN from the victim’s PC. However, the attacker can still available the services with the victim’s account. This is possible because the client does not communicate with the Microsoft server when removing or changing the PIN.

Scenario #2: The password for the Microsoft account cannot be found in the victim’s PC. However, the attacker can access the PIN and authentication data that are used instead of a password in Windows Hello.

Scenario #3: The proposed attack is useful when the victim uses the Microsoft Authenticator application provided for multi-factor authentication. If the victim attempts to log in to a new device while using the Authenticator app, an alert will appear on the preregistered mobile device. The victim must approve the notification before they can use the service normally. Therefore, The attacker cannot log in with the victim’s account, even if the attacker tries to log in from a new device by obtaining the MS account password through a different path. This is because the attacker must approve the victim’s mobile device.
On the other hand, in the proposed attack the migrated information contains already approved data by the Authenticator app. Therefore, even if the attacker migrates the victim’s credentials into a new device and uses Windows Hello, it does not notify the victim’s mobile device. The attacker can successfully take a victim’s account.

Attack Details

This attack works in the following conditions. Administrator privilege is required to access authentication data for Windows Hello. By malware installed on a victim machine, unethical administrator in clouds, Or own the devices for forensic investigation. There are various ways to obtain the administrator privilege. This is out of our work. And we have not studied TPM-supported Windows Hello yet. That is one of our future work.

Attack Steps

The attack can be performed as follows. A malware that the attacker infiltrates into the victim’s PC gets administrator privilege. the malware extracts authentication data for Windows Hello stored in the victim’s PC. The attacker receives data through the network and migrates the victim’s authentication data into the attacker’s PC. After the migration, the attacker can access Microsoft services, such as store, one-drive, and outlook with the victim’s account.

How Migration Tool Works

We developed migration tools for Windows Hello login.

First, the attacker’s malware that infiltrates into the victim’s PC performs a PIN crack that identifies the PIN used for Windows Hello. Malware can access all private key files for Windows Hello. For finding the PIN, we developed the PIN cracker that tries to decrypt the first private key with brute-forcing. This tool works on offline, so it can bypass restriction policy about input count. Our PIN cracker takes six and a half hours to try every combination for 6-digit PIN on a single-core processor. The speed can be quicker on a multi-core processor or GPU. Another way to find the PIN is just hooking the memory when the user enters the PIN for Windows Hello login.

The next step is extracting and calibrating authentication data. Private key files, private key identifiers, seed, CacheData, EncryptedPassword, and credentials are extracted from the filesystem and registry on the victim’s PC. These extractions are based on the PIN we found in the previous step. And calibrate authentication data to use on the attacker’s PC. These are also based on the PIN and the first private key.

Finally, the attacker attempts to log in to the service with a victim’s account. We first tested the Microsoft store to prove the feasibility of this attack. You can see that the attacker’s PC is logged in with the victim’s account

DEMO

You can access the demo video here.

Conclusion

In this post, We examine Windows Hello internals by analyzing network protocol and client-side login procedure. and we propose a new attack, the Windows Hello migration attack. This attack exploits Microsoft services to the victim’s account on the attacker’s PC. Through the migration attack, the attacker can access all combined services in Windows Hello. And the attacker can leak personal data or confidential information. We need to reconsider the security of Windows Hello.

Future works

In the future works, we will expand our research

• Windows Hello with Biometrics
• Windows Hello with Trusted Platform Module(TPM)
• Windows Hello for business

Please contact author if you have any questions.
dlwjdgh100@o365.skku.edu