itman

This is a STOP ransomware variant. There is currently no decrptor available for it. Your best bet for help is this web site: https://www.bleepingcomputer.com/forums/t/671473/stop-ransomware-stop-puma-djvu-promo-drume-help-support-topic/?p=4860779 . Also make sure you read all the comments mentioned about the forensic tool mentioned that posters have said worked. It is a not a file decryptor. As such, I am skeptical of it.

Getting back on topic in regards to this specific ransomware sample, it appears it is an attempt to hide an .exe attachment. If you use an ISP or a third party e-mail provider such as GMail, etc., you will never see such an e-mail arrive in your inbox. This is because these providers will delete any e-mail with an .exe attachment as part of their routine e-mail examination on their servers. As far as the techniques employed by this ransomware sample, it is characteristic of a targeted attack employing APT like methods against a high valued target; i.e. enterprise level. The chances of an individual user receiving such an e-mail are about zip. In fact, almost all ransomware activities these days are criminal syndicate or state sponsored level against enterprise or government entities since these are the targets that are capable and willing to pay the ransom amount being demanded. As such, individual user testing of ransomware samples they find is really of dubious value unless the intent is to show some flaw in their security software detection mechanism. Again consumer based security software is "tuned" to the threats encountered by individual users. -EDIT- Another way this attack could be deployed is good old phishing. You're tricked into downloading what you believe is a .pdf file. You open it and you're nailed. To prevent this, make sure you have Win Explorer always set to show File Name Extensions. It is assume you have the "smarts" not to open a .exe file downloaded in this scenario.

Most of the dedicated anti-ransomware solutions do the same. BTW - Checkpoint has an excellent anti-ransomware solution that costs around $15 USD w/yearly subscription. I believe Kaspersky also works the same way. In addition if its System Watcher feature is enabled, it will use a snapshot to restore any files encrypted prior to its ransomware detection mechanism kicking in. As far as Eset goes, your best solution is to create HIPS rules to monitor file modification activities against any of your User folders. This really shouldn't be too much of an inconvenience for the average user since those directories are not updated that frequently in normal daily use. For business environments, process exceptions would have to be created increasing the risk of ramsonware succeeding due to malware modification of those processes.

Correct.

LiveGrid only submits suspicious processes to Eset servers for analysis. It won't alert or stop the process from executing. It does raise the question that given the testing the OP was doing with this sample previously, it had to have been submitted some time ago to Eset servers for analysis. @wraith you do have LiveGrid enabled and also the option to submit suspicious files to Eset for analysis?

Yes. This is the standard Eset response. The problem is that it's an option to the previous AV's mentioned. As such, its available if one chooses to deploy it. As far as WD goes, it submits the process to the MS cloud Azure AI servers for a scan that can be extended up to one min. in duration. As far as WD ATP goes, the scan duration can be extended further. Additionally, probability threshold can be modified; i.e. 80% (default) to 90% to increase detection likelihood. Of course, increased sensitivity means higher likelihood for a false positive detection. Again, Eset has this capability in EED.

Desktop notification duration can be set to the following range; 3 - 30 secs.. Increase to whatever you like and see if that allows the alert tp display on the desktop long enough for you to respond to it. Per my screen shot, mine is to 8 secs. which allows me plenty of time to respond to any alert.

One nasty ransomware. It's disguised to appear to be a .pdf file using the xxxxx.pdf.exe naming convention. Appears to be one of these dreaded compile on the fly .Net .dll malware buggers and then inject that .dll into legit process. Hook a thread to the .dll and we're off and running encryption wise. I would say the major complaint Eset-wise is why it didn't have a sig. for this when 37 other VT vendors did. Notice how it targeted WD and Malwarbytes via legit Net process use? Will say that this sample is a perfect example of why Eset needs "block-at-first-sight" capability; not just for Enterprise subscribers of EED.

This would explain part of it. Without AMSI, Eset can't examine packed, obfuscated, or encrypted scripts prior to execution.

It would be also beneficial to know how the ransomware was executed. You can submit it to Hybrid-Analysis which will provide a detailed analysis of it: https://www.hybrid-analysis.com/ . My gut is telling me a Windows "living off the land" .exe was deployed.

Thanks for the clarification.

And at execution time, you received no alerts, detections, etc. from Eset and the ransomware encrypted all your files? Note that it's possible a few files do get encrypted prior to Eset's ransomware protection kicking in.

Do this as an additional test. Upload your ransomware sample to a file sharing web site. Now download it, execute it, and see if it still bypasses Eset's protections.

It's not supposed to do that. My Eset installation shows the actual elapsed time from when the update was applied to my device; not the elapsed time from when the update was placed on the Eset update servers. You might want to uninstall and reinstall Eset and see if that corrects the problem. Make sure you export your Eset settings if you have made GUI custom changes prior to the uninstall.

By "ISP control panel," I assume you are trying to access your router's GUI interface. For example for many routers, this is done by entering URL, http://192.168.1.254, in an open browser window. As far as I am aware of, the Win DHCP service is not involved in this process. The Eset firewall has a default rule that will block any inbound traffic from ports associated with the NetBIOS protocol; i.e. 137-139, 445, unless the device IP address exists in the Trusted Zone; i.e. Win file sharing is enabled. The alert you are receiving would indicate a possible SMB exploit situation. As I recollect, earlier versions of Win 10 allowed SMB v1 protocol. Using Win Control Panel, make sure SMB v1 protocol is disabled per the below screen shot. Also make sure you have applied all Win Updates to date; one of those being a patch for the SMB v1 vulnerability.

Assuming you don't connect to the Internet via a dial-up connection, disable that update option. It appears that might be what is "confusing" Eset's main GUI last update time display.

Are you logged to Win 10 as a local admin or a standard user? If you are logged on as a local admin, you shouldn't be seeing any UAC alerts related to Eset setting updating. I run as a local admin w/UAC set to its maximum level and receive zip UAC alerts in regards to Eset GUI modifications. If you are logged on as a standard user, this would explain both the UAC alerts and the Win permissions alerts you have been receiving. I believe Eset assumes anyone modifying Eset GUI settings is running with at least local admin privileges.

Not applicable in Win 10 as I noted in this reply: https://forum.eset.com/topic/19529-failed-to-create-rule-no-permission-to-save-settings/?do=findComment&comment=97654

The only thing is can think of that is causing this behavior is that Desktop Notifications has been to "Diagnostic" versus the default "Informative" level. What is causing the quick appearance/disappearance firewall alerts is Eset's display of existing allow rule execution.

That is not a secure way to run the firewall for any extended period of time. All Internet traffic will be allowed including malware related traffic. This mode is only intended to be used to build a rule set for system and installed apps. Once that is accomplished, the firewall needs to be switched to Interactive or Policy mode. Also the preferred and safest way to employ Learning mode for any Eset protection is immediately after a clean OS install with immediate installation of all apps.

Based on everything posted so far, I also agree this doesn't seem to be a Eset RDP connection issue. What we need is a screen shot of the alert being displayed by Eset. Another way to get to the bottom of this is to open Eset's Network Connection Wizard. It will show all blocked connections within the last 5/15/60 minutes. Never heard of anything like this. Sounds like an Eset IDS protection is being enabled and shutting down all inbound connections to the device. Have you inspected your Eset Network Protection log for clues as to what is going on?

Add the local network assigned IP address; i.e. 192.168.xxx.xxx, for the computer you're trying to connect to via RDP, to the Eset firewall Trusted Zone. The existing default Eset firewall rule only allows RDP connections to IP addresses specified in the Trusted Zone.

Some additional important information: https://support.emsisoft.com/topic/31789-got-infected-by-gero-ransomware-file-need-decrypt/ Additionally, it appears this variant is not decryptable:

This is a new variant of STOP ransomware: https://twitter.com/demonslay335/status/1166760481786421248

Kaspersky just released their 2018 Malware Incident Report today. Most notable is the following: https://securelist.com/incident-response-analytics-report-2018/92732/ Also: https://www.infosecurity-magazine.com/news/the-great-big-ransomware-revival/