Jump to content

0xDEADBEEF

Most Valued Members
  • Posts

    361
  • Joined

  • Days Won

    3

0xDEADBEEF last won the day on June 5 2018

0xDEADBEEF had the most liked content!

1 Follower

About 0xDEADBEEF

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    USA

Recent Profile Visitors

2,542 profile views
  1. I feel many open sandboxs' malicious rule matchers are dumb. You can throw in a slightly modified ccleaner and it will also trigger many "malicious behaviors". Here it is just the driver file that gets detected by the scanner. The original installer is just a game downloader, after you install the downloader and download the game, the driver will be released to the installation directory and get quarantined by the scanner. There are indeed "legitimate" drivers using weird ways to achieve some questionable goals, and sometimes those even make system vulnerable to rootkit infection. I am not sure what's the issue in this file though.
  2. Decided to post here because this has already been reported to the eset's lab email for several days but it has not been processed (or at least, the FP is still there). password: "infected" the driver is from the installer downloaded here: https://honkaiimpact3.mihoyo.com/asia/en-us sample.zip
  3. Yes, so if I empty the quarantine, re-add 1~2 malware to it, and open the quarantine in egui, the UAC prompt won't happen. That's valid, but still certain cases will have output encrypted files quarantined (usually if detected by AMS and failed to clean the main process). Just want to see ESET being robust in handling such extreme but possible cases.
  4. not necessarily. It is not the first time that I saw ESET move thousands filecoder encrypted files to the quarantine, and those can exceed GBs (and users definitely don't want to empty the quarantine in this case). In other cases I once saw that the ransomware may repeatedly release thousands of ransomnotes because ESET repeatedly move it to the quarantine. In such case the quarantine will be "broken" unless the user manually empty that directory. I think the bottom line is to add a load progress bar so that users are not confused. Plus I don't think repeatedly prompting UAC is considered "normal" when handling a large number of entries/large files.
  5. I have found a way to reproduce this issue. After emptying the C:\Users\%user%\AppData\Local\ESET\ESET Security\Quarantine, the quarantine page is back to normal. After re-copying the quarantine files back, the same UAC issue appeared. I have sent you a private message containing those quarantine files. I hope those can help the devs identify the bug. Previously I've heard similar complaints about "bugs" in quarantine and log files: when there are too many entries in these sections, using egui to view them will display blank page. The solution is to empty them.... In this case, my quarantine is pretty large (> 2GB). I feel the QA may need to do some tests to cover such extreme cases.
  6. my bad.. this is actually set to "prompt for credential" Turning this two options back to default didn't help though...
  7. Yes, I am using admin account. This is the weird part. The only non default setting on my computer: 1) UAC level is set to the highest 2) Local security policy - UAC Behavior of the elevation prompt for administrators in Admin Approval Mode is set to "Prompt for credentials" But I don't think these two will cause this issue.
  8. System: Windows 10 Pro x64 EES Version: 7.2.2055 When trying to access the quarantine, a UAC prompt will show up (eecInt.exe). However, after granting the UAC elevation request, the quarantine page is still blank. Meanwhile the UAC elevation will prompt indefinitely. Not sure what kind of diagnostic info I should provide to help debug this issue.
  9. theoretically ESET should have update/livegrid servers in the "wall". So I guess this is more of a routing logic issue within the product. Previously users there try to modify host to force redirect the update server to the local ones. However I believe this had better be eventually fixed by ESET...
  10. I am submitting this issue on behalf of some Chinese user. I myself don't have any update issues. Yes, for large ISPs like China Telecom the update is OK, that person is using an ISP called Great Wall Broadband Network and had trouble accessing the server.
  11. It is about ISP connectivity. The update can work but with high chance of failure during the download process. This issue has been there for some mainland Chinese users with certain ISPs for years. I've heard numerous users there in the past complained that they had difficulty updating the virus db (the download being extremely slow or the download failed in the middle) or connecting to Livegrid. That's why I am providing the network dump here.
  12. Someone has reported that he had difficulty accessing ESET update server for quite some time. He has provided pcap trace for ESET to optimize the server and routing logic. Hopefully ESET can address this issue asap. The download link and download password are attached here pcap_trace.txt
  13. Someone encountered BSOD potentially induced by ESET. When download files in the virtual machine, the BSOD occurs after some time. After turning EIS monitoring off, the BSOD won't happen. The dump is attached here dump.zip
×
×
  • Create New...