Jump to content

LiveGuard Not Blocking Script Downloads


Recommended Posts

Posted (edited)

Ran two tests this morning. Both tests were submitted to LiveGuard for analysis, In neither test, the .bat script download containing PowerShell code was blocked, The file could be accessed; i.e. Win Explorer Edit option and the script could be executed w/o issue.

My suspicion here is this Internet module 1440.2 to fix the GPU performance counters issue busted something in LiveGuard processing.

Edited by itman
Link to comment
Share on other sites

Two days ago, I was installing a PyAutoGui library, to develop my projects in Python, it was sent to LiveGuard, I was waiting 5 minutes but it didn't show a return if I could install it or no warning came. went to see the eset report and it's still there with no return.
I wanted to know the answer but never got it.

image.png.5203fe7d40c65b0bebf3aabc3e28176c.png

Link to comment
Share on other sites

There is no issue with .exe downloads. Those are being blocked upon download after LiveGuard submission occurs. The issue is with script downloads not being blocked.

1 hour ago, New_Style_xd said:

it was sent to LiveGuard, I was waiting 5 minutes but it didn't show a return if I could install it or no warning came. went to see the eset report and it's still there with no return.
I wanted to know the answer but never got it.

To date, LiveGuard behavior in regards to receiving a safe verdict response for a prior submission is the following.

You will only receive this response if you physically try to access a LiveGuard submitted file that is currently blocked. Otherwise when the LiveGuard analysis is completed and a safe verdict rendered, the file will be silently unlocked and no user notification in any form will be provided to the user as to the safe verdict status.

Link to comment
Share on other sites

5 minutes ago, itman said:

There is no issue with .exe downloads. Those are being blocked upon download after LiveGuard submission occurs. The issue is with script downloads not being blocked.

To date, LiveGuard behavior in regards to receiving a safe verdict response for a prior submission is the following.

You will only receive this response if you physically try to access a LiveGuard submitted file that is currently blocked. Otherwise when the LiveGuard analysis is completed and a safe verdict rendered, the file will be silently unlocked and no user notification in any form will be provided to the user as to the safe verdict status.

That's why I didn't have an answer about the result, when I went to install PyAutoGui again, the installation was successful.
It would be great if I had a return informing, I spent some time in front of the pc waiting for the answer.
Thanks for the doubts you cleared.

Link to comment
Share on other sites

I finally figured out what is going on in regards to LiveGuard processing of script downloads. Title this posting, "LiveGuard bypass no. 1."

I download a script that is immediately submitted to LiveGuard. When I try next to immediately execute that script, I get the SmartScreen alert about "Untrusted Publisher." Overriding that alert when the script attempts to execute, I get the Win access violation alert and the script fails to execute. Also at time, Win Explorer Context Menu shows the script is blocked and  the LiveGuard desktop alert appears indicating script is still under analysis by LiveGuard.

I again download a script that is immediately submitted to LiveGuard. This time I attempt to open the script via Win Explorer file Edit option. Again, I get the SmartScreen alert about "Untrusted Publisher." I override that alert and the script opens w/o issue. No access violation alert is generated. I then close the script. Finally, I run the script w/o issue.

Let's analyze.

It appears LiveGuard is modifying the script download access permissions to prevent execution only. All another process has to do is access the download in non-execute mode and the close it. This will remove LiveGuard previously set execute file block and the attacker can now run the script unimpeded.

Link to comment
Share on other sites

Maybe, the bat file downloaded is considered to be 100% clean by ESET local scanning engine, so the sample will not be uploaded to LiveGurad  (https://support.eset.com/en/kb6569-eset-liveguard-advanced-faq).

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

I also have an issue with LiveGuard. I tested this sample (https://www.virustotal.com/gui/file/945a03df112866cd0d1da3b476f674aa81c556df2ceab354eb4ff545888e27f2). ESET scanner and LiveGuard fail to detect it. However, when I execute this sample on VM, ESET's ESET Deep Behavioral Inspection immediately blocked this sample (detected as BH/PSWFareit.1). Also, ESET's web protection can block the C2. So, it is wield that LiveGuard said this sample was safe to open.......

Link to comment
Share on other sites

27 minutes ago, AnthonyQ said:

I also have an issue with LiveGuard. I tested this sample (https://www.virustotal.com/gui/file/945a03df112866cd0d1da3b476f674aa81c556df2ceab354eb4ff545888e27f2). ESET scanner and LiveGuard fail to detect it. However, when I execute this sample on VM, ESET's ESET Deep Behavioral Inspection immediately blocked this sample (detected as BH/PSWFareit.1). Also, ESET's web protection can block the C2. So, it is wield that LiveGuard said this sample was safe to open.......

It's Lokibot malware:

Eset_Lokibot.thumb.png.d4349208babd1f830055f09f78a713b6.png

Lokibot anti-evasion tactics are quite successful on Win 10 based sandboxes: https://mdpi-res.com/d_attachment/jcp/jcp-01-00003/article_deploy/jcp-01-00003.pdf?version=1605851667 .

Link to comment
Share on other sites

33 minutes ago, AnthonyQ said:

Maybe, the bat file downloaded is considered to be 100% clean by ESET local scanning engine, so the sample will not be uploaded to LiveGurad 

The issue I highlighted has nothing to do with LiveGuard uploading capability. All scripts were uploaded to LiveGuard.

Link to comment
Share on other sites

This also needs to be noted about LiveGuard processing in ESSP.

It is using a malware confidence factor of 90%. Whereas, this level is great for eliminating false positive detection's, a lot of new stealthy malware is not going to be detected by it.

LiveGuard in ESSP needs to have the same configuration options that exist in LiveGuard Advanced; aka EDTD. That is the ability to set malware confidence factor and the ability to return suspicious detection's. These could be provided in an "Advanced" section of existing LiveGuard settings similar to that which exists for the HIPS. This would make it harder for non-technical Eset users from modifying them.

Link to comment
Share on other sites

Posted (edited)
5 hours ago, AnthonyQ said:

However, when I execute this sample on VM, ESET's ESET Deep Behavioral Inspection immediately blocked this sample (detected as BH/PSWFareit.1). Also, ESET's web protection can block the C2. So, it is wield that LiveGuard said this sample was safe to open.......

Excluding the sandbox evasion possibility posted about previously, I had a similar episode when testing a PowerShell script. It too came back with a safe verdict. The interesting part is as follows.

This script actually dialed-out to download a Github script. The interesting part is when I independently attempted to download the Github script via browser download, Eset detected by in memory signature:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
5/10/2022 10:42:52 AM;HTTP filter;file;https://codeload.github.com/gist/f646cb07f2708b2b3eabea21e05a2639/zip/4137019e70ab93c1f993ce16ecc7d7d07aa2463f;MSIL/Rozena.I trojan;connection terminated;xxxxxx;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (021FF4E98DFC0305D80136D97F5DB3B0A8B6F3D9).;6DC4E1A593E2716F9364205876910059CA7471EF;

This result implies two possibilities:

1. Eset LiveGuard is submitting files to the cloud but not actually running them in the cloud.

2. Eset LiveGuard cloud scanning is entirely behavior based and Eset is not employing its existing protection mechanisms in the cloud sandbox to detect malware status.

-EDIT- This detection, MSIL/Rozena.I, indicates the download was Meterpreter. It may very well be that the Github server will refuse to download to a sandboxed sourced connection. In this case, label it as another example of anti-sandbox evasion.

Edited by itman
Link to comment
Share on other sites

43 minutes ago, itman said:

Excluding the sandbox evasion possibility posted about previously, I had a similar episode when testing a PowerShell script. It too came back with a safe verdict. The interesting part is as follows.

This script actually dialed-out to download a Github script. The interesting part is when I independently attempted to download the Github script via browser download, Eset detected by in memory signature:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
10/05/2022 10:42:52; HTTP de filtro; arquivo; https://codeload.github.com/gist/f646cb07f2708b2b3eabea21e05a2639/zip/4137019e70ab93.; 6DC4E1A593E2716F9364205876910059CA7471EF;

This result implies two possibilities:

1. Eset LiveGuard is submitting files to the cloud but not actually running them in the cloud.

2. Eset LiveGuard cloud scanning is entirely behavior based and Eset is not employing its existing protection mechanisms in the cloud sandbox to detect malware status.

So are we paying more for a protection that is not actually protecting with full power?

Link to comment
Share on other sites

Posted (edited)
7 hours ago, itman said:

It's Lokibot malware:

Eset_Lokibot.thumb.png.d4349208babd1f830055f09f78a713b6.png

Lokibot anti-evasion tactics are quite successful on Win 10 based sandboxes: https://mdpi-res.com/d_attachment/jcp/jcp-01-00003/article_deploy/jcp-01-00003.pdf?version=1605851667 .

But the sandbox Zenbox on VT flags this file as: MALWARE STEALER TROJAN EVADER and accurately detects this malware. So perhaps ESET needs to improve LiveGuard. It's nice to see ESET has added a detection for it.

Another example:

I downloaded this Netwire sample (https://www.virustotal.com/gui/file/e82eb173325ee7fa787d4a3553ac250f0784a36bba695278889091ce84a2f38a). ESET's real-time scanner did not detect and remove this threat, LiveGuard was triggered, and sample was uploaded to the cloud sandbox. Then, I performed an on-demand scan and found that ESET is able to detect the component (> 7ZIP > cgB1AG4AMQAuAGUAeABlAA) inside it as A Variant Of Win32/Kryptik.FRHZ, and I chose retain. Several mins later, LiveGuard said it was safe to use this file......

I am shocked, as even the local-based ESET scanner is able to detect the harmful object inside this sample.

Below is the screenshot of logs (in Chinese):

1941799768_2022-05-16091850.png.c20bfd694385b6c4337a8502ee0ee3de.png

Edited by AnthonyQ
Link to comment
Share on other sites

5 hours ago, New_Style_xd said:

So are we paying more for a protection that is not actually protecting with full power?

LiveGuard is still useful.

Examples:

1. I tested this GuLoader, with very low VT detection rate (4/67). ESET scanner missed but LiveGuard detected it. 

2. I tested this new variant of Magniber ransomware that is popular recently. ESET scanner missed but LiveGuard detected it. Without LiveGuard, users' files are very likely to be encrypted. Although LiveGuard did a good job at detecting this ransomware, I still hope ESET can create a generic detection for Magniber ransomware (like Kaspersky does), because there are many variants of it in the wild.

Link to comment
Share on other sites

  • Administrators
1 hour ago, AnthonyQ said:

2. I tested this new variant of Magniber ransomware that is popular recently. ESET scanner missed

When did you test it? According to VT it was detected yesterday at 13:54 UTC already.

image.png

Also I've tried to run the msi on a machine disconnected from the Internet and with a 2-week old engine and the threat was detected and blocked upon execution:

image.png

Link to comment
Share on other sites

2 minutes ago, Marcos said:

When did you test it? According to VT it was detected yesterday at 13:54 UTC already.

image.png

Also I've tried to run the msi on a machine disconnected from the Internet and with a 2-week old engine and the threat was detected and blocked upon execution:

image.png

I tested it yesterday (15:08 GMT+8). The scanner failed to detect it.

It is nice to see ESET is able to block it upon execution.

Link to comment
Share on other sites

Posted (edited)
9 hours ago, Marcos said:

Also I've tried to run the msi on a machine disconnected from the Internet and with a 2-week old engine and the threat was detected and blocked upon execution

The point to note here is Eset detected the ransomware within something the installer was attempting to run. Which really is how ransomware protection should work since the ransomware could be packaged many ways.

On the other hand, Eset ransomware detection is still very much signature based.

Edited by itman
Link to comment
Share on other sites

Posted (edited)

I will also point out that as I view it, Eset LiveGuard processing has a "fatal flaw" in regards to cloud scanning of scripts.

First and most noteworthy in ESSP is scripts are immediately submitted upon download to the cloud. If any local heuristic scanning is being performed on the script, it's minimal at best.

Let's use these recent rash of Powershell coin miner attacks on Eset installations as example. This is a two stage attack. Stage one is the attacker drops a BASE64 encrypted file on the targeted device. Stage two is the attacker then drops a PowerShell script on the device. This script deploys a LOL Win trusted process that loads the BASE64 encrypted file into memory, decrypts it, and then executes the coin miner code.

The problem here is this PowerShell attack can only be fully detected at script execution time on the local device. That is scripts should not be submitted to the Eset cloud via LiveGuard until they are actually executed. Eset's AMSI interface needs to allow the script to fully uncloak in memory, then submit full uncloaked script details to the Eset cloud via LiveGuard processing. This in turn implies that Eset LiveGuard suspend script execution until LiveGuard verdict is rendered.

An example of a security product that performs the above processing is FireEye's Endpoint solution. FireEye provides detailed documentation on their AMSI interface here: https://fireeye.market/assets/apps/9WKuUMlB//2c356777/Endpoint Security - AMSI_v1.1.0_UserGuide .pdf . Points to note in this product is the ability to create custom script processing YARA rules and that the submission to the FireEye cloud is done through their AMSI interface.

Edited by itman
Link to comment
Share on other sites

15 hours ago, AnthonyQ said:

LiveGuard is still useful.

Examples:

1. I tested this GuLoader, with very low VT detection rate (4/67). ESET scanner missed but LiveGuard detected it. 

2. I tested this new variant of Magniber ransomware that is popular recently. ESET scanner missed but LiveGuard detected it. Without LiveGuard, users' files are very likely to be encrypted. Although LiveGuard did a good job at detecting this ransomware, I still hope ESET can create a generic detection for Magniber ransomware (like Kaspersky does), because there are many variants of it in the wild.

I understand that if I was using EIS I would be infected because the EIS does not have LiveGuard protection.
I understand that without LiveGuard in EIS products this ransomware would infect the machine.

Link to comment
Share on other sites

33 minutes ago, New_Style_xd said:

I understand that without LiveGuard in EIS products this ransomware would infect the machine.

That is not correct.

I guess you didn't understand @Marcosposting on this. He disconnected his Internet connection. He then ran the .msi file using a two week old virus signature database and Eset detected the ransomware.

Link to comment
Share on other sites

Posted (edited)

Here's a .vbs script that Eset LiveGuard gave a safe rating for after a 8 min. analysis.

On VT, only McAfee detects it: https://www.virustotal.com/gui/file/35d11d86e996833469ee713fce6ba52dbcdcf3211e36985182f47040c2166ac9/detection .

Joe's Cloud Sandbox analysis yielded a 100/100 malicious verdict for it: https://www.joesandbox.com/analysis/995223 . Highlighted are Win trusted LOL binaries used:

Eset_Script.thumb.png.dc6852282959004c105740af651d05b8.png

Appears Eset cloud doesn't even use its own recommended HIPS anti-ransomware rules which would have stopped PowerShell spawned child processes.

Edited by itman
Link to comment
Share on other sites

6 minutes ago, itman said:

That is not correct.

I guess you didn't understand @Marcosposting on this. He disconnected his Internet connection. He then ran the .msi file using a two week old virus signature database and Eset detected the ransomware.

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.

Link to comment
Share on other sites

  • Administrators
27 minutes ago, itman said:

Here's a .vbs script that Eset LiveGuard gave a safe rating for after a 8 min. analysis.

We'll add a detection, however, the vbs script doesn't do anything - the payload url https://textbin.net/raw/... is down, no payload is downloaded and also the connection to MySQL is failing. On a replicator it didn't do anything malicious.

Link to comment
Share on other sites

23 minutes ago, Marcos said:

We'll add a detection, however, the vbs script doesn't do anything - the payload url https://textbin.net/raw/... is down

Odd since Joe's Cloud Sandbox shows analysis date of today:

Eset_Joes.png.cb3bf25871d3bd3892c0e29123ef1e93.png

Possible attacker became aware of the sandbox analysis and took down the payload download site.

Link to comment
Share on other sites

  • Administrators

35d11d86e996833469ee713fce6ba52dbcdcf3211e36985182.vbs - PowerShell/TrojanDownloader.Agent.FJS trojan

 

Link to comment
Share on other sites

Posted (edited)
1 hour ago, itman said:

Possible attacker became aware of the sandbox analysis and took down the payload download site.

Believe I know what happened here and won't make the same mistake again.

The malware sample was an anonymous submission. Assumed this was the malware developer "doing a trial run" on detection. Whereas he did a great job on bypassing VT static analysis by the AV vendors, he forgot about the existing YARA sigs. for his RAT deployed in Joe's Cloud Sandbox.

Ref.: https://blogs.blackberry.com/en/2022/05/dirty-deeds-done-dirt-cheap-russian-rat-offers-backdoor-bargains

Edited by itman
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...