pronto

Okay, thanks for the effort. The setting is not a matter of life or death but as a nice to have it would be great... Thx & Bye Tom

I am not sure if this is the right place. It reads that way but as soon as I edit this notification it ends up asking me if I want an email, use a syslog server or send an SNMP trap. Actually, none of them. I was only referring to the colored background in the 'Last Connected' column in the Protect console and that doesn't seem to be what I'm looking for. But it would be close.... Thx & Bye Tom

Servus Community, is it possible to change the time period for triggering a warning of the last connection date? We have it set to around three to four days, which causes quite a number of warning messages, especially after the weekend. Since we have quite a few part-time employees, the majority of the computers are constantly displayed with a warning. To me, one week as a warning and four weeks as an error would be more suitable. I have not found a corresponding setting in the policy. Can someone tell me where to set this? Thx & Bye Tom

Hi Community, is there a possibility to determine which file in which email produces the following alert? Thx & Bye Tom

Also that one in the first screenshot?

Servus Marcos, I already don't have half of the paths on my system that were excluded in the other thread. I could only add the /System/Application path. But I noticed something else, I wrote the path to the Time Machine volume with a wildcard character but I didn't define any files with it ( -> /Volumes/Time* ) I have now rewritten the path as shown in the screenshot. Probably that alone was the reason. If this works will take a while to find out, the detections came very irregularly. i'll watch this now for a few days and then give feedback at the end of the week. Thx & Bye Tom

Servus Community, I created a path exclusion for the volume belonging to the local Time Machine backup but I get many of detections on this volume on my personal Mac (10.15). ESET is apparently unable to delete the files it finds, which is why it repeatedly issues a plenty of Popus warnings at irregular intervals. I created the exclusion with a wildcard character (/Volumes/Time*) but according to the manual this should work. Can anyone see an error in the configuration? Thx in advance & Bye Tom

Hi Marcos, the audit log says that the task was modified on 26.03 in the afternoon. On this day we have reinstalled our two Exchange servers with a service provider. Afterwards, we could not activate the two mail security instances, but this was simply due to the fact that the mail security license was not checked in the activation task. Probably the task was modified by mistake while searching for the problem. When installing system updates, the server was restarted and the problem took its course... Thx & Bye Tom

I have now contacted the ESET hotline about this issue. The reason for the disappearance of the clients was an unplanned execution of the Static Group Synchronization server task. This task moved all AD clients into the AD Organisation Unit folder structure. Why this task was executed is unclear. I then had to manually move the clients back into the groups created for them, now hopefully everything is back in the place where it is supposed to be. Summary: In principle no software error, so also magically no fix available. Thx & Bye Tom

Hi Community, today all the static groups we created are suddenly empty. Except for two groups, the Apple macOS devices are apparently still there and two Windows devices are still there but all others are not displayed in the ESET Protect console. I still see all computers in the dynamic group where all machines are and when I look at the properties of my workstation for example, none of our policies are applied. What happened? Thx & Bye Tom

In my opinion, they tried to attach importance to their cloud products, but probably underestimated the dynamics of the situation. It seems like they have lost control in the meantime. With the implementation of Windows 10 and their Windows as a Service update strategy, one update after another is blowing up. Either they came too early or too late. The customer has not been the king anymore, rather they are being forced towards in the direction where Microsoft wants them to go. The other global players like Apple and Google are no exception. If Google decides that any standard is no longer useful, a new standard will be introduced and the world will have to follow. You just stand by shaking your head and get the feeling that they're making fun of it, also. Sorry but I had to vent a bit... Bye Tom

This is a pretty good tool, easy to use and each warning is commented with a link to an explanation. Really very good. I'm thinking about adding something like this to our general monitoring. Only the attacked server had anomalies, but those were the things we already knew. One issue with a compromised web.conf.bak is still open but there I remember darkly that I once created a backup of the file before I made changes to it. The file extension bak is typical for me. After that the exchange server will not have been interested in this file anymore and after a few updates the content does not match the running config. This is my personal explanation for this. All other tested servers like the other Exchange and the two domain controllers were completely unsuspicious in the analysis. According to this, we could have been really lucky. Is there something similar that looks for potential vulnerabilities without any attempt to use them? Thanks again for the suggestion. I don't know where I ended up when I looked at it. I found something similar but it requires having sensors or agents installed on each machine to detect the lateral movements of the intruders. That would only made sense if I already had that set it up beforehand. Therefore I discarded it. Thx & Bye Tom

Hm, I thought I followed the link but the site looks quite different from the ones I remember. Somewhere I took apparently a wrong turn. Thanks for bringing this up again, I'll take a closer look tomorrow. Thx & Bye Tom

ESET Mail Security is installed on our Exchange servers and we found evidence of two backdoors. On 10.03, we ran Microsoft's detection tool with a service provider and found evidence of an infection. The service provider had already opened the directory where the backdoor was installed and we could see the file. We then scanned the system with Windows Defender and exact at that point, ESET's real-time protection jumped in and detected and removed the file. Not a good sign, the file had a timestamp of 05.03. There was a second incident on 06.03 according to ESET, though here the file was detected by ESET and removed as soon as it was created. The first file on 05.03 was not detected as malware by ESET, that's the bad news but depending on receiving the detection pattern it could also mean that the backdoor was not used either. At least not after ESET integrated this threat into an antivirus pattern. Probably between 05.03 and 06.03 ESET has configured the antivirus pattern to the threat. If the backdoor was not used immediately, it could be that it was not used at all. In that case, we might have been lucky. Do you know when exactly the pattern for this threat was released and what version number it had? Do you have any information on how the intruders proceeded after installing the backdoor in the wild? We are not a top target for the intruders, we think that we are a victim of the mass infection. We have now installed ESET File Security on all servers in the domain, including those that are not connected to the Internet, and enabled Live Grid and HIPS on all of them to have as many sensors as possible that could report anomalies, and hopefully we are better protected against possible post exploit attacks. Tomorrow we will start installing Sysmon on the servers and hope to get more data about unusual activity. A little bit late but we can't be more in the dust than we are now. Thx & Bye Tom

Thanks for the list of patched files and the further information. My learning curve has increased rapidly over the last few days. I could have come up with the idea of looking at the file properties in the GUI earlier. Sorry for that but having the list is more valuable. The files have a valid signature and e.g. the owaauth.dll is also shown in the list with the exact size in bytes and version number, only the timestamp is exactly 8 hours before ours, which is probably due to the time zones. Tommorow I compare the other files but that helps to fall asleep. @schuetzdentalCB Have you not patched your server? You should see a similar result. Thx & Bye Tom

Servus Community, I am investigating the post exploit activity of the Hafnium attack and have come across several DDLs that have a creation date a few hours after the installation of the backdoor (05/06.03.21). I uploaded some of these DDLs to Virustotal and they were found to be unsuspicious. However, the temporal context makes me wonder. The creation date is (a few days) before the time when ESET detected and removed the backdoor. However, a manual scan of the files with ESET Mail Security, is also unsuspicious. Can anyone compare these files on their system? C:\Windows\system32>cd C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth>dir Volume in Laufwerk C: hat keine Bezeichnung. Volumeseriennummer: ACE3-7FD2 Verzeichnis von C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth 10.03.2021 12:12 <DIR> . 10.03.2021 12:12 <DIR> .. 16.08.2018 16:53 8.398 error.aspx 22.02.2019 02:28 1.856 error2.aspx 22.02.2019 04:16 7.239 expiredpassword.aspx 06.03.2021 03:37 83.328 exppw.dll 16.08.2018 16:53 6.104 logoff.aspx 06.03.2021 03:37 92.032 owaauth.dll 16.08.2018 16:53 1.106 signout.aspx 7 Datei(en), 200.063 Bytes 2 Verzeichnis(se), 148.422.361.088 Bytes frei C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\auth>cd ..\bin C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Bin>dir *.dll Volume in Laufwerk C: hat keine Bezeichnung. Volumeseriennummer: ACE3-7FD2 Verzeichnis von C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Bin 20.08.2019 23:03 346.848 Microsoft.AspNet.SignalR.Core.dll 20.08.2019 23:03 23.264 Microsoft.AspNet.SignalR.SystemWeb.dll 06.03.2021 03:37 83.832 Microsoft.Exchange.Clients.EventLogs.dll 06.03.2021 03:38 2.970.520 Microsoft.Exchange.Clients.Owa.dll 06.03.2021 03:37 5.029.248 Microsoft.Exchange.Clients.Owa2.Server.dll 06.03.2021 03:37 924.544 Microsoft.Exchange.Clients.Strings.dll 06.03.2021 03:37 45.952 Microsoft.Exchange.InstantMessaging.dll 06.03.2021 03:37 77.208 Microsoft.Exchange.WopiClient.dll 01.05.2018 16:36 101.032 Microsoft.Owin.dll 01.05.2018 16:36 133.288 Microsoft.Owin.Host.SystemWeb.dll 01.05.2018 16:36 53.416 Microsoft.Owin.Security.dll 01.05.2018 16:36 4.608 Owin.dll 12 Datei(en), 9.793.760 Bytes 0 Verzeichnis(se), 148.435.795.968 Bytes frei C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\Bin> Thx in advance & Bye Tom

Hi Community, is ESET File Security in Mail Security included or do I need to install File Security additionally to protect the Exchange server operting systems? Thx & Bye Tom

Hi Guys, well, the upgrade process was really straight forward. The web console took a little longer, I could still log in to the old one, which generated some error messages, but after a few minutes that was done also. Upgrading the agents also went through without a problem on about 25 clients in an evaluation group (Windows 10 and Mac OSX). The Anti Virus application on Windows (EEA) was also updated to version 8 without any problems in this group. That the EEA application on Mac is still on version 6.x is intended? Summary: As far as I can see, everything seems to work without problems. Thx & Bye Tom

Servus Marcos, okay, thanks. Is the upgrade process straight forward or is there major work for reconfiguration to expect? Looks the Webgui almost the same or is it like Microsoft and everything is renamed and puzzeld to anywhere...? 😉 Thx & Bye Tom

Servus Marcos, is ESET PROTECT a regular update for ESMC or is this an upgrade to another product? Possibly subject to a charge? Thx & Bye Tom

Servus Community, I'm lost in the jungle of the thousands of different modules which ESET offers. I'm doing some updates of the ESET infrastructure, including the server components and thought that I've running the latest version of ESMC. I took the version from the the help menu in the about section. There is a version 7.2.1278.0 shown. But when I compare this with the website of ESET where the current releases are listet, the current version of ESMC there is 7.2.11.3. I'm confused. My question is, if I'm lokking on the wrong place to determine the current running version or is the ESET website outdated? Thanks in advance & Bye Tom

Servus Community, I created a new client task today to update the ESET product and it ran correctly on 12 test machines, but not on two. The task terminated there with the error: Repository package checksum verification failed While searching for the cause I came across several post that specified a different update source in the task. I tried that as well and the task terminated successfully on the other two machines as well. In the process I noticed that a latest version is specified in the URL[1]. My question would be, is this URL permanent? So I wouldn't have to create a new task for every version I want to upgrade to, but could simply configure a task with Upgrade to latest and run it over and over again. If that then makes sense in the long run in the history of updates as well. Another question follows, is there somewhere a list of all these URLs? When I only modify the URL to enter an above located folder, I get an 404 error. [1] https://download.eset.com/com/eset/apps/business/eea/windows/latest/eea_nt64.msi Thx & Bye Tom

Servus Community, I am trying to determine the mail flow in our Exchange 2016 infrastructure. I have found a flowchart from both Microsoft and ESET, but I can't get the two together. The transport agents are resolved on the Exchange Server as follows: [PS] C:\Windows\system32>Get-TransportAgent Identity Enabled Priority -------- ------- -------- ESET Filtering Agent True 1 ESET Filtering AV Agent True 2 Transport Rule Agent True 3 DLP Policy Agent True 4 Retention Policy Agent True 5 Supervisory Review Agent True 6 Malware Agent True 7 Text Messaging Routing Agent True 8 Text Messaging Delivery Agent True 9 System Probe Drop Smtp Agent True 10 System Probe Drop Routing Agent True 11 Exchange Server also has a number of filters that are processed in a different order and logged in different log files. I would like to find out which logfiles are written before the ESET filter? Regardless of what happens to a mail afterwards. Thx in advance & Bye Tom

This is maybe the reason why I haven't found it... 🙄

Servus Community, is it possible to configure a firewall in Windows File Security that only allows inbound and outbound ports from certain sources or destinations and prohibits everything else? For example RPD only from this host and also only RDP and nothing else? Or port 2222 (ESET Communication) only from and to this host? I can't follow the instructions I found in the File Security interface. The Windows Firewall would be one possibility but there are 1001 magic rules inside, of which probably half are only understood by Microsoft Nerds. I would like to avoid using them. Thx & Bye Tom