If you'd asked me before today if you could forge a legit Microsoft address on a scam message and have it pass DMARC I'd have said no way. But that just happened. Message originated from a malicious M365 tenant. Exchange Online added two DKIM sigs - the tenant’s MOERA domain and a valid d=microsoftonline.com platform signature. Because the forged From address also matched microsoftonline.com, DMARC passed solely on the platform DKIM, even though SPF failed multiple times. This is nuts; basically anyone can forge a microsoftonline.com address when sending from M365 infra. I now have a transport rule that bumps SCL on any message from microsoftonline.com with failed SPF.

When I was at school I had to learn a dead language (Latin). I hated it. Now having to learn a complex vendor-specific query language that is about as painful and probably soon to be about as dead. Timely comments from @riskybiz, though I think perhaps not everyone is awake to the new reality yet!

I've seen several homonym domains used in phishes lately, all registered immediately before they were used, all with solid SPF, DKIM, DMARC, M365 hosted. Seems like Microsoft are missing a trick in not providing a way of blocking newly-registered domains in Exchange. And clearly not doing much to prevent the hosting of malicious domains in M365 either!

Great brief update on the status of passkeys from @ollie_whitehouse who makes a good point that change needs to be forced on businesses by insurers. https://podcasts.apple.com/gb/podcast/ncsc-cyber-series/id1742556737?i=1000704578142

Query for the #Entra nerds; have Continuous Access Evaluation and Token Binding always been enabled by default with supported apps even in the absence of a Conditional Access policy?