Jump to content

itman

Most Valued Members
  • Content Count

    6,740
  • Joined

  • Last visited

  • Days Won

    178

Everything posted by itman

  1. It appears this module relates to Eset's real-time scanner. Have you tried to create a real-time exclusion for this Advisor app?
  2. There also appears to be a problem with the Microsoft Bing servers that has cropped up today. Don't know if this could be related to this issue in some way.
  3. Have you checked your Eset log files to determine if Eset is detecting this plug-in file or anything else associated with this Sarine Advisor software as malware or the like?
  4. I for one have previously posted a modification recommendation to existing HIPS learning mode processing that would only create startup rules for existing processes versus recording every activity a process is performing. The later in effect makes overall HIPS rule review unmanageable. One of the problems with whitelisting is to be effective it is hash based. Given the frequency of OS and app updating, maintenance of whitelisted processes is problematic. Trusted Publisher exclusion capability is not secure since it is certificate based and well, it really can't be trusted anymore these days.
  5. Hum ........ A bit puzzled here. EIS/ESS Windows consumer versions have a default firewall that exists at the top of the rule set titled "Allow all traffic within the computer." This rule allows all inbound and outbound traffic to/from remote destination "Local addresses" zone. This zone by default on Windows installations contains IPv4 and Ipv6 localhost addresses; i.e. 127.0.0.1 and ::1. I would assume this default rule also exists on EES? Appears from the original posting, you want to access localhost addresses other than those noted above. Best way to do this would be to create a new firewall zone named whatever you desire. Specify in that zone 127.0.0.1/x and ::1/x; where "x" is the appropriate CIDR notation for the localhost ranges you want to reference. Or alternatively, only specify the individual localhost addresses you use. Then create a new firewall rule duplicating the details of the above noted "Allow all traffic within the computer" but specifying the new zone name you created in the remote destination rule area. Move that new rule to the top of the existing rule set. By using a Zone specification, you can add/delete IP addresses at needed without having to modify the new firewall rule. Below is a screen shot of the existing Eset Windows "Allow all traffic within the computer" rule:
  6. Is this a commercial or consumer installation? If commercial, I believe the appropriate Eset product would be either Eset Endpoint Antivirus (EEA) or Eset Endpoint Security (EES). The commercial equal to NOD32 is Eset Endpoint Antivirus. Note that EEA or EES have minimum license seat requirements. Neither are available as single license puchase option.
  7. If Eset couldn't detect the ransomware and it executed unimpeded, there is in all likelihood no code present to decompile. Most ransomware will remove its code after execution leaving only the ransomware note. Also only low-level ransomware would leave its encryption key on the targeted device.
  8. Microsoft added Tamper Protection in Win 10 1903. Oddly, it has to be manually enabled. I keep looking for a published bypass if it, but so far so good for Microsoft. It also appears to "have held its own" against the latest and greatest version of Trickbot which tried its darnedest to disable it: https://www.bleepingcomputer.com/news/security/new-trickbot-version-focuses-on-microsofts-windows-defender/ Such can not be said for MalwareBytes or Sophos.
  9. This one has been bugging me for a while. Eset HIPS default behavior for ask rules that have not received a user response is allow. This is the only HIPS I have used where like default behavior is not block. Before I get into my suggested enhancement in this regard, overall I agree with Eset's approach. It is designed to prevent a user from creating an ask rule that due to; Eset GUI not fully initialized at boot time Non-response due to user physically not present at device that could inadvertently lead to critical system/app function being blocked leaving the system inoperable. However, the fact remains that the default allowed activity could have been malicious or suspicious in nature and needs user review. I therefore propose the following HIPS enhancement as far as default allow ask rule activity: 1. All such ask rules are logged in the HIPS log. 2. Eset display a non-expiring desktop alert that such default activity has occurred. At boot time, this could be done after the Eset GUI is fully initialized. The alert does not have to more than a notification that such default behavior occurred. This would alleviate one constantly reviewing the HIPS logs for such activity assuming he previously set logging to the correct level to capture such default activity.
  10. Could you please elaborate on just what this means? For me, it means Eset didn't fully handle the threat and further user action is required. I asked this same question in another thread and really didn't receive what I consider a full explanation. In my case, it was a web based browser javascript detection; ref. here: https://forum.eset.com/topic/17986-detected-threat-shows-in-red/ . The alert Eset generated states "Threat removed" and "The file has been cleaned." Also there is no required user interaction for the threat. I interpret this to be the threat was fully mitigated by Eset. Is this a correct assumption? If so, why are the threat detections shown in the Detected Threats log as red versus yellow? -EDIT- I always forget that that I have "strict cleaning" enabled for all realtime ThreatSense selections other than for PUA. So it appears that "red" indicates Eset detected and removed the threat without performing any further activities such quarantining it, displaying user threat handling options, etc.. So in essence Eset didn't "handle the threat," it wiped it out instead.
  11. This is an English language forum. Please post in English if you expect to get any replies.
  12. What you could do is temporarily set your default browser to IE11. This will result in Eset's BP&P opening in IE11. Navigate to the Chase and Discover web sites you noted previously. If you get no Eset web cam alerts, it can be assumed the issue is related to Chrome. Why this web cam behavior appears to have started after your hardware changes, I really have no clue. I can't see how a NAS device would in any way influence web cam behavior.
  13. Suspect this might be related to Chrome web cam issues noted in this thread: https://forum.eset.com/topic/16852-smart-security-premium-webcam-access-notifications/?_ These won't be fixed until vers. 12 is released as noted by @Marcos.
  14. Add option to realtime scanner to block obfuscated Powershell scripts. Option would be dependent upon Win 10 AMSI option enabled in the Eset GUI. Justification Microsoft added a like mitigation in the form of a Windows Defender Exploit Guard ASR mitigation effective with Win 10 1709. ASR mitigations are only effective if Windows Defender is enabled as the realtime scan engine. Further justification is Eset's failure to detect malware in highly obfuscated PowerShell script in a Malware Research Group ad hoc test: https://www.mrg-effitas.com/research/current-state-of-malicious-powershell-script-blocking/
  15. Add a column showing PID number in the following logs after the noted existing log column headings: 1. HIPS - Application 2. Network - Source This is necessary to properly identify the origin for multiple same process occurrences such as svchost.exe.
  16. The only startup program via registry means I am aware of is for the Eset GUI desktop taskbar icon as show in the below screen shot. It has been so as long as I have been using Eset. I suggest you download SysInternals Autoruns which will show you all possible startup locations which processes can run from:
  17. I also have suggested at the minimum to create an option to allow default Win firewall outbound rules and alert for any other outbound traffic. This would get around the problem many have in creating outbound rules for Win 10 Microsoft package apps.
  18. This HIPS issue has been "bugging" me for some time. I keep cmd.exe execution "under tight reins" so to speak with a number of HIPS rules to monitor what it is doing. However, I have .bat scripts that I schedule via Win task manager that I want to run at boot time. What I really need is an option in the HIPS rule creation where a command line string could be specified for rules pertaining to cmd.exe. It appears Eset can fully decipher the entire command line string as noted by the below screen shot. My suggestion would be to add an input box to the existing Eset GUI HIPS app rule screen titled "Command string." The HIPS could then concatenate this data for any rule where the target app being monitored is cmd.exe and compare it to the full commandline attempting to execute:
  19. It actually used to do this prior to ver. 11. I believe this has something to do with Microsoft's decree to AV vendors that they can't interfere with the boot process in Win 10 ver. 1709. I am actually surprised that Eset even processes an Ask HIPS use in ver. 11 and instead, just auto allows it. I know it is doing so because it will slightly delay your boot time; something I though wasn't supposed to happen on Win 10 ver. 1709. Again it is a bit peculiar that the HIPS default action is allow. However, it always has been this way. To be honest, I seriously doubt Eset will change it to block mode. A proper frame of reference for you is Eset first and foremost created the HIPS for its own internal use. As such, it really isn't designed to be user configurable other than to create a few exception rules. This is more so evident in the retail vers. of Eset. For example, Eset added file wildcard capability a while back for the Endpoint vers. but refuses to do so for the retail vers..
  20. I explained this once to you. Eset has internal default rules and those rules take precedence to any user created rules. Also if an alert response is not received within a short period of time, Eset will auto allow the action. This comes into play for example with any ask rule that might be triggered during the boot process. Those will be allowed by the time the PC initializes, the desktop appears, and finally the Eset GUI is started.
  21. Nvidia in their "infinite security wisdom" created two .bat scripts they dumped in C:\Windows directory. Their startup service can run these .bat scripts if errors are encountered in their software as recovery procedures. So basically, you have to allow svchost.exe to run cmd.exe. Not the most secure thing to do if malware creates a malicious service. Hence my recommendation that file wildcard support is needed. There is also the issue of why the HIPS hasn't been updated to reflect Win 10's current ability to uniquely identify an individual svchost.exe service by process id.
  22. You need to be more specific on what you are trying to do. Give an example. One issue I have in regards to the cmd.exe is that there is no way to restrict what .bat files it can execute. A "target" in a HIPS rule has to be an application - period. This could be accomplished if the HIPS provided a read restriction in the Files section. I really don't know why read restriction capability was never added. Every other HIPS I have used in the past had the capability. I will also add that file wildcard capability which I have repeated asked for needs to be added to make this capability functional. The following is example rules. 1. Allow cmd.exe to read xyz.bat. 2. Block/ask cmd.exe to read C:\*\*.bat; where C:\* would mean the drive root directory and all subdirectories.
  23. Yeah, I know about this. Just be careful with GitHub software. Being open source, it can be hacked. One of the major sources of nasty backdoors has been GitHub software.
  24. As far as anti-exec processing, there is a one built into Win 10 - native SmartScreen. I have tested with a couple of unknown reputation files and each time got an alert from it when they tried to run. Eset let the files run w/o issue. Neither file was malicious but I prefer an option to disallow execution in this instance. The downside is native SmartScreen relies on "The Mark of the Web" remaining associated with the downloaded file. There are ways to "strip that off" of a download.
×
×
  • Create New...