itman

It's happened before. Refer to my posting here: https://forum.eset.com/topic/23266-unable-to-select-a-state-during-product-activation/?do=findComment&comment=113263 MicroCenter really needs to clarify Eset activation procedure in the U.S..

Was Eset installed when you purchased the PC from MicroCenter?

I think its also time Eset start offering an optional Home product version of their Commercial EDTD product. This is Eset's equivalent offering to Windows Defender ATP cloud protection. Price it to compete with WD ATP which as I recollect costs less than $10 per month on Win 10 Pro versions; cost would be per each license seat.

Given the shenanigans the U.S. gov. courtesy of the Israeli's caught Kaspersky in, I would say foreign AV vendors are still under surveillance.

In a "tit-for-tat," the Russians do it against American AV vendors: Elite Russian Hackers Claim To Have Breached Three Major U.S. Antivirus Makers: https://www.forbes.com/sites/leemathews/2019/05/09/russian-hackers-breach-antivirus-makers/#76ceef3b1db2

Correct. They do so without their knowledge or consent. Eset was on the list: NSA Spied On Non-American Anti-Virus Companies: https://www.forbes.com/sites/thomasbrewster/2015/06/22/foreign-av-companies-targeted-by-nsa/#d35cac75b8c3

Getting back to the specifics of the POC, note how Python was run: RunProgram="python\\python.exe pyrate.py" https://documentation.help/7-Zip/sfx.htm To summarize the events: Unknown/unsigned .exe dropped on device. The .exe contains an embedded 7zip self-extracting archive. The archive in turn spawns the Python executable as a child process from Python runtime components also extracted from the archive. The self-extracting archive contains a read-me file. The Python executable runs a Python script that contains ransomware encryption code. Ignoring no. 5 script execution details, are not the above activities enough to warranty a suspicious detection and resultant quarantine of the unknown .exe? Finally ponder the detection outcome if this Python script was obfuscated along this line: https://liftoff.github.io/pyminifier/ . Note this section:

Really nothing new. I remember some time ago it was discovered select American AV vendors at the time were letting NSA stuff (Yeah .....) sneak by.

This is a valid statement for commercial installations. However, there are numerous retail users that would very much like to see optional detection mechanisms added to Eset to enhance malware detection regardless of the higher risk of false positives. I also find it a bit odd that Microsoft has provided advanced surface reduction (ASR) rules for Windows Defender. Those rules have to be applied using specific PowerShell commands. In other words, it appears this feature is very much directed to commercial installations and is being deployed by them. -EDIT- Forgot to list a few notable ASR mitigations: Block execution of potentially obfuscated scripts. Block JavaScript or VBScript from launching downloaded executable content. Block Office applications from creating executable content. Block process creations originating from PSExec and WMI commands. Block executable files from running unless they meet a prevalence, age, or trusted list critera* * Aah .............. a reputational scanner "with some meat to it."

In Win Event Viewer, Open "Applications and Service logs" -> Microsoft -> Windows. Scroll down to the StorPort folder. Open the Operational log. Check for error and warning entries listed there as to what might be going on with the drive. Another possibility is you have a corrupted Win page file.

If ekrn.exe memory usage keeps going up throughout the day while the PC is on, it would be indicative of a memory leak.

If this is the port 8880 block rule I recommended, did you move it to the top of the firewall rule set? If this activity stops after doing so, its safe to assume it must be related to a previous firewall rule you created.

Also it appears the poster in the other thread fixed the issue by installing Internet Security. So you might want to take a look at your existing user created firewall rules as a possible source for this activity.

Do you have a surveillance DVR attached to your network?

If the blocks are occurring when your browser is open, check for like entries in Eset's Filtered websites log. Otherwise, check for entries in the Detections log.

Mine is currently using 74 MB:

It should also be noted that Python scripts can be run from PowerShell. In the PyLocky incident linked above, it used a legit installer to install Python. Ref.: https://ridicurious.com/2018/03/30/powershell-scripting-guide-to-python-part1/

I guess it's also time to talk a bit why conventional AV products have problems detecting Python based malware other than by signature methods. Python is an interpretive language. That is it uses an interpreter process to run its code. Windows facilitates this by loading the Python engine into a visualized container. The problem is that only the OS has access to this container. This also in effect nullifies AV sandbox heuristic analysis of Python based executable's since they in effect won't run in a conventional sandbox environment. Ditto for any other post execution methods such as memory scanning and the like. Appears to me AV's have to come up with a way to extract the associated Python script from the executable while sandbox. Then come up with a way to unmask packed, encrypted, or obfuscated scripts outside of current AMSI script examination methods to detect suspicious/malicious code usage. Until this can be accomplished, the Python .exe should be de facto deemed suspicious, given an obfuscated code alert message, and quarantined. I for one have long held to the assumption that an unknown process containing like masked script code is in the majority of cases malicious.

I use AT&T - POP3S and AOL - IMAPS in my Thunderbird e-mail client with Eset e-mail scanning enabled w/o any issues. Ensure that the "Enable email protection by client plugins" setting remains enabled as shown in the below screen shot. Although your e-mail client is not one one listed as supported, Eset will still scan IMAPS and POP3S traffic upon download from your e-mail servers. Disabling the Enable email protection setting in effect stops Eset from scanning SSL/TLS encrypted e-mail. Additionally, you might have to add Eset's root certificate to your e-mail client's equivalent root CA certificate store if it is not present there. Suspect this might be the case since your e-mail client, Claws, is one I have never heard of.

Here's a book, 'Creating a Ransomware With Python', in .pdf format for those wanting to get into the "nitty gritty": https://hakin9.org/product/creating-a-ransomware-with-python/

Looks like someone just made things a lot easier for Python based ransomware: https://github.com/sithis993/Crypter#builder

It also should be noted that this technique is not new. PyLocky ransomware employed similar methods: https://blog.trendmicro.com/trendlabs-security-intelligence/a-closer-look-at-the-locky-poser-pylocky-ransomware/

Also before anyone gets real excited about this, it was pointed out in the comments section of original linked malwaretips.com reference that Win 10 native SmartScreen will trigger on attempted execution since the process is unknown, unsigned, and definitely not a Win Store download.

The prototype for this POC comes out of a posting on malwaretips .com: https://malwaretips.com/threads/macdefender-test-2-trojan-ransomware.98294/#post-857972 . Someone discovered that using 7-zip's main process, 7z.exe, can be used to perform nasty stuff. It also slips by a lot of AV's because it is a trusted process.

https://github.com/jabbalaci/PythonEXE https://realpython.com/pyinstaller-python/ The bottom line here is the Python engine components are not malicious, the embedded script most certainly can be. And "bet your booties" that the script will be packed, encrypted, or obfuscated in such a way that it won't fully decode until executed. Win AMSI also is basically worthless against stand alone Python scripts since it doesn't by default analyze them.