LiveGuard Concerns

[AZ Tech 32]

18 hours ago, Marcos said:

I assume so since the download from a blacklisted url was just one of several reasons why the file was detected and blacklisted by LiveGuard.

Excuse me, can someone explain this answer to me !!
I don't know if this is because English is not my native language or if @Marcos answer did not provide a sufficient answer to @itman question !
 

18 hours ago, itman said:

This is the only logical present explanation for the sample not being submitted to LiveGuard when he executed it.

I agree with this knowing that so far this has not been confirmed by eset.
Unfortunately, all the answers that Marcos provides to these direct questions are inconclusive, as he has so far neither denied nor confirmed anything !!
and please if the answers he gave represent a definitive answer that is understandable for one of you, please explain to me the answer .

[itman 1,659]

I did some additional testing. For this test I downloaded a .exe I knew LiveGuard had most definitely scanned in the past. It was a password protected archive.

Upon download and during archive extraction, it was immediately sent to LiveGuard. I therefore conclude LiveGuard submission is conditioned solely upon the file not previously submitted from the local device. I have removed my previous posting in regards to "stale" LiveGuard re-submission since it is not applicable.

I additionally retested by again downloading the same .exe after removing all traces of it being prior LiveGuard submitted on my device. This time I removed the "mark of the web" (MotW) ADS from the file prior to extraction. Removal of the MotW had no effect upon the file again being submitted to LiveGuard. Therefore at present, I take the Eset statement that LiveGrid is not conditioned by MotW at face value.

Pertaining to ChromeSetup.exe not being submitted to LiveGuard when downloaded from its web site source, the possible explanations are:

1. The file was somehow classified as "trusted." It did employ an installer that has been abused in the past.

2. The file had been previously scanned by Eset, deemed safe, and "whitelisted."

In other words, LiveGuard is not going to protect you from a previous rendered erroneous safe classification that would bypass LiveGuard submission.

Edited January 25, 2022 by itman

[itman 1,659]

17 minutes ago, AZ Tech said:

Excuse me, can someone explain this answer to me !!

Are you referring to how Eset performs blacklisting in general, or how Eset's blacklisting of the URL connections used in ChromeSetup.exe would have prevented it from executing? 

[AZ Tech 32]

19 minutes ago, itman said:

Are you referring to how Eset performs blacklisting in general, or how Eset's blacklisting of the URL connections used in ChromeSetup.exe would have prevented it from executing? 

No, what I mean is that your question was :

19 hours ago, itman said:

However in the instance the exact same ChromeSetup.exe was deployed using different C&C download servers and, it was downloaded; lets say 2 months ago, would it had been submitted to LiveGuard? If submitted to LiveGuard would it have found this instance malicious?

I will quote from your words these two questions:
"lets say 2 months ago, would it have been submitted to LiveGuard?
If submitted to LiveGuard would it have found this instance malicious?"

my question is :
Did Marcos provide an answer to these two questions that I could not understand ?
Marcos' response was :
 

19 hours ago, Marcos said:

I assume so since the download from a blacklisted url was just one of several reasons why the file was detected and blacklisted by LiveGuard.

 

[AZ Tech 32]

39 minutes ago, itman said:

Removal of the MotW had no effect upon the file again being submitted to LiveGuard.

the second time the file was downloaded in the form of archive or exe ?
Because I need to make sure that it is not a general problem with all files that are not downloaded as archive, or in other words, files that eset cannot scan during the download process and marked them as safe and therefore are not sent to LiveGuard !

[itman 1,659]

5 hours ago, AZ Tech said:

the second time the file was downloaded in the form of archive or exe ?
Because I need to make sure that it is not a general problem with all files that are not downloaded as archive, or in other words, files that eset cannot scan during the download process and marked them as safe and therefore are not sent to LiveGuard !

The question of my test.exe not being submitted to LiveGuard is still outstanding. Since it did not have the MotW associated with, it led me to believe it was the  reason for the non-submission. It isn't the reason.

In regards to my last posted test results, the .exe contained code within it that Eset would have detected locally as suspicious/malicious. This has led me to conclude that LiveGuard submissions are being conditioned upon Eset local real-time heuristic sandbox analysis. If a major anomaly is detected by that scan and the file has not be previously submitted to LiveGuard on the local device, it will be blocked and submitted to LiveGuard. Otherwise, no LiveGuard upload will occur.

Again and bottom line - LiveGuard submissions are not unconditional. Eset local scanning must detect something "suspicious" to warrant an upload to LiveGuard.

In regards to your initial ChromeSetup.exe download that was not submitted to LiveGuard, no suspicious/malicious behavior activity was detected locally. The file was submitted to LiveGrid, I suspect, because of the blacklisted URL references contained within. Your next question will be are not those blacklisted URL references considered suspicious enough to warrant a LiveGuard upload? Appears they are not.

Edited January 25, 2022 by itman

[itman 1,659]

22 hours ago, itman said:

Your next question will be are not those blacklisted URL references considered suspicious enough to warrant a LiveGuard upload?

I guess I should clarify this statement. It really is N/A.

Once ChromeSetup.exe was able to inject WMIADEP.exe, a trusted Win system process, to run its batch script, it was "game over" for any futher Eset local heuristic detection of malicious activity. 

Code injection detection by an unknown and untrusted process is what Eset needs to improve upon.

Edited January 26, 2022 by itman

[itman 1,659]

Rather than edit my prior posting, I will make another one. This illustrates another possible scenerio in regards to ChromeSetup.exe. This scenario also "wraps up" malware concepts I have previously posted in this thread. We'll assume that all Eset detection mechanisms were deployed and this .exe is sandbox aware.

At Eset "first sight" of  ChromeSetup.exe, Eset local hueristics did detect the injection activity to WMIADEP.exe. This detection in turn resulted in a block and upload by LiveGuard to the cloud sandbox. The .exe detected that it was being scanned in the sandbox and set a "switch" in memory to this effect. Upon connection to the remote C&C servers, they first queried if the sandbox switch was set. If set, the download was done minus the malware payload. 

Eset LiveGrid scanning of the .exe completed and the following "suspicious" indicators were evaluated:

1. Process injection - very suspicious.

2. Download of a non-native Windows download utility not frequently used - suspicious.

3. Execution of the above downloaded utility to download additional software - highly suspicious.

Since LiveGuard won't return a suspicious verdict, it rendered a "safe" one. Eset local based processing received the safe verdict, whitelisted the process -OMG!, and unblocked the .exe.

Thereafter whenever an Eset installation encountered ChromeSetup.exe, it ran unimpeded. This only stopped when Eset in an unrelated detection incident, flagged the C&C servers used by .exe and blacklisted them.

Given the above two scenarios, I would prefer to believe that ChromeSetup.exe was not detected by Eset local heuristic scanning ........................