FTL

Hope so, as this will be the 3rd version that apparently fixes the issue, yet nearly 5 months later were still having to roll people back to an older version so they can work properly in Outlook, only so many excuses i can keep making to my clients about ESET before they get fed up and start questioning why they are running old versions of software.

Any news on this please Marcos? 9.1.2160 is still a real PITA with Outlook and shared mailboxes - makes them hang, crash, slow down to a complete crawl. Still having to put some clients back to 9.0.2046 which is the last known good working version with Outlook Thanks

Hi JamesR No none of the servers have RDS installed. They are IIS web servers, my PRTG monitoring server (which i cant easily lock down 443 access via IP for as the mobile app needs to connect over 443 for push notificaitons to work to my tech's, and an Exchange on prem server, which again has 443 open for its operation. Of the 5 servers that are getting this alert: IIS Web Server 1 - only has port 443 open and natted on the firewall for inbound internet traffic IIS Web Server 2 - only has port 443 open and natted on the firewall for inbound internet traffic IIS Web Server 3 - only has port 443 open and natted on the firewall for inbound internet traffic PRTG Monitoring Server - only has port 443 open and natted on the firewall for inbound internet traffic Exchange Server - has ports 25 and 443 open and natted on the firewall for inbound internet traffic. No other ports are open on the firewall to these devices

Hi JamesR Thankyou for this. I have peformed the steps above and can confirm they are all inbound from public IPs and on port 443 (which is leitimately open on the firewall for these servers) They are all ntoskrnl.exe apart from my PRTG monitoring server which is prtgserver.exe but again external IP and on port 443 which is legitimately open on the firewall. Command lines are all None and username is "nt authority\system"

Hi, New to Inspect so still learning the ropes so to speak I seem to get this alert periodically on all of my internet facing servers. Category: ESET Inspect alerts Computer name: cleansed Computer static group hierarchy: cleansed Rule: Protocol Mismatch ‑ detected RDP communication over non‑standard port [E0517] Time Detected: 11/18/22, 2:09:34 AM UTC Process Detected: %SYSTEM%\ntoskrnl.exe Severity Rating: Critical Is this someone port scanning and trying to be clever, and just noise, or do i have a bigger problem? I have RDP allowed internally, but not from the internet. Thanks

Yup, all patched both Windows and Exch CU/SU, its as up to date as it can be

@MarcosSo to confirm i am not infected then, its a bug in the software?

Ok had 6 more IP's overnight getting blocked All the listed IP's below seem to be reported on the link from Marcos and comments say brute force attacks ESET scan not finding anything, MBAM not finding anything. As they are outbound connections being blocked are we saying that the mail server is compromised and one/more of these brute force attacks has been successful? </RECORD> <RECORD> <COLUMN NAME="Time">01/11/2022 23:56:23</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:25</COLUMN> <COLUMN NAME="Target">193.251.180.116:50462</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> <RECORD> <COLUMN NAME="Time">01/11/2022 23:56:27</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:25</COLUMN> <COLUMN NAME="Target">189.113.184.5:59338</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> <RECORD> <COLUMN NAME="Time">01/11/2022 23:57:04</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:25</COLUMN> <COLUMN NAME="Target">118.150.80.237:38407</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> <RECORD> <COLUMN NAME="Time">02/11/2022 02:26:30</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:25</COLUMN> <COLUMN NAME="Target">172.81.45.38:50681</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> <RECORD> <COLUMN NAME="Time">02/11/2022 02:27:10</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:25</COLUMN> <COLUMN NAME="Target">117.61.1.194:47785</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> <RECORD> <COLUMN NAME="Time">02/11/2022 07:43:07</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:25</COLUMN> <COLUMN NAME="Target">202.165.193.166:38604</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> <RECORD> <COLUMN NAME="Time">02/11/2022 07:44:28</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:25</COLUMN> <COLUMN NAME="Target">175.100.117.22:48100</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD>

EMSX has blocked some outbound connections from our Exch server <?xml version="1.0" encoding="utf-8" ?> <ESET> <LOG> <RECORD> <COLUMN NAME="Time">06/10/2022 14:54:27</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:25</COLUMN> <COLUMN NAME="Target">76.184.134.117:55806</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> <RECORD> <COLUMN NAME="Time">06/10/2022 14:56:10</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:587</COLUMN> <COLUMN NAME="Target">27.147.181.38:48022</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> <RECORD> <COLUMN NAME="Time">09/10/2022 23:21:31</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:587</COLUMN> <COLUMN NAME="Target">165.22.230.190:61953</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> <RECORD> <COLUMN NAME="Time">01/11/2022 08:37:49</COLUMN> <COLUMN NAME="Event">Security vulnerability exploitation attempt</COLUMN> <COLUMN NAME="Action">Blocked</COLUMN> <COLUMN NAME="Source">192.168.1.5:25</COLUMN> <COLUMN NAME="Target">204.138.26.219:41471</COLUMN> <COLUMN NAME="Protocol">TCP</COLUMN> <COLUMN NAME="Rule/worm name">EsetIpBlacklist.B</COLUMN> <COLUMN NAME="Application">D:\Exchange Install Dir\Bin\MSExchangeFrontendTransport.exe</COLUMN> <COLUMN NAME="Hash">8C10F7C821A250FDB04AFCB491CF74090700107D</COLUMN> <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN> </RECORD> </LOG> </ESET> Things being blocked outbound naturally raise suspicion, how do i investigate these further please?

Seems to be behaving itself on my system too on 9.1.60.0 😀 Will roll it out to some users over the weekend and guage their responces Monday. @Marcos - what was the exact issue and how was it resolved?

Not sure about Auto Update - but 9.0.2046 is still in the repo. I have a task for this version in my eset protect console to roll back users who are having slow outlook issues with 9.1 until resolved and its still a valid download. Just use your Protect console to push the 9.0 update out via task and disable the option in task setup to install the latest version.

I didnt have the general laggy performance when opeing email/typing etc on mine, but i did have the blank screen when opening Outlook rather than showing the inbox, and it only displayed after about 20-30 seconds after it had Connected to Exchange. Just tested by removing all my delegated/shared mailboxes and now outlook opens normally on 9.1.2057 as it did before the bug was introduced in 9.1.2051, so your definately looking in the right direction Marcos!

In my case users complaining do have only there own mailbox in accounts but do have full control granted to other mailboxes - a mix of other active licenced o365 users and shared mailboxes - however shared mailboxes are not cached.

Yep i concur, all of my 2051 clients that have put up with it are still affected with 2057. 9.0.2046 we shall stay still for the rest!

Disabling MS Outlook Integration does resolve the issue. But im not going to disable that for obviosu reasons. Outlook connected to o365 for email

Turning off these options doesnt make a difference to the issue Turning this one off makes Outlook happy again I cant see the antispam setting you have posted?

Turning any or all of these settings off have not resolved it for me. Still only way to get Outlook behaving again is to turn off Outlook integration (which im not doing) or rolling back to v9.0.2046 Im getting constantly moaned at, so please ESET give us a fix for this Ive not had any update at all to my case raised.

Also have this issue since updating to 9.1.2051, attaching emails is painfully slow, outlook is laggy and buggy as hell, type away and nothing appears almost like cpu is at 100% when it isnt. Moving emails to another folder - forget it. 365 versions of Outlook sit on the splash screen on "Processing" for an age Pro Plus VL versions seem to open speed wise fine, but then sit on a blank inbox screen for ages and then as reported takes 20-30 secs to connect to exchange. Support witnessed the 365 version issue, and can also too replicate "fixing it" by disabling the Outlook integration, or rolling back to 9.0.2046 which makes Outlook a happy bunny again Opened case with support and uploaded logs - Case 00396052

Hi On the 11 October i submitted 7 dll files to samples@eset.com that ESET's software decided to leave behind as clean from an infected Exchange 2019 Server from Hafnium/ProxyShell exploits. I know they are malicious as the time stamps of the files created mataches that of when the attack on that server took place, and they were in one of the known locations its like to dump its files. C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\e22c2559\92c7e946) At the time only Kaspersky detected them as malicious through uploading them via virustotal. Still today ESET is not picking these files up, even though there are now 10+ other vendors detecting these on virustotal as part of the proxy exchange expolits. Anybody from ESET staff on here able to escalte this please and get these files checked and added! Thanks

Hi, sorry for the delay in replying, Target OS - Windows 7 Pro x64 + Windows 10 Pro/Enterprise x64 Target - does it on both an individual computer, also a dynamic group Software Version - Endpint 6.6.2046.0, I do my servers manually but could try one i guess via a task to see Task was just to install Endpoint - Activation has a seperate task against the not activated dynamic group ERA Server deployed on Server 2012 R2 Thanks

Hi, Just like to bring to your attention a couple of bugs found whilst using ERA 6.5 ESET Remote Administrator (Server), Version 6.5 (6.5.522.0) ESET Remote Administrator (Web Console), Version 6.5 (6.5.388.0) 1. When creating a software install client task (in my case Endpoint AV and Endpoint Security) - the task stays showing as Running even though its actually completed, the product is successfully installed and the agent reporting on it correctly. Doesnt matter how long you leave it for, its stays blue and status running. 2. When editing a Agent Push Install Server Task - when you re-type the password in, after inputting the first character the cursor defaults back to the start of the password so the first character you have typed in actually ends up at the end of the password (appears to be ok when creating the task for the first time, just when subsequently editing it) Thanks

Symantec Messaging Gateway. Trend Micro WFBS and SMEX also has the ability to set rules to scan inside zips and delete them at server level If Symantec, the worlds worst vendor of AV can, anybody can ill ever know!

Hi Peter, I have double checked my server settings as suggested and confirm that everything is setup how it should be for the virus scanner to scan insidie archives. However it doesnt explain the fact that in any given hour of the day my own Exchange Quarantine mailbox can accumulate 300+ emails marked as spam and the majority of them contain an exe inside a zip!!! Id say that over a whole day if we get 10 that are actually caught and moved the to Quarantine folders Infected Items saying XYZ infection has been found we have had a good day! Surely the AV side of EMSX should be catching these and marking them all as infections, not just the odd few, even if the rule side of deleting anything with exe inside an archive cannot be achieved? 99% of the mail i get quarantined that has .exe attachments is just marked with SPAM. Example- even though inside of this email has a zip file containing Invoice.pdf.exe attachment Then 3 minutes later i get So why are all .exe archives not being stripped out like the last example and appended with what was found? Either that or we are a very very unlucky company and get hit with the newest variants all the time that have been undectected and not added to the spam updates yet. Then im having to comb through my Quarantine mailbox everyday that contains thousands of spam mail, 95% containing .exe infections, trying to fish out any legit ones it may have caught gets pretty tiring; very quickly. When then i have to do it for clients on managed contracts who dont have onsite IT personal aswell you can start to see how ive gotten angry with this issue!? Its alot of my time wasted daily. Im not ESET bashing here so please dont think I am, im trying to give constructive critisism on issues that end users in the real world are facing - issues i know you are not ignorant nor already unaware of.

Likewise Reformit - we too are resellers and if it wasnt for this fact that we have many clients using ESET on our so say, id have sacked ESET off and got in a mail security product that is actually secure as soon as i was told this basic, necessary feature doednt actually exist! We are very unhappy resellers and an end-user at the moment!

Unfortunately not Peter (thankyou for your reply)- we recieve many .zips that are legitimate from a wide range of sources - far too many to whitelist individually. How come the AV program itself does not scan the zip file and see the .exe and quarantine it anyway? As an AV it surely has the ability to scan inside of a zip file even if it cannot delete the whole attachment yet at mail server level? If i zip up a folder on my desktop and then scan it with Endpoint then it scans all files inside the zip folder. Where does the difference lie?