本文介绍了笔者在某次攻防演练中，如何从外网渗透到某车企的内网的详细过程（为了保护敏感信息，所有数据都已经脱敏，有些截图也不完整，请见谅）。
这次网络攻防演练分为两个阶段一共十四天，前七天是私有资源阶段，后七天是公共资源池阶段。共有12支队伍参与比赛，我们公司全程只有两名选手参赛。由于公司从不提供一些辅助工具和人力资源，并且我俩近期连续参加了多场比赛，导致每次比赛后我俩都很内耗。
裁判只给出了目标企业的名称，让我们自行寻找其他的信息，这是对我们资源差的队伍是一种考验。
幸运的是，笔者之前编写了一套信息收集的辅助脚本，现在可以派上大用场了。
首先，使用子公司收集脚本来搜索一级子公司。该脚本根据特定的条件和规则进行搜索，以获取与一级公司有50%的控股关系的子公司。然后，我们对这些一级子公司再次使用脚本进行搜索，以找到与它们有50%的控股关系的子公司。这个过程不断循环，直到没有符合条件的子公司为止，所以你看到下面最深达到了四级公司。
接下来，再用资产收集脚本对子公司收集脚本的ICP结果进行一系列的操作，该脚本包括子域名匹配、端口扫描、web路径搜索、服务识别等，最终结果会到了以下三个文件，其中ip文件可以交给灯塔去进行信息收集、url文件可以交给poc扫描器、详情文件可以在扫描poc的时候手工去寻找一些POC扫描器里面没有的漏洞（如弱口令，手动狗头）。
我先用poc扫描器（xray青春版，poc-bomber等开源作品）对资产收集的结果进行了一番扫描，结果没有发现一个可利用漏洞（人少公司也不提供些打点资源，怎么搞嘛，狗头保命）。
没办法，只能老老实实手动地一个个分析哪些URL可能有惊喜了。
在翻了一大堆无聊的页面后，我目光锁定在了一个url上，这url的title是XXConfluence
当发现这个网站使用的是Confluence时，我想很多师傅们都知道该怎么做了。我立刻检测它是否存在RCE，经过一番尝试后，发现这个版本确实存在RCE，并且确认了服务器的操作系统是Linux。
接下来就把shell反弹到服务器上，发现已经拿到了无限制的shell访问权限。马上做了一个远程控制马并上传到目标服务器。MSF上线后我就查了一下网卡，发现这个服务器有个172.32.0.30的网卡，接着上传代理工具。
利用frp工具将内网暴露出来后，我们成功进入了172.32.0.0/24网段。
接下来，我和队友开始了正式的内网信息收集工作。
按照常规的习惯，用fscan工具来扫一扫，看看能不能找到一些弱口令或者可利用的漏洞，让我们的攻击更加顺畅。可是，扫描结果让我失望了，32网段居然没有一个可以利用的漏洞点。我只好用fscan继续扫172.16到172.31的网段，希望能有所收获，但是又怕扫的太猛触发了一些报警，于是就小心翼翼的进行着。运气比较好，在扫172.16段的时候，发现了一个F5 BIG-IP文件上传漏洞。
为了验证这个漏洞是否真的存在，于是构造了一个URL来测试一下，结果发现可以成功执行和回显。我心里暗喜，这下有戏了！
https://172.16.0.11/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
接下来的步骤变得相对简单了，我将反弹shell的代码上传到F5服务器上，并通过本地的NC监听来执行。这样，我成功获取了F5服务器的反弹shell，并且发现它具有root权限，这意味着我们可以在这台服务器上做更多的信息收集了，拓宽攻击面。
为了进一步探索这台服务器的漏洞，分别测试了它是否能够无密钥登录其他服务器ssh、检查了历史命令记录和一些运行中的服务，但都没有找到有价值的信息。后来想到由于这台服务器上主要运行着java程序较多，使用了一条配置文件搜索命令，希望能从配置文件中发现一些突破点。
find / -name "*.properties" -o -name "*.yaml" > ret.txt在仔细检索了多个文件后，我最终在一个叫做base_config.yaml的文件里发现了Redis和MySQL的密码。可是，当我尝试登录这些服务时，并没有找到任何敏感数据。而且最新的数据只更新到了2022年（此截图密码部分为笔者随机生成，不过与原密码长度相同）。
就在我思考是否应该停下来的时候，我突然灵光一现，想到既然Redis和MySQL的密码都是一样的，那么SSH的密码是否也是相同的呢？我立即使用Xshell工具尝试连接，令人惊喜的是，我居然成功连接了！接着，我开始思考是否其他服务器也会使用相同的密码，因为在内网中，很多管理员认为密码强度足够，所以会在其他服务上重复使用相同的密码。
在这里，将fscan扫描的172B段服务器的IP汇总到一个列表中，并使用爆破工具进行密码爆破。最终，我成功破解了47台服务器的密码。在使用Xshell手动登录时，我不得不承认，当资产数量较多时，手指会感到很累（手动狗头）。加微信hackctf55进渗透交流群。
以下是成功登录上的服务器
我正在手动使用Xshell登录时，收到了来自队友的好消息。他尝试登录172.32.0.81时，发现该服务器存在多个网卡。
并且在历史命令中，我们找到了管理员在该服务器上添加了一条软路由，将流量转发到10.54.0.0/19网段
我们立即决定在172.32.0.81上搭建一个代理，以便能够访问到10.54.0.0/19网段的资源
前置工作做好后，然后使用fscan对10.54.0.0/19网段进行扫描，我们发现了一个MySQL数据库弱口令：
[+] mysql:10.54.15.233:3306:root P@ssw0rd
在该数据库中，我们找到了一些敏感的数据，包括基础配置文件、车联网信息、车籍档案信息等。尤其是基础配置文件中，包含了各种服务账号和密码、nacos配置、云服务的secretId和secretKey等敏感数据。
既然已经获取了云服务secretId、secretKey，那就利用CF这个云渗透神器进行进一步的探测，配置好AK后发现权限为管理员权限
随后创建子账户，接管控制台
在登录控制台时发现拥有64台云服务器、13个mysql云数据库、3TB的对象存储、17个vpc网络等信息
这64台服务器在cf里执行命令都是root权限
此外，神仙队友还从存储桶中找到了几万人的联系方式、家庭住址、驾驶证、身份证正反面照片、车牌号等高度敏感的信息。加微信hackctf55进渗透交流群。
这样一来，本次渗透也基本完成了，48台物理服务器加上64台云服务器以及大量配置文件数据、开发环境配置、大量客户敏感数据，分数已经远超上线分了。
注意清理痕迹：在我和队友看到分数下来后就继续去渗透别的资产了，没有及时去跳板机上做清理痕迹，导致被溯源该单位成功复活，我们也相应地被扣了分数，损失惨重;
内网横向的时候一定提高速度，因为特别是有安全服务的win主机，一般报警都是有延迟性的，但是延迟性可能只有2小时、4小时、6小时等，所以一定要尽快地把资产梳理清楚，多获取路径分;
总结下本次攻击流程：
外网Confluence应用RCE --> 内网F5应用RCE --> 从F5服务器配置文件中获取到数据库密码–>将数据库密码对ssh进行密码爆破 --> 爆破成功的服务器的历史记录中发现逻辑隔离10网段 --> 找到数据库弱口令 --> 从数据库的nacos配置中获取到云服务具有管理员权限的AK和SK --> 进入核心业务内网-->找到核心数据;
多尝试一下密码喷洒，可能会有意外的收获;
之后我会多利用社工钓鱼的技巧，去获取目标的敏感信息，因为现在通过传统的技术手段去攻击目标的漏洞已经不太容易了。
- end -