Hips Configuration

[govind 0]

Dear Eset, 

I suggest ESET internet security to all my clients and most of them are satisfied with its speed and stability. As an extra safety measure i would like to create a HIPS rule to prevent files being modified/encrypted in  selected  folders/partitions. The rule should allow only the trusted apps to access/modify the files. This is something like Bitdefender safe files feature. Is this possible in Eset Hips settings ? . If yes , kindly guide me. Thanks 🙏

Thanks

Govind 🙂

 

[Marcos 5,074]

You can create such HIPS rule as follows:

1, On the first wizard screen, select "Allow" action and enable "Target files":

2, In the next step select "Specific applications" and enter the path to applications that will be able to modify files in protected folders:

3, Then enable "Write to file" and possibly also "Delete file":

4, Finally select the target folder that you want to protect:

5, Create a similar HIPS rule but now with the action set to Block and without any source applications (ie. "Any application" should be selected from the drop-down menu like in step 2).

[itman 1,659]

Assuming one only wants to only protect User account directories from modification; e.g. My Documents, etc., my favorite is Win 10 File History option. -EDIT- You can also add additional directories of your choosing to File History backup processing: https://www.tenforums.com/tutorials/55259-add-remove-folders-file-history-windows-10-a.html

File History will create a backup of all such directories with a frequency from 1 hour to 24 hours. It creates these backups in a directory titled "FileHistory." I directed that this directory be created on a non-boot drive I have installed for backup purposes. I then created two Eset HIPS rules:

1. Allow svchost.exe to modify all files in D:\FileHistory\*.*; where "D" represents any non-boot drive. Note that File History runs as a Win service via a scheduled task.

2. A block or ask rule preventing all applications from modifying all files in D:\FileHistory\*.*.

In the event of my User account directories became encrypted by ransomware, I can just delete all of them and restore them from File History. This option also provides additional protection from file loss other than ransomware such as boot drive failure. It saved my butt recently when my Win boot drive crashed.

The finally advantage of this approach is I don't have to concern myself with the issue of what apps can and cannot access my User account directories files.

Edited March 2, 2020 by itman

[itman 1,659]

Additionally, HIPS rules against ransomware can be deployed per this Eset knowledge base article: https://support.eset.com/en/kb6119-configure-hips-rules-for-eset-business-products-to-protect-against-ransomware .

[govind 0]

15 hours ago, Marcos said:

You can create such HIPS rule as follows:

1, On the first wizard screen, select "Allow" action and enable "Target files":

2, In the next step select "Specific applications" and enter the path to applications that will be able to modify files in protected folders:

3, Then enable "Write to file" and possibly also "Delete file":

4, Finally select the target folder that you want to protect:

5, Create a similar HIPS rule but now with the action set to Block and without any source applications (ie. "Any application" should be selected from the drop-down menu like in step 2).

Thanks Marcos for your quick reply. 😍 I have configured it as per your information.

I would like to know whether this would ensure protection from unknown variants of Ransomware.

And should add the following rules given in the below link shared by itman ?  🙄

 

https://support.eset.com/en/kb6119-configure-hips-rules-for-eset-business-products-to-protect-against-ransomware

 

 

 

 

[Marcos 5,074]

You can configure also the extra HIPS rules as per the article to harden the system against ransomware even more. While the rules may cause issues in environments where scripting is used and editing or disabling a particular rule may be needed, home users should not encounter any issues if using the system in a standard way.

[SeriousHoax 83]

@Marcos

What windows related processes should I allow if I want to allow manual modification of files in that folders like manually renaming, moving, pasting new files.

[Marcos 5,074]

You can temporarily change the blocking rule to an ask rule and you'll be prompted for an action. Then you can allow the action and create a permissive rule. However, the more exceptions you'll make the less resistant the block rule will be against ransomware that may inject into legitimate processes.

[SeriousHoax 83]

11 minutes ago, Marcos said:

You can temporarily change the blocking rule to an ask rule and you'll be prompted for an action. Then you can allow the action and create a permissive rule. However, the more exceptions you'll make the less resistant the block rule will be against ransomware that may inject into legitimate processes.

Yeah right. I usually use ask for most HIPS rules so personally troubleshooting what needs to allowed for certain modification would be better. Ok, thanks.

[itman 1,659]

9 hours ago, Marcos said:

You can configure also the extra HIPS rules as per the article to harden the system against ransomware even more.

I will also add I consider Eset recommended HIPS rules against ransomware referenced in the KB article too permissive for my liking. I additionally monitor anything that would start any of the Windows scripting processes including cmd.exe. Monitoring PowerShell  this way could cause issues in commercial installations that employ PowerShell scripts. And of course, you're going to get alerts from cmd.exe on occasion. 

[itman 1,659]

I will also add that malware developers are constantly adapting to security solutions detection methods. Currently they have evolved to increasing deploying Win OS trusted system utility processes to execute their malicious scripts. Therefore it is up to Eset security researchers to be "on top" of these attacks and add appropriate machine learning rules to the Augur engine and flag these script executions as suspicious. And to hell with the false positive element in this regard I say.

[SeriousHoax 83]

2 hours ago, itman said:

I will also add that malware developers are constantly adapting to security solutions detection methods. Currently they have evolved to increasing deploying Win OS trusted system utility processes to execute their malicious scripts. Therefore it is up to Eset security researchers to be "on top" of these attacks and add appropriate machine learning rules to the Augur engine and flag these script executions as suspicious. And to hell with the false positive element in this regard I say.

I think Trend Micro is one of the products that kind of does what you are suggesting and blocks most of the suspicious script executions by default. It may result in some false positives but it's very good against script based malwares where ESET is a bit weak in this department. 

Edited March 3, 2020 by SeriousHoax

[Marcos 5,074]

6 minutes ago, SeriousHoax said:

It may result in some false positives but it's very good against script based malwares where ESET is a bit weak in this department. 

Please provide examples of script malware that ESET was unable to detect. We actually have a very effective script scanner which is why users often report us alleged false positives on their website because "no other AV detected malware". However, after checking the website we confirmed that it was really compromised and infected.  ESET also employs a command line and AMSI scanner to improve detection even more on systems with AMSI support.

[itman 1,659]

1 hour ago, Marcos said:

Please provide examples of script malware that ESET was unable to detect. We actually have a very effective script scanner which is why users often report us alleged false positives on their website because "no other AV detected malware". However, after checking the website we confirmed that it was really compromised and infected.  ESET also employs a command line and AMSI scanner to improve detection even more on systems with AMSI support.

This is great as long as Eset has an existing signature for the malware code within the script.

Malware authors are increasing embedding .Net code and recently C++ code compiled on-the-fly within scripts. It was only fairly recently Eset flagged a .Net based PowerShell global keylogger embedded in a .vbs script I used for testing purposes. I used this script two years prior w/o detection.

Attached is an AMSI-Bypass PowerShell script that Eset doesn't detect.

AMSI-Bypass.zip

Edited March 3, 2020 by itman

[SeriousHoax 83]

1 hour ago, Marcos said:

Please provide examples of script malware that ESET was unable to detect. We actually have a very effective script scanner which is why users often report us alleged false positives on their website because "no other AV detected malware". However, after checking the website we confirmed that it was really compromised and infected.  ESET also employs a command line and AMSI scanner to improve detection even more on systems with AMSI support.

I am not saying it's bad at this but saying I've seen it missing script malwares more than other types. I always email those samples to the ESET lab and they also response when they add those to the signatures. But haven't found any sort of serious misses in recent times like ransomwares but I will share here if I find such. I think @itman may have some examples of misses.

Edit: Well I was right about him. He even has logs.

Edited March 3, 2020 by SeriousHoax

[itman 1,659]

F-Secure has an interesting article on AMSI bypasses. Of note:

Quote

Can the signatures be bypassed?

A script’s content is only deemed as malicious if the appropriate signature has been logged. However, bypassing a logged signature is relatively easy; all a threat actor needs to do is simply change the payload, as shown below.

Effectively, this becomes a cat and mouse game, as it would be up to antivirus providers to update their own signatures. AMSI can’t do much in this scenario, as it is mainly an interface for antivirus programs. We will not be diving into this too deeply, as signature bypassing on its own is a huge topic.

https://blog.f-secure.com/hunting-for-amsi-bypasses/

Edited March 3, 2020 by itman

[Marcos 5,074]

5 minutes ago, itman said:

F-Secure has an interesting article on AMSI bypasses. Of note:

https://blog.f-secure.com/hunting-for-amsi-bypasses/

Yes, I've read this article a couple of weeks ago and we've also seen the PoC for AMSi bypass. We plan to implement some improvements for smart detection of AMSI bypass, detection of PoC (ie. not actual malware) cannot be deemed a solution. However, ESET also employs a HIPS-driven command line scanner that scans scripts upon execution. Mimikatz as well as other malware can be detected also in memory upon execution if a standard detection is bypassed. It is a matter of fact that crooks always try hard to find ways how to bypass AV detection. In a presentation by an independent penetration tester that I attended last years, ESET was the second AV to withstand manipulations and various tricks to evade detection of a Metasploit payload.

[itman 1,659]

AMSI bypassing withstanding, there is the question of Eset's effectiveness against highly obfuscated scripts: https://www.mrg-effitas.com/research/current-state-of-malicious-powershell-script-blocking/ . I for one would very much like to see a retest by MRG on this issue using Eset current version products.

[itman 1,659]

In this BitDefender commissioned test by A-V Comparatives: https://www.av-comparatives.org/tests/advanced-endpoint-protection-test/ which Eset apparently declined to participate, one section was dedicated exclusively to PowerShell based malware:

Quote

PowerShell-based File-less Attacks and File-based Exploits Test

File-based malware and ransomware such as VBS, JS or MS Office macros can install a backdoor on victims’ systems and create a control channel (C2) to the attacker, who is usually in a different physical location, even in a different country. Apart from these well-known scenarios, it is possible to deliver file-less malware using exploits, remote calls (PSexec, wmic), task scheduler, registry entries, Arduino hardware (USB RubberDucky) and WMI calls. This can be done with built-in Windows tools like PowerShell. These commands load the actual malware directly from the Internet into the victim’s memory and continue to expand further into the local network with native OS tools, or may even become persistent on machines in this way.

In pen-tests we see that in such file-less scenarios, many popular AV products still provide insufficient protection. Some newer business security products seem to be focusing on this problematic area now, and are closing the gap in some scenarios.

In the following tests, we focused on several different command-line stacks, CMD/PS commands, which download malware from the network directly into RAM (staged) or base64 encoded calls. Thus, we completely avoid disk access, which is usually (well) guarded by AV products. We sometimes use simple concealment measures or change the method of the stager call as well.

Once the malware has loaded its 2^ndstage, an http/https connection to the attacker will be established. This inside-out mechanism has the advantage of establishing a C2 channel beyond the majority of NAT and firewall products to the attacker (http/https). Once the C2 tunnel has been established, the attacker can use all known functions of the common C2 products (Meterpreter, PowerShell Empire). These include e.g. file uploads/downloads, screenshots, keylogging, Windows shell, and webcam snapshot

Test scenarios used

Below the 25 test scenarios used in the PowerShell-based File-less Attacks and File-based Exploits Test are shortly described.

The results were far from encouraging with only two products achieving a top score of 23/25 detections.

Edited March 4, 2020 by itman

[itman 1,659]

One other important point in regards to ransomware protection and any other malware that deploys scripts.

Eset firewall rules need to be created to monitor outbound network traffic done by scripts and other commonly abused processes used by malware developers. Additionally, these firewall rules will serve as a backup mechanism to any like HIPS created rules in the event malware was able to bypass those. A very common technique employed by malware developers to use scripts to connect to their remote C&C servers for the purpose of downloading their malicious payload executable or to stage a remote execution attack. How to create these firewall rules are given here: https://support.eset.com/en/kb6132-configure-firewall-rules-for-eset-endpoint-security-to-protect-against-ransomware .

Finally, Eset best practices recommendations should be reviewed for additional ways to mitigate ransomware: https://support.eset.com/en/kb3433-best-practices-to-protect-against-filecoder-ransomware-malware .

Edited March 4, 2020 by itman

[itman 1,659]

One final comment about ransomware attacks against commercial concerns.

There are organizations that compile statistics on sources of ransomware attacks on a yearly basis. One statistic that has not changed since this tracking commenced is 90%+ of ransomware is e-mail based. It would therefore be logical and prudent that commercial concerns direct their security efforts at preventing e-mail based ransomware attacks. These methods include:

1. If a mail server is deployed, it be secured via the appropriate product such as Eset Mail Server Security and that product be configured for maximum security.

2. Workstation e-mail clients be configured for maximum security;

• all active content is disabled
• attachments be displayed in line. Employee's need to be trained on how to spot suspicious attachments.
• attachments open via their respective file type; e.g. .docx is opened in MS Word protected mode, etc..
• links within e-mails are either disabled or open within the default browser.
• and my personal favorite, e-mails only display in text mode.

Another alternative is to employ the services of an e-mail screening provider. Obviously, there are privacy and security concerns that need to be evaluated with this alternative.

Edited March 4, 2020 by itman

[SeriousHoax 83]

Any thoughts on this? https://www.bleepingcomputer.com/news/security/windows-explorer-used-by-mailto-ransomware-to-evade-detection/

[itman 1,659]

1 hour ago, SeriousHoax said:

Any thoughts on this? https://www.bleepingcomputer.com/news/security/windows-explorer-used-by-mailto-ransomware-to-evade-detection/

We've discussed Debug mode privately. The difference here is they started explorer.exe from their attack program in Debug mode. then injected their malicious code into via:

Quote

use debug APIs such as WaitForDebugEvent to perform the actual malicious code injection and have the explorer.exe process execute it.

Since they are using legit API's to do their dirty work, it probably wouldn't trigger any suspicions from Eset's deep behavior inspection processing for example.  On the other hand, Eset HIPS does have a option, Debug another application, defined to be "attach debugger to another application." Appears this is exactly what is occurring here.

Problem here is this can be done for any process running at medium Integrity level such explorer.exe. Eset does set a hook into explorer.exe. Whether they by default monitor for debug activity in explorer.exe, only Eset can answer.

BTW -code injection into explorer.exe is nothing new. And this malware still has to set a thread into explorer.exe. So just monitoring explorer.exe for process modification via a HIPS rule should do the trick along with allow rule/s for legit Win processes that do the same. Or, by monitoring explorer.exe startup via HIPS rules.

Personally, I think an Eset sig. detection for the parent process should do the trick.

Edited March 4, 2020 by itman

[itman 1,659]

Appears Eset is detecting via Augur machine learning rules some of the AMSI bypasses. At least those  loosely described as:

Quote

This is the true bypass. Actually we do not "bypass" in the strict meaning of the word, we actually DISABLE it. AMSI has several functions that are executed before any PowerShell code is run (from Powershell v3.0 onwards), so to bypass AMSI completely and execute any PowerShell malware, we need to memory patch them to COMPLETELY DISABLE it.

BTW - I found an undocumented Eset feature in regards Augur's writing to the Detection log. There might be multiple log entries related to the Augur detection. But only the last detection shows in the Detection log. You have to double click on that entry which will display all sub-entries as follows. Appears Augur is using decoded.exe as the file it analyzed after decypting the bypass .exe:

 

 

Edited March 4, 2020 by itman

[itman 1,659]

Actually, there are better ways to deliver script based malware. That is, convert the script to a .exe.

Here's an article on how to do so for a PowerShell script: https://www.ilovefreesoftware.com/19/windows/powershell-to-exe-converter.html . This will also allow me to password protect my script code so Eset can't scan it via hueristics. I then phish the target into entering the password via e-mail etc..

Here's one for .bat scripts: https://www.addictivetips.com/windows-tips/convert-a-bat-script-to-an-exe-on-windows-10/ . Note this runs hidden.

One for .vbs scripts: https://www.snapfiles.com/get/vbstoexe.html

Finally and my favorite, one for Python scripts: https://ourcodeworld.com/articles/read/273/how-to-create-an-executable-exe-from-a-python-script-in-windows-using-pyinstaller . Note that Win AMSI does not scan Python scripts.