记一次IIS-Raid后门应急经历

0x01 缘由

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

0x02 应急

服务器环境：

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/0Day
Web服务入侵
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/

0x04 复盘

首次攻击发生在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机制来做到权限维持，最后上传了自己寄生虫程序，给自己菠菜和某些广告带流量和关键词，至此被学校相关人员发现，导致痕迹没有清理干净；最终的入侵目的是为了搞寄生虫和关键词排名，入侵者后来留的这些后门基本都被卡巴斯基查杀，但是寄生虫程序已经运行且已经被百度蜘蛛爬取到，只能第一时间去做快照和关键词举报

0x05 加固

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

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

0x06 附录

IIS-Raid：

https://github.com/zhangdebiao/iisbackdoor/
https://github.com/0x09AL/IIS-Raid
https://www.cnblogs.com/zaqzzz/p/12942439.html
https://www.codercto.com/a/112760.html
https://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.96
149.154.161.4
223.24.162.36
223.24.160.2

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