Possible major problem with MS Defender scanning/clicking links??

[Alex Kwitny]

Our organization has a process that emails users "magic links" to approve/reject various workflows.

All of our troubleshooting points to something systematically "clicking" the first link in the email and I think it's Microsoft Defender for O365 somehow validating/exploring links?

Is this a possibility and what would be the best way to prove/disprove/fix?

As of a few days ago, these workflows are getting approved from the "magic link" immediately as the email is received. The first link in the email is "Approve" and "Reject" is the second link. I swapped the order and now they're getting automatically rejected as soon as the email is received.

[#2]

I was able to turn on IP logging and I can prove that Defender is clicking on these links and submitting them!

What feature/functionality of Defender would be responsible for this and/or how do I disable it?

[#3]

URL detonation is a feature your organisation signed up for with MDO: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/protection-stack-micros...

You can exempt given URL host names in your Safe Links policy, but that only stops encapsulation. The detonation tests might still happen.

If your magic link is in a public domain then you might not want to lift Safe Links protection anyway. If your magic link is in a private subdomain of a public domain then I am not even sure an exemption is possible. If your magic link is in a private domain that only your internal recipients can resolve, that might work - internally only.

You cannot write a separate policy turning off Safe Links because Safe Link policies are applied by recipient, not sender. Presumably you have many internal recipients who want to receive unclicked magic links but whom you otherwise want protected by Safe Links.

Finally, consider this: if MDO URL detonation can cause a premature click then anyone who could guess a link could click it. You have no authorisation in your process.

[#4]

@ExMSW4319 Wow that's great to know the actual terminology for what's happening; "URL detonation" and that explains things.

You can exempt given URL host names in your Safe Links policy, but that only stops encapsulation. The detonation tests might still happen.

I agree this doesn't sound like it would solve it if it's only exempting the "sandboxing" behavior.

If your magic link is in a public domain then you might not want to lift Safe Links protection anyway. If your magic link is in a private subdomain of a public domain then I am not even sure an exemption is possible. If your magic link is in a private domain that only your internal recipients can resolve, that might work - internally only.

The magic links are private subdomain of a public domain and basically this:

https://<privatesub>.servicebus.windows.net/Email/applyURLActionWithComment?action=Approve&Key=bd2cc52e-05ac-49b3-9762-45ad9c977970

It sounds like an exemption might not be possible.

What I did manage to do is create a transport rule that says basically "any email coming from <MagicLinkSendingEmail>[@]MyCompany.com bypass the anti-phishing checks completely". This seems to have worked, but then technically an external sender could spoof that one special exempt email and get by the MDO checks.

Finally, consider this: if MDO URL detonation can cause a premature click then anyone who could guess a link could click it. You have no authorisation in your process.

The solution uses GUIDs and things so it's not guessable, but the product/solution that's broken is actually Microsoft's but it's an older product that they've broken. It's not my favorite thing they've released but it's all that works with the older product.