Forum Discussion
Marnik
Jan 15, 2025Brass Contributor
No URL Detection in Emails with Extensive %2580 Encoding
Hi Community,
I encountered a concerning issue where emails containing URLs with extensive encoding (%2580) completely bypassed all detection and security mechanisms. These encoded URLs weren’t identified as links, which allowed them to evade security scanning.
Issue Details:
- The email contained malicious URLs encoded with %2580.
- The URLs were not flagged or identified as links, allowing the payload to bypass filters entirely.
Questions:
- Has anyone else encountered similar issues with encoded URLs bypassing detection?
- What’s the best process to submit this email to Microsoft for analysis and improvements to detection mechanisms, since no URL's were identified?
Looking forward to your input and recommendations.
Thanks in advance!
- MarnikBrass Contributor
Indeed, thank you everyone for your feedback.
A temporarily mitigation action might be to set a transport rule for to identify usage of extensive encoding in email body (so we don't rely on URL extraction/parsing from MDO)?
MSFT team is aware of the issue since late January.
- CipherGhost_007Copper Contributor
I encountered similar issues. It seems Defender parses URLs from emails in a certain way. If the URL is embedded in an image or uses obfuscation techniques (like encoding), Defender might not extract it as a URL entity.
- ExMSW4319Steel Contributor
Yep, I call it the padded URL tactic. The padding is typically visually displayed as spaces so the recipient may just see "youtube.com ", a domain some marketing types love to put in signature blocks. Pattern matching has horrendous problems (test non-intrusively, kiddies) and I gave up when it seemed that any Youtube TLD was fair game. I am pretty sure I have seen the tactic used with other domains too. Stepping back from MDO, putting a block or warning on your web proxy won't do any good because it is the payload domain at the far end of the padding string that is the real threat. Just for once, it isn't the Google infrastructure being weaponised except tangentially for the reputation, and the real problem as the OP said is down to MDO not being able to display the value in Threat Explorer or, it seems, offer any detection except by peripheral factors.
I looked at a recent sample and the padding ran to over 4k characters prior to the payload domain. A quick Copilot check suggests that RFC-1035 sets a maximum host name length of 255 characters, so someone isn't checking bounds.
- Xblu3Copper Contributor
That's the issue we have observed in SOC I'm working in. Very long url build in a specific way: legitimate domain (like YouTube.com) followed by a lot of %20 or %2520 then '@' and then finally phishing Url. The Url is not detected in EOP... It basically shows 0 URLs in email. Microsoft please fix it ASAP.