DLL and VBScript execution hooking

c++ / delphi package - dll injection and api hooking
Post Reply
torstenv
Posts: 26
Joined: Sat Jun 26, 2004 5:13 pm

DLL and VBScript execution hooking

Post by torstenv »

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.
madshi
Site Admin
Posts: 10764
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

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.
torstenv
Posts: 26
Joined: Sat Jun 26, 2004 5:13 pm

Post by torstenv »

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.
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?
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.
I thought about this, too. But you could copy wscript.exe to myapp.exe and then call "myapp.exe myscript.vbs", couldn't you?
madshi
Site Admin
Posts: 10764
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

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.
Hmmm... Wouldn't ReadDirectoryChangesW also report about file changes? Of course that would only work in the NT family.

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.
I thought about this, too. But you could copy wscript.exe to myapp.exe and then call "myapp.exe myscript.vbs", couldn't you?
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...
mutantc0der
Posts: 11
Joined: Thu Jun 17, 2004 1:48 pm

Post by mutantc0der »

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!
madshi
Site Admin
Posts: 10764
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

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 ?
Yeah, I think CoCreateInstance and related APIs are what you need to look at:

http://msdn.microsoft.com/library/defau ... c_1nad.asp

I'm not too good with COM stuff, either, though.
mutantc0der wrote:if you can hook that you might have a starting point for VB script ??
Not sure. Does every VB script result in COM objects being used? I've no idea.
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!
Thanks, that's fine!
mutantc0der
Posts: 11
Joined: Thu Jun 17, 2004 1:48 pm

Post by mutantc0der »

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
madshi
Site Admin
Posts: 10764
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

Cool!! Sounds like a good idea to hook scripting! :D
Michael
Posts: 10
Joined: Thu Apr 07, 2005 5:41 pm
Location: Brazil

Post by Michael »

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
Michael
Posts: 10
Joined: Thu Apr 07, 2005 5:41 pm
Location: Brazil

Post by Michael »

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
How did you do? I tried to hook CoCreateInstance, but it is called by Windows many times, not only for VBScript objects creation.

May you post your DLL code?

[]'s
Forsaken
Posts: 4
Joined: Thu May 26, 2005 7:52 am

Post by Forsaken »

maybe by hooking createprocess and checking the CRC of a file, if it matches the WScript.exe then inject dll?

ofcourse there might be a lot of WScript.exe builds but that would catch it if it hasnt been infected with a virus or something :D
Post Reply