Configure ESET as default-deny (bye ransomware!)

As always another great post from @RoboMan. I use ESET with these HIPS rules but I have modified some of the rules. I have HIPS configured to disable execution of wscript, cscript, powershell, mshta, ask if anything tries to modify the hosts file, ask for changes in startup applications. I think it's also a good option to set rules in the firewall to ask for outgoing connections from command prompt and regsvr32.
Are you sure? The HIPS settings from RoboMan post, do not disable the execution of wscript.exe, cscript.exe, etc., but only prevent starting them from Explorer. This will not stop some other ways of executing them (often used by malware), for example, via cmd.exe or WMI.
You can try the below command to be sure:
cmd /c wscript
 
Are you sure? The HIPS settings from RoboMan post, do not disable the execution of wscript.exe, cscript.exe, etc., but only prevent starting them from Explorer. This will not stop some other ways of executing them (often used by malware), for example, via cmd.exe or WMI.
You can try the below command to be sure:
cmd /c wscript
I do not use these same settings as Roboman. I have HIPS to deny any application from launching powershell, cscript, wscript and mshta. Since I don't need them for anything I don't encounter any problems. I can't comment about the rules for MS Office since I use Libre office which has macros disabled. Theoretically even then the HIPS can be bypassed if a malware copies any of these files(like wscript), renames it and then executes it but then again the chances of a home user running in this type of malware is very small.
 
I do not use these same settings as Roboman. I have HIPS to deny any application from launching powershell, cscript, wscript and mshta.
...
I think that some members who use Eset, could be interested, how to deny any application from launching PowerShell.:giggle:(y)
 
I think that some members who use Eset, could be interested, how to deny any application from launching PowerShell.:giggle:(y)
I have this HIPS rule set up for powershell. Theoritically it should block any powershell execution.
 

Attachments

  • 1.JPG
    1.JPG
    77.1 KB · Views: 747
  • 2.JPG
    2.JPG
    70.3 KB · Views: 737
  • 3.JPG
    3.JPG
    74.3 KB · Views: 718
  • 4.JPG
    4.JPG
    76.6 KB · Views: 719
I have this HIPS rule set up for powershell. Theoritically it should block any powershell execution.
Could you test these HIPS settings by running the below commands form Explorer:
  • cmd
  • cmd /c powershell
  • wmic process call create powershell
(y):giggle:
 
Could you test these HIPS settings by running the below commands form Explorer:
  • cmd
  • cmd /c powershell
  • wmic process call create powershell
(y):giggle:
The first two are executed from the run command box and the last two are executed from command prompt. I didn't try launching cmd since I don't have any HIPS rule to block cmd from executing(I need it sometimes) but I have the firewall set to block all outgoing connections from cmd.
 

Attachments

  • powershell 2.JPG
    powershell 2.JPG
    91.5 KB · Views: 790
  • powershell 4.JPG
    powershell 4.JPG
    103.6 KB · Views: 724
  • powershell 3.JPG
    powershell 3.JPG
    97.8 KB · Views: 676
  • powershell.JPG
    powershell.JPG
    99.3 KB · Views: 692
@RoboMan while these rules should suffice in stopping most of the ransomwares I think you can also add two firewall rules that would stop malwares like astaroth. Since these HIPS rules do not include wmic and certutil it would be a good idea to prevent wmic and certutil to connect to the internet using the ESET firewall. :):emoji_v:
 
The first two are executed from the run command box and the last two are executed from command prompt. I didn't try launching cmd since I don't have any HIPS rule to block cmd from executing(I need it sometimes) but I have the firewall set to block all outgoing connections from cmd.
Blocking outgoing connections from cmd.exe is a weak protection, because most commands used by malc0ders are the child processes of cmd.exe, which will not be blocked by the firewall rule for cmd.
 
Blocking outgoing connections from cmd.exe is a weak protection, because most commands used by malc0ders are the child processes of cmd.exe, which will not be blocked by the firewall rule for cmd.
So in that case would it be advisable to configure the HIPS not to allow cmd to launch any child processes?
 
So in that case would it be advisable to configure the HIPS not to allow cmd to launch any child processes?
You can do it, but it will be similar in effect to blocking CMD.
It is a problem with blocking CMD or its child processes. On many computers, CMD can be blocked with admin bypass and some whitelisting of .bat and .cmd files (like in H_C). The best way is blocking cmd and whitelisting some safe command lines (NVT ERP, Excubits Bouncer or CommandLineScanner).
 
I finally got around to adding the Powershell rules on top of ESET's recommended ransomware rules. I had something I was working on that needed a powershell line run, but I finished. I tested it out and it seemed to be working. Then this morning randomly svchost.exe tried to open powershell in the background. Are there any legitimate processes that need that to happen?
 
  • Like
Reactions: ZeroDay
@devjit2018 have you noticed it blocking any svchost.exe regularly? I have OSArmor set to block all powershell before and never noticed it blocking anything...However I know CruelSister had mentioned that programs could get around OSArmor.
 
  • Like
Reactions: ZeroDay and Nevi
@devjit2018 have you noticed it blocking any svchost.exe regularly? I have OSArmor set to block all powershell before and never noticed it blocking anything...However I know CruelSister had mentioned that programs could get around OSArmor.
What HIPS rule did you set? On my PC, I never get alert from ESET HIPS about blocking svchost.
 
Here's the rule I made...maybe I did it wrong? It is blocking the process from launching Powershell every 25 minutes. I had the rules yesterday and it was not exhibiting this behavior, but this morning it occurred out of the blue. I am curious if it has to do with the VPN connection I was setting up to connect to a VPS, which is what I needed Powershell for in the first place. I am going to restart after running all the second opinion scans and see if it stops if I don't connect to the VPN after a restart.
 

Attachments

  • HIPS1.PNG
    HIPS1.PNG
    23 KB · Views: 614
  • HIPS2.PNG
    HIPS2.PNG
    19.5 KB · Views: 596
  • HIPS3.PNG
    HIPS3.PNG
    25.1 KB · Views: 549
  • HIPS4.PNG
    HIPS4.PNG
    29.7 KB · Views: 590
  • HIPSWarning.PNG
    HIPSWarning.PNG
    10.7 KB · Views: 604
Last edited:
Okay so you disabled launching of powershell for every applications. It should throw HIPS alert when some legit applications require launching of powershell. If you have enabled constraint mode for powershell via syshardener and have powershell blocked from creating outgoing connections with the ESET Firewall, you can try editing the HIPS rule for powershell to this one below. If you suspect any malware infection, open ESET, go to Tools and see the list of the running processes to see if any suspicious process is running.Then go to Network Connections and see if any suspicious application is connecting to the Internet. If you know how to use ESET SysInspector, you will be able to spot the malware.
 

Attachments

  • 1.JPG
    1.JPG
    85.6 KB · Views: 589
  • 2.JPG
    2.JPG
    84.2 KB · Views: 533
  • 3.JPG
    3.JPG
    84.6 KB · Views: 531
  • 4.JPG
    4.JPG
    79 KB · Views: 588
Last edited:
Okay so you disabled launching of powershell for every applications. It should throw HIPS alert when some legit applications require launching of powershell. If you have enabled constraint mode for powershell via syshardener and have powershell blocked from creating outgoing connections with the ESET Firewall, you can try editing the HIPS rule for powershell to this one below. If you suspect any malware infection, open ESET, go to Tools and see the list of the running processes to see if any suspicious process is running.Then go to Network Connections and see if any suspicious application is connecting to the Internet. If you know how to use ESET SysInspector, you will be able to spot the malware.

Thanks, I’ll give that a shot and see how that works. I actually default deny all connections and have no rule for powershell, so I should be good to go for the firewall.

The most suspicious running process I have is OSArmor, by number of users, and IVPN :ROFLMAO:. I have never used sysinspector, so I'm not sure what I'm looking for.

Decided since I’m not sure what I’m looking at to restore an image at the point before I was utilizing Powershell and see if applying those rules works without blocking things regularly.
 
@Andy Ful Hello I followed your steps to test ESET's protection and this was the result:

View attachment 212795View attachment 212796

This is what should happen? Thank you very much.
Not exactly, but anyway, from your post it follows that:
  1. Eset does not prevent cmd.exe from spawning powershell.exe.
  2. Eset prevents powershell.exe from spawning wmic.exe.
We still do not know if wmic.exe can spawn powershell.exe.

My test commands were slightly different:
  1. cmd
  2. wmic
  3. cmd /c powershell
  4. wmic process call create powershell
All commands have to be run independently from Explorer! In your case, they were not.
The first and the second - test if cmd.exe and wmic.exe can be executed from the Windows Explorer. If they can be executed, then:
The third - can test if cmd.exe is able to spawn powershell.exe.
The fourth - can test if the wmic.exe is able to spawn powershell.exe.

There are many ways to execute powershell.exe, those mentioned by me are only two examples.