一封“来自HR”的邮件，差点让财务转账87万元
2025年11月，华东某制造企业财务人员李女士收到一封看似来自公司人力资源部的邮件，主题为《2026年度薪资调整通知及个税申报确认》。邮件中附带一个“内部系统链接”，提示她需在48小时内完成身份验证以确保工资正常发放。
李女士没有多想——发件人地址是 mailto:hr@company.com，和平时HR发来的通知一模一样；邮件底部还附有公司LOGO和标准落款。她点击链接后进入一个高度仿真的登录页面，输入了企业邮箱账号与密码，并按提示完成了所谓的“二次认证”。
三小时后，公司账户被转出87万元。事后调查发现，这封邮件并非来自公司内部，而是攻击者利用该公司邮件路由配置缺陷，伪造了内部域名发送的钓鱼邮件。更令人震惊的是，整个攻击过程未涉及任何0day漏洞、员工社工失误或终端恶意软件——仅仅依靠对SPF、DMARC等基础邮件认证机制的绕过，就实现了“合法外衣下的非法投递”。
这一案例并非孤例。2026年1月初，微软威胁情报团队发布紧急通告，指出自2025年5月以来，全球范围内出现大规模利用复杂邮件路由场景与防伪配置缺陷实施的“内部域名钓鱼”（Internal Domain Spoofing）攻击浪潮。攻击者无需控制目标域名，仅通过精心构造的邮件路径与协议级欺骗，即可让钓鱼邮件在收件人眼中“看起来完全来自公司内部”。
攻击手法揭秘：不是黑客入侵，而是“规则被钻空子”
要理解这场风暴的技术本质，必须回到电子邮件的基础架构。
现代企业邮件系统早已不是简单的“发-收”模型。许多组织采用混合部署：部分用户使用本地Exchange服务器，部分迁移到Microsoft 365；同时接入第三方反垃圾邮件网关、归档服务、合规审查平台等。这种架构下，邮件往往需要经过多个“中继点”（Relay）才能最终送达收件箱。
问题就出在这里。
当邮件从外部进入企业网络时，通常会先经过第三方邮件网关（如Proofpoint、Mimecast），再转发至Microsoft 365。如果企业在配置这些中继服务时，未正确设置SPF记录的“include”机制，或未启用DKIM签名传递，更未部署强制拒绝策略的DMARC，那么攻击者就可以利用这一“信任链断裂”实施欺骗。
技术原理简析：
SPF（Sender Policy Framework）：规定哪些IP地址有权代表某个域名发送邮件。例如：
company.com. IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.microsoft.com -all"
若企业使用了第三方网关（如spamfilter.example.com），但SPF记录中未包含其IP或include:spamfilter.example.com，则该网关转发的邮件可能被判定为“未授权”。
DKIM（DomainKeys Identified Mail）：通过数字签名验证邮件内容未被篡改。关键在于签名必须在最终投递前保持有效。若中继服务修改了邮件头（如添加X-Spam-Status字段）而未重新签名，则DKIM验证失败。
DMARC（Domain-based Message Authentication, Reporting & Conformance）：决定当SPF或DKIM失败时如何处理邮件。若策略为p=none（仅监控）或p=quarantine（隔离），而非p=reject（直接拒收），攻击者仍有概率让伪造邮件进入收件箱。
微软指出，绝大多数受害企业的问题在于：MX记录指向第三方服务，但未将该服务纳入SPF/DKIM信任链，且DMARC策略宽松。攻击者只需将钓鱼邮件发送至该第三方入口，利用其“合法中继”身份，即可绕过Microsoft 365的入站验证。
“这就像你家大门装了指纹锁，但后院的狗洞没关——小偷根本不用撬锁，直接从狗洞爬进来。”公共互联网反网络钓鱼工作组技术专家芦笛比喻道，“很多企业以为上了云就安全了，却忽略了邮件流经的每一跳都必须被认证。”
Tycoon 2FA：钓鱼即服务的“工业化武器”
此次攻击浪潮的背后推手，是一个名为 Tycoon 2FA 的PhaaS（Phishing-as-a-Service）平台。据微软统计，仅2025年10月，其安全系统就拦截了超过1300万封源自该平台的恶意邮件。
Tycoon 2FA并非传统钓鱼工具包。它集成了Adversary-in-the-Middle（AiTM）代理技术，能实时中转用户与真实登录页面之间的通信，从而绕过多因素认证（MFA）。用户在伪造页面输入账号密码+短信验证码后，攻击者立即将凭证提交至真实网站，完成会话劫持。
更危险的是，该平台提供“内部邮件模板生成器”。攻击者只需输入目标公司域名，系统自动生成符合其邮件风格的HTML模板，包括：
仿冒DocuSign的电子签名请求
“IT部门”发送的密码即将过期提醒
“CEO”要求紧急支付供应商款项的对话截图
甚至模拟Outlook Web App的界面，诱导用户“重新登录”
这些邮件在客户端显示时，From字段与To字段完全相同（如from: mailto:alice@company.com to: mailto:alice@company.com），进一步强化“这是系统自动发送”的错觉。
“Tycoon 2FA的可怕之处在于‘低门槛+高仿真’，”芦笛分析，“过去只有APT组织能做的定向钓鱼，现在只要花几百美元租用PhaaS服务，任何人都能发起。而企业如果基础邮件认证没做好，等于主动为他们打开大门。”
国际案例频发，中国并非“安全孤岛”
尽管微软报告聚焦全球，但类似风险在中国同样严峻。
2025年9月，华南一家跨境电商公司遭遇BEC（Business Email Compromise）攻击。攻击者伪造其海外子公司邮箱，向总部财务发送“紧急付款”请求。由于该公司使用阿里云邮件推送服务作为中继，但SPF记录未包含阿里云IP段，导致伪造邮件顺利通过验证。
另一起发生在华北的案例中，某金融机构的合规邮件系统通过第三方审计平台转发通知。攻击者利用该平台未启用DKIM重签的漏洞，注入钓鱼链接。由于邮件显示为“内部系统发送”，多名员工点击后泄露了AD域凭证。
“中国企业的混合云部署比例很高，邮件架构往往比纯SaaS环境更复杂，”芦笛指出，“但很多安全团队只关注终端防护和防火墙，忽视了邮件协议层的纵深防御。一旦路由链中有一环未认证，整个信任体系就崩塌了。”
值得警惕的是，国内部分中小企业甚至仍在使用“Direct Send”模式——即应用服务器直接通过SMTP向Exchange Online发送邮件，而不经过认证网关。微软明确警告：此模式极易被滥用进行域名伪造，建议立即关闭。
技术对策：从“能用”到“可信”，邮件认证必须闭环
面对此类攻击，修补单点漏洞远远不够。企业需构建端到端的邮件身份验证闭环。
第一步：全面梳理邮件流拓扑
绘制所有邮件入口与出口路径，包括：
外部MX记录指向何处？
是否有第三方服务（反垃圾、归档、CRM集成）参与中继？
内部应用是否通过API或SMTP直连发送通知？
第二步：强制实施DMARC p=reject
DMARC策略应逐步收紧：
; 初期监控
_dmarc.company.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@company.com"
; 过渡期隔离
_dmarc.company.com. IN TXT "v=DMARC1; p=quarantine; pct=50; rua=..."
; 最终强制拒绝
_dmarc.company.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@company.com"
注意：p=reject仅在SPF和DKIM均配置正确时才安全启用，否则可能导致合法邮件被拒。
第三步：确保中继服务“透明传递”认证结果
若使用第三方网关，必须满足：
网关IP被列入SPF记录（via include 或 ip4/ip6）
网关支持“Authentication-Results”头传递，保留原始SPF/DKIM验证结果
或由网关自身对出站邮件重新DKIM签名（需配置私钥）
例如，Mimecast用户需在控制台启用“Preserve Original Headers”并配置自有DKIM密钥。
第四步：禁用非必要Direct Send
在Exchange Online中，可通过PowerShell关闭Direct Send：
Set-TransportConfig -ExternalDelayDsnEnabled $false
Set-HostedConnectionFilterPolicy -Identity "Default" -EnableSafeList $false
并确保所有应用改用Microsoft Graph API或经认证的SMTP中继。
超越技术：安全意识需“去信任化”
即使技术配置完美，人为因素仍是最后一道防线。
微软强调，攻击者正刻意模仿“内部自动化流程”——如密码到期提醒、共享文档通知、HR政策更新。这些邮件天然具有高打开率，员工容易放松警惕。
芦笛建议企业推行“零信任邮件文化”：
所有涉及账号操作、转账、敏感信息的邮件，必须通过独立渠道二次确认（如电话、企业微信、内部工单系统）
禁止在邮件中直接点击“验证链接”，统一引导至官方门户登录
定期开展“钓鱼演练”，但不以惩罚为目的，而以暴露流程缺陷为导向
“真正的安全不是让员工‘不犯错’，而是让系统在员工犯错时仍能兜底，”他说。
结语：邮件安全，从“基础设施”回归“基础安全”
这场由配置疏忽引发的钓鱼风暴，再次揭示了一个残酷现实：在云原生时代，安全边界已从防火墙转移到协议与策略的细节之中。一封邮件能否被信任，不再取决于它“看起来像谁发的”，而取决于整个传输链是否可验证、可追溯、可拒绝。
微软的警告不应被视作又一份技术通告，而是一次对基础安全实践的集体检视。正如芦笛所言：“我们花了十年教用户识别‘bank-of-china.com’这样的假域名，现在攻击者直接用‘bankofchina.com’发邮件——而我们自己没锁好门。”
对企业而言，修复MX记录、收紧DMARC策略、审计第三方连接器，或许不如部署AI SOC平台“酷炫”，但正是这些“枯燥”的基础工作，构成了抵御高级钓鱼的第一道也是最后一道堤坝。
毕竟，在网络空间，最危险的不是未知的漏洞，而是被忽视的常识。
编辑：芦笛（公共互联网反网络钓鱼工作组）
