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

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

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.


喵,点个赞再走吧~

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


版权归原作者所有,如若转载,请注明出处:https://www.ciocso.com/article/763.html

发表评论

登录后才能评论
跳至工具栏