itman

This Eset knowledgebase article also has a few additional recommendations in regards to best practices against ransomware: https://support.eset.com/kb3433/?locale=en_US&viewlocale=en_US

https://www.us-cert.gov/ncas/alerts/AA18-337A I have copied the recommended mitigations with sections underlined for emphasis:

Disabled. I thought it wouldn't matter what that setting was since my prior use of Application Modification showed it was only applicable with the firewall in Interactive mode. Again the only alert I have ever received was for equi.exe. What is strange is the alert doesn't manifest until a few hours after an Eset upgrade. And the alert only occurs once after I respond with keep existing firewall rules. For example, Eset upgraded to 12.0.31 at 9:00 AM today and the alert appeared late in the afternoon. Also there has been no change to equi.exe last modification date after the above noted upgrade time.

The only firewall rule for equi.exe is the default rule. See the below screen shot. Should that rule be disabled?

I assume you are trying to remove SEP? Did you try this: https://support.symantec.com/en_US/article.HOWTO74877.html

I have had the below screen shot alert occur the last few times an Eset in-product upgrade occurred. I have the firewall set to Automatic. I thought Application Modification detection only occurred when the firewall was set to Interactive mode. Also this is the only app update alert I every receive. The Eset GUI default firewall is enabled allowing all equi.exe outbound traffic. Is this some type of internal security check to detect any unauthorized equi.exe modification?

This is an English language forum. Please post in English if you expect to get any replies.

There is one "glitch" I found in regards to in-product Eset upgrades. If you perform an Eset repair installation via Control Panel -> Uninstall Programs option, Eset reverts back to the last version that was off-line installed. For example if you manually installed Eset ver. 11 and in-product upgraded to ver. 12, after the repair installation, you're back to ver. 11. You then have to perform an in-product upgrade to get to the latest Eset version. I find this very odd behavior.

If it's GrandCrab ver. 1,4, or 5, you can try this to see if will decrypt the files: https://www.nomoreransom.org/en/decryption-tools.html#GandCrabV1V4andV5versions Additional reference is here: https://www.europol.europa.eu/newsroom/news/pay-no-more-universal-gandcrab-decryption-tool-released-for-free-no-more-ransom

Let's get back to the methodology employed in this test namely: There are only three ways a Python script can be executed on a user device: 1. The user manually installed Python. 2. The attack involved downloading Python and installing it. 3. As posted previously, the attacker created an executable with the Python engine component and malicious script contained within. Methods 1). and 2). are not viable scenarios since most users do not install Python and malware installation of it would be extremely "noisy." That leaves number 3). as the most likely way Python based malware would be deployed. And this method needs attention by Eset and other AV vendors. Also this is not an easy mitigation in that the presence of the Python engine code within the .exe is in itself not malicious. It is the code within the script that is malicious. And, it is a given that the script code will be hidden and will not reveal itself until the executable unhides the script code in memory prior to executing it via the Python engine. Compounding the issue is Python scripts cannot be examined by the Win 10 AMSI interface when executed this way; even if it did so which BTW, it does not. This leads to two possible detection scenarios: 1. Improved sandboxing analysis for any executable that contains Python engine code remnants and detection of script code malware after it is unhidden in memory. 2. After sandbox detection of Python engine code remnants, alerting the user of possible suspicious process activity. This alerting could be conditioned upon a number of factors such as process reputation status; e.g. unknown, signing status; e.g. unsigned, etc.. I believe number 2). is the only viable solution given the capability of Python script code executed this way. Also it is not the norm for legit application software to be developed this way.

To clarify, what I was trying to suggest is this and like activity is possible in ad hoc testing; not that it actually occurred. I have no direct proof that TPSC engaged in such activity.

Perhaps the non-detection is due to the fact both products have shown issues with malware detection in AV lab testing? Malware Research Group up until recently used to include both products in their quarterly 360 Full Spectrum tests: https://www.mrg-effitas.com/wp-content/uploads/2018/05/MRG-Effitas-2018Q1-360-Assessment.pdf

That said, I see a few "irregularities." TPSC has affiliations with Bitdefender, Kaspersky, and Sophos. Next as show in the below screen shot, Kaspersky only scored in 80.46% versus Eset's 95.6% in Phase 1 testing but passed overall testing? Appears that because Eset failed the Python ransomware test that was justification for the overall failure rating. Is this a standard AV lab testing methodology? Or is what we have here is a polished presentation using a pre-evaluated ransomware sample that my sponsors product detected but its major competitor did not?

AV-Comparatives has a write up on uTube security test sources. The most important point to note is these concerns are not formally recognized AV lab testing sources. As such, they don't adhere to formalized and verifiable testing standards. https://www.av-comparatives.org/youtube-security-channels/

Doubt this is the case. From what I can determine, PC Security Channel is not an AMTSO member: https://www.amtso.org/members/ This test falls into the category of all ad hoc Internet tests whose results cannot be verified and therefore should be ignored. The only exception I can think of would be Runbenking's PC Magazine tests employing the Core Impact tools. He has been doing those for years and is very upfront on how and what he tests for.