When “block” doesn’t mean necessarily “block”

I just came across this and I was really puzzled as I never thought something like this would happen:

What do you expect, if you use a feature, which states that you could block specific senders?

Right, you feed the system and messages from these senders will never made it to protected recipient.

Well, let me tell you that the feature Tenant Allow/Block List (TABL) of Microsoft Defender for Office 365 (MDO)is exactly doing this:

Promising that you can block senders, but actually deliver messages to mailboxes depending on your anti-spam policy settings.

Symptom

I was approached by our cyber defense team as they saw that emails from senders, which are supposed to be blocked, delivered to recipients.

Note: I’m aware that blocking sender addresses is NOT a final solution for protecting your environment. However, it makes sense for those senders/domains, where your solution has not yet treated those messages as malicious!

Analysis

After looking into some examples, I could shed some light into the behavior and a Sev A case confirmed that this is “by design”.

But let me show what happens:

I added a specific sender on the TABL as described in this article:

Manage your blocks in the Tenant Allow/Block List – Office 365 | Microsoft Docs

TABL entry to block a specific sender

Now I’m sending a message from this sender to me.

Note: I’m using Swaks – Swiss Army Knife for SMTP (jetmore.org) for this on my Pi. I can really recommend this tool for tests like this.

You can see that EOP is accepting the message on SMTP protocol level (not like our previous system, which blocked messages at this point!) and the message of the “Blocked sender” is delivered to my Junk Folder:

The headers show that the value of the message header X-MS-Exchange-Organization-SCL was set to 9, which means High Confidence Spam. Also the value for CAT is set to HSPM, which represents the category of protection policy. You can find more details here:

Anti-spam message headers – Office 365 | Microsoft Docs

Analysis of message header

I also checked the Threat Explorer and even here I could find this statement:

Blocked by organization policy / Tenant Allow/Block List sender email address blocked

As you can see it will show the GUID of the policy/rule, which was hit by this item. In this case we have the action MoveToJmf:

The policy and its defined actions

The outcome of the case just confirmed our assumptions:

Official statement from Microsoft

The overall behavior is “by-design”.

I really tried hard to find any documentation on Docs, which explains this and that TABL for senders is acting based on the anti-spam policy a user is assigned to, but I failed. And not only this: how can you name a feature with “block” and don’t do anything related to?

These are the links to the documentation, where I took the screenshots:

Manage your allows and blocks in the Tenant Allow/Block List – Office 365 | Microsoft Docs

Manage your blocks in the Tenant Allow/Block List – Office 365 | Microsoft Docs

Maybe I’ve overseen something. I’m very confident that Microsoft will update the documentation to highlight the dependencies to anti-spam policies.

While I’m complaining about this, I also want to highlight another topic related to TABL:

I was really happy, when I read about the ability to delegate maintaining the entries by assigning a role to the responsible teams:

Tenant AllowBlockList Manager

This is the role, which needs to be assigned in the new Security Center and should allow the colleagues to maintain the entries. Unfortunately this is not true. Microsoft is trying to get this fixed for months, but is not able to do so. It should be easy as described in Docs:

Manage your allows and blocks in the Tenant Allow/Block List – Office 365 | Microsoft Docs

You need to be assigned permissions in the Microsoft 365 Defender portal before you can do the procedures in this article:

You need to be assigned permissions in the Microsoft 365 Defender portal before you can do the procedures in this article:

required permissions for TABL

There is a clear “or” in between all the roles. I’m testing this now and then, when I get approached by the support engineer to test this (I don’t understand why customers have to perform testing…).

All I can say is how it looks with the role assigned and how it should look like:

Conclusion

Maybe I’m the only one, but I strongly believe that Microsoft can and should do much better. Just updating the documentation would not reflect all the names of the feature, which actually costs licences!.

Or they would need to rename also the UI and all Cmdlets related to.

If you are using this feature, be aware of and open a case as a DCR will be created and the more complains the responsible Product Group receives, the higher the chance to get this really fixed and maybe a real block will be implemented.

2 thoughts on “When “block” doesn’t mean necessarily “block”

  1. Pingback: Migrating to and Using Microsoft Defender for Office 365 | Prime News List

  2. Pingback: Bermigrasi ke dan Menggunakan Microsoft Defender untuk Office 365 | Seids.live

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s