Jump to content

itman

Most Valued Members
  • Posts

    12,102
  • Joined

  • Last visited

  • Days Won

    319

Kudos

  1. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    Verify that Log files minimum verbosity level is set to "Informative" per below screen shot;

  2. Upvote
    itman received kudos from New_Style_xd in Eset icon does not appear.   
    When the
    When Eset desktop toolbar icon does not appear, verify that it is not hidden; mouse click on desktop toolbar "^" symbol. If it's hidden, drag it to the desktop toolbar and see if it "sticks" there afterwards.
  3. Upvote
    itman received kudos from New_Style_xd in Eset icon does not appear.   
    Are you stating the Eset desktop toolbar icon does not appear after resume from standby mode?
    Do have Win 10 fast startup mode enabled? If so, does the Eset icon appear when you do a system startup after a prior system shutdown?
  4. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    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.
  5. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    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.
  6. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    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.
  7. Upvote
    itman received kudos from New_Style_xd in More LiveGuard Concerns   
    @Marcos , I am also reverting back to my original theory that there is some issue with LiveGuard file access in regards to locking the download on my device.
    First, note that these script downloads are only a few hundred bytes in size. As such, the download is almost instantaneous.
    Next, the relevant details from my last download test:
    Time;Hash;File;Size;Category;Reason;Sent to;User
    4/12/2022 9:05:43 AM;DBC9B93FBC82DC9BA1772A0668CAA7CAABFDF68D;https://www114.zippyshare.com/d/Sy0TpgxU/5564/test.vbs;392;Script;Automatic;ESET LiveGuard;xxxxxxxxx
    Time;Component;Event;User
    4/12/2022 9:05:43 AM;ESET Kernel;File 'test.vbs' was sent to ESET Virus Lab for analysis.;SYSTEM
     

     
    Let's now analyze this data.
    1. The test.vbs file was created in my Downloads folder 2 secs. prior to the LiveGuard upload activity. Assumed it took Eset local hueristics this amount of time to complete its analysis processing.
    2. 5 secs. after the LiveGuard upload activity, test.vbs shows it was modified. I assume this modification activity was initiated by LiveGuard in an attempt to "lock" the file from access. Something at this point prevented LiveGuard from completing the full file "locking" activity and resultant verdict rendering by the LiveGuard cloud.
    Again, I suspect SmartScreen interference here since it will display a Win popup upon any attempted access to the file that it was downloaded from Internet; i.e. Mark-of-the-Web status.
  8. Upvote
    itman received kudos from fabioquadros_ in More LiveGuard Concerns   
    I am now 100% convinced that LiveGuard processing of suspicious unknown scripts is non-existent.
    This morning I found a web site that was showing code examples for two .vbs scripts that could be used maliciously. Note that the code was shown in clear text and therefore couldn't be directly executed from web site access. LiveGuard upload was triggered by the code in one of the scripts:
    Time;Hash;File;Size;Category;Reason;Sent to;User
    4/11/2022 9:16:36 AM;2AC6C154FA1000AE10D85D4892B79D13763DAB8A;https://gist.github.com/Alekseyyy/6e3569c5b3dfa5eeee60f9f48af58579.js?file=medium.2021.infosecw.vbscript_fun.reboot.vbs;30092;Script;Automatic;ESET LiveGuard;xxxxxxx
    Time;Component;Event;User
    4/11/2022 9:16:36 AM;ESET Kernel;File '6e3569c5b3dfa5eeee60f9f48af58579.js?file=medium.2021.infosecw.vbscript_fun.reboot.vbs' was sent to ESET Virus Lab for analysis.;SYSTEM
    This is "classic" LiveGrid processing behavior I have seen many times in the past.
    First, Eset detection is not "smart" enough to realize that the web page code was shown in clear text and can't be directly executed. Next, Eset's detection of this script code was by signature which I will get to later. The upload to the Eset clould was for notification that a web site was found with malicious code.
    Why do I know that this code was detected by signature? I copied the code and pasted it in Notepad. When I tried to save  the code as a .vbs file:
    Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here
    4/11/2022 9:23:26 AM;Real-time file system protection;file;C:\Users\xxxxxx\Downloads\edtdtestfile\Test.vbs;VBS/Agent.DN trojan;cleaned by deleting;xxxxx;Event occurred on a new file created by the application: C:\Windows\System32\notepad.exe (5B80BBB07B1A84384E61FB3F9366CAD97904EBEA).;2482C486EB9F55C9DD98FEFD55B200B169A75DAA; 4/11/2022 9:23:23 AM
    As far as I am concerned, LiveGuard, as currently designed, will only protect you from unknown, to Eset, suspicious binaries. That is stand-alone .exe's and the like or, the same embedded in another file that can be identified by Eset as such. Note that the procedure Eset recommends for testing LiveGuard functionality is create an e-mail and attach the created test .exe to it. This is as bogus a test that I have seen in a while. Note that most if not all third party e-mail providers will immediately delete any .exe attachments upon receipt of the e-mail by the provider.
  9. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    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.
  10. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    You can add them as an attachment to your next reply. Only Eset moderators can access file attachments.
  11. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    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?
  12. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    Also, locally detected malicious file are sent to the Eset cloud via LiveGrid; not LiveGuard.
  13. Upvote
    itman received kudos from fabioquadros_ in More LiveGuard Concerns   
    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.
  14. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    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.
  15. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    @Marcos, it appears it was the install.bat script that was submitted to LiveGuard on your device. Here's the code in that script:
    This code result;
    cd %~dp0
    would vary based on what device it was executed on. It appears this alone is enough to have Eset determine there is something suspicous about it.
  16. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    I believe I know what the issue is with Eset in regards this RegGuard app download and its local heuristic scanning,
    This app contains dual install/uninstall scripts; one for Win x(86) OS and one for Win x(64) OS. Note that the code within the x(86) scripts is identical to that in the x(64) scripts. It appears that Eset hueristics goes "bonkers" on this. Most likely its running both sets of scripts in the local heuristic sandbox and afterwards saying to itself:
    "Err ......... what?"
    "That can't be; multiple scripts creating/deleting the same service."
    "Definitely suspicious."
    "I'll upload the first of the duplicate scripts I scanned to LiveGuard."
    "But, I won't block these scripts since there is nothing in them malicious."
    The problem here is Eset VirusLab scan won't find anything since there is nothing malicious about any of the scripts uploaded to it. Additionally since not all scripts were uploaded to the cloud, not enough data exists to make a definitive decision.
    The bigger problem here is how the hell does one determine if LiveGuard is functioning properly and as described in Eset documentation?
  17. Upvote
    itman received kudos from Leonardo in More LiveGuard Concerns   
    I will also note that both these .bat scripts have 0 detections at VirusTotal.
    This again leads me to believe that LiveGuard is again operating in "LiveGrid mode" in certain instances. That is, data harvesting activities are being performed for locally detected benign, but potentially dangerous unknown files. If this is the case, Eset should publicly state this.
  18. Upvote
    itman received kudos from New_Style_xd in More LiveGuard Concerns   
    I will also note that both these .bat scripts have 0 detections at VirusTotal.
    This again leads me to believe that LiveGuard is again operating in "LiveGrid mode" in certain instances. That is, data harvesting activities are being performed for locally detected benign, but potentially dangerous unknown files. If this is the case, Eset should publicly state this.
  19. Upvote
    itman received kudos from New_Style_xd in More LiveGuard Concerns   
    It appears that the file was detected as malicious/PUA by one of Eset local detection methods. You should have received an Eset popup detection alert for this download. Check your Eset Detections log for an entry related to this file download.
  20. Upvote
    itman received kudos from New_Style_xd in More LiveGuard Concerns   
    Another point I should clear up is my prior assumption that there was some Eset local suspicious file detection threshold in regards to file submissions to LiveGuard. There isn't one. I have deleted that posting.
    I was reviewing LiveGuard Advanced on-line documentation. It clearly states that if Eset local scanning of the file download is not 100% malicious or safe; and the file has not been previously submitted to LiveGuard via file hash verification; the file is uploaded to LiveGuard for scanning.
  21. Upvote
    itman received kudos from New_Style_xd in More LiveGuard Concerns   
    I finally got LiveGuard to work as expected.
    Yesterday, the software developer whose previously downloads were mentioned in this thread released his production version. Upon download of this version, LiveGuard worked as expected:


    First, note that I had extended LiveGuard verdict rendering time to 10 mins. versus the default 5 mins. when I installed ESSP. Hence, the verdict decision being received from the Eset cloud.
    Next and notable, there were no Firefox downloaded .part file submissions to LiveGuard.
    Three events have transpired prior to this current Firefox download:
    1. Firefox updated to ver. 99.
    2. An Eset module update occurred to ver. 15.1.12.
    3. I set existing Firefox setting entries in the Application section to their default values:

    At this point, I believe that my prior Application entry settings were the cause of this issue with LiveGuard functioning properly. Why I don't know. But modification of browser file download behavior should not impact LiveGuard functionality.
  22. Upvote
    itman received kudos from micasayyo in Where is Eset in the AV-TEST test?   
    Most commercial concerns IT auditing sources require that an AV product be certified by a major AV lab.
  23. Upvote
    itman received kudos from micasayyo in Where is Eset in the AV-TEST test?   
    As far as A-V Comparatives test reports go, the one to review is their annual summary report: https://www.av-comparatives.org/tests/summary-report-2021/ . This report summarizes all individual comparative tests performed during the year.
    As far as the Advanced Threat Protection (ATP) test goes, both Eset and Kaspersky were awarded silver level awards.
    Of note is where Microsoft Defender was ranked.
  24. Upvote
    itman received kudos from Mr_Frog in Where is Eset in the AV-TEST test?   
    I will note this about the major AV labs tests.
    With almost all tested AV vendors scoring 98% or better on the real-time tests; the minimum certification score is 98%, no one on the web security forums pay any attention to them anymore. It is somewhat obvious that if these tests reflected the real world current status of malware detection, no one would be getting infected anymore.
    The only AV lab test I put any trust in anymore is the testing done by AVLab in Poland who BTW is not an AMTSO member. Unfortunately, Eset no longer participates in their periodic test series.
  25. Upvote
    itman received kudos from New_Style_xd in Where is Eset in the AV-TEST test?   
    Most commercial concerns IT auditing sources require that an AV product be certified by a major AV lab.
×
×
  • Create New...