Leonardo

Glad to see that Eset has joined AVLab test series. Since they are not an AMTSO member, they are not constrained by its testing methodology. As such, they can be more "creative" in testing of malware.
There does appear to be some confusion as to what the various test levels; L1 - L3 mean. So let's review those:
https://avlab.pl/en/modern-protection-without-signatures-comparison-test-on-real-threats/
To sum up the above, Level 3 ranking means malware detection based on behavior methods only. Also, behavior based detection implies that some system modification activities may have occurred prior to detection. Level 1 detection obviously offers the most system protection. However, almost all in the security industry will state that given the current and evolving state of malware development, it is an unrealistic malware detection standard. Rather, Level 3 malware behavior detection today is mandatory in conjunction with Level 1 and 2 methods.
As far as LiveGuard being a contributing factor to ESSP 100% Level 1 scoring, I see no evidence of this in the current test published details. One of many ways to determine LiveGuard effectiveness would be to have AVLab perform a controlled test of both EIS and ESSP. The test malware samples would include a large number of "true" 0-day samples. That is malware in-the-wild not currently being detected by any AV solution; not 0-day malware seen in the last 30 days. This test would also establish Eset's effectiveness using L3 behavior methods.

Looks great, only ESET 100% on level 1 👍. Just keep it up..

Appears that LiveGuard helped a lot to receive 100% L1 detection in this test: https://avlab.pl/en/recent-results/

It's impossible to determine what went on from your posted logs screen shot since the dates are different.
Best to test using BAFS when you get back in town and then compare your results with my posted one. When you do retest, make sure you log on to MS BAFS web site and download a new wdtestfile.exe to test with.

I'll save you some work.
For those not familiar with this download test, it is to test Microsoft Defender "block-at-first-sight" of a file download with subsequent upload and analysis by the Microsoft cloud.
Upon file download by Firefox, Eset LiveGuard detected it and submitted it to the Eset cloud:
Time;Component;Event;User
4/19/2022 9:12:55 AM;ESET Kernel;File 'Sj2-Kz7u.exe.part' was sent to ESET Virus Lab for analysis.;SYSTEM
Time;Hash;File;Size;Category;Reason;Sent to;User
4/19/2022 9:12:55 AM;09C513ABE0F1B48029E8EBE288EBE530DEE8E5FE;C:\Users\xxxxxx\Downloads\Sj2-Kz7u.exe.part;5716;Executable;Automatic;ESET LiveGuard;xxxxxxxxx
Since this download was an executable, Eset blocked file access upon file creation until Eset cloud scanning was completed:

Blocked file access was further confirmed when I tried to access the file while Eset cloud analysis was underway:
Time;Component;Event;User
4/19/2022 9:16:14 AM;ESET Kernel;ESET LiveGuard is analyzing the file to ensure it's safe to use. We will notify you in a few minutes.Unblock the file (not recommended)Change setup;xxxxxxxxx
Upon completion of Eset cloud scanning, a safe verdict was rendered by LiveGuard and access to the file was unlocked:
Time;Component;Event;User
4/19/2022 9:17:49 AM;ESET Kernel;ESET LiveGuard has analyzed a file. It is safe to use.;xxxxxxxxxx

Pertaining to Eset log entries created in this transaction, all were Event log entries except for one Sent log entry.
-EDIT- I forgot to mention that although 29 vendors at VirusTotal detect this file malicious, Kaspersky's detection is the most accurate, "Not-a-virus:HEUR:RiskTool.Win32.TestFile.gen."
When the file is created by the Microsoft download site, it in turn creates a sig. for it only used by the MD cloud. In other words, this is a MD "block-at-first-sight" functionality test only. This is further confirmed by the file not being detected by Microsoft at VirusTotal.

If you are able to reproduce the situation when files are temporarily blocked by LiveGuard but are not listed in the Sent files log, I could provide you with a logging module to get more info about what's going on.

Verify that Log files minimum verbosity level is set to "Informative" per below screen shot;

Hello @Marcos
Thank you for your interest in my problem.
Are these explanations enough ?

A detection for your sample was added yesterday. You can also submit samples via the built-in form, but I'd recommend not to submit anonymously. For some reason a lot of users submit anonymously without entering the email address, yet they expect us to reply.

Unfortunately it's not clear to me what the problem is and what I should check in the ELC logs. Please elaborate more on the issue.

Not true. For instance, the script that I provided above doesn't perform anything malicious, yet it was submitted to LiveGuard for analysis and was temporarily blocked.

If you want to have a sample analyzed, please send it by email to samples[at]eset.com in an archive encrypted with the password "infected". Files that are sent to LiveGrid go to the ticketing system, however, since most the submitted files is junk and appropriate files (exe/dll, scripts ...) make up maybe less than 1% of the submissions, it's better to submit them by email as instructed above.

Since I realize many are following this thread, I will post an update on LiveGuard script processing.
After a long and arduous off-forum session with @Marcos, the following has been resolved. LiveGuard will not process suspicious scripts until actual execution of the script is performed. Again when a script is downloaded, LiveGuard will not be invoked.
Additionally when the script is being processed by LiveGuard, script access is "locked" but this status will not be shown via Win Explorer Content Menu examination.

That really isn't necessary.
I've seen enough to conclude LiveGuard processing in regards to non-executables will only be initiated where code exists for potential malware behavior. That is the code has been previously detected performing both benign and malicious activities. The only way to determine the status in this instance is to actually run the code in a full sandbox environment. Hence, the upload to LiveGuard.

I just dawned on me that what I posted above clearly shows LiveGrid processing is being performed.
LiveGuard is a two step process. First, submission is made to Eset cloud for analysis. If that analysis is inconclusive, then an additional upload is performed to Eset VirusLab.

You can download it from https://we.tl/t-kGTJmoyalk
It will be unique on your machine so it should be blocked and submitted:

If the test you really come to the conclusion that LiveGuard has some problem I get very worried, because I made some downloads did not return anything. oh I thought either that it was not detected or the file is clean. I always have this doubt.

One last test.
This is to rule out Eset archive scanning after .zip file extraction as the reason for these .bat files not being blocked by LiveGuard.
Repeated same procedure as above with the exception that only the previous archive .bat files triggering LiveGuard uploads to the Eset cloud were uploaded to a file sharing site.
Upon download of these files from the file sharing web site, the exact same LiveGuard behavior occurred. The file was uploaded to Eset VirusLab and the .bat script download was not blocked from execution by LiveGuard. Nor was any LiveGuard safe verdict received on the local device.
It therefore can be concluded that LiveGuard is not properly processing script file downloads. Or, not processing script file downloads per Eset published documentation.
The remaining question is if other non-.exe file downloads are also not being properly processed by LiveGuard.

You can add them as an attachment to your next reply. Only Eset moderators can access file attachments.

SmartScreen is not the reason for non-blocking.
I excluded original .bat file downloads from Eset real-time scanning. Modified the .bat files to change their hash value. Created a new .zip archive of the original file download. Uploaded the new .zip archive to a file sharing web site. I also disabled SmartScreen file and app checking.
Upon download of this new .zip archive and extraction of it, exact same behavior from LiveGuard as originally reported. Same two .bat file were uploaded to LiveGuard and they were not blocked.
-EDIT- BTW with SmartScreen app and file checking disabled, I still get a Win warning popup when accessing the ,bat files via Win Explorer Edit option about not being from a Trusted Publisher; i.e. unsigned. Wonder if that could be a factor?

Also, locally detected malicious file are sent to the Eset cloud via LiveGrid; not LiveGuard.

This file was sent to LiveGrid, ie. access to it was not blocked. It could be that the file is either trusted or has already been submitted to LiveGuard before and was evaluated as clean. ELC logs could shed more light.

Assumed here is the LiveGuard did not complete its cloud scanning activities within the ESSP LiveGuard default scan time limit of 5 mins.. In this instance, the file will be unblocked after 5 mins. and no safe Event log entry will be generated.
You can increase ESSP LiveGuard default scan time limit.

You won't receive any notification unless you attempt to run a file that has been submitted and is temporarily blocked.

I assume the rejection was due to the submission to LiveGuard previously from my device; i.e. file hash previously submitted to LiveGuard.
As far the other script that was sent to LiveGuard, was it blocked on your device? Did you receive a safe verdict rendering from LiveGuard? Also, this file should not have been sent to LiveGuard since its file hash is already known to LiveGuard from my previous submission of it.
The question still remains that when these scripts were sent to LiveGuard from my device, expected LiveGuard behavior did not occur. That is again, the files were not blocked and LiveGuard safe verdict received.