攻防实战 | 一次钓鱼到快速打穿

一次钓鱼到快速打穿

由于微信公众号推送机制改变了，快来星标不再迷路，谢谢大家！

背景

21年中旬的一个对某互联网公司的红队项目，为期5天。客户要求最终能获取堡垒机权限，客户安全部门全部人员投入对网络进行防守。

前期信息收集

fofa、quake搜寻子域名、证书、高命中C段，到处信息寻找可以快速getshell漏洞，theharvester邮箱搜寻。最终在高命中C段资产中找到一个gitlab并开放注册功能，在公共仓库中找到了一个邮箱账户密码，但是密码已经失效，不过知道了客户工作人员使用的是第三方163企业邮箱，后来在hackerone上找到了cve-2021-22205漏洞，该漏洞当时国内各大公众号并未发文利用，在21年10月中旬下旬国内各大安全公众号开始披露报告，打了一个信息时间差。

项目过程

利用cve-2021-22205 ExifTool打进gitlab，打的过程中弹shell发现弹不出来（在这个时候其实已经被设备捉住了），后来利用openssl加密弹的shell。使用linux的C2走CDN控住以求隐蔽控制并权限控死。

拿到权限后直接进入gitlab的data目录，该目录存放了全部代码，利用grep快速查找关键词在该目录搜寻到了一个代码中存放的邮件账户密码，该密码有效登录了163企业邮箱，但是在搜寻邮箱中邮件的时候发现gitlab已经被下线，C2中的session也直接断掉了，机器已经断网。从控制gitlab服务器到下线，中间时间不超过5分钟，至此权限丢失。足以可见防守方没有在进行摸鱼，也在积极的与攻击队对抗。

外网除了这个gitlab以外无在发现能进入内网的点，没有进入内网的点后我们将目光转移到了手上的邮箱账户上，该邮箱为监控服务状态邮箱，会定时接收应用状态error信息以及服务器运行状态等，除了群发的通告邮件外无与工作人员单独来往邮件。但是该邮箱可以看到全部通讯录，我们导出了开发/运维人员的邮箱准备进行钓鱼。

时间临近端午节，就以端午节展开文案进行钓鱼，找写马的同时要了写好的马，免杀+捆绑+ico替换。不捆绑的话对方点击后无弹出有效文件对方就会警觉，毕竟钓的是开发/运维也属于专业人士了。马采用winrar压缩加密并且采用超长文件名，超长文件名在winRaR的默认显示中不会显示后缀，只会在后面状态中显示为应用程序，大部分人会直接在WinRAR中直接点开邮件信息。（现自建邮箱大部分会有现邮件网关并且会自动搜寻邮件正文中的明文对邮件进行解压放入沙盒，但是163企业邮箱好像并没有该功能）。

选择时间在中午13:50发送，该时间点大部分人刚午休结束，还没进入工作状态。脑袋转的不是那么的快，大部分还属于刚睡醒懵逼状态，对邮件这种通讯信息会掉下戒备心并且随意点开看看信息就忘了此事。

邮件发送后陆续上线10余台机器，均为运维/开发，价值很高。

上线后不能胡乱操作，先确定好该机器的防护情况，不然一个误操作可能导致员工察觉到异常，机器下线上线。后拿了处理过的frp直接上线进入内网（去特征+CDN），我们对其中一个机器进行了导出浏览器凭据，获取了dap认证的账号密码，后发现该内网无域，采用了openldap。

根据对上线机器的信息手机获取到了内网多个应用，其中我们将目光放到了wiki上。

其实看到wiki以及/login.action的时候我就知道只是个confluence，当时脸上已经开始乐了。众所周知，confluence为互联网公司用的比较多，像运维/开发等空间又往往存放了大量的敏感信息，资源拓扑，密码等。

并且大部分企业在使用confluence的时候没有做到合理的鉴权。随意一个通过认证的账号就可访问各大目录空间，比如你登录一个市场部的用户，正常来说，你能访问的目录空间应该只限于市场部。但是没有做鉴权就可以访问任何部门的空间。

在安全部门空间定位到了几个管网络安全设备的人。

并且获得了jumpserver堡垒机、一个疑似自研堡垒机、青藤云server的登录地址。

其中我们在运维空间发现了OA的登录地址，以及OA服务器登录密码、OA数据库账户密码。后与客户复盘得知OA是几个人在运维因密码复杂，为了方便就将密码放在了wiki里面。

有了数据库的账号密码，那就不用登录机器了，直接远程登录数据库。该OA是ekp蓝凌，用户账户密码存放在 ekp--dbo--sys_org_person中。

运维人员其中一人解密出hash后登录自研堡垒机，发现机器少得可怜，当时判断可能机器依旧还在jumpserver上管控，后续可能会全部上线到自研堡垒机中，但是该账户登录jumpserver的时候发现为密码错误。

后把信息安全部门员工的hash抠出来去解密。成功解密了两人，其他人hash未解出明文。

我们拿着解出来的密码成功登录的青藤云server控制端

青藤云是可以对所管控主机下发命令的，但是在前台页面去掉了这些功能，需要他们的API文档，可惜的是我并没有这份文档，但是我在任务系统中发现了一个有意思的功能点，读取系统文件功能。我们利用该功能读取了jumpserver堡垒机的history文件，在该文件中读取到了一个关键信息，jumpserver数据库的密码，运维在对jumpserver数据库运维的过程中在命令行使用 mysqldump -u root -p xxxx去备份数据库，在命令行中记录了明文，并且幸运的是该数据库支持外连。

使用该密码登录了jumpserver数据库，进入jumpserver数据库中的assets_adminuser获取到了所管控机器的加密密码。

该加密为jwt，直接去"jwt.io"解密即可。后看到大部分机器为同一密码直接使用工具低线程跑了下ssh验证了下，证明密码的确有效。

后我们通过数据库中的密码成功登录了jumpserver堡垒机的系统，通过jumpserver的Django中manager.py工具直接添加账户密码成功登录了堡垒机的web应用。通过堡垒机可直接管控6k余台机器，至此任务完成。

如果你对Deep Web感兴趣，"W不懂安全"公众号后台发送：“DeepWeb频道”。

三连加关注，追文不迷路。