I wanted to submit a URL for testing but canceled out of the Report False Positive Forum because I don’t understand some of the stuff that you are supposed to fill in. Can someone tell me the minimum amount of information that must be submitted in each form field? How do you just report a URL for testing?
I have been going to that site with no problems for about five years. It’s just a bunch of Flash games from a site in the United Kingdom. There are some banner ads on that site but my family and I have never clicked on them. The “Trojan Horse” being reported is a sign of the JS:Downloader:FT Trojan that started being blocked on the site, December 22nd and again today on December 26th.
I also told Mousebreaker’s site administrator through E-Mail about the aborted Trojan. I have heard of this JS Downloader Trojan before. It doesn’t show up most of the time when you go to the site, (The Avast Warning about the Trojan horse.) So I am hoping that Mousebreaker will address the issue, but I think they might be working with a skeleton crew because of the Christmas Holiday. We have just been clicking on “Abort Connection” when it shows up.
Just to emphasize, Avast has stopped whatever this is. I have not been infected. What I was asking about is when you submit a False Positive Report, there is a form that comes up from Avast that says things like:
Program Version, along with about 5-8 other data fields with a check box that says, “I know what I’m doing.” And I did not know what to put in the boxes for the testing of the URL. That’s what I was saying.
You will have to be more specific on the URL as I have visited the home page you gave and no alert.
Check the avast! Log Viewer (right click the avast ‘a’ icon), Warning section, this contains information on all avast detections. C:\Program Files\Alwil Software\Avast4\ashLogV.exe
Or check the source file using notepad C:\Program Files\Alwil Software\Avast4\DATA\log\Warning.log and copy and paste the entry.
When posting URLs to suspect sites, change the http to hXXp so the link isn’t active (clickable) avoiding accidental exposure.
12/22/2009 7:17:49 AM SYSTEM 1404 Sign of “JS:Downloader-FT [Trj]” has been found in “hXXp://statcstat.com/news/go.php?sign=29bcb362de2bcd871c59babfc352cdd5&s=5715” file.
12/22/2009 4:27:54 PM SYSTEM 1404 Sign of “JS:Downloader-FT [Trj]” has been found in “hXXp://statdstat.com/news/go.php?sign=0097d2b60237d0563dc070bc2fb1860a&s=5715” file.
12/26/2009 1:54:32 PM SYSTEM 1392 Sign of “JS:Downloader-FT [Trj]” has been found in “hXXp://statsistats.com/news/go.php?sign=5dd27a38c9fdcc4ba888ab6570ca7e7b&s=5715” file.
This site is the issue, hXXp://statcstat.com (hXXp://statdstat.com and hXXp://statsistats.com would seem to be more of the same) as it has in the past been used to serve up malware and avast is effectively preventing that possibility.
So I don’t know if that/these has been placed there legitimately by the site (which I doubt given its history, see below) or inserted by a hack, trying to make the thing look like some sort of legit stats counter.
The third one statsistats.com seems to be a new one as the others are now regularly seen as malicious and blocked and currently there are no other google entries for it, but I suspect that will change as its history is also built up.
I did send the log to Mousebreaker with the hXXP stuff in place to keep it secure. I agree, that does not seem to be the kind of site that would insert malware ads. Good to Avast for stopping it!!! Just out of interest, what would be the next step that Mousebreaker could or should take? Also, how bad is this particular trojan?
This is commonly down to old content management software being vulnerable, PHP, Joomla, Wordpress, SQL, etc. etc. see this example of a HOSTs response to a hacked site.
We have patched up the server and we found a weakness in PHP which was helping aid the compromise of some domains. We updated it, and changed some default settings to help prevent these coding compromises. The weaknesses were not server wide but rather just made it easier on a hacker to compromise individual end user accounts.
I suggest the following clean up procedure for both your accounts:
check all index pages for any signs of java script injected into their coding. On windows servers check any “default.aspx” or
“default.cfm” pages as those are popular targets too.
Remove any “rouge” files or php scripts uploaded by the hackers into your account. Such scripts allowed them to make account wide
changes, spam through your account, or spread their own .htaccess files through all of your domains in that end user.
Check all .htaccess files, as hackers like to load re-directs into them.
Change all passwords for that end user account. The cp password, the ftp password, and any ftp sub accounts. Make sure to use a
“strong” password which includes upper case, lower case, numbers and NO COMPLETE WORDS OR NAMES!
This coupled with our server side changes should prevent any resurfacing of the hackers efforts. In some cases you may still have coding which allows for injection. All user input fields hidden or not should be hard coded, filtered, and sanitized before being handed off to php or a database which will prevent coding characters from being submitted and run through your software.