Jump to content

itman

Most Valued Members
  • Content Count

    6,245
  • Joined

  • Last visited

  • Days Won

    173

Everything posted by itman

  1. This is normal and expected behavior when the Eset default SmartScan profile is used. These files are locked by the OS and Eset cannot scan them. If you wish to minimize this behavior, perform a Custom scan as Administrator. Files will show show as locked but there will be fewer of them showing this status.
  2. This has nothing to do with Eset. As the above posted description text clearly shows, it is a browser issue. Namely, the browser is allowing SHA1 connections. This can be corrected by removing the ciphers associated with SHA1-intermediate which involves a registry modification.
  3. Refer to the below screen shots. Substitute the shown Local 192.168.0.0 address for the DHCP assigned IP address for the local device you wish to block outbound echo reply activity. If you want to be notified about block activity, check mark the "Notify user" setting. Move this rule above any existing Eset default ICMP rules that exist.
  4. Appears this a bored "script kiddie" due to COVID-19 lockdown that copied a much more virulent "living of the land" attack which "blew through" a whole bunch of AV solutions when it was in-the-wild since it employed a UAC bypass. Unless UAC was set to max. level which most users don't do, the escalation level to admin would have been hidden and done silently. The original ref. to CertUtil abuse dating to 2018: https://www.bleepingcomputer.com/news/security/certutilexe-could-allow-attackers-to-download-malware-while-bypassing-av/ Tip:
  5. Refer to this thread: https://forum.eset.com/topic/23227-what-good-is-a-reputation-scanner-that-doesnt-provide-reputation/ I would allow the action since I believe its related to a recent Office update. If additional issues arise afterwards, restart your device and see if the issue resolves itself.
  6. I can't. As previously posted once I killed the process and rebooted, the issue resolved itself. The SHA1 I previously posted is for the OfficeClickToRun process that now runs with good reputational status. Likewise any decent malware will delete its payload after doing its dirty work to prevent discovery.
  7. I am going to post two Eset reputation examples to help "demystify" it processing. The thing to note initially is both these executables are code signed. First up is a HP monitor driver installer. I chose this one since it is rarely used: As shown, Time of discovery shows Unavailable. This confirms as previous posted that Unavailable means that the process has never been previously seen by the Eset user community. Next is O & O ShutUp 10 which is a widely used process that changes Win 10 default telemetry settings: So why does the HP installer show good reputation and O & O ShutUp 10 show a reputation status barely above the unknown reputation status? Both processes are code signed as previously noted. It pertains to Trusted Publisher status and the type of code signing certificate used. HP is a Trusted Publisher and the code signing certificate used is an EV status one issued by Digicert. O & O Software is not a Trusted Publisher and the code signing certificate used was a non-EV one issued by Symantec. Now back to my original posted LiveGrid reputation running processing screen shot in regards to the highlighted OfficeClickToRun process. No reputation status is shown along an Unavailable Time of Discovery status. Any process starting in a like status needs an alert issued by Eset reputation processing stating a process is attempting to execute for which reputation status could not be determined with Allow or Block execution options available.
  8. Specifically, echo reply is only allowed from devices in the Trusted Zone; i.e. local subnet. Alternatively, you can manually create an outbound firewall rule to block echo reply from a specific device. Then move that rule prior to any existing default ICMP rules.
  9. Looks like you ignored by previous recommendation. As posted above, this option resets your Windows installation to default settings. The problem with this option is it has no way of recognizing any previous manual modifications you made or those made by specialized utility software you might have run to do the same. For example, Windows System Restore settings. I for one have multiple drives installed on my device. I only want my OS installation drive to be backed up via System Restore. I modified System Restore configuration settings to reflect this. If I were to use Eset's Reset feature, it would reset System Restore back to its default setting to backup all my drives. The problem with Eset's Reset feature is: 1. It doesn't show what settings it has detected as modified. 2. It provides no granularity capability to selectivity set what settings that should be reset to default settings. Again, this Eset Reset option is only supposed to be used after a malware infection where the likelihood is high that Windows settings have been modified by the malware.
  10. Have you tried to duplicate this outside of Banking Payment & Protection mode and observe if the same behavior manifests? For example, navigate to the same web site and enter "45..." Or, open Win Notepad and see if you can duplicate it in a new document. Do you have any other anti-keylogger software installed such as KeyScrambler?
  11. Leave that area alone unless instructed otherwise by Eset technical support. Eset wants to collect product use and performance data about its installations. If you're uncomfortable with this, simply disable the option.
  12. One other detail about the OfficeClickToRun.exe process that shown as unavailable per LiveGrid running processes feature. When I clicked on "Details" about it, nothing was shown. This was odd since my posted Process Explorer screen shot clearly shows the source path associated with the .exe. This indicates to me that process identity data retrieved by LiveGrid was being thwarted in some fashion. Now for this "Not available" status. There is nothing mentioned about this status in any Eset published documentation I could find. I assume when Eset classifies a process as "Unknown," that is based on some reputational factors such as signing status, Trusted Publisher status, and Eset white and black list status. In other words, overall the process looks "legit" but hasn't been discovered yet by existing Eset installations. Not available status on the other hand implies that Eset can't even establish enough information on the process to determine if it is legitimate to mark it as unknown. As noted by @Marcos , not available status is commonly assigned to unknown; i.e. 0-day, malware. Therefore, it would appear to me that the prudent method for Eset security software to handle this is to alert the user that a suspicious reputational status process is attempting to execute.
  13. My theory on this is as follows. The previous Office update for some unknown reason didn't fully complete. This left the file is some type of altered state as evidenced by the child process spawned. I have never seen that process running previously although it is legit and resides in the same directory as the parent process. Once I did a system restart, the issue resolved itself. I am using Win 10 fast boot and had not restarted the system since this update occurred. My reasoning here is that something Eset-wise should have alerted that this process was in an altered unrecognizable state.
  14. VT shows the following as far as creation and signature date: Creation Time 2020-03-30 04:28:58 Signature Date 2020-03-30 05:31:00
  15. That's not the case here. Per the below screen shot, the same file shows reputation with a discovery a week ago. Additionally, I killed the prior shown instance of the this process and associated child process prior to my first posting and after reboot, the same below shown reputation was established.
  16. That is exactly what happened in regards to a process evaluated by LiveGrid today. See below screenshots. Not available? Is not the whole purpose of a reputational scanner to determine just what the process status is based on known reputational factors Eset employs? If this status means submitted for analysis and under review which I most certainly hope it does, it should state just that. On the other hand, I log such LiveGrid submissions and none exist in my Eset event log. Now I fixed this process issue myself and believe it was related to a recent MS Office update. However stuff like this reinforces my previous belief that LiveGrid's sole purpose is for uploading suspect unknown processes, maybe if that works properly, and has nothing to do with evaluating overall process real reputation status.
  17. Next time the Eset PUA alert appears, check mark the "Copy to Quarantine" box prior to mouse clicking on the Block tab. If the alerts persist, you will have to manually exam all your existing Chrome extensions and remove the one causing this behavior. The way this is normally done is to remove all extensions. Then re-add them one by one until this adware manifests. This last added extension is the one causing the the adware behavior and then must be again deleted. Repeat the prior processing until all your previous extensions have been re-added. It is also recommended that Chrome be reset to default settings.
  18. What I did notice is that Medal of Honor (2010) can be downloaded from the publisher: https://www.ea.com/games/medal-of-honor/medal-of-honor for $4.99 versus Steam's price of $19.99. So they might only be hosting cracked software but grossly overcharging to boot.
  19. I forgot about the DRM aspect. And that very well might be the crack Eset is detecting. Medal of Honor (2010) indeed has it for online activation: https://www.pcgamingwiki.com/w/index.php?title=Special:Ask&offset=100&limit=100&q=[[Category%3AGames]]+[[Uses+DRM%3A%3AOnline+activation]]&p=format%3Dtemplate%2Ftemplate%3DDRM-20list-2Frow%2Fintrotemplate%3DDRM-20list-2Fintro%2Foutrotemplate%3DDRM-20list-2Foutro&po=%3FDeveloped+by %3FPublished+by %3FRelease+date %3FAvailable+on I would contact Steam and see if they can shed some light on what is going on here.
  20. Then that's a lot better situation. The only Warning 1014 log entries I ever received on my Win 10 1909 build are for wpad timeouts at logon time which I have seen every since I have been on Win 10. I really have no clue why these Eset related Win Event log entries would be created on your build. It might be related to the DNS provider you are using.
  21. Clear the update cache as shown in this article: https://support.eset.com/en/kb3189-resolve-modules-update-errors-in-eset-windows-home-products Check if that eliminates the Win event log entries. BTW - did you verify that Eset is not actually updating? That the issue is just Win Event log related?
  22. Again using command prompt window and the IP address returned via previous nslookup, ping that IP address as shown in the below screen shot. Reply should be almost instantaneous.
  23. To begin, we are talking about 10 year old game software. Like software is notorious for "dodgy" behavior. AML which also monitors API call behavior sees something it hasn't been previously trained for. A fair assumption since we are again talking 10 year old software which is a "stretch" to run on Win 10. It in turns passes control to deep behavior inspection for a "look see." DBI is now running outside of normal context w/o LiveGrid analysis feedback. DBI sees API behavior related to cracking activity. Again we are talking about 10 year old game software that may indeed be using such in regards to anti-crack protection. In reality only the game software developer really knows what is going on but I believe the previous scenario is a reasonable one.
×
×
  • Create New...