扫码领资料

获网安教程

免费&进群

windows 内网基础，还是得多学学，都记录一下，其中的某些概念只能说是通俗但不准确的理解，哈哈哈

认证流程展开目录

Windows 本地认证采用 sam hash 比对的形式来判断用户密码是否正确，计算机本地用户的所有密码被加密存储在 % SystemRoot% system32configsam 文件中，当我们登录系统的时候，系统会自动地读取 SAM 文件中的 “密码” 与我们输入的密码进行比对，如果相同，证明认证成功.

winlogon.exe（Windows Logon Process）是 Windows NT 用户登陆程序用于管理用户登录和退出。
lsass.exe（Local Security Authority Subsystem Service，本地安全认证子系统服务），它用于本地安全和登陆策略该程序运行内存中会记录用户输入的 hash
两个程序都是 system 权限运行

具体流程如上图：首先，用户注销、重启、锁屏后，操作系统会让 winlogon 显示登录界面，也就是输入框，接收输入后，将密码交给 lsass 进程，这个进程中会存一份明文密码，将明文密码加密成 NTLM Hash 与 SAN 种的 NTLM Hash 进行比较

SAM 文件展开目录

文件所在位置：% SystemRoot% system32configsam

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

LM Hash 与 NTLM Hash 展开目录

借一下大师傅的图

window 系统下的 hash 密码格式：
用户名称：RID:LM-HASH 值：NTLM-HASH 值
ps：Hash，一般翻译为 “散列”，就是把任意长度的输入（又叫做预映射 pre-image）通过散列算法变换成固定长度输出，该输出的就是散列值。
lsass 进程就是将密码转换为 Hash ，其实就是将 NTLM Hash 与 SAM 文件种的 NTLM Hash 进行比较

LM Hash

LM Hash 是 Windows 使用的最古老的密码存储，其历史可追溯到 1980 年代的 OS / 2。在 LAN Manager 协议中使用，由于允许的字符集有限，因此它们很容易破解。如果仍然可用，则可以从 Windows 系统上的 SAM 数据库或域控制器上的 NTDS 数据库中获取它们

但是从 Windows Vista / Server 2008 开始，默认情况下已关闭 LM，但某些工具的参数需要填写固定格式 LM hash:NT hash，可以将 LM Hash 填 0 (LM hash 可以为任意值)，即 00000000000000000000000000000000:NT hash
NT Hash

Vista 之后现代 Windows 系统使用的 Hash，它的前身是 LM Hash，两者相差不大，只是使用的加密算法不同。通常意义上的 NT Hash 指存储在 SAM 数据库及 NTDS 数据库中对密码进行摘要计算后的结果，NT Hash 可以通过转储 SAM 数据库或使用 Mimikatz 来获得，可直接用于 PtH，并且通常存在于 lsass 进程中，便于 SSP 使用 NT Hash 是支持 Net NTLM 认证协议及本地认证过程中的一个重要参数。其长度为 32 位，由数字与字母组成，通常人们称其为 NTLM Hash

NTLM 网络协议展开目录

具体想了解 NTLM 协议可以看看：http://davenport.sourceforge.net/ntlm.html
简单的例子：

主机 A 想要访问主机 B 上的资源，就要向主机 B 发送一个存在于主机 B 上的一个账户，主机 B 接收以后会在本地进行验证，如果验证成功，才会允许主机 A 进行相应的访问。

NTLM 协议是一种基于挑战（Chalenge）/ 响应（Response）认证机制，仅支持 Windows 的网络认证协议。
它主要分为协商、质询和验证三个步骤

1. 协商：这个是为了解决历史遗留问题，也就是为了向下兼容，双方先确定一下传输协议的版本等各种信息。

2. 质询：这一步便是 Chalenge/Response 认证机制的关键之处，下面会介绍这里的步骤。

3. 验证：对质询的最后结果进行一个验证，验证通过后，即允许访问资源

首先是协商

首先用户客户端向服务器发送消息协商它主要包含客户端支持和服务器请求的功能列表。

然后质询的完整过程图如下

首先 server 会发送一个 username 给 server，当 server 接收到这个信息时，首先会在本地查询是否存在这样的一个用户，如果不存在，则直接返回认证失败，如果存在，将会生成一个 16 位的随机字符，即 Chalenge，然后用查询到的这个 user 的 NTLM hash 对 Chalenge 进行加密，生成 response2，将 response2 存储在本地，并将 Chalenge 传给 client。当 client 接收到 Chalenge 时，将发送的 username 所对应的 NTLM hash 对 Chalenge 进行加密即 Response，并 Response 发送给 server。

最后一步就是验证的机制

server 在收到 Response 后，将其与 response2 进行比较，如果相同，则验证成功

然后就是如果是在域中，用户的 NTLM Hash 都处于域控中时的认证

这个时候 client 就会通过 netlogon 协议联系域控建立一个安全通道，然后将 server 发送的信息发给域控 (这个过程也叫作 Pass Through Authentication 认证流程)

（仅交互式身份验证存在此步骤）用户访问客户机并提供域名，用户名，密码。客户端计算密码的 Hash，并丢弃实际密码

1. 客户端将用户名发送到服务器

2. 服务器生成一个 16 字节的随机数 Challenge 并发送给客户端

3. 客户端使用用户密码的 Hash 对 Challenge 进行加密，然后将结果 response (Net-NTLM hash) 返回给服务器

4. 服务器将三个信息发送到域控制器：用户名，发送给客户机的 Challenge，返回给服务器的 response

5. 域控制器使用用户名从 SAM 数据库中检索用户密码 Hash。使用此密码 Hash 对 Challenge 进行加密

6. 域控制器将其加密的 Challenge（在步骤 6 中）与客户端计算的 response（在步骤 4 中）进行比较。如果它们相同则身份验证成功

值得一提的是 response 里面包含 Net-ntlm hashNTLM v1 响应和 NTLMv2 响应对应的就是 Net-ntlm hash 分为 Net-ntlm hash v1 和 Net-ntlm hash v2。
Net-ntlm hash v1 的格式为 username::hostname:LM response:NTLM response:challenge
Net-ntlm hash v2 的格式为 username::domain:challenge:HMAC-MD5:blob
在实际过程中使用哪个版本的响应由 LmCompatibilityLevel 决定。
但是由于 Net-ntlm hash v1 的自身缺陷，所以在多数情况下 Net-ntlm hash v1 已经废弃。
具体了解可以看看这篇文章：https://www.cnblogs.com/husterlong/p/14271976.html

Kerberos 域认证展开目录

在 Kerberos 协议中主要是有三个角色的存在（三个狗头）

• 访问服务的 Client (以下表述为 Client 或者用户)

• 提供服务的 Server (以下表述为服务)

• KDCKey Distribution Center 密钥分发中心 kerberos 测试工具介绍

其中 KDC 服务默认会安装在一个域的域控中而 Client 和 Server 为域内的用户或者是服务如 HTTP 服务 SQL 服务。在 Kerberos 中 Client 是否有权限访问 Server 端的服务由 KDC 发放的票据来决定。
先了解一下前置基础

• TGT (Ticket Granting Ticket)：入场卷，通过入场卷能够获得票据，是一种临时凭证的存在

• 票据 (Ticket)：是网络对象互相访问的凭证

KDC：

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

ps: 物理层面看，AD 与 KDC 均为域控制器
域认证粗略流程

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

• AS:client 发送信息给 KDC 通过 AD 认证之后返回一个经过 AD 中查询到的对应的 NTLM Hash 加密的生成的随机 Session key（Session Key 是 AS 随机生成的）

• TGT:KDC hash（AD 某个特殊用户的 NTLM Hash）加密一个客户端的信息（认证之后产生的），Session key 与 AS 的是一样的

看一下客户端发送的数据结构

看一下返回的 AS 与 TGT 的具体结构

以为 TGT 是特殊用户加密的所有 client 不能解密，TGT 有时间限制
第二步
Session Key 与 Ticket

这里的时间戳有防范暴力枚举的作用
Server Session key 又是 KDC 随机生成的（与 server 不共享）
KDC 提取 Server info 中的信息，有一个计算机名，提取对应的 hash 值加密 ticket
Ticket 构成

第三步
Server Session Key 与 Ticket

server 解密 Ticket 得到 Server Session Key，再解密下面的加密信息，两者都有时间限制的验证

白银票据展开目录

白银票据的特点：

1. 不需要与 KDC 进行交互

2. 需要目标服务的 NTLM Hash

在 kerberos 认证的第三步 Ticket 中组成：
Ticket=Server Hash(Server Session Key + Client info + End time)
当我们拥有 Server Hash 时，我们就可以伪造一个不经过 KDC 认证的一个 Ticket。
PS:Server Session Key 来自未发送 Ticket 之前 KDC 随机生成且没与 server 共享的，所有 server 不知道它具体是什么，（意思是我们客户端可以随意构造 Server Session Key 来伪造一个 Ticket）
所有：一切的凭据都来自 Server Hash

白银票据伪造
条件

1. 域名

2. 域 SID

3. 目标服务器的 FQDN

4. 可利用的服务

5. 服务账号的 NTLM Hash

6. 需要伪造的用户名

使用 Mimikatz

kerberos::list #列出票据
kerberos::purge #清楚票据

1：导出目标服务器计算机名的的 Hash

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

2: 票据伪造

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

3: 白银票据 (Silver Tickets)- 伪造默认服务

重点关注 DCSync 服务，这是域同步的服务，我们如果通过这个服务拿到域控的 hash 我们就可以拿到整个域的用户的 hash 以至于拿下整个域

具体伪造过程可以看看这篇文章：https://www.jianshu.com/p/dbea5b78ad18

白银票据防御

1：尽量保证服务器凭证不被窃取
2：开启 PAC (Privileged Attribute Certificate) 特权属性证书保护功能，开启 PAC 后，PAC 会将 client 发送的票据 ticket 发送给 KDC，由 KDC 来进行验证 ticket 是否有效，就可以使所伪造的票据无法进行利用。
开启方式：将注册表中的 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters 中的 ValidateKdcPacSignature 设为 1

具体可以看看这篇文章：https://zhuanlan.zhihu.com/p/89380294

黄金票据展开目录

黄金票据的特点：

1. 需要与 DC 通信

2. 需要 krbtgt 用户的 hash

ps：这里的 krbtgt hash 就是之前将的 KDC Hash（其实就是第一步中那个特殊用户的 hash ）

意思就是我们只需要拿到 krbtgt hash 就能伪造 TGT，而 session key 是由 AS 随机生成的，TGS 在收到 TGT 之前并不知道，所以可以伪造，然后申请不同服务的 Ticket，虽然黄金票据伪造难，但是 TGT 被 KRBTGT 密码散列加密并且可以被域中的任何 KDC 服务解密的，所以危害大。

黄金票据伪造
条件

1. 完整的域名称

2. krbtgt 账户的 NTLM Hash 或者 AES-256

3. 域的 sid

4. 需要伪造的域管理员用户名

利用：Mimikatz 与 msf 中的 kiwi 模板
具体可以看看这篇文章：https://www.jianshu.com/p/233d9d180cb1

黄金票据的防御
（1） 限制域管理员登录到除域控制器和少数管理服务器以外的任何其他计算机，将所有其他权限委派给自定义管理员组。这可以降低攻击者访问域控制器的 Active Directory 的 ntds.dit 文件。而如果攻击者无法访问 AD 数据库（ntds.dit 文件），则其无法获取到 krbtgt hash。
（2） 增加更改 krbtgt 账户的密码的频率。

其实并不很难，Kerberos 只是升级版的 NTLM ，然后白银票据和黄金票据只是在 Kerberos 中的不同步骤窃取凭证而已，最后都是达到一个 Ticket 的构造的目的，只是黄金票据可以持续维权还有可溯源性很低。
如果还不懂，推荐看一下这个视频：https://www.bilibili.com/video/BV1S4411e7hr

来源：http://blog.m1kael.cn/index.php/archives/105/

声明：⽂中所涉及的技术、思路和⼯具仅供以安全为⽬的的学习交流使⽤，任何⼈不得将其⽤于⾮法⽤途以及盈利等⽬的，否则后果⾃⾏承担。所有渗透都需获取授权！

（hack视频资料及工具）

（部分展示）