本案样本发现于 Outlook 收件箱, 由 NodeSeek 论坛成员提供.

【求助】记录一封离奇的钓鱼邮件

该案样本利用了疑似受损的邮件系统和网页 iframe 对未实施 DMARC 策略的域名下用户发起钓鱼攻击, 尝试通过网页表单诱骗用户提交他们的邮箱及密码, 因此作为现代钓鱼邮件的典型而在本案分析.

邮件样本

查看链接

提示

为了最大程度保留样本和保护本案样本提供者(原受害者贴文设有权限墙), 样本的目标受害者替换为了来自公共威胁情报样本, 替换的内容包含发件人地址, 收件人地址, 唯一钓鱼网页参数和受害者网页, 本案继续使用「原始受害者」表示样本第一来源.

邮件样本预览
邮件样本预览
钓鱼网页预览
钓鱼网页预览

传递路径

跃点发送方接收方时间延迟类型
1[198.12.123.8] (port=50179 helo=198-12-123-8-host.colocrossing.com)5508667.revistamedicagt.org2/25/2025 3:04:52 PMesmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from sede.jalapa+bounce@colmedegua.org)
25508667.revistamedicagt.org (162.241.142.128)cloudflare-email.net (unknown)2/25/2025 3:04:52 PM0 seconds
3c-bje.cloudflare-email.net (104.30.2.194)****.mail.protection.outlook.com (10.167.17.71)2/25/2025 3:04:54 PM2 secondsMicrosoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384)
4****.namprd04.prod.outlook.com (2603:10b6:5:3b4:cafe::f6)****.outlook.office365.com (2603:10b6:5:3b4::19)2/25/2025 3:04:54 PM0 secondsMicrosoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384)
5****.namprd03.prod.outlook.com (2603:10b6:5:3b4::19)****.KORP216.PROD.OUTLOOK.COM (2603:1096:101:2a::10)2/25/2025 3:04:56 PM2 secondsMicrosoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
6****.KORP216.PROD.OUTLOOK.COM (::1)****.KORP216.PROD.OUTLOOK.COM2/25/2025 3:04:57 PM1 secondHTTPS

发送方身份为 sede.jalapa@colmedegua.org, 接收方为 inbound@outlook.com, 被利用的邮件系统是由 HostGator Email 代托管的属于 revistamedicagt.org 的邮件服务器.

分析

这是封典型的钓鱼邮件, 目的是索取目标用户的邮箱账号和密码.

传递分析

在覆盖公共威胁数据之前的原始样本中的受害者实践和遭遇来看, 原始受害者的邮箱 users@example.com 公布在同域名 example.com 的公共网页之上, 域名使用 Cloudflare Email Routing 来接收邮件, 原始受害者虽然按照 Cloudflare 的指引设置完成了 SPF 和 DKIM, 但没有继续设置 DMARC 策略, 并且继续使用了 Cloudflare 指引提供的 softfail 默认 SPF 记录.

从传递路径来看, 攻击方使用了 HostPapa Inc. 旗下的 ColoCrossing 托管主机连接到发信服务器 revistamedicagt.org, 使用了 MAIL FROM 身份 sede.jalapa+bounce@colmedegua.org 直接向原始受害者的邮箱 users@example.com 发送了 From 标头为 noreply@example.com, 这个 MAIL FROM 通过了 SMTP 服务器验证成功发送邮件, 进入 Cloudflare 并通过了 MAIL FROM 的地址所属域名 colmedegua.org 的 SPF 认证, 然后 Cloudflare 继续通过 ARC 签名签署了验证通过的标头, 转发给了 Outlook, 而最终抵达 Outlook 后显然已经成了一封「合法」邮件了, 并且还直接通过了 Microsoft 的过滤.

为了让整个传递链策略更清楚, 这里将列出他们的传递策略:

发送方SPFDKIMDMARC
colmedegua.org"v=spf1 +a +mx +ip4:162.214.105.143 ~all"❌❌
example.com"v=spf1 include:_spf.mx.cloudflare.net ~all"✅❌

说实话, 如果忽略邮件内容的意图, 这封邮件只是传递策略有缺陷的合法邮件, 因为在 Outlook 看来它已经基本符合了发送方和接收方声明的策略, 而且最终入站前还有 ARC 签名的验证结果, 还是从 Cloudflare 发送来的邮件.

最后可能是各方的策略都不完整, 发送方地址和实际身份不符或者内容还是被扫描出来了问题, Outlook 给到的置信等级非常低: X-MS-Exchange-Organization-SCL: 9 (最低分数).

不过最为奇怪的是, 这封邮件最终却还是被放进了收件箱(dest:I), 不得不让人感叹 Outlook 过滤机制的玄妙.

意图分析

由于 From 标头被设置为了 noreply@example.com, 使得受害人 users@example.com 单纯直接看 "发件人" 虽然会感到疑惑但找不到问题, 发件方在赌 MUA 不会加以代发提示并且受害人没有分析邮件源代码的能力.

邮件使用了非常规整的 HTML 模板, 并且还特意通过获取网站 Favicon 的 API 将受害者网站的图标展示在了邮件标题上, 标题和页脚关键词也都和网站完全对应.

主要的索取密码入口的按钮背后链接为:

1
https://secure.adnxs.com/clktrb?id=704169&redir=https://auth-****.pages.dev%3Fms%3D****%26auth%3D****

可以看出, 钓鱼链接的真实入口被编码在一个链接重定向中间页中, 这个中间页属于 Adnxs, 这是一个臭名昭著的通过恶意跳转来推送广告的平台, 这个 adnxs.com 起始的所有域名目前已经被主流的广告拦截器拦截. 经过情报中的记录, 该类型的钓鱼曾经还用过其他不同的中间页.

钓鱼网页主体托管在 Cloudflare Pages, 使用的是固定前缀的随机 pages.dev 域名, 使用 iframe 直接将受害者邮箱域名所属网站嵌入了钓鱼网页中. 只有其中的表单组件才是属于网站本身的元素, 这个表单还会会随着访问者用户代理提供的语言信息变换显示组件显示语言, 网页和组件整体的设计也很规整. 钓鱼网页带有反 DevTools 调试特性, 会在用户打开控制台后跳转回上一个页面.

输入框中的用户名应该是直接从参数传递给 JS 脚本解密后填充在输入框中. 网页脚本还会通过 API 接口判断受害者所属域名网站是否允许 iframe, 如果不许允许嵌入则 API 会返回:

1
2
3
{
  "iframe-allow": false
}

如果允许 iframe 嵌入则会返回 "iframe-allow": true, 用来判断是否可以被嵌入, 避免强行嵌入导致浏览器显示错误页面成为网页背景, 让受害者发现异常.

该钓鱼网页使用的外部 API 如下:

用途示例
iframe 嵌入https://contextio.one/zwrtqpljgh/assets/js/script.php
目标 iframe 政策判断https://contextio.one/zwrtqpljgh/lookup.php?type=website&domain=example.com
CORS 代理https://cors.contextio.one/https://example.com
表单提交https://contextio.one/zwrtqpljgh/form/post/index.php

整个钓鱼页面最核心的 "要犯" 域名其实是 contextio.one, 注册于 2024 年 4 月 3 日, 通过 DNS 解析最后都归于 IP 地址 68.65.123.149, 这是归属于 Namecheap, Inc. 的 IP 地址.

处置

如果你是用户或邮件管理员, 当遭遇这类邮件时应该如何处置呢?

用户

对于没有经验的用户来说, 这类钓鱼邮件设计得非常规整隐蔽, 如果没有被邮箱的反垃圾系统过滤, 甚至还放进了收件箱中, 那么普通用户看到这类邮件是有很大的概率点进去的, 然后被网页中本来就来自己网站的风格和布局甚至内容唬住, 这个钓鱼表单就活脱脱的是一个从自己网站上弹出来的弹窗.

不过, 只要仔细看看地址栏就会发现端倪, 域名使用的是随机的 pages.dev 地址, 并不属于自己的域名. 而且本身就是自己的网站, 用户自己应该能够明白网站到底有没有设计这种账户和密码提交的弹窗表单. 但是如果受害者身份从域名和网站管理员转换为网站用户, 那么上述基本方法可能就完全行不通了, 他们可能本来就不熟悉域名这种概念, 更不知道自己在使用的网站到底有没有这种提交表单, 被钓鱼的可能性是非常高的.

作为设计处处小心的很现代的钓鱼网页, 对于没有经验的用户, 笔者在此能给出的最为有效的办法只有:

  • 使用安全的密码管理器, 它能自动化辨别近似和错误的用户登录页地址, 不会提交密码给不正确的网页.
  • 使用广告拦截器, 如 uBlock Origin 和 AdGuard, 或者其他的安全替代产品.
  • 执行账户控制权限修改之前先咨询网站管理员.

其他的预防性教育笔者不想在此赘述, 对于用户来说这类教育可能已经耳朵都听出老茧了, 但最终还是会被钓鱼攻击, 把密码亲手提交给攻击者.

管理员

如果自己的邮件服务器已经收到了这类邮件, 请首先警告进入收件箱和垃圾箱的用户不要相信该邮件, 将邮件提交给过滤器学习或报告给供应商.

然后, 检查自己的传递策略, 确保配置好严格的 SPF, DKIM 和 DMARC 策略. 对于本案原始受害者这类使用 Cloudflare Email Routing 的域名, 可以参考本站的运营专栏文章:

保护仅收件或闲置域名免遭伪装发件利用 - 邮件人

根据本案具体样本的分析, 发送方服务器很可能已经被攻击者控制, 也很有可能是被相似钓鱼攻击获取来的身份凭证, 所以在协商解决问题之前可以考虑将发送方身份, 主机和 IP 暂时加入黑名单.

对于自身站点, 可以尝试设置 X-Frame-Options 和 Content-Security-Policy 标头控制 iframe 政策, 避免被恶意嵌入利用, 不过这也同时会影响用户在其他平台嵌入你的网站, 需要仔细设置范围.

来到了主动协商部分, 如果管理员有时间应该和多方报告和协调问题:

  • 向 ColoCrossing 报告其托管服务器被用于钓鱼邮件发送.

  • 向 HostGator 报告其代托管邮件服务器已经被入侵和滥用.

  • 向 Cloudflare 报告 Pages 滥用.

  • 向 NameCheap 报告其 DNS 和托管网站被用于钓鱼信息收集.

  • 向 NameSilo (注册商)报告钓鱼网页核心 API 端点域名.

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。

分享文章

快来参与讨论吧~