More LiveGuard Concerns

[itman 1,542]

I have two instances. Will cover this instance first.

A software developer wanted me to test his latest product release. I downloaded the .exe installer from his web site.

Using Win Context Menu on the downloaded .exe, it showed that Eset LiveGuard had blocked the file. A short while later, I received an Eset popup that file was submitted to Eset Virus Lab for analysis. Again, using Win Context Menu on the download .exe, it showed that Eset LiveGuard was still blocking the file.

The problem is that I could run the downloaded .exe while it was still showing that it was blocked. No Eset popup about overriding the Eset LiveGuard block, etc..

Edited March 29, 2022 by itman

[itman 1,542]

Here is the second instance. This one is more disturbing.

The same above developer previously wanted me to test just a .exe contained within the above noted app installer. The problem is he forgot to add the .exe extension to the file. When I downloaded the file from his web site, I received a file named "setup."

LiveGuard to its credit recognized the file was a .exe and did shortly submit to the Eset Virus Lab for analysis.

The problem is that upon completion of the download, the file was not blocked by LiveGuard via Context Menu verification. Nor was the file blocked after submission to Eset Virus Lab for analysis. I just renamed the file setup.exe and it ran w/o a peep from Eset LiveGuard.

Edited March 29, 2022 by itman

[Nightowl 187]

For me LiveGuard kicked normally and prevented me to run the software before I get an analysis result , but it didn't kick that much since I don't download that much , but it used to kick in when I downloaded CheatEngine's setup from Patreon link which is a setup file without the advertising bars prompt , which why LiveGuard didn't see it before.

But it used to make me wait for analysis report unless I bypass the block manually which is normal I understand.

But I didn't try to change the file name to see if it can bypass, but changing the file name won't give it a different HASH so still even with different name it should look the same to ESET isn't it?

Also kicked and prevented me from running when I downloaded PlayStation 3 emulator, RPCS3

Every different version I had downloaded , ESET had to send it to LiveGuard for more checking.

Edited March 30, 2022 by Nightowl

[itman 1,542]

1 hour ago, Nightowl said:

But I didn't try to change the file name to see if it can bypass, but changing the file name won't give it a different HASH so still even with different name it should look the same to ESET isn't it?

It appears that LiveGuard will only block startup of an executable and in that regard as posted, there are issues. In other words, it does not lock physical access to the file until verdict is rendered.

Hash status is immaterial here since the original download was never blocked. Since the file was originally submitted to LiveGuard when downloaded, it won't be resubmitted when renamed.

[Nightowl 187]

39 minutes ago, itman said:

It appears that LiveGuard will only block startup of an executable and in that regard as posted, there are issues. In other words, it does not lock physical access to the file until verdict is rendered.

Hash status is immaterial here since the original download was never blocked. Since the file was originally submitted to LiveGuard when downloaded, it won't be resubmitted when renamed.

I don't know honestly how LiveGuard analyzes files to determine if it's seen first time or not , but there should be something like a signature or a HASH , no? , I don't know I am just asking and I also don't have an answer for your case , but I just gave my 2 cents.

[Chelopher 0]

I used to be able to test the LiveGuard functionality former known as Dynamic Threat Defense using the file "EdtdTestFile.exe " available on https://help.eset.com/elga/en-US/test_functionality.html, I did several test two weeks ago cause I needed to setup an exclusion for a developers team. In all those test,  the file was sent, analized and then removed since it was cataloged as malicious.

Now I've been requested to create another exclusion and it turns out that  no matter its location, the EdtdTestFile is being ignored by Liveguard despite the fact that I'm chaging its hash using the Add-Content command as the instructions state. Did something change? 

Edited March 30, 2022 by Chelopher

[itman 1,542]

I have found out why LiveGuard didn't block access to the downloads from the developer provided URLs and it's pretty ugly. Let's get into the nitty gritty details.

Again and important, the browser used in all these activities is Firefox.

I performed another LiveGrid test yesterday by downloading a test malware from a Palo Alto web site:

Time;Hash;File;Size;Category;Reason;Sent to;User
3/31/2022 4:55:56 PM;8F8B9EF492042A968A0148FDEE7859C9A65DC458;C:\Users\xxxxx\AppData\Local\Temp\4ykilt5h.exe.part;55296;Executable;Automatic;ESET LiveGuard;xxxxxx

The file in my user Downloads folder was actually blocked and not accessible. Also, I did shortly later receive a confirmation from LiveGuard that the file was safe and LiveGuard then unblocked the file.  This parallels previous downloads in review of my Eset Sent files log. That is when Firefox downloaded the .part file to my User Temp folder, LiveGuard performed as expected.

Now about those downloads from the from the developer provided URL. Here's the Eset Sent log entries for those:

Time;Hash;File;Size;Category;Reason;Sent to;User
3/25/2022 4:49:29 PM;E59A11B7A7FA3D06D40BCB9225393462AF34CD41;https://downloads.novirusthanks.org/license-manager/update/v1/setup;28416576;Executable;Automatic;ESET LiveGuard;xxxxxx

Time;Hash;File;Size;Category;Reason;Sent to;User
3/28/2022 2:30:37 PM;499FB0A1734C95E33C220204B79A36A53BAB8B24;https://downloads.osarmor.com/nvtlicensemanager_setup_v1.5.2_test2.exe;28721072;Executable;Automatic;ESET LiveGuard;xxxxxxx

The important point to note is the downloads capture source by LiveGuard was a URL. Also upon access to this URL via Firefox, the file download processing initiated immediately.

Firefox made some important changes in ver. 98 in regards to file downloads as noted below:

Quote

The main new feature in Firefox 98 is the new download flow of the browser. The core difference between the old downloading behavior and the new is that Firefox won't prompt users anymore when downloads are started. Firefox will start the download immediately, similarly to how Chromium-based browsers handle it. You can check out our guide on restoring download prompts in Firefox.

Here are the main changes:

• The downloads panel is displayed automatically in Firefox 98 by default.
• Downloads may be opened while they still download. They are started immediately after the download completes them.
• File downloads are no longer put into the system's temp folder.
• The downloads menu displays the following options: always open similar files, show in folder, go to download page, copy download link, delete, remove from history and clear preview panel.

 

https://www.ghacks.net/2022/03/08/mozilla-firefox-98-0-here-is-what-is-new/

The change most significant is bold highlighted. 

When the download from the developer's URL initiated, it was directly created in my Downloads folder without any immediate User Temp file download as was the previous Firefox download behavior. It appears Eset's LiveGuard processing in regards to Firefox is dependent upon file creation in the User Temp for both Downloads folder file locking and safe verdict rendering activities.

I have now changed Firefox settings to its previous file download behavior to always ask where the download should be saved to as a temporary workaround. This reverts to always creating a .part download in the User Temp folder.

@Marcos Eset developers needs to address this issue immediately.

Edited April 1, 2022 by itman

[itman 1,542]

Per the link contained in the above ghacks.com article excerpt posted above, this new Firefox download behavior has been deployed by Chrome for some time. It also makes you more vulnerable to a malicious drive-by download attack:

Quote

Why you may want to enable download prompts

Downloads are checked by the integrated Safe Browsing component, but anything that passes the check, is downloaded automatically. Back in 2017, a new attack was discovered that used Chrome's automatic download behavior. The file in question was an old .scf file format, which Windows processed automatically when the folder is opened.

A drive by download attack, which downloads files automatically without user interaction, or getting users to click on the download link, was sufficient to plant the prepared file on the user system.

Our suggestion back then was to enable the "ask where to save each file before downloading" option in Chrome to prevent this attack from happening, as Chrome will prompt to pick a download location for the file before the file is saved to the local system.

This makes it imperative that Eset fixes the LiveGuard issue.

Edited April 1, 2022 by itman

[itman 1,542]

10 minutes ago, Marcos said:

Do you suggest that files downloaded via Firefox 98 are not sent to LiveGuard because Firefox doesn't create temporary files during the download?

No. This issue is not with the file being sent to LiveGuard. The issue is for direct URL downloads as described previously, the file in the Downloads folder is not being locked from access or execution.

As I originally posted, Eset Context Menu shows the file is locked. However, the file can still be executed.

Edited April 1, 2022 by itman

[itman 1,542]

@Marcos, the following Eset log entries detail chronologically, the events that occurred in regards to the developer .exe download via direct URL link that I could execute in a LiveGuard locked state.

First, the Sent log entries:

Time;Hash;File;Size;Category;Reason;Sent to;User
3/22/2022 2:02:36 PM;274AC75E6D7A68FD987527BB1CD44E33B30F80EF;C:\Users\xxxxx\AppData\Local\Temp\358VrPl_.exe.part;5824512;Executable;Automatic;ESET LiveGuard;xxxxxxx

Time;Hash;File;Size;Category;Reason;Sent to;User
3/22/2022 2:04:25 PM;4831B4D15840184B51AF91F34034007C07A6A256;https://downloads.osarmor.com/osa-personal-1-6-9-setup-pre2.exe;54517936;Executable;Automatic;ESET LiveGuard;xxxxxxx

The first log entry by LiveGuard appears to be only a partial upload of that downloaded to the User Temp directory of the entire .exe file.

The second log entry notes the upload of the entire .exe file to LiveGuard. Of note is the source of the upload is the developer's direct URL. This is the file, now present is my Downloads folder, that I was able to execute although LiveGuard via Win Content Menu display stated was locked from access.

Here are the related Event log entries:

Time;Component;Event;User
3/22/2022 2:02:35 PM;ESET Kernel;File '358VrPl_.exe.part' was sent to ESET Virus Lab for analysis.;SYSTEM

Time;Component;Event;User
3/22/2022 2:04:25 PM;ESET Kernel;File 'osa-personal-1-6-9-setup-pre2.exe' was sent to ESET Virus Lab for analysis.;SYSTEM

Of most interest is both files were submitted to Eset Virus Lab for analysis.

That's it as for LiveGuard activity for this download event. No feedback log entries from LiveGuard as to file status determination, etc..

There is clearly a problem with LiveGuard downloaded file processing.

[itman 1,542]

I also have a theory as to what the problem is in regards to LiveGrid processing as to Firefox downloads.

The above log entries reflect when I had not set Firefox global download setting to prompt as to which directory location to download to. Instead, I had set Firefox individual file download suffixes to ask mode. This will just result in Firefox prompting if I want to save the files. What the result appears to be of this is Firefox will initiate a partial download of the file as a .part file to the user Temp directory. When the response to the save file prompt is given, it proceeds to download the rest of the file appended to the existing .part file in the User Temp directory.

LiveGuard instead of waiting for the full download to complete is capturing the partial file download .part file and using that file as the source of further LiveGuard processing. Specifically, LiveGuard is locking a file that presently doesn't exist in the user's Download folder. That file will only be created after Firefox completes the full file download. LiveGuard needs to modified not to process Firefox .part file downloads. Instead, LiveGuard needs to wait till Firefox actually creates the full file download in whatever the target directory is. The big question is how does Firefox actual do this and is Eset capable of detecting this activity.

Edited April 1, 2022 by itman

[itman 1,542]

I forgot to mention an important detail in regards to these incomplete Firefox file download uploads to LiveGuard. The issue only manifests with large file downloads.

The large file download size here is dependent on how fast your Internet network connection is and how long it takes Firefox to show the save file prompt. On my 1 Gb Internet connection, it appears files less than 5 MB or so are completely downloaded to the .part file in my user Temp directory by the time the save file prompt from Firefox appears. In this instance, full LiveGuard processing of the file works correctly. This is because the full file download has occurred prior to the save prompt being responded to. No further additional downloading of remaining file data and appending to the prior .part file by Firefox is being performed.

BTW - this LiveGuard issue has existed for sometime. I also previously only noticed it in regards to large file downloads. It was only when I performed the above posted diagnostic activities that I was able to identify it was a LiveGuard bug.    

Edited April 2, 2022 by itman

[itman 1,542]

I performed another test today and I know what the issue is with LiveGuard and I don't like it one bit.

This time I went to the developer's web site and downloaded one of his publicly available apps. Due to my previous modification of Firefox download behavior which now results in a full file download being performed, only one submission to LiveGuard was made:

Time;Hash;File;Size;Category;Reason;Sent to;User
4/2/2022 12:11:46 PM;DC329F9AE0F78F20E475B5536D37C74DDE438C79;https://downloads.winupdatestop.com/latest/winupdatestop-standard/setup;46104056;Executable;Automatic;ESET LiveGuard;xxxxxx

Like the previous downloads mentioned in this thread when accessing this file in my Downloads folder, the behavior was the same. Eset, via Win Explorer Context Menu display, showed the file blocked by LiveGuard. However as with the previous downloads, I could execute the downloaded file.

This downloaded file, as with all the other downloads described in this thread, were code signed. Not Microsoft signed, but signed with a third party CA issued code signed cert..

The bottom line here is LiveGuard is not blocking execution of code signed .exe's. Rather its processing in this instance is identical to existing LiveGrid processing. All a malware developer has to do is code sign his 0-day malware .exe and you're nailed.

LiveGuard needs to add an option setting to process all not previously seen code signed .exe's excluding Microsoft code signed ones.

Edited April 3, 2022 by itman

[itman 1,542]

One last comment here.

Just how prevalent is code signed malware?

Quote

Trend Micro research found that there is an entire malware market supporting the development and distribution of code-signed malware. Malware operators gain access to valid certificates which they use to sign malicious code. The following table shows the volume of malware using code signing to evade antivirus, as of April 2018.

The Trend Micro research found that around 66 percent of the malware sampled was code-signed. Furthermore, certain malware types come with more code signing instances, such as Trojans, droppers, and ransomware.

https://www.makeuseof.com/tag/what-is-code-signed-malware/

It appears that Eset LiveGrid developers are oblivious to this fact.

Edited April 3, 2022 by itman

[Marcos 4,714]

Signed files are subject to analysis by LiveGuard. I've made a test by downloading a digitally signed 4 MB installer with Firefox 98 with default settings. The file was submitted and blocked when I tried to execute it:

The best would be if you could reproduce it with any file since a particular file would not be sent again. We could perhaps provide you with a logging version of a module to find out what's happening on your machine with downloaded files.

[itman 1,542]

39 minutes ago, Marcos said:

The best would be if you could reproduce it with any file since a particular file would not be sent again.

Err........ I posted three examples already in this thread with the latest being: https://forum.eset.com/topic/31893-more-liveguard-concerns/?do=findComment&comment=148981 .

Note: these downloads were all .exe based signed installers; not individual .exe programs.

Edited April 4, 2022 by itman

[itman 1,542]

I finally got LiveGuard to work as expected.

Yesterday, the software developer whose previously downloads were mentioned in this thread released his production version. Upon download of this version, LiveGuard worked as expected:

First, note that I had extended LiveGuard verdict rendering time to 10 mins. versus the default 5 mins. when I installed ESSP. Hence, the verdict decision being received from the Eset cloud.

Next and notable, there were no Firefox downloaded .part file submissions to LiveGuard.

Three events have transpired prior to this current Firefox download:

1. Firefox updated to ver. 99.

2. An Eset module update occurred to ver. 15.1.12.

3. I set existing Firefox setting entries in the Application section to their default values:

At this point, I believe that my prior Application entry settings were the cause of this issue with LiveGuard functioning properly. Why I don't know. But modification of browser file download behavior should not impact LiveGuard functionality.

Edited April 7, 2022 by itman

[itman 1,542]

Another point I should clear up is my prior assumption that there was some Eset local suspicious file detection threshold in regards to file submissions to LiveGuard. There isn't one. I have deleted that posting.

I was reviewing LiveGuard Advanced on-line documentation. It clearly states that if Eset local scanning of the file download is not 100% malicious or safe; and the file has not been previously submitted to LiveGuard via file hash verification; the file is uploaded to LiveGuard for scanning.

[New_Style_xd 64]

3 hours ago, itman said:

Another point I should clear up is my prior assumption that there was some Eset local suspicious file detection threshold in regards to file submissions to LiveGuard. There isn't one. I have deleted that posting.

I was reviewing LiveGuard Advanced on-line documentation. It clearly states that if Eset local scanning of the file download is not 100% malicious or safe; and the file has not been previously submitted to LiveGuard via file hash verification; the file is uploaded to LiveGuard for scanning. para digitalização.

Actually, I downloaded a file here it was not sent to LiveGuard, it has already been blocked. without being sent to the servers.
Why does it happen?

[Marcos 4,714]

2 hours ago, New_Style_xd said:

Actually, I downloaded a file here it was not sent to LiveGuard, it has already been blocked. without being sent to the servers.
Why does it happen?

If it was blocked by LiveGuard, then it had most likely been already submitted under your license and evaluated as malicious.

[itman 1,542]

10 hours ago, New_Style_xd said:

Actually, I downloaded a file here it was not sent to LiveGuard, it has already been blocked. without being sent to the servers.
Why does it happen?

It appears that the file was detected as malicious/PUA by one of Eset local detection methods. You should have received an Eset popup detection alert for this download. Check your Eset Detections log for an entry related to this file download.

Edited April 8, 2022 by itman

[itman 1,542]

@Marcos, there's an issue with Liveguard's processing of archive downloads.

First, upon download of the non-password protected archive, no activity from LiveGuard:

When I manually extracted the archive, LiveGuard detected two suspicious scripts and submitted them:

However, neither of the LiveGuard script submissions were blocked, nor did I ever receive any confirmation from LiveGuard that the files were safe.

As I see it, LiveGuard should have been activated upon or prior to archive creation in the Downloads folder. It also at a minimum should have blocked the scripts after archive extraction until LiveGuard cloud scanning verdict rendered.

Edited April 8, 2022 by itman

[Marcos 4,714]

Please copy & paste the whole 2 records related to the batch file submission from the Event log.

Archives (not sfx) are not submitted to LiveGuard after being downloaded, however, files from archives should be submitted after extraction.

[itman 1,542]

3 minutes ago, Marcos said:

Please copy & paste the whole 2 records related to the batch file submission from the Event log.

Time;Component;Event;User
4/8/2022 9:47:49 AM;ESET Kernel;File 'install.bat' was sent to ESET Virus Lab for analysis.;SYSTEM
4/8/2022 9:47:51 AM;ESET Kernel;File 'uninstall.bat' was sent to ESET Virus Lab for analysis.;SYSTEM

 

[Marcos 4,714]

Please provide also the corresponding records from the Sent files log.