Jump to content

pronto

Members
 View Profile  See their activity

  • Posts

    165

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Posts posted by pronto

    Search for sender's originating IP address in headers

    in ESET Products for Windows Servers

    Posted

    5 minutes ago, Marcos said:

    The highlighted record seems to be a correct block since 192.241.217.39 is a known source of attacks: https://www.abuseipdb.com/check/192.241.217.39

    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

    Search for sender's originating IP address in headers

    in ESET Products for Windows Servers

    Posted

    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

    Bildschirmfoto 2022-10-26 um 13.45.32.png

    Search for sender's originating IP address in headers

    in ESET Products for Windows Servers

    Posted

    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

    Bildschirmfoto 2022-10-25 um 16.42.19.png

    Search for sender's originating IP address in headers

    in ESET Products for Windows Servers

    Posted

    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:

    Quote

    Hello Mr. Wildgruber,

    the originating IP Address is detected automatically in all new versions of Mail Security. you don't need to specify it manually, as that option is not available anymore and the version 6.5 is already in End of Life.

    for an example, check the email headers and you'll see the originating IP Address "marked in red" similar to this: 

    X-ESET-AS: R=OK;S=0;OP=CALC;TIME=1666304162;VERSION=7938;MC=1344213395;TRN=0;CRV=-3;IPC=200.54.219.222;SP=0;SIPS=3;PI=3;F=0
X-ESET-Antispam: OK
X-EsetResult: clean, is OK

     

    Bildschirmfoto 2022-10-25 um 11.47.34.png

    Bildschirmfoto 2022-10-25 um 11.57.20.png

    Search for sender's originating IP address in headers

    in ESET Products for Windows Servers

    Posted · Edited by pronto
    Ticket ID added

    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

    New threat found

    in ESET Products for Windows Servers

    Posted

    1 hour ago, Marcos said:

    Most likely a threat was detected by real-time protection recently before you attempted to pause it.

    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

    New threat found

    in ESET Products for Windows Servers

    Posted

    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

    Bildschirmfoto 2022-10-12 um 16.29.37.png

    Unresolved Detection -> Action: Blocked

    in ESET Products for Windows Servers

    Posted

    12 hours ago, itman said:

    If you haven't applied the latest Microsoft security patches, you need to do ASAP. Exchange server vulnerabilities are at the top of the list of exploits being deployed by hackers.

    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

    [Exchange 2016] ESET IP address blacklist and reverse proxy

    in ESET Products for Windows Servers

    Posted

    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

    Tricephalic Hellkeeper Backdoor Alert on Windows Exchange Server

    in ESET Products for Windows Servers

    Posted

    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

    Bildschirmfoto 2022-06-13 um 12.26.22.png

    UEFI Threat Moonbounce

    in Malware Finding and Cleaning

    Posted

    24 minutes ago, itman said:

    Looks like "we can put this one to bed."

    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

    UEFI Threat Moonbounce

    in Malware Finding and Cleaning

    Posted

    21 minutes ago, itman said:

    If the Thor scanner detected inbound network traffic from this IP address, it could have been just a random connection attempt. If the connection to the IP address is outbound, then that's a different story. Note that most gateways will only allow inbound TCP network traffic that is statefull based; i.e. response to prior outbound TCP network traffic.

    The key element will be if further Thor detection's occur.

    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...

    UEFI Threat Moonbounce

    in Malware Finding and Cleaning

    Posted

    38 minutes ago, itman said:

    Eset will detect a stand-alone Microcin attack. However, if it is embedded in the UEFI, all bets are off.

    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

    UEFI Threat Moonbounce

    in Malware Finding and Cleaning

    Posted · Edited by pronto

    8 minutes ago, itman said:

    Here's a Kaspersky detailed analysis on Microcin: https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2018/03/07170759/Microcin_Technical_4PDF_eng_final_s.pdf

    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

    UEFI Threat Moonbounce

    in Malware Finding and Cleaning

    Posted

    8 minutes ago, Marcos said:

    Probably FP. To me it looks like a Yara rule merely detected the string "172.105.94.67" in the Received SMTP log file.

    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

    UEFI Threat Moonbounce

    in Malware Finding and Cleaning

    Posted · Edited by Marcos
    Screenshots removed

    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

     

     

×
×
  • Create New...