这是 酒仙桥六号部队 的第 78 篇文章。 全文共计3484个字,预计阅读时长12分钟。 Kerberos认证原理 Kerberos是一种认证机制。目的是通过密钥系统为客户端/服务器应用程序提供强大的可信任的第三方认证服务:保护服务器防止错误的用户使用,同时保护它的用户使用正确的服务器,即支持双向验证。kerberos最初由MIT麻省理工开发,微软从Windows 2000开始支持Kerberos认证机制,将kerberos作为域环境下的主要身份认证机制,理解kerberos是域渗透的基础。 kerberos认证框架 kerberos机制中主要包含三个角色:Client、Server、KDC(Key Distribution Center)密钥分发中心。Client代表用户,用户有自己的密码,Server上运行的服务也有自己的密码,KDC是受信任的三方认证中心,它拥有用户和服务的密码信息。KDC服务默认会安装在域控中,Client想要访问Server的服务(xxx service),前提是通过KDC认证,再由KDC发放的票据决定Client是否有权限访问Server的服务。框架图如下:
windows域环境下认证和攻击初识
kerberos认证术语初识 KDC(Key Distribution center):密钥分发中心,在域环境中,KDC服务默认会安装在域控中。 AS(Authentication Service):认证服务,验证client的credential(身份认证信息),发放TGT。 TGT(Ticket Granting ticket):票据授权票据,由KDC的AS发放,客户端获取到该票据后,以后申请其他应用的服务票据(ST)时,就不需要向KDC的AS提交身份认证信息(credential),TGT具有一定的有效期。 TGS(Ticket Granting Service):票据授权服务,验证TGT,发放ST。 ST(Service Ticket):服务票据,由KDC的TGS发放,是客户端应用程序访问Server某个服务的凭证,Server端验证通过则完成Client与Server端信任关系的建立。 先由简到繁地去梳理以上术语的关系。首先Client想要访问Server的某个服务,就需要通过KDC的认证,获取到服务票据(ST),服务会验证服务票据(ST)来判断Client是否通过了KDC认证。为了避免Client每次访问Server的服务都要向KDC认证(输入密码),KDC设计时分成了两个部分,一个是AS,另一个是TGS,AS接收Client的认证信息,认证通过后给Client发放一个可重复使用的票据TGT,后续Client使用这个TGT向TGS请求ST即可。 Authenticator:验证器,不能重复使用,与票据(时效内能重复使用)结合用来证明Client声明的身份,防止票据被冒用。 windows域kerberos认证流程
第一步 AS认证(获取TGT)请求:Client 向KDC的AS发起认证请求,身份认证信息包含了用户密码hash(user_hash)加密的timestamp预认证信息pre-authentication data,以及用户名(user)、客户端信息(client info)、服务名(krbtgt)等未加密信息。 生成session key以及TGT:域控中存储了域中所有用户密码hash(user_hash),KDC的AS依据用户名查找相应的user_hash,成功解密预认证信息,验证客户端通过,然后会生成一个sessionkey-TGS(后续用于加密Client与TGS通信),以及TGT(由krbtgt hash加密的sessionkey-TGS、user、client info、lifetime、timestamp等信息)。 注:krbtgt账户是创建域时系统自动创建的,可以认为是为了kerberos认证服务而创建的账号。 注:TGT是KDC加密的,Client无法解密,并且具有有效期,客户端用其向TGS请求ST。 响应:AS用user_hash加密sessionkey-TGS,与TGT一起生成REP响应发送给客户端。客户端解密响应成功说明数据包是KDC发送来的,并且获得sessionkey-TGS以及TGT,sessionkey-TGS用于后续加密通信。
windows域环境下认证和攻击初识
第二步 TGS认证(获取ST)通过第一步,客户端解密AS的响应后,可以得到一个sessionkey-TGS以及TGT。 请求:用户想访问Aservice服务,于是向TGS请求访问Aservice的ST。首先客户端会生成验证器Authenticator,内容包含user、client info、lifetime、timestamp信息,并且用sessionkey-TGS加密。客户端将验证器、Aservice信息、TGT发送给TGS请求ST。 生成session key以及ST:TGS收到请求,利用krbtgt hash解密TGT,获取到sessionkey-TGS,user、client info等信息,然后利用sessionkey-TGS解密验证器,校验验证器和TGT中的user信息,如果一致,则说明该请求符合TGT中声明的用户,该用户是通过AS认证的。然后TGS会为用户user和服务Aservice之间生成新的session key sessionkey-Aservice,并用sessionkey-TGS加密sessionkey-Aservice。再生成一个ST,内容包含user、client info、lifetime、timestamp、sessionkey-Aservice,ST用Aservice的service_hash加密。 注:验证器Authenticator只能使用一次,是为了防止TGT被冒用。kerberos设计之初,产生票据的概念就是为了避免重复的常规密码验证,因为票据在有效期内可以重复使用。为了避免冒用,设计出session key以及Authenticator。session key只有真正的客户端、服务知道,利用session key加密验证器,服务就可以解密对比验证器以及票据中声明的用户、客户端信息是否一致,一致说明票据来自可信客户端。 响应:TGS将sessionkey-TGS加密后的sessionkey-Aservice以及service_hash加密的ST响应给客户端。
windows域环境下认证和攻击初识
第三步 服务认证通过第二步,Client获取到sessionkey-Aservice以及ST,接下来Client利用sessionkey-Aservice加密Authenticator,连同ST去请求Server的Aservice。Aservice 利用自己的service_hash解密ST,获得sessionkey-Aservice,再解密Authenticator验证Client声明的user信息,通过认证后Aservice还需要用sessionkey-Aservice加密一段信息返回给Client,Client利用sessionkey-Aservice解密成功说明Aservice用自己service_hash成功解密出了sessionkey-Aservice,是可信服务端。
windows域环境下认证和攻击初识
至此,kerberos认证流程完成,Client可访问Aservice提供的服务。 NTLM认证 NTLM认证采用质询/应答(Challenge/Response)的消息交换模式。NTLM既可用于域环境下的身份认证,也可以用于没有域的工作组环境。主要有本地认证和网络认证两种方式。 本地认证: 用户登陆windows时,windows首先会调用winlogon.exe进程接收用户输入的密码,之后密码会被传递给lsass.exe进程,进程会先在内存中存储一份明文密码,并将密码加密为NTLM hash,与本地SAM数据库中用户的NTLM hash对比,一致则登陆成功。
windows域环境下认证和攻击初识
网络认证: 如下为NTLM域环境中网络认证流程。 第一步:首先用户输入正确用户密码登陆到客户端主机,用户想要访问某个服务器的服务,客户端先发送一个包含用户名明文的数据包给服务器,发起认证请求。
windows域环境下认证和攻击初识
第二步:服务器生成一个随机数,称为Challenge,返回给客户端。
windows域环境下认证和攻击初识
第三步:客户端接收到Challenge后,用密码hash加密,生成Response,发送给服务。
windows域环境下认证和攻击初识
第四步:服务将Response、用户名、Challenge发送给域控验证。域控使用本地数据库(NTDS.dit)中保存的对应用户的NTLM hash对Challenge进行加密,得到的结果与Response进行对比,一致则认证成功。然后将认证结果返回给服务端。
windows域环境下认证和攻击初识
相关攻击基础
windows下的用户密码hashwindows系统下的用户密码hash通常指的是Security Account Manager中保存的用户密码hash,也就是SAM文件中的hash,mimikatz读取出已登录用户的NTLM hash都是同一个hash,域控中NTDS.dit的hash。如下密码均为Aa123456,都是NTLM hash值。(以下操作均需以管理员权限执行) SAM中的hash先导出sam,mimikatz读取(本地用户ate/Aa123456)。
windows域环境下认证和攻击初识
mimikatz读取。
windows域环境下认证和攻击初识
mimikatz从内存dump出的hash如下,cmd运行mimikatz.exe,在mimikatz会话中执行privilege::debug和sekurlsa::logonpasswords。
windows域环境下认证和攻击初识
testdomain\test1密码Aa123456的hash。
windows域环境下认证和攻击初识
域控中NTDS.dit的hash如下,testdomain\test1密码Aa123456的hash。域中先利用ntdsutil导出NTDS.dit,SYSTEM和SECURITY文件。
windows域环境下认证和攻击初识
导出文件的位置。
windows域环境下认证和攻击初识
利用NTDSDumpEx查看,如下。
windows域环境下认证和攻击初识
PTH通过前面的内容,可以看到kerberos、NTLM认证过程的关键,首先就是基于用户密码hash的加密,所以在域渗透中,无法破解用户密码hash的情况下,也可以直接利用hash来完成认证,达到攻击的目的,这就是hash传递攻击(Pass The Hash)。如下,192.168.39.100为域控的地址,192.168.39.133为登陆过域管理账号的终端,获取到了域管理的hash,在192.168.39.133模拟pth来接管域控。
windows域环境下认证和攻击初识
攻击成功后获取到一个shell,虽然是本机的,但可以操控域控,如下:
windows域环境下认证和攻击初识
SPNSPN 是指服务主体名称(Service Principal Names),就是一个具体的服务在域里的唯一标识符,服务要使用kerberos认证,就需要正确配置SPN,服务可以使用别名或者主机名称向域注册SPN,注册完成后,可在域控使用ADSI编辑器连接到LDAP目录,查看服务的SPN。 SPN分为两种,一种是注册在机器账户上的,一种是注册在域用户账户中的。当服务的权限为Local System或Network Service,则SPN注册在机器帐户下。当服务的权限为一个域用户,则SPN注册在域用户帐户下。 比如,域控机器(也是一个机器账户)里的DNS服务(用ADSI编辑器连接LDAP查看)。
windows域环境下认证和攻击初识
域用户可向域控LDAP目录查询SPN信息,从而获取到域内安装了哪些服务。
windows域环境下认证和攻击初识
抓包可以看到是通过LDAP协议查询获得SPN信息。
windows域环境下认证和攻击初识
通过SPN查询的方式发现域内的服务相比端口扫描更为隐蔽,但是也有缺陷,可能漏掉一些未注册的服务。 黄金票据和白银票据
黄金票据黄金票据(Golden Ticket)是可换取任意服务票据(ST)的票据授权票据(TGT),前面kerberos认证原理提到TGT是由域控krbtgt的密码Hash加密的,所以伪造金票的前提是控制了域控。 伪造金票需要域名、域sid、krbtgt的密码hash。如下在域控获取krbtgt hash。
windows域环境下认证和攻击初识
在mimikatz.log中找到其NTLM hash。
windows域环境下认证和攻击初识
用普通用户伪造金票并访问域控,获取域sid,注意不包含最后-xxxx。
windows域环境下认证和攻击初识
/user指定伪造用户名,/domain指定域,/sid指定sid,/krbtgt指定krbtgt hash,/ptt直接将票据导入内存。
windows域环境下认证和攻击初识
成功之后可访问域控C盘,注意要用主机名(如下WIN-xxxxx)而不是IP。
windows域环境下认证和攻击初识
白银票据白银票据(Silver Tickets)是指伪造的服务票据(ST),只能用来访问特定的服务,通过kerberos的认证原理得知ST是由TGS颁发的,使用了服务的密码hash加密,所以在伪造银票的时候需要知道服务的密码hash。下面通过创建LDAP银票访问域控LDAP服务来演示银票的伪造和利用。 域控的LDAP服务是由网络服务账户运行的,其对应sid是S-1-5-20,域控上通过mimikatz获取hash,执行mimikatz.exe log privilege::debug sekurlsa::logonpasswords exit。
windows域环境下认证和攻击初识
普通用户伪造银票并导入内存获取权限,可取到域控krbtgt hash。/target指定服务主机名,/rc4指定服务密码的hash,/service指定服务,如下。
windows域环境下认证和攻击初识
参考: https://www.cnblogs.com/felixzh/p/9855029.html
[url]https://blog.csdn.net/dog250/article/details/5468741[/url]
[url]https://tools.ietf.org/html/rfc4120.html[/url]
[url]https://blog.csdn.net/qq_18501087/article/details/101593642[/url]
[url]https://blog.csdn.net/weixin_30532987/article/details/96203552[/url]
[url]https://support.microsoft.com/en-au/help/243330/well-known-security-identifiers-in-windows-operating-systems[/url]
|