In traditional forensic workflows, gaining access to a Windows system was a straightforward exercise: extract the NT hashes from a local database and run a fast (very fast!) offline attack. Today, Windows authentication is moving away from those essentially insecure NTLM hashes toward more resilient mechanisms. Microsoft is actively steering users away from local Windows accounts, pushing them toward cloud-integrated identities (such as the Microsoft Account) and hardware-backed security models (like Windows Hello).

In this article, we will examine the four primary sign-on options used in modern versions of Windows: legacy local Windows accounts, consumer Microsoft Accounts, traditional Active Directory environments, and Entra ID cloud configurations. We will detail what credential extraction actually entails in each specific scenario with Elcomsoft System Recovery. Because the definition of a recoverable credential now varies depending on the account type, we will discuss exactly which data can be targeted, what can be recovered with an offline attack, and where traditional password recovery is no longer applicable.

Local Windows Accounts (NTLM)

Local Windows accounts represent the legacy standard for system authentication. While Microsoft actively buries this option during the Windows 11 setup process to push users toward cloud-connected profiles, these accounts remain common in the field. Examiners frequently encounter them on older systems, offline workstations, or machines where users deliberately bypassed Microsoft’s default setup prompts.

Under the hood, the architecture for these accounts is entirely self-contained. User credentials are natively stored on the local disk rather than synchronizing with an external server. The operating system calculates and saves these passwords as NTLM hashes directly within the Security Account Manager (SAM) registry hive.

For the forensic examiner, this remains the most straightforward password recovery scenario. The process simply requires acquiring the SAM and SYSTEM registry hives from the target drive offline. Once the NTLM hashes are extracted from the registry, they can be rapidly broken using high-speed dictionary or brute-force attacks on standard GPU hardware.

Microsoft Accounts (MSA), Passwordless Sign-In and Windows Hello Ambiguity

The Microsoft Account (MSA) is the current consumer default, bridging local device access with Microsoft’s broader cloud ecosystem. A compromised account yields a high reward: access to local files, synchronized OneDrive data, and potentially BitLocker recovery keys. Under the hood, authentication branches into two distinct paths: traditional passwords and modern passwordless sign-ins.

It is a common misconception that Windows simply caches a traditional NTLM hash of the online password for offline logins. In reality, the password hash is not stored on the PC. Instead, the system forms a “protector.” These protector details are stored locally and are encrypted with the user’s Microsoft Account password and/or with hardware-backed credentials depending on how exactly the account is configured. The encryption is significantly stronger and slower to break than the old NTLM. For an examiner, credential extraction means targeting this locally stored protector, not a raw hash.

Conversely, Microsoft is aggressively pushing toward passwordless logins via Windows Hello. This method relies on a PIN or biometrics (such as an IR camera or fingerprint reader). In this scenario, the local protector is encrypted by a hardware-backed mechanism tied to the system’s Trusted Platform Module (TPM), effectively blocking offline brute-forcing.

This introduces a hardware-level ambiguity, specifically in older Windows installations. In Windows 10, if a system has a disabled or unsupported TPM, the Windows Hello PIN might fall back to a locally cached software state. It is not visually obvious from the login screen whether a device relies on hardware protection or has fallen back to a vulnerable software cache. We must admit this ambiguity clearly: you cannot tell from the Windows version or the hardware config alone. The forensic examiner is responsible for handling this by parsing the local credential database to determine exactly how the protector is encrypted. If the protector is encrypted by the MS Account password or a software-cached PIN, an offline attack may proceed. If the protector is confirmed to be strictly hardware-backed, offline recovery is a dead end.

How Elcomsoft System Recovery Can Help

This is exactly where Elcomsoft System Recovery (ESR) comes into service. When an examiner boots the target machine using ESR, the software handles the ambiguity by automatically parsing the system’s database to identify the exact type of protector in use.

If ESR identifies that the protector is encrypted with an MS Account password, it can launch an immediate offline attack. However, examiners must be aware of current technical constraints regarding this specific attack vector. Because of the specific encryption used by the protector, the attack relies entirely on the CPU. There is currently no GPU acceleration available for this process. As a result, examiners are strongly advised to use targeted dictionary attacks rather than attempting a full brute-force recovery.

Currently no other Elcomsoft tool supports the recovery of these passwords. Elcomsoft Distributed Password Recovery (EDPR) is not compatible with this specific protector format in its current version (compatibility is planned for a future update). For the time being, this attack can only be executed using the latest release of ESR and the upcoming release of Elcomsoft Quick Triage (EQT).

Active Directory Accounts

Traditional Active Directory environments represent the classic corporate network setup. In this architecture, the master authentication database (NTDS.dit) resides centrally on the Domain Controller. However, for the sake of mobility, Windows workstations cache domain credentials locally so users can still log in when disconnected from the corporate LAN. For an examiner analyzing an isolated machine, the central server is out of reach, making this localized cache the primary target.

At the workstation level, forensic extraction focuses on pulling Local Security Authority (LSA) secrets and DPAPI data from the system. If successfully extracted, the examiner can run a fast offline attack against these cached domain credentials.

Entra ID (Corporate Cloud) Accounts

Entra ID (formerly Azure AD) is the modern corporate standard, engineered specifically for zero-trust environments and remote workforces. Authentication in this architecture is fundamentally cloud-based, heavily utilizing Windows Hello for Business, Conditional Access policies, and Primary Refresh Tokens (PRTs) to validate users and manage sessions.

In these setups, traditional local password hashes are nonexistent. This raises a clear ambiguity regarding our terminology: does gaining access to an Entra ID environment actually count as “password recovery”? Technically, it does not. We must be upfront with the reality of modern corporate forensics: literal “password recovery” is effectively dead in a properly configured Entra ID environment. Instead, the forensic examiner is responsible for handling access by extracting a block of protected data and running an offline attack against it, as detailed below.

How Elcomsoft System Recovery (ESR) Can Help

While an Entra ID deployment does not store a traditional password hash on the local PC, it does store a localized block of data secured with strong encryption (distinct from legacy NTLM). Access to this encrypted block is managed by a protector. In a standard corporate rollout, this protector is usually a hardware-backed PIN or a FIDO security key. However, if the system configuration utilizes a password as the protector, localized recovery is still an option.

Elcomsoft System Recovery (ESR) can be deployed to attack this specific localized data block, but examiners must note several technical constraints. First and most importantly, we can only recover the authentication data if it is guarded by a password protector. If the data block is secured by a hardware-backed PIN or FIDO key and lacks password-based access (which is Microsoft’s recommended practice), offline recovery is not possible. Second, similar to Microsoft Accounts, Entra ID uses strong encryption to protect that data block, which means the attack will be slow compared to NTLM. The currently implemented method relies entirely on the CPU, and there is no GPU acceleration available yet. Therefore, running a targeted dictionary attack is highly recommended over attempting a full brute-force recovery.

Finally, while offloading the attack onto a more powerful tool such as Elcomsoft Distributed Password Recovery sounds tempting, that tool does not currently support this specific encryption format (an update is planned). As of now, this encrypted block can only be attacked using the current release of ESR and the upcoming release of Elcomsoft Quick Triage (EQT).