Running Sonicwall, OS version SonicOS Enhanced 6.1.2.3-20n
Detection being flagged when some systems go out for a CIS update to 199.66.201.27:80, being detected as "Gateway Anti-Virus Alert: Win32_Ransom.AWL (Trojan) blocked. So those systems won’t update. And, some of my systems do not go to the 199. ip for updates, but to 104.16.61.31 address. Tose are all saying update successful, but the last update on the home CIS page is anywhere from 13 hours old to more than a day out of date. Very unusual. Other IPS involved in the update connections: 52.202.64.239, and the usual 178. x.x.x.x address.
Is the detection by Sonicwall?
Yes it was. Does not seem to be doing it any longer, though. The systems are connecting and getting updates again.
This issue has started up again this afternoon with systems checking for updates. We are running CIS 8.2.0.5027 with DB version 25189. The alert message I receive for the affected systems is this:
06/07/2016 16:14:19.624 - Alert - Security Services - Gateway Anti-Virus Alert: Win32_Ransom.AWL (Trojan) blocked. - xxx.xxx.xxx.105, 49617, - 199.66.201.27, 80, cima.security.comodo.com -
This email was generated by: SonicOS Enhanced 6.1.2.3-20n
Not all my systems are connecting to this IP for updates, so some are successfully updating. Not sure why the difference in where they check for updates. But it is quite disconcerting to get this during an update. Any way to know what is triggering and fix it? This means I have many systems not as up to date as they should be.
Thanks in advance.
During installation, you probably have enabled “cloud based behavior analysis”. :-La
Any file that is identified as unrecognized is sent to the Comodo Instant Malware Analysis (CIMA) server for behavior analysis. Each file is executed in a virtual environment on Comodo servers and tested to determine whether it behaves in a malicious manner. If yes, the file is then manually analyzed by Comodo technicians to confirm whether it is a malicious file or not. The results will be sent back to your computer in around 15 minutes. Comodo recommends users leave this setting enabled. Read the privacy policy by clicking the 'Privacy Policy' link.
Thanks for the reply.
Uh…installation of CIS, do you mean? Maybe, but not that I can recall, we have been using the product for quite a few years now. This issue is a recent phenomenon.
I would be more likely to turn it off in case the cloud service was not available, and so that we could control what files were actually sent off to “the cloud” without us knowing…
So I went thru all the settings the only cloud based item checked/enabled are for the File Rating section, and also on the scheduled scans. Can’t find anything any place else, so what are we missing?
And, I’m not entirely clear why having “cloud based behavior analysis” enabled in CIS would trigger Sonicwall to detect a database download that Comodo does, from its own website, as being malicious files?? That seems a bit odd. Call me dense, I just don’t see the link between the two.
The way I’m imagining it :
Machine gets malicious / unknown file → file is sent to CIMA → SonicWall detects it → domain gets blocked → interferes with updating.
Additionally, you could check under “Submitted Files” :
Good imagination! 
I see now. I did go back to the user’s system and looked…nothing was submitted. But I checked the alerts and was able to see that a specific file used to launch our ERP software was not the usual one she uses. She somehow had 2 shortcuts on her desktop, one the normal one and one this alternate exe for starting the program.
After performing incident response work, the file is a secondary exe file from the vendor that is used to kill a previous instances of the ERP software file if the user didn’t properly close the last session. The behavior of this file is what is triggering the detection. I think. It acts like malware (i.e, launches another exe file, creates temp folders, copies a batch file into them, launches the bat file which runs attrib.exe and then looks for and kills specific processes, then launches another exe to run the ERP program). Geez…I confirmed the hashes and file details with the vendor, and they admitted it is most likely a false positive as there have been other AV programs also making the same or other detections. Unfortunately, they don’t sign their programs so we can’t get their stuff trusted.
Anyway, thank you for the help. It seems at least I know the cause and what to look for should this come up on other systems.