LiveGuard Not Blocking Script Downloads

[itman 1,755]

BTW - below are YARA rules to detect DCRAT and AsyncRAT:

https://malpedia.caad.fkie.fraunhofer.de/details/win.dcrat

https://malpedia.caad.fkie.fraunhofer.de/details/win.asyncrat

[itman 1,755]

For those wishing to "delve into" YARA, this is a good starting point: https://github.com/Yara-Rules/rules .

Edited May 17, 2022 by itman

[peteyt 396]

20 hours ago, New_Style_xd said:

I didn't find the print showing the last database update date, that's why I said that the machine could be infected using the EIS.

I think what the person earlier was saying is that live guard is missing features that are available in eset  advanced threat defence, now known as ESET LiveGuard Advanced.

With ESET LiveGuard Advanced, which is available for business users, you can select the confident level, the idea being you can get alerted for things that appear suspicious but could be false positives. This isn't an option for home users and I belive the business users have other extra options to. It's not an option for home users to avoid false positives as a home user wouldn't be able to tell the difference.

That's not to say liveguard can't protect you. I belive any protection is better than none.

[itman 1,755]

@Marcosdoes LiveGuard scan .js files?

Found a malicious .js file and it wasn't submitted to LiveGuard at all: https://www.joesandbox.com/analysis/628800/0/html

Attached is the file. Password is infected.

c8238e4ba5d2aafcb132239f682f11ba67387adc8abc80ac0614d3dbe3634e6d.zip

Edited May 17, 2022 by itman

[Marcos 5,290]

7 hours ago, itman said:

@Marcosdoes LiveGuard scan .js files?

It does. I've just tested it with the above js file:

[itman 1,755]

6 hours ago, Marcos said:

It does. I've just tested it with the above js file:

When I unzipped the file on my EESP installation, no LiveGuard submission occurred. Did you attempt to execute the .js file and this is when LiveGuard submission occur?

Also when I just now repeated the archive extract, I am now receiving an Eset sig, detection; appears this was just recently added:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
5/18/2022 8:52:42 AM;Real-time file system protection;file;C:\Users\xxxxxx\Downloads\c8238e4ba5d2aafcb132239f682f11ba67387adc8abc80ac0614d3dbe3634e6d\c8238e4ba5d2aafcb132239f682f11ba67387adc8abc80ac0614d3dbe3634e6d.js;JS/TrojanDropper.Agent.OQD trojan;cleaned by deleting;xxxxxxxx;Event occurred on a new file created by the application: C:\Program Files\7-Zip\7zG.exe (DF22612647E9404A515D48EBAD490349685250DE).;C68E16991A3453FC8A33ABE802421830EFAA1FEC;5/18/2022 8:52:39 AM

Edited May 18, 2022 by itman

[AnthonyQ 51]

Another case where LiveGuard said the sample was safe, but when I ran it on a VM, ESET blocked the C2.

This Powershell-based Remcos sample was automatically submitted to LiveGuard after being downloaded. However, LiveGuard said it's safe to use. But, with the current blacklist database, ESET can actually block the C2, so I'm not sure why LiveGuard missed this sample.😂

[itman 1,755]

5 hours ago, AnthonyQ said:

Another case where LiveGuard said the sample was safe, but when I ran it on a VM, ESET blocked the C2.

This Powershell-based Remcos sample was automatically submitted to LiveGuard after being downloaded. However, LiveGuard said it's safe to use. But, with the current blacklist database, ESET can actually block the C2, so I'm not sure why LiveGuard missed this sample.😂

Eset now blocking it via signature:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
5/19/2022 9:09:18 AM;Real-time file system protection;file;C:\Users\xxxxxx\Downloads\c1b594b4e47d437a5f73891c1a7112452dfbd9243ac3e77fdb72871af430b19e.ps1;PowerShell/TrojanDownloader.Agent.FKH trojan;cleaned by deleting;xxxxxxxx;Event occurred on a new file created by the application: C:\Program Files\7-Zip\7zG.exe (DF22612647E9404A515D48EBAD490349685250DE).;42B18E70F988F90074BCEF5EACF8A65915181DAA;5/19/2022 9:09:07 AM

Did you submit it manually after the safe LiveGuard detection?

As far as the Eset local blocked connection to C2, this malware another example of sandbox evasion; at least LiveGuard's sandbox processing.

 

Edited May 19, 2022 by itman

[AnthonyQ 51]

1 hour ago, itman said:

Eset now blocking it via signature:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
5/19/2022 9:09:18 AM;Real-time file system protection;file;C:\Users\xxxxxx\Downloads\c1b594b4e47d437a5f73891c1a7112452dfbd9243ac3e77fdb72871af430b19e.ps1;PowerShell/TrojanDownloader.Agent.FKH trojan;cleaned by deleting;xxxxxxxx;Event occurred on a new file created by the application: C:\Program Files\7-Zip\7zG.exe (DF22612647E9404A515D48EBAD490349685250DE).;42B18E70F988F90074BCEF5EACF8A65915181DAA;5/19/2022 9:09:07 AM

Did you submit it manually after the safe LiveGuard detection?

As far as the Eset local blocked connection to C2, this malware another example of sandbox evasion; at least LiveGuard's sandbox processing.

Yes, I noticed that. Actually ESET added signature detection hours ago. 

No, I haven't submitted via email. Maybe a malware analyst noticed this post or found this sample in the wild and added the detection. 

Looking at the logs, I find that this sample was submitted to LiveGuard at 16:16 (GMT +8) and safe verdict was sent back at 16:21. So basically it took 5 mins to analyze. I think suspicious behaviors should be shown in the sandbox environment. Still don't know why LiveGuard gave it a safe verdict.  

Edited May 19, 2022 by AnthonyQ

[itman 1,755]

23 minutes ago, AnthonyQ said:

Still don't know why LiveGuard gave it a safe verdict.  

Most of the LiveGuard misses I am seeing is when the script payload is being downloaded from attacker's C&C server. Assumed is these attacker's aren't stupid and are refusing to download the payload when they detect a sandbox server connection. Without the payload, LiveGuard won't observe any actual malicious activity occurring.

However from a YARA behavior detection aspect, there certainly is enough suspicious activity with this script to flag it. However, ESSP default LiveGuard malware confidence factor of 90% is at a level that it is only going to trigger on observed known malicious activity.

[AnthonyQ 51]

1 hour ago, itman said:

Most of the LiveGuard misses I am seeing is when the script payload is being downloaded from attacker's C&C server. Assumed is these attacker's aren't stupid and are refusing to download the payload when they detect a sandbox server connection. Without the payload, LiveGuard won't observe any actual malicious activity occurring.

However from a YARA behavior detection aspect, there certainly is enough suspicious activity with this script to flag it. However, ESSP default LiveGuard malware confidence factor of 90% is at a level that it is only going to trigger on observed known malicious activity.

Yep. In the future version of ESSP, users should be able to modify the detection threshold and choose which action to take based on maliciousness (Highly suspicious - Malicious: Quarantine; Suspicious: Ask users).

I also hope there will be a dedicated window showing the details of LiveGuard, such as which file is currently being uploaded to the sandbox and the final verdict/status of each submission (I understand that detailed reports are not available in ESSP 🙂).

[itman 1,755]

1 hour ago, AnthonyQ said:

also hope there will be a dedicated window showing the details of LiveGuard, such as which file is currently being uploaded to the sandbox and the final verdict/status of each submission (I understand that detailed reports are not available in ESSP 🙂).

"Don't hold your breath" on the behavioral report. It is only available for LiveGuard Advanced users under the following criteria:

Quote

Behavioral report

Seat limit

The full behavioral report is available only for files submitted by users with 100 or more seat licenses. The seat count is the sum of all seats from ESET LiveGuard Advanced licenses in EBA.

https://help.eset.com/elga/en-US/overview.html?behavioral_report.html

Other LiveGuard Advanced users just receive a cloud scanning status verdict as shown below:

https://help.eset.com/elga/en-US/results_analysis.html

Edited May 19, 2022 by itman

[New_Style_xd 69]

It would be perfect if ESS had a detailed report of what happened to the suspicious file.

[itman 1,755]

Another point about this recent .ps1 script miss by LiveGuard.

It confirms behavior; rather lack of it, I observed in another script download I tested. Refer to the above screen shot where I highlighted the url used for the payload download. Eset had previously blacklisted it. Ditto for my other script I tested.

As such, it really is immaterial if the payload downloaded or not in cloud sandbox analysis. The fact that an outbound network connection was being attempted to a blacklisted URL is enough justification to label the script malicious. It really appears that there are seriously issues with the script processing LIveGuard cloud scanning is performing.

[New_Style_xd 69]

1 hour ago, itman said:

Another point about this recent .ps1 script miss by LiveGuard.

It confirms behavior; rather lack of it, I observed in another script download I tested. Refer to the above screen shot where I highlighted the url used for the payload download. Eset had previously blacklisted it. Ditto for my other script I tested.

As such, it really is immaterial if the payload downloaded or not in cloud sandbox analysis. The fact that an outbound network connection was being attempted to a blacklisted URL is enough justification to label the script malicious. It really appears that there are seriously issues with the script processing LIveGuard cloud scanning is performing.

From what you're posting, I understand that the liveguard is having serious problems. and that eset has to improve to protect.

[AnthonyQ 51]

7 hours ago, itman said:

"Don't hold your breath" on the behavioral report. It is only available for LiveGuard Advanced users under the following criteria:

https://help.eset.com/elga/en-US/overview.html?behavioral_report.html

Other LiveGuard Advanced users just receive a cloud scanning status verdict as shown below:

https://help.eset.com/elga/en-US/results_analysis.html

That is a pity. Viewing results/verdict, I think, is essential and should not be an exclusive feature for LiveGuard Advanced. 

2 hours ago, itman said:

Another point about this recent .ps1 script miss by LiveGuard.

It confirms behavior; rather lack of it, I observed in another script download I tested. Refer to the above screen shot where I highlighted the url used for the payload download. Eset had previously blacklisted it. Ditto for my other script I tested.

As such, it really is immaterial if the payload downloaded or not in cloud sandbox analysis. The fact that an outbound network connection was being attempted to a blacklisted URL is enough justification to label the script malicious. It really appears that there are seriously issues with the script processing LIveGuard cloud scanning is performing.

Yes. Someone from LiveGuard development team needs to investigate this issue. And in my opinion, if a sample exhibits sandbox-evasion-like behaviors, LiveGuard should not declare this sample is clean and safe.

[peteyt 396]

10 hours ago, AnthonyQ said:

That is a pity. Viewing results/verdict, I think, is essential and should not be an exclusive feature for LiveGuard Advanced. 

Yes. Someone from LiveGuard development team needs to investigate this issue. And in my opinion, if a sample exhibits sandbox-evasion-like behaviors, LiveGuard should not declare this sample is clean and safe.

I'd like to see some improvements. If liveguard is no good detecting sandbox evasion surely many will just abuse this. @Marcosis there anything eset could implement to detect things like this?

[Marcos 5,290]

The PowerShell script mentioned above didn't access any malicious / blocked url during replication and didn't perform any malicious action in the sandbox either. Of course, we are constantly monitoring if there is malware that actively attempts to evade sandbox detection and try to improve the sandbox environment accordingly. We appreciate if you notify us about undetected malware that was evaluated as clean by LiveGuard as we can then focus on it and try to find out what happened and possibly improve the sandbox analysis.

[AnthonyQ 51]

21 minutes ago, Marcos said:

The PowerShell script mentioned above didn't access any malicious / blocked url during replication and didn't perform any malicious action in the sandbox either. Of course, we are constantly monitoring if there is malware that actively attempts to evade sandbox detection and try to improve the sandbox environment accordingly. We appreciate if you notify us about undetected malware that was evaluated as clean by LiveGuard as we can then focus on it and try to find out what happened and possibly improve the sandbox analysis.

But I think it tried to access hxxp://gotovacoil[.com/cname/Encrypted%20Client%20OG.jpg, which has been blacklisted by ESET and many vendors. Also, ESET has recently added a detection for it. 🤔

[Marcos 5,290]

2 minutes ago, AnthonyQ said:

But I think it tried to access hxxp://gotovacoil[.com/cname/Encrypted%20Client%20OG.jpg, which has been blacklisted by ESET and many vendors. Also, ESET has recently added a detection for it. 🤔

It didn't. The url is in the script but was not accessed when the script was run in the sandbox.

[AnthonyQ 51]

36 minutes ago, Marcos said:

It didn't. The url is in the script but was not accessed when the script was run in the sandbox.

Just ran this script on my VM. ESET block the access immediately:

2022/5/20 21:34:37;hxxp://gotovacoil[.com/cname/Encrypted Client OG.jpg;Blocked;Internal Blacklist;C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe;;;EEE0B7E9FDB295EA97C5F2E7C7BA3AC7F4085204

Maybe this script sample is sandbox-aware? 🤔

Edited May 20, 2022 by AnthonyQ

[itman 1,755]

1 hour ago, Marcos said:

The url is in the script but was not accessed when the script was run in the sandbox.

That may be the case. However as the OP noted when he ran the script in a VM, the network connection was blocked.

At this point, it can be concluded the script has anti-sandbox evasion capabilities. However as far as I am concerned, that is not the major issue. Is not any unknown script that performs outbound network communication by definition suspicious? Should sandbox processing not force this network connection? Or is the issue as I suspect is that script obfuscation/packing/encryption defeated LiveGuard cloud sandbox recognition the network connection actually existed?

Edited May 20, 2022 by itman

[itman 1,755]

I've seen enough in my limited testing of actual script malware that one is well advised on relying on "tried and true" anti-exec methods when it comes to scripts. An excellent start in this regard is Eset's recommended anti-ransomware HIPS and firewall rules. The HIPS rules need to be supplemented. I have been running with these rules for sometime and have yet had a rule trigger. This fact alone is indicative that false positive detection would be a rare event,

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.

Refs.:

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

https://support.eset.com/en/kb6132-configure-firewall-rules-for-eset-endpoint-security-to-protect-against-ransomware

Edited May 20, 2022 by itman

[itman 1,755]

Another strong recommendation is to set PowerShell Language mode to "Constrained" mode. This will block most PowerShell .Net based malware. You "can use your fingers" via Google search on how to do this.

[New_Style_xd 69]

Taking advantage of this topic, I wanted to know if anyone is experiencing slowness in downloading torrent with ESSP will be that LiveGuard is blocking the full speed of my broadband, I've tried to download several it's always slow!
Can anyone let me know? Below is the speed print.