DLL and VBScript execution hooking
DLL and VBScript execution hooking
Hi!
We're trying to use MadCodeHook for detecting the execution of new code. We're currently hooking CreateProcess and this works very well except for some rare examples (like starting a 16Bit application (edit.com), which involves ntvdm.exe, the execution of ntvdm.exe is not being detected). When new code is found, we fingerprint it, to detect if it has been changed (e.g. by a virus).
Now we're thinking about a way to do the same with DLLs and VBS script files. The goal is to check and fingerprint code before it is actually being executed.
One approach we thought of would be to hook LoadLibrary to detect DLLs. The problem there is, that we need to have some sort of caching, because LoadLibrary is being called very often and we cannot fingerprint a DLL each time, LoadLibrary has been called. Therefore we need something like a cache. I think it's impossible to write into a DLL file, as long as the DLL is in use, so we can assume that the fingerprint won't change as long as this the DLL is in use. We could use LoadLibrary and see if the DLL is already in our list. If not, we fingerprint it and put it into the list. But then we would need to hook an API that would tell us when a DLL is being unloaded so that it can be removed from the cache and be checked and fingerprinted again, should it be called again. Is there such an API? How would we know that the DLL is not being used anymore and therefore can be overwritten with different, yet unchecked code?
The last question is: How can we detect the execution of VB script-code? Does anyone know of an API to hook?
Thanks in advance!
Regards,
T.
We're trying to use MadCodeHook for detecting the execution of new code. We're currently hooking CreateProcess and this works very well except for some rare examples (like starting a 16Bit application (edit.com), which involves ntvdm.exe, the execution of ntvdm.exe is not being detected). When new code is found, we fingerprint it, to detect if it has been changed (e.g. by a virus).
Now we're thinking about a way to do the same with DLLs and VBS script files. The goal is to check and fingerprint code before it is actually being executed.
One approach we thought of would be to hook LoadLibrary to detect DLLs. The problem there is, that we need to have some sort of caching, because LoadLibrary is being called very often and we cannot fingerprint a DLL each time, LoadLibrary has been called. Therefore we need something like a cache. I think it's impossible to write into a DLL file, as long as the DLL is in use, so we can assume that the fingerprint won't change as long as this the DLL is in use. We could use LoadLibrary and see if the DLL is already in our list. If not, we fingerprint it and put it into the list. But then we would need to hook an API that would tell us when a DLL is being unloaded so that it can be removed from the cache and be checked and fingerprinted again, should it be called again. Is there such an API? How would we know that the DLL is not being used anymore and therefore can be overwritten with different, yet unchecked code?
The last question is: How can we detect the execution of VB script-code? Does anyone know of an API to hook?
Thanks in advance!
Regards,
T.
The problem with the "in use" approach is that in the NT family you can rename files which are in use. So you can't say that a file which is in use can't be replaced. You can rename it from e.g. "notepad.exe" to "killme.exe" and then create a new "notepad.exe". Same with dlls.
About vbs scripts: I think they're executed in a "WScript.exe" process. So you might get access to the scripts by checking for WScript.exe in your CreateProcess hook.
The dll stuff is difficult. You could probably use the "in use" approach you suggested, but you have to combine it with ReadDirectoryChangesW, so you get informed about file rename actions. After a rename action you should clear the renamed dll from your cache.
About vbs scripts: I think they're executed in a "WScript.exe" process. So you might get access to the scripts by checking for WScript.exe in your CreateProcess hook.
The dll stuff is difficult. You could probably use the "in use" approach you suggested, but you have to combine it with ReadDirectoryChangesW, so you get informed about file rename actions. After a rename action you should clear the renamed dll from your cache.
OK that's a good hint. But how do I find that a dll is NOT in use anymore? In that case it could be replaced (without tricks like renaming) by just overwriting! We would have to delete the entry from the cache as soon as the file is not in use anymore. Does anybody have an idea how to find out?madshi wrote:The problem with the "in use" approach is that in the NT family you can rename files which are in use. (...) You could probably use the "in use" approach you suggested, but you have to combine it with ReadDirectoryChangesW, so you get informed about file rename actions.
I thought about this, too. But you could copy wscript.exe to myapp.exe and then call "myapp.exe myscript.vbs", couldn't you?About vbs scripts: I think they're executed in a "WScript.exe" process. So you might get access to the scripts by checking for WScript.exe in your CreateProcess hook.
Hmmm... Wouldn't ReadDirectoryChangesW also report about file changes? Of course that would only work in the NT family.torstenv wrote:OK that's a good hint. But how do I find that a dll is NOT in use anymore? In that case it could be replaced (without tricks like renaming) by just overwriting! We would have to delete the entry from the cache as soon as the file is not in use anymore.
If you really want to know when a dll is not used anymore you need to watch over 2 things: (1) A process can unload a dll manually by calling FreeLibrary or ExitThreadAndFreeLibrary. (2) Windows automatically unloads all dlls of a process when the process exits. So you need to hook FreeLibrary and ExitThreadAndFreeLibrary. And you need to open a handle to each running process and use WaitForMultipleObjects to wait until one of them closes.
Probably yes. Well, you could check all CreateProcess calls which get a script as a parameter. Of course that would also aim at Notepad then...I thought about this, too. But you could copy wscript.exe to myapp.exe and then call "myapp.exe myscript.vbs", couldn't you?
-
- Posts: 11
- Joined: Thu Jun 17, 2004 1:48 pm
I think this is related, so i dont start a new topic, but how do you hook CreateObject or better, creation of COM dlls ??? CoCreateInstance ?
the COM world is still so vague for me, i still dont have a idea where those e.g. filesystem objects and more come from, a DLL ? somewhere deep inside the reg with clsid keys i suspect!
if you can hook that you might have a starting point for VB script ??
btw madshi, im currently working on a security product concept, i'll buy the commercial version for sure when im going commercial with, your package and support is great!
the COM world is still so vague for me, i still dont have a idea where those e.g. filesystem objects and more come from, a DLL ? somewhere deep inside the reg with clsid keys i suspect!
if you can hook that you might have a starting point for VB script ??
btw madshi, im currently working on a security product concept, i'll buy the commercial version for sure when im going commercial with, your package and support is great!
Yeah, I think CoCreateInstance and related APIs are what you need to look at:mutantc0der wrote:I think this is related, so i dont start a new topic, but how do you hook CreateObject or better, creation of COM dlls ??? CoCreateInstance ?
http://msdn.microsoft.com/library/defau ... c_1nad.asp
I'm not too good with COM stuff, either, though.
Not sure. Does every VB script result in COM objects being used? I've no idea.mutantc0der wrote:if you can hook that you might have a starting point for VB script ??
Thanks, that's fine!mutantc0der wrote:btw madshi, im currently working on a security product concept, i'll buy the commercial version for sure when im going commercial with, your package and support is great!
-
- Posts: 11
- Joined: Thu Jun 17, 2004 1:48 pm
Hi mutantc0der!
Maybe today you already got that information, but FileSystemObject (FSO) is stored in scrrun.dll. So, if you find out a way to extract functions headers from it, you can hook methods like CreateFile or DeleteFile. Or, at least, hook LoadLibrary to check out when scrrun.dll is loaded by any process.
I'm creating a open source Delphi-based antivirus, so I got that information.
[]'s
Maybe today you already got that information, but FileSystemObject (FSO) is stored in scrrun.dll. So, if you find out a way to extract functions headers from it, you can hook methods like CreateFile or DeleteFile. Or, at least, hook LoadLibrary to check out when scrrun.dll is loaded by any process.
I'm creating a open source Delphi-based antivirus, so I got that information.
[]'s
How did you do? I tried to hook CoCreateInstance, but it is called by Windows many times, not only for VBScript objects creation.mutantc0der wrote:I'v tested it, a standalone loaded .vbs or .js script with the scripting host creates indeed a VBScript or JScript object , called with CoCreateInstance
Also applies when you visit a scripting page with Internet Explorer
May you post your DLL code?
[]'s