0x00 前言
过年回到家更是懒散,完全没有好好利用到放假的时间,除了自身的原因外,还与家里琐事和过年的忙碌有关。今天终于有时间来好好的学习一下了,这次我们将来学习充满神秘感并具有无限可能的内网安全知识。
0x01 工作组
简介
用过Windows的同学可能都会对“工作组”这三个字有印象。工作组其实就是类似于将电脑分组整理,比如行政部门组,财务部门组。他的特点有:
- 可以自由进出(只需修改自己电脑的工作组名称即可加入或者退出)
- 对等,没有管理和被管理之分
所以工作组虽然有一定的对内网网络进行分门别类的作用,但是不便于管理。
0x02 域
简介
域是工作组的升级版,但是不同的是,域有一定的安全措施。域有且至少有一个“域控制器(域控,Domain Control)”,即DC,它相当于门卫,负责对连入的电脑和用户进行验证,域内电脑想要互相访问,也必须经过了DC的认证。总结域的特点为:
- 有且至少有一个域控,不能自由进出
- 不对等
下面,我们再来深入了解其他关于域的知识。
域的组成
域内计算机根据作用的不同,可以划分为以下几类:
- 域控制器:域控制器用于管理所有的网络访问,包括登录服务器、访问共享目录和资源。
- 成员服务器:成员服务器是指安装了服务器操作系统并加入了域、但是没装活动目录(AD)的计算机,其主要任务是提供网络资源。
- 客户机:域中的计算机可以是安装了其他操作系统的计算机。用户利用这些计算机和域中的账户就可以登录域。
- 独立服务器:独立服务器和域没有关系。独立服务器可以创建工作组、与网络中的其他计算机共享资源,但不能使用活动目录提供的任何服务。
其中,如简介中所说的那样,一个域中必须要有一个DC,而其他部分可以不必有。也就是说,最小的域就是一台DC。
组织单元OU
组织单元(Organization Unit,OU)是一个容器对象,将域中的对象组织成逻辑组,帮助网络管理员简化管理组。组织单元包含下列类型的对象:用户,计算机,工作组,打印机,安全策略,其他OU(可以嵌套)等。可以在组织单元基础上部署组策略,统一管理组织单元中的域对象。 在企业域环境里面,我们经常看到按照部门划分的一个个OU。
云里雾里,其实OU就类似于Windows中的目录。
父域与子域
一个域下新建另一个域,即构成了父子域。一个父域可以有多个子域,但子域必须以父域的域名作为后缀,与域名类似,即父域为chenlvtang.com,子域为php.chenlvtang.com等。
单域
即单独一个域
域树
类似于数据结构中的树,一层层的父域与子域,即构成了一颗域树。由于父域与子域的名字连续性,域树自然也具有名字上的连续性。
域林
不同域树之间通过建立信任关系,即构成了域林。域林中创建的第一个域,叫做根域。
活动目录(AD)
Active Directory,活动目录的逻辑结构就包括上面讲到的组织单元(OU)、域(domain)、域树(tree)、域森林(forest)。在域树内的所有域共享一个活动目录。通过活动目录,可以对域中计算机进行集中的管理,相当于域中的数据库和字典。值得注意的是,AD是安装到DC上的,也就是说,一台计算器在安装完AD后,就变成了DC。
域控(DC)
如上文所说,一个域中就有一个AD,并根据域的多少,会组成一个AD库,存放了AD库的机器我们就称之为DC。因为AD库中含有用户账户、密码等信息,所以在内网渗透中,拿下域控对我们的横向移动至关重要。
DNS域名服务器
如上文,域的名字实际上就是DNS域的名字,域中的计算机通过DNS来定位域控以及其他的成员。一般DNS服务器与DC会布置在同一台服务器中,所以在渗透测试中,我们通常需要通过DNS服务器来定位域控。
DMZ
DMZ即demilitarized zone,“隔离区”。外网与内网之间的缓冲区,用于存放Web服务器、FTP服务器等必须公开的服务器设施。
0x03 域内权限
简介
域内权限通过组来划分,常见的组有:域本地组、全局组、通用组。
域本地组
成员范围:域林
使用范围:本域
全局组
成员范围:本域
使用范围:域林
通用组
成员范围:域林
使用范围:域林
A-G-DL-P策略
- A(account),表示用户账号
- G(Global group),表示全局组
- U(Universal group),表示通用组
- DL(Domain local group),表示域本地组
- P(Permission 许可),表示资源权限。
A-G-DL-P策略是将用户账号添加到全局组中,将全局组添加到域本地组中,然后为域本地组分配资源权限。即,在AGDLP形成以后,当给一个用户某一个权限的时候,只要把这个用户加入到某一个本地域组就可以了。
0x04 信任关系
信任
信任是在域之间建立的关系,可以使一个域中的用户由其他域中域控制器进行身份验证。
在Windows NT4.0中,信任被限制在两个域之间,且是单向不可传递的。
如:信任域A信任方向指向受信任域B,则只能域B访问域A,称为访问方向。
flowchart LR A -- 信任方向 --> B B -. 访问方向 .-> A
在Windows Server 2000,2003,2008,2008R2中,域林的所有信任都是双向的且可传递。
flowchart LR A<-->B<-->C
信任协议
运行 Windows Server 2008 或 Windows Server 2008 R2 的域控使用以下两个协议之一对用户和应用程序进行身份验证:Kerberos 版本 5 (V5) 协议或 NTLM。
NTML是Windows NT早期的信任协议,现在的Server2000、2003等服务器,都是默认采用的Kerberos V5,只有在事务中任意台计算器不支持Kerberos时,才会使用NTML。
kerberos协议
Kerberos协议主要涉及到三个角色:
- 请求服务的Client
- 提供服务的Server
- KDC(Key Distribution Center)密钥分发中心
这三者的关系是:Client要访问Server,必须提供票据,而票据就是由KDC颁发。
KDC一般默认安装在域控中,而KDC又分为两部分:
Authentication Server: AS的作用就是验证Client端的身份(确定你是身份证上的本人),验证通过就会给一张TGT(Ticket Granting Ticket)票给Client。
Ticket Granting Server: TGS的作用是通过AS发送给Client的票(TGT)换取访问Server端的票(上车的票ST)。ST(ServiceTicket)也有资料称为TGS Ticket,为了和TGS区分,在这里就用ST来说明。
flowchart LR Client --我要访问server--> AS AS--给你TGT,去TGS上换张票-->Client Client--给你TGT,换一张ST去server-->TGS TGS--好的,给你ST-->Client
创建域时,会自动创建一个KDC账户KRBTGT,但无法登录。
kerberos认证过程
用户登录
在用户输入完用户名和密码后,客户端会将密码计算生成NTML HASH,作为Client密钥
之后开始Kerberos的认证过程。
第一步
(此处有文章说是发送了NTML HASH加密的信息,包含时间戳等,可能是版本问题,此处以维基百科为准)
1.Client 以明文的方式发送User ID给AS(并没有发送密码或是密钥)
2.AS在接收到ID后,会先现在AD(活动目录)中寻找是否存在该用户,如果存在,则会根据AD中的用户密码生成KDC端的Client密钥(如果用户输入密码正确,则NTML HASH与此密钥自然相同),然后返回给Client以下信息:
- Msg_A: 使用KDC生成的Client密钥加密KDC生成的Client/TGS SessionKey
- Msg_B: TGT,使用Krbtgt用户的NTML HASH加密而成,其内容包括,Client/TGS SessionKey,Client ID,Ticket有效时间,Client 地址(在开启include_pac选项后,还会有pac,PAC包含用户Client的sid和用户Client所在的组。PAC对于用户和服务全程都是不可见的。只有KDC能制作和查看PAC。)
3.Client 接收到了Msg_A和 TGT 之后:
用自身密码解密Msg_A得到 Client/TGS SessionKey(以此相互确定了客户端和KDC的身份,因为只要有一方是假,则不能成功解密)。
TGT 是由 KDC 密码加密,Client 无法解密。
第二步
1.Client在得到TGT后,接着向TGS(TGS对用户的认证过程中,只要能够成功解密TGT就会认为用户是可信的。)发出请求,包含以下两个信息:
- Msg_C: TGT和要访问的服务ID(SPN)
- Msg_D: 使用刚刚获得的Client/TGS SessionKey加密{Client ID,时间戳}而成的Auth1
2.TGS在收到请求后:
使用Krbtgt用户的NTML HASH来解密TGT,得到Client/TGS SessionKey,以及其他信息
使用得到的Client/TGS SessionKey来解密Auth1,得到{Client ID,时间戳},并与刚刚获得的{Client ID,Ticket有效时间}进行对比验证
3.如果上面的验证通过,TGS就会返回以下的信息:
- Msg_E: 使用Server密钥(即其NTML HASH)加密而成的ST(有的材料称为TGS票据),其内容包括:Client/Server SessionKey,Client网络地址,Ticket有效时间,Client ID (在开启include_pac选项后,还会有pac)
- Msg_F: 使用Client/TGS SessionKey加密的Client/Server SessionKey
第三步
1.Client 收到TGS返回的信息后,同理的可以获得Client/Server SessionKey,但是无法解密ST,其之后会向Server发出包含以下信息的请求:
- Msg_G:ST
- Msg_H: 使用刚刚获得的Client/Server SessionKey加密{Client ID,时间戳}而成的Auth2
2.Server在接收后:
使用自己的Hash,解密ST,得到了Client/Server SessionKey及其他信息
然后使用得到的Client/Server SessionKey解密Auth2,得到{Client ID,时间戳},并与刚刚获得的{Client ID,Ticket有效时间}进行对比验证
(在开启include_pac选项后,server会拿着PAC去KDC那边问Client有没有访问权限,域控解密PAC。获取Client的sid,以及所在的组,再根据该服务的ACL,判断Client是否有访问Server的权限。)
3.通过验证后,Server会给Client返回以下信息:
- Msg_I: 使用Client/Server SessionKey加密的从Auth2获得的时间戳
4.Client收到后,使用Client/Server SessionKey解密,提取出时间戳,确认与之前发送给Server的时间戳一致
5.客户端和服务端建立起连接
受信任对象TDO
受信域对象 (TDO) 是用于代表特定域中的每个信任关系的对象。每次建立信任时,在受信域(系统容器中)中创建并存储唯一的 TDO。在 TDO 中表示属性,如信任可传递性、类型和相应的域名称。
林信任 TDO 存储其他属性以识别其伙伴林中的所有受信任命名空间。这些属性包括域树名称、用户主体名称 (UPN) 后缀、服务主体名称 (SPN) 后缀和安全标识符 (SID) 命名空间。
信任方向
运行 Windows Server 2008 或 Windows Server 2008 R2 的域控制器上的安全系统必须确定信任域(包含用户尝试访问的资源的域)与受信域(用户的登录域)之间是否具有信任关系之后,用户才可以访问另一个域的资源。若要确定这一点,安全系统会计算位于受信域中的信任域和域控制器中的域控制器之间的信任路径。如上文的图(信任小结)中,信任路径由箭头表示,该箭头显示信任的方向。
分为两个方向:
单向,即只能单向访问。
其又分为内传与外传:
内传表示被其他域信任,外传表示信任其他的域
双向,即建立信任后,可以互相访问
注意的时,信任方向与传递关系并没有直接联系,即,双向不一定可传递,可传递性,与信任类型有关
信任类型
创建信任时,可以创建以下四种类型的信任:
信任类型 | 传递性 | 方向 | 描述 |
---|---|---|---|
外部 | 不可传递 | 单向或双向 | 使用外部信任可提供对位于 Windows NT 4.0 域上的资源或林信任未连接的单独林中域上资源的访问权限。有关详细信息,请参阅了解何时创建外部信任。 |
领域 | 可传递或不可传递 | 单向或双向 | 使用领域信任可在非 Windows Kerberos 领域和 Windows Server 2008 或 Windows Server 2008 R2 域之间形成信任关系。有关详细信息,请参阅了解何时创建领域信任。 |
林 | 可传递 | 单向或双向 | 使用林信任共享林间的资源。如果林信任是双向信任,在任一林中发出的身份验证请求都可以到达另一个林。有关详细信息,请参阅了解何时创建林信任。 |
快捷方式 | 可传递 | 单向或双向 | 使用快捷方式信任可减少用户在 Windows Server 2008 或 Windows Server 2008 R2 林中两个域间登录所花的时间。这在由两个域树分隔两个域时非常有用。有关详细信息,请参阅了解何时创建快捷方式信任。 |
创建可以使用单独创建或同时创建信任的双方:
选择单独创建信任的每一方,则必须运行新建信任向导两次,即为每个域运行一次。在使用此方法创建信任时,必须为每个域提供相同的信任密码。
如果选择同时创建信任的双方,则运行一次新建信任向导。选择此选项后,将会自动生成强信任密码。必须具有在其间创建信任的域的适当管理凭据。
林中的信任关系
0x05 参考
内网基础知识 - 肖洋肖恩、 - 博客园 (cnblogs.com)
了解信任 (forsenergy.com) (一个很好的网站,可以帮你了解Windows域知识)
域渗透-Kerberos.md (这里面的认证过程可能有点问题,最后我基于维基百科以及其他博客进行了重新编写)