LiveGuard Concerns

[itman 1,659]

I have figured out why LiveGuard missed both my test.exe and the ChromeSetup.exe download.

To begin, I will have to contradict a prior statement I made in the thread. That was LiveGuard scanning is not dependent upon file download "mark of the web" (MotW) status. LiveGuard is indeed very much dependent upon it.

For those who don't know what MotW is and to save forum space, here is an excellent article on it: https://outflank.nl/blog/2020/03/30/mark-of-the-web-from-a-red-teams-perspective/ . The point to note in this article are some of the ways MotW status setting can be bypassed. Note that there are also other ways to bypass it such as an undocumented single PowerShell command which will strip the ADS from any file.

As to my test.exe that was not submitted to LiveGuard upon download from the file sharing web site, no MotW was present. I don't know if this is something to do with the file sharing web site I used or, it applies to all file sharing web site downloads.

In regards to the malicious ChromeSetup.exe download non-submission to LiveGuard, it was done using wget. Wget is a Linux based file transfer utility that has also been ported to Windows. Wget is primarily used for large bulk file transfers. That is individual files are combined into one large data stream; note that "containers" are a MotW bypass method per the above linked article, then transmitted as such and extracted into individual files on the destination device. Hence, the malware payload would have no MotW.

As to my test using a password protected archive e-mail attachment that was decompressed using 7zip, first note that 7zip is a MotW bypassed method per the above linked article. None of the extracted files will have a MotW associated with them. However, the extracted file was sent to LiveGuard? Appears Eset LiveGuard processing in regards to archives is keying off of the source attachment archive file status which would (maybe) have the MotW associated with it.

The point to take away from this posting is MotW status as a trigger for LiveGuard file scanning is far from "bulletproof"

My next posting which I will make later today is in regards to what I strongly beleive Eset is using for its LiveGuard processing.

[Marcos 5,070]

We don't use MOTW and this was confirmed by developers. LiveGuard proactive protection is described at https://help.eset.com/edtd/en-US/proactive_protection.html

[AZ Tech 32]

1 hour ago, itman said:

In regards to the malicious ChromeSetup.exe download non-submission to LiveGuard, it was done using wget.

I think you misunderstood the Processes Tree. What happened first is that ChromeSetup.exe was downloaded from this phishing link as I mentioned it earlier here, and when ChromeSetup.exe run it extracts “bat.bat” to the following path “C:\Users\ <USER>\AppData\Local\Temp" and "bat.bat" is a simple batch file that executed wget followed by a malicious url used to download the payload, by the way the malicious url was already blocked by eset as @Marcos said and I confirmed that Previously by screenshot .

so far the most realistic and valid theory as to why ChromeSetup.exe won't automatically sent to LiveGuard is what I've posted here, and I don't know why @Marcos hasn't responded to me since it's one of the unacceptable issues to ignore !!

[AZ Tech 32]

1 hour ago, Marcos said:

LiveGuard proactive protection is described at https://help.eset.com/edtd/en-US/proactive_protection.html

Quote

Proactive protection

Proactive protection detects only files from the following sources:

•Files downloaded using a supported web browser

•Downloaded from a mail client

•Files extracted from an unencrypted or encrypted archive using one of the supported archive utilities

•Executed and opened files located on a removable device

If a file is suspicious, Proactive protection blocks its execution until the detection layers complete the analysis.

I have a question related to LiveGuard proactive protection :
What about files downloaded using third-party download software such as Internet Download Manager ?

[Trooper 65]

1 hour ago, Marcos said:

We don't use MOTW and this was confirmed by developers. LiveGuard proactive protection is described at https://help.eset.com/edtd/en-US/proactive_protection.html

So is LiveGuard the same as EDTD for business users?  I have seen some files missed in EDTD as well.  I am also curious what notifications you need to have enabled to see the alerts on this page you linked.  They have been hit and miss for me.  I am also using LiveGuard on my home PC as I have ESSP.

[itman 1,659]

6 hours ago, AZ Tech said:

I think you misunderstood the Processes Tree.

Yes, it is possible ChromeSetup.exe had been previously scanned by LiveGuard. @Marcos already stated that the outbound connections used by it were already blacklisted. However, detection of those malicious C&C servers should have been enough to flag ChromeSetup.exe as malicious. On the other hand, they might not have been detected as malicious at the time ChromeSetup.exe was LiveGuard scannned and LiveGuard gave the process a safe rating.

Taking @Marcos statement at face  value that LiveGuard doesn't condition file uploading on MotW status which I presently don't, do you see wget.exe as a supported LiveGuard/EDTD app?

-EDIT- BTW I downloaded latest ver. of wget from here: https://eternallybored.org/misc/wget/. The sucker is code signed! Created my global OSA block rule. Tested it. Good to go now on this bugger.

Edited January 23, 2022 by itman

[Marcos 5,070]

12 hours ago, Trooper said:

So is LiveGuard the same as EDTD for business users?  I have seen some files missed in EDTD as well.  I am also curious what notifications you need to have enabled to see the alerts on this page you linked.  They have been hit and miss for me.  I am also using LiveGuard on my home PC as I have ESSP.

There are differences between EDTD and LiveGuard.

Quote

I have seen some files missed in EDTD as well

More details would be needed, including some screenshots for clarification.

[Marcos 5,070]

12 hours ago, AZ Tech said:

I have a question related to LiveGuard proactive protection :
What about files downloaded using third-party download software such as Internet Download Manager ?

Those are not scanned. Theoretically we could probably send files executed from IDM for analysis in LiveGuard, however, I assume that most users don't use IDM to run downloaded files so the files would not be submitted anyways.

[Marcos 5,070]

13 hours ago, AZ Tech said:

I don't know why @Marcos hasn't responded to me since it's one of the unacceptable issues to ignore !!

I have no clue why it was not submitted if it wasn't detected as Suspicious object either. Was the file downloaded by a browser and not through a download manager for instance? What date and time did you download the file ?

[itman 1,659]

As far as ChromeSetup.exe goes, a lot more was going on than disclosed in this thread to date.

Per the Process Explorer activity analysis at VT, the first thing ChromeSetup.exe did was most likely process hollowing against legit Win WMIADEP.exe process:

and the code injected to run .bat script to download update.exe and subsequent processing.

The rest of the processing done by update.exe and subsequent to it is highlighted below in red:

Edited January 23, 2022 by itman

[itman 1,659]

I will also add that this OSA mitigation:

Would have stopped this ChromeSetup.exe malware "dead in its tracks." Again from the VT Process Explorer behavioral analysis:

Edited January 23, 2022 by itman

[AZ Tech 32]

On 1/23/2022 at 9:37 AM, Marcos said:

I have no clue why it was not submitted if it wasn't detected as Suspicious object either. Was the file downloaded by a browser and not through a download manager for instance? What date and time did you download the file ?

I think you are the one who should have an explanation for that !!

Normally I use IDM mainly for downloads but the ps1 files are downloaded by the browser which was here Chrome, knowing that the zip file mentioned in the same example was downloaded by IDM. 

for me I think I did my part to give you feedback about a LiveGuard issue , you are free to investigate, or just say, "I have no clue", You could at least repeat what I did here then you'll have a clue !!
I've done enough so far. I gave a working example of two files, one downloaded from the Internet as a ps1 file and the other as a password-protected zip file, and explained what happened with both.

We wouldn't have had this discussion until now if it was so important to eset, an investigation would have started by the developers a few days ago.

It is a pity that eset offers the LiveGuard feature at such a cost and that they do not have enough time to try and verify the problem, you do not care about the matter in the first place, see you reply to me days after I posted the problem and just say “I have no clue”.

[itman 1,659]

2 hours ago, AZ Tech said:

I think you are the one who should have an explanation for that !!

I have one! I will also comment on @Marcos prior statement on differences between EDTD and LiveGuard.

Besides Eset cloud scanning configuation capability and the optional creation and download of detailed scan analysis report, the main difference between LiveGuard and EDTD is the rendered scan verdict as shown below:

Quote

First, note that "Score" column is what is referred to in security analysis as the malware confidence percentage factor. The higher that factor is, the more the likelihood that submitted file is malware. The first thing I conclude from the above is Eset has set a "high bar" for malicious state rating; i.e. 100%. The currently accepted standard for malicious status is =>90%.

The main difference between EDTD and LiveGuard is one will never have a suspicious detection verdict returned by LiveGuard. This is keeping with industry standard practice that end users of consumer AV products do not have the skills to perform the required steps to evaluate a suspicious detection; e.g. above "Recommendations for users with suspicious samples." Also, Eset will get "dinged" on AV lab tests of consumer products for activity that requires user interaction.

Finally, my opinion why the ChromeSetup.exe sample was "missed" when originally scanned by LiveGuard. It's scan verdict was either safe or fell in the "suspicious" confidence range. Appears Eset will treat the "suspicious" category as safe for LiveGuard purposes. When @AZ Tech manually submitted the sample again to LiveGuard, the rating resulted in a "highly suspicious" confidence range verdict. This in turn resulted in the creation of a "suspicious" signature to allow Eset to block any subsequent downloads of the sample via real-time scanning.

As to why LiveGuard subsequently detected the sample, I strongly suspect the primary factor was the C&C servers wget connected to and downloaded the payload from. They were blacklisted by Eset sometime after the initial LiveGuard analysis.

Edited January 24, 2022 by itman

[Marcos 5,070]

Quote

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 .

My understanding is that the browser creates temporary file(s) and then joins them into one and renames the final file which may prevent the script from being recognized (at least Firefox and Edge seem to work like that, Chrome probably too).

[itman 1,659]

I will also add that this ChromeSetup.exe is a significant malware for detailed analysis.

Elaborating, the malware developer created it specifically to bypass cloud based AV analysis. At the time of initial deployment, the remote download performed was a benign payload. After sufficient wide distribution of  ChromeSetup.exe , the developer switched the download to a malicious version.

Corrective action required to prevent a like re-occurrence. Cloud scanning needs to be performed repeatedly on any download originating from untrusted sources. This means code unsigned; not a trusted Publisher; etc.. And since signed malware has been deployed with valid code signed certificates, determining trust status is iffy at best.

I on the other hand adhere to blocking suspicious behavior whether benign or not; e.g. "cmd /c" use. 

[Marcos 5,070]

ChromeSetup.exe discussed in this topic was analyzed in EDTD/LiveGuard on Jan 8 with the result:

Date/time (UTC)	Score	Status
2022/01/08 02:03:36	100	MALWARE

[itman 1,659]

1 minute ago, Marcos said:

ChromeSetup.exe discussed in this topic was analyzed in EDTD/LiveGuard on Jan 8 with the result "malware" (score 100).

OK. The manual re-scan by @AZ Techresulted in a malicious versus highly suspicious detection. At this point, I would have suspected Eset would have blacklisted it. However, when I ran the sample from its download source:

Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
1/17/2022 11:41:45 AM;HTTP filter;file;https://objects.githubusercontent.com/github-production-release-asset-2e65be/415741799/0d35497c-5e47-459d-a8f7-7037a6e7ae52?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A/20220117/us-east-1/s3/aws4_request&X-Amz-Date=20220117T164144Z&X-Amz-Expires=300&X-Amz-Signature=155eccd0e17bc5a9256c58bcf7a5c561f0e0f7ab3bd3829a52c103e654ece7f2&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=415741799&response-content-disposition=attachment; filename=ChromeSetup.exe&response-content-type=application/octet-stream;Suspicious Object;connection terminated;XXXXXXX;Event occurred during an attempt to access the web by the application: C:\Program Files\Mozilla Firefox\firefox.exe (A56FB4525DA249A093D84260BE60C110D1235204).;C5E1883FC2D3E23BC4D81F1A94F5A58A6F85FA7A;1/17/2022 11:41:45 AM

I received a suspicious detection?

[Marcos 5,070]

2 minutes ago, itman said:

I received a suspicious detection?

That's correct. The whole file was blacklisted in LiveGrid after receiving "malicious" verdict from LiveGuard/EDTD on Jan 8.

[itman 1,659]

1 minute ago, Marcos said:

That's correct. The whole file was blacklisted in LiveGrid after receiving "malicious" verdict from LiveGuard/EDTD on Jan 8.

Then why was it not detected as malicious from real-time protection via Web Access protection?

[Marcos 5,070]

Just now, itman said:

Then why was it not detected as malicious from real-time protection via Web Access protection?

Do you mean it's not detected by real-time protection if Web access protection is disabled?

[SlashRose 25]

On 1/19/2022 at 5:24 AM, AZ Tech said:

 

Nun, in diesem Fall
habe ich eine Frage: Warum wird eine Datei automatisch an LiveGuard gesendet, wenn sie eset bereits vor zwei Jahren "wie in den beigefügten Screenshots gezeigt"bekannt ist und natürlich bereits lokal "irgendwo" gescannt wurde, und gleichzeitig keine komplett neue Datei gesendet wurde? Selbst wenn wir sagen, dass diese Datei bereits lokal "irgendwo" gescannt wurde und wenn wir davon ausgehen, dass es passiert ist, ist es vor ein paar Stunden oder Minuten passiert, also wer von ihnen hat Ihrer Meinung nach Priorität, an LiveGuard zu senden?
 

 

That's exactly what I had already reported to the v14 and asked myself, for me it was about eMule, only so really answered was not answered to me!

[itman 1,659]

2 hours ago, Marcos said:

Do you mean it's not detected by real-time protection if Web access protection is disabled?

Sorry. I forgot and in reference to AMTSO Cloudcar test, Eset shows blacklist detection's under the suspicious category. It will only show a malicious detection as a result of a signature detection.

This does bring up the point of how the hell does one be able to determine the actual status of what was detected? I strongly suggest that blacklist detection's be identified as just that; blacklisted. It would also be helpful to Eset users that it be explained via Eset online product help the following. An Eset blacklist detection is a status where malware activity has been detected and Eset is in process of developing a formal signature for the malware activity.

Edited January 24, 2022 by itman

[itman 1,659]

2 hours ago, Marcos said:

ChromeSetup.exe discussed in this topic was analyzed in EDTD/LiveGuard on Jan 8 with the result:

Date/time (UTC)	Score	Status
2022/01/08 02:03:36	100	MALWARE

I will note that repeated reference to this is obscuring what actually transpired.

What actually occurred was LiveGuard detected ChromeSetup.exe after @AZ Tech manually resubmitted it LiveGuard. Prior to that point, it would have executed on the user's device. For this specific sample and upon execution, Eset would have blocked the payload download since the C&C download servers had been previously blacklisted.

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?

Edited January 24, 2022 by itman

[Marcos 5,070]

7 minutes 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 assume so since the download from a blacklisted url was just one of several reasons why the file was detected and blacklisted by LiveGuard.

[itman 1,659]

28 minutes 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?

To clarify, I mean it was originally submitted to LiveGuard two months. Let's also assume it was not detected which I strongly believe would be the case.

All indications at present, point to the fact that @ AZ Tech's sample was submitted but not originally detected by LiveGuard. This is the only logical present explanation for the sample not being submitted to LiveGuard when he executed it. Or is it? My test.exe example downloaded from a file sharing web site via Firefox also was not scanned by LiveGuard prior to execution.

Edited January 24, 2022 by itman