Solved

WSA missed a trojan

  • 1 November 2012
  • 39 replies
  • 587 views

I've been a dedicated Webroot user for 3 years... until now. I downloaded the SecureAnywhere update a few weeks ago, and since then the service has basically stopped working. SecureAnywhere never found any viruses, spyware, or malware, despite repeated and regular scans. This would be great if I didn't know for a fact that my computer was infected. In the last few days it has gotten to the point that every other time I click on a search result from Google, I am taken to a completely unrelated website.
 
Since my subscription ends in a couple days, I decided to download the free trail for AVG Internet Security and see if it would help. As soon as I started the program, it detected and removed a trojan, which Webroot hadn't detected during the scan a few hours ago. I hadn't even run a scan yet! As soon as AVG removed the trojan, the problem stopped.
 
I was a huge fan of Spy Sweeper, but SecureAnywhere turned out to be a waste of my time (and money). I used to be a huge Webroot fan and recommended it to many others who had issues, but now I'll be recommending for everyone using it to switch.
icon

Best answer by gpb500 5 November 2012, 01:54

View original

39 replies

Userlevel 4
Thank you for the information
Userlevel 7
Hi Muddy
 
You are absolutely correct in that BitDefender & WSA to not sit well together...and if I understand it correctly it is BitDefender that is at fault or at least that is what a WSA fan would say, eh? ;)
 
Regards, Baldrick 
Userlevel 4
Thanks
@ wrote:
Everything is compatible with Webroot
Even BitDefender?? I'd heard from several internet forum sources of problems with BitDefender co-existing with Webroot. It's the only AV I've heard about where this was supposedly the case.
Userlevel 4
Hi Kit,
I never had any problem with either one,  they both are compatible and compliment WebRoot.
 
Thanks for your reply
Userlevel 7
Everything is compatible with Webroot no matter how hard they sometimes try to claim otherwise and break that compatibility. Webroot ensures that.

The question more becomes whether SAS and MBAM will work happily with each other. That is one I cannot answer. As a general rule, if they both perform on-demand scanning, they are not likely to be unless at least one of them say they are.
Userlevel 4
:D  I check SAS and  MBAM is compatible with webroot. I had these programs for a number of years never had a problem with conflicting with any antivirus software.  Webroot may detects viruses that SAS miss,  same with the MBAM detect malware that Webroot and SAS do not catch. 
Userlevel 7
Honestly tough to tell without a full evaluation. For example, the website could actually be "ineptly malicious", such as having a bug that will only be able to infect people who use Windows 2000. Technically, yes, it's malicious, but completely incapable of actually infecting anybody who uses the protection software, so not-blocked.

As this thread originally said, "OMG, Webroot missed this!" and that turned into "Never mind... the thing that caught it was lying. Sorry." So honestly it's really hard to say without knowing what you're looking at whether something is malicious or being lied about or mis-caught or just genuinely annoying.
Userlevel 4
:D  Thanks kit for your response.  Yes the webroot web filter extension is active in the browser.  I will check to see if SAS and MBAM coexist with other antispyware software.  How do one know if the website is annoying and not malicious?  I never had a virus on this computer.
Userlevel 7
Badge +56
? hey buddy long time no hear I hope your doing well, and nice to see drop in once in a while also say hi to ? for me!
 
Thanks,
 
Daniel 😉
Userlevel 7
You are correct, nothing is 100%. Though a curious question is whether you had the Webroot web filter extension active in the browser at the time. Also, the definition of "Malicious" varies. For example, "Tries to install malware" is consistently malicious. "Pops under an annoying video advertisement"? Annoying, but not technically malicious, but something might block it anyway. "Had a virus six months ago and now it doesn't"? Not-malicious, but still might be on some things.

Webroot itself is specifically made to be able to coexist with other security software. I cannot speak for SAS and MBAM at the same time however, though I can say that unless one of them explicitly indicates it can, I wouldn't. Blocking contentions can do horrible things.

@ I still exist. Move pretty far. All the usual. ^.^
Userlevel 4
:(  I  unknowing click on a Malicious website,  Webroot did not block,  however Malwarebytes blocked the malicious website. No softeware is perfect so it would be wise to have both Malwarebytes and Superanti Spyware on a computer.
 
Thanks Kit ,  I like this forum.
Userlevel 7
Badge +62
Thank you ? for your input. It's always a pleasure to hear from you!
 
 Hope you are doing well?:D
Userlevel 4
😃 LOL  That is very true.
Userlevel 7
And Norton has caught stuff that AVG missed. But AVG also caught stuff Norton missed. And Webroot has caught more stuff that SAS missed than SAS caught that Webroot missed. And if SAS/AVG/Norton miss something, you're completely 100% out of luck because they will do nothing to fix it until they get a definition update. By comparison, Webroot can still remove it on your instructions even if it doesn't detect it. Or get free help from support to remove it, not costing you a penny extra.

Also notably, if you have another AV installed and both it and Webroot would catch the same Malware, only the Non-Webroot one will catch it, because if they both caught it, they'd get into a fight over it, so Webroot will always allow another installed program to catch it if it can. Mind you if you "get something" and then install SAS and it catches it, that's a different thing. But also the nature of what SAS "caught" is up for consideration. SAS will say "OMG, a text file that could have been created by Trojan.ADHD! I caught it!". So without knowing precisely what it "caught", there's no way to say anything.

Thank you for your input though. 🙂
Userlevel 4
😛 I have to put my 2 cent worth in,  I have paid webroot.  I have Superantispiware that caught a malaware where Webroot did not. 
Userlevel 7
Glad to hear it wasn't a problem going on there.  There is a potential that MBAM was interfering with the normal operation of the OS while it had some issues there.  The shutdown you described is caused when a program that is invisible but critical to the system operating shuts down or crashes.  There are so many potential causes that it's nearly impossible to narrow down from the information provided and not really our position to try to determine on that, but it doesn't sound like a malware issue.  You might want to do a full disk check including checking for bad sectors just in case.
 
 
Badge +3
Well after all that, it turns out the _isdel.exe file was a false positive.  MBAM fixed the FP on their end and now it looks like the inf files that were being flagged are also FPs.  I did submit one file for review via the WSA client software.  Not sure how this exercise fixed my buddy's problem but it seems to have nothing to do with that file...and now restored.  Thanks for all the help...it was an interesting effort...and the remaining mystery apparently won't be solved.  Cheers!
Userlevel 7
POTENTIALLY safely.  In my position, I would be comfortable taking the risk on my computer, but it's up to you.  After all, if it's a threat and does go active agan somehow, MBAM removed it once, so should be able to again, right?
 
Even just scanning it with SecureAnywhere gets all the data we need from the file into the cloud, so generally it doesn't need to be "submitted".  the scan line, like I showed above, contains the information key for us to look it up on the cloud, and then changing determinations is a 12-second process. :D  We'd want to evaluate it first though, bu the scan does the raw evaluation and sends that data to the cloud so we can look at it.
 
inf files are a type of installer script that is processed by WIndows.  They are not machine code and in and of themselves cannot be threats.  They can be USED by threats to install themselves though in a manner that bypasses detection by a lot of security software.
 
MBAM's forums appear to be down, according to numerous posts about MBAM FPs on other forums.. :/
 
As to the right-click scan not working, that is something I am trying to get greater attention on.  It occurs when the system service for SecureAnywhere crashes and restarts.  Focus thus far has been on preventing the crashes, but I am concerned that there are thousands of things that can crash software, and faulty hardware would be outside out control for example, so it should recover gracefully.   You can find the line about 'teminated unexpectedly' in the WRSA logs prior to the context menu stopping working.
 
You can recover it by rebooting, as you noted, but also by simply shutting down and restarting SecureAnywhere itself.
Badge +3
So he could restore those files safely, then immediately move them over to his desktop and perhaps go back to his image library from a few months ago and compare those files with these current ones to see if they are a match or changed...?  If changed, he could submit them to you folks for analysis and get it added to the database as needed?
 
Well, I just installed MBAM and ran and came up with two files identified as trojan.agent.  They are:
 
Files Detected: 2
C:WindowsInfafw.inf (Trojan.Agent) -> No action taken.
C:WindowsInfafwmp.inf (Trojan.Agent) -> No action taken.
 
A google finds false positive reported on mbam's forums...though the google link doesn't take me to the actual post...so unsure.  BUT...when MBAM was installed, right clicking on the file in Windows Explorer and invoking Scan with Webroot no longer worked (WSA didn't pop up as normal).  Closing MBAM didn't help...somehow the context menu was broken.  Uninstalling MBAM and rebooting fixed that, then I had my first blue screen (frowny face) in Win8...oh joy...not webroot's fault...was browsing at the time...probably Outpost Firewall if I had to guess.  Just an FYI.  Thx.
Userlevel 7
We don't actually send the files to the cloud.  The cloud has a list of the fingerprints of everything that is/was running or would be very likely to run though, as well as its genericized behavior, state, and current determination information.  We can also look that up by the keycode, as I mentioned earlier.   If the threat was running, we'd likely have it in the cloud information.  If it wasn't running... well, bear in mind that other products do find dormant and non-code things (like a log file that says "01001" but HAPPENS to be in a directory created by a threat) that we don't waste the user's time looking for.
 
Now, on that thread, this is interesting...  I'm trying to take a look in the cloud back end based on the filename, but that is usually a futile effort.  From the very surface, that looks like a false positive.  At the same time, a good infection will try to make sure it looks legitimate.  You could take a look at the scan logs to see if it lists that file anywhere in it as well, though a scan run after MBAM quarantined it would not see it.  Buuuuuuut...
 
On a 64-bit windows system, the location you're seeking is actually in c:windowsSysWOW64, not REALLY in system32.  And sure enough, that _isdel.exe shows up here with a file date of 6/10/2009.
 
Scan log shows it as:
[g] c:windowssyswow64installshield_isdel.exe [MD5: 9D4EC4B71FD189A0B2C4DBD6AADE16BF] [Flags: 00000000.0]

So it's NORMALLY a legitimate file.
 
Hmmm...  So a quick check on Google for "malwarebytes _isdel.exe"...  and suddenly it screams False Positive. :/  People with clean Windows 8 installs, multiple reports on the Norton forums 22 hours ago, etc...
 
One wonders whether the _isdel.exe is now completely missing from the SysWOW64InstallShield folder, in which case the computer will be slightly broken, as there SHOULD be a legitimate version of it there normally.
 
This is all just a casual inspection, mind you, and could easily warrant further investigation.  Depending on how brave you are, you could even poke at it more deeply if you wanted to.  Restoring the _isdel.exe from MBAM quarantine would not cause it to run unless MBAM didn't do a proper cleanup job, so it wouldn't "reinfect" until it did run.  Then scan it with MBAM again after updating the definitions and see if it's detected again.  Or run a scan on just that file with Webroot, save the logs when the scan is completed, and look for the line similar to what I pasted above.  If it says [u], we may have something Very Interesting™ to poke at.  If it matches the line above, or otherwise says [g], then it's legit and almost invariably a false positive by MBAM, though we can definitely investigate more deeply with the info in that line alone.
Badge +3
One clarification, the files are quarantined in MBAM's quarantine, so not sure how you'd be able to see them via cloud method you mention.
 
And second, just googling a bit more, today someone reported the same files MBAM flagged on friend's PC yesterday.  See here, top post:
 
http://forums.majorgeeks.com/showthread.php?p=1782021
 
So perhaps this is something new?  On friend's PC, the first folder flagged didn't even exist prior to quarantine, perhaps hidden/system attribute set...not sure if he shows those or not...didn't think to ask at the time.
 
 
Userlevel 7
No problem. 🙂 Not like there are too many threads about infections on the forum anyway. XD
Badge +3
Much appreciated and apologies for hijacking this thread...wasn't my intent.
Userlevel 7
Just file a support ticket from the computer when Webroot is installed properly and it will automatically add its ID token to the support ticket on our side.  With that ID, we can look up the basic scan information in the cloud system.  There is a possibility for something further being needed (for example, if the system has certain MBR or full boot infections, there is no way for anything to see them, and that infection may have downloaded and installed ZBot), but in those cases we'll respond to the ticket with that info. 
 
We cannot remote in randomly, so if we do see a need for remote work, we'd request contact information and a time to reach him.  But usually it can be fixed just with the cloud view of the computer.

Reply