本文转载自 mailer.su ，文章内容是群友写的，不过收到垃圾邮件与提供邮件样本的是笨蛋博主，因此在征得群友的授权后转载到了这里~
原文：https://www.mailer.su/wiki/spam-analysis/google/case-google-groups/
案例 #1
本案例样本的是在 Exchange Online 的垃圾箱中发现的, 作为一个典型的使用邮件列表发送未经同意邮件的例子而在本案中分析.
邮件样本
传递路径
| 跃点 | 发送方 | 接收方 | 时间 | 延迟 | 类型 |
|---|---|---|---|---|---|
| 1 | mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) | mx.google.com | 2/11/2025 2:43:35 AM | SMTPS | |
| 2 | 2002:a50:d49c:0:b0:5de:6049:7bb5 | 2/11/2025 2:43:36 AM | 1 second | SMTP | |
| 3 | 2002:aa7:c891:0:b0:5de:5a2a:b0f9 | 2/11/2025 2:43:39 AM | 3 seconds | SMTP | |
| 4 | ****.google.com | 2/11/2025 2:49:26 AM | 5 minutes 47 seconds | SMTP | |
| 5 | ****.google.com (2a00:1450:4864:20::547) | ****.mail.protection.outlook.com (2603:1096:f:fff5::4) | 2/11/2025 2:49:26 AM | 0 seconds | Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) |
| 6 | ****.apcprd02.prod.outlook.com (2603:1096:4:b8:cafe::26) | ****.outlook.office365.com (2603:1096:4:b8::13) | 2/11/2025 2:49:27 AM | 1 second | Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) |
| 7 | ****.SGPP274.PROD.OUTLOOK.COM (2603:1096:4:b8::13) | ****.apcprd04.prod.outlook.com (2603:1096:400:210::8) | 2/11/2025 2:49:27 AM | 0 seconds | Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) |
| 8 | ****.apcprd04.prod.outlook.com (::1) | ****.apcprd04.prod.outlook.com | 2/11/2025 2:49:30 AM | 3 seconds | HTTPS |
发送方为 serviice@uxa.tamtamtai.vn, 接收方为 i@example.com, 被利用的邮件系统是 Google Workspace 和 Google Groups.
分析
从传递路径和消息标头中的 List-Subscribe 就可以看出发送者是利用了 Google Groups 作为邮件列表工具, 将目标邮箱未经许可就添加到列表中, 然后使用 Google Workspace 作为 MTA 发送了第一封邮件到达这个 Google Groups 群组, 然后 Google 就将这封邮件转发到群组中的所有目标成员.
接收方从未主动注册或同意过发送方发送该类邮件, 因此到这里就已经完全构成垃圾邮件的定义. 而且内容也非常可疑, 也有理由将它定义为诈骗邮件. 发送方的站点看似是个越南的法律咨询服务, 但邮件的内容却是只有一张图片的减肥软糖广告, 还用的是 Blogger 的外链图片, 内容还是蹭的明星歌手 Adele 的流量, 这些内容如果直接写成文字的话恐怕更难通过 Exchange Online 的垃圾邮件过滤器, 所以发送方直接将全部内容写在了图片里面, 还使用了 Blogger 的图片外链以提高检查通过的概率.
个人用户使用 Google Groups 的时候是不允许直接将非 Gmail 用户添加到群组的, 但商业版本也就是 Google Workspace 里的管理员却是能够直接将任意邮件地址直接添加到群组, 甚至还提供了 CSV 上传.
Add or invite users to a group - Google Workspace Admin Help
那么发送方是如何找到这些收件人地址的呢? 排除掉公网爬虫抓取邮箱地址, 其实笔者认为更有可能其实是只从某个源中获取了域名清单, 然后穷举了常用的地址, 比如本案中收件人的 i@example.com 中的 i 就是一个非常常用的地址名称但又不是共识中的保留地址, 当然其他的保留地址也是此类容易被穷举后当作目标的地址.
本案中的发送方身份也并非是被利用的, 它甚至连 DMARC 策略都没有配置. 而笔者在前往查询这个越南国家顶级域的 Whois 信息时发现所有查询服务都无法获取 Whois 结果, 令人感叹. VNNIC:什么叫做 Whois 隐私啊? (后仰)
处置
如果你是用户和邮件管理员, 当遭遇这类邮件时应该如何处置呢?
用户
对于用户来说, 一般的现代邮件客户端在接收到 Google Groups 这类标准的邮件列表的邮件时会识别其中的特征标头, 一些邮件列表软件还会直接像营销邮件一样添加 “Unsubscribe” 超链接在邮件尾部以供收件人退订. 邮件客户端会将 List-Unsubscribe 乃至 “Unsubscribe” 作为一个退订入口包装后展示在用户面前, 提醒用户可以退订该邮件, 用户点击按钮之后就会自动请求退订.
但如果邮件客户端没有展示包装入口, 用户如果要退订此类邮件就只能打开邮件源代码, 检查 List-Unsubscribe 标头字段中的值, 在本案中即为:
1 | List-Unsubscribe: <mailto:googlegroups-manage+****+unsubscribe@googlegroups.com>, |
可用的值有两个:
mailto:googlegroups-manage+****+unsubscribe@googlegroups.com: 指示的是向其中的邮件地址发送一封空标题空正文的邮件即可退订[1].https://groups.google.com/a/uxa.tamtamtai.vn/group/n/subscribe: 通常直接访问该地址就能直接管理自己的 Google Groups 在该群组中的成员状态, 但由于本案是 Google Workspace 直接没有邀请就创建的群组, 所以用户没有办法自行在网页管理自己的成员状态, 是无效的退订入口.
管理员
- 向 Google 提交滥用举报(包括 Workspace 和 Blogger 两部分).
- 向域名注册局提交滥用举报.
- 向 DNS 解析服务器提交滥用举报.
- 向网站解析 IP 的 ASN 管理员提交滥用举报.
- 添加发送方域名到入站黑名单.
注释
案例 #2
本案例实际上和《Google 案例 #1》几乎相同, 同样发现于 Exchange Online 的垃圾箱中. 只不过入站路径和被利用的对象发生了变化, 作为一个补充的例子在这里单独列出.
邮件样本
传递路径
| 跃点 | 发送方 | 接收方 | 时间 | 延迟 | 类型 |
|---|---|---|---|---|---|
| 1 | .smtp-out.amazonses.com (.smtp-out.amazonses.com. [54.240.9.46]) | mx.google.com | 2/9/2025 12:57:39 AM | ESMTPS | |
| 2 | 2002:a05:622a:6107:b0:467:5ee5:b23 | 2/9/2025 12:57:39 AM | 0 seconds | SMTP | |
| 3 | ****.google.com | 2/9/2025 1:01:11 AM | 3 minutes 32 seconds | SMTP | |
| 4 | ****.google.com (2607:f8b0:4864:20::f46) | ****.mail.protection.outlook.com (2603:1096:20f:fff4::88) | 2/9/2025 1:01:11 AM | 0 seconds | Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) |
| 5 | ****.apcprd03.prod.outlook.com (2603:1096:4:1f4:cafe::51) | ****.outlook.office365.com (2603:1096:4:1f4::17) | 2/9/2025 1:01:13 AM | 2 seconds | Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) |
| 6 | ****.apcprd02.prod.outlook.com (2603:1096:4:1f4::17) | ****.apcprd04.prod.outlook.com (2603:1096:405:44::13) | 2/9/2025 1:01:14 AM | 1 second | Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) |
| 7 | ****.apcprd04.prod.outlook.com (::1) | ****.apcprd04.prod.outlook.com | 2/9/2025 1:01:16 AM | 2 seconds | HTTPS |
发送方为 "'trustandsafety@support.aws.com' via mixss" <fopals@jic.swordsman.in.th>, 接收方为 i@example.com.
被利用的邮件系统有:
- Kustomer (CRM 服务)
- Amazon SES
- Google Groups
但起 “关键作用” 的还是 Google Groups, 于是本案依旧被归功给了 Google.
分析
与《Google 案例 #1》相比较就能看出, 本次使用来发送第一封邮件的 MTA 从 Google Workspace 切换为了 Amazon SES. 而且可以额外披露的是, 本案例与 1 号案例利用的 Google Groups 群组是同一个, 并接收方也是同一个, 不过手段稍微有些不同.
发送方利用了 From 标头的特性, 将自己的身份伪装为 trustandsafety@support.aws.com (AWS 的 T&S 部门邮件), 然而实际上的发件人其实是 fopals@jic.swordsman.in.th. 还不论内容是完全复制的 AWS 部门邮件, 此类伪装发件人的行为已经完全属于钓鱼邮件, Exchange Online 的扫描结果也是 PHISH.
swordsman.in.th 看起来被做成了一个泰语网游的页面, 不过某些关键图片还是中文的 “笑傲江湖”, 耐人寻味.
其中涉嫌钓鱼用途的发信域名 swordsman.in.th 注册于 2024 年 9 月 16 日, 网站域名 188betlink.bet 注册于 2024 年 11 月 6 日, 被利用的 Kustomer 作为 CRM 系统用来发送第一封邮件, 而 Kustomer 使用的 MTA 正好就包括了 Amazon SES, 随后第一封邮件达到 Google Groups 群组, Google 再将这封邮件转发给群组内所有目标地址.
处置
用户
处置方式与《Google 案例 #1》完全相同, 详见处置章节.
管理员
- 向 Kustomer 提交滥用举报.
- 向 Amazon 提交滥用举报.
- 向 Google 提交滥用举报.
- 向域名注册局提交滥用举报.
- 向 DNS 解析服务器提交滥用举报.
- 向网站解析 IP 的 ASN 管理员提交滥用举报.
- 添加发送方域名到入站黑名单.