渗透实战 | 耗时三个月的项目全流程（上）

#实战记录

1个

0x00 前言

之前做的一个实战项目，共耗时三个月，我参与了从开始的信息收集到最后数据分析的全流程。期间遇到并克服了许多困难与波折，其过程在此记录并分享给大家。

0x01 项目特点

是GA的项目，项目过程没有截图，做过类似项目的师傅们应该都懂，这里就讲一下这类项目的特点：

1、目标以正常的生产状态参与项目，没有事先准备，也不了解项目什么时候开始。

2、攻击过程不限制路径和手段。

3、以拿到目标的数据和人员身份为目的。

4、几乎无时间限制，比速度和权限更重要的要求是稳。

0x02 外围踩点

一开始拿到的是目标的公司名和官网的url，除此之外没有其他信息。自然首先要进行的步骤是踩点——信息收集。

经过几天的信息收集，我大概了解的目标的基本情况：公网上能访问到目标的生产环境和测试环境，目标有几个app都是套壳的，本质是调用了web端的api接口。

（1）生产环境：均部署在阿里云，收集到几个后台，一个官网，一些app的api接口域名（直接访问是403，404），每个资产有单独的外网ip地址。

（2）测试环境：和生产环境基本一样的资产，只不过都部署在同一个ip上，通过不同域名来反向代理，不是云服务器，后面发现是目标自建的机房。

（3）人员信息：从目标官网的新闻动态和招聘网站上，收集到公司大体的人员架构——姓名，职位，部门。

0x03 撕开口子

外部信息收集的差不多的时候，就顺其自然的可以打入目标内网了。之前发现目标测试环境都在同一个ip，扫该ip的全端口，在9999端口上发现一个xxl-job分布式任务调度平台，xxl-job的作用大概是能远程控制很多机器定期自动执行某些任务，这些被控制的机器称为执行器。

用默认口令 admin/123456 进入xxl-job后台，后台可以添加GLUE(SHELL)计划任务，但这个感觉是废弃或测试的资产，里面只有一个执行器还是它自己。

通过后台添加计划任务反弹shell，拿下目标内网一台linux服务器，普通用户权限。首先没有尝试提权，提权exp有可能导致系统崩溃，只有一个入口的情况下要好好珍惜。

并且现在就算不提权也能做很多事情，在该机器上打nps隧道代理进入目标内网，虽然之前收集到目标应该是没有安全团队的，但还是因为刚进来不了解目标内网情况，没有进行大规模扫描（怂）：

我怎么通过前期信息收集判断目标是否有安全团队：

1、招聘网站和目标官网中没发现安全部门的存在。

2、信息收集过程中除阿里云自带的waf外，没见到其他安全措施。

3、xxl-job默认口令都敢放到公网上。

当然判断不可能说100%准确，我为了求稳，打算用手工探测内网80端口——就是在浏览器手动输入同网段的ip地址，从1-255……

0x04 误入歧途

255个没有全部输完，大概二十几个之后，发现了内网的gitlab代码仓库，其开启了注册功能，注册一个账号登入，里面只有两个项目，下载回来看了一遍没什么价值。

转变思路，收集开发人员的邮箱，去sgk查密码，拿到了其中一人的手机号和通用密码，然后社工撞库，一系列流程过后，收集到了他大量的信息，并登入他的微博，看博文的小尾巴得知其手机品牌，最后登入他的对应品牌的手机云盘。

这种云盘登录后是不能直接查看信息的，还需要手机验证码二次确认，但我手里有这个人的大量信息，直接套路客服更改绑定手机号获取到访问权限，不过里面没发现有用的东西。

一般这种情况我们称之为：打偏了。

0x05 灵光一闪

重新把重心转回内网，感觉还是要从gitlab下手，之前里面没什么东西可能是注册的账号权限不够。

准备字典爆破gitlab其他用户名，用户名字典除了用收集的人名生成，还把前期收集到的域名也放了进入，最后发现其中一个域名作为用户名存在，再爆破它的密码就是简单的域名+123。

爆破时使用针对目标信息生成的字典是很有必要的，之前我写过一篇人名字典生成的脚本：《分享 | 人名字典生成脚本》

言归正传，用该账号登入gitlab，果然发现了大量源码，拖回来看了三天，收集到了内网的一个业务数据库权限和大量redis权限，但是业务数据库里的数据比较老，差了两年多。

0x06 权限通杀

先放下数据库不管，随便挑了一台redis，写计划任务getshell，发现是root权限。关于redis的getshell方法我之前也写过一篇文章：

《实验|CentOs下Redis漏洞利用方式复现》

在root用户的.bash_history中发现明文口令，然后碰撞发现基本通杀了目标内网的所有linux服务器，不过不能登入生产环境的阿里云服务器。

用这个密码在目标内网开始探测，基本流程应该是：登入linux服务器，看上面运行了什么东西，从数据库中或配置文件中收集目标信息和用户口令，然后带着收集的信息再继续碰撞下一台……

当时做项目的时候没什么经验，在目标内网数百台服务器中迷失了方向，每登入一台服务器都要看好久，把有用没用的信息和文件都拖回来分析。如果换成现在，我会关注自己最终的目标是数据，收集的信息应该是明确的和数据库相关的——应用配置，数据库端口等，这样效率会高一些。

0x07 意外之喜

当时我大概登了五六台机器后没什么大的收获，这时突然想起来应该做一些权限维持了，目前权限维持就只是打了几条隧道而已，如果被管理员发现直接ban了nps服务器的ip那权限一瞬间就全不见了。

通过咨询身边的大佬，我选择了pam后门进行权限维持，pam后门：重新编译并替换服务器上ssh连接鉴权所用的一个文件，之后便可以在不影响ssh正常使用的情况下用自己的后门密码登录服务器。

因为之前收集到目标外网的测试环境的ip是开了一个22端口的，所以选择了这个方式，以便在内网权限丢失的时候能重新打入。直接用通杀的密码连接这个端口，进到内网的又一台机器上，在上面留下了pam后门。

这时顺手又对这台机器进行信息收集，意外的发现了一个运维脚本，里面记录了内网另一个网段的一台业务数据库的ip和密码，连接后发现虽然数据仍然不是实时在用的，但是很新，于是根据这个数据库的连接情况反查到内网的核心后台，在数据和源码都在手的情况下开始向客户交付。

0x08 未完待续

拿到了通杀内网服务器的口令，又发现了可以交付的数据，看似这个项目已经快结束了，但其实这时才只过了一个月而已。在之后长达两个月项目过程中，手里获得的数据库权限经历了三次波折——得而复失，失而复得。

中间甚至遇到了一次几年不遇的突发情况导致内网权限尽失，并且惊动了目标运维人员。后面会记录我如何和管理员斗智斗勇恢复并维持权限。

还有其他的问题：

1、怎么打入生产环境拿到最新的数据。

2、目标内网非域架构，如果非要不可，怎么拿到关键员工的个人机权限（财务，运维等）。

0x09 后记

字数差不多了，这周就写到这里，后面的过程下周再继续更新，欢迎关注~

我才不会说是为了能再水一周的文章

END.

喵，点个赞再走吧~

渗透实战 | 耗时三个月的项目全流程（上）

0x00 前言

相关推荐

发表回复