Jump to content

0xDEADBEEF

Most Valued Members
  • Posts

    361
  • Joined

  • Days Won

    3

Everything posted by 0xDEADBEEF

  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
  14. Attached is the one with advanced logging enabled eis_logs2.zip
  15. The system is Windows 7. After EIS 12 installation the firewall was shown as disabled and could not be enabled. Reboot and repair didn't help. Attached is the diagnostic log eis_logs.zip
  16. hmmm I feel like this is a false positive
  17. I think the sample I provided (not the one in this thread) is not even obfuscated. I don't know how the scanner actually does signature matching with text files but it is definitely not only the obfuscation's fault. Anyway I sincerely hope that this could be addressed in an elegant way in the near future
  18. I am not sure if the detection from realtime scanner utilizes the AMSI or not. AMSI to me is like AMS to PE scanning, which will only be triggered upon execution. I think the core problem here is to detect what type of script the txt file is in (e.g. js, powershell, or anything else). And this may be non trivial. Apparently there are samples which can even trick AMSI, however here with unobfuscated code the only possible explanation is that the scanner doesn't even bother to check if txt file is actually js or something else. This is what I am thinking The subtle thing here is that if people want to optimize the realtime scan performance with aggressive caching, they had better make sure all possible ways of execution can be guarded to avoid leakage. For example, what if there are 3rd party interpreters that is not going through AMSI? In the old days, people have tried to use some installer's interpreter to bypass the "guards". There are many possibilities here. I was thinking about this before I start this thread. However, it is not an elegant solution, and there may be other possibilities to bypass with similar principles..
  19. https://pandownload.com This has been blocked for quite some time while most other vendors are all showing clean. Is there a reason behind this detection?
  20. even in 1903 this is the case. So apparently AMSI is working fine in 1903. This is the most trivial case and I'd be surprised if this can bypass the protection
  21. for powershell script, I have already given you the answer in the prev replies: Of course I said this after doing the actual experiment. However, it is not always the case (I can enumerate at least 2 other possible ways but I've yet tested them)
  22. See my PM. I'm not going to discuss it here before they say it is expected and acceptable
  23. However in my test this is not the case. My test env is Win10 1903 so AMSI is enabled. I did no source code change to the payload. What's worth noting is that I cannot reproduce the case on EES. Only EIS has such issue. I also uploaded the sample to a webhost to simulate the user download scenario with a different hash, still no luck...
×
×
  • Create New...