道高一尺，魔高一丈

序言：

本文主要讲述我一个朋友公司所发生的种种安全事件，且一个比一个有意思，但因为时间有限，这次就介绍最近比较有意思且让人不禁赞叹的一个事件，接下来也希望读者带着攻防的思路，一起思考响应处置该告警事件是否有更好的调查取证思路以及怎么提炼规则加到现有的安全设备能力中，去排查是否有其他系统也存在同样问题。具体内容，我朋友是这样说的......以下内容将以“我"名词来代替我的朋友。

该死的安全管真多！

以下是大多数公司都会管控的一些点：

1）系统管理端口（22、3389）、应用高危端口（3306、1433）等不允许开放到互联网直接访问；

2）访问生产服务器需要通过堡垒机登录访问；

3）跨机房、跨区域需要申请开通网络权限访问；

......

    对于我或者其他的用户（开发、运维、其他人），有时想上个服务器，或者访问个业务，都得经过多次认证，有时需要通过VPN、再到堡垒机、堡垒机再双因素、再到跳板机、再到对应的服务器，流程麻烦的不行，但是安全就是这么要求，痛苦的不行，既然那么痛苦，那就绕过之，于是有了我朋友安全运营过程中发现的各种姿势：

1）以开通访问web应用端口（80、443，等）除了高危限制端口（22、3389、3306，等），然后等网络通了再把相关高危的端口服务改成已开通的访问权限的监听端口，如SSH服务改为80端口监听，那就可以直接公网或者绕过堡垒机访问了；

2）通过ssh -r 或ssh -l 等方式将端口转发至外部可直接访问绕过安全的限制；

3）通过部署VPN，然后使用正常的业务端口访问建立起隧道，使得两网间接的通过这两台服务器直接互通；

4）当然也有使用黑客工具（frp、nps、ngrok），是的没错除了黑客会用，自己人或者自己的服务客户也会为了方便使用这些

......

    上述的一些绕过姿势，也逐步在每次响应后不断的去完善和丰富安全设备的检测规则，去挖掘更多潜在的安全风险，这里就不继续罗列过多各种真实环境下绕过安全团队限制的姿势了，对于如何去丰富规则或者有其他有意思的检测规则可以后面与我探讨，接下来主要分享最近我朋友发现的一个更有意思的告警处置，又绕过了之前常出现的手法所制定的规则！

告警内容：

每逢快下班，经常都有事：

准的在快下班的时候发起了告警，告警内容是某个进程发起了提权的操作，初步通过进程内容判断是通过利用带有s权限的文件，在低权限用户下执行了root权限的命令。

处置流程：

 初次处置

    一般情况下，如果我们无法百分百确认该行为被攻击入侵的话，是不会直接对系统进行处置（隔离、封禁IP等），而是会先按以下几个步骤：告警是什么？告警是因为什么触发的？这种行为正常不、合规不？所以看到告警出现时，快速通过cmdb、脑海里的网络架构判断出是核心区域的某个设备，且有访问互联网的权限，故响应等级迅速拉升！快速电话联系用户，该用户还是我司的服务对象。

简单安全客服三连问：

 1、您好，这个进程是你们的程序嘛？

 2、刚刚执行了这个命令是你操作的嘛？

 3、这个程序是做什么作用的？（了解下看看是否存在其他安全风险或者是否存在合规问题）

    当得到了相关答复后，确认该行为确实用户手动触发且暂未发现其他安全风险，好了这个事情基本结束，但是因为这部分用户一直以来都搞出些意想不到的操作（各种代理转发绕过安全控制），于是出于还有5分钟下班的空闲情况下，对设备简单做了个检查，果不其然发现设备登录来源非堡垒机！

此时能想到的几个点：

 1、该用户也做了骚操作也绕过了堡垒机的访问控制

 2、不排除是用户某些监控程序自登录的情况

通过了一系列的简单排查：

 1）设备是否存在什么可疑的转发进程 （确认无）

 2）对外访问的进程是否有异常参数，如什么ssh -r 22:127.0.0.1:xxx xxx之类的命令（发现无）

 3）是否有VPN之类的软件 （无）

...... 通过之前的所有经验都确认无，于是因为到点下班的原因，且也无其他异常的原因，主要是因为无异常而不是到点下班了，暂定认为该现象可能是第二种猜测，就是用户有自登录巡检脚本。

再次处置

    原本想着这个事暂时也搞不定先搞别的吧，结果在吃完早餐没过多久，又出现同样的提权告警，正准备加白告警，然后关闭的时候，突然脑海一闪，昨天他好像说这个操作是他们手动执行的，对！手动！但是这么早运维应该和我一样也在吃早餐才对，没那么快帮他们登录吧（目前用户要登录需要我们运维协助）；问了下运维确实没帮他们，此时心想"传统美德"，肯定又搞转发之类的了，

此时有两个方案供我选择：

1）抄起电话与用户对峙，你是不是搞了转发啥的啊，怎么可以直接执行，不通过堡垒机？然后等他答复。

2）选择不相信对方任何行为和言语，就认为他乱搞了，亲手排查，眼见为实！

    此时我不是为了省事选择1，而是选择了方案2，因为人与不熟的人之间怎么可以有信任呢！如果他答复不是他搞的，可能是自动的吧，那就很被动了，只能选择原谅了~于是找运维再次上机！

    由于用户想要直接登录，那么用户肯定需要通过某些手段与外网通讯，才可以使他在公网可以直接访问，于是主要就是定位与公网有通讯链接的进程。

    发现确实存在一个程序与外网有通讯，但是查了下相关申请流程，看起来貌似正常的业务请求，且进程后面传的参数是一串字符，也不知道是啥，但是看起来不像是什么22、或其他反弹shell之类的脚本；但是继续保持怀疑，1）搜寻全机与该进程有关联的文件，看看是否有配置将ssh服务端口映射出去的行为；2）按往常处置经验排查ssh_config、hosts解析等其他的配置...果然！毫无收获，陷入困局。

    此时回去选择方案一，然后选择相信，然后加白告警，关单一定很舒服；但是有种干安全的被非专业的脚本小子摩擦好像有被冒犯到，而且人家还会用s权限文件提权，这个程序一定也有古怪。于是...

逼上IDA，现学现卖：

    听我朋友说，他做出这个选择的时候内心斗争了很久，因为一旦碰上一定要花费时间调试且还要现学现卖（之前只看过，没实操过），最终还是秉着打破砂锅问到底的精神，去吾爱现下载了一个！

配置远程调试：

一、被调试程序的服务器运行ida带的模块

二、本地配置远程调试参数

三、万事配好，开始现卖

      运行起来后F5查看伪代码，然后对对应的位置F2做断点，看看传参进去后做了什么操作

      发现传进去的参数后，被分成两块，然后各自传参进去，根据我短暂的渗透测试练习生经验，时16进制，分别转换为10进制后，就是该进程对内监听和远程链接的两个端口，一切好像准备要水落石出了！

      但是连接了？又如何，那他做了啥呢?重点关注到了咱们反弹shell经常会关注到的一个点

       这段伪代码想要看到大概需要了解下fork函数的作用，大家自行百度下，但是如果不懂的话也没有关系，断点到最上面进入判断的地方，改改参数，让他跳进去，然后看看服务器会有什么反应！

......

      经过了多次的百度怎么改参数和摸索后终于进入（具体细节就不继续详细浪费篇幅了，有机会再一起学习）

      以前用户都是用网上自带的frp或者其他简单的方式来转发直接登录和执行命令，这个用户玩出新高度，自己写上了类似木马的程序，然后玩起了反弹shell。回过头想想，如果我不坚持逼上IDA，安全就被当游戏玩了（Game on!!!）

至此，这个事件就差不多水落石出了，可以交差了。

感悟：

       经过我这个朋友的事情，逼着自己接触和学习了IDA，不禁感叹到，非安全或者说攻防领域的用户都不断轻易绕过着你的安全防线，那么对于真实的黑客攻击，我们又是否能防得住呢？

      对于目前正在干着甲方安全的自己还是得多持续的提升自己，很喜欢lake2的一句话“关注未知”是尽责的运营和优秀的运营的重要区别，也以此要求着自己需要去不断提升，去更多的“关注未知”，与大家共勉。

      同时，本次能有效的取证，得报着打破砂锅问到底的精神，多问自己几个为什么？往往在这个过程你能收获更多也能发现更多的问题，不要把自己做成了仅会沟通的“安全客服”。