Matraex, Inc Blog

Today a customer called me about a PHP website that was popping up viruses all over the place.

I loaded up the site and there it was,  the page was immediately redirected to a spyware / virus type site that tried to convince me to download their software to fix a problem.  Since I knew better I carefully answered the browser prompts to make sure I closed out and left the page without opening anything malicious.
Then I went back to the page that had the problem and tried to load it again.  But the problem was GONE!

After a bit more investigation I found that the people who wrote the “virus” dropped a cookie on my machine and made sure they allowed me back in the site.  I am sure this trick helps them to keep the “virus” on a site for longer because the site administrators may not recognize it as an on going problem (or even a problem that their site caused).

In digging I found that each PHP page on the site had some PHP code added to the top of it.
something like

This was on a single line at the top of the file and even the administrator who had noticed the odd code at the top passed over it not thinking it was malicious.
However,  the text inside the “encoded” string was VERY malicious.  I decoded it and found several PHP functions and additional encoded strings.

I decided it wasn’t worth figuring out what all they did with the code but instead decided to just clean it up.  I assumed that the code probably helped “replicate” itself by checking that ALL other PHP pages on the site also had the same code in them.  So if someone removed the code and then the code was run on another page it put itself back where you removed it.

 Anyway,  pretty sophisticated but it was easy for me to find the problem just opened and looked at the PHP file and saw code that shouldn’t have been there.

A cool way that I found where the problem was before even opening the PHP file was to use HTTPWatch to see which exact files were downloaded from which site in the browser.  I use the free version of the softwar and it has met all my needs so far.  It is similar to firebug in FireFox.

We have a custom ActiveX Applet we built which was randomly throwing this error, it was happening on a new machine only and it was rather random.  Automation Error: the object invoked has disconnected from its clients

Sometimes the error did not happen at all.  The new machine had a fresh install of XP on it.  Lots of other new XP machines were not running into the problem.
We researched and found that the problem always happened during some sort of usage with the “MSINET.OCX” activex object.  This led us to an article on Microsoft’s support site with this article.

http://support.microsoft.com/kb/254908

Turns out the new machine was dual core which somehow caused problems with threading of the object, the problem was fixed on a later version of Visual Studio so if I redeployed the application with the latest MSINET.OCX object it should have worked.  As a quick fix though I downloaded a later version MSINET.OCX to the machine and reregistered it so that the system would use that object.

regsvr32 /u msinet.ocx
regsvr32 msinet.ocx

Voila,  no more random error.