一日，某公司接到来自监管单位的通报，表示该公司的网站存在S情违规内容……于是乎我又得出发了，先是向客户要到了网站的地址先看看哪里存在违规的内容，一顿乱翻网站上的子页面都显示正常，回到首页按下F12果然网站的关键字标签那被修改了。
拧着我的小电驴到达现场后，开始跟负责网站的管理员进行谈话了解当前的网络情况，当前网站呢是部署在四川西部数码服务商上的，租用的是虚拟空间并没有登录服务器的权限，平时维护更新文件是也都是通过FTP进行上传更新的，而且也未购买什么安全防护。
因为网站首页文件已经被修改了，所以我们看到index.html的修改日期为6月28号19:08分也就是在此时发生了篡改，值得注意的是当我们需要将FTP上的文件进行下载到本地电脑查看时，需要将虚拟空间上的源文件都打包成一个压缩包在下载下来，不然使用FTP一个个下载下来时文件的修改时间将是下载的当前时间，这样会对后面结合日志分析的溯源工作带来一定的困难。
当页面被恶意篡改，那说明网站的控制权已经被获取了，而修改的内容为首页的源代码文件说明获取的权限比后台管理员拥有的权限更大可以随意的更改源代码，但也不排除有些网站的后台管理功能也是具备编辑网页的源代码的，所以说那网站上肯定是被黑客上传了后门文件。
下面咱们就使用D盾webshell专杀工具选择网站的wwwroot根目录进行一个全面的查杀看看黑客一共上传了多少个后门文件，可以看到共检测了5731个文件其中6个文件：radminpass.php为dedecms的管理员重置脚本，config.php、buak.php、lower.php、pig.php、need.php均为大马后门文件。
细心的朋友这时就发现了radminpass.php这个密码重置脚本与其他后门的修改时间相隔了两年反而与网站内搭建时生成的文件时间不相上下，当时我也疑惑为什么会不一样呢？还是先来看看radminpass.php有何作用吧。
radminpass.php是织梦官方发布的管理员密码重设工具，只需要将对应编码的radminpass.php文件用ftp上传到到网站根目录，并访问该文件(例如：http://www.xxx.com/radminpass.php)把域名更换为自己网站的域名进入密码重置界面。
啊这……直接访问脚本修改了admin的管理员账号密码并不需要输入旧密码即可修改，随后询问网站的负责人才得知，早期的时候忘记过密码并使用了这个重置密码的脚本修改了密码，至于当时自己修改后有没有删除脚本早也没了印象。
到这里思路就比较明朗了，前面知道了首页发生篡改的时间为6月28号19:08分最早上传的config.php后门文件为6月27号16:24份，根据这个时间点筛选6月24号至6月30网络日志进行分析，搜索radminpass.php的流量发现早在24号时就有人访问了，但在27号8:21分开始时只有一个1.206.x.x的IP访问GET请求后又三步POST数据提交的操作，很像前面的改密三步曲，所以此IP为攻击者的嫌疑最大且与网页被修改的时间最相近。
根据分析到嫌疑IP1.206.x.x在进一步的筛选日志，可看到改IP的所有操作行为，先是利用密码重置脚本修改了密码，随后马上访问了/tmcmspc56/login.php后台界面进行登录下一条的/tmcmspc56/index.php说明已经登录成功。
前面知道了网站上存在最早的后门文件为config.php，一样的对流量日志进行筛选config.php瞧瞧它是如何被上传的，可见攻击者先是访问file_manage_view.php文件后往下接着一条POST数据从而产生了config.php文件。
回到网站文件目录查看file_manage_view.php文件，好家伙这是一个管理后台的文件管理编辑器，攻击者是直接在后台添加生成了个大马的后门文件啊这是。
下面看看其他的后门文件是如何被上传的，依据时间顺序搜索buak.php后门文件看得出是通过config.php上传的。
继续搜索lower.php后门文件，是由app.php文件上传的，但D盾并未扫出该文件到流量日志记录的路径下查看也并未发现有该文件存在，应该是已经被删除了。
那app.php又是如何上传又是哪个IP上传的呢，筛选app.php可见是有buak.php上传而来的。
只剩下pig.php和need.php两个后门文件了，在经过一轮的筛选need.php是app.php文件上传的，而pig.php后门文件并未筛查出，只有一种可能是攻击者上传后将原来的后门文件重命名成了pig.php。
IP为1.206.x.x的攻击者首先是在27号8:21分首先发现了radminpass.php密码重置脚本，并在8:22分修改了管理员admin账号的密码并且登录了后台，在8:24分时访问了后台file_manage_view.php文件管理编辑器上传了config.php的大马后门文件，随后通过config.php后门文件上传了buak.php后门，再由buak.php上传了app.php（目前已经删除），再再由app.php生成的need.php的后门文件（iis日志需加8个时间段即可对应正确发生时间），细心的小伙伴就发现了，每生成一个新的后门所连接的IP就会发生变化，其实原因很简单可以大胆的猜测这是一起webshell的买卖行为，一个卖另一个的。
综合以上的分析，此次事件的关键点在于运维管理人员的粗心大意导致了攻击者的有机可乘。
转自：hack学习呀
觉得文章有用就打赏一下文章作者
支付宝扫一扫打赏
微信扫一扫打赏
seo优化_前端开发_渗透技术
