Malware Defender Customized Rules

Discussion in 'other anti-malware software' started by wat0114, Feb 19, 2009.

Thread Status:
Not open for further replies.
  1. wat0114

    wat0114 Guest

    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
     

    Attached Files:

    Last edited by a moderator: Feb 20, 2009
  2. screamer

    screamer Registered Member

    Joined:
    Apr 14, 2006
    Posts:
    921
    Location:
    Big Apple USA
    Great project Watt,

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

    ...screamer
     
  3. wat0114

    wat0114 Guest

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

    bellgamin Very Frequent Poster

    Joined:
    Aug 1, 2002
    Posts:
    5,648
    Location:
    Hawaii
    Good stuff. More please.

    (I hope Kees comments)
     
  5. wat0114

    wat0114 Guest

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

    Attached Files:

    Last edited by a moderator: Feb 20, 2009
  6. tony62

    tony62 Registered Member

    Joined:
    Aug 26, 2005
    Posts:
    214
    Location:
    UK
    Good stuff wat0114, nice to see some shared understanding of this beautifully organized application.
     
  7. wat0114

    wat0114 Guest

    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.
     
  8. wat0114

    wat0114 Guest

    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.
     

    Attached Files:

    Last edited by a moderator: Feb 21, 2009
  9. JosephB

    JosephB Registered Member

    Joined:
    Jan 3, 2008
    Posts:
    310
    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).
     
  10. wat0114

    wat0114 Guest

    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.
     
  11. JosephB

    JosephB Registered Member

    Joined:
    Jan 3, 2008
    Posts:
    310
    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.)
     
  12. tony62

    tony62 Registered Member

    Joined:
    Aug 26, 2005
    Posts:
    214
    Location:
    UK
    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.
     

    Attached Files:

  13. tony62

    tony62 Registered Member

    Joined:
    Aug 26, 2005
    Posts:
    214
    Location:
    UK
    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.
     

    Attached Files:

  14. wat0114

    wat0114 Guest

    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.
     

    Attached Files:

    Last edited by a moderator: Feb 22, 2009
  15. hooj

    hooj Registered Member

    Joined:
    Feb 22, 2009
    Posts:
    1
    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
     
  16. tony62

    tony62 Registered Member

    Joined:
    Aug 26, 2005
    Posts:
    214
    Location:
    UK
    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'.
     
    Last edited: Feb 22, 2009
  17. JosephB

    JosephB Registered Member

    Joined:
    Jan 3, 2008
    Posts:
    310
    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.
     
  18. wat0114

    wat0114 Guest

    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 :)
     
  19. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    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).
     
  20. Dark Shadow

    Dark Shadow Registered Member

    Joined:
    Oct 11, 2007
    Posts:
    4,553
    Location:
    USA
    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.
     
  21. JosephB

    JosephB Registered Member

    Joined:
    Jan 3, 2008
    Posts:
    310
    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 o_O 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 !!!
     
  22. xiaolin

    xiaolin Registered Member

    Joined:
    Aug 11, 2008
    Posts:
    248
    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. :)
     
  23. wat0114

    wat0114 Guest

    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.
     
    Last edited by a moderator: Feb 24, 2009
  24. JosephB

    JosephB Registered Member

    Joined:
    Jan 3, 2008
    Posts:
    310
    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 ?
     
    Last edited: Feb 24, 2009
  25. tony62

    tony62 Registered Member

    Joined:
    Aug 26, 2005
    Posts:
    214
    Location:
    UK
    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*
     
Loading...
Thread Status:
Not open for further replies.