Jump to content

carmik

Members
  • Posts

    156
  • Joined

  • Last visited

Everything posted by carmik

  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.
  13. Marcos, this was a sealed ESET package, not an electronic key. I will provide you with the details over a PM.
  14. I'm sorry, I was not provided with a public ID upon purchase, just a license key...
  15. Hello @Marcos, on a related context I've got a multi user license similar to the one described here, that I am unable to activate. According to the installer it is already expired, although I recall that I have never used it. This license was bought from Amazon if I recall correctly two years ago and I'm unable to figure out who to contact... Would it be ok if I contacted you with the license key and my details? Thanks in advance!
  16. I'm sorry I had to try some things to return the pc to its user. What I did was disable the antivirus protection, which seemingly disabled both eset and defender. Then I enabled eset only and it all looked well.
  17. EDIT: by "... I'd appreciate if there is something on powershell or script I could push to a system to take the least time needed to do that" I meant if there is some powershell command to cleanly disable windows defender.
  18. I have a Win 10 system on which for some reason Windows Defender is still fully active, even though endpoint security 8.1 (centrally managed by eset protect) is installed and running correctly. Is this a known issue? This is the 2nd time I'm noticing something like that. The first time I uninstalled and re-installed ES and that took care of disabling defender. This time though I'd appreciate if there is something on powershell or script I could push to a system to take the least time needed to do that. Plus, target all my systems at the same time.
  19. I'm sorry, I can't really suggest something here. I've not looked into dedicated/paid solutions in the past 3-4 years (my experience with fortiguard is before that time, using a small UTM for the purpose). Shalla is available at at hxxp://www.shallalist.de/faq.html although obviously one should look for the terms and conditions. It has a quite grained categorization and includes not only domains but URL regexps as well. It does the job much, much better that the current ESET filtering. Like I said, I'm certain that this job can be performed better. It's not only me that is interested in eset being a better product; it's mainly the eset company by itself!
  20. Thank you for tackling this faster than a bullet. I was under the impression that this sort of categorization is community-driven in a way. That is, users might upload specific sites to specific categories, or tag them in multiple categories. Which can be subjective. Now, as for the test cases discussed, I might agree with you about boro.gr. But I do disagree about daniilidisbio.gr. This is a site that offers plants for biological farming. Food refers to something you can eat, and this is not what this site is about. The farm owner basically ridiculed us today because his site was not accessible to our government agency. The fact that the site contains a small number of references to fruits does not imply that this is about selling food. You did not mention the iatronet.gr site, which contains medical related information. It does contain some news, but it is not the site's core function. Therefore if your AI thinks it is, then perhaps you should try to do something here. I have three "solutions": either block only pornographic sites, downloads/warez and basically red-flagging sites, avoiding blocking categories that will effectively carpet bomb sites not belonging there or do a whitelisting of everything ending in *.gr (allowing bad material from *.gr to creep in), followed by blocking whatever we are blocking right now... get rid of ESET web control which does not work as it should and tender for something that can accomplish the task better (see my notes below) I can not really offer a huge technical help on how you should go about reducing the site false positives. You might believe that your product works well and does its job properly. My own experience with our users on classification as performed by other products (Fortigate comes to mind, as well as the community-as-a-service driven Shall squidguard URL lists) makes me feel that eset web control is unusable for broad business application here. Will most likely go with (2) above for the time being, that is if ESET allows a top level domain (.gr) to be whitelisted.
  21. Sure, I've just communicated to ESET Greece the following links: https://boro.gr/31192/sxizofreneia-ta-prwta-symptwmata-kai-oi-kindynoi/ https://www.iatronet.gr/ygeia/psyxiki-ygeia/article/27098/sxizofreneia-poia-symptwmata-prepei-na-mas-anisyxoyn.html The latter site contains medical information, the former get-well/fitness related information. Both links were categorized as "news". ESET Greece changed these to "health"/"magazine". An example logged just some minutes ago:https://www.daniilidisbio.gr/ This is the site about farming: plants and varieties. This was logged under "food and restaurants". The case open with the local ESET distributor is 64499, hope that helps.
×
×
  • Create New...