Jump to content


Most Valued Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by itman

  1. Check the Eset Detection log for entries associated with this quarantine activity. Post the file hashes from the Eset Detection log entries associated with those two files.
  2. It should also be noted that the above referenced VT link that Eset and Rising detect as a PUA is in reference to the unhackme.zip download. That .zip file contains the UnHackMe installer, unhackme_setup.exe, that is detected by Avast, AVG, Eset, Rising, and Sangfor at VT: https://www.virustotal.com/gui/file/bf51b737b14bc72fb819f2e79f5a8da870848cbb9add1c95f6d26d62cf2551fd/detection . Sangfor detects it as malware. -EDIT- Also the Tencent detailed behavior analysis at VT shows a screen scraper being installed and never uninstalled.
  3. Here's a specific example of what happens when MBAM Premium and Eset's real-time scanning are both enabled: https://forum.eset.com/topic/23826-wmi-provider-crash/?do=findComment&comment=118013
  4. Yes. I found it after enabling Resolved cases. It was submitted to AppEsteem on 6/20/2020 and resolved on 7/5/2020. Eset within their products gives the user options to opt-out of some or all the telemetry and detection data they collect. Bottom line - you can rant to "your heart's content" in this forum and it won't change a thing in regards to Eset's decision on UnHackMe. The only way to do so is to employ proper channels.
  5. I did come across this interesting posting on how other software "doesn't play nicely" with Eset when it comes to WMI: https://answers.microsoft.com/en-us/windows/forum/all/windows-management-instrumentation-causing-massive/4b1bff2e-b2e2-4a44-80bd-114d9c3eb712 Microsoft's recommendation:
  6. Anything WMI related is shown in the below Win WMI Event Log. Win Reliability Montor just shows operational events that are critical in nature.
  7. As far as WMI crashes go, no one has posted any details in regards to the crash. Again refer to this Technet posting: https://techcommunity.microsoft.com/t5/ask-the-performance-team/wmi-common-symptoms-and-errors/ba-p/375483 . Then cross reference error codes in the article to those shown in the technical details for the associated Reliability log event. If this new Eset version was the absolute source for these WMI crashes, everyone would be posting about it. It is possible Eset might be a contributing factor to these WMI crashes but only because previous issues exist in regards to WMI overall fitness status.
  8. UnHackMe is not listed on AppEsteem's Deceptor list unless it runs under a different name: https://customer.appesteem.com/deceptors Perhaps Eset doesn't care for what is in your EULA: https://greatis.com/unhackme/eula.htm
  9. No such reply from @Marcos in this thread to this effect. Where did you see this?
  10. The issue here is not the debate the reputation and methods employed by AppEsteem. It appears Eset doesn't share these same concerns since they are employing their service for software reputation purposes. Your argument lies with AppEsteem; not with Eset.
  11. UnHackMe is not certified on AppEsteem. Solution - get certified. Ref.: https://customer.appesteem.com/home/checklist
  12. Yes. And definitely not recommended since it is Eset's most important off-line scan. To be determined is if ESET in ver. 13.2.15 built in limited registry scanning for this start up scan. Don't believe so since it appears Eset previous versions were already scanning select registry areas known to be abused by malware.
  13. Just checked again on VT and Eset and Rising are detecting UnHackme as a PUA. Looks like my previous check was a VT "anomaly."
  14. Is this related to current COVID-19 situation in California?
  15. Check the WMI crash time event in Win Reliability monitor and compare to time of last startup scan shown in Eset Scheduled Task section. Best to do this right after system startup and when Eset startup task completes execution. If WMI crash time syncs with Eset startup scan time, then we can state Eset startup scanning might be related to your WMI crashes.
  16. The term "anti-malware" is a misnomer these days. Eset protects against all types of known malware including but not exclusively Trojans, viruses, worms, etc..
  17. They were a false positive as far as I am concerned. If you get around to reinstalling the game, search in the registry for references to these .dlls. If found, print a screen shot of the keys they are found in. Depending on how they are used in the registry will confirm my assertion that off-line registry scanning was the source of the original Eset detection.
  18. It depends if uTorrent sets up a Win file association for .torrent files to itself. Then they can only directly be run by uTorrent. On the other hand, the file downloaded might really be named malware.exe.torrent. Unless you had the hidden files setting enabled in Win Explorer, all you would see is malware.torrent. Finally, Eset scans all files on download. File extension use is immaterial as such.
  19. Here's an idea, Temporarily uninstall NOD32. This will result in Window Defender being activated. Then observe if the same Wi-Fi connection disabling occurs after a WD update. Make sure you force a signature update and don't wait for one via the next Win Update check.
  20. The only difference between and Ethernet connection and a Wi-Fi connection is that the network traffic is encrypted; and only for connections between the router and a local network connection device. So whatever is going on during an Eset update to the Wi-Fi based local network device, it appears to be adversely affecting the status of the Wi-Fi router connection to that device. What that could be I really have no idea. This is the first I have ever heard of such an occurrence. I would contact your ISP and maybe they could provide an explanation for this Wi-Fi connection behavior.
  21. A good analogy is playing Russian roulette. The odds of you being shot when you pull the trigger depends on where the gun chamber containing the bullet ends up after spinning the chamber housing. Only thing known for sure is if you keep pulling the gun trigger, you will eventually be shot.
  22. Again, something about the Eset server connection is taking down the Wi-Fi connection. @Marcos is IDS protection part of NOD protection? The activity being described mirrors that of like IDS response behavior where the network connection would be set to block all incoming traffic when an inbound attack is detected. Another possibility is the Wi-Fi router has like IDS protection and it is being triggered for some unknown reason after Eset update activity is completed. Again and of note is this behavior does not manifest on an Ethernet connection. Note that Eset IDS has an Intrusion detection setting to block unsafe addresses after an attack. Assume the Wi-Fi router if has built-in IDS protection performs the same activity.
  23. Refer to the below screen shot. Ensure you mouse click on "Details for Technical Support" first and copy the details shown into your support request.
  • Create New...