LiveGuard Not Blocking Script Downloads

[czesetfan 22]

14 hours ago, itman said:

The only modification I had to make to the recommended anti-ransomware HIPS rules is to allow PowerShell to start conhost.exe since without it, Win PowerShell maintenance tasks that run at system startup time were being blocked.

 

Can you specify what maintenance tasks you have in mind? What would be the impact on the system of this blocking?

[itman 1,542]

8 hours ago, czesetfan said:

Can you specify what maintenance tasks you have in mind? What would be the impact on the system of this blocking?

I don't understand your question.

My previous reference was to Win 10 Powershell tasks that run once a day as shown in the below screen shot:

Win 10 has a scheduled task that runs CompaTelRunner.exe that starts PowerShell.exe that creates the above log entries. PowerShell.exe in turn, runs conhost.exe.

The "ideal" HIPS rule in this case would be to allow:

CompatTelRunner.exe -> PowerShell.exe -> conhost.exe

Unfortunately, Eset HIPS doesn't have this capability.

Finally, note that I created a HIPS rule to monitor all script engine's startup which is how I detected this activity in the first place.

[czesetfan 22]

My question is. What will be the impact of not allowing PowerShell.exe -> conhost.exe on the system? That is, if the execution of PowerShell.exe child processes remains blocked, as in ESET's original policy. 

[czesetfan 22]

Are these maintenance tasks necessary or dispensable for the smooth operation of Win.

[itman 1,542]

3 hours ago, czesetfan said:

My question is. What will be the impact of not allowing PowerShell.exe -> conhost.exe on the system? That is, if the execution of PowerShell.exe child processes remains blocked, as in ESET's original policy. 

Overall, conhost.exe is not usually associated with malicious script execution: https://www.elastic.co/guide/en/security/current/conhost-spawned-by-suspicious-parent-process.html .

Well, leave it up to the PowerShell attackers to figure out a way to abuse it:

Quote

For me, the cool part here is the command line output that was successfully captured from the PowerShell registry Run key and payload executions. I was also interested in the \??\C:\WINDOWS\system32\conhost.exe 0xffffffff -ForceV1 execution and came across this stackexchange post that explained the execution to be affiliated with, “If there is no session attached to the physical console, (for example, if the physical console session is in the process of being attached or detached), this function returns 0xFFFFFFFF.”

https://www.trustedsec.com/blog/who-left-the-backdoor-open-using-startupinfo-for-the-win/

The key element on this one is the "-ForceV1" command line parameter.

So I guess for maximum security, conhost.exe startup from Powershell should not be allowed. If Eset HIPS had YARA rule capability, you could then only block conhost.exe startup using the "-ForceV1" command line parameter.

Now that I am monitoring all script engine startup, I believe my HIPS rule that allows CompatTelRunner.exe to start PowerShell.exe will also now allow conhost.exe to run unimpeded in this instance. This is due to an Eset HIPS "gotcha." When you allow a process to run via HIPS rule, any subsequent activity performed by that process instance is auto allowed.

Edited May 21, 2022 by itman

[itman 1,542]

3 hours ago, czesetfan said:

Are these maintenance tasks necessary or dispensable for the smooth operation of Win.

I've migrated over time to allowing Win 10 internal telemetry activities to run unimpeded lest some thing system-wise gets broken.

Edited May 21, 2022 by itman

[AnthonyQ 42]

Hi @Marcos,

I'd like to report another two malicious samples that bypassed LiveGuard for your teams' analysis.

The first one is a ransomware written in Flystudio. This sample, when downloaded, was not automatically blocked by LiveGuard. So I submitted it to LiveGuard manually. Since I cannot view the result, about five mins later, the file was not removed by LiveGuard and I assumed LiveGuard had marked it as Clean. I then submitted it via email and the detection "Win32/Filecoder.OLA" was added in a timely manner, which is great.  But why this obvious ransomware bypassed LiveGuard?

The second one is a AsyncRAT loader. This sample was automatically analyzed by LiveGuard and confirmed to be Clean. I then ran this sample, and interestingly, ESET HTTP filter immediately blocked the connection due to the detection of MSIL/Agent.CFQ trojan (see logs below, translated). 

2022/5/22 10:08:20; HTTP filter; File; hxxp://45[.41.240[.44/goonie/Runtime broker.exe;A Varient Of MSIL/ agent.cfq trojan;Connection terminated

Thanks.

[czesetfan 22]

9 hours ago, itman said:

Now that I am monitoring all script engine startup, I believe my HIPS rule that allows CompatTelRunner.exe to start PowerShell.exe will also now allow conhost.exe to run unimpeded in this instance. This is due to an Eset HIPS "gotcha." When you allow a process to run via HIPS rule, any subsequent activity performed by that process instance is auto allowed.

Edited 9 hours ago by itman

Could you post your HIPS rules configuration related to enabling conhost.exe? (monitoring all script engine startup, allows CompatTelRunner.exe to start PowerShell.exe)

[itman 1,542]

9 hours ago, czesetfan said:

Could you post your HIPS rules configuration related to enabling conhost.exe? (monitoring all script engine startup, allows CompatTelRunner.exe to start PowerShell.exe)

Unfortunately, allowing compatelrunner.exe to start powershell.exe does not in turn, allow powershell.exe to start conhost.exe. The only alternative to allow powershell.exe to start conhost.exe.

What is strange here is no Eset HIPS alert is generated in the above situation about conhost.exe startup being blocked. But the PowerShell event log entries I posted previously do not appear indicating that compatelrunner.exe did not run successfully.

[itman 1,542]

13 hours ago, AnthonyQ said:

The first one is a ransomware written in Flystudio. This sample, when downloaded, was not automatically blocked by LiveGuard.

Again, file submission to LiveGuard is dependent upon local heuristic scanning finding something suspicious about file. Like most ransomware, appears this sample was set to run at system startup time. 

Next time this happens, run sample in your VM or preferably, on stand-alone test device not connected to the local network. If files get encrypted, it proves Eset is worthless against 0-day ransomware.

Edited May 22, 2022 by itman

[itman 1,542]

16 hours ago, AnthonyQ said:

The first one is a ransomware written in Flystudio. This sample, when downloaded, was not automatically blocked by LiveGuard.

Let's analyze this ransomware a bit more in regards to recent conhost.exe discussion.

Per VT Dr. Web sandbox analysis:

Per prior linked article from Elastic on recommended conhost.exe parent process startup monitoring:

[itman 1,542]

20 hours ago, AnthonyQ said:

The second one is a AsyncRAT loader. This sample was automatically analyzed by LiveGuard and confirmed to be Clean. I then ran this sample, and interestingly, ESET HTTP filter immediately blocked the connection due to the detection of MSIL/Agent.CFQ trojan (see logs below, translated). 

Eset detects the payload download:

Again and obviously, the script is not being executed in Eset's cloud sandbox.

Edited May 22, 2022 by itman

[AnthonyQ 42]

10 hours ago, itman said:

Again, file submission to LiveGuard is dependent upon local heuristic scanning finding something suspicious about file. Like most ransomware, appears this sample was set to run at system startup time. 

Next time this happens, run sample in your VM or preferably, on stand-alone test device not connected to the local network. If files get encrypted, it proves Eset is worthless against 0-day ransomware.

The special thing about this ransomware is that it's written in Flystudio programming language (a Chinese programming language), which might be the reason why this sample was not uploaded to LiveGuard at the first place. Despite that, the ransomware-like behavior is quite obvious. So I want to know whether this sample has actually been executed in the LiveGuard sandbox... 🤔

Quote

Again and obviously, the script is not being executed in Eset's cloud sandbox.

I think so. Maybe another example of sandbox evasion, which ESET should address.

[Marcos 4,716]

3 hours ago, AnthonyQ said:

The special thing about this ransomware is that it's written in Flystudio programming language (a Chinese programming language), which might be the reason why this sample was not uploaded to LiveGuard at the first place.

Correct. The sample had been detected as @ApplicUnwnt.Win32/Packed.FlyStudio.AA for years. The problem is that FlyStudio is a very popular scripting language in China so flagging every FlyStudio file would generate a huge number of false positives there.

[SeriousHoax 76]

1 hour ago, Marcos said:

Correct. The sample had been detected as @ApplicUnwnt.Win32/Packed.FlyStudio.AA for years. The problem is that FlyStudio is a very popular scripting language in China so flagging every FlyStudio file would generate a huge number of false positives there.

I think the issue is not the programing language. The problem is that this ransomware was not initially picked neither by ESET locally nor by the LiveGuard cloud sandbox which is a matter of concern. More so for customers who are paying extra for ESSP.

Edited May 23, 2022 by SeriousHoax

[Marcos 4,716]

4 minutes ago, SeriousHoax said:

I think the issue is not the programing language. The problem is that this ransomware was not initially picked neither by ESET locally nor by the LiveGuard cloud sandbox which is a matter of concern. More so for customers who are paying extra for ESSP.

It indeed is. For many other users outside Chine this very sample would have been detected as @ApplicUnwnt.Win32/Packed.FlyStudio.AA even 5 years ago.

[SeriousHoax 76]

9 minutes ago, Marcos said:

It indeed is. For many other users outside Chine this very sample would have been detected as @ApplicUnwnt.Win32/Packed.FlyStudio.AA even 5 years ago.

Ok, so ESET didn't detect it only for users living in China? That's interesting.

[AnthonyQ 42]

1 hour ago, Marcos said:

Correct. The sample had been detected as @ApplicUnwnt.Win32/Packed.FlyStudio.AA for years. The problem is that FlyStudio is a very popular scripting language in China so flagging every FlyStudio file would generate a huge number of false positives there.

Exactly, "Win32/Packed.FlyStudio.AA" PUA detection is disabled for ESET products in Simplified Chinese versions.

However, it cannot be ignored that there are a lot of malware (especially MBR killers, system destroyers, etc.) written in Flystudio language and mainly targeting Chinese users. Therefore, I would like ESET LiveGuard to be triggered when these Flystudio samples are downloaded to Chinese ESET users' computers and perform behavioral analysis in the cloud to fill the security holes. 🙂

[itman 1,542]

6 hours ago, AnthonyQ said:

Exactly, "Win32/Packed.FlyStudio.AA" PUA detection is disabled for ESET products in Simplified Chinese versions.

However, it cannot be ignored that there are a lot of malware (especially MBR killers, system destroyers, etc.) written in Flystudio language and mainly targeting Chinese users. Therefore, I would like ESET LiveGuard to be triggered when these Flystudio samples are downloaded to Chinese ESET users' computers and perform behavioral analysis in the cloud to fill the security holes. 

The main issue here is being obscured.

All Eset's existing detection for non-Chinese base users of FlyStudio is doing is detecting that FlyStudio is being deployed in the executable and flagging this usage as a PUA. This existing Eset detection has absolutely nothing to do with ransomware or any other malicious behavior for that matter being detected when the executable ran. Therefore, FlyStudio running undetected in Eset Chinese versions has absolutely nothing to do with Eset's miss of this sample's ransomware behavior in the Eset cloud.

-EDIT- Likewise, the Win 10 AMSI based interface only processes PowerShell, wscript, and cscript engine based scripts along with JavaScript, VBScript, and Office VBA macros. Ref.: https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal . Finally, it should be noted that bypassing the AMSI interface is rather "trival" for attackers: https://news.sophos.com/en-us/2021/06/02/amsi-bypasses-remain-tricks-of-the-malware-trade/ .

This means obfuscated, packed, and encrypted Python based scripts that are the "darlings" of malware script creators can only be detected via full sandbox analysis. Ditto for AutoIt scripts deployed by the ATP threat actors.

Edited May 23, 2022 by itman

[itman 1,542]

One thing I will state is that it's getting harder to find 0-day samples that Eset hasn't already created a sig. for. Of note is Kaspersky doesn't detect this one:

https://www.virustotal.com/gui/file/bf6666ed547f439ec5396dd0b03aa39edb9626418d5bc3f2a0b7490191ae8898/detection

[AnthonyQ 42]

20 hours ago, itman said:

The main issue here is being obscured.

All Eset's existing detection for non-Chinese base users of FlyStudio is doing is detecting that FlyStudio is being deployed in the executable and flagging this usage as a PUA. This existing Eset detection has absolutely nothing to do with ransomware or any other malicious behavior for that matter being detected when the executable ran. Therefore, FlyStudio running undetected in Eset Chinese versions has absolutely nothing to do with Eset's miss of this sample's ransomware behavior in the Eset cloud.

-EDIT- Likewise, the Win 10 AMSI based interface only processes PowerShell, wscript, and cscript engine based scripts along with JavaScript, VBScript, and Office VBA macros. Ref.: https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal . Finally, it should be noted that bypassing the AMSI interface is rather "trival" for attackers: https://news.sophos.com/en-us/2021/06/02/amsi-bypasses-remain-tricks-of-the-malware-trade/ .

This means obfuscated, packed, and encrypted Python based scripts that are the "darlings" of malware script creators can only be detected via full sandbox analysis. Ditto for AutoIt scripts deployed by the ATP threat actors.

Currently, ESET (international version) flags all Flystudio-based software as PUA, and ESET (Chinese version) flags all unknown Flystudio-based software as safe, which might cause new Flystudio-based malware not to be blocked and analyzed by LiveGuard. That is the problem. 

--------------------------------

Another two backdoor (maybe CobaltStrike) samples were not detected by LiveGuard. I share the VT links for analysis by relevant teams. The samples have been submitted via email and detection is yet to be added.

https://www.virustotal.com/gui/file/dac35a874ca47b8de8103ac84b2db9dea4e6b44f9ed2081fcd5bff1143a66d97

https://www.virustotal.com/gui/file/2e5364644255681ae085c113b6d88e4d3bc1db18d3ef8c06b8264194a39687e9

[itman 1,542]

4 hours ago, AnthonyQ said:

https://www.virustotal.com/gui/file/dac35a874ca47b8de8103ac84b2db9dea4e6b44f9ed2081fcd5bff1143a66d97

CobaltStrike: https://www.joesandbox.com/analysis/1000506   Confidence factor is 76/100.

4 hours ago, AnthonyQ said:

https://www.virustotal.com/gui/file/2e5364644255681ae085c113b6d88e4d3bc1db18d3ef8c06b8264194a39687e9

CobaltStrike: https://www.joesandbox.com/analysis/1000504   Confidence factor is 76/100. 

Assuming ESSP cloud analysis detected anything which is highly doubtful, these samples would have  been deemed safe since ESSP LiveGuard will only return a malicious verdict if the confidence factor is >= 90/100.

Edited May 24, 2022 by itman

[AnthonyQ 42]

1 hour ago, itman said:

CobaltStrike: https://www.joesandbox.com/analysis/1000506   Confidence factor is 76/100.

CobaltStrike: https://www.joesandbox.com/analysis/1000504   Confidence factor is 76/100. 

Assuming ESSP cloud analysis detected anything which is highly doubtful, these samples would have  been deemed safe since ESSP LiveGuard will only return a malicious verdict if the confidence factor is >= 90/100.

It's possible.

---------------------------

Another vbs-based script trojan downloader bypassed LiveGuard: https://www.virustotal.com/gui/file/e083ccac5c920d2b3014872aa4a0a09d77f058ecf1db8325da7c865b111a254a.

However, after I acutally ran it, ESET's AMSI scanner immediately detected it 🙃: 
2022/5/24 21:56:57;AMSI scanner;e083ccac5c920d2b3014872aa4a0a09d77f058ecf1db8325da7c865b111a254a.vbs;VBS/TrojanDownloader.Agent.WYJ trojan

[itman 1,542]

38 minutes ago, AnthonyQ said:

Another vbs-based script trojan downloader bypassed LiveGuard: https://www.virustotal.com/gui/file/e083ccac5c920d2b3014872aa4a0a09d77f058ecf1db8325da7c865b111a254a.

Yes. LiveGuard gave it a safe verdict:

Time;Hash;File;Size;Category;Reason;Sent to;User
5/24/2022 10:35:14 AM;440FE9F3F6A1D8AB3FE4C0BA78D93BF1DDBCEFAA;C:\Users\xxxxxx\Downloads\e083ccac5c920d2b3014872aa4a0a09d77f058ecf1db8325da7c865b111a254a.vbs;3120;Script;Automatic;ESET LiveGuard;xxxxxxxx

Time;Component;Event;User
5/24/2022 10:37:04 AM;ESET Kernel;ESET LiveGuard has analyzed a file. It is safe to use.;SYSTEM

However, I though by now it's obvious that ESSP LiveGuard is not sandbox executing scripts, or anything else for that matter.

[AnthonyQ 42]

7 minutes ago, itman said:

Yes. LiveGuard gave it a safe verdict:

Time;Hash;File;Size;Category;Reason;Sent to;User
5/24/2022 10:35:14 AM;440FE9F3F6A1D8AB3FE4C0BA78D93BF1DDBCEFAA;C:\Users\xxxxxx\Downloads\e083ccac5c920d2b3014872aa4a0a09d77f058ecf1db8325da7c865b111a254a.vbs;3120;Script;Automatic;ESET LiveGuard;xxxxxxxx

Time;Component;Event;User
5/24/2022 10:37:04 AM;ESET Kernel;ESET LiveGuard has analyzed a file. It is safe to use.;SYSTEM

However, I though by now it's obvious that ESSP LiveGuard is not sandbox executing scripts, or anything else for that matter.

LiveGuard just removed this IcedID sample with a very low VT detection rate. Considering it took more than 5 mins to display a result, I believed this sample has be examined by behavior analyzer.

Maybe LiveGuard needs to improve its detection of script malware.