Malware Defender Customized Rules

[wat0114]

After finally gaining a far better (not expert) understanding of this terrific product, I have been progressively modifying the rules to suit my security preferences. I'd like to share them with others who are interested. This first post will only show the basics. I will reveal individual group and even some individual application rules, explaining their protection measures if required, when time permits over the next week or so.

Feel free to critique them and ask questions or offer advice.

Please realize they are a work in progress; they are not necessarily final.

*EDIT*

On the ss where it says "Added some additional "high risk" executables to defaults" it should read as: "Added some additional "high risk" file types to defaults". fixed

[screamer]

Great project Watt,

Keep it up. I'd really appreciate a better understanding of this app.

...screamer

[wat0114]

-{ Quote: "Great project Watt,

Keep it up. I'd really appreciate a better understanding of this app.

...screamer" }-

Thank you screamer. I'll have more, hopefully, this evening, starting with "Application Rules - System", providing a rundown on how MD processes the rules.

[bellgamin]

Good stuff. More please.

(I hope Kees comments)

[wat0114]

Now for a quick rundown on the rules processing:


Malware Defender processes rules from the bottom to the top, with highest priority rules at the bottom to the lowest priority (global rules) at the top. The Application rules-System are built-in rules and have the highest priority. They can not be deleted but they can be modified.

There are several Application permissions available, with permission "type" as:
Ignore Ask Permit Deny Deny and kill the process


They should all be self-explanatory but it is especially important to understand the permission type: Ignore

as one might expect, MD will ignore the rule, but then it will search for the next lowest priority rule up the ladder.

Now for applications organized in "Group" folders: Important: Applications within groups with their own rules take higher priority over rules applied to the group folder. If the permission type of an application within a Group is set to "Ignore" the Group permission will then be checked next.


This is about all I can say for now for MD's rule processing; it is too overwhelming to explain everything. I would advise reading over the help file for more tips. It contains lots of useful information to at least get you started with this program. The majority of the learning, however, comes from a "hands on" approach. It helps a great deal to try different things so you can gain an understanding of this program.

Finally, a few screenshots of the very common System rule: explorer.exe.

You will notice the enormous influence it has as a parent application on child applications :) Important: Applications listed as "Child" under explorer.exe with permission to execute will not trigger rules further up the ladder (lower priority) for permission to execute; this is because they are garnered by a higher priority parent application than the lower priority rules. I have changed the default permission types on this from "Ignore" to "Ask". Note also the use of wildcard "*" for its Registry rules. This affords me solid enough protection while minimizing pop-ups. it is highly advisable to prudently incorporate wildcards into certain rules where applicable, to keep a nice balance between security with fewer unnecessary pop-ups.

This will be it for tonight. Maybe more tomorrow or the weekend :)

[tony62]

Good stuff wat0114, nice to see some shared understanding of this beautifully organized application.

[wat0114]

Thank you tony and bellgamin! The possibilities for organizing these rules seems virtually endless. I'm starting to think about using more, common trusted folders such as d:\program files\*, for example, in my ruleset which would eliminate tons of applications within these rules These same folders could be guarded with a rule to prevent unauthorized writing to them. Anyways, we'll see.

[wat0114]

Before posting some screenshots of System application rule "rundll32.exe" and Group folder "Internet Access Applications", I would like to comment on the developer's, xiaolin, default ruleset:

The default ruleset imo is solid, offering sound protection with general ease of use. They can be left "as is" without compromising the security of your machine. I would suggest before modifying the rules, run MD in "Learning mode" for at least a day, possibly two, re-booting a couple times, logging in to all accounts and opening as many applications and performing as many common tasks as possible. Make sure you have logs enabled (bottom tab, far left). The logs serve as an excellent tool for figuring out what's happening with the rules Next you will want to look over the rules, especially the higher priority ones and look for anything that is either:
too granular (registry rules especially can get this way), making it a candidate for wildcard use. Excessive granularity in the rules will ultimately lead to MD triggering lots of pop-ups. too liberal, example: you wouldn't want Rundll32.exe having create permission on "*" this is not the best example, maybe, because in learning mode MD should not allow this to happen :) However, for demonstration sake it could be tightened as: C:\Windows\system32

More on the logs:

As I mentioned previously, the logs are a very useful tool in MD. Here is what you can do with them: Right-click on an entry: Jump to process - allows you to see where the main process is located under MD's Processes tab Jump to target - allows you to view the target of the main process under MD's Processes tab Jump to rule - highlites the rule location that was triggered Create permit rule - very handy if MD has denied something legitimate create deny rule - this will change the current Permit type to Deny type Copy, Copy process, Copy target

There is also Clear logs, Select all and Invert selection, though I think you will find the first five options the most useful.

BTW, I still encourage any comments, suggestions or criticisms. I'm open to any ideas that will improve upon my work. Please feel free to post them.

[JosephB]

wat0114,

Since, I am still learning, I have a question about your setup:

You added protection to protect against writing all file types to both c:\windows and c:\windows\system32.

... So, my basic learning question is why not also protect writing all file types to all of the subdirectories below c:\windows, as well ??

.... Any significant disadvantage in doing this ??
.... (Then none of the windows system components could be tampered with and malware could not even do a delete of all the files in the entire windows folder and its subfolders).

[wat0114]

-{ Quote: "wat0114,

Since, I am still learning, I have a question about your setup:

You added protection to protect against writing all file types to both c:\windows and c:\windows\system32.

... So, my basic learning question is why not also protect writing all file types to all of the subdirectories below c:\windows, as well ??

.... Any significant disadvantage in doing this ??
.... (Then none of the windows system components could be tampered with and malware could not even do a delete of all the files in the entire windows folder and its subfolders)." }-

Good question Joseph and thank you for your input. To be honest, I'm basically guessing that protecting at least these two malware-targeted directories will provide the right balance for optimal security without the barrage of alerts that could, and probably would, occur with protecting all sub-directories. I'd really like to see opinions from malware savvy members on this. If you are one, please let me know if this protection setting is adequate enough. I'm no expert at all in this area so I more than welcome advice from others.

[JosephB]

wat0014,

Re: Write (ask) protecting all file types to c:\windows and c:\windows\system32:

-{ Quote: "Originally Posted by wat0014,

Good question Joseph and thank you for your input. To be honest, I'm basically guessing that protecting at least these two malware-targeted directories will provide the right balance for optimal security without the barrage of alerts that could, and probably would, occur with protecting all sub-directories. I'd really like to see opinions from malware savvy members on this. If you are one, please let me know if this protection setting is adequate enough. I'm no expert at all in this area so I more than welcome advice from others." }-


I am no expert either. Would be interesting to know, after say a week or so whether or not you get too many alerts with your setup of protecting all writing of files to c:\windows and c:\windows\system32, when you perform typical operations under windows.

(Perhaps, Xiaolin, Kees will comment on your setup and this question.)

[tony62]

Sandboxie users may want to add these rules to their sandbox directory and start.exe. At least I have, in order to minimize on prompts when installing new software in a sandbox. Also note that:

sandboxiedcomlaunch.exe
sandboxierpcss.exe
sbiectrl.exe
sbiesvc.exe
start.exe

have been placed in the 'Installers and Updaters' Group.

[tony62]

-{ Quote: "wat0014,

Re: Write (ask) protecting all file types to c:\windows and c:\windows\system32:




I am no expert either. Would be interesting to know, after say a week or so whether or not you get too many alerts with your setup of protecting all writing of files to c:\windows and c:\windows\system32, when you perform typical operations under windows.

(Perhaps, Xiaolin, Kees will comment on your setup and this question.)" }-
The following rule will permit read and ask for all write access to Windows and all sub directories. Note that I do not use this rule and I am not sure of how annoying it may be.

[wat0114]

tony thank you for your contributions :thumb:

I thought I'd continue with a look at a typical MD alert.

The anatomy of a Malware Defender alert:

Here is a pictorial example of an alert where svchost.exe wants to: “Duplicate handle to another process”, where the “target process” is powerpnt.exe.

BTW, in the last screenshot where you see: File Path: d:\program files\microsoft office\office12\powerpnt.exe

it is possible to edit the path any way you want using wildcards. example: d:\program files\microsoft office\* This would decrease the granularity of the rule, allowing svchost to influence files in the "office12" directory and files in all directories below it.

[hooj]

tony62
I tried what you have done in post #12 concerning sandboxie, I made the rule but can't seem to move it to "Installers and Updaters". How did you move it to that location.
Thanks

[tony62]

-{ Quote: "tony62
I tried what you have done in post #12 concerning sandboxie, I made the rule but can't seem to move it to "Installers and Updaters". How did you move it to that location.
Thanks" }-
Hi hooj,
In Malware Defender select the rules tab. Right click the application you wish to move into the 'Installers and Updaters' Group, then from the context menu select 'Move to Group' and select 'Installers and Updaters'.

EDIT: If this is concerning the folder and file permissions in the first screenshot, then it should remain under the 'Global File Rules'.

[JosephB]

wat0014, tony62, .....

For my education, can someone please explain to me in your example (wat0014) what is meant by "duplicate handle to another process" ?

... Also, Is Powerpoint trying to access its ony data in process memory or is it trying to accees another process's data in memory.

What is role of Svchost and why is it the main process calling powerpoint, if your just excuting powerpoint ?


Trying to learn.
Thanks.

[wat0114]

-{ Quote: "wat0014, tony62, .....

For my education, can someone please explain to me in your example (wat0014) what is meant by "duplicate handle to another process" ? " }-

Sorry, I don't know. There is some info on the 'net, but it's pretty technical. Maybe tony, xiaolin or someone else has the answer.

-{ Quote: "... Also, Is Powerpoint trying to access its ony data in process memory or is it trying to accees another process's data in memory." }-

According to to the example I posted, I think it's only svchost accessing or controlling powerpnt.exe.

-{ Quote: "What is role of Svchost" }-

Try this link ( http://www.howtogeek.com/howto/windows-vista/what-is-svchostexe-and-why-is-it-running/).

-{ Quote: "why is it the main process calling powerpoint, if your just executing powerpoint ?" }-

svchost is one of the processes influencing powerpnt.exe but there is also explorer.exe creating (launching) it. That's in another rule. You will see that explorer.exe is involved in pretty much everything that's executed in Windows.

-{ Quote: "Trying to learn.
Thanks." }-

Me too :)

[xiaolin]

wat0014, thank you for the great tutorial. :)

To JosephB,

A handle is used as a ID of system object (file, registry key, process, thread, token, etc). Duplicating handle from/to another process may cause security problems. MD classify these actions as "Access process data" (another process).

[djohn]

Wat0014, Very nice tutorial and its truly amazing what can be done with programs like MD and the like outside of the defaults with the rules and customization when one knows what there doing as you do and clearly did here with MD.

[JosephB]

wat0114,

I was just wondering, in your exanple of the alert that popped up for Powerpoint, did you change a default permission on the Svchost Rule and that is why the Alert involving Svchost accessing Powerpoint appeared for you ?

-- OR --

This alert appears with the default shipping permissions of MD, only if you do *not* first exercise the Powerpoint application in "learning mode" of MD ?

---------------------------------

Xiaolin,

....Thanks for the explanation "duplicate handle to another process".


I) Now, for an Enhancement Request:

... As an enhancement, I think it would greatly clarify alerts if you can add a one or two sentence text describing the "Action" that is being attempted by the process as text in the Alert screen (if you can fit it) or as a dropdown view to show the description text (if screen is to crowded to fit the text directly).
..... For example, So if for the "Duplicate handle to another process" Alert , you showed as a text sentence description the explanation you gave me (action is "Accessing process data" (of another process)." This would greatly clarify what is being attempted for us less experienced users.


II) Xiaolin, .... another quick question:

What is your reccomendation about either:

Method 1 - Write (Ask) protecting all file type extensions of c:\windows and all its subdirectories.

-- OR --

Method 2 - Write (Ask) protecting all file type extensions of the parent folders c:\windows and c:\windows\system32, but *not* their subdirectories.

1) What would you say are the Advantages/Disadvantages ??? vs. just going with MD's default protection of only executable extension protection of c:\windows and its subdirectories ??


2) I would think that an advantage of Method 1 would be protection against Malware, trojan doing a generic wildcard delete of all the files under c:\windows and its subdirectories,

... Unless, ... Does MD have a built-in way of protecting against a generic wildcard delete, performed by either a batch file, VBScript, or a malware .exe program ??


... Congratulations, for a very good first time score for MD on the latest Matousec Test !!!

[xiaolin]

-{ Quote: "
I) Now, for an Enhancement Request:

... As an enhancement, I think it would greatly clarify alerts if you can add a one or two sentence text describing the "Action" that is being attempted by the process as text in the Alert screen (if you can fit it) or as a dropdown view to show the description text (if screen is to crowded to fit the text directly).
..... For example, So if for the "Duplicate handle to another process" Alert , you showed as a text sentence description the explanation you gave me (action is "Accessing process data" (of another process)." This would greatly clarify what is being attempted for us less experienced users.
" }-
Thanks for the suggestion. I will think about it.

-{ Quote: "
II) Xiaolin, .... another quick question:

What is your reccomendation about either:

Method 1 - Write (Ask) protecting all file type extensions of c:\windows and all its subdirectories.

-- OR --

Method 2 - Write (Ask) protecting all file type extensions of the parent folders c:\windows and c:\windows\system32, but *not* their subdirectories.

1) What would you say are the Advantages/Disadvantages ??? vs. just going with MD's default protection of only executable extension protection of c:\windows and its subdirectories ??


2) I would think that an advantage of Method 1 would be protection against Malware, trojan doing a generic wildcard delete of all the files under c:\windows and its subdirectories,

... Unless, ... Does MD have a built-in way of protecting against a generic wildcard delete, performed by either a batch file, VBScript, or a malware .exe program ??
" }-
I recommend Method 1.

There are many executable files in the sub directories of c:\windows, they are need to be protected, such as c:\windows\system32\drivers. Creating rule for each directory is inconvenient, and may omit some directories.

There is no built-in way to protect against a generic wildcard delete, because the "generic wildcard delete" is implemented with single file delete.

-{ Quote: "
... Congratulations, for a very good first time score for MD on the latest Matousec Test !!!" }-
Thank you. :)

[wat0114]

thank you for the kind words xiaolin and djohn!

-{ Quote: "wat0114,

I was just wondering, in your exanple of the alert that popped up for Powerpoint, did you change a default permission on the Svchost Rule and that is why the Alert involving Svchost accessing Powerpoint appeared for you ?" }-

The alert occurred because it was the first time, believe it or not :) , that I launched powerpoint since the installation of MD, though it was on a recently restored image. However, I did also change the default permissions on svchost to "Ask" so that the Application rule: "Appication Rules - Normal" above would not trigger. This way svchost's own permissions would trigger alerts because they are now set to "Ask" rather than "Ignore". Remember when a permission type is set to "Ignore", MD looks for the first lower priority rule containing the same permission type.

-{ Quote: "-- OR --

This alert appears with the default shipping permissions of MD, only if you do *not* first exercise the Powerpoint application in "learning mode" of MD ?" }-

Yes, the default rules in MD would have triggered this alert, but it would have been triggerd by the "Appication Rules - Normal" rule above the "Appication Rules - System" rules.

let me just say I'm customizing the default rules both as a way to gain a thorough understanding of MD, and as an attempt to improve upon what xiaolin designed, though this is not to imply his defaults are weak; the defaults are strong, affording excellent protection of the applicacions and file system.

[JosephB]

wat0114,

Thanks for your explanations and examples!!! I now have a much better understanding due to your expertise and great tutorial. Your customizations just got me thinking whether or not, it is practical to come up with a way to also protect the Windows System directories from have any files, within them deleted by a trojan/malware/virus. This is what prompted my questions about different choices of protecting the windows system directories.
I just didn't word my question about it properly to indicate what I was trying to acheive and whether there would be any disadvantages to this tight a protection.

------------------------------

xiaolin,

I didn't word my last question properly.

Basically, I was wondering whether it was practical to come up with a way to protect the Windows System directories from have any files, within them deleted by a trojan/malware/virus.

.... So, I really meant to ask the following question:

-- If I was to replace MD's shipping default file protection of:

c:\windows\*; *.exe
c:\windows\*; *.dll
etc.

--With protection as follows:

c:\windows\* Write(Ask)

a) Will I get too many popups by the window's system needing to write to its only data files for normal windows operations ?
b) Could it get Windows or MD stuck with this tight a protection ?
c) Is it not practical in trying to make protection this tight because its really not needed ?

[tony62]

-{ Quote: "
xiaolin,

I didn't word my last question properly.

Basically, I was wondering whether it was practical to come up with a way to protect the Windows System directories from have any files, within them deleted by a trojan/malware/virus.

.... So, I really meant to ask the following question:

-- If I was to replace MD's shipping default file protection of:

c:\windows\*; *.exe
c:\windows\*; *.dll
etc.

--With protection as follows:

c:\windows\* Write(Ask)

a) Will I get too many popups by the window's system needing to write to its only data files for normal windows operations ?
b) Could it get Windows or MD stuck with this tight a protection ?
c) Is it not practical in trying to make protection this tight because its really not needed ?" }-
JosephB,
You should really test this for yourself, as most systems are very different in their configurations.
If you do decide to test this, then I'd suggest a reboot or two in learning mode.
Anyway I've decided to give this a little test run to give people an idea of the kind of activity that goes on. I'd also expect most systems to generate a lot more activity using Vista or systems where the services have not been tamed.

I am using XP Professional with a number of unnecessary services disabled:

24/02/2009 08:33:15 c:\windows\explorer.exe Write file C:\WINDOWS\WindowsUpdate.log Permitted [File]c:\windows*
24/02/2009 08:33:24 c:\windows\system32\wuauclt.exe Write file C:\WINDOWS\SoftwareDistribution\DataStore\Logs\edb.log Permitted [File]c:\windows*
24/02/2009 08:33:24 c:\windows\system32\wuauclt.exe Write file C:\WINDOWS\SoftwareDistribution\DataStore\Logs\edb.log Permitted [File]c:\windows*
24/02/2009 08:33:24 c:\windows\system32\wuauclt.exe Write file C:\WINDOWS\SoftwareDistribution\DataStore\Logs\edb.log Permitted [File]c:\windows*
24/02/2009 08:33:24 c:\windows\system32\wuauclt.exe Create file C:\WINDOWS\SoftwareDistribution\DataStore\Logs\tmp.edb Permitted [File]c:\windows*
24/02/2009 08:33:24 c:\windows\system32\wuauclt.exe Write file C:\WINDOWS\SoftwareDistribution\DataStore\Logs\tmp.edb Permitted [File]c:\windows*
24/02/2009 08:33:24 c:\windows\system32\wuauclt.exe Write file C:\WINDOWS\SoftwareDistribution\DataStore\Logs\tmp.edb Permitted [File]c:\windows*
24/02/2009 08:33:25 c:\windows\system32\wuauclt.exe Write file C:\WINDOWS\SoftwareDistribution\DataStore\Logs\tmp.edb Permitted [File]c:\windows*
24/02/2009 08:33:25 c:\windows\system32\wuauclt.exe Write file C:\WINDOWS\SoftwareDistribution\DataStore\DataStore.edb Permitted [File]c:\windows*
24/02/2009 08:33:25 c:\windows\system32\wuauclt.exe Write file C:\WINDOWS\SoftwareDistribution\DataStore\DataStore.edb Permitted [File]c:\windows*
24/02/2009 08:33:25 c:\windows\system32\wuauclt.exe Write file C:\WINDOWS\SoftwareDistribution\DataStore\Logs\edb.chk Permitted [File]c:\windows*
24/02/2009 08:33:25 c:\windows\system32\wuauclt.exe Delete file C:\WINDOWS\SoftwareDistribution\DataStore\Logs\tmp.edb Permitted [File]c:\windows*
24/02/2009 08:34:11 c:\windows\system32\imapi.exe Create file C:\WINDOWS\TEMP\vms8fo87.TMP Permitted [File]c:\windows*
24/02/2009 08:34:11 c:\windows\system32\imapi.exe Write file C:\WINDOWS\Temp\vms8fo87.TMP Permitted [File]c:\windows*
24/02/2009 08:35:02 c:\windows\system32\svchost.exe Write file C:\WINDOWS\WindowsUpdate.log Permitted [File]c:\windows*
24/02/2009 08:35:04 c:\windows\system32\svchost.exe Write file C:\WINDOWS\WindowsUpdate.log Permitted [File]c:\windows*
24/02/2009 08:35:05 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemcore.log Permitted [File]c:\windows*
24/02/2009 08:35:06 c:\windows\system32\svchost.exe Write file C:\WINDOWS\WindowsUpdate.log Permitted [File]c:\windows*
24/02/2009 08:35:42 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Repository\$WinMgmt.CFG Permitted [File]c:\windows*
24/02/2009 08:35:43 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemess.log Permitted [File]c:\windows*
24/02/2009 08:35:44 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemess.log Permitted [File]c:\windows*
24/02/2009 08:35:44 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemess.log Permitted [File]c:\windows*
24/02/2009 08:35:45 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemess.log Permitted [File]c:\windows*
24/02/2009 08:35:46 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemess.log Permitted [File]c:\windows*
24/02/2009 08:35:46 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemess.log Permitted [File]c:\windows*
24/02/2009 08:35:47 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemess.log Permitted [File]c:\windows*
24/02/2009 08:38:18 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemcore.log Permitted [File]c:\windows*
24/02/2009 08:38:18 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemcore.log Permitted [File]c:\windows*
24/02/2009 08:38:19 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemcore.log Permitted [File]c:\windows*
24/02/2009 08:38:20 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemcore.log Permitted [File]c:\windows*
24/02/2009 08:38:21 c:\windows\system32\wbem\wmiprvse.exe Write file C:\WINDOWS\system32\wbem\Logs\wmiprov.log Permitted [File]c:\windows*
24/02/2009 08:38:22 c:\windows\system32\wbem\wmiprvse.exe Write file C:\WINDOWS\system32\wbem\Logs\wmiprov.log Permitted [File]c:\windows*
24/02/2009 08:38:22 c:\windows\system32\wbem\wmiprvse.exe Write file C:\WINDOWS\system32\wbem\Logs\wmiprov.log Permitted [File]c:\windows*
24/02/2009 08:38:23 c:\windows\system32\wbem\wmiprvse.exe Write file C:\WINDOWS\system32\wbem\Logs\wmiprov.log Permitted [File]c:\windows*
24/02/2009 08:38:23 c:\windows\system32\wbem\wmiprvse.exe Write file C:\WINDOWS\system32\wbem\Logs\wmiprov.log Permitted [File]c:\windows*
24/02/2009 08:38:24 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemcore.log Permitted [File]c:\windows*
24/02/2009 08:38:25 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Logs\wbemcore.log Permitted [File]c:\windows*
24/02/2009 08:38:25 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Repository\FS\OBJECTS.DATA Permitted [File]c:\windows*
24/02/2009 08:38:26 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Repository\FS\INDEX.BTR Permitted [File]c:\windows*
24/02/2009 08:38:27 c:\windows\system32\wbem\wmiadap.exe Create file C:\WINDOWS\system32\WBEM\Performance\WmiApRpl_new.h Permitted [File]c:\windows*
24/02/2009 08:38:27 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\wbem\Performance\WmiApRpl_new.h Permitted [File]c:\windows*
24/02/2009 08:38:29 c:\windows\system32\wbem\wmiadap.exe Delete file C:\WINDOWS\system32\wbem\Performance\WmiApRpl.h Permitted [File]c:\windows*
24/02/2009 08:38:29 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\wbem\Performance\WmiApRpl_new.h Permitted [File]c:\windows*
24/02/2009 08:38:30 c:\windows\system32\wbem\wmiadap.exe Create file C:\WINDOWS\system32\WBEM\Performance\WmiApRpl.h Permitted [File]c:\windows*
24/02/2009 08:38:30 c:\windows\system32\wbem\wmiadap.exe Create file C:\WINDOWS\system32\WBEM\Performance\WmiApRpl_new.ini Permitted [File]c:\windows*
24/02/2009 08:38:31 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\wbem\Performance\WmiApRpl_new.ini Permitted [File]c:\windows*
24/02/2009 08:38:33 c:\windows\system32\wbem\wmiadap.exe Delete file C:\WINDOWS\system32\wbem\Performance\WmiApRpl.ini Permitted [File]c:\windows*
24/02/2009 08:38:33 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\wbem\Performance\WmiApRpl_new.ini Permitted [File]c:\windows*
24/02/2009 08:38:34 c:\windows\system32\wbem\wmiadap.exe Create file C:\WINDOWS\system32\WBEM\Performance\WmiApRpl.ini Permitted [File]c:\windows*
24/02/2009 08:38:35 c:\windows\system32\wbem\wmiadap.exe Create file C:\WINDOWS\system32\perfc009.dat Permitted [File]c:\windows*
24/02/2009 08:38:35 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\perfc009.dat Permitted [File]c:\windows*
24/02/2009 08:38:36 c:\windows\system32\wbem\wmiadap.exe Create file C:\WINDOWS\system32\perfh009.dat Permitted [File]c:\windows*
24/02/2009 08:38:37 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\perfh009.dat Permitted [File]c:\windows*
24/02/2009 08:38:37 c:\windows\system32\wbem\wmiadap.exe Create file C:\WINDOWS\system32\PerfStringBackup.TMP Permitted [File]c:\windows*
24/02/2009 08:38:38 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\PerfStringBackup.TMP Permitted [File]c:\windows*
24/02/2009 08:38:39 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\PerfStringBackup.INI Permitted [File]c:\windows*
24/02/2009 08:38:39 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\PerfStringBackup.INI Permitted [File]c:\windows*
24/02/2009 08:38:40 c:\windows\system32\wbem\wmiadap.exe Delete file C:\WINDOWS\system32\PerfStringBackup.TMP Permitted [File]c:\windows*
24/02/2009 08:38:41 c:\windows\system32\wbem\wmiadap.exe Create file C:\WINDOWS\system32\perfc009.dat Permitted [File]c:\windows*
24/02/2009 08:38:41 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\perfc009.dat Permitted [File]c:\windows*
24/02/2009 08:38:42 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Repository\FS\MAPPING1.MAP Permitted [File]c:\windows*
24/02/2009 08:38:42 c:\windows\system32\wbem\wmiadap.exe Create file C:\WINDOWS\system32\perfh009.dat Permitted [File]c:\windows*
24/02/2009 08:38:43 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Repository\FS\OBJECTS.MAP Permitted [File]c:\windows*
24/02/2009 08:38:44 c:\windows\system32\wbem\wmiadap.exe Write file C:\WINDOWS\system32\perfh009.dat Permitted [File]c:\windows*
24/02/2009 08:38:44 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Repository\FS\INDEX.MAP Permitted [File]c:\windows*
24/02/2009 08:38:45 c:\windows\system32\svchost.exe Write file C:\WINDOWS\system32\wbem\Repository\FS\MAPPING.VER Permitted [File]c:\windows*
24/02/2009 08:44:59 c:\windows\system32\wbem\wmiprvse.exe Write file C:\WINDOWS\system32\wbem\Logs\wmiprov.log Permitted [File]c:\windows*

[JosephB]

-{ Quote: "Originally Posted by tony62

JosephB,
You should really test this for yourself, as most systems are very different in their configurations.
If you do decide to test this, then I'd suggest a reboot or two in learning mode.
Anyway I've decided to give this a little test run to give people an idea of the kind of activity that goes on. I'd also expect most systems to generate a lot more activity using Vista or systems where the services have not been tamed.

I am using XP Professional with a number of unnecessary services disabled:


Originally Posted by JosephB

xiaolin,

I didn't word my last question properly.

Basically, I was wondering whether it was practical to come up with a way to protect the Windows System directories from have any files, within them deleted by a trojan/malware/virus.

.... So, I really meant to ask the following question:

-- If I was to replace MD's shipping default file protection of:

c:\windows\*; *.exe
c:\windows\*; *.dll
etc.

--With protection as follows:

c:\windows\* Write(Ask)

a) Will I get too many popups by the window's system needing to write to its only data files for normal windows operations ?
b) Could it get Windows or MD stuck with this tight a protection ?
c) Is it not practical in trying to make protection this tight because its really not needed ?" }-

tony62,
That's quite a bit of activity! Thanks for taking the time to run the test. It is good to know that MD can support this level of protection. I am constantly impressed with the capability and flexibility of MD. This is truly an excellent program !!! Thanks again tony62 and wat0014 for your explanations and testing, I have learned a lot from your posts.

[wat0114]

Okay, now I thought I'd post some shots of a registry object alert of Internet Explorer triggering an alert under the Registry Group: "Internet Explorer Settings".

I have included shots of some of the available options when finalizing the rule.

First, the main alert including a shot of the window where the granularity of the rule can be edited...

[wat0114]

Second, shots of a few of the available options...

[JosephB]

wat0114,

Superb tutorial of registry alerts/rules !

I want to ask your advice about the execute permissions rule, do you feel that it is best to set it as permit or ask ?

P.S. Side question, what software do you use to capture those screenshots which allows one to mark with red framing and arrows ?

[wat0114]

-{ Quote: "wat0114,

Superb tutorial of registry alerts/rules !

I want to ask your advice about the execute permissions rule, do you feel that it is best to set it as permit or ask ?

P.S. Side question, what software do you use to capture those screenshots which allows one to mark with red framing and arrows ?" }-

Thank you JosephB!

I use Snagit for screen captures.

For "Application rules - System" I leave it at "Permit". For Application Rules - Normal I changed the default from "Ignore" to "Ask" for tightening things up a bit, though do keep in mind that pretty much all, if not all, of your applications are going to be a "Child" of one of your system apps, especially explorer.exe, so the "Ask" rule further up the ladder (lower priority) will not get triggered in this case.

I just consider the possibility some form of malware may not need one of the trusted system apps as a parent to launch. This possibility may be remote but you never know. I just want to make sure the "Execute" rule will trigger early if that is going to be the case.

[cruchot]

Thanks for this thread :)

As a MD newcomer I'm currently playing with the rule system.
Are there handy rules or possibilities to stop Gpcode for example?

Regards from Germany

[wat0114]

The addition of an Install mode has been discussed often regarding MD, so I have decided to try to design a basic one using a custom Application Rule, keeping it disabled except when a program needs to be installed.

Please note this is a work in progress and I'm no expert at choosing the best rules and permissions; I am only interested in choosing a ruleset that will afford some protection against malware behaviour with minimal pop-ups, so I have experimented extensively in VBox using Wireshark/Winpcap as the test installation program, selected because it will generate tons of pop-ups in MD without an Install mode. Every time I made a change to the rules, I exported the configuration, then reverted to VBox'es current snapshot, imported the the configuration, then started over again re-installing the program on the clean snap shot.

The screen shots essentially show its settings.


First, I created an Application Rule and placed it at the very bottom of Application Rules - Normal
On the Permissions tab I have chosen "Ask" in key areas where malware might target.
Under the File tab I have selected two File groups
Under the Registry tab I have selected two Registry groups.
Under the Network tab any network access attempts will trigger an alert

Note the permissions I have given to these groups, quite liberal overall, yet some restrictiveness, in order to reduce the pop-ups while installing programs.

The results so far are as follows:

MD pop-ups generated with full install of Wireshark/Winpcap:

With the custom Program install mode Application rule disabled: 141 pop-ups

With the custom Program install mode Application rule enabled: 10 pop-ups

That is quite a huge difference. This way there is at least some degree of protection in the event of an unintended launching of a rogue program, without the barrage of annoying pop-ups that would occur without a toned down Application rule such as the one I created but better than simply disabling MD before installing a program where there is not 100% certainty in its trustworthiness.

Any suggestions are both encouraged and welcomed :)

[wat0114]

Finally a screen shot of the Network tab settings:

[Scoobs72]

Setting "Access Keyboard in Low Level" to "Ask" causes endless pop-ups for me as soon as this rule is enabled. Is this setting correect?

[arran]

regarding installing new unknown software for the first time, I have always recommended in these forums to first install on a backed up image or on VM before you install on your real system to see if it is clean and see how well it behaves, and to see if you like the software.

After a quick test. I have found that using the "Remove Stale Rules" option does indeed remove all the installation rules for MOST software.

Its really only when you install software which during the install process calls up system apps to make system modifications to install things like start up drivers etc.

[wat0114]

-{ Quote: "Setting "Access Keyboard in Low Level" to "Ask" causes endless pop-ups for me as soon as this rule is enabled. Is this setting correect?" }-

Yes, it's correct. What program is causing all those alerts, and are you enabling the Application rule only for installing a program?

-{ Quote: "regarding installing new unknown software for the first time, I have always recommended in these forums to first install on a backed up image or on VM before you install on your real system to see if it is clean and see how well it behaves, and to see if you like the software." }-

A nice option, for sure, but not everyone wants to go this route.

-{ Quote: "After a quick test. I have found that using the "Remove Stale Rules" option does indeed remove all the installation rules for MOST software. " }-

That's good to know. Thank you for checking it out :)

-{ Quote: "Its really only when you install software which during the install process calls up system apps to make system modifications to install things like start up drivers etc." }-

Do you mean this is malicious behaviour when installing programs? I'm attempting to cover at least most areas with my custom Application rule to alert on malicious behaviour during a new program install, so I'm hoping you and others can offer suggestions on what could be added or deleted to the rules. Ultimately, I'm hoping xiaolin can pipe up with some suggestions or announce he will eventually addd an "Install mode" for MD :)

[Scoobs72]

-{ Quote: "Yes, it's correct. What program is causing all those alerts, and are you enabling the Application rule only for installing a program?


" }-

It's a couple of processes relating to mouse and ATA drivers. I've placed them below the new rule in the list and that seems to have solved the problem.