Tony Klein's RD Standard .gsr file - Comments

I notice that in the default Rules for File Associations we have the following two keys:-

HKEY_CLASSES_ROOT\Comfile\Shell\Open\Command

HKEY_CLASSES_ROOT\.cmd


However for consistency shouldn't we also be protecting these two keys?:-

HKEY_CLASSES_ROOT\Cmdfile\Shell\Open\Command

HKEY_CLASSES_ROOT\.com

I've added them to my setup, but I'm wondering if other people are seeing this - or is it a case of me deleting things I shouldn't have.

 

Re: Inconsistency in default Rules?

Hi TopperID.

I have done the same thing as you,as well add more extensions to be watched,i figured maybe Jason thinks those keys/values may cause too many pop-ups for average user,i dunno

But yes,i have noticed other similar things,for example:-
he has
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows nt\Currentversion\Windows - appinit_dlls
but not
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows nt\Currentversion\Inifilemapping\Win.ini\Windows - appinit_dlls

There are a few more aswell,he may add/get round to adding them,but i don't get any logs/alerts for that stuff,so they may not be that important.

 

Re: Inconsistency in default Rules?

Fortunately the above Key is covered by the Kent/RegRun Group which has:-

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows nt\Currentversion\Inifilemapping\Win.ini**

However, for good measure, I have also included the HKCU version as well. There is a lot of this kind of thing, for example we are protected against:-

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Currentversion\Explorer\Browser helper objects**

but not:-

HKEY_CURRENT_USER\Software\Microsoft\Windows\Currentversion\Explorer\Browser helper objects**

HKEY_CLASSES_ROOT\Software\Microsoft\Windows\Currentversion\Explorer\Browser helper objects**

I don't know whether the above two are important, but they are used by malware, eg:-

http://securityresponse.symantec.com/avcenter/venc/data/trojan.goldun.b.html

http://www3.ca.com/securityadvisor/pest/pest.aspx?id=453094133

 

Re: Inconsistency in default Rules?

as a matter of fact, is it possible to use wildcard to cover both hklm and hkcu ?

i beleive most key would benifit from this ?
unless there is a drawback i don't know ?

let say you have hklm/something
but not hkcu/something

even if hkcu doesnt exist, or does nothing... it doesnt hurt to protect something that will never be trigered.

This could even speedup gss as you'll have half less rules

 

Re: Inconsistency in default Rules?

I don't have those...so like i said...maybe thay're not that important .

 

Re: Inconsistency in default Rules?

I think, if anything, it would slow RegDefend down. You'd have fewer rules in the list, but RegDefend would be watching many more keys and values, which is what really counts.

 

Re: Untested Ghost files .gst

Ahhhhh,i've been wandering how to include that key without adding all of them.

Your a saviour mate.

 

Re: Untested Ghost files .gst

Don't thank me, thank Jason: it's all in the Helpfile :

http://www.ghostsecurity.com/gsshelp/

 

Re: Untested Ghost files .gst

Doh... God knows how many times i've read that helpfile...

 

Re: Inconsistency in default Rules?

I know this is an Ooooold thread, but I thought I'd react all the same...

In reality neither of those keys exist 'in the wild'... .

Only HKLM\Software\Microsoft\Windows\Currentversion\Explorer\Browser helper objects does

As for its namesake in HKCU, I'm afraid that's Symantec goofing up. Sophos has it right: http://sophos.org/virusinfo/analyses/trojgoldunj.html

Neither does the key exist in HKCR, nor in fact does the Symantec article say it does, if you re-read it carefully.

HKEY_CLASSES_ROOT\CLSID\{92617934-9abc-def0-0fed-fad48c654321} of course DOES exist.

 

Re: Untested Ghost files .gst

Oh, of course, you want to confine protection to keys like:-

HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers

but can't use the '*' as it would be misinterpreted by RD as a wildcard, hence the need for '?' instead.

We live and learn!

 

Re: Untested Ghost files .gst

Eggzactly!

 

Re: Untested Ghost files .gst

Tried importing Tony K's latest file and it won't import. After extracting I tried renaming it.ghst and .gst and neither worked. Also copied the .gsr to the RD folder. Any suggestiuons? I am running RD 2.001.

 

Re: Untested Ghost files .gst

Hi G1111,

After extracting Tony's .gsr file to your GhostSecuritySuite folder, you need to exit and restart RD. Tony's .gsr should then be available via the pull down menu on the Main tab.

Nick

 

Re: Inconsistency in default Rules?

Hi Tony,

I can believe Symantec goofing up, but not everybody else as well; here are a few examples:-

http://de.trendmicro-europe.com/enterprise/vinfo/grayware.php?vGrayware=3723

http://www.trendmicro.co.jp/vinfo/grayware/ve_graywareDetails.asp?GNAME=SPYW_WER1316.A

http://www.trendmicro.co.jp/vinfo/grayware/ve_graywareDetails.asp?GNAME=SPYW_TUBBY.A

http://www3.ca.com/securityadvisor/pest/pest.aspx?id=453082734

http://www3.ca.com/securityadvisor/pest/pest.aspx?id=453072519

http://www3.ca.com/securityadvisor/pest/pest.aspx?id=453076995

http://www.symantec.de/avcenter/venc/data/adware.hungryhands.html

https://www3.cai.com/securityadvisor/pest/pest.aspx?id=453078845

http://www.symantec.com.mx/avcenter/venc/data/adware.smartpops.html

Hojtsy also accepts that such keys are relevant:-

https://www.wilderssecurity.com/showthread.php?t=32823

So what am I to believe? Surely malware does create and make use of Keys that do not normally exist, and if so it should be desirable to stop that from happening.

 

Re: Untested Ghost files .gst

Thanks Nick - That worked. Didn't realize this is not an add on like hi s old one but a complete (replacement) for RDStandard.

 

Re: Inconsistency in default Rules?

You are to believe me... LOL

Certainly malware can and will create keys that not normally exist, but if they're not going to work you'll agree with me that that wouldn't be of very much use.

The BHO key is located in HKLM only. Windows is just wired like that: Upon startup, Internet Explorer looks up that key and loads all the objects whose CLSID is stored there.
It finds those objects by consulting the Improcserver32 subkey of HKCR\CLSID of the same name, where the default data contain the path to the file implementing the BHO.

Although you can certainly create BHO keys anywhere else, they won't be recognized by Windows, and Iexplore will not load BHOs stored there. You have to play by its rules.

Also, if a BHO key could exist and work on a per user basis, you could be sure that someone somewhere would actually know about it. It would somewhere be found in the MS Knowledge Base, and the folks behind Sysinternals Autoruns, RunAlyzer, HijackThis, Startuplist, Autostart Viewer (and RegDefend) would scurry to check those other keys as well.

They don't.

There is an incredible amount of erroneous information to be found on the Internet due to either people being sloppy, not checking their facts, or just not knowing what they're talking about...

Let me explain this in another way:

Do a Google search for MSCVRT.DLL.

That will yield over 2200 hits, a couple of them at microsoft.com.

Trouble is, there's no MS file by that name, as you'll see when checking the Microsoft dll Help Database

This is actually all people misspelling MSVCRT.DLL... LOL!

Same thing with your HKCU BHO key: it yields about 70 results: http://tinyurl.com/9gcr7

.. while a search for the correct key yields over 30,000: http://tinyurl.com/e4zv4

So to return to your earlier question: yes, all your examples are AV companies giving out erroneous information.

The trojans/adware in question really do exist, but I can assure you they install their BHOs somewhere they will be recognized by Windows ie in HKLM

 

Re: Inconsistency in default Rules?

Hi Tony,

I just wanted to say that it is good to see you back posting with your expertise in clarifying some things as far as the registry. I have missed your posts and appreciate your knowledge as I always learn from you.

Thanks for pointing out the inconsistencies that exist when researching different keys in the registry.

 

Re: Inconsistency in default Rules?

Hi Kent, good to see ya!

You're very welcome. It's good to be back and I'll try to be a little less sparse than I've been lately.

 

Re: Untested Ghost files .gst

Fine-tuning: had to add the following rules to the Rundll32 and Explorer Application Rules groups in order to ALLOW the following:

To the Explorer group add:

HKEY_CURRENT_USER\Software\Microsoft\Internet explorer\Desktop\Components | GeneralFlags | SET VALUE

HKEY_CURRENT_USER\Software\Microsoft\Internet explorer\Desktop\Components\0 | Position | SET VALUE |


To the Rundll32 group add:

HKEY_CURRENT_USER\Control panel\Desktop | screensavetimeout | SET VALUE |

Haven't updated the file yet; you can add these rules manually for the time being

 

Re: Untested Ghost files .gst

New file up, containing these and other additions, plus a few refinements and other tweaks.

Between the apps groups there will be a couple referencing third party applications that you don't need if you don't happen to run those programs (Port Explorer, ACDsee, and so on) In that case there's obviously no need to keep those groups.

https://www.wilderssecurity.com/attachment.php?attachmentid=174267&d=1139318037

 

Thanks Tony, I might have guessed it - you just can't trust these AV companies!

One further question though, I notice you've included:-

HKEY_LOCAL_MACHINE\System\*controlset*\Control\Bootverificationprogram

with protection on the 'ImageName' value; but why not 'ImagePath'?

http://support.microsoft.com/?id=102987

 

Well, they DO consist of people, and you know how people are...

Well, that's one rule I borrowed from an existing set being tested, and I didn't research it. My bad....

it SHOULD be ImagePath, as ImageName only exists as a subkey, not a value...

I'll edit that, and you should do likewise.

Thanks!

 

Wow - that was an incredibly quick reply, I've only just posted.

Thanks Tony - that's what I call service.

 

Well, I happened to be online...