itman

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.

This is immaterial per se. Although I do have a HIPS rule to monitor all PowerShell execution. Also, Eset has a KB article in regards to PowerShell HIPS rule monitoring as it applies to FileCoders.

I will say this. If traces of the Python engine code are detected in an .exe, Eset should flag that .exe as suspicious.

As far as the first test phase, the malware .exe's were dropped in %AppDataUser% directories. So I don't know why those weren't detected. I personally have a HIPS rule that monitors any process startup in those directories. As far as the Python based ransomware, it first needs to be verified if the tester had previously installed Python on the test rig. If so, then running of a malicious Python script would be much easier to accomplish. Note that the average user would not be installing Python. Now there are malware attacks that can download the Python engine "on the fly" with a malicious script. However, this requires the previous to be "bundled" in a .exe. If the script was encrypted, obfuscated, packed, etc.., it would be hard to detect in memory since Win 10 AMSI interface does not scan Python scripts.

Well, that didn't work. Only God knows what the heck Microsoft is doing to initiate the ICMP outbound connection. So I am just allowing that single IP address for the time being.

@Marcos, fairly certain I have identified the source of the alert. Alert time corresponds to startup of a scheduled task running sedlauncher.exe that was installed courtesy of KB4023057. This bugger is Microsoft's monitoring of Win10 1803 for suitability to upgrade to 1809. When the alert appears is there a way to create an exception by process name? Never mind, found out how to do so.

Yes it can detect it if PUA protection is enabled. PUA protection is most effective at software installation time. Possibly the concern overrode the PUA alert? In any case, have the concern run a full system scan with Admin privileges.

I don't use Skype. I will not worry about it for the time being unless it reappears in any frequency. I am curious as to why Eset appears to be sending outbound traffic directly from its internal proxy?

This morning I received the following alerts for the first time ever. Note that both times these alerts were generated I was on the Eset forum web site using IE11. Note the IP address which is Akamai: The alert also stated that malicious traffic was being sent from my PC via ICMP. Looking at the Eset default firewall rules in regards to ICMP IPv4, the only outbound connections allowed are for echo and to 224.0.0.0/4, Trusted Zone, and local connections. There is nothing defined in Trusted Zone and I use the Public profile. The only suspect in local connection is localhost; 127.0.0.x. This leads to the next screen shot: Note the Eset proxy activity being sent to the same to the same Akamai IP address associated with the alerted ICMP activity. Now what I have done is run ipconfig /flushdns to clear the local DNS cache which appears to have so far stopped the Eset ICMP alerts. But I really would like to know what is going on here.

Here's a reference to a targeted SWIFT attack against Bank of Bangladesh: https://www.theregister.co.uk/2016/04/25/bangladeshi_malware_screwed_swift/ . Here's a detailed technical analysis of the incident: https://baesystemsai.blogspot.com/2016/04/two-bytes-to-951m.html . Of note: Eset detects the malware associated with the above hash value.

DyePack namely Hacktool.APT.DYEPACK has been around since 2015. I assume Eset has a signature/detection for it. To 100% verify this, a hash value would be needed. This malware is directed toward SWIFT based operations at financial institutions. Also believe most of the targets were within France.

@Marcos , chaulk this up to "sometimes you post dumb things." What I was using for testing via admin level command window was: reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v debugger /d "c:\windows\system32\cmd.exe" The alert I was getting was from reg.exe trying to start. I monitor all reg.exe execution with an Ask HIPS rule.

Yes, I knew that. The question is just what does the Debug another application monitor for? Most likely windbg.exe use I assume. Too much work. Below are screen shots of the rule in question:

Internet Security 12.0.27 First up is the block action as it pertains to monitoring of registry key changes. An Eset alert is generated to block or allow even if the Notify User option is disabled . In other words, the block action behaves identical to an ask action with the exemption that thankfully, the action will be blocked after the alert display times out. Such is not the case if the monitoring action is for an application. This works as expected with no Eset alert generated. Next is the HIPS action pertaining to Debug another application. I assumed this rule would monitor the following type of activity: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe "debugger"="c:\windows\system32\cmd.exe" That is when sethc.exe is started, what actually runs is cmd.exe. I created a HIPS rule with cmd.exe as the source application, the action Debug another application, and the target application as sethc.exe and the activity was not detected by the HIPS.

Per Robtex: Per Wikipedia: https://en.wikipedia.org/wiki/Webtrekk Appears your web traffic is being tracked.

Now this is strange. I reinstalled IS 12.0.27 yesterday from a download from the Eset U.S. web site. Prior to this, I had 12.0.27 installed via the in-program upgrade feature from the latest ver. 11. The upgraded 12.0.27 ver. did show the Eset GUI Refer Friend option. This latest direct download install of 12.0.27 does not. Me thinks that the problem lies in the direct download from Eset.