MSE removes some user-defined HOSTS entries

Joe,

As noted, I am reporting the article on "face value" and welcome refutation if it's incorrect.

One question:   Have you checked your MSE exceptions/exclusions to see if the HOSTS file might be listed there?

I dunno about this one.

Initial reports indicated this was true for "Windows Defender" (the re-branded name for MSE in Windows 8), but your link claims "Microsoft Security Essentials (MSE) in older versions of Windows also takes care to reset entries for these domains."

I'm not seeing that with Win 7.  I manually edited my HOSTS file several hours ago to add "ad.doubleclick.net". It is still present, and a quick scan of MSE does not remove it. Perhaps it will be gone later (I will check tomorrow, and report back).

Despite what your link claims, I am seeing nothing in my MSE "History" about a possible HOSTS File hijack, at least not in Win 7. I have yet to check this out in XP.

As a side note, I observe that both WD and WinPatrol both always alerted me to changes whenever my HOSTS file was changed (be it due to a MVPS update or a manual edit) on my XP system. I have never seen such alerts on my Win 7 systems, and have received confirmation from others that this is their experience also.

It's all very curious.

One question:   Have you checked your MSE exceptions/exclusions to see if the HOSTS file might be listed there?

Yes. It is not.

Thanks ky331. I fully realise you are only the messenger.

My initial attempts to add ad.doubleclick.net to my XP HOSTS file remain successful, albeit only after a few hours.

Even if MSE were deleting these few domains (only ad.doubleclick.net, Facebook, and Twitter have been identified so far, AFAIK) from a HOSTS file, I fail to see this as a significant blow to the utility of using a HOSTS file, given the huge number of bad sites that continue to be included.

The supposed rationale for deleting these domains is that they are very common targets of re-direction by malware, using the HOSTS file.  I have no idea if this is true. Frankly, I view this all as a tempest in a teapot.

What I do object to are suggestions for mitigation out there to:
- Switch to another AV over this supposed "outrage".
- Exclude you HOSTS file from MSE. Bad idea!

And I question the motives of those who make these suggestions.

Joe,

I really have no idea what my motivation or intent was in posting the link to this article... other than I found it interesting.

Certainly, if the assertion as presented was false, I welcomed a refutation.

I would have no qualms with it if, like WinPatrol, it merely advised the user about a change in the HOSTS file, which the user could then either accept or deny.   (But as I understand it, for simplicity and ease-of-use, MSE makes all decisions on its own, so as not to "burden" the user.)

As long as the claim is that it's only looking for specific sites like FB, Twitter, & Doubleclick, it would seem simple enough for MSE to differentiate between assigning 127.0.0.1 (blocking these sites) vs. other assignments (possible hijacking of these URLs).   While malware could certainly block FB [via the local feedback loop], I think such blocking is more likely user implemented, which should be acceptable.

Like you, I would neither want to switch AVs nor exclude the HOSTS file from monitoring, based on this issue alone.   But if my AV were "tweaking" my HOSTS file, yes, I'd certainly want to know about it.

Joe,

I've stumbled on another article which confirms the allegations for Windows 8 RTM (where "Windows Defender" is the Windows8 name for what used to be "MSE" in previous Windows versions) ---

but in the comments, notes that "MSE under Windows 7 does not do the same though".

http://www.ghacks.net/2012/08/19/you-cant-block-facebook-using-windows-8s-hosts-file/

David:

Thanks for that info.

I must apologise if it appeared I was critical in any way of you for starting this thread, posting links, or suggested you were spreading misinformation on this subject. This was not my intention.

I objected only to the claims in the links that suggested MSE in Win 7 and earlier versions were also altering the HOSTS file, because I could not duplicate this on my XP system, and on 2 Win 7 systems, at least not for ad.doubleclick.net. (Which is actually included in the latest MVPS Hosts file). I certainly was not questioning your motives, nor the importance of this topic!

MS has certainly muddied the waters by renaming MSE in Win 8 (to Windows Defender, which was previously only an anti-malware program in prior Win Versions). I have no way of knowing what changes were made to MSE/Windows Defender for Win 8.  But to equate it with the MSE of prior versions, without solid evidence, seems wrong.

My concern was that folks would see these reports, and abandon a  good freeAV, or cripple its ability to detect changes to the HOSTS file by malware, without a proper understanding of all the isssues or repercussions involved.

I could, of course, be wrong, and will be keeping a closer eye on my HOSTS file for changes or deletions. (Not a particularly easy task, given the number of entries!)

In Windows 7, MSE does alter the hosts file.  In my work environment, a user had taken it upon themselves to mess with the hosts file.  They complained that the hosts file was unable to retain the changes because MSE was altering it.  I was able to confirm this on all other 14 workstations in the office that I have administrative privileges for.

Sorry, Joe,the article David posted appears to be correct.

Hi, Hoop Geek, and welcome to DCF:

Thanks for the input. I do not dispute your experience in a "work environment", but I continue to question whether MSE is responsible for blocking changes to the HOSTS file in Win7.

In my 2 home Win7 systems (one using the Home Premium version, and one the Professional) both use MSE and both use The MSVP HOSTS file. Since the original article mentions "Twitter.com"  as one of the edits that is being altered by MSE, and since my HOSTS file does not include this, I added it to both my systems' HOSTS files.

It remains there still in both systems' Host file.