文章来源|MS08067 内网安全知识星球
本文作者:Spark(Ms08067内网安全小组成员)
内网纵横四海 认准Ms08067
所谓的本地认证也就是计算机自身的认证。计算机本身是如何进行认证的,密码存储在哪里,是以什么样的形式存储的?
%SystemRoot%\system32\config\sam
当我们登录系统的时候,系统会自动地读取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. 如果相同,则认证通过
在内网渗透中,经常遇到工作组环境。工作组环境是一个逻辑上的网路环境,隶属于工作组的机器之间缺少“信托机构”,无法互相建立一个完美的信任机制,只能点对点,是比较落后的认证方式。
这里什么是信托机构,什么又是点对点认证呢?下面有请故事主角张三。
现张三有一笔钱需要转给李四,他需要有权限访问到李四的钱包,然后把钱放进去。
如果说存在一个信托机构,比如银行。那么首先张三得是银行的一个合法用户,李四也是银行的一个合法用户。在这样的前提下,张三访问李四的钱包,需要先通过银行的认证。
实际上信托机构就是指域控,而工作组下没有域控。所以张三访问李四的钱包,只需要知道李四的账号密码,直接向李四发起访问请求即可。
本节故事描述的就是工作组的情况,即张三与李四进行点对点认证。现假设张三需要访问的是李四的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
扫描下方二维码加入星球学习
加入后会邀请你进入内部微信群,内部微信群永久有效!