pronto

It is possible that we have the setup in operation for 1500 days now but the checkbox that requires a password change is not checked.

Servus Marcos, the specific setting wasn't set

Servus Community, today I was suddenly asked to change the password of the ESET Protect GUI. This was unexpected. This is the first time in all the years we use ESET. Where does this come from suddenly and how to turn it off? Thx & Bye Tom

Hi Marcos, the highlighted record in the log file is the last record we've seen since we put a reverse proxy server into service. We have configured the reverse proxy server to send the original IP address in an X-Forwarded-For header tag, but it seems that ESET does not analyze this record in the header. Instead, ESET now seems to analyze the internal IP address of the reverse proxy server. With this we fear to have put a bypass around the IP address list database. Our question was, how do we have to configure ESET to evaluate the correct IP address? Thx & Bye Tom

And what do we do now?

Hi Marko, I'm pretty sure the feature doesn't work anymore. The last entry in the logfile is pretty much the time when we put the reverse proxy into service. Thx & Bye Tom

Hi M, thanks for your explanation but I'm guessing we still have a missunderstanding. What we want to test is not if an email is blocked (SMTP/25) but client connections over HTTPS/443 (EWS, OWA, Autodiscover etc). We have placed a reverse proxy (Apache; HTTPS) in front of our mail servers and now the client arrives e.g. via OWA with the internal IP address of the proxy server instead of its own public IP address. However, it is possible to send the original IP address in the header in the proxy configuration (X-Forwarded-For), which we have set and also verified that this is indeed the case. But this is an HTTP request, not an SMTP based communication. Since we put the proxy server into service, no more blocked requests are logged on port 443 on the Exchange server, which were matched with an IP blacklist. This is unusual and can now have two causes. Either the proxy server discards all malicious requests, which we have not set (mod_secure and other dynamic security features are not yet enabled on the proxy) or ESET analyzes the wrong field in the HTTP header when checking the request. Finally, there is the possibility that the firewall between the proxy server and the mail server removes the X-Forwarded-For tag, but the support of the firewall manufacturer has denied this. We could now install a packet sniffer on the Exchange and analyze whether this tag really arrives the Exchange server, but before I do that I would like to clear up our misunderstandings. If ESET is analyzing the wrong IP address at this point, our proxy server setup in front of the Exchange is rather insecure, at least as long as we don't outsource this analysis to the proxy server itself. This is a critical point. Thx & Bye Tom

Servus M, Well, we have imported this new configuration now and it is also in the config but we can't determine if this actually works. We have now created the following request with an original IP, which is definitely on the blacklist, but we cannot detect a blocked request in Eset Mail Security Logs. GET / HTTP/1.1 Host: 192.168.11.20:8080 X-Forwarded-For: 223.171.91.191 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:106.0) Gecko/20100101 Firefox/106.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Upgrade-Insecure-Requests: 1 The entire request is sent that way: $ openssl s_client -connect 192.168.1.6:https We would have expected a matching entry in ESET Mail Protection, but it did not come. Does ESET have to be restarted after the config change? Thx & Bye Tom

Servus M, Okay, I exported the ESET Mail Protection (Network) settings (See screenshot), then just put your code in <eset><product>PUT IN HERE</product></eset> and import it again? Or should I select a different setting than network protection to export? How does that then behave in the case of an update? Btw: As already mentioned at the beginning, we also have a ticket open in parallel and there came earlier the answer that this feature is now always on, where we asked back again whether this also affects HTTP, because the colleague referred specifically to SMTP:

Hi M, do you have a manual where we can find the handling about this way of setup undocumented settings. Why is this setting removed in the GUI? Is there a possibility to test this setup? Thx & Bye Tom

Servus Community, we are looking for the setting "Search for sender's originating IP address in headers" in the policy for our Exchange Server as described in [1] for example. We have installed a Reverse Proxy Server in service in front of our Exchange servers and need the evaluation of the original IP address for the full support of the ESET security features (IPBlacklist for example). Is this setting outdated, does it not work anymore or is this always active now? How can we test if the setup works as expected? The Apache web server on the reverse proxy is set to send the original IP address (ProxyPreserveHost On). We are currently using ESET Mail Protection for Exchange Server version 9. [1] https://help.eset.com/emsx/6.5/en-US/index.html?idh_config_av_agent2.htm FYI: A support ticket has also been created for this issue under the ID 00442012 Thx & Bye Tom

It seems you were right. I just patched the second Exchange Server and it did not bring this message when disabling the virus scanner. It probably was really just a coincidence. Thx & Bye Tom

Servus Community, I stopped the virus scanner on one of our Exchange servers to apply security updates. During the dialog to disable real-time protection, I was surprised by a thick red banner that said that a new threat had been found. Only after confirmation could I proceed with deactivating the virus scanner. On another normal Windows server, this banner did not appear. What does this mean specifically? Thx & Bye Tom

Thank you for your attention. Okay, the security patch from August was missing, we are up to date with the CU. But why does a match with an IP blacklist produce a red error? According to my information, ESET itself partly does not know which vulnerability was tried to be exploited. So far, they were always shown as resolved when the connection was finaly blocked. Thx in advanced & Bye Tom

Servus Community, I have conflicting information on several detections in our Exchange Server. There are three unresolved detections logged, but theaction type is indicated as blocked. What exactly is my to do now? Thx & Bye Tom

Servus Community, since we have repeatedly found indications in the log files of the Exchange server that attempts are being made to exploit security vulnerabilities which are then neither found by the IDS on the firewall nor detected by ESET, we are considering placing a reverse proxy in front of our Exchanger server. But one of us has the argument that we could possibly bypass the IP address filter of ESET's mail security on our Exchange servers. With proxy servers it is partly possible to set that the original sender IP address is sent along with the HTTP header. At least this was the case with a Squid proxy we used in the past. The question now is whether ESET is also able to analyze the HTTP header in this regard and interpret it correctly? If not, this would be a knock out criterion for a proxy server, because the IP addresses blocked by ESET are already many. Even if it is not really clear what this IP address is trying to do, something will be on the one hand and on the other hand it is most likely not a false positive detection. Thx & Bye Tom

Thx, it seeams this could be anything...

Servus Community, I am currently trying to chronologically overlay some suspicious log file entries and in this context I am interested in some entries in the ESET log file regarding our Exchange servers (See attached image). Is there any way to determine which vulnerability was blocked there? Thx & Bye Tom

Servus Community, we have received a backdoor alert from a Yara rule scanner (Thor) on both Exchange servers over the past two days. A signature of the backdoor Tricephalic Hellkeeper was found in the process memory[1]. I'm pretty sure this is a false positive detection, as this backdoor appears to have been developed for Linux and Solaris. I have now whitelisted the rule on both Exchange servers. Finally, I wanted to ask here if there is any other information known about this backdoor that makes the issue more critical than it appears? Here are the files whose processes are affected. All of them have also been tested negatively by Virustotal. ESET has not reported any suspicious behavior either: PATH: C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeHMRecovery.exe PATH: C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeCompliance.exe PATH: C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.Mitigation.Service.exe PATH: C:\Program Files\Microsoft\Exchange Server\V15\Bin\ComplianceAuditService.exe [1] https://exatrack.com/public/Tricephalic_Hellkeeper.pdf Thx & Bye Tom

Servus Itman, thank you for your support and research on this issue. I have rarely felt so helpless. The more I read about it, the more frightened I became. Anyway, we have disabled the execution of macros in office applications for a long time and tomorrow I will block the IP at the perimeter gateway. You also gave me the tip about the Thor scanner, without I wouldn't have noticed anything. Maybe the problem wasn't as big as I made it, but since I had no idea how to track down a possible infection, I just collapsed in panic for a while. In the meantime I also had the time to take a closer look at the plenty of warnings of the Thor scanner. There were 72 of them. The reason for this was that we received several emails from this IP at once (as described above) and in every line of the SMTP handshake the IP address appeared. Thus Thor generated a warning from every single line. I'll take a more relaxed look at it tomorrow. Hope it remains so... 🙂 Thx & Bye Tom

It was an incoming e-mail from this suspicious address, but I have not found it yet, or even searched for it. Or actually even several emails with random sender addresses but always the same receiving address. I'll look for this email now and keep watching...

Oh Itman, the world is evil... Why is this hitting us? How should I proceed now? I feel a little helpless right now... The good news is, so far it has remained with this one incident. I'll have to see if I can still find that ominous email. I am already very interested in what it has to do with it... Thx & Bye Tom

Puh, like the link before, this is way beyond my knowledge. But I found the complete SMTP handshake in the Exchange log files and it only affects an email address of a colleague who left and the forwarding destination of the emails terminates on a macOS system. So far I could follow Kaspersky's technical explanations that it is probably a Windows based attack vector. But the question still remains, how could I detect a successful attack? Thx & Bye Tom

Since the rule is also called that IP address, it may well be. I can live with that... BTW: Can you set the screenshots to non-public? I found an email address in a screenshot that I should have made unreadable. Thx & Bye Tom

Servus Community, our Thor scanner encountered suspicious entries in the log files of both Exchangers tonight. The information points to this vulnerability: https://securelist.com/moonbounce-the-dark-side-of-uefi-firmware/105468/ I could not find any evidence of detection of the attack in the virus scanner, nor in the firewall. Is this known to you? Thx & Bye Tom