Proof needed for .exe files being blocked by Symantec

[MarkIT]

Hi AutoIT masters,

Good day! Sorry to have bothered this forum but we really need help. We are working on an automation project that is running on VDI server. The BOTS are in .exe are running fine until AV detected them and deleted the files. The files were re-compiled and AV kept on deleting them. The copy of the .exe BOT deleted were sent to Symantec for whitelisting. After whitelisting, it is no longer deleted but no longer working as designed (showing Line script error). We checked the scripts and there were no issues since we run it using SciTE editor and it performed the desired task. Good thing we found on this thread the solution using .a3x and the BOTS worked fine and no longer deleted. Now, the problem is they are asking why the BOTS won't run in .EXE and what is the reason behind Symantec AV deleting them. We raised a case with Symantec but they cannot provide further information as they are always seeing the file as "False Positive". We even tested with Symantec turned off and those .EXE files are working fine, however, after re-enabling, it got deleted.

Just seeking help on how to better convince them that it is really Symantec causing the issue and the .a3x file.

[Nine]

I suppose showing them this thread could help :

https://www.autoitscript.com/forum/topic/34658-are-my-autoit-exes-really-infected/ 

cause it did helped me in the past

ps. it is not specific to Symantec, as far as I know all AVs react the same...

Edited January 15, 2020 by Nine

[MarkIT]

Thanks Nine! I will read the thread.

[TheXman]

Why go through the hassle of dealing with a behemoth like Symantec, or any other AV company for that matter, over scripts that you create?  I could understand it if it were a full-blown application, but these are scripts.  If it were me, and I had control over my environment (as any IT department or professional should), I would designate a folder structure that scripts can be run from, apply the appropriate ACLs to that structure, and exclude that folder structure from AV scanning.  That way, you don't have to play whack-a-mole with AV companies and you can rest assured that your scripts wont be quarantined due to any AV-related issues.

Edited January 15, 2020 by TheXman

[ViciousXUSMC]

1 hour ago, TheXman said:

Why go through the hassle of dealing with a behemoth like Symantec, or any other AV company for that matter, over scripts that you create?  I could understand it if it were a full-blown application, but these are scripts.  If it were me, and I had control over my environment (as any IT department or professional should), I would designate a folder structure that scripts can be run from, apply the appropriate ACLs to that structure, and exclude that folder structure from AV scanning.  That way, you don't have to play whack-a-mole with AV companies and you can rest assured that your scripts wont be quarantined due to any AV-related issues.

That is what I do, but when I was in positions lower than those with the authority to make the action or you get a new higher authority (like a security officer) it can make it a pain when it comes to government or corporations.

I try to use .bat and .ps1 as much as possible for this reason to standardize and make it easy for other techs to use my work.  However when I need the extra power of AutoIT I still use it.  I have more than once been bitten by some random false positive that comes up and deletes a script that has been in production for months or even years. 

Infact I may soon try to just start keeping a local copy of AutoIT on the machines and keep a copy of the script compiled as an a3x and run it as a parameter, this is also a way to work around the problem as far as I know.

[Exit]

On 1/15/2020 at 7:25 PM, ViciousXUSMC said:

Infact I may soon try to just start keeping a local copy of AutoIT on the machines and keep a copy of the script compiled as an a3x and run it as a parameter, this is also a way to work around the problem as far as I know.

And that's exactly why I wrote the Au3toCmd app.
A CMD file with all necessary files as "alternate data streams".
The CMD file runs standalone on the computer and the virus scanners are left behind.
See my signature for download.

[Neutro]

Symantec has a false positive system:

https://submit.symantec.com/false_positive/

Just submit your exe to them through it. Once they've fixed the problem they'll give you rapid releases definitions you can use to update your symantec server, or if you wait a bit longer it'll be included in the global definition release.

It happend to me once or twice when i was working for a company that used symantec and they acted quickly to solve it.

I'm not a fan of symantec but i must admit they did a good job about my submissions.

Edited February 1, 2020 by Neutro