Dangerous trojans on the loose

AE's message "Copy" refers to the attempt to copy to the HD from removable media, or download from internet (copying from a web site to the HD)

The .gif is a spoofed file extension - the code is executable binary. No image viewer was involved - the file was just blocked from downloading (being copied) because it is an executable.

Please see my test again and check your computer for any of the files listed.

The fact that you detected that "MS.....update.exe" file would indicate that the original downloader "cnte-oiduuyes.gif" did run. When I ran the test, none of those files downloaded until "cnte-oiduuyes.gif" executed. But maybe not. Please check.

Redirect Test

regards,

-rich

 

Are u sure about this? gif file was jnfact there in my Temp Internet Files folder.
SSM free should not give me an alert if gif file runs?
What will happen if I double click the gif file my self?

BTW I tested it with ShadowUser and I have already rebooted my PC until now. No more files.

 

If the file was cached, then it did run. that is the only way the other files could download. I don't know how SSM works, so I can't help you here.

Whatever program *.gif is associated with will attempt to open it, but since it is not an image file, it will either display as text or you will get an error message.

Then you have no worries!

regards,

-rich

 

I also have this IP range blocked:

69.50.160.0 - 69.50.191.255

It's been blocked for quite a while.

 

Ok, I think I need some more work. Can u give me some links about these spooped gif executables especially some sample files? Thanks

When I clicked over it, FS Image Viewer opened it but there was no image. Same when I opened it with windows builtin image viewer. No pop up from SSM.
So AE will deny this action?

BTw I have trouble to get the redirect URL. I have to change my proxy again and again. How can I get the direct link of this drive by download?

Thanks for all the help.

 

See this thread:

JPGs are Executable!
http://www.dslreports.com/forum/remark,13689141?

In the recent *.ani exploit, the script was embedded in a .jpg file. In this case, it didn't matter what the file extension was.

AE doesn't care about the file extension - if the code is binary executable, it blocks.

That file would not get on the system in the first place, so I couldn't try it with an image viewer.

However, testing samples in the past - .jpg files spoofed as executables, for example - double clicking on my system opens the file in Photoshop which returns an error, "mal-formed file" or something to that effect.

Remember, the file extension tells Windows what program to run. So, clicking on an executable .jpg file won't "execute" the bad code; rather, it will attempt to open in the particular image program it is associated with. Same thing with .txt. Rename a *.exe file to *.txt, double-click on it, and it will open in Notepad.

Caching the file by the browser is different, as we've discussed in the WormGuard thread.

Sorry, I don't use a Proxy. Someone else will have to help!

regards,

-rich

 

Thanks Rmus.

So if a malicious exe is spoofed as jpeg or txt, double click by user will nor run the malicious code. Am I right?

 

From all of the samples I've seen, that is correct.

regards,

-rich

 

Pardon me for butting in...

So if a malicious exe is spoofed as jpeg or txt, and some process show how renames it to an .exe, will AE spring into action just because of "rename vacation.jpg cmd.exe" or "rename vacation.jpg control.exe"?

Mike

 

Thanks for tolerating me so long.

 

When I ran a test to deliberately get infected I used Proxomitron's logging function to record the HTTP traffic. I've attached it here as a text document. Be careful going to the locations inside the document unless you are well protected and have disk imaging software, etc.

(I haven't edited out any Proxomitron filter match info and the max-age headers I modify on the fly to increase caching) Lots of activity from 69.50.172.115...I think I'll add the range in SirMalware's post above to my firewall blocking too.

 

Hello, Mike.

I'm answering this over in the AE thread, so as to keep this thread on topic.

thanks,

-rich

https://www.wilderssecurity.com/showthread.php?p=1010399#post1010399

 

This is superb, noway!

The order of the IPs matches my alerts using Kerio to stagger the outbound attempts.

Can you determine why this happens when you click on the link from Google, whereupon the Sloan page redirects to hxxp://85.255.115.221?

Yet when copying|pasting the link directly into the browser, we don't get the redirect?

I've compared the code pages both ways, and see no differences.


regards,

-rich

 

I think so. I tried blocking IE's (outbound) Referrer header using Proxomitron and I don't get redirected. So I think that the (compromised) web server at Sloan's is checking my referrer when I go there and the browser doesn't transmit the Referrer header if I go there from the address bar whereas if I go there from Google, the web server can tell. As a further test of this, I used Proxomitron to spoof the Referrer. If I substituted the true value the browser sends with stuff like "www.apple.com" or "http://www.google.com" I don't get redirected. If I spoof as the search results page ("http://www.google.com/search?hl=en&q=sloan's%20nursery") will the redirect happen. So it is being rather selective with whom it infects.
I tried going to http://search.msn.com and made the same search...the Sloan's site is the first link there too. I get the redirect here, just like at Google. So Google is not at fault for anything...the referrer header is just being checked.

 

OK, I disabled Referrer Logging and Automatic Redirect in Opera, and clicking on the Google link, I don't get redirected.

Enabling Referrer and leaving Redirect disabled:

http://www.urs2.net/rsj/computing/imgs/sloan-redirect.gif
___________________________________________________________________

The fact that Sloan's web server is compromised, we would never be able to tell from their page code.

Good sleuthing, noway!


regards,

-rich

 

Hey guys, I am the webmaster for sloantreefarms.com. Not sure what is going on with the server, but I have contacted my hosting company so hopefully they can help me out. The site is on a shared server, so am I correct to assume that all the sites hosted on this server will be affected, or will it only be this one domain?

I will let you know what they find out.

Thanks to the person that emailed me about this.

Jeff

 

"The site is on a shared server, so am I correct to assume that all the sites hosted on this server will be affected...."

If you had the URLs of the other websites we could perform a test very quickly.

 

Well here are a couple that are on the same server.

http://sundownertruckaccessories.com/

http://monte2007.com/

I already heard from tech support from my hosting company. They said they are investigating. Perhaps they might even have it fixed by now.

 

Just tried your site and the problem seems to be fixed. No longer getting the malicious redirect to Inhoster.com.

 

Is there any way you could have your hosting company tech support document when they found and how they fixed it?

I sure the posters in the thread would love to see that.

On the other hand, "normal people" like me, would not have much of a clue.

Mike

 

Very good idea!

 

Hmm...some interesting stuff here...

A Google search for "Sloan's nursery" did not turn up anything untoward on my system, and the first result went straight to sloantreefarms.com without any redirects.

While Google have been known to add occasional redirects (via Javascript using onmouseover), the type of redirects mentioned above seem far more likely due to malware present on the system modifying webpages like Google (a variation of a "dropper", trying to download malware by misdirecting the browser rather than making a separate network connection itself).

Noway, I note that you have had previous issues with Google searches so could this be a new manifestation of an old problem?

Reviewing the HTML source of Google's results (or posting it here for others to check) may help also, but it is pretty complex so please take care to only include the part covering the actual link. In my case, this was (with line breaks added):

Code:

<div id=res>    <div><div class=g><h2 class=r><a href="http://sloantreefarms.com/" class=l>
SloanTreeFarms.com - <b>Sloan's Nursery</b> and Christmas Tree Farms</a></h2>
<table border=0 cellpadding=0 cellspacing=0><tr><td class="j"><font size=-1>
Welcome to <b>Sloan</b> Tree Farms and <b>Nursery</b>, located in Bothwell, Ontario, Canada.<br>
<span class=a>sloantreefarms.com/ - 7k - </span><nobr>
<a class=fl href="http://209.85.135.104/search?q=cache:z3JnOVdFmcMJ:sloantreefarms.com/+sloan%27s+nursery&hl=en&ct=clnk&cd=1">Cached</a>
 - <a class=fl href="/search?hl=en&q=related:sloantreefarms.com/">Similar pages</a></nobr></font></td></tr></table></div>

Note that the only IP address shown refers to Google's cached copy at 209.85.135.104.

 

I asked them for details. If they can tell me anything I will let you guys know. Thanks again for the heads up.

 

Hi Paranoid, welcome to the thread here.

https://www.wilderssecurity.com/showthread.php?t=175666

 

This and the castlecops "search.ug" example from 2005 are both examples of server hacks. (Much more is known now about the "search.ug" problem and a Google search for the 2 search terms: search.ug htaccess will provide details). Although we hope to find out more info about the methods used for this new hack, the problem has been fixed by the web hoster and you should not expect anything unusual whatsoever when trying to reproduce what was seen in the past few days in this thread.