Jump to content

Recommended Posts

1 hour ago, Marcos said:

So you confirm that the file you tested existed on the disk, ie. it was scanned by ESET before you uploaded it to the file sharing service and then you downloaded it?

If Eset scans locally created .exe's, then that is the explanation for the non-submission to LiveGrid upon download. The file hash for the downloaded file would be the same as the original uploaded file on disk.

However, the .exe was a self-executing CAB file. Of note is the file is extracted from the CAB archive and immediately run. Does Eset scan those upon file creation? Of note is Eset's reference to only .SFX files that are scanned:

Quote

Self-extracting archives – Self-extracting archives (SFX) are archives that can extract themselves.

https://help.eset.com/eis/15/en-US/idh_config_threat_sense.html

Edited by itman
Link to comment
Share on other sites

9 hours ago, Marcos said:

That also means users could not download the payload with WAP enabled.

I confirm it, as shown in the attached screenshot.

 

9 hours ago, Marcos said:

I assume that the triviality of the batch file might have contributed to the fact that an automated detection was not generated. We manually analyzed and created the detection yesterday.

But at the same time I strongly object to this, in my view you shouldn't say triviality of the batch is the reason or justification, I come to eset from the background of using Kaspersky for more than 5 years and I have never met a single case detection was not generated no matter what kind of threat, it is worth mentioning "As shown in the second screenshot" Kaspersky from day one created automatic detection for this file which Marcos justified that eset did not create automatic detection for it because of the triviality of the batch !! .
I apologize, but I am not convinced by such justifications. A threat is a threat, no matter how simple or trivial the threat is !.

This is just a quick reply, without deviating from the main topic.

payload.png

Kaspersky.png

Link to comment
Share on other sites

9 hours ago, Marcos said:

That also means users could not download the payload with WAP enabled.

to clarify, I confirmed it without forgetting what @itman said :

6 hours ago, itman said:

This is OK as far as it goes. The download could have been modified since then to use different C&C download servers.

 

Link to comment
Share on other sites

2 hours ago, AZ Tech said:

Eu confirmo, como mostrado na captura de tela anexada.

 

Mas, ao mesmo tempo, eu me oponho fortemente a isso, na minha opinião você não deve dizer que a trivialidade do lote é a razão ou justificativa, eu venho ao fundo do uso da Kaspersky por mais de 5 anos e eu nunca conheci um único caso de detecção não foi gerado não importa que tipo de ameaça, vale mencionar "Como mostrado na segunda captura de tela" Kaspersky desde o primeiro dia criou detecção automática para este arquivo que Marcos justificou que eset não criou detecção automática para ele por causa da trivialidade do lote !! .
Peço desculpas, mas não estou convencido por tais justificativas. Uma ameaça é uma ameaça, não importa o quão simples ou trivial seja a ameaça !.

Esta é apenas uma resposta rápida, sem desviar do tema principal.

carga.png

Kaspersky.png

This situation made me afraid, how is it that ESET treats this threat as trivial, not giving importance on the subject. It's explained why Kaspersky has a higher detection rate on threats.

Link to comment
Share on other sites

14 hours ago, Marcos said:

If a file downloaded from the Internet is not sent for analysis in the LiveGuard cloud sandbox and is not whitelisted, most likely it's because the file is already known to ESET (was already scanned locally). Likewise already detected files are not sent either.

 

5 hours ago, Marcos said:

So you confirm that the file you tested existed on the disk, ie. it was scanned by ESET before you uploaded it to the file sharing service and then you downloaded it?

Well, in this case I have a question :
Why is a file automatically sent to LiveGuard when it is already known by eset two years ago "as shown in the attached screenshots" and of course has already been scanned locally "somewhere", and at the same time not sent a completely new file?

Even if we say that this file has already been scanned locally "somewhere" and if we assume that it happened, it happened a very few hours or minutes ago, so which of them do you think has priority to send to LiveGuard ?

Screenshot 2022-01-19 052059.png

TidyMyMusic-2.1.0.3-2020.png

Link to comment
Share on other sites

9 hours ago, AZ Tech said:

Why is a file automatically sent to LiveGuard when it is already known by eset two years ago "as shown in the attached screenshots" and of course has already been scanned locally "somewhere", and at the same time not sent a completely new file?

Thanks for pointing this out.

Most of the complaints about LiveGrid uploads of safe files appear to originate from "old" scanned files. It appears that LiveGuard upload criteria is also conditioned by age of the file. Namely, the elapsed time from present when Eset originally whitelisted the file. This kind of makes sense to me in that Eset detection methods in the past do not equal those at the present time. In other words, Eset is doing a re-verification of the file in the cloud sandbox.

Edited by itman
Link to comment
Share on other sites

43 minutes ago, itman said:

Most of the complaints about LiveGrid uploads of safe files appear to originate from "old" scanned files. It appears that LiveGuard upload criteria is also conditioned by age of the file. Namely, the elapsed time from present when Eset originally whitelisted the file. This kind of makes sense to me in that Eset detection methods in the past do not equal those at the present time. In other words, Eset is doing a re-verification of the file in the cloud sandbox.

At first glance, it seems logical, but when I think a little, I find that the vast majority of old files are not treated with the same logic, It's a little confusing to me.

Link to comment
Share on other sites

  • Administrators

By new I mean new locally. The age of a file doesn't play any role in whether a file is submitted or not. It just cannot be trusted/whitelisted (e.g. MS-signed) or scanned locally before and evaluated as clean. Locally scanned files are either detected, if malicious, or submitted to LiveGrid immediately after being scanned by any of the scanners, if determined to be suspicious for whatever reason. Such file is subsequently automatically replicated similarly to the LiveGuard sandbox, a block and detection is created automatically or manually and distributed to users via LiveGrid.

Submissions have nothing to do with the complexity or triviality of samples, it was a wrong assumption. The file above (ChromeSetup.exe) was blocked in LiveGrid on 2022-01-08, 03:05 CEST which appears to be shortly after we received it first from LiveGuard.

Link to comment
Share on other sites

49 minutes ago, Marcos said:

Locally scanned files are either detected, if malicious, or submitted to LiveGrid immediately after being scanned by any of the scanners, if determined to be suspicious for whatever reason. Such file is subsequently automatically replicated similarly to the LiveGuard sandbox, a block and detection is created automatically or manually and distributed to users via LiveGrid.

For clarification, are you stating:

1. Eset locally detected suspicious detection's are submitted to LiveGrid.

2. All newly created files not trusted and/or whitelisted are blocked and submitted to LiveGuard for cloud scanning. This assumes an Eset local malicious detection did not occur previously via real-time scanning.

Is the above correct?

 

Link to comment
Share on other sites

1 hour ago, Marcos said:

By new I mean new locally. The age of a file doesn't play any role in whether a file is submitted or not. It just cannot be trusted/whitelisted (e.g. MS-signed) or scanned locally before and evaluated as clean.

This doesn't sync with prior forum postings stating old files resident on the user's device are being submitted to LiveGuard.

I can only infer from our current discussion, that these files must have existed on the local device prior to Eset installation and, both the Eset initial scan was terminated and no subsequent Eset scan; either scheduled or on demand, was ever performed. Plus, the file has never been accessed since the Eset installation. This is possible but " a bit of a stretch."

Edited by itman
Link to comment
Share on other sites

  • Administrators
56 minutes ago, itman said:

For clarification, are you stating:

1. Eset locally detected suspicious detection's are submitted to LiveGrid.

2. All newly created files not trusted and/or whitelisted are blocked and submitted to LiveGuard for cloud scanning. This assumes an Eset local malicious detection did not occur previously via real-time scanning.

Is the above correct?

 

1, Yes. I mean files detected by heuristics, generic detections, DNA/XDNA detections, etc. Only static detections are not typically sent automatically.

2, Yes when it comes to EDTD. Maybe when it comes to LiveGrid. If downloaded from the Internet or run from removable media, they are submitted by LiveGuard.

Link to comment
Share on other sites

  • Administrators
41 minutes ago, itman said:

I can only infer from our current discussion, that these files must have existed on the local device prior to Eset installation...

LiveGuard basically requires a file to be downloaded from the Internet or to be run from removable media in order to be submitted. If files already existed on the disk, they are not submitted by LiveGuard but may be submitted by LiveGrid if they are suspicious for some reason or if they meet some criteria.

Link to comment
Share on other sites

5 hours ago, Marcos said:

2, Yes when it comes to EDTD. Maybe when it comes to LiveGrid. If downloaded from the Internet or run from removable media, they are submitted by LiveGuard.

Let's talk about my IMAPS AOL based Thunderbird e-mail that for some unknown reason ( I suspect OAuth2 security) Eset doesn't scan at all via client e-mail processing. This issue BTW to this day still remains unresolved.

Because of this, I only accept text based e-mail with attachments listed separately. I never open attachments in Thunderbird but instead have it set to open with its default associated program. For example, a .docx attachment would be open by MS Office Word. Since the file already exists on my disk, it appears that it would never be submitted to LiveGuard.

-EDIT- I stand corrected and thankfully so.

E-mailed myself a password protected archive I knew would trigger LiveGuard when opened. In Thunderbird, selected 7zip to extract the file. T-Bird dropped the compressed file to my User account temp directory. Note: the compressed file did not have the "Mark-of-the-Web" associated with it. Upon extraction, the .exe contained within was immediately sent to LiveGuard and its associated temp file deleted.

Edited by itman
Link to comment
Share on other sites

Since there were some questions about Eset local real-time processing scanning my test.exe in regards to my original posting I started this thread with, I retested using the following procedure:

1. I disabled Eset real-time scanning for my test.exe file by adding an exclusion for it.

2. I modified my test.exe using PowerShell to add some code to the end of the file resulting in the file hash being changed.

3. I uploaded the test.exe to a file sharing web site.

4. I removed the prior created Eset real-time scanning exclusion for the test.exe file along with deleting the file from my hard disk.

5. I downloaded the test.exe file from the file sharing web site. No LiveGuard submission occurred.

6. When I ran the downloaded test.exe, I received notification the file had been submitted by LiveGrid for Eset AV lab analysis and the process executed successfully.

Therefore, I conclude that something else within Eset is triggering an upload to LiveGuard and unknown files are not being submitted as stated by Eset. Or, my .exe as created bypassed LiveGuard processing.

Link to comment
Share on other sites

31 minutes ago, itman said:

Since there were some questions about Eset local real-time processing scanning my test.exe in regards to my original posting I started this thread with, I retested using the following procedure:

1. I disabled Eset real-time scanning for my test.exe file by adding an exclusion for it.

2. I modified my test.exe using PowerShell to add some code to the end of the file resulting in the file hash being changed.

3. I uploaded the test.exe to a file sharing web site.

4. I removed the prior created Eset real-time scanning exclusion for the test.exe file along with deleting the file from my hard disk.

5. I downloaded the test.exe file from the file sharing web site. No LiveGuard submission occurred.

6. When I ran the downloaded test.exe, I received notification the file had been submitted by LiveGrid for Eset AV lab analysis and the process executed successfully.

Therefore, I conclude that something else within Eset is triggering an upload to LiveGuard and unknown files are not being submitted as stated by Eset. Or, my .exe as created bypassed LiveGuard processing.

Great analysis, based on this I'm thinking that the cost charged to have LiveGuard is not worth it. better stick with the EIS. since we are paying a high amount for nothing. or Kaspersky's Cloud solution, has the best result.

Link to comment
Share on other sites

I have a theory as to why LiveGuard is not detecting my test.exe and other missed downloads I have observed; that is they were only detected after download and submitted to LiveGrid. As much as I would like to believe it was my "stealthy" coding, that is not the reason.

To date, all LiveGuard submissions on my Eset installation have been detected during the in-process file creation phase. For Firefox browser based downloads, it was submission of the .part file in my User account temp directory. For the prior posted archive file attachment example, it was in the User Account temp created sub-directory by 7zip processing.

But what happens if the file downloaded/created locally doesn't involved any intermediate processing during file creation? My suspicion is FireFox for example, only will create a .part place holder file in the User account temp directory for larger file downloads. Otherwise, it will just directly create the download in the user's default download directory.

-EDIT- Also from the fileinfo.com link posted previously is:

Quote

When downloading a file with Firefox, the web browser creates a PART file in the "Downloads" folder on your computer. You may see the PART file if the file is currently downloading or if the download was interrupted before completion.

As such, it is possible Eset is moving the .part file to the User account temp directory during LiveGuard analysis. In any case, it would appear LiveGuard processing would be dependent upon a .part file being created.

Edited by itman
Link to comment
Share on other sites

Since I haven't commented on this point, I will now and "it's a no brainer."

In ESSP, there should be no LiveGrid submissions period. If Eset feels the file is suspicious enough to warrant a LiveGrid upload, it should be sending the executable to LiveGuard instead and blocking it until verdict rendered. This also would provide a backup mechanism for a missed LiveGuard submission upon initial file download.

-EDIT- Just read in Eset ETDT documentation that if one is receiving a LiveGrid submission versus LiveGuard submission, it means that the file was previously submitted to LiveGuard.

Looks like my test.exe is indeed a LiveGuard bypass.👍

Edited by itman
Link to comment
Share on other sites

On 1/16/2022 at 9:44 PM, itman said:

The question is why wasn't this file sent initially to LiveGuard and blocked execution until verdict rendered?

I have a theory and a working example of why ChromeSetup.exe is not sent to LiveGuard and may also apply to your test.exe, Here is what I did :

1- I created a simple powershell script inside a virtual machine completely isolated from eset.

2- I first uploaded the file as ".ps1" to a file sharing service, then I deleted several lines from the script to get a new hash, then I uploaded the new file to the file sharing service as password protected zip file .

3- When I downloaded the first file, which was in ".ps1" format, it was not sent to LiveGuard .

4- When I downloaded the second file, which was in “.zip” format, it was sent to LiveGuard as soon as it was extracted from the zip file “as shown in the screenshot”.

Based on what has been explained, I conclude the following :

When downloading exe - ps1, etc. files, It is scanned by eset during the download process and possibly marked as safe as happened with ChromeSetup.exe which was not detected during the download process, so this file from LiveGuard's point of view is already scanned and marked as safe .

and as @itman said :
 

On 1/18/2022 at 11:03 PM, itman said:

This also means LiveGuard is not going to protect you from an Eset borked non-detection.

Even if the "Eset borked non-detection" happened on your device !! "during the download"

as for files that are downloaded inside a password-protected zip file, they are not scanned during download, and therefore when extracted, they are sent directly to LiveGuard .

@Marcos I hope to investigate the matter and present it to the developers, because if what I suppose is correct, this is a problem that can be abused very badly.

Screenshot 2022-01-21 083942.png

Link to comment
Share on other sites

4 hours ago, AZ Tech said:

Even if the "Eset borked non-detection" happened on your device !! "during the download"

as for files that are downloaded inside a password-protected zip file, they are not scanned during download, and therefore when extracted, they are sent directly to LiveGuard .

My test.exe is nothing more than a .bat to .exe created file. The difference is how it was created.

It was created not by any web available program to do so, but by a .bat script. The script deployed a little known but quite effective, for bypass purposes, "living off the land" Win trusted binary to create a .exe that contained a self-executing .cab file containing test.bat. These types of files are used by Windows internally to extract the content in memory and immediately execute what was extracted. Of note is my test.exe Properties show details for a trusted Win executable that exists in every Windows version.

Edited by itman
Link to comment
Share on other sites

6 hours ago, AZ Tech said:

I have a theory and a working example of why ChromeSetup.exe is not sent to LiveGuard

Refer to the following per VT behavior analysis:

Eset_Chrome.png.c53e416761a8339d925e20d02313b4c4.png

Wget.exe was spawned from a trusted WMI based process. Notice the "-O" command line parameter. The update.exe malware payload was downloaded from attackers C&C server and immediately executed.

Bottom line is LiveGuard missed the file download by wget.exe.

Link to comment
Share on other sites

How many problems do you have in this LiveGuard.
Will the developers take into account the issues you guys showed in the comments.
If they are going to fix it, it will be fast, because their fixes take a long time to get out to the general public.

Link to comment
Share on other sites

I am thankful for this ChromeSetup.exe LiveGuard bypass.

Wget doesn't have to be installed and can be dropped anywhere:

Quote

Download wget.exe from https://eternallybored.org/misc/wget/ and then copy into your "C:\Users\%USERNAME%\AppData\Local\Microsoft\WindowsApps" folder. You'll get an up to date copy of wget and it will be on the path right away.

https://superuser.com/questions/77247/how-do-i-install-wget-for-windows

As such, this rules out any Eset mitigation for it since it doesn't support global wildcard path specification; something I have asked years for. I will do so in OSArmor which does support global wildcard path specification. It also might already have a built-in mitigation for it.

Link to comment
Share on other sites

  • Administrators

Not sure what ChromeSetup you mean but the one mentioned in this topic was blocked on Jan 8, 3:05 AM CET based on a LiveGuard analysis.

Link to comment
Share on other sites

6 minutes ago, Marcos said:

Not sure what ChromeSetup you mean but the one mentioned in this topic was blocked on Jan 8, 3:05 AM CET based on a LiveGuard analysis.

That is not case initially as @AZ Tech posted here: https://forum.eset.com/topic/31086-liveguard-concerns/?do=findComment&comment=145452 .

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...