Malware Defender - Possible Leak!

Can someone please check this out? This could be a Virtualbox issue or MD issue.

Here is the setup I'm using:

• XP Pro, SP3 running in Virtualbox
  
• Administrator account
  
• latest version MD (2.3.3)

I can go to any file under C:\Windows\* and change the file extension - even though MD alerts me and I select Deny on all alerts (usually 5-6 alerts).

Example: Under System32 folder I changed the .exe on wuauclt.exe to .doc. Screen shot shows this. I can reproduce this every time choosing a different file to rename. You can see the alert for winlogon.exe attempting action "Create file", but denying the rename does not work, even when I refresh explorer. Also, I notice the rename takes place a couple seconds before the first MD alert! Again, maybe there is a conflict with VBox, but could someone please test this on their normal Windows (Real system) setup running as administrator? Thanks!

 

Hi wat0114,

Not exactly your setup but it doesn't happen on my XP SP2 host with MD 2.2.2

I don't know why you have winlogon trying to do the file create, when I do it with Explorer it's (naturally) that app that appears in the log.

 

Not a leak, but rather a rule issue. Your File rules for explorer.exe are probably too permissive. I would take a look at them. Delete all existing File rules for explorer.exe and you will get a better result. Be sure to back up your rules first.

BTW, when you block those actions you see by winlogon.exe, you're also blocking Windows File Protection from restoring the system file you modified.

 

i can confirm this also , do as u advice and file became *.doc...weird..need to look deeper in it

 

i try it on 2.3.3 and didnt set/change any rules for explorer.exe (default rules)same goes for winlogon , and i get same issue in here...

 

Thanks all for checking. Maybe a rules issue, but I did not, as far as I remember, change anything regards to explorer.exe from the defaults. Also, MD is alerting me on it so why would it not stop the action when I deny, and why does the alert happen after the rename takes place No time right now but I'll check this a little later this am.

Thanks again all!

You're right, I don't know why winlogon.exe is the parent file here. This has me baffled a bit too, but I think I know the reason. More later.

 

Maybe.........svchost.exe is also the one to rename wuauclt.exe.Just I guess .

Explorer.exe is the most suspicious application.It always has privilege in default rule.

 

where is XLion , MD developer to answer this things coz it look as a default setting is wrong ,noting to do with user made maybe a wrong rule

cheers

 

nick s you're right - not surprisingly - it was a too permissive rule, specifically with explorer.exe, and maybe my fault, although I don't remember creating the rule. I found a global allow File rule under explorer.exe's File tab. After deleting it and trying the rename again, I was alerted by explorer.exe attempting a Write file action (rule was System execuatable files, c:\Windows\*;*.exe) on the the target file. The alert was immediate and I had no problem stopping the rename with one deny click

So maybe it is a default rule in MD causing the weakness?? Oh well, we'll see.

 

The default File rule for explorer.exe is overly permissive IMO. I don't remember which MD build introduced it as a default rule. Older builds did not include it and I delete it whenever I do a clean install of MD. The idea behind it was, probably, to reduce alerts and shift the burden of system protection to other rules.

 

i did what u write and it doesnt seems to work or its my fault , can u write step by step how to?

10x

 

1. Delete the default File rule (and any other wildcard .exe rule) for explorer.exe
2. Try to rename wuauclt.exe

 

that what i did , since it doesn't work for me, and file got renamed i thought i missed something .....

 

What does MD do when you try to rename wuauclt.exe to wuauclt.dll?

 

i try to rename it to doc file , its bring up winlogon and this windows file protection after that.... at the end (after rapidly ) press deny , it rename it.
its a flew in MD i am sure , since my MD is fresh install for 2 days.

cheers and 10x mate

 

nick s that is the exact rule I had and deleted to fix the issue. Thanks again!

Demoneye, check the logs to see which rule is causing the alert, but I think you probably have some rule for explorer.exe somewhere that is too permissive. That has to be the problem.

 

You're welcome wat0114 .

 

If you don't mind, I would like to take a look at your ruleset. Export your rules, zip the file, upload it somewhere, and PM me the link. I'll import them and see if I can spot a problem.

 

many 10x for the help nick , much appreciated , i wounder what Xalion , MD developer got to say about it ...


cheers

 

It is a rule set issue. On my setup MD intercepts the file name changes no problems at all. I tried with both default deny and on MD normal ask pop up mode.

 

any solution to that ? coz its bother , what more MD default rules set same bad as this one................


cheers

 

solution is use custom rules instead. Default rules are irrelevant.

a bit off topic there SSJ. this thread is more about the working ability of rules sets. has nothing to do with malware if it can bypass MD or not.

 

did you not read thru the thread? it has been worked out that it is to do with the rule settings. has nothing to do with Possible Leak of malware bypassing.

at this point in time I think demoneye and every one else is more interested in getting rule sets working properly, rather than you telling us some thing we already know about if malware can bypass or not.

 

You are right. Explorer.exe have permissions to access all files and folders in default rule set.

When the wuauclt.exe is renamed, winlogon.exe will copy a new one from the dllcache.

Thanks,
Xiaolin

 

Hi xiaolin,

sorry about the thread title. I don't want to tarnish the reputation of a terrific product, but I was concerned about the ease with which the files could be renamed and it turns out the permissive default rule for explorer.exe is the culprit. I realize it takes some previous actions to occur beforehand regarding malware for the potential renaming of a file, but will you consider removing that permissive rule from the defaults?