Jump to content

LiveGuard not working for me !


Recommended Posts

I will also state this based on your postings. There really is no change in Eset processing of suspicious files in LiveGuard that currently exists in the other Eset home versions. That is suspicious files are being marked as Safe by LiveGuard and allowed to run.

Link to comment
Share on other sites

  • Administrators
6 hours ago, starrtiktokk said:

I will also state this based on your postings. There really is no change in Eset processing of suspicious files in LiveGuard that currently exists in the other Eset home versions. That is suspicious files are being marked as Safe by LiveGuard and allowed to run.

Please clarify based on which postings did you come to the conclusion that LiveGuard is useless. The file tested above (07c670b4ae43186e7e56124048946ba2f7324226359c10e344241e633773e6f0) is benign and not subject to detection, the LiveGuard verdict was correct and the file was correctly allowed to run.

Link to comment
Share on other sites

9 minutes ago, Marcos said:

Please clarify based on which postings did you come to the conclusion that LiveGuard is useless. The file tested above (07c670b4ae43186e7e56124048946ba2f7324226359c10e344241e633773e6f0) is benign and not subject to detection, the LiveGuard verdict was correct and the file was correctly allowed to run.

Safe file. Kaspersky also removed the detect.

 

Снимок1.png

Link to comment
Share on other sites

9 hours ago, starrtiktokk said:

I will also state this based on your postings. There really is no change in Eset processing of suspicious files in LiveGuard that currently exists in the other Eset home versions. That is suspicious files are being marked as Safe by LiveGuard and allowed to run.

Based on my experience and tests of LiveGuard, the verdict is only wrong " So to speak " in three cases:

-That the file is corrupted "cannot be run" and it is strange that you find the file is detected on VT by other vendors .

-The file is password protected.

-The last case is the strangest for me as it happened here, what happened here is that when you run the file "double clicking" nothing happens, the file does not perform any suspicious behavior, but if you double click on the file again, it is detected by eset.

Other than that everything is fine, I did many tests on new/undetected malicious files, and LiveGuard verdict was positive and correct every time.

Link to comment
Share on other sites

  • Administrators

Actually if a file is corrupted or if it's a password-protected sfx archive the verdict will be "clean" since the file could not be executed and could not do anything malicious.

By the way, are you still having issues with a delay in submitting samples when you run it? Or the issue is gone and samples are now submitted immediately according to the Submitted files log?

Link to comment
Share on other sites

7 hours ago, Marcos said:

By the way, are you still having issues with a delay in submitting samples when you run it? Or the issue is gone and samples are now submitted immediately according to the Submitted files log?

Currently I don't do many tests so I was waiting for your response as you told me, but during normal use and since my last complaint about the delay I came across some new files and the process of sending to LiveGuard was fast with an average of 3 to 5 minutes.

Link to comment
Share on other sites

On 11/6/2021 at 9:37 PM, Marcos said:

the LiveGuard verdict was correct and the file was correctly allowed to run.

Wrong LiveGuard verdict

When I downloaded this malicious file :

MD5    5229e967a3ede3c8ef51714135b161fb
SHA-1    8e2ced692643135f7f598ca2c0282f6fbe3845c9
SHA-256    996cf8f61a636f8c09e5919fe6426a28b3d5b6e7865a0e46294cc0085a9e83aa

As shown in the screenshots, when I extracted the file it was sent to LiveGuard for analysis, then the verdict came that the file was clean and safe to use, although at the same time it was 29/67 at VT detected this file as malicious .
At first I thought the VT results were a false positive, but after several hours I found that the file was also detected by eset as a malicious file.

e1.png

e2.png

e2_v2.png

e3.png

e3_v2.png

e4.png

e4_v2.png

e6.png

e7.png

VT_Before.png

Link to comment
Share on other sites

  • Administrators

It's a dll so it won't run on a replicator. The detection was added by an analyst yesterday. While LiveGuard improves detection, it's not a magic thing that could 100% distinguish benign and malicious files.

Link to comment
Share on other sites

21 hours ago, AZ Tech said:

When I downloaded this malicious file :

MD5    5229e967a3ede3c8ef51714135b161fb
SHA-1    8e2ced692643135f7f598ca2c0282f6fbe3845c9
SHA-256    996cf8f61a636f8c09e5919fe6426a28b3d5b6e7865a0e46294cc0085a9e83aa

This was no ordinary Windows .dll.

Rather, it was an Excel dll; i.e. .xll, used by a third party Excel add-in software, Excel-DNA Add-In Framework for Microsoft Excel: https://excel-dna.net/

Of note is this add-in allows for .Net to interface with Excel to run .Net based code contained within the .xll file.

Also, it is critical to properly configure Excel security-wise in regards to add-ins:

  • Require Application Add-ins to be signed by Trusted Publisher     Check this box to have the Trust Center check that the add-in uses a publisher's trusted signature. If the publisher's signature hasn’t been trusted, the Office program doesn’t load the add-in, and the Trust Bar displays a notification that the add-in has been disabled.

  • Disable notification for unsigned add-ins (code will remain disabled)     When you check the Require Application Extensions to be signed by Trusted Publisher box, this option is no longer grayed out. Add-ins signed by a trusted publisher are enabled, but unsigned add-ins are disabled.

  • Disable all Application Add-ins (may impair functionality)     Check this box if you don't trust any add-ins. All add-ins are disabled without any notification, and the other add-in boxes are grayed out.

https://support.microsoft.com/en-us/office/view-manage-and-install-add-ins-in-office-programs-16278816-1948-4028-91e5-76dca5380f8d#ID0EBBD=Newer_versions

Additionally, add-ins are considered macros and those should be set to disabled mode. Alternatively if a corp uses macros internally, they need to implement a signing policy for those macros as noted above. Ditto for customer e-mail attachments and they can be added to the Trusted Publisher list.

Edited by itman
Link to comment
Share on other sites

22 hours ago, Marcos said:

It's a dll so it won't run on a replicator.

 

7 hours ago, itman said:

This was no ordinary Windows .dll.

Sorry, there was an unintentional mistake on my part, this file was not downloaded on a virtual machine so I didn't try to run it, but when I got access to one of the virtual machines today, I found that the file couldn't be run, so it wasn't wrong LiveGuard verdict, the file couldn't be run and therefore not There is any suspicious behavior for the file to be judged as malicious .

Screenshot 2021-11-13 060315.png

Link to comment
Share on other sites

On 11/13/2021 at 12:10 AM, AZ Tech said:

I found that the file couldn't be run, so it wasn't wrong LiveGuard verdict, the file couldn't be run and therefore not There is any suspicious behavior for the file to be judged as malicious .

Not exactly true. The file is an executable as all macros/add-in's are. However, it can only be executed by Excel. -Correction- See below posting.

Eset_xll.png.ee407bc3443e936cc6a35b6319839bb1.png

Edited by itman
Link to comment
Share on other sites

2 hours ago, itman said:

it can only be executed by Excel.

As for me, Excel was not installed on my virtual machine, but for LiveGuard I don't know how it run/analyze files in this case.
I expect that what happened was similar to what happened to me on the virtual machine when I tried to run the file (simply did not run), I don't know, but I think so.

Link to comment
Share on other sites

16 hours ago, AZ Tech said:

but for LiveGuard I don't know how it run/analyze files in this case.

Count it as a LiveGuard missed detection.

But I wouldn't be extremely upset about it since Office macros/add-ins are frequently missed by AV software unless a specific signature exists. Hence, the strong warning that they should not be allowed to run in e-mail attachments unless signed by a Trusted Publisher. Also, see below posting as to .xll stand-alone execution capability.

Edited by itman
Link to comment
Share on other sites

  • Most Valued Members
13 hours ago, itman said:

Count it as a LiveGuard missed detection.

But I wouldn't be extremely upset about it since Office macros/add-ins are frequently missed by AV software unless a specific signature exists. Hence, the strong warning that they should not be allowed to run in e-mail attachments unless signed by a Trusted Publisher.

More secure just to disable all macros by default, I find it the most better solution.

Link to comment
Share on other sites

Xll files can be also executed using like methods for .dll's; e.g. JavaScript, rundll32.exe, PowerShell, etc.. See this for further details: https://gist.github.com/ryhanson/227229866af52e2d963cf941af135a52. This technique allows for creating a malicious .dll and running it as a .xll file.

You can disguise that a .xll file is attempting to run as follows:

Quote

An interesting thing about Office, is it will perform file format sniffing for certain extensions, such as .xls, .xlk, and .doc (and probably more). This means that you can rename the .xll to a .xls or .xlk and it will still open. However, the initial add-in warning is still triggered, along with another warning that mentions the file format and extension don't match.

Since the add-in warning shows the full path to the filename, certain unicode characters can be used to mask the .xll extension. One of my favorites is the [Right-to-Left Override Character] (http://www.fileformat.info/info/unicode/char/202e/index.htm). By using this character, you can make the Excel file appear as if it has any extension. For example, the filename Footbaslx.xll would display as Footballx.xls, since everything after the character is reversed.

Edited by itman
Link to comment
Share on other sites

Here's an example of a recent malicious .xll attack:

Quote

Complicating things even further, the malicious XLL file used in this campaign (at the time of analysis) is signed with a valid digital signature and chained accordingly. Signed malware containing valid digital certificates are used by threat actors to evade detection as they are trusted by antivirus and other endpoint security software. Because a company or organization is vetted by a certificate authority (CA) before the issuance of a digital certificate, operating systems and anti-virus software treat files signed with these certificates as clean, which ultimately allows the signed file to operate with impunity. 

https://www.fortinet.com/blog/threat-research/signed-sealed-and-delivered-signed-xll-file-delivers-buer-loader

In regards to @Nightowl previous comment:

Quote

More secure just to disable all macros by default, I find it the most better solution.

Below are Excel's default security settings in regards to add-in's. A signed add-in will run "without a peep" from Excel.

Excel_Add-ins.thumb.png.c0d32b527b64c3859f149c167591962b.png

Edited by itman
Link to comment
Share on other sites

  • Most Valued Members

Yes I just tend to disable all macros in Trust Center, since malware these days can come Signed even by Microsoft.

As they were signing malicious drivers from Chinese developers, I now expect anything from Microsoft.

Edited by Nightowl
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...