Thread: Trend Micro OfficeScan Spyware detection program issues

Thanks for sharing this, did you happen to find out if they use the same
scanning engine in there PC-cillin Internet Security suite?

BB

"falconerck1" <falconerck1@discussions.microsoft.com> wrote in message
news:48C347B3-270B-4C5F-A973-3313F3FF70CC@microsoft.com...
>I spent 3 hours on the phone yesterday with Trend Micro working on a
>problem
> that we observed.
>
> The short synopsis is that their OfficeScan V7.0 spyware/adware/greyware
> detection and remediation application is, in my opinion, badly broken and
> can
> wreak havoc in an enterprise.
>
> OfficeScan corporate edition version 7.0 includes a
> spyware/adware/greyware
> detection and cleanup feature. After our upgrade installation of V7.0, we
> noticed a significant detection rate (~50%) of HKTL_Bruteforce.A,
> SPYW_Csnoop.A, SPYW_Marketscore.A, and SPYW_Gator, among others. I started
> looking into these detections and became alarmed at what I found.
> Searching
> Trend's website for information on these detections told me that I should
> be
> seeing as many as 20 or so different files that has been placed on the
> supposedly infected machine by the exploit. When I checked the client
> logs,
> there was only one file and in some cases a few registry values/keys that
> had
> been identified and deleted. Here are some details on the files that were
> deleted:
>
> Bruteforce.A: C:\WINNT\system32\regobj.dll
> Csnoop.A: C:\WINNT\uninst.exe
> Marketscore.A: C:\WINNT\system32\sporder.dll
> Gator: C:\WINNT\system32\wbem\Logs\wmiadap.log
>
> I did some more research on these files and found that these were all
> legitimate system files that were used by other processes and were
> actually
> part of our base image. These files are used by VB app runtimes,
> InstallShield uninstall routines, Winsock LSP chains, and WMI providers
> and
> readers.
> There were also a number of registry keys/values that were deleted during
> this detection. (most reg entries were in HKLM\software\classes and
> consisted
> of guids.)
>
> I contacted Trend's customer support to find out why their product was
> deleting these files without any cross-checking with the virus pattern
> files
> to determine if the files being deleted were indeed malicious.
> Long story short, they don't check. If even one file from the detection
> definition matches the pattern definition, it triggers the anti-spyware
> action. This includes legitimate system files.
> It would be easy to write a spyware app that drops a perfectly legit copy
> of
> ntoskrnl.exe or something like that which would then be detected and
> deleted.
>
> I asked Trend if they had a fix for the machines that had had these system
> files and registry entries deleted. Their answer, after well over an hour
> of
> checking, was "you need to copy the files from a good system back to the
> damaged system. You need to recreate the registry entries by hand as
> well."
> They do not have a tool to fix the problems that their app causes. They
> admitted that this product was broken.
> They did know about the regobj.dll problem, and had labeled that as a
> false
> positive already. They opened a case to look into the additional false
> positives, since they said their engine shouldn't have done what it did.
> There is an updated spyware engine and client pattern file available that
> supposedly prevents the regobj.dll detection, but there's a catch on that.
>
> Most of us set our AV apps to update from the manufacturer once per day or
> once per hour. We then know that our pattern files will be as current as
> possible.
> Problem is, the DCS component, which is what performs the automatic
> updates
> for the spyware engine (as compared to the AV engine), requires purchase
> of a
> different product (the DCS product) in order to be fully operational (as
> in
> allowing automatic updates), even though the anti-spyware interface is
> installed and functional as part of the OfficeScan console install, is not
> greyed out, and that additional purchase requirement is not documented in
> their manuals. So, unless I want to purchase their DCS component, I have
> to
> manually get the files from Trend each time I want to update, and then
> manually install them on the server and restart the master service. I can
> use
> the anti-spyware component, but can't update it.
> New buzzword - hostageware.
>
> So, to recap, I believe that the spyware detection component of Trend
> Micro's OfficeScan V7.0 is badly broken. Not only does it not perform
> detailed inspection of possible spyware, it deletes legitimate system
> files
> and registry entries. It also does not allow for automatic updates that
> could
> correct this type of problem unless you are willing to purchase another
> license that isn't mentioned in your admin or installation manual. Oh, and
> when it does damage your systems, you have to touch each one and fix it
> manually. No fix tool.
>
> Thankfully, we have not yet migrated our servers running Trend's
> ServerProtect to the recommended OfficeScan product. So far our only
> effect
> is on client PCs.
>
> I am awaiting further explanations/fixes from Trend on this issue. My
> recommendation in the meantime is that if you are running Trend OfficeScan
> v7.0, you inspect your settings to see if you are scanning for
> spyware/adware/greyware and evaluate whether this scanning method and its
> ramifications are going to adversely affect your environment. If you are
> seeing similar actions in your environment, I would contact Trend and ask
> them why they are using this method to detect spyware and how they are
> going
> to fix it.
>
> Trend's AV product has been pretty good to us over the years. Their new
> version, however, specifically the spyware detection app, does not seem to
> have anywhere near the quality that we are used to from them. The abysmal
> detection logic and inability of Trend's technical support to adequately
> address this issue have lead us to begin evaluating other antivirus
> vendors.
>
> Charlie

I didn't look at that; we don't use the PC-cillin product, just OfficeScan...

"Bigbruva" wrote:

> Thanks for sharing this, did you happen to find out if they use the same
> scanning engine in there PC-cillin Internet Security suite?
>
> BB
>
> "falconerck1" <falconerck1@discussions.microsoft.com> wrote in message
> news:48C347B3-270B-4C5F-A973-3313F3FF70CC@microsoft.com...
> >I spent 3 hours on the phone yesterday with Trend Micro working on a
> >problem
> > that we observed.
> >
> > The short synopsis is that their OfficeScan V7.0 spyware/adware/greyware
> > detection and remediation application is, in my opinion, badly broken and
> > can
> > wreak havoc in an enterprise.
> >
> > OfficeScan corporate edition version 7.0 includes a
> > spyware/adware/greyware
> > detection and cleanup feature. After our upgrade installation of V7.0, we
> > noticed a significant detection rate (~50%) of HKTL_Bruteforce.A,
> > SPYW_Csnoop.A, SPYW_Marketscore.A, and SPYW_Gator, among others. I started
> > looking into these detections and became alarmed at what I found.
> > Searching
> > Trend's website for information on these detections told me that I should
> > be
> > seeing as many as 20 or so different files that has been placed on the
> > supposedly infected machine by the exploit. When I checked the client
> > logs,
> > there was only one file and in some cases a few registry values/keys that
> > had
> > been identified and deleted. Here are some details on the files that were
> > deleted:
> >
> > Bruteforce.A: C:\WINNT\system32\regobj.dll
> > Csnoop.A: C:\WINNT\uninst.exe
> > Marketscore.A: C:\WINNT\system32\sporder.dll
> > Gator: C:\WINNT\system32\wbem\Logs\wmiadap.log
> >
> > I did some more research on these files and found that these were all
> > legitimate system files that were used by other processes and were
> > actually
> > part of our base image. These files are used by VB app runtimes,
> > InstallShield uninstall routines, Winsock LSP chains, and WMI providers
> > and
> > readers.
> > There were also a number of registry keys/values that were deleted during
> > this detection. (most reg entries were in HKLM\software\classes and
> > consisted
> > of guids.)
> >
> > I contacted Trend's customer support to find out why their product was
> > deleting these files without any cross-checking with the virus pattern
> > files
> > to determine if the files being deleted were indeed malicious.
> > Long story short, they don't check. If even one file from the detection
> > definition matches the pattern definition, it triggers the anti-spyware
> > action. This includes legitimate system files.
> > It would be easy to write a spyware app that drops a perfectly legit copy
> > of
> > ntoskrnl.exe or something like that which would then be detected and
> > deleted.
> >
> > I asked Trend if they had a fix for the machines that had had these system
> > files and registry entries deleted. Their answer, after well over an hour
> > of
> > checking, was "you need to copy the files from a good system back to the
> > damaged system. You need to recreate the registry entries by hand as
> > well."
> > They do not have a tool to fix the problems that their app causes. They
> > admitted that this product was broken.
> > They did know about the regobj.dll problem, and had labeled that as a
> > false
> > positive already. They opened a case to look into the additional false
> > positives, since they said their engine shouldn't have done what it did.
> > There is an updated spyware engine and client pattern file available that
> > supposedly prevents the regobj.dll detection, but there's a catch on that.
> >
> > Most of us set our AV apps to update from the manufacturer once per day or
> > once per hour. We then know that our pattern files will be as current as
> > possible.
> > Problem is, the DCS component, which is what performs the automatic
> > updates
> > for the spyware engine (as compared to the AV engine), requires purchase
> > of a
> > different product (the DCS product) in order to be fully operational (as
> > in
> > allowing automatic updates), even though the anti-spyware interface is
> > installed and functional as part of the OfficeScan console install, is not
> > greyed out, and that additional purchase requirement is not documented in
> > their manuals. So, unless I want to purchase their DCS component, I have
> > to
> > manually get the files from Trend each time I want to update, and then
> > manually install them on the server and restart the master service. I can
> > use
> > the anti-spyware component, but can't update it.
> > New buzzword - hostageware.
> >
> > So, to recap, I believe that the spyware detection component of Trend
> > Micro's OfficeScan V7.0 is badly broken. Not only does it not perform
> > detailed inspection of possible spyware, it deletes legitimate system
> > files
> > and registry entries. It also does not allow for automatic updates that
> > could
> > correct this type of problem unless you are willing to purchase another
> > license that isn't mentioned in your admin or installation manual. Oh, and
> > when it does damage your systems, you have to touch each one and fix it
> > manually. No fix tool.
> >
> > Thankfully, we have not yet migrated our servers running Trend's
> > ServerProtect to the recommended OfficeScan product. So far our only
> > effect
> > is on client PCs.
> >
> > I am awaiting further explanations/fixes from Trend on this issue. My
> > recommendation in the meantime is that if you are running Trend OfficeScan
> > v7.0, you inspect your settings to see if you are scanning for
> > spyware/adware/greyware and evaluate whether this scanning method and its
> > ramifications are going to adversely affect your environment. If you are
> > seeing similar actions in your environment, I would contact Trend and ask
> > them why they are using this method to detect spyware and how they are
> > going
> > to fix it.
> >
> > Trend's AV product has been pretty good to us over the years. Their new
> > version, however, specifically the spyware detection app, does not seem to
> > have anywhere near the quality that we are used to from them. The abysmal
> > detection logic and inability of Trend's technical support to adequately
> > address this issue have lead us to begin evaluating other antivirus
> > vendors.
> >
> > Charlie
>
>
>