Script Trap

Anyone in the mood to share their opinions of this simple script interceptor? It's listed as last Updated: August 18th 2000. For a simple freeware it seems to do alright plus you can even add either your AV or any AntiSpyware program to scan scripts (aka:text) it interrupts to ensure their safe. Unlike ScriptDefender this one uninstalls completely without gumming up XP's associations. Probably not that useful in light of today's POWERFUL new AV's & HIPS but i toyed around with it a bit and found it reasonably useful as a backup script catcher in the event you disabled your HIPS protections for whatever reason.

Script Trap

 

With a little imagination you can make this script stopper display your own preferred information.

 

I havn´t used it for several years, but as you mentioned, compared to ScriptDefender it works flawlessly even if it havn´t been updated since 2000. One could always toy around and for example sandbox ST and thereby the executed scripts. For users of on-demand scanners, one could add Winpooch as well and thereby get a decent "resident" protection using low resources.

/C.

 

That's using some useful imagination Cerxes. Sandboxing ST would definitely seal the primer so to speak on any of the scripts allowed to pass that gate.

Excellent idea.

EASTER

 

I dunno why i allowed this tiny script catcher to escape me all this time for ScriptDefender, but it compliments any security setup rather nicely and since it's equipped with both a WHITE LIST and a BLACK LIST as well as you can use any Anti-Spyware or Anti-Virus to scan scripts, it's useful indeed. With the exception of batch files, it monitors most basic scripts just fine like .HTA, .REG, .VBS, etc.

How's this for an alert prompt. LoL

 

Hmmm....from where to get some malicious scripts? Easter! can u PM me.

Thanks

 

Aigle in your setup, adding scripttrap as an untrusted program would make testing more or less useless (first: script trap will notify you, second: all scripts executed by an untriusted program can do very little harm).

Cheers Kees

 

Hmmm.... I can,t understand this. Why not sandbox windows scripting host then. No need of even ST. Am I true?

 

I understand that. Never have seen any malicious script in action, so wanted to play a bit.

Thanks

 

Check U R pm mailbox.

 

Well that´s what I´ve done for the scripts I´m allowing to run on my system, sandboxing WSH since I´m not using ST. Other types of scripts which are not allowed to run is blocked by SRP (chosen file extensions).

/C.

 

Useful prevention Cerxes, however with ST, it's able to capture scripts without having to set pre-defined extensions or sandbox or set for example mshta.exe for one that launches .HTA script files.

The only drawback is you can't add additional extensions which would really cap it off nicely. But, as-is, it's enough as a fallback measure i think.

Scripts don't seem to be in high demand for exploiters as much as they used to, just executable loaders and the like.

With Real-Time Defender + MAMUTU guarding the gates it's almost of none effect really to employ Scriptrap, but it raises confidence for me to have it in place as a support security monitor just for those types.

 

Yes, there are several ways of controling these types of executables.

I don´t know about that, since they are powerful enough to achieve certain malicious activities which could be rather serious.

/C.

 

Scripts and script writing will always be apart of the malware scene. In the scheme of things its relatively easy to write a script which malware writers have taken full advantage of eg the ILOVEYOU malware.

The key is regulating the execution of the code, SRP as mentioned by Cerxes is a good place to start as the type of user.

 

With those comments i respectfully stand corrected. Of course as long as Windows is equipped to launch script files via runDLL and such, those script files can fan out all over a system and make unwelcome changes per malware intentions.

Script Trap however is proven an X-Tremely useful preventitive measure against them and it's Black List/White List plus the fact it can SCAN anything that it interrupts is a big bonus.

You're quite right. Scripts can be easily fashioned to carry out malware assignments and pack a punch once run without being interrupted.

 

Speaking for myself, it seems to me that the key is to keep malicious script files from getting on to my computer in the first place.

I haven't looked at the topic of scripts in a while, so in light of the concern in this thread, I should update my knowledge to see what is new.

Starting with some questions:

Under what circumstances should I worry that a malicious script file could get on to my system and execute? That is, what current attacks use script files?

---

 

Of course it is RMUS but I wasn't exactly talking about that. One point I was trying to make is that they for example a script written in VBscript can come back and visit us anytime as they are generally easy to produce. Although that is not the only one, I shouldn't imagine any unauthorised executable accessing your machine RMUS, the truth is most everyday users don't need to run a script either.

 

So my HIPS rules are right then!

 

as we dont need it for every day use i blocked it from system 32.

 

The point I'm making is, how do you think that this VBS file going to come back and visit? Or get downloaded in the first place?

Identifying the attack vector is the first step in prevention:

==> Script file in an email attachment? (love.vbs virus)

Prevention: safe email practices

==> Script file (VBS, BAT) on a USB stick (Autorun.inf file -- switchblade exploit)

Prevention: use non- U3 type flash drive which won't run AutoRun.inf files; block AutoRun in some way

==> Script via internet worm (MSBlaster exploit via port 135)

Similar to this is the current 0-day RPC exploit for which Microsoft has released an out-of-cycle patch (MS08-067). Yet note these comments in articles yesterday:

Prevention: properly configured firewall

Yes, but how do you think that the .vbs file would get on your computer in the first place? That's what I'm asking, so as to determine prevention at the perimeter -- at the entry point.

What you have showed is no different then the firewall leaktests, where you have to download/run a test executable simulating a trojan executable.

So far no one has noted any current attacks using script files so we can see what the attack method -- the point of entry -- is.

Once an attack method is identified, then preventative measures can be implemented. Prevention meaning that the script file does not get downloaded, therefore, has no chance to execute.


---

 

I don,t know really.

I infact mostly disable windows scripting host by some way as I don,t need it.

 

Rmus, you don't need to convince me about prevention .

 

Good preventative measure, when upgrading I check this just in case its been reinstalled.

Or who tries what at the machine.

Going back to what aigle says about prevention and disabling wsh, on some machines I redirect by re associating the extensions in the registry and have a message that will pop up in notepad explaining to the user what is happening usually something like - you are trying to run a file which is restricted.

 

I realize that I don't have to convince you about prevention! But put yourself in the place of someone viewing this thread who doesn't understand too much about scripts and their potential to do great damage.

At this moment, 379 guests are connected to Wilders. Those reading this thread are confronted with discussions assuming that a malicious script file happens to be on the computer and how to block it when you click on it.

I'm asking, how does this script file get on the computer in the first place, and why would you click-to-run an unknown file anyway?

I've given several scenarios as to how a script file could enter, and successful ways to prevent that.

I'm asking if people know of current attacks using other methods to bring in a malicious script file, so we can analyze what is going on.

If someone asked you for advice about scripts, would you just recommend a product, or would you explain the various attack methods and how to successfully prevent them from entering in the first place?


-----

 

Ahh, i knew Rmus would eventually chime in on this topic.

He is been paramount in better educating many of us here on the very real and always present danger that exploits such as even text scripts can visit on Windows systems, and his details & explainations along with screenshots raise an often overlooked and dismissed problem that can very well sneak up and bite any user no matter how experienced.

Thanks Rmus for all your efforts and brilliant exhibitions to these threats THAT STILL EXIST, even to this very day when it comes to scripts, and no one is been any more forward & present in sharing this issue with all of us here then you, and we're honestly grateful for each and every comparison from your testings & experience, and we're all the more better protected for it.

EASTER