carmik

Therefore, how is JS executed in the browser (a very common scenario for infection I presume) handled? Basically, are scripts in a browser passed on to LiveGuard for a check? I presume that it would be very difficult to obtain a meaningful result though, since a browser-running script contains extra context (the browser it is running in, the web page it is running from etc) that can not be passed to liveguard for a meaningful sandbox simulation.

Isn't JS by default executed by the browser? How does chrome, firefox and the new new edge execute it?

I don't have any such information sorry. All users exhibiting this belong to different agencies. The way I see it there is not a single non-malicious site that they all connect to... We also receive a zillion of phishing/spear-phishing emails. In conjuction with my observation about that site I thought it might be malevolent somehow (ie user clicks a link in a phishing email and passes downloads a payload from eu.b2c.com).

Thanks Marcos, just wanted to know whether this is something bad that I should act upon. EDIT: Just curious though, any idea why the extra liveguard checks described in the OP are not performed at all?

On our ESET protect 9.1 installation (latest) we have recently add a LiveGuard license. In any case, casually browsing around the LiveGrid logs it seems like a number of my users tried to visit hxxps://eu.b2c.com/api/init-224mtm6aorewjg83k2h.js This script is different on each access, containing obfuscating code. De-obfuscating the code reveals yet another layer of obfuscated javascript. Now, according to livegrid all is well with this code. I've manually created a .js file with content corresponding to the URL above and it seems like liveguard also sees everything perfect with the code: https://d.edtd.eset.com/details?hash=AC75843E159AE2E64E8AEE7E47ED2DF932231126&key=1647271159477560934&lang=en_US&era_ver=9.1 Checking the result list, shouldn't this JS code when run trigger the "hidden code detection" in liveguard? Or the "fileless threat"? Please advise. I've initiated full scans on the users' systems, but I do know on how to proceed from here...

Thanks for the info Martin, that would explain this behaviour.

Got a ESET VA gradually upgraded to the current version 9.1. From the server info page: [quote] ESET PROTECT (Server), Version 9.1 (9.1.2301.0) ESET PROTECT (Web Console), Version 9.1 (9.1.292.0) Copyright (c) 1992-2022 ESET, spol. s r.o. All Rights Reserved. CentOS (64-bit), Version 7.9.2009 Connected Clients: 167 Active Licenses: 4 Installed Components: Update module 1079 (20211110) Translation support module 1936 (20220727) SysInspector module 1281.1 (20210407) SSL module 1070 (20220608) Push Notification Service module 1128.1 (20220525) Configuration module 2021.1 (20220711) [/quote] I was out of office for around 3 weeks and when I returned I viewed the following in the ESET console: As you can see there is a vast number of systems in a waiting state. I understand that these 120 systems will be most likely stagger-updated. However, being away from way I'd expect that some updates would take place (the 8 systems in latest state, as well as the ones in the latest state agent-wise were manually upgraded by me). How does the auto-update mechanism work? How much time does it take for an update to take place? A note on our server setup: the VA is located on our DMZ. Therefore, if the server directly initiates an update by contacting the client, this will not work...

Not sure about that; if I understand correctly the policies created in parts IV-V of the guide create policies specific to either Windows endpoint or Windows server products, therefore they won't apply to Linux/non-Windows products at all.

Thanks, appreciated.

I was following the instructions under KB8016 (https://support.eset.com/en/kb8016-automate-the-activation-of-eset-liveguard-advanced-with-eset-protect but there seems to an issue. Specifically in part I, step 2 of the instructions the user is asked to "Click Computers, expand Windows computers, click Windows (desktops) → gear..." This is most likely wrong since the instructions in parts V-VI instruct the admin to create a policy and assign it to a dynamic sub-group to the one created in part I, step 2. However that group contains no Windows Servers and therefore the policy will not "find" any windows servers to connect to. It feels as though the proper way to address this is by modifying part I, step 2 to create the "ESET LiveGuard compatible" dynamic group directly under "Windows computers" instead of "Windows (desktops)". This way, the dynamic group created will contain Windows server and ESET file server products...

Hello, I've got an email asking me for auto-renewal of smart security. It was in German and pressed accept by mistake, but I do not understand. Have I been charged with something and if so from where? Was there some subscription in place? How can I find out what is happening and possibly cancel the subscription? No shop was involved, this was an ESET email offer...

@MartinKI am seriously starting to think other AV platforms here, considering all quirks I've been finding and the time I'm spending trying to properly manage the ESET products... Regarding to your points, I really don't understand why two thirds of my clients (and all my clients are the same) did the certificate switch properly and the other third stopped connecting to the console altogether... And frankly I don't care on why this happened, it simply shouldn't. How can I fix this properly with the minimal impact on the use of my work time? I don't care if I have to disable advanced security in the process, as it seems it did more damage than any good.

How can I go about reverting this safely?

Server settings -> Connection: Server Port: 2222 Webconsole Port: 2223 Advanced Security: enabled Certificate: Subject (CN=Server certificate for host *; [SN:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX14201]), Issuer (CN=Server Certification Authority;), Valid from (31/10/2021, 12:00:00 π.μ.), Valid to (31/10/2026, 11:59:59 μ.μ.), Subject Alternative names (DNS:*)

This is a rather strange case: we have had Eset protect 8.1 running as a VA. We decided to update it to 9, but first we enabled advanced security, following the details in https://help.eset.com/esmc_admin/70/en-US/advanced_security.html but without step 10 (ie, without deleting and revoking our old CA and certificates), since there were quite a few clients (on shelf for example) that would remain with the old CA/certificates. All our clients were running 8.1 (either ES or EA). Things seemed to be going ok. Both the server certificate was updated all right as well as a number of clients. Out of around 150 systems, 100 were updated in the first 2 hours or so. This happened on the start of November. Today we noticed though that one out of three clients remain with the old CA/certificates: That would not be a problem if among these 56 systems there were not systems already active. We see the following problems: 1) New systems on which we installed agent (MSI version) with the .ini file containing keys of the old CAs/certificates would not appear in the console. I'm not sure that was supposed to happen, if I understand correctly the policy to replace certificates is still in place... The problem was solved by creating a new .ini (from create GPO or SSCM script) and using that alongside the MSI installer.... 2) Most (if not all) of the 56 systems have stopped contacting our server. So, if I understand correctly, they are unable to retrieve the policy to update the CA/certificates. How do I fix this problem? EDIT: Some additional info: Certification authorities (up old, below new): Going to status overview there seems to be a warning in certificates (might be normal, since the old ones have not been revoked yet), see:

Opened a ticket with local ESET support who stated the same thing, ie you have to either remove the Windows defender role on Windows server, or gag it manually or through gpo...

Glad to hear that we have no issue whatsoever!

Some days ago we updated our eset protect 8.x virtual appliance to 9. Method of update was via task and not via database migration. Today I tried to modify my install task, to have it install endpoint security 9. However, ES 9 was nowhere to be found. Versions from 6.5.2132.6 to 8.1.2037.3 were only offered. I am attaching a screenshot of server version from the web console.

In that case it's not an option I could use. Is it possible to do it via web control? That is, have a specific URL category be blocked without any information (including alert) given to the user?

Wouldn't this disable all alerts, including useful notifications (ie detection)? If so, can I selectively disable only this type of alerts?

Hello, I've enabled web filter, blocking a number of categories. Unfortunately a large number of "xxxxx site is blocked" alerts pop up on the clients. Is it possible to inhibit this type of alerts via the eset protect console? If so, which area of the configuration should I modify? Thanks in advance.

EDIT: correction, defender is disabled but is shown as an active AV application. Defender-provided cloud protection is enabled, as is automatic submission to MS...

Recently we got some Windows Server 2019 Standard boxes, which we fully patched. Afterwards we installed Server Security (currently at version 8.0.12003.0). We've noticed that in windows update we're constantly reminded to install intelligence updates for windows defender. Looking further, Windows defender seems to be still enabled. This happens on all of our 3 server 2019 systems. Shouldn't ESET have registered itself as the security application? How can we fix this?

Thank you for the clarification. One favor though: is it possible to attach here the httpd.conf file of 9.x esxi VA? I'd like to do a diff of what I have with the vanilla 9 VA.

Hello, I've just taken the plunge to update our ESET 8.1 VA to 9. I did not use the recommended method of database pull, too much hassle. Used a components upgrade task in the web console. We do use the Apache HTTP proxy on our VA, and there's a note in https://help.eset.com/protect_install/90/en-US/components_upgrade.html titled "Important instructions before upgrading Apache HTTP Proxy on Virtual Appliance" which states to back up the original httpd.conf (located in /opt/apache/conf). Problem is that no such directory exists. Under /opt there's only "eset", nothing else. I did a wget https://help.eset.com/protect_install/90/apache/httpd.conf -O /tmp/httpd.conf -o /tmp/wgeterror.log but the httpd.conf file downloaded was quite a bit different compared to the existing /etc/httpd/conf/httpd.conf How should I proceed?