ESET Smart Caching Questions

[itman 1,718]

Do you have access to another PC with Win 10 1809 on to this? One possibly answer here is there is an issue with Eset on 1903 with AMSI.

Also PM me the PowerShell .txt example you were testing with that Eset detects in .ps1 form. Attach it as a non-password protected .zip file.

Edited July 5, 2019 by itman

[itman 1,718]

5 hours ago, itman said:

Also PM me the PowerShell .txt example you were testing with that Eset detects in .ps1 form. Attach it as a non-password protected .zip file.

In regards to the PowerShell .txt malware sample, it is a heavily obfuscated .Net based PowerShell script. Setting PowerShell to Constrained Language mode would have stopped it from executing regardless of the Eset element.

My test procedure for this malware script as follows:

1. Unzipped it and renamed it from .txt to .ps1.

2. Started Process Explorer for monitoring purposes.

3. Opened Run window in Win 10 x(64) 1809.

4. Entered into Run window;

powershell -ep bypass malware.ps1.

PowerShell never started execution and Eset detected the malicious script via AMSI scanning:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
7/5/2019 10:30:23 AM;AMSI scanner;file;C:\Users\xxx-xxxx\Downloads\powershell\ps.ps1;PowerShell/TrojanDropper.Agent.S trojan;blocked;xxx-xx\xxx-xxxx;;169A92DADC65118C905957FB081493087B422140;7/5/2019 10:30:23 AM

-EDIT- Of note and important! Eset did not delete and quarantine the malware. It only blocked its execution. So it appears, AMSI detections will require manual cleaning. -EDIT- Appears after AMSI detection, upon next access to the file, Eset's realtime engine will detect, delete, and quarantine the file.

 

Edited July 5, 2019 by itman

[0xDEADBEEF 43]

22 minutes ago, itman said:

PowerShell never started execution and Eset detected the malicious script via AMSI scanning:

even in 1903 this is the case. So apparently AMSI is working fine in 1903.

This is the most trivial case and I'd be surprised if this can bypass the protection

[itman 1,718]

A few more discussion points to "tidy up"

The first is about Eset being able to detect the malware script when it is created on the local device in .ps1 format. Appears that advanced hueristics will actual run the script via Powershell in its sandbox. This will allow for examination via AMSI. In this case, Eset will detect the malware and can delete and quarantine it.

Next up is this malware script's code. I looked at it again. Appears it is not obfuscated. All that voluminous code at the end of the script appears to be either packed or encrypted. Unfortunately, my skill set in either of those two areas is deficient. So I can't analyze it further.

This then leads to the ability of any security solution being able to detect in a .txt file:

1. That packed or encrypted code actually exists.

2. If the solution did detect the code, could it actual decipher it?

Definitely the answer is no if its encrypted with a strong cypher.

From what I can tell from this analysis to date, there appears to be a deficiency in the Eset file scanning whitelist processing. One solution would be for the HIPS to monitor for existing file renaming where the extension was changed to .ps1. When this occurs, the original whitelist status would be removed. It appears that Eset presently special cases .ps1 files overall in that these files are indeed always re scanned . But it appears so only if they were originally scanned as .ps1 files.

[Marcos 5,158]

It's all just about smart optimization, nothing else and nothing more. It's caused by obfuscation that the txt file was not detected.

1, Advanced heuristics doesn't scan scripts, there's a script scanner for that and the command-line (AMSI) scanner on Windows 10.
2, Scripts are not run sandboxed.
3, HIPS doesn't monitor file operations but real-time protection does.

We'll try to address it asap but if turns out to cause more harm then good then we'll probably leave it until it's addressed in a smarter way in the future utilizing HIPS.

[0xDEADBEEF 43]

6 minutes ago, itman said:

The first is about Eset being able to detect the malware script when it is created on the local device in .ps1 format. Appears that advanced hueristics will actual run the script via Powershell in its sandbox. This will allow for examination via AMSI. In this case, Eset will detect the malware and can delete and quarantine it.

I am not sure if the detection from realtime scanner utilizes the AMSI or not. AMSI to me is like AMS to PE scanning, which will only be triggered upon execution.

10 minutes ago, itman said:

Definitely the answer is no if its encrypted with a strong cypher.

I think the core problem here is to detect what type of script the txt file is in (e.g. js, powershell, or anything else). And this may be non trivial. Apparently there are samples which can even trick AMSI, however here with unobfuscated code the only possible explanation is that the scanner doesn't even bother to check if txt file is actually js or something else.

12 minutes ago, itman said:

From what I can tell from this analysis to date, there appears to be a deficiency in the Eset file scanning whitelist processing

This is what I am thinking 

The subtle thing here is that if people want to optimize the realtime scan performance with aggressive caching, they had better make sure all possible ways of execution can be guarded to avoid leakage. For example, what if there are 3rd party interpreters that is not going through AMSI? In the old days, people have tried to use some installer's interpreter to bypass the "guards". There are many possibilities here. 

18 minutes ago, itman said:

One solution would be for the HIPS to monitor for existing file renaming where the extension was changed to .ps1. When this occurs, the original whitelist status would be removed. It appears that Eset presently special cases .ps1 files overall in that these files are indeed always re scanned . But it appears so only if they were originally scanned as .ps1 files.

I was thinking about this before I start this thread. However, it is not an elegant solution, and there may be other possibilities to bypass with similar principles..

[0xDEADBEEF 43]

9 minutes ago, Marcos said:

It's caused by obfuscation that the txt file was not detected.

I think the sample I provided (not the one in this thread) is not even obfuscated. I don't know how the scanner actually does signature matching with text files but it is definitely not only the obfuscation's fault.

 

Anyway I sincerely hope that this could be addressed in an elegant way in the near future 

[itman 1,718]

16 minutes ago, Marcos said:

It's caused by obfuscation that the txt file was not detected. 

If this was the case, it would have been true when Eset scanned the downloaded .ps1 version of the malware. Eset had no trouble detecting that when initially scanned.

This means that Eset processes .ps1 files differently upon initially scanning them.

Edited July 5, 2019 by itman

[itman 1,718]

14 minutes ago, 0xDEADBEEF said:

For example, what if there are 3rd party interpreters that is not going through AMSI?

Yes. Python scripts are not scanned by AMSI. Nor AutoIt; WMI scripts that use their own script engine; etc..

Given malware developers roaring success in abusing legit Win binaries in "living of the land" attacks, "the sky is the limit" when it comes to malware these days.

[itman 1,718]

This one has me baffled.

Eset still doesn't detect the ps.txt malicous script in the .zip file when scanned locally via context scan. However when the .zip file was submitted to Virus Total, the malicious script was detected by NOD32.

I am also running EIS.

Could there be an issue with the default SmartScan ThreatSense parameters which I believe context scanning uses?

-EDIT- It's Smart Optimization. Disable that in Context-Scan profile and Eset now detects it.

Here's the story. After Eset detected the renamed .ps1 script via AMSI, appears it created a local detection for it. Afterwards, when I scanned the folder containing the .ps1 script, Eset detected it.

So as far as I am concerned, my assumption about once scanned never scanned again non-.ps1 files is correct.

BTW - with all this "fooling around" with this malicious .txt PowerShell script, only 13/56 detect it at VT; of the major AV players - G-Data, Avira, Qihoo-360, Rising, Kapersky, Ikarus, and Dr. Web. This further reinforces the difficulty of finding hidden malicious code in a .txt file.

Edited July 5, 2019 by itman