Malware Defender Customized Rules

Malware Defender Customized Rules - A Learning Thread

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

 

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.

 

Good stuff. More please.

(I hope Kees comments)

 

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:
  1. Ignore
  2. Ask
  3. Permit
  4. Deny
  5. 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

 

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

 

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.

 

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:
  1. 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.
  2. 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:
  1. Jump to process - allows you to see where the main process is located under MD's Processes tab
  2. Jump to target - allows you to view the target of the main process under MD's Processes tab
  3. Jump to rule - highlites the rule location that was triggered
  4. Create permit rule - very handy if MD has denied something legitimate
  5. create deny rule - this will change the current Permit type to Deny type
  6. 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.

 

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.

 

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.)

 

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.

 

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.

 

tony thank you for your contributions

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.

 

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'.

 

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.

 

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.

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

Try this link.

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.

Me too

 

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).

 

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.

 

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 !!!

 

Thanks for the suggestion. I will think about it.

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.

Thank you.

 

thank you for the kind words xiaolin and djohn!

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.

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.

 

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 ?

 

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*