McAfee False Positive for ThinApped View Client

[synergy90t]

Hello,

In our organization, we have packaged the View Client (4.01) using ThinApp (4.0.4-204871) and deployed to some test users (using XP) for a pilot program. Some of the users reported that our corporate antivirus software (McAfee VirusScan Enterprise 8.7i) detected wswc.exe as a generic Trojan virus. The wswc.exe and Thinstall folder indicate to me me that it is the View Client. Here is a portion of the McAfee log file:

10/14/2010 1:12:08 AM Engine version = 5400.1158

10/14/2010 1:12:08 AM AntiVirus DAT version = 6135.0

10/14/2010 1:12:08 AM Number of detection signatures in EXTRA.DAT = None

10/14/2010 1:12:08 AM Names of detection signatures in EXTRA.DAT = None

10/14/2010 3:54:32 PM Deleted NT AUTHORITY\SYSTEM C:\WINDOWS\system32\CCM\CcmExec.exe C:\Documents and Settings\(username removed)\Local Settings\Application Data\Thinstall\Cache\Stubs\5a21d3a6a2ac166efd290dc64a9bea5988496d\wswc.exe Generic.dx!ugk (Trojan)

We have been telling our users that ThinApp is not leaving any trace on the system that the package is being ran from. I am assuming now that this is incorrect. Would anyone in the community be so kind as to explain what McAfee is actually detecting here and some suggestions on how we can avoid our users seeing these kind of "false positive" virus messages?

Let me just say that I have only been working with ThinApp for a few months so I am still learning the application and I appreciate any input given for my question.

Thank you,

Bob

[EuwRhU]

I also noticed this behavior before with Norton AntiVirus. A lot of the stub programs created in "%Local AppData%\Thinstall\Cache\Stubs" were detected as malware.

You should try to virtualize your applications with the last version of ThinApp, it seems that the last one doesn't generate stubs.

[shrivastavaa]

I am surprised, not because an AV reports ThinApp binaries as false positive but because McAfee does. We also use McAfee as corporate AV and it never showed any ThinApp binary as trozan.

These are what it shows Engine version = 5400.1158, dat version = 6139.00(I do not think it matters in this case).

I don't really know an exact answer but have you tried copying files given in logs to AV machine manually, i.e. copy if from capture machine and paste it at deployment machine, I think McAfee should catch them as well.

[shrivastavaa · Accepted solution]

>>We have been telling our users that ThinApp is not leaving any trace on

the system that the package is being ran from. I am assuming now that

this is incorrect. Would anyone in the community be so kind as to

explain what McAfee is actually detecting here

Only place which ThinApp change in system is the Sandbox location, which you can simply get rid by deleting the folder. An exception is if the isolation mode for a certain folder is merged (check attribute.ini in any folder at package) .

When you capture

an application and build a ThinApp project from it; resulting bin

folder contains all installation files with the container file as read only data.

Now

when you copy this to deploment machine and execute it, ThinApp may

need to write file in certain cases (For example if application tries to

create a log file). Now ThinApp does not allow creation of files into

OS system folders (windows, program files etc) and sandbox all creates

and writes. You can locate the default sandbox at %AppData%.

So when you say no trace, it should mean the application will not write system registry, system folders. Of course if an application creates files, thinApp has to create them as otherwise application will not work, but instead of creating those file at all the places in system, ThinApp restrict them to a single sandbox location.

I hope it make better sense now.

Aditya