On Saturday evening I received a mail from one of the people that calls me in a couple of times a year to check the computers of his wife and him, and he wrote that he was possibly infected as Spybot S&D generated a warning on one of his scans. I've worked with Spybot S&D quite a lot and find it one heck of a tool, so I took his mail rather serious. I proposed to come over Sunday afternoon after working an early shift, to see what the problem was, and how to get rid of it.
Since I asked him to send me all information about the possible virus/trojan before coming over I packed my VundoFix tools and updated HiJack!This and all my other anti-spyware tools. When I arrived sure enough S&D reported a win32.onlinegames trojan to reside in pfmapi16.dll. I ran HiJack!This, took a look at the logfile created and found no trace of Vundo infection. I ran a specific scan for Vundo, but that too was negative.
Even after several attempts to get S&D to clean or remove the trojan, it remained present. I decided to verify the infection and sent the file to Virustotal for a second opinion. Out of 30 scanners that analyzed the pfmapi16.dll file, none reported it as being infected. Strange, very strange. This leads me to believe that a false positive is generated on the DLL file, but as I promised my "client" I would verify on other machines. Note : detection for Win32.OnlineGames was added to Spybot S&D on August 1st 2007.
I called B&H to see if I could pop in and verify the possible false positive on any of their machines and they said I was welcome. D&M were also on their way, so it would be a nice meeting. I checked two machines, no Win32.OnlineGames trojans found, but those are english XP machines, not German ones. When I checked my machines, none of the S&D installs gave me a trojan infection. This only makes me more convinced that there is a possible false positive on a german XP version in the latest detection updates.
Today I found a post on the forum where another German S&D uses claims to have a potential false positive on a file named Ctrsct16.dll, which also resides in the system32 folder. He has sent the file in for further analysis and I'll be doing the same tomorrow, as I think we are both seeing the same incorrect detection.
Will be continued...