MS exchange on prem protection

Just a couple of quick questions first for the team, 2nd for members.

Like many others in the world with ON PREM exchange servers, it has been a busy few days both patching and checking servers after MS announced there was a major issue that needed action quickly, fielding calls from concerned clients after media started publishing headline stories and so forth.

Q. IF we had SOCaaP setup and running on an unpatched or out of date 2016 Exchange server, what would have been the outcome for this particular incident?

Would it have blocked the actions that others have seen on the servers like apsx scripts dropped and run, files zipped, AD perhaps compromised?

Would the team have seen it in “real time” as probed or compromised and would we have been notified or an alert sent?

Very interested in how the SOCaaP system has performed over the last few weeks or so.

Also looking for feedback from members who have been dealing with perhaps Exchange servers that did get hit, or those who are aware of others that required investigation etc.

What notifications did you have in place, if any, and did anyone have AEP or SOCaaP in place.

Perhaps these are very open-ended questions, and members may only want to answer brief forum responses in general terms but via private message in detail if they want.

I’m getting the same type of queries from clients along the lines of "how well are we protected, and what can we do better or differently going forward?

We are in AU.


Very good question indeed and thanks for asking. There are many stages for such kind of attacks and SOCaaP can help you on many of them. In a typical customer environment where SOCaaP is used, we can assume that our endpoint solution has been deployed to the Exchance server itself and we are also collecting Domain Controller audit logs.

First of all, as you know the attack initiated by remote exploitable vulnerability to drop webshells as aspx files. Webshells are hard to detect by regular scans so lets assume that at that our endpoint solution do not detect those webshells (Note: we are detecting webshell used in the attack check Comodo there)
The next step of attack is IIS process w3wp.exe creates a child process cmd.exe to write a file to disk. At this step, our containment technology will contain the file and run it via Kernel API virtualization so that there will be no harm and persistence at all. At the same time our SOC team will get alerts about this containment event and start investigating so that they end of with asking for additional logs of your IIS server to go in depth analysis even you are protected.

Lets assume that somehow the containment profile is not active (Btw with SOCaaP Endpoint Protect, containment is managed profile so the SOC team will make sure that it is properly configured) and cmd.exe runs and drop China Chopper (another webshell) what we see as next step the attackers runs for command to delete administrator user from the Exchange Organizations administrators group. SOCaaP will detect it from Domain Controller logs and generates another warning to check. Our SOC team will again start investigating the issue and will contact with you about it.

Of course SOCaaP is not just about endpoint agent and AD monitoring. It comes with network sensor and IDS to detect those remote exploit HTTP requests, it also allow you forward IIS logs where we can correlate webshell injections from there as well. So in short, while our endpoint agents will protect you any threats like this, SOCaaP and SOC team will bring managed endpoint, real time monitoring, incident analysis and management for you.


That would be one of the most responsive and informational posts I have seen for a while, thank you.

I’m almost going to do a copy and paste as part of some proposals requested in the next few weeks.


Good question deserves detailed answer. Thanks @mcfproservices and good luck for your opportunities

Hi,is that SOCaaP agent a different one or it is the same of itarian one? Is SOCaaP comply with GDPR ?