首发于奇安信攻防社区
文章地址：https://forum.butian.net/share/896
2019年的7月份左右，朋友那边所在的企业收到了来自监管单位红头文件的通报，称其网站存在异常的违规内容估计是被入侵了，并火急火燎的要我帮忙康康，又鉴于与他在校时同为最好的朋友便答应了下来。
据朋友口中得知，他们的企业网站之前是委托第三方外包公司搭建的，维护的话建设好了几乎就没有什么维护了，平时也都是他们负责文案的同事只是上后台更新更新文章内容而已，合着业主手里就有一个网站后台的权限，后面让朋友去沟通费了蛮长时间也才得到一些基本信息和网站源代码和access.log网络访问日志。
网站部署在的是阿里云上至于是虚拟空间还是独立主机也不清楚，主机杀毒也没有更别说网页防篡改等其他的安全服务了，后面问了朋友要通报里的图片一看，看得出style.php页面上的内容乱七八糟的指定是被篡改了。
将朋友发过来的整站源码解压后，发现在通报中的style.php文件不见了，去问了朋友才知道因为怕处罚那边就第一时间把通报的文件给删除了，这就很蛋疼，但问题不大像这类的网站篡改的尿性index.html首页文件肯定也逃脱不了黑帽的魔爪，排序下时间果然index.html的修改时间为19年7月22日12点27分与其他页面的时间是截然不同的。
下面用文本编辑器打开index.html文件查看内容，果然啊一眼看得出在标签和keyword关键字处经过了unicode编码转换，这时候我们在去站长工具那的在线编码转换把unicode编码转换成中文就一目了然了，正常的网站标签这大多都是网站的自身介绍是不会有这些涉Du的信息的，所以该首页面已经被恶意修改了，那为什么页面篡改大部分又偏偏只修改的是首页的这几行内容呢，其实各大的搜索引擎的蜘蛛爬虫需要爬取的也是这几行内容去做搜索引擎的收录，所以那些黑帽植入的Du博链接网站从而提高他们网站的收录和访问量，受害者也变相性的帮他们做了推广。
确定了篡改的时间为7月22的12点27分，下面就用D盾webshell查杀工具在杀一遍看看网站中是否还遗留有后门文件，果然查杀出来upload.php、tyuhsdb.php、botright.php三个可疑文件。
其中tyuhsdb.php、botright.php这两个都为大马文件，而upload.php是仅具备上传功能的脚本文件，但仔细一看tyuhsdb.php和upload.php的修改时间都为2011年，这与事件发生的时间相差过于久远，难道这又是一起长久的遗留后门文件的问题？
进入到imagesswfuploadimages目录下查看upload.php文件，在通过对比官方的源码的目录中并未发现该目录下有upload.php这个文件的存在，在看其的创建时间为2019年7月10日11点52分但修改时间却为2011年的，可以很确定入侵者为了掩人耳目把修改时间调整为与目录中其他文件的时间相同，这就给人一种以为该文件是源码本身就自带的错觉。
按照以上的特性，咱们也来看看tyuhsdb.php、botright.php这两个大马文件的创建日期是多少，这样好方便后面筛查日志的时候好做溯源，图中可以看到这两个大马文件都被转移到了images图片目录下，botright.php的创建时间是7月10号12点01分的，tyuhsdb.php创建时间是7月22号12点49分的。
根据以上知道了这三个后门文件的创建时间，我们知道了upload.php是最先被生成上传的，下面就根据upload.php这个文件进行对照日志的筛选看看这个文件是如何产生的，因为朋友发过来的access.log日志是以增量产生的数据，所以足足有260MB的文本文件这里推荐一款EmEditor编辑器，即使渣渣的电脑也能秒开上G大小的文本文件。
因为如果直接搜索upload.php这个文件名的话那结果会想当的多，而且upload.php大部分是正常网站的一些上传脚本有些可能不是恶意的，所以就带上绝对路径进行查找images/swfupload/images/upload.php，看得出在该文件的前一条访问记录是由/include/ckeditor/images/multipic.php这个文件POST数据产生的但目前这个目录下已经不存在这个文件了，应该也是个大马文件可能被利用后删除了，upload访问的时间也与创建的时间7月10号11点52分对应得上。
继续往上搜索multipic.php文件是如何产生的，虽然本地文件被删除了但日志可都会还记录着的，multipic.php是在11点49分的时候由/plus/task/xadsb.php目录下的这个脚本文件产生的，而且这个文件本地也是不存在了可能又被删除了，继续往上走！
再再往上看看xadsb.php文件是怎么产生的，天呐！又是由/data/enums/inbox.php下的文件产生的而且这个本地也被删除了，但从流量记录日志上可以看得出他利用了inbox.php逐层的进入到task/目录下最后上传了xadsb.php文件，因此就不难看得出这也是个后门文件了。
不要气馁！继续往上翻inbox.php文件，到这里往上一条记录是由plus/mytag_js.php文件产生的，而且这部分的记录都是同一个IP所为，并且在7月10号10点28分的时候不止生成了这个后门文件还生成了其它大量乱七八糟的脚本，而且细一点的小伙伴就看得出生成的时间都是毫秒的间隔，千真万确就是利用工具批量生成的。
以上知道了入侵者很可能就是利用了工具进行批量的植入木马，所以不妨大胆的猜测plus/mytag_js.php这个脚本文件会不会是应用系统的漏洞点呢，当我想进到目录去看看这个文件的时候，好家伙这个文件也不存在了这是利用完了就断了路了吗，不慌直接把路径带上脚本跟参数丢到搜索引擎去瞧瞧，果然没猜错直觉还是很靠谱的这是个老洞了，程序也是个老版本了也不难怪会存在怎么老的漏洞。
经过以上最终定位到了mytag_js.php这个脚本文件，而这个脚本在dedecms的5.7版本以下都存在变量覆盖的漏洞，而这个漏洞利用方式是通过往数据库插入恶意的语句后执行这个脚本带上参数就可以生成恶意文件或者更改管理员密码的操作，接着搜索mytag_js.php文件的流量情况，在7月10号的凌晨5点09分时执行了插入数据的操作，并通过JavaScript在线工具对该exp进行解码。
通过以上分析已经确定了此次的漏洞利用的IP是哪个，下面继续分析首页文件是被哪个后门和IP利用的呢，对于分析出的那些后门文件进行逐个的全部筛选，最后在botright.php这个后门文件下发现142这个IP在7月22号12点27分的时候打开的index.html文件并在28分时修改了文件内容，时间点都与前面index.html修改的时间相对应。
通过上述的分析，结合目前还留存的丁点后门文件，通过对比现有的日志文件一步一步的去分析它们其中所产生的关系，从而揪出问题的源头。
事情到这里也简单写了份报告给朋友交了差，同时也叮嘱朋友告诫他们老板不要找这么不靠谱的第三方公司，只管搭建不管运维就算了还拿满是漏洞低版本的cms来搭建，最终受罚的还是责任主体得不偿失啊，请第三方搭建的费用估计都没罚得多。
点赞 在看 转发
原文始发于微信公众号（HACK学习呀）：实战｜记一次某企业被入侵的远程应急响应
