一、 背景介绍

简单自我介绍一下，我是一个安全工程师，也是一个人的“安全部”。一个周五的晚上，我正在和小伙伴们在游戏中厮杀，还沉浸在躺赢快乐中的我突然接到紧急短信。
因为我重置过短信告警条件，只有行为出现漏洞扫描、入侵警告的达到触发值，才允许发送短信。所以我们接到短信后要立即回公司处理。

二、 评估

登录态势感知平台，一台服务器在疯狂发包，对内网主机发起扫描。直觉告诉我，这种扫描行为与正常业务请求无关，因为这个时间没有业务提交过排期，所以很可能该已失陷。
时间已入深夜，我匆忙的叫上运维同学来到公司定位失陷所关联的主机。可是奇怪的是这个经过之一眼的推测应该属于区域，因为这个区域的地址段是，为了更精准又去找的小伙伴一起确认。经过最终确认运维同学的记录中却并没有这个的记录。
这给我们排查添了大的麻烦，只能让运维同学找业务同学一起排查这个地址的归属。此时的我们是又累又困的。
排查陷入了僵局，因为从资产管理档案中，无法寻找到该主机的相关人员的登记历史记录。所以只能回到态势感知系统上翻一翻态势感知的信息。
通过关联攻击IP行为，发现该地址存在对线上的一台暴力破解。做信息安全的我之一时间猜想，是不是和这台服务器上的业务有所关联？
叫上运维同学和业务同学来到机房，由运维同事进入服务器系统检查。首先检查一下日志，此文件默认存放目录中。
从上述记录可以看到，有用户在试图猜测口令，时间分别在某年某月某日凌晨，地址来源分别是。检查端口，的信息也存在猜测口令记录。
经过初步判断，内网机器疑似遭受黑客入侵。攻击者入侵后扫描了内网弱口令进行横向移动的尝试，从图中的暴力破解可以感知到。
这个地址不属于服务器范围。我询问同在旁边的业务同学是否能够确定是哪个在使用这一个，业务同学不能确定。此时有点慌~因为出现了类似的“ *** 灵异”事件。
几经波折，终于在运维和业务同学的配合下定位到这台机器。原来是一个外包项目组用的服务器。
随后辗转战场，我们在机房里找到了这台主机。这台是由外包项目组实施项目的时候临时搭建，并未迁移到服务器网段，所以没有记录在我们的资产表中。由于外包人员不规范的操作，让我们错过了最宝贵的一段时间。

三、控制

当即通知业务将这台设备进行隔离，随后我立即把遇到的情况和处理结果通过邮件上报给领导。

四、消除

可是这台机器究竟出什么问题了呢？为了弄清楚真相，我们决定对这台系统进行取证分析。

检查进程

先用命令查看系统进程列表，显示如下：
只有3个系统进程正在运行，这很不正常。
通过命令列出目前系统上面所有可能被更改过的文件，如、、等命令已经被替换。
因为此前有过类似文件被篡改的经历，不想历史重演，所以在上线前运维同事就已经在目录下加密保存了一些重要的系统文件的副本。

开放端口分析

只有，端口对外开放， *** 连接层面正常。

账号分析

仅有一个用户具有root权限，未被注入超级权限。

可登录用户

只有两个用户可以使用SSH方式进行登录：、

可以看出账号层面正常。

定时任务

通过分析系统未创建定时任务

hosts 文件分析

文件正常。

启动项分析

启动项记录系统自启动的情况，若攻击者入侵植入木马或者后门，为了维持服务器控制，会在启动项中发现他的蛛丝马迹。

启动项无异常。
历史命令分析

History

历史命令被清空，等程序被替换攻击者对痕迹进行了清理，对系统排查似乎理不出什么头绪。我决定换一个思路，从上尝试突破。从日志排查。

Jenkins日志

异常文件

日志信息正常，但是我们找到了一些有趣的文件。通过分析这些文件，发现这是攻击者的使用的横向移动脚本，通过这些脚本进行横向移动。从这里可以确定这台已经失陷。

Jenkins简介

是美国公司的一套基于开发的持续集成工具。该产品主要用于监控持续的软件版本发布/测试项目和一些定时执行的任务。
通过分析，系统使用，查看配置文件分析，发现其版本为。
通过Google搜索响应漏洞，发现该版本重大漏洞，可利用，和组合，拿到服务器权限。

远程命令执行漏洞

使用框架开发，其允许用户通过来调用一次 *** 。由于这个过程没有做限制，攻击者可以构造一些特殊的来执行一些敏感的 *** 。
通过这个漏洞，我们可以找到很多可供利用的利用链。其中最严重的就是绕过导致未授权用户可执行任意命令：在沙盒中执行前会先检查脚本是否有错误，检查操作是没有沙盒的，攻击者可以通过的方式，在检查这个步骤时执行任意命令。
参考链接：

使用给出的poc，发送如下请求即可成功执行命令：

poc地址：

迷雾重重

到现在为止已经可以确定这台机器被入侵，因为从态势感知上关联的攻击行为和历史记录、日志文件被清理的异常现象来看这台主机已经失陷。
但是是内网的系统，并未放给公网，攻击者通过什么途径入侵撕开到内网的入口呢？对此一筹莫展的我们决定下楼抽支烟顺便理一下思路。
由于放在区域，最有可能的攻击路径有两条：

1. 通过钓鱼入侵：攻击者已经拿到办公网机器，入侵到。

2. 通过外部服务器：攻击者通过外部漏洞拿到应用服务器权限，横向移动入侵到。

云开雾释

当即我们兵分两路，对邮件服务器和下可以访问公网的服务器进行排查。还真让我们有了新的发现，发现一台服务器存在反连外部恶意域名的行为。排查并没有发现异常邮件，那么这一台服务器就有可能存在问题。

夜尽天明

登录这台服务器查看日志，发现尝试疑似木马后门上传，但根据日志中状态码反馈，均已反馈失败，猜测这台服务器可能已经被攻击者攻破。随后我们对这台机器进行溯源。
攻击源统计如下：
攻击者
上传木马失败日志
攻击者通过威胁情报反馈如下：
读取访问日志，发现攻击者尝试痕迹
控制服务器日志
分析控制服务器日志，发现利用反序列化漏洞经常出现的几个异常
类
类
反序列化缓存文件
这个是网上的一个轮子，刚好入侵者是没有去修改这些特征。
附带链接：
*** 反序列化文件
通过检测控制服务器发现漏洞。
定位到的黑客攻击路径为：
通过一夜的努力我们终于可以大致梳理出攻击者的攻击路径，攻击者通过外网信息收集，探测到公网服务器存在反序列化漏洞。上传失败后，攻击者在尝试横向拓展驻留点过程中发现了我们未打补丁的服务，通过服务发起了内网扫描。

五、 恢复：加固工作记录

首先将升级到最新版本，对漏洞进行修复。再将访问权限设置为办公网有限权限访问。
控制服务器，我们决定采用重装系统的方式。

六、总结分析

此系统因为是临时启用，内网仅有jenkins服务访问权限，因为使用数据才临时启用一周，未经过安全审批，未及时同步信息。

服务对应内部IP为，目前对互联网仅开放其，，端口，端口只能通过内部访问。

服务部署的纯内网服务器，未更新安全补丁。

系统账号正常。

*** 连接情况正常。

历史命令曾存在手工清除痕迹。

定时任务正常。

启动项正常。

日志正常

系统层面黑客使用的脚本。

结合记录，通过入侵方向推演，攻击者通过信息收集发现公网服务器存在反序列化漏洞。以反序列化漏洞为入口，入侵后对进行攻击，获得权限后尝试横向移动过程中触发告警。

七、复盘反思

安全团队和业务团队之间有高效的沟通机制和较强的合作意识。

提升内部安全意识，及时关注各补丁推送。