windows域环境下认证和攻击初识

roger

这是 酒仙桥六号部队 的第 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的服务。框架图如下：

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用于后续加密通信。

第二步 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响应给客户端。

第三步 服务认证

通过第二步，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，是可信服务端。

至此，kerberos认证流程完成，Client可访问Aservice提供的服务。

NTLM认证

NTLM认证采用质询/应答(Challenge/Response)的消息交换模式。NTLM既可用于域环境下的身份认证，也可以用于没有域的工作组环境。主要有本地认证和网络认证两种方式。

本地认证：

用户登陆windows时，windows首先会调用winlogon.exe进程接收用户输入的密码，之后密码会被传递给lsass.exe进程，进程会先在内存中存储一份明文密码，并将密码加密为NTLM hash，与本地SAM数据库中用户的NTLM hash对比，一致则登陆成功。

网络认证：

如下为NTLM域环境中网络认证流程。

第一步：首先用户输入正确用户密码登陆到客户端主机，用户想要访问某个服务器的服务，客户端先发送一个包含用户名明文的数据包给服务器，发起认证请求。

第二步：服务器生成一个随机数，称为Challenge，返回给客户端。

第三步：客户端接收到Challenge后，用密码hash加密，生成Response，发送给服务。

第四步：服务将Response、用户名、Challenge发送给域控验证。域控使用本地数据库(NTDS.dit)中保存的对应用户的NTLM hash对Challenge进行加密，得到的结果与Response进行对比，一致则认证成功。然后将认证结果返回给服务端。

相关攻击基础

windows下的用户密码hash

windows系统下的用户密码hash通常指的是Security Account Manager中保存的用户密码hash，也就是SAM文件中的hash，mimikatz读取出已登录用户的NTLM hash都是同一个hash，域控中NTDS.dit的hash。如下密码均为Aa123456，都是NTLM hash值。(以下操作均需以管理员权限执行)

SAM中的hash

先导出sam，mimikatz读取(本地用户ate/Aa123456)。

mimikatz读取。

mimikatz从内存dump出的hash

如下，cmd运行mimikatz.exe，在mimikatz会话中执行privilege::debug和sekurlsa::logonpasswords。

testdomain\test1密码Aa123456的hash。

域控中NTDS.dit的hash

如下，testdomain\test1密码Aa123456的hash。域中先利用ntdsutil导出NTDS.dit，SYSTEM和SECURITY文件。

导出文件的位置。

利用NTDSDumpEx查看，如下。

PTH

通过前面的内容，可以看到kerberos、NTLM认证过程的关键，首先就是基于用户密码hash的加密，所以在域渗透中，无法破解用户密码hash的情况下，也可以直接利用hash来完成认证，达到攻击的目的，这就是hash传递攻击（Pass The Hash）。如下，192.168.39.100为域控的地址，192.168.39.133为登陆过域管理账号的终端，获取到了域管理的hash，在192.168.39.133模拟pth来接管域控。

攻击成功后获取到一个shell，虽然是本机的，但可以操控域控，如下：

SPN

SPN 是指服务主体名称(Service Principal Names)，就是一个具体的服务在域里的唯一标识符，服务要使用kerberos认证，就需要正确配置SPN，服务可以使用别名或者主机名称向域注册SPN，注册完成后，可在域控使用ADSI编辑器连接到LDAP目录，查看服务的SPN。

SPN分为两种，一种是注册在机器账户上的，一种是注册在域用户账户中的。当服务的权限为Local System或Network Service，则SPN注册在机器帐户下。当服务的权限为一个域用户，则SPN注册在域用户帐户下。

比如，域控机器(也是一个机器账户)里的DNS服务（用ADSI编辑器连接LDAP查看）。

域用户可向域控LDAP目录查询SPN信息，从而获取到域内安装了哪些服务。

抓包可以看到是通过LDAP协议查询获得SPN信息。

通过SPN查询的方式发现域内的服务相比端口扫描更为隐蔽，但是也有缺陷，可能漏掉一些未注册的服务。

黄金票据和白银票据

黄金票据

黄金票据(Golden Ticket)是可换取任意服务票据(ST)的票据授权票据(TGT)，前面kerberos认证原理提到TGT是由域控krbtgt的密码Hash加密的，所以伪造金票的前提是控制了域控。

伪造金票需要域名、域sid、krbtgt的密码hash。如下在域控获取krbtgt hash。

在mimikatz.log中找到其NTLM hash。

用普通用户伪造金票并访问域控，获取域sid，注意不包含最后-xxxx。

/user指定伪造用户名，/domain指定域，/sid指定sid，/krbtgt指定krbtgt hash，/ptt直接将票据导入内存。

成功之后可访问域控C盘，注意要用主机名(如下WIN-xxxxx)而不是IP。

白银票据

白银票据(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。

普通用户伪造银票并导入内存获取权限，可取到域控krbtgt hash。/target指定服务主机名，/rc4指定服务密码的hash，/service指定服务，如下。

参考：

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]
　　

---