这2天测试了一个使用了WMI提供ASEC后门，里面使用了JS脚本往外请求http获取执行命令。但我的分析系统却没抓到这个行为，可在真机中确实抓到有HTTP请求。相当奇怪。
最后无奈windbg出手，内核断点afd 发送函数。最后发现是scrcons.exe进程，自然就google后，最后晓得是脚本宿主神马的。
最后了解了下这块，多谢EVA大侠的《深入挖掘Windows脚本技术》系统文章。加深了理解。
背景小故事说完了。个人对VBS脚本不懂。但常见的创建脚本
网上好像都是这样：
set fso=wscript.createobject("Scripting.FileSystemObject")
set ie=wscript.createobject("internetexplorer.application","event_") '创建ie对象'
或者直接createobject("Scripting.FileSystemObject")。
这个貌似还蛮好理解的。“Scripting.FileSystemObject”这玩意是注册表里面有关联，这就是COM注册方面的知识了。这里面不多讲。
我想知道的是像下面这种写法，是怎么找到接口的
for each ps in getobject("winmgmts:\\.\root\cimv2:win32_process").instances_
if lcase(ps.name)="scrcons.exe" then ps.terminate '自杀'
next
wscript.echo "die": wscript.quit '（调试用）
上面代码执行的时候。comodo比较友好的做出下面的提示
可以看到这个提示里面给出了触发的脚本文件和访问的接口。OK，触发的脚本我怀疑是comodo读取了相应进程如wcsript.exe的参数得到的。想验证也不难。在合适的时间，把参数改成其它的看COMODO怎么显示就OK了
关于接口名字呢，我就想调试跟踪下了。在弹出这个窗口的时候，拿出windbg attach上去。
执行~*k
0:003> ~*k
0 Id: 1db4.189c Suspend: 1 Teb: 7ffdd000 Unfrozen
ChildEBP RetAddr
0013ef50 7c92d28a ntdll!KiFastSystemCallRet
0013ef54 4aa91752 ntdll!ZwDeviceIoControlFile+0xc
0013efb8 4aa923c7 fltlib!FilterpDeviceIoControl+0xcc
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\guard32.dll -
0013efe0 10024aef fltlib!FilterSendMessage+0x23
WARNING: Stack unwind information not available. Following frames may be wrong.
0013f00c 1002e316 guard32+0x24aef
0013f070 769d3b9d guard32!Exported+0x7316
0013f0bc 769d3ae8 ole32!FindClassMoniker+0x5d
0013f0f4 732825fe ole32!MkParseDisplayName+0xd2
0013f140 73282590 vbscript!VbsPrint+0xe8
0013f15c 732824ee vbscript!VbsGetObject2+0xc4
0013f178 732739cd vbscript!VbsGetObject+0x33
0013f18c 73273b6f vbscript!StaticEntryPoint::Call+0x11
0013f290 732763ee vbscript!CScriptRuntime::RunNoEH+0x1e02
0013f2d8 73276373 vbscript!CScriptRuntime::Run+0x62
0013f3d0 73276ba5 vbscript!CScriptEntryPoint::Call+0x51
0013f42c 73276d9d vbscript!CSession::Execute+0xc8
0013f47c 73275103 vbscript!COleScript::ExecutePendingScripts+0x144
0013f498 01001dbe vbscript!COleScript::SetScriptState+0x14d
0013f4a4 01001d6c WScript!CScriptingEngine::Run+0xb
0013f4b8 01001c19 WScript!CHost::RunStandardScript+0x85
0013f6f0 0100332c WScript!CHost::Execute+0x1f0
0013fc94 01003105 WScript!CHost::Main+0x385
0013ff38 01003076 WScript!StringCchPrintfA+0xc3b
0013ff60 01002f16 WScript!WinMain+0x187
0013ffc0 7c817077 WScript!WinMainCRTStartup+0x5d
0013fff0 00000000 kernel32!BaseProcessStart+0x23
。。。。后面省略无关紧要线程栈
不错，有结果了。发现竟然是直接应用层拦截做提示出来的。这个方法是一个小技巧，因为要拦截，那hips的通知就必须的同步的了，所以对应的线程栈就会出现hips的模块。很显示，就是这里了。
如果这里没有comodo的话。有些函数拦截可能是这样，像LPC通信拦截，有可能是在内核栈。这时候如果不想用虚拟机，也可以借助MS的一个工具process Explorer。可以看线程的内核栈。也可以找出comodo的
驱动模块
0:003> dd 0013f070 +8
0013f078 0013f0a8 00000417 00000000 7699244c
0013f088 0013f0a4 0049b838 800401e3 800401e3
0013f098 0013f0ec 0018d618 0049b838 00000000
0013f0a8 172bddf8 11d1ceea 6000058b b6d90608
0013f0b8 00007ad6 0013f0f4 769d3ae8 0018d618
0013f0c8 0049b838 0013f0f0 0013f0ec 00942020
0013f0d8 0049b838 00000000 00000000 00000030
0013f0e8 769ae698 00000000 00000000 0013f140
0:003> db 0013f0a8
0013f0a8 f8 dd 2b 17 ea ce d1 11-8b 05 00 60 08 06 d9 b6 ..+........`....
0013f0b8 d6 7a 00 00 f4 f0 13 00-e8 3a 9d 76 18 d6 18 00 .z.......:.v....
综合上面的结果，很容易就猜到comodo是拦截了HOOK了 CoGetClassObject
CoGetClassObject原型如下：
HRESULT CoGetClassObject( __in REFCLSID rclsid, __in DWORD dwClsContext, __in_opt COSERVERINFO *pServerInfo, __in REFIID riid, __out LPVOID *ppv );
参数1就是clsid,上面显示0013f0a8就是参数1，里面的值正是注册表里面的clsid
后来又看了下riid，发现传过来的是
769d3b84 bf4c249976 mov edi,offset ole32!IID_IParseDisplayName (7699244c)
769d3b89 57 push edi
看来，WINMGMTS.1组件（对应C:\WINDOWS\system32\wbem\wbemdisp.dll）支持这个接口，从这个接口名字，可以猜测是用来解析名字的
接着就调用这个接口的ParseDisplayName函数
0 Id: 1880.1a94 Suspend: 1 Teb: 7ffdf000 Unfrozen
ChildEBP RetAddr
0013ec60 7c92d28a ntdll!KiFastSystemCallRet
0013ec64 4aa91752 ntdll!ZwDeviceIoControlFile+0xc
0013ecc8 4aa923c7 fltlib!FilterpDeviceIoControl+0xcc
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\guard32.dll -
0013ecf0 10024aef fltlib!FilterSendMessage+0x23
WARNING: Stack unwind information not available. Following frames may be wrong.
0013ed1c 1002e55b guard32+0x24aef
0013ed80 74e518c1 guard32!Exported+0x755b
0013edb4 74e5186e wbemprox!CDCOMTrans::DoActualCCI+0x3d
0013edf8 74e515db wbemprox!CDCOMTrans::DoCCI+0x12d
0013eeb4 74e517e4 wbemprox!CDCOMTrans::DoActualConnection+0x25c
0013eee0 74e51ee1 wbemprox!CDCOMTrans::DoConnection+0x25
0013ef20 5a7872f3 wbemprox!CLocator::ConnectServer+0x7c
0013ef74 5a7839e2 wbemdisp!CSWbemLocator::ConnectServer+0x108
0013f070 769d3bb8 wbemdisp!CWbemParseDN::ParseDisplayName+0x5c5
0013f0bc 769d3ae8 ole32!FindClassMoniker+0x89
0013f0f4 732825fe ole32!MkParseDisplayName+0xd2
0013f140 73282590 vbscript!VbsPrint+0xe8
0013f15c 732824ee vbscript!VbsGetObject2+0xc4
0013f178 732739cd vbscript!VbsGetObject+0x33
0013f18c 73273b6f vbscript!StaticEntryPoint::Call+0x11
0013f290 732763ee vbscript!CScriptRuntime::RunNoEH+0x1e02
0013f2d8 73276373 vbscript!CScriptRuntime::Run+0x62
0013f3d0 73276ba5 vbscript!CScriptEntryPoint::Call+0x51
0013f42c 73276d9d vbscript!CSession::Execute+0xc8
0013f47c 73275103 vbscript!COleScript::ExecutePendingScripts+0x144
0013f498 01001dbe vbscript!COleScript::SetScriptState+0x14d
0013f4a4 01001d6c WScript!CScriptingEngine::Run+0xb
0013f4b8 01001c19 WScript!CHost::RunStandardScript+0x85
0013f6f0 0100332c WScript!CHost::Execute+0x1f0
0013fc94 01003105 WScript!CHost::Main+0x385
0013ff38 01003076 WScript!StringCchPrintfA+0xc3b
0013ff60 01002f16 WScript!WinMain+0x187
0013ffc0 7c817077 WScript!WinMainCRTStartup+0x5d
0013fff0 00000000 kernel32!BaseProcessStart+0x23
可以看出这是在解析一个名字，而这个名字正是：（这次断点是脚本调用了一个登陆WebLoginxxxx的接口，访问的接口是{8BC3F05E-D86B-11D0-A075-00C04FB68820}，应对的localservice便是winmgmt）
0:003> dd 0013f070 +8
0013f078 00941010 0018d618 0049b838 0013f0f0
0:003> du 0049b838
0049b838 "winmgmts:\\.\root\cimv2:win32_pr"
0049b878 "ocess"
最后一次comodo提示的就是
断点下来是
0013e2ec 7c92db8a ntdll!KiFastSystemCallRet
0013e2f0 77e6ef14 ntdll!NtSecureConnectPort+0xc
0013e41c 77e6fc75 RPCRT4!LRPC_CASSOCIATION::OpenLpcPort+0x261
0013e5f4 77e6fbae RPCRT4!LRPC_CASSOCIATION::CreateBackConnection+0x6a
0013e630 77e68746 RPCRT4!LRPC_CASSOCIATION::ActuallyDoBinding+0x32
0013e6a8 77e5bba8 RPCRT4!LRPC_CASSOCIATION::AllocateCCall+0x18c
0013e710 77e5baba RPCRT4!LRPC_BINDING_HANDLE::AllocateCCall+0x202
0013e73c 77e58ed9 RPCRT4!LRPC_BINDING_HANDLE::NegotiateTransferSyntax+0xd3
0013e754 76ab241b RPCRT4!I_RpcGetBufferWithObject+0x5b
0013e798 76ab221f ole32!CRpcChannelBuffer::ClientGetBuffer+0x2e6
0013e7a8 769da3a1 ole32!CRpcChannelBuffer::GetBuffer+0x19
0013e7c4 769da33c ole32!CAptRpcChnl::GetBuffer+0x122
0013e824 77ed5f6e ole32!CCtxComChnl::GetBuffer+0x194
0013e840 77ed5f26 RPCRT4!NdrProxyGetBuffer+0x3e
0013ec24 77ed5e42 RPCRT4!NdrClientCall2+0x171
0013ec44 77e68519 RPCRT4!ObjectStublessClient+0x8b
0013ec54 769cea05 RPCRT4!ObjectStubless+0xf
0013eca0 769ce953 ole32!CStdMarshal::Begin_RemQIAndUnmarshal1+0xaf
0013ecc0 769cea52 ole32!CStdMarshal::Begin_QueryRemoteInterfaces+0x45
0013ed08 769cebf2 ole32!CStdMarshal::QueryRemoteInterfaces+0x37
0013ed54 769bc3e5 ole32!CStdIdentity::CInternalUnk::QueryMultipleInterfaces+0xbf
0013ed78 77ed5b68 ole32!CStdIdentity::CInternalUnk::QueryInterface+0x33
0013ed8c 74e5195f RPCRT4!IUnknown_QueryInterface_Proxy+0x16
0013ede8 74e51692 wbemprox!SetClientIdentity+0x34
0013eeb4 74e517e4 wbemprox!CDCOMTrans::DoActualConnection+0x40c
0013eee0 74e51ee1 wbemprox!CDCOMTrans::DoConnection+0x25
0013ef20 5a7872f3 wbemprox!CLocator::ConnectServer+0x7c
0013ef74 5a7839e2 wbemdisp!CSWbemLocator::ConnectServer+0x108
0013f070 769d3bb8 wbemdisp!CWbemParseDN::ParseDisplayName+0x5c5
0013f0bc 769d3ae8 ole32!FindClassMoniker+0x89
0013f0f4 732825fe ole32!MkParseDisplayName+0xd2
0013f140 73282590 vbscript!VbsPrint+0xe8
0013f15c 732824ee vbscript!VbsGetObject2+0xc4
0013f178 732739cd vbscript!VbsGetObject+0x33
0013f18c 73273b6f vbscript!StaticEntryPoint::Call+0x11
0013f290 732763ee vbscript!CScriptRuntime::RunNoEH+0x1e02
0013f2d8 73276373 vbscript!CScriptRuntime::Run+0x62
0013f3d0 73276ba5 vbscript!CScriptEntryPoint::Call+0x51
0013f42c 73276d9d vbscript!CSession::Execute+0xc8
0013f47c 73275103 vbscript!COleScript::ExecutePendingScripts+0x144
0013f498 01001dbe vbscript!COleScript::SetScriptState+0x14d
0013f4a4 01001d6c WScript!CScriptingEngine::Run+0xb
0013f4b8 01001c19 WScript!CHost::RunStandardScript+0x85
0013f6f0 0100332c WScript!CHost::Execute+0x1f0
0013fc94 01003105 WScript!CHost::Main+0x385
0013ff38 01003076 WScript!StringCchPrintfA+0xc3b
0013ff60 01002f16 WScript!WinMain+0x187
0013ffc0 7c817077 WScript!WinMainCRTStartup+0x5d
0013fff0 00000000 kernel32!BaseProcessStart+0x23
忘记用那个工具看了，但基本可以确实是COMODO在内核拦截了NtSecureConnectPort,另外，这个函数这时候连接的LPC端口名字是
0:007> DS 0013e32c
0015dcb8 "\RPC Control\OLE5414EF9AB84D4EE2"
0015dcf8 "AFC7B846FF8C"
基本可以断点COMODO发现这个端口是那个svchost.exe创建的，所以便那么提示了。
PS：这lpc端口名应该可以在RPC Control目录下找到。
在LPC通信模型中，连接之后，就可以使用里面提供的各种接口了。。一般这些接口都是在某些组件(.dll)内，按常规来说，那个svchost.exe应该是加载着那个dll.
下面看下到底是哪个DLL。
由于是应用层，而且那个提示窗口只给了svchost.exe名字，但不知道哪个进程啊（一般系统下有很多个svchost）
但由于那个port是在rpc control目录下，那就还好办。
拿出windbg,切到本地内核调试
lkd> !object \RPC Control
Object: e1bccf58 Type: (8b03d1f0) Directory
ObjectHeader: e1bccf40 (old version)
HandleCount: 0 PointerCount: 52
Directory Object: e1000350 Name: RPC Control
Hash Address Type Name
---- ------- ---- ----
00 e3dc7218 Port tapsrvlpc
01 e15848c8 Port wzcsvc
e35b31e0 Port OLE5DFA1BD881D74714A865E2E2DE16
02 e165d1e0 Port dhcpcsvc
e1405d50 Port OLE6A08EAAB60A4456FB606E7E5AD6F
e3c273d8 Port INETINFO_LPC
03 e7001958 Port OLE4526068DB2AD4F00A0584BB32A01
e40578f0 Port OLE4045BDC0F35B4A6C9EC0BFCB971B
e4121a50 Port OLE0D24358162B64C61B634D06E66EE
04 e3e6a5e8 Port unimdmsvc
e3dc7040 Port LRPC00000580.00000001
05 e3a77180 Port OLEEAF56F3A5DF5473D84060E2D1C60
06 e15be4b8 Port protected_storage
e1513798 Port OLE8FB57FF8C1824D62BF47D28BB006
07 e3861498 Port OLED5A3FD0ECB4E41C7A75DF1CE9515
e167b5f0 Port OLE5414EF9AB84D4EE2AFC7B846FF8C
e6f0ed48 Port OLE0861D9F566444CCF8AEDD666C3C7
08 e1682f68 Port keysvc
e1581f68 Port audit
10 e3dab540 Port IcaApi
e1da8488 Port sclogonrpc
e15e3b08 Port OLEBDFC0F42ED6347049785CAB4F298
11 e699ab28 Port OLE0EF5E2DB8DEC4F7A8C80F61F4764
e412f878 Port OLE48CBF912C1D240F9ABD8296C44E0
e7a13850 Port OLE43E91EBCA37B45FE8B37E267ABD3
12 e1bbf518 Port OLEE097F8B3D8B7451BBC3EE1D86436
13 e47dee88 Port OLE44AAE06A644D46E79AE2A5872027
14 e1ad03a8 Port OLE8E2F097BDEC1447C9B746ED30837
15 e1b5ac28 Port securityevent
16 e6eac218 Port OLEE5059F8A4BFE430BA359F3223E67
e12bef68 Port IUserProfile
17 e168f1e0 Port DNSResolver
18 e3aaf878 Port OLE8E4F1754257642B380E15A81AE27
19 e37ba6c8 Port OLEB7E9ABDD162E47F3AB7BADCF8C63
20 e15bb528 Port ntsvcs
21 e5684f68 Port OLEE51CFA1E9E594F60A9F336C28FED
26 e5758270 Port OLED9DD9A5535724C43B831A7D3E721
29 e3def810 Port OLE7CAA8DA2B985419EAC9403A3CBAF
e3d94758 Port OLE23F17B9484C14B6D8C76C44B05DA
30 e35bd040 Port OLE723E15967CDD4DFE9FB451D0D368
e15acf68 Port actkernel
31 e355a600 Port OLEEF9DEEA758F948A592975CC63127
32 e1f0b040 Port OLE068EAE8970EE4A6CA3BB091E7F93
e3eab390 Port {D0C8F705-A505-4255-B192-295EB90A3DE0}
e1602aa0 Port AudioSrv
33 e15eff68 Port 1_476_30242289_574288206
34 e3b0f1f0 Port senssvc
e14db8d8 Port epmapper
e2a73040 Port OLE66B78EA13E5E4FE9BBB12117021E
35 e3a53868 Port OLE1CCD86AFC16345C1850509558999
36 e6007258 Port OLE7825936FD45340669F384AF0EE6F
lkd> !lpc port e167b5f0
Server connection port e167b5f0 Name: OLE5414EF9AB84D4EE2AFC7B846FF8C
Handles: 1 References: 16
Server process : 87582da0 (svchost.exe)
Queue semaphore : 875403a0
Semaphore state 0 (0x0)
The message queue is empty
The LpcDataInfoChainHead queue is empty
OK，知道是哪个进程了。是eprocess =87582da0
用工具了下这个进程的模块，发现好多可疑模块（在wbem目录下的模块），无法确定 是哪个，也许是多个共同合作
既然也可以是很多个共同合作，那很难找出了。不过还是继续玩下。。。
确定模块现在有2个方法：
1。根据LPC 端口特性，由于客户进程可以连接它，那自然服务端就要有一个线程要等待连接了，所以可以看线程栈，看哪个线程在等待这个端口的连接。
2。如果能确定脚本会触发svchost.exe执行某个API的话，便可以去调试这个svchost.exe。最后断点那个API，。断下来后，栈回溯便能找出那个处理请求的模块。