文章来源｜MS08067 内网安全知识星球
本文作者：Spark（Ms08067内网安全小组成员）
内网纵横四海 认准Ms08067
所谓的本地认证也就是计算机自身的认证。计算机本身是如何进行认证的，密码存储在哪里，是以什么样的形式存储的？
%SystemRoot%system32configsam
当我们登录系统的时候，系统会自动地读取SAM文件中的“密码”与我们输入的“密码”进行对比，如果相同，则认证成功。
上图是用python将“admin123”转换为NTLM Hash的形式。NTLM Hash长度32位，由数字与字母组成，是支持本地认证及Net NTLM认证协议过程中的一个重要参与物。
Windows Logon Process(即winlogon.exe) 是负责处理安全相关的用户交互界面的组件。Winlogon的工作包括加载其他用户身份安全组件、提供图形化的登陆界面，以及创建用户会话。
LSASS(本地安全认证子系统服务)用于微软Windows系统的安全机制。它负责Windows系统安全策略。它负责用户在本地验证或远程登陆时验证用户身份，管理用户密码变更，并产生访问日志。
整体流程如下：
1. 开机
2. winlogon.exe显示输入用户名密码的图形化页面
3. 用户输入用户名密码
4. lssas.exe将密码加密为NTLM Hash，并与本地SAM数据库中的NTLM Hash进行比较
5. 如果相同，则认证通过
故事一：windows网络认证
在内网渗透中，经常遇到工作组环境。工作组环境是一个逻辑上的网路环境，隶属于工作组的机器之间缺少“信托机构”，无法互相建立一个完美的信任机制，只能点对点，是比较落后的认证方式。
这里什么是信托机构，什么又是点对点认证呢？下面有请故事主角张三。
现张三有一笔钱需要转给李四，他需要有权限访问到李四的钱包，然后把钱放进去。
如果说存在一个信托机构，比如银行。那么首先张三得是银行的一个合法用户，李四也是银行的一个合法用户。在这样的前提下，张三访问李四的钱包，需要先通过银行的认证。
实际上信托机构就是指域控，而工作组下没有域控。所以张三访问李四的钱包，只需要知道李四的账号密码，直接向李四发起访问请求即可。
本节故事描述的就是工作组的情况，即张三与李四进行点对点认证。现假设张三需要访问的是李四的445号钱包（对应服务端的445端口）。
445端口对应的SMB服务，早期在网络上传输明文口令。后来出现了LAN Manager Challenge/Response验证机制，简称LM认证。它是如此简单以至于很容易就被破解。后来微软提出了WindowsNT挑战/响应验证机制，称之为NTLM认证。下面来逐步理解这个NTLM挑战/响应验证机制。
客户端主要在这一步向服务器确认协议的版本，是v1还是v2，当然不止这些。
1. 李四（Server）接受到张三（Client）发送的用户名（LiSi）后，判断本地账户列表是否有用户名LiSi。如果没有，返回认证失败；如果有，生成Challenge，并且从本地查找LiSi，使用NTLMHash加密Challenge，生成一个Net NTLM Hash对应的NTLM Hash存在内存中，并将Challenge发送给张三。
2. 张三接受到Challenge后，将自己提供的用户名（LiSi）的密码（123456）转换为NTLM Hash，使用NTLM Hash加密Challenge，这个结果叫Response，本质上也是Net NTLM Hash。最后将Response发送给李四。
3. 李四接受到张三发送的Response，将Response与之前的Net NTLM Hash进行比较，如果相等，则认证通过。
其实整个过程中缺少了一样很重要的东西，也就是在故事背景中埋下过的一个小伏笔：windows本身不存储明文密码。
基于上述逆推结果，诞生了Pass The Hash（即hash传递攻击）。
-
内网渗透中获取不到明文密码、破解不了NTLM Hash而又想扩大战果横向移动。
必要条件：
-
需要服务端的用户名
-
需要正确的NTLM Hash
实验
故事一是讲没有信托机构的情况，接下来说有信托机构的情况。物理层面上，大家可以把信托机构看成是域控。域中的认证一般使用kerberos协议认证。
-
Client
-
Server
-
KDC(Key Distribution Center) = DC
-
AD（Account Database）：存储所有的client白名单，只有存在于白名单的client才能顺利申请到TGT。
-
AS（Authentication Service）：为client生成TGT的服务。
-
TGS（Ticket Granting Service）：为client生成某个服务的ticket。
-
DC：Domain Controller：域控
-
KDC：Key Distribution Center：密钥分发中心
-
TGT：Ticket-Granting Ticket：发放的票据
-
AD：Account Database：账户数据库
-
AS：Authentication Service：认证服务
-
TGS：Ticket Granting Service：票据分发服务
如上图，整个域认证可分为三大步六小步。
下面开始讲故事。故事的名字叫张三（client）去游乐园坐过山车（server）。
由于前文提到，域环境内存在信托机构，非点对点认证。现在张三想坐过山车，必须通过游乐园管理员（DC）的认证。
首先张三在网上提前订了游乐园的门票，成为了游乐园（Domain）的合法用户。这是前提。
第一步：
游乐园管理员接收到请求后，由AS认证服务去AD中查询张三是否为合法用户。AD确认张三为合法用户后，AS返回给张三一张游乐园通票（TGT），通票上含有张三的身份证号（client info）等信息，用于后续验证。通票由管理员密码（KDC hash）加密，张三不可解。
除了通票（TGT）以外，管理员还会返回以张三的密码（client hash）加密的一把钥匙（session key），这把钥匙也会存在于通票（TGT）中。
第二步：由于得到通票（TGT）后张三没有管理员的密码，无法解密通票，所以张三再次向游乐园管理员（DC）发起请求，提出要坐过山车（server）的445号（445端口）座位。该请求包含使用钥匙（session key）加密的张三的身份证号（client info）和通票（TGT）。
管理员（DC）得到通票后，先使用自己的密码（KDC hash）解密通票，得到钥匙（session key）和张三的身份证号（client info）。接着，使用钥匙（session key）解密另一部分，获得张三的身份证号。两个身份证进行对比，相同则通过认证。通过认证后，管理员返回使用钥匙（session key）加密的过山车钥匙（server session key）和一张小票（ticket），这张小票使用过山车密码（server hash）加密，其中包含了过山车钥匙（server session key）和张三的身份证号（client info），结构大致如下。
第三步：最后张三将过山车钥匙（server session key）加密的身份证号，和小票（ticket）发送给过山车，过山车先用自己的密码解密小票（ticket），得到过山车钥匙（server session key）和张三的身份证号，再用过山车钥匙（server session key）解密请求的另一部分，得到张三的身份证号，两个身份证号进行对比，相同则认证通过。
至此，张三终于可以坐过山车的445号座位了。但是如果张三想坐游乐园的其他设备，比如摩天轮或者旋转木马，甚至张三如果想坐过山车的其他座位，都需要带着通票重新向管理员发起请求，也就是重复下图中的第3小步。
2.1 Pass The Ticket
-
如果我们获取到了过山车的密码（server hash），那么我们可以伪造ticket与server session key，也就是我们常说的白银票据。
-
如果我们获取到了游乐园管理员的密码（KDC hash），那么我们可以伪造TGT与session key，也就是我们常说的黄金票据。
白银票据
kerberos::list #列出票据kerberos::purge #清除票据kerberos::golden /domain:域名 /sid:域SID /target:Server01.spark.com /service:cifs /rc4:NTLM Hash /user:server001 /ptt
-
需要域控的权限（KDC hash）
-
需要与域控通信
kerberos::golden /domain:域名 /sid:域SID /rc4:krbtgt NTLM Hash /user:任意用户名 /ptt
-
https://www.bilibili.com/video/BV1S4411q7Cw?from=search&seid=6002087845489093061
扫描下方二维码加入星球学习
加入后会邀请你进入内部微信群，内部微信群永久有效！
本文始发于微信公众号（Ms08067安全实验室）：给大家讲个关于kerberos协议的故事...
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论