HEC and MS Direct Send

[FuzzyLogic]

TLDR
For those less interested in my philosophical rambling: Check Point Harmony Email and Collaboration does protect you from Direct Send phishing attacks.

Security Engineering is Changing

Lately I have been thinking about sort of tidal shift that seems to be happening in cybersecurity related to security administration. It has come up organically in a number of conversations at some local conferences and user groups in the last few months, so I know that I am not the only one noticing it.

The way we protect our IT systems is changing. Or rather I should say; the way we configure our protection systems is changing. It is driven by the nature of AI technologies but I don't mean the AI itself. Once we start to move away from the deterministic style of protection systems built on older technology, to adaptive systems that are dynamically learning and contextually aware, we can't manage them in the same way. Or at least, shouldn't; if we want to get the best result.

Often in this new landscape we will find ourselves implementing controls that don't "feel" as safe as they used to. Even if it is providing a much better level of protection. We have to learn the AI protection systems, but not learn as in; "memorize all the individual manual setting options". Instead, we get to know the kinds of things the system will do and the context that is important for the protections we want applied. Often this means "training" a system rather than configuring it, or validating behaviors that we never explicitly defined.

I am rambling a bit, but it is a fascinating topic and I think, a very important one for security admins to be thinking about. Today I am going to add to the general conversation on this topic that I found so engaging, with a deep dive into a specific example related to Harmony Email and Collaboration (HEC).

The Direct Send Vulnerability
A few years ago MS released a feature integrated into their cloud email platform called Direct Send. The purpose of this feature is to enable IoT style devices or printers to send email messages into the Exchange online system. Like so many convenience or backward compatibility based features, it nicely enables not only the desired behavior but also leaves a door wide open for malicious activity. Oh, and of course, it cannot be turned off.
MS Documentation
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-de...

Basically what it means is, anyone who can find your MS tenant domain (Read: query your MX record) can use a simple 1 line command from PowerShell, from anywhere in the world to send you spoofed phishing messages. An open relay from the internet to your internal recipients.

The only minor road block to exploitation here was that they do block messages sourced from blacklisted IPs and there are large blocks of public cloud IP ranges now blacklisted by default. So that helps a little, but not much. (I am a Red Teaming Noob and it took me less than an hour to solve for my testing)

The broader PEN Testing implications and details of how to execute it are beyond the scope of this post. (For those who are interested, that part it is better coming from the experts anyway.) However, it is well documented and discussed. This is one of the better write-ups I found:

How to setup DS
https://www.blackhillsinfosec.com/spoofing-microsoft-365-like-its-1995/

Harmony Email and Collaboration

Now this initially came up on my radar because I had a client that wanted to know how Check Point HEC would handle this situation. See, when you look up the guidance around how to mitigate, the general recommendations seem to be that you need to lock this down with a bunch of static settings in your Secure Email Gateway (SEG) proxy.

For those of us familiar with HEC, it will jump out right away why this question would come up. Our architecture is fundamentally different that a traditional SEG. We pioneered a different approach years ago. The integration is setup via API and we provide inline protection rather than sitting in front of the mail system.

 There are a number of advantages to this approach, and while we were the first, we are not alone in recognizing it. Almost every email security start-up that has launched in recent years is trying to emulate our integration pattern. Personally, I expect this trend to continue and in the near future Gateway/Proxy setups will probably become the exception rather than the rule.

So what does it look like, when your infrastructure provider creates a vulnerability in your mail system, then tells you that in order to mitigate it you must apply static settings and manual changes in a legacy system architecture you no longer use… When instead, you are working in a state-of-the-art email protection platform, dynamically integrated with your infrastructure and built from the ground up on AI based protection technologies?

Let's find out!

Testing it

First off, I set this all up in a "lab" that functions exactly like any other small business might have configured. A basic MS subscription with email and office. No fancy or advance settings configured beyond the basic pieces needed to get everything working. I then followed some of the blog posts I found to setup a simple cloud based server to run the PowerShell script from.

After executing the script, here is what a basic message looks like.

We can even impersonate valid internal addresses

Now savvy users may notice the differences and if your awareness training is working they will report it. But I should point out that some of the discrepancies here may just be from my relative lack of skills in crafting custom phishing attacks. A skilled attacker may be able to get this to look much more legitimate. The real problem is that it is getting to them at all. (Disturbing how easy it was to get this far)

So what does it look like with HEC in place?

I went ahead and enrolled my test tenant without changing or optimizing a single setting. Just defaults out of the box.

Side note: if you aren't familiar with this process, it takes about 5 min. After the initial connection, we let it sit for about 48 hours for the AI to train on your historical message logs.

Execute the script and boom.

Wait it made it through, what went wrong?

Let's look at the HEC console.

This is the Security Stack summary for the message we just send. So we can see a few interesting things here:

1. MS labeled the message as clean.

No big surprise here, the MS engines are still looking at Direct Send messages, but they are fairly limited in their sophistication, so not hard to bypass

2. Check Point did detect it as a Phishing attempt

The platform easily identified multiple issues with both the metadata of the message (SPF, Headers, etc) and the content of the message

3. The reason the message was delivered is that we are in Monitor only mode

One of the features we use to make sure we never impact operations on new deployments is that HEC always deploys initially into a Monitor Only mode. The system starts watching all the messages but won't take any action unless we specifically turn on enforcement.

With our lab here there is no need to worry about enforcement, so now that we know it was handled correctly let's take a deeper look at how the system evaluated the message.

Here we see dynamic nature of true AI based protection platform. We didn't have to manually set anything. The indicators based phishing and semantic AI models were not fooled at all. This is then combined with the email attribute risk markers and the message was caught.

Think about paradigm shift I mentioned earlier. The infrastructure provider wants you to implement an legacy protection system and add manual configurations or static entries. Your next generations protection system doesn't care about all that noise and just protects you. It feels a little weird right? We have to trust the models and protection algorithms without being able to see a table of rules that say block this and allow that.

While there is a certain level of comfort that comes from mapping each identified threat vector to a specific configuration item and it certainly makes auditors happy when people are applying a check-list style approach to security management, the truth is that sense of comfort was never a real reflection of how well you were protected.

Those of us who have lived it can tell the stories. Stories exploits, vulnerabilities, and countless hours spent diving into the legacy protection platforms and infrastructure systems with the digital equivalent of duct-tape and chicken-wire to create custom mitigations while we waited. Painfully waited, months or even years for the vendor to release an update with awareness of some new threat vector.

Those kinds of systems make it easy to check boxes and almost impossible to stay up to date with new threats as they are emerging. Threat Actors certainly don't wait until a new definition file or product update ships before they start leveraging the latest "feature" to be added by your infrastructure provider for your "convenience".

Now we have less to configure, and in this case a much higher functioning protection system, but we are left with a gap… How do we prove that we can trust the protection when we didn't tell the system anything about this specific threat?

The good news here, at least as far as it concerns Check Point products, is that we don't have to just blindly trust the AI to take care of everything. We can test and validate. Prove it is doing what we want. If we do find something unexpected, we can train it or tweak settings to adjust context or scope.

So let's be thorough and take it a little bit further to build up that confidence.

Validation

Let's take this exact message, sketchy text content and all, and send it back through the system but from a valid user account. Maybe a scenario where the end user just copy/pastes the message content over to IT because they think it is suspicious (not that that would ever happen, lol)

Now this is interesting! Look at that. Clearly the semantic models still threw up the red flag, but the message was allowed. The indicator analysis and message meta data now clearly indicate it was a legitimate internal message.

This is where the quality of the AI in your security toolset really comes into play!
Some important notes:
1. Yes we are protecting internal messages!

This is really important as it is possible someone's account may get compromised and they could try to target other users in the organization

Spoiler: we help protect against that scenario too!

2. My testing link is benign

I didn't show the URL analysis for brevity but the system would have also factored this in had it been sketchy
It will even go 10 levels deep chasing redirects, so no simple bypasses here

3. The system also understands the user to user relationships

Again for the sake of keeping this post from becoming too long I didn't include all the protection engines involved
This existing relationship is part of the context considered in marking this message clean

4. Notice the "First Time Sender" tag is gone?

Even with matching the email address, HEC recognizes the spoofed email is not the same "entity"
So why not just simply block off that?

I caught you thinking statically again, lol. There is a reason this Direct Send feature was created, while I don't like the implementation, it is nevertheless true that often senders will be "spoofed" internally for a variety of legitimate reasons. We don't create a static check box to block all of these because we don't need to. We will automatically only block the ones that are a threat.

Final test: Let's try again with benign text. Change our sample to something the semantic AI has already looked at and said "this is fine", then run that back through the Direct Send vector.

To get a good sample to steal the text from I went back through the logs to find a good candidate.

Execute the updated script and…

Hmm, it is possible to sneak a message through…. Let's take a look at the Security Stack Report.

So did we just break HEC? Not at all…

Remember there are actually legitimate use cases for this feature, so if a company is using it to send messages that are not a threat, then we do actually want those messages to be delivered. Technically we just proved that HEC won't block these legitimate messages. (as long as they are seen as clean by the protection engines)

However, that doesn't mean we can't make this a little better. Remember how we scoped this test? 100% default, out of the box settings with no changes. So if we want to strengthen our defenses here, we can setup the system to reject these messages from any IP addresses we don't include in our SPF.

I would argue that this doesn't really change that much, as our protection engines are ultimately what is going to keep us safe , but it does allow you to add a weight the analysis of the engines in this context so that as it will drop any attempts from un-controlled IP addresses. If you maintain good hygiene on your DNS records, this is probably a good tuning practice.

Also handy that it is a simple, single check-box.

Now we test again with the exact same message…

Et voila!

Summary

So does HEC protect against Direct Send base phishing attacks despite the fact that we don't use a legacy gateway/proxy based architecture or require a series of complex manual settings to mitigate it? Absolutely!

There is a change happening in how security administrators need to think about protection configurations. Advanced products like HEC are a driving force behind this change, but I think it will be largely a change for the better. It sort of becomes less like system administration and more like system mentorship.

In this example we did find some tuning of the system that can help mitigate the risks by changing the scope of messages allowed to be filtered. This will be a common pattern, sometimes it will be a setting, sometimes is will be training the AI engines, and sometimes it will testing or Red Team exercises to prove your protection works.

In the broader sense, we have to adapt our administration thought processes to the capabilities and nature of these new systems. We see it today in spaces like email security and Web Application Firewalls, but it won't stop there. We already have autonomous management of IPS protections in our network firewalls and AI policy suggestions for management is out now. The whole cybersecurity ecosystem will be following this pattern eventually. As admins, the better we are able to embrace the conceptual change the more value we will get out of this new generation of AI based protection systems.

Thanks for riding along with me on this one. Hopefully you found it insightful.

Editor's note: MS does indicate that they plan to enable the ability to turn off Direct Send at some point in the future. At the time of posting there was no official release date.

[PhoneBoy]

Thanks for sharing this rambling.
It might make an interesting podcast subject 🙂

[the_rock]

Nicely done, I can tell you put a lot of effort into it.

Andy

[D_W]

Nice post! After I forwarded it to our mail admin he was able to disable direct send. See also https://ourcloudnetwork.com/how-to-block-the-use-of-direct-send-in-exchange-online/#Block_the_use_of...