I have an Exchange server 2019 wich have not been correctly patched since one month ago; it had Sophos Advanced Endopoint installed allready + Sophos Firewall Intercept X in front (protected by WAF - no DNAT)
I started questioning my self as soon as I noticed some notifications about Sophos deliting some "CXmal/WebAgnt-A" in www/inetpub folders
Searching around I saw that these might be related to ProxyShell vulnerabilities, this server wasn't correctly patch with last cumulative updates so I did everything it needed...
Then I made a quite deep search with Micrisoft Scripts (TestProxylogon + others found here https://github.com/microsoft/CSS-Exchange/tree/main/Security ) and nothing came out so I thought I should be relaxed that this server has not been compromised...
...but then Sophos keeps intercepting this "CXmal/WebAgnt-A" so, my question is: is it normal that I see these notifications? in other words Sophos is doing it's job so there is nothing to worry about?
or may I have to watch something else in this EX server that I didn't realize with those scripts?
Thanks in advance.
is it normal that I see these notifications? No.in other words Sophos is doing it's job so there is nothing to worry about? Sophos is doing its job, but these detections come from files that must come from…
is it normal that I see these notifications? No.in other words Sophos is doing it's job so there is nothing to worry about? Sophos is doing its job, but these detections come from files that must come from somewhere, so you need to worry about that.
“First things first, but not necessarily in that order” – Doctor Who
So you might want to check all startup items for traces of persistency, and/or find out what process is writing those files, and go from there.
The steps mentioned in the following Sophos News article may lend some guidance in your situation.- ProxyShell vulnerabilities in Microsoft Exchange: What to do
What does a sample path or two look like to a detected item?
It looks like this 'C:\inetpub\wwwroot\aspnet_client\aaoeu.aspx' (name of aspx is different every time. Up to now it happened reandomly and not under a "time schema" so it doesn't make me think about some bad service or exe in the exchange itself still runinng...
To give other people more infors, Yesterday I dedicated lot of time to every single row of Qoosh advice, I don0t have XDR service but I ran trhough all those queries and have found (and deleted) these:
<virtualDirectory path="/auth/部/hKMhI" physicalPath="C:\ProgramData\COM1\hKMhI" /> <virtualDirectory path="/auth/笔/dorkU" physicalPath="C:\ProgramData\WHO\dorkU" />
They seemed soem sort of "not genuine" configurations (they were in C:\Windows\System32\inetsrv\Config\applicationHost.config)
Since I have deleted them, no more interceptions by Sophos, but maybe it's just a coincidence.
If anybodyelse got other informations would be really appreciated
I am getting these detections for CXmal/WebAgnt-A occasionally as well and I also had these strange settings in the applicationhost.config file. The directories do not exist so I can only think it never made it past the config stage. I deleted them and will see if the detection happens again..
virtualDirectory path="/auth/部/hKMhI" physicalPath="C:\ProgramData\COM1\hKMhI" /><virtualDirectory path="/auth/笔/dorkU" physicalPath="C:\ProgramData\WHO\dorkU" />
Hi Robert, since I have deleted those, no more notifications so far; I would be interested in knowing if it will be for You also... thanks
Now I get the CXmal/Webagnt-A from a process on exchange c:\program files\microsoft\exchange server\v15\bin\msexchangemailboxreplication.exe which is reading from a PST file someone created and writing a file to \\127.0.0.1\c$\inetpub\wwwroot\aspnet_client\llplckqxnci.aspx which is immediately detected as a Virus and deleted. Looking at how this is happening now... I have used all the systools to verify files and check schedualed jobs .. Could it be the user computer running some schedualed mailbox replication job that is creating this?
Hey, do you have any update on your findings? I'm running into the same issues. Thanks.
I narrowed this down to Shadow copy process that our backup solution VEEAM uses to back this up... When I cleaned all the servers hosting VEEAM and the administrators PC ... This problem has gone away for now.