Windows认证机制

Windows认证

1.Windows本地认证

  • Administrator
  • 登陆系统时从sam文件中读取密码哈希和用户输入的密码进行NTML HASH进行比对。

2.我的密码在哪?

  • 路径**%System%\System32\config\SAM**

3.NTLM (NT LAN Manager) HASH

  • 32位 数字+字母(和md5长度一致)
  • Windows本身不存储用户的明文密码

4.NTLM Hash产生流程

1. 输入预处理:密码转 Unicode 编码

  • 原始密码:用户输入的明文密码(例如 Password123)。

  • 编码规则:将密码转换为 UTF-16 Little Endian (LE) 格式的字节序列。

    1
    2
    # 示例:密码 "Password123" 的 UTF-16LE 编码
    bytes = "P\0a\0s\0s\0w\0o\0r\0d\0123\0".hex() # 每个字符占 2 字节(含空终止符)

2. 计算 MD4 散列值

  • 算法选择:使用 MD4 算法(已被证明不安全,但 NTLMv1/v2 仍依赖此设计)。

  • 计算过程

    1. 填充消息:将 UTF-16LE 字节流按 MD4 规范填充至长度满足 长度 ≡ 448 mod 512
    2. 分块处理:将填充后的数据分为 512-bit 的块。
    3. 循环运算:对每块进行 48 轮位操作(包括非线性函数、模加、循环左移等)。
    4. 生成哈希:最终输出 128-bit(16字节) 的散列值。
  • 示例输出

    1
    2
    # "Password123" 的 NTLM Hash
    NTLM_Hash = "8846F7EAEE8FB117AD06BDD830B7586C"

image-20250316123942242

image-20250316125137000

  • 可以看出本质是编码后进行一次md4。

5.本地认证流程

image-20250316125341348

6.LM HASH

LM Hash(LAN Manager Hash) 是微软早期用于存储用户密码的哈希算法(Windows 95/98/Me 及旧版 NT 系统),因其严重安全缺陷(如弱加密、无盐值、密码长度限制等)已被弃用。以下是其生成流程及关键步骤:


1. LM Hash 生成流程

步骤 1:密码处理

  1. 转换为大写
    将用户密码的所有字母转为大写(例如 "Password123""PASSWORD123")。

  2. 填充或截断至14字节

    • 若密码长度 <14字符:用空字符(0x00)填充至14字节。
    • 若密码长度 >14字符:直接截断前14字节。

    python

    复制

    1
    2
    # 示例:密码 "Password123" 处理为 14 字节
    processed = "PASSWORD123".ljust(14, '\0') # 实际长度已足够,无需填充

步骤 2:分割为两组7字节

将14字节分为两组(每组7字节):

python

复制

1
2
part1 = processed[0:7]  # 前7字节
part2 = processed[7:14] # 后7字节

步骤 3:生成DES密钥

每组7字节转换为8字节的DES密钥(含奇偶校验位):

  1. 7字节 → 8字节扩展
    • 将7字节(56位)按每7位一组分割,插入奇偶校验位形成8字节(64位)。
    • 例如:7字节 0x123456789ABCDE → 扩展为8字节 0x123456789ABCDEF0(具体算法略)。

步骤 4:加密固定字符串

使用两组DES密钥分别加密**固定字符串 "KGS!@#$%"**(ASCII值 0x4B47532140232425):

python

复制

1
2
3
# 伪代码示例
cipher1 = DES_Encrypt(key=part1_key, plaintext="KGS!@#$%")
cipher2 = DES_Encrypt(key=part2_key, plaintext="KGS!@#$%")

步骤 5:拼接结果

将两次加密结果拼接为 16字节 的 LM Hash:

1
lm_hash = cipher1 + cipher2  # 16字节 → 32位十六进制字符串

2. 示例

以密码 "Password123" 为例:

  1. 处理后密码"PASSWORD123"(长度11,填充3个 \0 → 14字节)。
  2. 分割分组
    • Part1: "PASSWOR"(7字节)
    • Part2: "D123\0\0\0"(7字节)
  3. DES加密结果
    • Part1加密结果:AA39D9B300DE9D05(假设值)
    • Part2加密结果:D6E9D4F0B3F4C8A1(假设值)
  4. 最终 LM HashAA39D9B300DE9D05D6E9D4F0B3F4C8A1

7.Winodws网络认证

  1. 在工作组的网络环境中,想要进行网络认证必须得登陆目标主机的用户,因此无法建立一个完整的信托机制。
  2. 常见服务SMB 445

8-12.NTML 协议

  1. 在早期SMB协议采用明文传输密码,后来出现了LAN Manager Challenge/Response 验证机制,但也很容易呗破解。
  2. 后面由提出了WindowsNT挑战/响应机制,成为NTML,现在已经用NTML2以及kerberos认证了。
  • 第一步协商,向服务器协商是使用NTMLV1还是V2协议,

NTLM(NT LAN Manager)

  • 用途:旧版协议,用于非域环境或旧系统兼容。
  • 流程
    1. 客户端发送用户名到服务器。
    2. 服务器返回随机挑战(Challenge 8\16)。
    3. 客户端用密码NTML哈希加密(DES\HMAC-MD5)挑战并返回响应(Response)。
    4. 服务器验证响应。
  • 缺点:易受中继攻击(Relay Attack),无双向认证。

image-20250316131613421

13.NTMLv2-v1 协议区别

  1. 加密密钥都是NTML哈希,但加密算法不同,一个是V1-DES,一个V2-HMAC-MD5。
  2. Challenge值长度不同,一个是8位,一个是16位。

14.PASS-THE-HASH (哈希传递)

  • 在内网中抓取管理员的NTML HASH值。
  • 通过对服务器传递HASH值来完成认证的方式。

15.哈希传递必要条件

  1. 需要用户名和MTML-Hash

16.PTH原理

image-20250316133132980

17.PTH 工具

  • Smbmap
  • CrackMapExec
  • Smbexec
  • metasploit

18.Active Directory (活动目录)概念

  • Active Directory 存储了有关网络对象的信息,并且让管理员和用户能够轻松地查找和使用这些信息。AD使用了一种结构化地数据存储方式,并以此作为基础对目录信息进行合乎逻辑地分层组织
  • 网络对象分为:用户、用户组、计算机、域、组织单位以及安全策略等。

19.活动目录的功能

1. 统一身份管理与认证

  • 用户/组管理
    • 集中创建、删除、修改用户账户和用户组(如安全组、通讯组)。
    • 支持批量操作(如通过 PowerShell 或 CSV 文件导入用户)。
  • 身份认证
    • 集成 Kerberos 协议作为默认认证方式,支持单点登录(SSO)。
    • LDAP(轻量目录访问协议) 兼容,用于跨平台身份查询。
  • 密码策略
    • 强制密码复杂度(长度、字符类型)、过期时间、历史记录(防止重复使用)。
    • 账户锁定策略(失败登录次数阈值)。

2. 资源访问控制

  • 权限管理(ACL)
    • 通过 NTFS 权限共享权限 控制文件、文件夹、打印机等资源的访问。
    • 支持细粒度权限分配(如“读取”、“写入”、“完全控制”)。
  • 组策略(Group Policy)
    • 统一配置用户和计算机的桌面环境、安全策略、软件部署等。
    • 例如:强制安装防病毒软件、禁用 USB 存储、设置屏幕锁定时间。
  • 组织单元(OU,Organizational Unit)
    • 逻辑分组管理对象(如按部门划分 OU),便于分层应用组策略。

3. 域环境与逻辑结构

  • 域(Domain)
    • 安全边界,共享同一 AD 数据库和策略的管理单元。
    • 每个域有独立的安全策略和用户账户数据库。
  • 树(Tree)与林(Forest)
    • :多个域通过父子信任关系形成的层次结构(如 parent.comchild.parent.com)。
    • :多个树的集合,是 AD 中最大的逻辑边界,共享全局编录(Global Catalog)和架构(Schema)。
  • 信任关系(Trust)
    • 允许跨域或跨林资源共享(如单向信任、双向信任、外部信任)。

4. 服务与应用程序集成

  • DNS 集成
    • AD 依赖 DNS 解析域控制器(Domain Controller)和服务定位(SRV 记录)。
    • 动态更新 DNS 记录(如域控制器的 _ldap._tcp.dc._msdcs 记录)。
  • 证书服务(AD CS)
    • 颁发和管理数字证书,用于加密通信(如 SSL/TLS、智能卡登录)。
  • 联合身份(AD FS)
    • 支持跨组织单点登录(SSO),集成云应用(如 Office 365、SaaS)。
  • Azure AD 混合部署
    • 同步本地 AD 用户到云端的 Azure AD,实现混合身份管理。

5. 安全与合规

  • 审计与日志
    • 记录用户登录、文件访问、策略变更等事件(通过 Windows 事件日志)。
    • 支持合规性报告(如 GDPR、HIPAA)。
  • 特权账户保护
    • 管理管理员账户(如 Domain Admins)的访问权限,防止滥用。
    • 通过 Just-In-Time(JIT) 临时提升权限。
  • BitLocker 密钥备份
    • 将磁盘加密密钥存储在 AD 中,便于恢复。

6. 高可用性与灾难恢复

  • 域控制器(DC)冗余
    • 部署多台域控制器,通过多主机复制(Multi-Master Replication)同步数据。
    • 自动故障转移(如通过 DNS 轮询或站点感知)。
  • 备份与还原
    • 使用 ntdsutil 工具或第三方方案备份 AD 数据库。
    • 支持权威还原(恢复误删对象)和非权威还原(同步数据)。

7. 扩展与自动化

  • AD 架构(Schema)扩展
    • 自定义对象类型和属性(如添加员工工号字段)。
    • 需谨慎操作,架构变更不可逆。
  • PowerShell 管理
    • 使用 ActiveDirectory 模块自动化任务(如批量创建用户、导出报表)。
    • 示例命令:Get-ADUser -Filter * | Export-CSV users.csv

20.域认证协议-Kerbroes

Kerberos

  • 用途:域环境中的默认协议,更安全高效。
  • 流程
    1. 用户登录时,客户端向 AS 请求 TGT(使用密码哈希加密的时间戳)。
    2. AS 返回 TGT(用 KDC 密钥加密)和会话密钥。
    3. 客户端用 TGT 向 TGS 请求访问特定服务的票据(Service Ticket)。
    4. 客户端向服务出示票据,服务验证后授权访问。
  • 优势:双向认证、票据有效期短、支持委派。

21.域所参与的角色

  • KDC(密钥分发中心):包含 AS(认证服务)和 TGS(票据授予服务)。
  • Client(客户端)
  • Server(服务端)

22-23.KDC中的角色

  • AD (accout database) :存储所有客户端白名单,只有存在于白名单的客户端才能顺利申请TGT
  • Authentication Service:为客户端生成TGT服务
  • Ticket Granting Service: 为客户端生成某个服务ticket

image-20250316134946431

PS:从物理层面看,AD与KDC均为域控制器DC(Domain Controller)

24-27.域认证流程

  1. client向kerberos服务请求,希望获取访问server的权限。
    kerberos得到了这个消息,首先得判断client是否是可信赖的,也就是白名单黑名单的说法。这就是AS服务完成的工作,通过在AD中存储黑名单和白名单来区分client。成功后,返回AS返回TGT给client。
  2. client得到了TGT后,继续向kerberos请求,希望获取访问server的权限。kerberos又得到了这个消息,这时候通过client消息中的TGT,判断出了client拥有了这个权限,给了client访问server的权限ticket。
  3. client得到ticket后,终于可以成功访问server。这个ticket只是针对这个server,其他server需要向TGS申请。

Kerberos 认证详细流程

ps: KDS密钥分发中心

image-20250316140119990

步骤 1:客户端请求 TGT(AS_REQ)

  1. 客户端发起请求:用户输入用户名,客户端向 KDC 的 AS 发送明文请求,包含:

    • 用户名(如 [email protected])。
    • 请求的 TGS 名称(固定为 krbtgt/REALM)。
    • 客户端 IP 和时间戳(防止重放攻击)。

    image-20250316140503362

  2. AS 验证用户身份

    • AS 根据用户名查询域数据库,获取用户的密码哈希(即用户的密钥)。
    • 生成会话密钥(Session Key):AS 生成一个临时密钥(Client-TGS Session Key),用于后续客户端与 TGS 的通信。
    • 生成 TGT
      • TGT 包含:客户端用户名、客户端 IP、时间戳、TGT 有效期、Client-TGS Session Key
      • 加密 TGT:用 KDC 的主密钥(krbtgt 账户的密码哈希)加密 TGT,确保只有 TGS 能解密。
  3. AS 返回响应(AS_REP)

    • 加密部分
      • Client-TGS Session Key(用用户密码哈希加密)。
      • TGT(用 KDC 的主密钥加密)。
    • 明文部分:TGT 的有效期等信息。

    image-20250316140723995


步骤 2:客户端请求服务票据(TGS_REQ)

image-20250316141022519

  1. **客户端解密 Client-TGS Session Key**:

    • 用户输入密码后,客户端生成密码哈希,解密 Client-TGS Session Key
    • 客户端缓存 TGT 和 Client-TGS Session Key
  2. 客户端构建 TGS_REQ

    • 向 TGS 发送请求,包含:
      • 目标服务名(如 HTTP/server.domain.com)。
      • TGT(已加密)。
      • 认证器(Authenticator):包含客户端用户名、时间戳,用 Client-TGS Session Key 加密。
  3. TGS 验证请求

    • 用 KDC 的主密钥解密 TGT,获取 Client-TGS Session Key
    • Client-TGS Session Key 解密认证器,验证客户端身份和时间戳(防止重放)。
    • 检查 TGT 是否有效(未过期、未吊销)。
  4. TGS 生成服务票据(Service Ticket)

    • 生成服务会话密钥(Client-Server Session Key):用于客户端与服务端的通信。
    • 生成服务票据
      • 包含:客户端用户名、客户端 IP、时间戳、服务名、票据有效期、Client-Server Session Key
      • 加密服务票据:用服务端的密钥(服务账户的密码哈希)加密,确保只有服务端能解密。

    image-20250316150936188

  5. TGS 返回响应(TGS_REP)

    • 加密部分
      • Client-Server Session Key(用 Client-TGS Session Key 加密)。
      • 服务票据(用服务端密钥加密)。
    • 明文部分:服务票据的有效期等信息。

步骤 3:客户端访问服务(AP_REQ)

image-20250316141659078

  1. 客户端发送服务票据和认证器
    • 向服务端发送请求,包含:
      • 服务票据(用服务端密钥加密)。
      • 新的认证器(包含用户名、时间戳,用 Client-Server Session Key 加密)。
  2. 服务端验证请求
    • 用自身密钥解密服务票据,获取 Client-Server Session Key
    • Client-Server Session Key 解密认证器,验证时间戳和客户端身份。
    • 检查票据是否有效(服务名匹配、未过期)。
  3. 服务端响应(AP_REP,可选)
    • 若需双向认证,服务端返回一个时间戳(用 Client-Server Session Key 加密),客户端验证后确认服务端合法。

28.白银票据

  • 如果我们知道要访问的目标服务器的NTML HASH就可以就可以跳过KDS的认证流程,直接伪造Ticket票据来访问目标服务器。

29.白银票据伪造流程

  1. 首先随机自定义一个Client-Server Session Key加密Client infoTimestamp

  2. 然后使用目标服务器的NTML HASH加密(客户端用户名、客户端 IP、时间戳、服务名、票据有效期、Client-Server Session Key)。

  3. 然后将构造的两个信息发送给目标服务器,进行认证。

  • 白银票据相当于伪造了步骤 2:客户端请求服务票据(TGS_REQ)的4,5步。利用服务端NTML HASH进行伪造Ticket,达到访问的目的。
  • 白银票据主要用于已获得目标服务器权限但想访问目标服务器的服务,且没用域用户时使用。

Mimikatz

  • kerberos::list # 列出票据
  • kerberos::purge # 清楚票据
1
Mimikatz: c:\files>mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit" > log.txt

30.白银票据 (Silver Tickets) 默认服务

  • 白银票据只能针对目标服务器,也不能通过TGT申请,只能针对目标服务器某些服务器去伪造。
服务注释 服务名
WMI HOST\RPCSS
Powershell Remoteing HOST\HTTP
Scheduled Tasks HOST
LDAP\DCSync LDAP
Windows File Share(CIFS\SMB) CIFS
Windows Remote Server
Administration Tools
RPCSS
LDAP\CIFS

31.白银票据 具体流程

  • 通过将mimikatz将为找的票据导入到内存中,然后直接访问服务,就可以跳过认证。

32.白银票据 防御

  1. 尽量保证服务器凭证不被窃取。
  2. 通过注册表配置,开启PAC 特权属性证书保护功能。

33.黄金票据 (Golden Tickets)

黄金票据特点

  1. 需要与DC通信
  2. 需要krbtgt用户hash(就是之前说的KDC特殊用户hash)

原理

  1. 通过使用krbtgt用户HASH不断伪造TGT,来请求TGS,获取访问域内所有服务器服务的目的。

34.黄金票据-MSF kiwi

image-20250316163013560

image-20250316163041505

35.黄金票据创建

  • 使用mimikatz创建环境票据
1
mimikatz "kerberis::golden /domain:<域名> /sid:<域SID> /rc4:<KRBTGT NTLM HASH> /user:<任意用户名> /ptt" exit

36.Ticket总结

  • 黄金票据:从攻击面来看,获取krbtgt用户的hash后,可以在域中进行持久性的隐藏,并且日志无法溯源,但是需要拿到DC权限,使用黄金票据能够在一个域环境中长时间控制整个域。

  • 从防御角度来看,需要经常更新krbtgt的密码,才能够使得原有的票据失效。最根本的办法是不允许域管账户登录其他服务器。

  • 白银票据:人攻击面来看,伪造白银票据的难度比伪造黄金票据的难度较小,因为一个域中的服务器如果对外的话,非常容易被入侵并且容易被转储Server Hash。

  • 从防御角度来看,需要开启PAC认证,但这会降低认证效率,增加DC的负担,最根本的还是要加固
    服务器本身对外的服务。

  • 票据特性对比

特性 黄金票据(Golden Ticket) 白银票据(Silver Ticket)
攻击目标 域内所有服务 特定服务(如文件服务器、SQL)
依赖条件 KRBTGT 账户哈希 服务账户哈希
所需权限 域管理员权限 本地管理员或服务账户权限
检测难度 较高(需监控 TGT 生成行为) 极高(绕过 KDC,仅服务端日志)
持久性 长期有效(可设数十年) 依赖票据有效期(通常较短)

37.Windows Access Token 简介

  • 种类:主令牌、模拟令牌
  • 不同用户登陆计算机后都会生成一个Access Token,这个Token在用户创建进程和线程时使用,不断拷贝,也就是说一个进程对应一个令牌,其他用户访问则没有权限。
  • 用户运行一个程序都会拷贝一个explorer.exe的Access Token
  • 在桌面激活的情况下默认都使用的是主令牌。
  • 只有当用户注销后,系统才会将主令牌切换为模拟令牌。只有再重启计算机后将令牌清除。

访问令牌的类型

(1) 主令牌(Primary Token)

  • 关联对象:用户登录后生成的初始令牌,绑定到用户启动的进程(如 explorer.exe)。
  • 特点
    • 代表用户完整的身份和权限。
    • 用于创建新进程(子进程默认继承主令牌)。

(2) 模拟令牌(Impersonation Token)

  • 关联场景:当进程需要临时以其他用户身份执行操作时生成(如服务进程处理客户端请求)。
  • 模拟级别
    • Anonymous:无法获取用户身份。
    • Identification:仅能获取用户身份,不能模拟。
    • Impersonation:可在本地系统模拟用户。
    • Delegation:可跨机器模拟用户(需 Kerberos 委派支持)。
  • 生命周期:通常短暂,操作完成后恢复原始令牌。

38.访问令牌的组成

每个访问令牌包含以下关键信息:

  • 用户身份标识
    • 用户 SID(Security Identifier)**:唯一标识用户账户(如 S-1-5-21-...)。
    • 所属组 SID:用户所属的安全组(如 AdministratorsDomain Users)。
  • 权限列表(Privileges)
    • 分配给用户的特权(如 SeDebugPrivilegeSeShutdownPrivilege)。
    • 特权状态:Enabled(已启用)、Disabled(已禁用)或 Removed(已移除)。
  • 登录会话信息
    • 登录类型(交互式登录、网络登录等)。
    • 登录时间登录会话 ID
  • 其他安全属性
    • 所有者(Owner):默认是用户 SID,决定新创建资源的所有者。
    • 默认 DACL(Discretionary Access Control List):若无显式 ACL,资源将继承此默认访问控制列表。
    • 完整性级别(Integrity Level):从低到高(如 UntrustedMediumHighSystem),用于强制完整性控制(MIC)

39.SID 安全标志符

  • 具有唯一性
  • SID表现形式:
    • 域SID-用户ID
    • 计算机SID-用户ID
    • SID列表都会存储在域控的AD或者计算机本地账户数据库中。

40.Token产生过程

生成时机

  1. 用户登录:成功验证后,系统(LSA- Local security Authority)生成主令牌。
  2. 进程创建:新进程继承父进程的令牌(可通过 CreateProcessAsUser 指定不同令牌)。
  3. 模拟操作:服务或应用程序调用 ImpersonateLoggedOnUser 生成模拟令牌。

41.令牌仿冒实战

  • 使用工具对已经注销的用户查看系统上存在的模拟令牌
    • lncognito
    • Powershell - invoke -TokenManipulation.ps1
    • Cobalt Strike - steal_token

image-20250316170153320

42.Windows Access Token 伪造令牌防御

  1. 禁止Domain Admins 登陆对外且没有做安全加固的服务器。
  2. 清除模拟令牌,重启即可。