Jump to content


  • Posts

  • Joined

  • Last visited

About carmik

  • Rank

Profile Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Marcos tested with Firefox 92 (64-bit), normal installation made via group policy. Downloaded cloudcar.com from https://amtso.eicar.org/cloudcar.exe Furthermore, the downloaded file was intact. It was when I right-clicked on it and selected to demand-scan it that it got detected and quarantined: However, right now it works just fine (crazy)! That is, I immediately got a "suspicious" window and the download of eicar.com ended up with a zero-length file! This lack of consistent defense does scare me. But the fact that I can not reproduce the issue is problematic. Would current logs of the pc in question have any decent information that would help, or should extended logging have been enabled beforehand?
  2. Was looking into something policy-related and ended up checking whether livegrid works/is enabled on our 8.1 endpoint clients. AFAIK, both livegrid as well as tls filtering are enabled. So I ended up at this test https://support.eset.com/en/kb5552-enable-or-disable-eset-livegrid#TestLiveGrid where for various reasons I could not test (regular HTTP) hxxp://amtso.eicar.org/cloudcar.exe but I could test secure http https://amtso.eicar.org/cloudcar.exe I was able to download the latter just fine!!! Which is a twofold surprise for me: first, why didn't the web filter block this download in the first place? Second, why didn't saving the file to disk trigger the on-access tagging of this file as malevolent (even though I think that eset scans on read access and not on write access by default). Any ideas why this happens? For the record, all options regarding live grid are enabled and all options regarding TLS scan are also enabled:
  3. Ok, back at work. The scenario is this: we have a Checkpoint VPN software that does not run well under Windows 10. In order to be able to actually utilize it successfully, a user has to start internet explorer as an admin. This is problematic as you can understand, since this opens a full can of worms. So we've been instructed to follow this approach: install powertoys and create two scripts. One that launches internet explorer named script.cmd: elevate "C:\Program Files\internet explorer\iexplore.exe" And one that resides on the user desktop, named vpn.cmd: runas /user:local_admin_user /savecred "cmd /c c:\path\to\script.cmd" So the user runs vpn.cmd, which in turn starts cmd to execute script.cmd. Hope this makes sense now. The bug (if it is one) is that admin block rules in the eset HIPS policy seem to be case-sensitive, regarding the name of the application used!
  4. elevate "C:\Program Files\internet explorer\iexplore.exe" itman the issue is that the allow rule for the action above does not match the same command when "internet explorer" above is written as "internet Explorer".
  5. Not sure if this is a bug or not (I think it is though). Got a number of Endpoint security 8.1 boxes on which I've loaded the KB6119 HIPS policy. Since I had a script that starts Internet explorer, I made a new policy to append a rule that allows wscript.exe to start C:\Program Files\internet explorer\iexplore.exe (note especially how the underlined part is written). For the record, the script is named script.cmd and contains: elevate "C:\Program Files\internet explorer\iexplore.exe" This worked on a couple of systems. However, I was receiving HIPS alerts from other systems. Upon closer inspection the problem was that in the scripts used in those systems, I had written script.cmd with different casing in the words internet explorer, ie: elevate "C:\Program Files\internet Explorer\iexplore.exe" It seems that the HIPS rule differentiates between these two cases, although it shouldn't (as far as I know, Windows file system names are case insensitive, therefore the first rule should match the 2nd case as well. Can someone from ESET check if this is an issue indeed, and, if so, provide a fix?
  6. @Marcosthank you for your intervention. ESET support replaced the key with another one! Much obliged!
  7. Very interesting! Have to ask: how did you isolate this task. That is, how did you go about investigating the cause of this?
  8. Two thirds of my systems are dell optiplex desktops, whereas the other third consists of HP desktops. No dism so far...
  9. That's understood. However, in my setup it's not one or two systems generating alerts, but about half of my installed base, meaning I'd have to disable the rule completely until finding a way to tune it somehow. Otherwise, this policy defeats its merits, at least on my installation. For example, I was blocked while interactively starting installation of the Microsoft windows installer cleanup utility (blocked wscript).
  10. @Marcos I've been communicating with Amazon. Due to the time passed they can not provide a refund, but they've provided an email statement that the license is defective. Due to the personal information enclosed, I'll be passing this to you over a PM.
  11. @PuterCareI'm running into some similar issues, as outlined in If you manage to find something that actually helps you here, please drop me a line!
  12. I've imported and applied an ESET-provided HIPS rule to our LAN clients, as per KB6119. After doing so I'm bombarded by the following event types: C:\Windows\System32\cscript.exe trying to start C:\Windows\System32\cmd.exe C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe trying to start C:\Windows\system32\ipconfig.exe C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe trying to start C:\Windows\System32\Conhost.exe This behaviour seemed similar to the one described in: However, my own clients are normal PCs which are not connected to AzureAD but rather to our local AD servers (2019). Around 30 out of 120 systems are triggering this policy at the moment. Since I have just applied, I expect this figure to rise. I must say though that this policy has not been triggered on any of the IT stuff client systems. Which is a bit worrisome, suggesting that this might be something more than false positives. I'll try to raise logging level as per the thread above, but I'd be grateful if someone could provide better instructions on how to do it.
  • Create New...