Microsoft ATP是否会损坏邮件链接URL中的Base64编码路径参数

1. 触发字符修改的进程判定 #

• 首先排除诺顿、Outlook扩展类反追踪工具：这类工具的处理逻辑是直接删除、拦截整个追踪参数，或者替换完整链接，不会逐字符做偏移替换后还完整保留JSON语法结构。
• 触发修改的就是你已监测到IP归属的微软365 Defender（原ATP）Safe Links扫描模块，属于该模块的已知误判bug：
  • 该模块扫描入站邮件链接时，会自动识别疑似经过ROT13、凯撒移位等简单混淆的恶意链接参数，自动尝试解码后检测恶意内容。部分版本的检测逻辑存在误判，会将Base64解码后得到的结构化JSON误识别为混淆过的恶意参数。
  • 模块的替换规则仅匹配[a-zA-Z0-9]范围的字符做偏移计算，JSON用到的大括号、引号、冒号、逗号等语法字符不在混淆字符匹配范围内，因此外层JSON结构会被完整保留。
  • 你观察到的请求无明确可识别User Agent、全部来自微软官方IP段的特征，完全匹配Safe Links的行为：它会在邮件投递后、用户点击前做两次爬取，第一次是服务端离线扫描，第二次是用户点击时的实时校验，两次爬取都可能触发该误替换逻辑。
  • 可自行验证：所有触发损坏链接的请求，对应收件人使用的都是微软365/Outlook系列托管邮箱，使用Gmail、自建邮局等其他邮件服务的收件人不会触发同类问题。

2. 字符修改逻辑说明 #

• 该修改不是哈希、也不是针对特定字段的刻意混淆，是Safe Links内置的多套简单混淆解码规则误触发导致的逐字符替换：
  • 模块内置了ROT13、多位数凯撒移位、简单数字偏移等数套基础混淆解码规则，会对疑似混淆的字符串逐字符套用规则尝试还原，只要还原结果命中内置的恶意特征（比如形似资源ID、用户标识的字符串），就会直接将原字符替换为解码后的结果。
  • 你已总结的小写字母偏移规律，本质是不同位置的字符命中了不同解码规则：ROT13规则本身就是对g-m区间小写字母+13、n-z区间小写字母-13，a-f区间+1是凯撒移位1位规则的匹配结果，数字的数值变化也是同理命中了对应数字移位规则。
  • 字段名、字段值的对应关系不存在特殊映射：替换是逐字符独立进行的，和字段语义无关，你观察到的videoID转为ivefbVE、CA220502FR转为DB553835AE，只是每个字符单独命中对应移位规则后的结果，不存在针对特定业务字段的定向修改逻辑。
• 你判断的“不可逆”是因为该替换没有全局统一偏移量：同一个字符在字符串不同位置可能命中不同的移位规则，因此无法通过固定转换公式还原原始内容。

业务侧临时规避方案 #

• 避免直接将Base64编码的JSON明文放在URL路径中，可在Base64外层增加一层URL安全的AES对称加密，或给参数增加签名校验，服务端收到请求时先验签，验签不通过直接返回400，避免扫描器误改产生的无效请求污染业务日志、触发缺陷告警。
• 可调整魔术链接的路径格式，增加无意义随机路径段，降低被ATP参数识别规则命中的概率，减少误判。

内容的提问来源于stack exchange，提问作者DanielTheDifficult