Re: HOSTS File Hijack/Changed DNS Entries

[Russ <[EMAIL PROTECTED]>]

Ok, so some more information is coming but its still not clear.

Delude certainly sounds very similar to the reports regarding the hosts file. All of the hosts files I have received have been very similar, with the only difference being in the address used for the elite system name. All point to 207.44.194.56, but no doubt some point elsewhere. All of the reports I received today contain addresses that are resolving to EV1.NET IP addresses.

Now, its not clear whether or not this has anything to do with the registry key changes. I won't report those again here, you can view http://ntbugtraq.ntadvice.com/default.asp?pid=36&sid=1&A2=ind0310&L=ntbugtraq&F=P&S=&P=1048 (probably wrapped) for those details. Some people have reported not seeing the original message, I can only assume your AV product decided not to put it through to you.

I have reports of systems which have experienced "both" problems, and others which have not seen the hosts file, only the registry changes. I also received a report from Steve Shockley yesterday which suggests there's an involvement with another large hosting provider's banners. We are trying to verify whether those are still active now. He was not the only person to identify the same provider's cookie as being common amongst machines which had modified registry keys.

It appears as if a web page is causing an executable to be downloaded, executed, and then deleted.

To determine if you have the hosts file effects, do a search on your registry looking for the keyword "Database" and see whether or not the hosts file directory hasn't been changed to %systemroot%\help, if so, change it back to %systemroot%\system32\drivers\etc and look in the help directory for a rogue hosts file. One report indicated the file was called hosts.dat, in which case it wasn't working. The file is just text, but if the registry key is changed to point to it windows will use it. I've also had reports of the regular hosts file being altered.

Most systems where outbound DNS was prevented at the gateway did not resolve local systems (or any system) after they were infected. Default Deny is the best practice, inbound and outbound. If you cannot default deny, then deny outbound DNS to find affected systems.

The script is in jscript and redirects to another page (which I have not yet seen the source for) which downloads a program called aolfix.exe into the temp directory and executes it. There are many past executables with that name, and there's no reason today's problem might not have many names also.

More as we get it.

Cheers,
Russ - NTBugtraq Editor

-----
Wondering as to whether the list is running? The NTBugtraq archives are
updated first before messages are emailed to subscribers. Check the
archives first to see if you have missed any messages;

http://www.ntbugtraq.com/archives

-----