Can anyone tell me what this file mfeavfk01.sys is?

[DannyBoy_Chicag]

I came across this only by chance as i ran Autoruns (Sysinternals Autoruns by Microsoft), and says file not found and also has a registry entry related to it in the mcafee registry folder. "I do not use cleaners or anything to do any cleaning to the registry", besides using the McAfee cleaning tools which even using that, I uncheck the registry option in fear of not knowing if it will delete anything it should not.

Googled all over and shows to be apart of mcafee, but checked here in the forums to find nothing regarding the file although i have seen that the file mfeavfk.sys seems to be a legit file.

what is the file mfeavfk01.sys for and is it a legit file?

Concerned that it is possibly a bad file seeing that "01" after the name or was it part of the install or removal process using the removal tool and re-installed after i had done a complete wipe of my computer months ago and had to remove the Mcafee Plus that came pre-installed and never used as I  put my Mcafee Total Protection back by downloading from my McAfee account online?

Virtual Tech runs and always stated good...

Thanks

[Hayton]

You know, I wondered if anyone else would ever find this discrepancy .... stand by for a very long answer.

I noticed it some weeks ago in Autoruns and asked about it in one of the conference calls. They asked me to send in this (nonexistent) file so McAfee could analyse it ...

After I raised the issue I was sent a text file with the title "McAfeeDellFix" with instructions on changing registry settings which was ostensibly meant to cure the problem but which doesn't actually mention mfeavk01.sys at all .... so now I get mfeavfk02.sys as well as mfeavfk01. And mfefirek01.sys as a bonus.

These entries appear in Autoruns because there are registry entries for them : mfeavk01 is to be found at

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mfeavfk01\.  The files themselves do not exist. Note the "AltServiceName" entry.

Like you I am suspicious about this entry and somewhat bothered that I still haven't received a proper explanation of why it appears in Autoruns. If you like I will add to this thread the message I originally posted in the Internal section (which no-one answered).  This has a number of references to other AV products detecting the file as Suspicious (in some cases as a rootkit) and showing it as a Hidden Process.

Possibly McAfee isn't cleaning up correctly after an update, because I came across this instructive paragraph in an old post (about mfehidk.sys) from the Business section :

The registry key listed is created by us, and notice the numeric appendage? mfehidk01.
We create this key when that driver gets updated. It allows for another instance of the driver to exist in memory, while the older instance gets put into a pass-through mode. It's a clever way to update drivers without requiring a reboot.

I like that explanation better than the alerts returned from GMER and AVG -

---- Services - GMER 1.0.15 ----
Service (*** hidden *** ) [MANUAL] mfeavfk01 <-- ROOTKIT !!!

and from TDSSKiller -

14:54:26.0587 1856     Suspicious service (Hidden): mfeavfk01
14:54:26.0618 1856     mfeavfk01 ( HiddenService.Multi.Generic ) - warning
14:54:26.0618 1856     mfeavfk01 - detected HiddenService.Multi.Generic (1)

Message was edited by: Hayton on 16/03/12 03:45:26 GMT

Message was edited by: Hayton (correcting typos in file names)  on 17/03/12 04:05:26 GMT

[DannyBoy_Chicag]

Hello Hayton,

Thanks for the quick reply and I am wondering after all i have read above from your addressed statements that its safe to say that there is no need to worry or freak out about then?, lol

Anyhow like you i have been suspicious as i have been sitting on this question for several months now and have searched and Googled to no end and just waited for some kind of query regarding this and honestly i just got to the point that if im the only one with this issue, maybe i did indeed have something hidding deep inside the computers. I decided to wait no more and just give it a shot to see if maybe somebody might be aware of the situation or reconize the file problem and here i am.

Actually i only came across this problem because i seen that there was a problem with Win7 SP1 Update when they pushed it out and there were three(3) system32  Driver files that never propagated from the update and instead of the files getting put into the "system32/Drivers" folder they were dormant in the "System32/Driverstore/FileRepository" folder and needed to be copied into the "System32/Drivers" folder manually as they did not exist.

F.Y.I. ---Some of the users may want to try  (Sysinternals Autoruns by Microsoft) as to the issues regarding the missing files with Win7 SP1 Update were not due to my client as it is a problem with Microsoft and the Autruns program has some nice features for novice users to have that can be used to also see if anything is just not right or you do not reconize certain software that may be running and can even check for valid files, missing files or Valid file signatures.

Well, Back On topic Like you i also ran "GMER and TDSSKill" among other top reputable scanners and procedures and my systems have always been clean other then this issue which has been an ongoing quest to try to find any information relating to this file or this issue other then getting the same logs created like the ones you posted by running "GMER AND TDSSKill" while making me raise an eyebrow and saying"Hmmmmm! , Interesting!!!", and of course the mind flooding with everything to try and figure things out and thinking do i really have a root infection? Even checked User Agents in all my browsers as those can be a good hidding place for bad things!

So It seems that im the first to bring up this issue and wondering if this thread would be more useful in a better catagory? Possibly so other users can be aware of it and also respond. Would it justify to the developers that theres an issue that needs addressing then? I know from experience that if there are complaints or compiled issues alot of times things get looked into faster, as issues where it seems there is little feedback or complaints do not get addressed as they tend to not fall on the priority list.

So do you foresee a possibility to re-hash this subject matter the next time you have a conference?

Is it even a matter to worry about?

I would just like to be reassured 100% that all is well malware/virus/etc wise and that there is no malfuntions going on due to this process!

Well at any rate thanks again for your reply and at least someone knew what i was talking about as when i went to the live tech support they once again had no clue and just wanted to do the same old dance of things like run virtual tech, which is always stating all good, and then always want to connect remotely which i still have a sour taste in my mouth which i learned long ago never again as they always made things worse!!

Have a great day Hayton and sorry if this seemed to be lengthly as well. If by chance you do come across any updated information please let me know...

[Hayton]

I suspect that if the registry entries are removed the problem will just go away. Of course, McAfee Access Protection needs to be turned Off to enable that removal, and the registry would have to be backed up first, just in case. I might try it later.

The problem is not, for me, one to worry about. But then I'm not seeing ROOTKIT!!!! alarms in any of my scans 🙂

[DannyBoy_Chicag]

Hello Hayton,

Im with you full of when it comes to not seeing any "Uglies" or RootKit Alarms in any of my Scans!

If or when you get a chance to try and remove the entry in the Registry please let me know how it went and if any non-wanted events take place. I know from everything it sounds as it may not even be a big deal since really no threat of it, or at least for now that is...

But here is a question, knowing there is a live Registry entry and obviously looking to call on the File "mfeavfk.sys" which prompts file not found, What is there to stop a malicious file to be named the same file name? Could this actually be used as an exploit? Kind of currious to that possibility

Hope thats not a stupid question !!!

Thanks Again

[Hayton]

I've put the question in for the call. Let's hope I get an answer. I've also asked about the registry entries, and I don't intend to touch the registry until after this has been discussed.

Your question about an exploit : I don't think so. Any file that was created and put into the location pointed to by the registry entry would have to be a valid McAfee file. Just changing an entry in the registry would not be enough to include a unsigned driver file and, in any case, there is a repository of information which McAfee uses (in MVT and elsewhere) about which files and registry entries make up the McAfee application. Any file not included in that repository which someone tried to substitute for a genuine McAfee file would, I think, cause an error. In addition, McAfee Access Protection (see in the Security Center) prevents changes to or deletion or replacement of McAfee components.

That's a bit tortuous, but in essence : no, I don't think an exploit of the kind you had in mind would work.

Final thought : when I first came across this I went into msconfig and, in Boot.ini, selected the '/Bootlog' entry. I ended up with a text file named ntbtlog.txt which listed all the files being loaded, or not loaded.

In several places were the two following entries :

Did not load driver \SystemRoot\system32\drivers\mfeavfk.sys
Loaded driver \Device\mfeavfk01.sys

But there were also exactly the same number of occurrences of

Loaded driver \SystemRoot\system32\drivers\mfeavfk.sys

Enable boot logging and look at the output and you'll probably see the same.

[exbrit]

Just a thought here directed to the original question.

When you see a number, in this case '01', attached to a file name that already exists (without the number) all it means is that somehow remnants of a previous version were left behind and Windows, not allowing duplicate entries in certain directories, assigned it a number.   Normally a warning should have appeared somewhere alerting you to that fact, but as with all things Windows, that doesn't always happen. 

In the case of the one above it can be deleted.

Message was edited by: Ex_Brit on 17/03/12 4:56:13 EDT AM

[Hayton]

I don't think it's Windows doing the filename assignation, but McAfee.

We create this key when that driver gets updated. It allows for another instance of the driver to exist in memory, while the older instance gets put into a pass-through mode. It's a clever way to update drivers without requiring a reboot.

If this is correct it's a way of updating a driver and somehow substituting the ...01 version for the original version within the running McAfee program. The existing process isn't exactly killed off but goes into "pass-through" mode, which I would like explained. It seems to be relegated to the shadows and hidden, but is still running - hence the detection by AVG, GMER and TDSSKiller. Hidden Process which can't be killed off (Access Protection?) = Rootkit. That's my best guess anyway. At shutdown/reboot things should be tidied up (and I assume they are) but still we get these registry keys left behind pointing to non-existent files. That should be easy enough to fix in a later release.

[exbrit]

Strange.   I haven't observed this in my installations at all.

[Hayton]

Have you looked in Autoruns or enabled the /Bootlog switch?