一个完整的项目流程图，一个完整的项目流程图包括？

0x00 前言

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

项目特点：

1、目标以正常的生产状态参与项目，没有事先准备。

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

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

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

0x01 外部打点+撕开口子

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0x02 误入歧途+灵光一闪

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

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

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

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

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

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

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

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

0x03 权限通杀+意外之喜

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

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

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

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

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

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

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

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

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

0x04 未完待续

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

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

还有其他的问题：

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

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

0x05 权限初掉+打怪升级

因为目标的系统和数据架构都很复杂，数据量也比较大，为了避免惊动目标，此时并没有一次性把全部数据都拖回来（也是没想到后面数据库权限会掉）。

当时根据客户要求先弄回了部分比较重要的表。然后自己就结合后台功能对数据进行初步的属性和用途判断，是个很繁琐的工作。

大概拿到数据库的几天后，在我对后台做一些操作时，突然发现数据库连不上了，再过几分钟发现后台也没了！ping 了一下数据库和后台应用两台服务器发现是关机了。当时吓得我还以为是我把服务弄坏了，后面才得知目标这两台服务器就是会定期关闭的，极少部分时间才会开机做测试。

这是项目的第一次波折，没了数据库权限的我继续在内网中漫无目的的飘荡：登录服务器收集信息，用浏览器查看占用端口的应用，了解源码功能，批量扫端口……这个过程又持续了很久很久，过程中我对目标的系统和内网的了解逐步加深。

就像游戏里的打怪练级一样，每一天的探测都会让我增加很多经验值，终于经验值足够的时候，就可以升级了——经过N天的探测后，我摸清了内网的测试应用服务器的位置，同时发现他们中的大部分使用的是阿里云的rds数据库。

即使从配置文件中获得了账号和密码，rds数据库也是远程连接不上的，后面我自己去阿里云开了一台数据库，了解了一下基本配置后发现数据库需要设置ip白名单后才可以对外网映射端口，但我当时也是挂着目标内网的代理去访问的，怎么会受到白名单限制呢，这个问题卡了我几天几夜。

突然在一个快下班的周五，也许是经验值够了，我突然灵光一现的想到：即使是目标的内网，可能不同的网段，或者不同的服务器出口ip也是不一样的。后面打进了目标的路由器才知道，能连通他们数据库的出口ip只分配给了大概五台服务器，验证了我的想法。

不过当时没有路由器的权限，并且已经探测许久，士气有些许低落，但我还是打起精神去尝试了——登录他们某台应用服务器，新打了一条nps隧道，然后连接这条隧道再一次尝试远程连接阿里云数据库。突然就成功了！数据虽然仍不是实时的，但是比之前那个还新。于是那个周五我搞到了晚上十一点才回家……

0x06 权限二掉+权限尽失

有了第一次的教训，这次拿到数据库后我几乎是马不停蹄的dump数据，果不其然，一个周末之后数据库就又没了。登录内网的应用服务器看应用日志，发现它们自己也连不上了。

后面得知因为目标的生产环境不在内网，所以内网这些应用只有在产品更新之前才会短暂的连通数据库进行测试，产品上线成功后内网这些应用就处于停滞状态，开发人员平时用的是内网的另外一批应用，它们用的是内网中数据特别老的那几台数据库，对我们没什么价值。

不过这次对我的打击并没有第一次那么大，首先我差不多已经dump下了70%的数据，其次做过GA项目的师傅应该清楚，此时已经不再需要我去获取权限了。大概一个流程的时间（两周），我被客户要求不要再惊动目标。

于是这段时间，我就安安静静的继续探索目标的内网（只登录服务器，不登录应用）。不同于之前找数据的目的，这次的探索的重心是摸清目标组织架构、人员信息、源码信息等等。现在回想起来，其实还是一个简单的打怪升级的过程。岁月静好的这段时间让我没想到后面还会有一场和管理员缠斗的血雨腥风。

记得那是一个快下班的周一，突然我发现我在目标内网打的所有隧道全掉了！最开始用于打入内网的xxl-job也不见了，留了pam后门的外网22端口也不通了。当时还抱有一丝侥幸，因为我还在几台服务器上留了计划任务后门——在每天上午的固定时间向我的vps反弹shell。于是我就按时下班了。

第二天上班，早早的登陆vps开启监听，结果过了当初设定的时间还没收到shell，这是我才迟钝的感觉到事情有点不太对。又经过一小时的确认，我终于站起来和老大说了一句：“XXX（目标名）的权限全没了……”

虽然客户那边可以搞定数据的问题，但目标系统架构复杂，数据混乱，之后还是需要内网的一些权限的，不然很难搞定这个项目。

将近两个月的探索，我对目标内网的熟悉程度都可以去面试他们的运维了，结果现在“啪”的一下就没了，沮丧情绪是肯定有的，但渗透工作就是会这样一波三折。能承受灵光一闪获得权限的意外之喜，就要承受突然之间权限尽失的意外之痛。经过一分钟的冷静之后，我重新开始了外部打点。

0x07 百折不挠+如影随形

一天的打点一无所获，下班后去食堂吃了顿饭，回到工位看着电脑，鬼使神差的进行今天的最后一次尝试：再扫一次目标外网ip的全端口，结果发现那台熟悉的xxl-job又出现了！同样的默认密码登入，十分小心又熟练的再次getshell，进到内网发现通杀密码没有改，赶快一条一条恢复了所有的隧道。

做完权限恢复的工作，开始翻看服务器各种日志了解权限丢失的原因，才知道自己遇到了几年不遇的突发情况——目标内网所有的服务器都关机了一遍，直到一天之后的现在才重启回来。众所周知，服务器一般是不会关机的，之前探测内网的过程中我也看到目标的服务器已经连续运行几年了，所以打nps隧道时没有考虑到这一点，是直接运行的，关机后就断了。

得知原因的我又去多打了几条隧道，不同以往的是这次的nps隧道是注册成服务的方式运行，可以实现开机自启的效果。同时去复查了一下之前留的计划任务，发现还在，看来管理员并没有发现我的存在。因为已经搞到差不多晚上11点了，做完这些工作后我就下班回家了。

没庆幸多久，第二天上班我发现隧道掉了一条，xxl-job又不见了。通过还在的隧道进入内网翻看服务器上管理员的history，发现管理员在某台机器上发现了我留的计划任务后门，采取了应急措施（关机）导致我的隧道断了一条。

不过这个管理员并不是安全人员（上周文章判断目标没有安全人员），只是一个运维，对安全应急响应似乎了解的不多。

他只是一台一台的登陆检查计划任务，查到的就清除计划任务并重启，同时关闭了内网对外网的一切端口映射，其实并没有发现我留的隧道。而且因为我每次登陆后日志清除的很彻底，他也不知道我到底干了什么，掌握了什么信息。我甚至可以和他登陆同一台服务器而不被发现。

那一天，我就跟着管理员的步伐，维持了我全部的隧道不被断掉，同时悄悄登陆他们的路由器，重新对外网映射出一个留了pam后门的22端口。计划任务后门我没再留了，因为这已经是目标运维的排查范围，重复留的话意义不大。

如果这个管理员不是运维，而是安全人员的话，我现在应该已经凉了。但很可惜，这个管理员并没对我造成太多麻烦，反而在这一次风波后帮助了我打入生产环境。

0x08 求求你招个安全吧

经过一天的梳理，我列举一下计划任务后门被管理员发现后，管理员采取的措施：

1、关闭对外网的所有映射端口，但是没再去检查路由器，同时没有关闭路由器自己的映射端口。

2、一台一台的排查计划任务后门，但没有排查到nps隧道的存在。

3、更改了部分服务器的ssh端口，但没有改密码，是的，一台都没改，还是通杀。（改端口能拦住黑客？）

4、使用ansiable工具辅助排查，这个工具具体是什么原理我不太了解，只知道运维把服务器的ssh账号密码写在了一个文件里，让工具去读取，然后实现批量登陆执行命令的目的。

5、文件记录了生产环境的阿里云服务器的账号密码，通关！

就这样，让一个运维去做安全人员的工作的结果是：不但制止不了攻击者，反而给攻击者提供了更多的便利。只有安全人员才会真正的重视安全。

0x09 收尾工作

权限稳稳的留住了，之后没再出什么差错。客户那边的流程也走完了，之后就进入了复杂枯燥的数据分析过程。最后再分享两个tips和一件趣事吧：

Q1：运维人员只记录了生产环境部分服务器的密码（生产环境密码非通杀），有一些没有记录密码的服务器却又需要登入，怎么办？

A1：目标生产环境有一台跳板机，运维人员通过这台跳板机去ssh连接其他服务器，在这台跳板机上留alias别名后门即可抓到ssh连接使用的密码。

Q2：目标内网非域架构，但后期项目需要拿到目标财务人员办公机上的文件，怎么通过服务器打入特定人员的个人机：

A2：登入目标生产环境的后台，找一个只有财务人员可见的板块，但是没找到，只有一个板块部分符合要求——所有财务人员和一个运维有权限可见，于是去生产环境数据库把运维的权限改没，就变成了只有财务人员可见。之后在这个版块留xss水坑攻击，引导访问此板块的人员下载木马，成功钓上来一个财务，拿到了其个人机的文件。

3、趣事：我在探测内网时拿到了目标公司的摄像头总控权限，可以直播观看目标公司日常办公、开会和员工摸鱼的全过程。

0x0a 后记

欢迎关注小黑，以后会继续给大家分享我在工作中的实战经历~

如果我的分享对你有帮助，可以在下面赞赏鼓励！

END.

喵，点个赞再走吧~