- CheckMates
- :
- Products
- :
- Harmony
- :
- Endpoint
- :
- Visual Studio vs Anti-Malware
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Visual Studio vs Anti-Malware
First: We are new to Checkpoint so everything is a little bit confusing.
An in-house Software developer has Visual Studio 2017 and is developing our own Administration System. When compiling, Anti-Malware immideately marks the generated .exe-file as a threat and removes it. This of course makes it difficult to develop anything
Since the location of the generated .exe varies I added the file name to the excluded files without a specific path. This worked, for a while. Two days later, Anti-Malware started blocking the files again.
I have now disabled Anti-Malware for this user, but would really like to find a solution.
Any ideas would be greatly appreciated.
// Andreas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would work with our TAC on this so we can see what's causing this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dameon
We seem to have a "collaborative support contract" (no idea what that means, we were not given any alternatives/explanation by the reseller how that works). This however seems to mean we cannot contact or chat with Checkpoint directly ("In order to open a chat, your account or appliance must be covered with a valid support contract" or "The selected account is covered by a collaborative support contract. To ensure your service request is being handled you should contact your support partner.").
So it seems I cannot go down the suggested path unfortunately.
As I am discovering more and more, the fine print of our Checkpoint investment is not what I expected from the sellers beautifully impressive demo. It has not been a smooth ride (it is unfortunately the worst software experience I have ever had, so far). The Endpoint Security Management Server is a very consultant friendly software, I have to give Checkpoint that at least.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A couple of other suggestions:
- The policy has somehow changed to not exclude the directory.
- The detection that is occurring that blocks the files happens before the user logs in and the policy for the entire organization does not have the exclusion.
- The file has moved to a different location than the one you are excluding.
Getting a dialog going with your partner and our TAC will allow us to see what's going on more closely and more concrete suggestions can be provided.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A Collaborative Support agreement means that your partner is the first point of contact for support issues.
If they cannot solve it, they can open a ticket with us on your behalf.
Direct Support agreements are certainly possible.
My guess is that there is something inside the executable that anti-malware is picking up as malicious but is really not (i.e. a false positive).
Obviously we would need a sample EXE for further analysis and the best way to provide this is through the support channels.
I'll see if there is another way.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I also think it is a false positive. The problem is that the developer might theoretically create any project with any name with any directory.
I asked him to create a new project, compile some code and the same thing of course happened. Anti-Malware stepped in deleting the exe-file. So it kind of seems that users with Visual Studio is incompatible with Anti-Malware.
But that cannot be a general case, I guess that are a lot of organization with software developers running Anti-Malware with success that do not have to contact company support for each and every project they might start.
I must be missing something or not thinking in the right lines here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm a developer and I use visual studio to work, and from what I've seen the checkpoint does not allow the local debugger (MSBSMON.exe) to run so it does not run any exe from the programs that its developer does.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am also having a similar problem with 2 of our developers that have the E80.70HFA1 client and they cannot debug using MSVSMON.exe in Visual Studio 2012. I have a case opened with TAC so I will update you on my findings.
From what I've seen, there is a lot of activity in the AntiBot.log in C:\ProgramData\CheckPoint\Logs folder on the times that the developer was trying to debug. In the AntiBot logs, there were a few errors saying the following:
2018-02-09 16:09:43 t:0x00002740 [.\NFDriverManager.cpp(197)] AntiBot.UrlInterceptor.NFDriverManager [ERROR] Sending a EPNF_IOCTL_AB_VERDICT control code to the driver failed (attempt number: 1 ). Error:87
2018-02-09 16:09:43 t:0x00002740 [.\NFDriverManager.cpp(197)] AntiBot.UrlInterceptor.NFDriverManager [ERROR] Sending a EPNF_IOCTL_AB_VERDICT control code to the driver failed (attempt number: 2 ). Error:87
I have whitelisted the executable MSVSMON.EXE in both Anti-Bot and Sandblast Blades, and they still cannot debug.
Have any of you found a solution yet?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I would suggest to check what infection is detected on the file. Perhaps, excluding file by detection name can be most effective in this case. For other options - please take a look at sk122706 in Knowledge Base DB.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It turns out there was a bug in either the Firewall or App Control Blade (Endpoint Client E80.70HFA2) where it prevents the debugging tool from running. Since upgrading to E80.80 Client, this fixes our issue so I'd suggest trying that.
