这篇文章已经过某师傅授权发布在该公众号，非常详细的一篇应急文，感谢这位师傅的分享！

0x01 缘由

晚上9点学校打电话说官网服务器可能被入侵了，第一时间登录服务器发现被装了一堆 360 的产品，360安全卫士，360安全杀毒 等等，之后又重新安装上了卡巴斯基卸载了360

服务器环境：

Windows Server 2016 IIS10.0.NET ASPX

因为服务器是双网卡，分别通校园资产内网和外网教育网，第一时间登录服务器把内网网卡禁用掉（外网登录），目的是为了防止入侵者做横向攻击，然后对关键文件做备份，修改RDP密码，数据库密码，杀毒，拍快照方便后期取证等手段...

卡巴斯基扫描发现存在一些以 .cs 结尾的.net恶意文件（这个 .cs 文件后面会详细说到）和木马文件 autohbas.dll，之后卡巴斯基直接把autohbas.dll给删了，结果服务器产生了503错误

IS重启和服务器重启都无法解决503，因为是学校官网服务器很多发文都在上面，503之后就有一堆老师打电话反应，迫于无奈，只能先把dll恢复，然后重新启动IIS让官网先运行着

dll无法移动和删除，看了一下dll被 IIS 调用，初步猜测是IIS后门

这里用火绒剑看了一下IIS进程的调用dll，dll没有签名和描述很可疑

文件属性

卡巴斯基KSN信誉扫描对比

打开 edge 浏览器发现，在 19点 左右入侵者搜索360安全卫士并且下载了安装包进行了安装，一开始不了解为什么会这样做，如果要搞隐蔽为什么要有这么大的动静？

检查了一下用户发现存在 vmadmin 并且还启用了 Guest

PS: 开始以为vmadmin是虚拟机管理用户一直没去排查，过了几个小时才反应过来 :(

Guest被启用，因为后来登录了一下，实际上次登陆时间是 2022/5/28 18:50，后来做的复盘截的图

把sam文件dump下来拉到本地做解密，因为是2016的操作系统，只能提取NTML Hash做解密，然后看一下入侵者设置的密码规则能不能获取到关键信息，然而最后解不开

用D盾做了一下检测发现vmadmin是克隆的administrator账号，且DLL是被恶意注册到了IIS的 Modules

扫了一下Web服务下的文件，找到了几个 Webshell ，发现 1月份 就已经有了，可见埋伏时间之长

因为dll不能直接删除，所以先把webshell和创建的用户给删除掉，之后把这些webshell和dll做一下样本提取

后来百度搜索了一下，发现后门手法是 IIS-Raid，将恶意dll注册到IIS服务端，之后可直接获取服务器权限

用list modules 找到恶意的modules，之后用命令删除已经注册的模块即可，因后来截的图，之前已经卸载过

删除掉模块后接着隔离删除dll，之后重启服务器和IIS服务器，发现官网不会在报503且一切功能正常使用，再用卡巴斯基和D盾做了一次全盘查杀都一切正常

再接着进行一些常规检查，检查完之后发现没什么异常，至此应急告一段落

官网后台账号系统进程网络连接驱动模块文件修改时间内容自启动计划任务等

0x03 排查

应急之后接着排查问题出在哪里，入侵者怎么黑进来的，做一个溯源。

因服务器做了反向代理，只对外网开放了80、53、3389服务，猜测入侵的手法：

DNS服务 Nday/0DayWeb服务入侵RDP爆破

先说一下DNS漏洞基本不太可能，就算是0day也不可能打到我们头上来，纯纯浪费，RDP爆破的话，服务器密码包含 字符数字大小写 也不太可能，爆破成本量太高，也更不至于，于是大概率是从Web下手

先看了下卡巴斯基的Web攻击日志，看到攻击者一直在用代理进行端口扫描，接着不管是什么中间件和开发环境，就拿一些exp乱打，目测是PoC集成工具做的扫描，但是有一条IP引起了注意

放到了微步看了一下

猜测这个可能是攻击者在做扫描的时候代理池断了一下导致真实IP发生泄露，不过并不确定

接着又看了一下卡巴的杀毒日志，发现删掉了很多 autohbas.dll 也就是那个IIS后门，之后的 svchost.exe 猜测是远控或者其他的后门，发现在19点之后，也就是安装了360之后就没有日志，通过这里可以知道，攻击者安装360的目的是为了替换掉卡巴斯基的安全防护，因为如果想退出卡巴斯基或结束掉进程都需要提供一个密码，而这个密码攻击者没有拿到，就只能利用360来接管卡巴斯基

Waf的日志，不明白为什么没阻断，看来规则需要加强了

看了一下dll的导出函数和内存，注册到IIS模块的函数

看到这些函数也就大概能知道这个dll做了什么

看了一下系统日志，发现在20点做了日志清理（没有日志审计），估计后门留好准备跑路了

接着看了一下4624的日志，发现IP也是代理

根据webshell创建的时间找了一下IIS的日志，结果5.27那天的日志被删了

只能去看01.16的日志

这几个IP放到微步和QAX情报社区发现都是来自泰国的傀儡机，也去扫了端口只开了3389和22

之后接着去排查webshell是怎么传上来的，因为shell的所在 文件夹目录 为后台上传图片所在的目录，初步猜测是上传图片的地方过滤不严格导致任意文件上传，但是我测了几个小时的任意文件上传发现webshell根本无法上传成功，且无法得知上传的路径反馈，加上我有服务器权限可以配合着D盾做文件监控，后来决定先上传正常的图片文件看看上传路径，发现可以上传成功，但是上传的路径却是在 \photo\product\ 下，不是在webshell的路径\photo\temp\ 下，哪怕是正常的图片也无法传到这个目录来，不知道代码对于图片的处理逻辑，且后台和前台的一些图片也被上传到了目录，百思不得其解，很没有道理

后来灵机一动，猜测temp目录下可能是损坏的图片，于是burp抓包故意把图片的内容做一些删除和增加，结果最后还是没有上传到webshell目录下，这个时候就很绝望，明明是通过官网后台上传上来的（webshell文件命名规则和上传图片命名一样），但是一直没有找到上传点，这个时候就猜想可能是0day，但是这个程序没有第二套都是单独开发的，入侵者应该也拿不到源码，正当一头雾水的时候，我联系了网站的开发商，对话如下：

我一直用的谷歌，谷歌表示不背这个锅 :(，接着让朋友白菜哥拿360浏览器去测了一下，结果不出所料

结果显而易见，至此漏洞点基本排查完成

正以为后门已经全部检查完成之后，过了一会，D盾的文件检测检测到了Webshell的创建，看了一下Waf日志确定Webshell不是从官网后台传上来的，卡巴斯基扫了下，发现是 .cs 文件，因为上回卡巴斯基直接做了删除没去看源文件，这次准备把文件先隔离到沙箱拖出来看一下，直接上图

路径：C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\b595ac21\4cd2f735

App_Web_x7curnr-.0.cs

可以看到有个叫door()的后门函数，且此Webshell的特征是 哥斯拉，因为哥斯拉实例化的类名是 LY，很明显用的哥斯拉生成的马子

猜测攻击手法：

1）官网文件夹下的 App_Code 文件夹可以包含 .vb、.cs  等扩展名的源代码文件，在运行时将会自动对这些代码进行编译。而 123.asmx.e8a2beba.compiled 是编译完成的输出文件，123.asmx就是生成的文件名。攻击者只需要将.cs源代码文件放到 App_Code目录下，网站每运行一次就会生成一个名叫123.asmx的Webshell在/js/目录下

2）官网文件夹下 Bin 文件夹中存放着已经编译的程序集，并且在Web 应用程序任意处的其他代码会 自动引用该文件夹，典型的示例是为自定义类编译好的代码，可以将编译后的程序集复制到Web应用程序的 Bin文件夹中，这样所有页都可以使用这个类，Bin文件夹中的程序集无需注册，只要.dll 文件存在于 Bin 文件夹中，.NET 就可以识别它。如果更改了 .dll 文件，并将它的新版本写入到了 Bin 文件夹中，则 .NET 会检测到更新，并对随后的新页请求使用新版本的 .dll 文件

3）.NET 内存马，参考文章：

https://tttang.com/archive/1408/

首次攻击发生在2022年的1月16日，那个时候的官网后台应该是有弱口令，攻击者通过扫描端口和Web目录找到Web后台，期间还进行过一系列的SQL注入测试，接着通过爆破进入到后台进行任意文件上传拿到shell，在拿到shell后继续留了一个aspx的webshell后门，接着用某种方法提权到system权限创建了用户vmadmin并且克隆了administrator的权限，接着以防万一激活了Guest用户，紧接着通过3389连接到administrator服务器桌面，发现有卡巴斯基，尝试退出结束发现无果后，隔了一短时间后通过浏览器下载360来接管卡巴斯基的防护，替换掉卡巴斯基后，上传了PChunter和dll后门，通过IIS-Raid手法将dll注册成IIS后门，然后接着留下.NET后门通过.NET机制来做到权限维持，最后上传了自己寄生虫程序，给自己菠菜和某些广告带流量和关键词，至此被学校相关人员发现，导致痕迹没有清理干净；最终的入侵目的是为了搞寄生虫和关键词排名，入侵者后来留的这些后门基本都被卡巴斯基查杀，但是寄生虫程序已经运行且已经被百度蜘蛛爬取到，只能第一时间去做快照和关键词举报

排查官网后台所有用户做弱口令检查，服务器RDP远程登陆设置白名单，Waf加强规则

针对任意文件上传做修复，可以看到之前的代码没有对文件后缀名做处理，只是原封不动的照搬上传文件的后缀

IIS-Raid：

https://github.com/zhangdebiao/iisbackdoor/https://github.com/0x09AL/IIS-Raidhttps://www.cnblogs.com/zaqzzz/p/12942439.htmlhttps://www.codercto.com/a/112760.htmlhttps://y4er.com/post/using-csharp-to-develop-the-iis-module-backdoor/

.Net DLL后门：

https://www.anquanke.com/post/id/153602

IOC：

IOC:45.8.68.96149.154.161.4223.24.162.36223.24.160.2
185.240.246.6 IDC机房 3389  49154 5342.247.33.214 ** 中国 北京市 |中国教育网223.166.75.202 ** 中国/上海/上海/浦东新区 |南码头|住宅用户|中国联通 | 家庭宽带| 121.510116,31.18071247.112.133.172 中国广东深圳 阿里云/电信/联通/移动/教育网

 还在等什么？赶紧点击下方名片关注学习吧！

推 荐 阅 读