记一次限制环境下的域渗透实战
The following article is from 雁行安全团队 Author 圭臬
公众号现在只对常读和星标的公众号才展示大图推送，
建议大家把听风安全设为星标，否则可能就看不到啦！
----------------------------------------------------------------------
这次是对某个单位的红队评估项目，时间比较紧迫，主打一个快准狠。
一、接触
简单做一下信息收集，因为时间紧迫先拿空间搜索引擎跑一遍。小弟一般是用几个子域名查询网站（rapiddns.io等）加上fofa跑出来的子域名去重，然后拿解析信息里的txt、mx、ns，cname、IP这些记录，再用fofa去分别查询去重后的IP，中间结合证书和网站title等信息跑一遍，最后判断对方资产IP是否有集中的网段，有的话再去搜一下x.x.x.x/24，当然这个过程还可以加入很多别的操作。
前期用这种方式找了一圈资产，感觉能打的不是很多，没有快乐shiro也没有duangduang的fastjson。在开发不断规范化和安全越来越重视的环境下，这些漏洞的出场率逐渐变少了。
对第一步找到的资产进行探活，找到了一个asp的登记界面，打开一看没有注册功能也没有忘记密码功能，非常的好。
简单测试一下，没有弱口令且存在前端加密，需要分析js或用selenium去暴力破解（好怀念那个admin/123456输完就写报告的夏天），用短文件名也没跑到想要的东西。
想着能不能搞到这套系统的源码方便后续测试，小弟先对该系统的指纹做一个提取，找几个只有他有的js文件名用fofa去搜索一下。
一共有143个，数据不多也不少，先用常见的打包文件名（www.zip、bak.zip、web.zip）组合一些系统名和目录生成字典对这些站点批量扫一下（需要考虑授权的问题），最终发现了www.zip和XXX-web.zip两个网站打包文件。
瞅瞅conf文件，有数据库的密码，还挺复杂的，当然在内网中。
全局找找上传功能点，发现了一处未授权的前台上传，测试一下。
进行信息收集后确定有杀软，没考虑执行exe后果，执行后发现再执行命令木有回显且卡住（实战进行每一步操作还是得先考虑后果，还是太菜了）。
这种一般是杀软拦截了（卡住30s左右）
绕过的方式也有很多，小弟一般会先试试更换进程链，猜测杀软识别方式是
w3wp.exe->cmd.exe-><执行的命令>
尝试更换为w3wp.exe-><执行的命令>
实现的方式也有很多，比如更换命令执行模板、用自带的进程注入功能，或者直接上传一个相关功能实现的webshell文件。这里为了方便所以选择上cs，实际场景还是动作越小越好。
先把exe落地到服务器，然后修改命令执行模板，直接启动。
进程链为w3wp.exe -> test.exe
将口子维稳，收集信息，开始准备内网的工作。
二、内网
内网查看一下网络连接表中的IP都是哪些服务，发现一个存在前台任意文件读取历史漏洞的系统，漏洞利用拿到了数据库的配置信息进一步连接数据库，数据库内通过md5的方式存放了口令，不过很可惜user表的数据不太多。
接着读取/root/.bash_history，用漏洞去查看一下所有conf、ini、YAML等文件的信息，最终获得了一个新的数据库的口令。
又是一波信息收集（翻找），发现LDAP的配置项。
查看ldap后确定存在域环境，拿到了一个域用户权限。
三、域渗透
有域账号了之后通过ldap搜集域内的相关信息，主要是域用户信息、域管和当前获得的用户能登录的机器等等，发现域账号和域内机器都不少。
在信息收集后，大致了解目前的域环境就准备提权拿域管了，方法有很多当然怎么快怎么来。
因为域内开启证书服务，先试试2022-26923，结果第一步就G了。
那么再试试CVE-2021-42278+CVE-2021-42287，通过探测发现存在漏洞。
试试sam-the-admin（https://github.com/WazeHell/sam-the-admin）
很难受，也失败了。
分析一下原因，报错信息是一致的，doesn't have right to create a machine account!，这两种提权方式都会创建机器用户，是因为没有权限创建吗？
域内和域用户创建机器账号有关的属性可以先看看ms-DS-MachineAccountQuota，ldap查询发现为0，当然工具中也显示了该信息。
默认情况下为10，即域用户可以创建10个机器用户，但是这里提示的是没有权限而不是超过最大允许数，猜测还和组策略和ACL有关。
查看了一下师傅们关于MAQ为0限制下漏洞利用的方式可以分为：
2.寻找组策略中设置的特权用户
因为第一种利用方式是存在导致正常机器无法登入域的风险，且在目标环境内也没有找到对应的机器。测试第二种绕过方法，很可惜也没有找到。
这个路子就有点僵住了，想着换个方向拿高权，比如试试ESC8，但这个时候项目经理说时间又加了两天，下周一来了再交报告（狂喜），收拾东西回到家弄个花茶，外面下着小雨，正好能安安静静的研究一下这个洞还能不能搞，搞不了的话还有时间试试别的法子。
思考一下，能否将机器拉入域内是和权限设置有关的，而域内的访问控制是先判定是否有特权再对比ACL，所以准备从ACL找找看。因为小弟学艺不精，各种查GPT找到了一个相关的权限配置。
本地环境测试一下，首先设置maq为0，用test域用户创建。
然后针对test用户添加一条ACE再进行测试
呦西，看来是可行的
接下来就是如何寻找了，可以通过PowerView.ps1进行寻找或者用SDDL进行过滤（;;;computer;;）
回到目标环境去寻找一下拥有权限的用户信息，最终是找到了三个用户。
查看该用户所属组，不在域管里，lXXX（李某某）用户应该是运维设置的加域账号，接下来就是想办法拿到该用户的权限了。在前期拿到的数据user表中找到李哥的账号，拿到md5上冲一下。
测试存在口令复用，在内网里员工在不同系统上使用同一口令也是一个大风险。
用李哥的账号去尝试加机器账号
很nice，直接冲一发指定一名域管获得相关票据，尝试去拿域管hash。
同理，26923也能打了。
小结
整个过程因为小弟学艺不精，踩了不少的坑，整体上难度不高，主要是因为对域基础知识不够扎实导致浪费了不少时间去测试。大致可以总结为域管理员对权限进行划分，并设置MAQ进行域安全加固，但是相关特权用户存在口令复用问题和内网历史漏洞未修复，导致提权成功。
最后祝师傅们身体健康，钱包鼓鼓。