在传统的取证工作流程中，获取 Windows 系统的访问权限曾是一件比较直接的事情：从本地数据库中提取 NT 哈希，然后运行一次快速的离线攻击。如今，Windows 身份验证正从那些本质上不安全的 NTLM 哈希向更具弹性的机制迁移。微软正积极引导用户远离本地 Windows 账户，转而使用云端集成身份（如微软账户）和基于硬件的安全模型（如 Windows Hello）。
在本文中，我们将研究现代 Windows 版本中使用的四种主要登录选项：传统的本地 Windows 账户、消费级微软账户、传统的 Active Directory 环境以及 Entra ID 云配置。本文将详细阐述在使用 Elcomsoft System Recovery时，每种具体场景下的凭据提取究竟意味着什么。由于"可恢复凭据"的定义现在因账户类型而异，我们将讨论究竟可以针对哪些数据、通过离线攻击可以恢复什么，以及传统的密码恢复在哪些情况下不再适用。
本地 Windows 账户 (NTLM)
本地 Windows 账户代表了系统身份验证的传统标准。尽管微软在 Windows 11 设置过程中故意隐藏此选项，以促使用户转向云端连接配置文件，但这些账户在现场仍然很常见。调查人员经常在较旧的系统、离线工作站或用户有意绕过微软默认设置提示的机器上遇到它们。
在底层，这些账户的架构是完全自包含的。用户凭据本地存储在本地磁盘上，而不是与外部服务器同步。操作系统直接将这些密码计算并保存为 Security Account Manager (SAM) 注册表配置单元中的 NTLM 哈希。
对于取证调查人员来说，这仍然是最直接的密码恢复场景。该过程只需从目标离线驱动器中获取 SAM 和 SYSTEM 注册表配置单元即可。一旦从注册表中提取出 NTLM 哈希，就可以在标准 GPU 硬件上使用高速字典或暴力攻击快速破解。
微软账户 (MSA)、无密码登录与 Windows Hello 的二义性
微软账户 (MSA) 是当前消费级系统的默认选项，它连接了本地设备访问与微软更广泛的云生态系统。一个被攻破的账户会带来高回报：可以访问本地文件、同步的 OneDrive 数据，以及可能的 BitLocker 恢复密钥。在底层，身份验证分为两条不同的路径：传统密码和现代无密码登录。
一个常见的误解是，Windows 只是简单地为离线登录缓存了在线密码的传统 NTLM 哈希。实际上，密码哈希并不存储在电脑上。相反，系统会形成一个"保护器"。这些保护器的详细信息存储在本地，并根据账户的具体配置方式，使用用户的微软账户密码和/或基于硬件的凭据进行加密。这种加密比旧的 NTLM 强大得多，破解速度也慢得多。对于调查人员来说，凭据提取意味着要针对这个本地存储的保护器，而不是原始哈希。
相反，微软正在通过 Windows Hello 积极推动无密码登录。此方法依赖于 PIN 码或生物识别技术（如红外摄像头或指纹读取器）。在这种情况下，本地保护器由与系统可信平台模块 (TPM) 绑定的硬件支持机制加密，从而有效阻止离线暴力破解。
这引入了一个硬件层面的二义性，尤其是在较旧的 Windows 安装中。在 Windows 10 中，如果系统禁用或不支持 TPM，Windows Hello PIN 可能会回退到本地缓存的软件状态。从登录屏幕上无法直观地看出设备是依赖硬件保护，还是已回退到易受攻击的软件缓存。我们必须明确承认这种二义性：你无法仅从 Windows 版本或硬件配置来判断。取证调查人员有责任通过解析本地凭据数据库来确定保护器的确切加密方式来处理这种情况。如果保护器由微软账户密码或软件缓存的 PIN 加密，则可以进行离线攻击。如果保护器被确认为严格受硬件支持，则离线恢复是死路一条。
Elcomsoft System Recovery 可以提供什么帮助
这正是 **Elcomsoft System Recovery (ESR)**发挥作用的地方。当调查人员使用 ESR 启动目标机器时，该软件通过自动解析系统数据库以识别正在使用的保护器确切类型来处理这种二义性。
如果 ESR 识别出保护器是用微软账户密码加密的，它可以发起立即的离线攻击。但是，调查人员必须了解当前针对此特定攻击向量的技术限制。由于保护器使用了特定的加密方式，攻击完全依赖于 CPU。目前还没有可用的 GPU 加速。因此，强烈建议调查人员使用有针对性的字典攻击，而不是尝试完整的暴力恢复。
目前，没有其他 Elcomsoft 工具支持恢复这些密码。Elcomsoft Distributed Password Recovery (EDPR) 当前版本不兼容这种特定的保护器格式（计划在未来更新版本中添加兼容性）。目前，此攻击只能使用最新版本的ESR 和即将发布的 **Elcomsoft Quick Triage (EQT)**来执行。
Active Directory 账户
传统的 Active Directory 环境代表了经典的 corporate 网络设置。在这种架构中，主身份验证数据库 (NTDS.dit) 集中存放在域控制器上。然而，为了移动性，Windows 工作站会在本地缓存域凭据，以便用户在断开与 corporate LAN 的连接时仍然可以登录。对于分析独立机器的调查人员来说，中央服务器是无法访问的，因此这个本地化缓存成为主要目标。
在工作站层面，取证提取侧重于从系统中获取 Local Security Authority (LSA) 机密和 DPAPI 数据。如果成功提取，调查人员可以对这些缓存的域凭据运行快速的离线攻击。
Entra ID（企业云）账户
Entra ID（以前称为 Azure AD）是现代企业标准，专门为零信任环境和远程工作人员设计。此架构中的身份验证 fundamentally 基于云，大量使用 Windows Hello for Business、Conditional Access 策略和 Primary Refresh Tokens (PRT) 来验证用户和管理会话。
在这些设置中，传统的本地密码哈希是不存在的。这给我们的术语带来了一个明显的模糊性：获得对 Entra ID 环境的访问权是否真的算作"密码恢复"？从技术上讲，不算。我们必须直面现代企业取证的现实：在配置正确的 Entra ID 环境中，字面意义上的"密码恢复"实际上已经失效。相反，取证调查人员有责任通过提取受保护的数据块并对其进行离线攻击来处理访问问题，详见下文。
Elcomsoft System Recovery (ESR) 可以提供什么帮助
虽然 Entra ID 部署不会在本地 PC 上存储传统密码哈希，但它确实存储了一个使用强加密（不同于传统的 NTLM）保护的本地化数据块。对此加密块的访问由保护器管理。在标准的企业部署中，此保护器通常是硬件支持的 PIN 或 FIDO 安全密钥。但是，如果系统配置使用密码作为保护器，则本地化恢复仍然是一种选择。
可以部署**Elcomsoft System Recovery (ESR)**来攻击这个特定的本地化数据块，但调查人员必须注意几个技术限制。首先也是最重要的是，只有当身份验证数据由密码保护器保护时，我们才能恢复它。如果数据块由硬件支持的 PIN 或 FIDO 密钥保护，并且没有基于密码的访问方式（这是微软推荐的做法），则离线恢复是不可能的。其次，与微软账户类似，Entra ID 使用强加密来保护该数据块，这意味着与 NTLM 相比，攻击速度会很慢。当前实现的方法完全依赖 CPU，并且还没有可用的 GPU 加速。因此，强烈建议运行有针对性的字典攻击，而不是尝试完整的暴力恢复。
最后，虽然将攻击卸载到更强大的工具（如 Elcomsoft Distributed Password Recovery）听起来很诱人，但该工具目前不支持这种特定的加密格式（计划进行更新）。截至目前，此加密块只能使用当前版本的 ESR 和即将发布的 Elcomsoft Quick Triage (EQT) 进行解锁。