itman

Let me begin with it is almost impossible to stop malicious use of PowerShell by a determined attacker. One might think that creating a HIPS ask rule to monitor the startup of C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe and C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe will detect all PowerShell execution. It won't. Past examples of malicious use of PowerShell include to name few: 1. The attacker downloading the old version of PowerShell, ver. 2.0, used in Win 7 and running it. This version for example, will run fine on Win 10 as long as .Net 2.0 or 3.5 is installed. 2. Downloading the current ver. of PowerShell to any directory, possibly renamed but not necessary to do so, and running it from that location. 3. Executing .Net subassemblies associated with PowerShell via C#, C, etc. program means. The only way to completely stop PowerShell execution would be to employ a security product that can block execution by hash value and then create ask/block rules for hash values associated with every known version of PowerShell. Also, setting PowerShell to Constrained Language mode or using AppContainer which does the same. Eset has a few knowledgebase articles on PowerShell and other script use mitigations: 1. Firewall rules: https://support.eset.com/kb6132/ 2. HIPS rules: https://support.eset.com/kb6119/ These will prevent the most prevalent malicious use of PowerShell. They will not prevent all malicious use of PowerShell.

This one is GrandCrab ransomware. Suspect the javascript payload is heavily obfuscated. Such has been the "Achilles heel" for AV's for some time. If you look at the Behavior section on the detection at VT, it is running PowerShell. One reason among many I have a HIPS rule to monitor all PowerShell execution.

Notable are the AV solutions not detecting it: AVG/Avast, Kaspersky, and Symantec. Microsoft detects as a PUA. The only Next Gen solution detecting it is Cylance and its Unsafe classification is basically one notch above the Suspicious rating confidence-wise. Almost all the other detections are "generic" based indicating the software might have behavior code associated with Trojan activity. It is not unreasonable to assume a hard drive utility associated with monitoring activities would exhibit such behavior.

No problem on my EIS 12.0.31 build and I am located in the U.S..

It also should be noted that Eset's HIPS is not going to throw an alert on suspicious process behavior unless: 1. That behavior has been confirmed with high confidence to be associated with malware. 2. Other process traces exist to associate the behavior with malware such as code snippets and the like. If one wants a solution that absolutely blocks suspicious process behavior regardless of if it is malicious or not, they are better served using a solution such as NoVirus Thanks OSArmor. Whereas this solution works with minimal negative impact in Home based environments, it can reek havoc in corporate environments where many of the processes it blocks are routinely deployed. -EDIT- It should be noted that OSArmor is marketed, it is freeware BTW, as anti-exploit protection to be run in parallel with your existing AV solution. I don't use it because it can conflict with other AV software components. And there have been past conflicts with Eset; namely the HIPS component. It is however, a great source for creating user rules for Eset's HIPS which I have used in the past. Finally, it goes without saying that this type of software is only for advanced users with the OS internals knowledge to effectively respond to the blocked activity it can generate without borking their OS and apps installation/execution activities.

Here's an example of an alert from the new ver. 12.1 HIPS behavior detection:

Good catch. I didn't know that option existed. Also the only way I could enable this is to right click on a shown existing connection and set off the TCP only option there. Thereafter, it applied to all shown connections.

If you want to monitor all UDP connections, use something like Nirsoft's LiveTcpUdp network monitor.

Eset has significantly improved its YARA behavior signatures in ver. 12. As such, most of these types of alerts will be detected by the realtime protection versus the HIPS. Again, Eset originally developed the HIPS for protection of its own internal processes and in default mode, it is still primarily used for that purpose. If you don't think IDS protection adds substantial security benefits, then by all means continue to use the Win Firewall. BTW - you may not be aware the Windows stores its firewall rules in clear text in the registry. As such a hacker with proper access can easily disable or modify them. Ditto for the firewall service itself.

Not exactly. The Window firewall for example doesn't monitor IPv4/6 localhost connections; the Eset firewall does. Also Eset has IDS protection, the Win firewall does not. Note that changing default IDS rules result in corresponding default firewall rules be modified. Finally, Eset a few vers. back added the Troubleshooting Wizard to the Network Connections feature. As a result in the default firewall mode, any connections blocked are done so silently and one has to refer to the Troubleshooting Wizard and determine if the count shown has a non-zero value. If so, you have to click on the setting to see any blocked connection activity. Will then be presented with an Unblock tab option. Clicking on that option will result in Eset creating the necessary firewall rules to allow the activity. There are a few issues with the Troubleshooting Wizard. Entries listed there will "age off" after 1 hour resulting in possible blocked activity you are not aware of. Also the Eset created firewall rules tend to be a bit too "permissive" for my liking. As far as the HIPS goes, without adding custom user rules, it is for the most part "silent." It will trigger only when select protected system and registry areas modification activity by unknown/untrusted process activity occurs. Also when suspicious ransomware and like behavior was attempted.

If its using UDP, the Eset network connections feature will not show the connection. It only shows TCP connections similar to many network activity monitors such as TCPView.

Did you reboot immediately after making the Autoruns changes? Also you posted that you are using Win 10 Enterprise. You sure you don't have any Group Policy rule set in regards to context menu changes? It sure appears to me that Windows is re-adding those menu items regardless of any deletion of same on your part. It also seems reasonable to me that Win 10 will not allow for Pin to Start menu to be disabled for example, since Win Store apps will auto add any new app to it.

Try using Autoruns to disable the Context Menu items. Screen shot given below. The advantage of Autoruns is it first, will modify the associated registry keys by simply unchecking the shown associated item. Next, the registry keys are only modified and not permanently deleted. Simply recheck marking the item reactivates the associated registry key. Note: when opening Autoruns for the first time, click on the Option tab and remove the checkmarks for "Hide Microsoft and Windows entries." This will ensure all Windows settings are shown. Also you will have to run Autoruns as admin to perform most registry modification activities.

I run as a limited admin and never created a standard user account, so that is not the culprit.

EIS ver. 12.0.31 I noticed something similar after my recent upgrade to Win 10 1809. When I was running 1803, I had the PC set to never enter standby mode. This was because my old hardware was not compatible with it if Core Isolation/Memory Integrity was enabled. I reenabled standby mode on 1809 since it won't let me enable Memory Integrity. My scheduled scan is set to run on Thursday at noon. Yesterday the scan did not run and the PC was in standby mode at that time. I also have the run as soon as possible if scan is missed option enabled. So I have now set it to run if does not do so after 4 hours from the scheduled time. So we'll wait and see what happens when the PC happens to be in sleep mode at scheduled scan time.

I was able to create a .iso using Media Creation Tool 1809 with Eset IS enabled w/o issue. I then used the disk based .iso to perform an in-place upgrade from 1803 to 1809 w/o issue. I additionally burned a bootable DVD from the .iso file using Windows DVD writer which successfully booted w/o issue. If your desire is to create a bootable 1809 ver. from the downloaded .iso to a USB drive, I would recommend Rufus 3.0 which can be downloaded here: https://rufus.ie/en_IE.html . Note: use default format options. Do not format the USB drive as NTFS.

No clue what the Windows alert is showing since it is not in English language. This is an English language forum.

Then why is the alert shown in red color? I have never seen that before as I recollect. Also my other questions; no action given and nothing quarantined? Because it's HTML code, Eset JavaScript scanner just blocks the code execution and that's it? -EDIT- Below is a screen shot of the actual Eset alert. Appears my above assumption of in-memory execution blocking is correct. Also, I guess the red color is now used to show an actual threat and orange/brown used for simulated malware detection? Details on alert color coding scheme in log files would be helpful in the Eset online help.

Are you stating that this stopped the inbound port 445 blocked connections you originally posted?

If this was the case, you should have been receiving HIPS alerts about modification of registry keys. Did you check your Eset HIPS log for entries related to your registry modification activities? If none of the prior apply, Eset is not preventing any of the registry key modifications you are performing.

@Marcos, suspect that the recent patch Microsoft issued for a JavaScript vulnerability which resulted in jscript.dll being modified might have busted Eset's javascript scanner in IE11.

Win 10 Home x(64) 1809, Internet Security 12.0.31 Never saw this one before. IE11 detected threat is shown in red color in the Eset associated log. Although no action appears to have occurred per log entry, I assume nothing malicious happened since the Eset alert stated threat was deleted. Note that nothing for this exists in Quarantine.

If a worm is able to install itself, the first thing it will try to do is connect outbound TCP port 445. Eset by default doesn't block outbound TCP port 445 since if your on a internal network and share files or printers, it is valid communication. I am not on a network and as such, don't share files or printers.

Try AdwCleaner. You can download it here: https://www.malwarebytes.com/adwcleaner/

You already posted a thread on this topic here: https://forum.eset.com/topic/17959-hank/