攻击者不一定需要伪造一个明显的登录页面，也不一定要破解密码。GTIG 近期追踪的 UNC6293、UNC7005 和 UNC5976 展示了另一条更隐蔽的路径：诱导目标使用真实的应用密码、OAuth 登录、设备验证码或 WhatsApp 设备绑定流程，再把由合法服务签发的访问权限交给攻击者。
这类攻击尤其针对学术界、航空航天与国防、政府、外交机构和智库人员。它们往往从一封看似来自会议组织者、使馆或合作机构的邀请开始，最终把“登录”“确认身份”或“加入安全通话”变成账户接管入口。
三个集群，三种侧重点
UNC6293：从应用密码转向 OAuth
GTIG 以中等置信度评估，UNC6293 是 ICE RELIC（此前常与 APT29 关联）负责初始访问活动的子集群。它的活动通常规模较小，一次针对少量高价值目标，长期使用外交活动、会议邀请和美国国务院冒充等主题。
早期操作诱导受害者创建名为 ms.state.gov 的应用密码，并通过邮件回传。较新的活动改为让受害者把应用密码输入攻击者控制的认证表单，或者在完成真实的第三方登录后提交完整 URL 或“verification code”。
这里的关键风险是：应用密码和 OAuth 流程可能绕过用户对常规密码和双因素认证的直觉防线。用户看到的登录步骤可能是真实的，但授权结果最终被攻击者接收。
UNC7005：社交工程、设备绑定和恶意软件组合
UNC7005，也被称为 STORM-2945，目标覆盖乌克兰、西欧和美国的学术、外交及非营利机构人员。它与 UNC6293 在目标行业和诱饵主题上存在相似性，但基础设施、运维习惯和工具使用方式不同，因此 GTIG 将两者分开追踪。
UNC7005 的设备验证码钓鱼通常伪装成会议、使馆活动或行业论坛邀请。目标需要填写详细报名信息，甚至选择葡萄酒偏好，随后页面要求“身份验证”，并展示 Microsoft 设备验证码。页面还会采集屏幕尺寸、时区、语言和浏览器特征，用于识别自动化分析环境。
针对 WhatsApp 的活动更加直接：受害者输入电话号码后，页面引导其把攻击者设备绑定到自己的 WhatsApp 账户。绑定成功后，页面可能继续伪造语音通话、加密聊天或文件传输。相关页面甚至尝试调用浏览器的摄像头和麦克风权限，并将录制内容上传到攻击者的 C2 端点。
UNC7005 还使用了 MaaS 信息窃取器，例如 Windows 平台上的 VIDAR 和 macOS 平台上的 ATOMIC，重点窃取浏览器保存的凭据、Cookie、支付信息和地址数据。它也开展了 Google OAuth 钓鱼，并把受害者导向攻击者控制的测试模式云项目。
UNC5976：自动化 OAuth 和更重的恶意软件痕迹
UNC5976 被 GTIG 视为独立集群，活动重点集中在军事、航空航天、国防工业、非政府组织和智库，地理目标主要涉及乌克兰和亚美尼亚。
它常购买看似文件共享服务的域名，搭建伪造的文件分享页面，再把用户带到真实的 Google OAuth 登录页面。用户完成认证后，攻击者控制的云项目会从重定向 URL 中提取访问令牌并保存，供后续操作使用。基础设施遭到处置后，该集群在约三个月内创建了至少十二组新域名和相关资源，并被观察到可能转向其他云服务商。
与 UNC6293 和 UNC7005 相比，UNC5976 使用的恶意软件和专用基础设施更多。GTIG 还发现了名为 HEADRUSH 的恶意 Excel 插件，其感染链最终可能下载 HTA 文件。
防守重点：验证“授权结果”而不只是登录页面
传统安全培训常要求用户检查域名、识别拼写错误和避免在陌生页面输入密码。这些做法仍然必要，但面对本次活动还不够，因为攻击者经常把用户带到真实的 Google 或 Microsoft 登录页面。
更有效的判断方式是检查“这次认证到底授予了谁什么权限”：
- 任何要求创建或分享应用密码的请求都应视为高风险。应用密码不是身份验证工具，也不应发送给活动组织者、同事或所谓技术支持人员。
- OAuth 登录后要检查授权应用名称、发布者、权限范围和是否处于 testing 或 unverified 状态。真实登录页面不代表后续应用值得信任。
- Microsoft 设备验证码、WhatsApp QR 码和设备绑定请求必须由用户主动发起。会议邀请、文件共享或“安全通话”不应要求把个人账户绑定到陌生设备。
- 对个人邮箱和消息应用建立独立的设备审计流程。企业只监控加入域的终端，会看不到个人账户被接管后的异常转发、对话和二次钓鱼。
- 对高风险人员优先使用硬件安全密钥或增强保护计划，减少应用密码和弱恢复流程的攻击面。
可以直接改造的检测示例
下面的 Bash 示例用于从导出的代理、DNS 或邮件安全日志中筛选部分报告中出现的可疑域名和 IP。示例指标仅用于演示防守流程；上线前应替换为组织自己的情报源，并结合时间、用户和访问行为复核，避免把共享基础设施或合法业务误判为恶意活动。
#!/usr/bin/env bash
set -euo pipefail
LOG_FILE="${1:-proxy.log}"
IOC_REGEX='foreignrelations\.us|chamber-ua\.org|wa-connect\.eu|wa-device\.com|my-invite\.org|statistic-ms\.live|owa-ms365\.com|m365-owa\.com|ms365-device\.com|finishoperations\.com|foc-share\.com|verify-drive\.com|107\.189\.18\.7|104\.194\.159\.150'
if [[ ! -f "$LOG_FILE" ]]; then
printf 'Usage: %s <exported-log-file>\n' "$0" >&2
exit 2
fi
printf 'timestamp,user,matched_indicator\n'
rg -i -o "$IOC_REGEX" "$LOG_FILE" | while IFS=: read -r file line match; do
printf 'unknown,unknown,%s\n' "$match"
done
在生产环境中，建议把命中事件与以下信号关联起来：用户是否刚刚完成 OAuth 授权、是否出现新的 OAuth 应用、是否新增应用密码、是否有新的 WhatsApp 或 Microsoft 设备绑定，以及浏览器是否随后下载了可执行文件或 Office/HTA 内容。
也可以把检测逻辑写入 SIEM。下面是一个需要按日志字段改造的 Sigma 风格示例，用于发现 OAuth 后访问新注册或低信誉云项目的组合信号：
title: Suspicious OAuth Redirect To Untrusted Cloud Project
status: experimental
logsource:
category: webproxy
product: generic
detection:
oauth_login:
url|contains:
- "accounts.google.com"
- "login.microsoftonline.com"
suspicious_destination:
url|contains:
- ".web.app/"
- ".cloudfunctions.net/"
- "verify-drive"
- "foc-share"
condition: oauth_login and suspicious_destination
level: high
fields:
- user
- url
- destination.ip
- user_agent
这个规则不能单独证明账户已经被窃取。它的价值在于把真实身份认证与异常后续跳转放到同一条告警链中，再由分析人员检查授权范围、云项目状态和用户是否确实发起过对应活动。
事件响应清单
若用户已经按照陌生指引创建应用密码、提交设备验证码或绑定了未知设备，应按账户接管事件处理：
- 立即撤销相关应用密码、OAuth 授权和未知设备绑定。
- 从可信设备修改密码，并重新注册双因素认证或硬件安全密钥。
- 检查邮箱转发规则、恢复邮箱、登录会话、第三方应用和最近下载记录。
- 在 WhatsApp 等消息应用中审计 Linked Devices，并通过线下渠道核实异常联系人。
- 对 Windows 和 macOS 终端执行针对信息窃取器的检查，重点关注浏览器凭据、Cookie 和本地配置文件是否被读取。
- 保存钓鱼邮件、页面、重定向 URL、时间线、DNS 查询和文件哈希，便于在组织内扩展排查。
结语
这三组活动的共同点不是某个固定域名或某一种恶意软件，而是对合法认证功能的持续滥用。UNC6293 偏向小规模、高针对性的应用密码和 OAuth 钓鱼；UNC7005 把会议邀请、设备绑定、浏览器窃取器和 MaaS 组合起来；UNC5976 则更强调 OAuth 令牌自动收集和恶意软件链路。
组织应把账户安全监控从“有没有输错密码”扩展到“谁创建了什么授权、哪个设备被绑定、认证后访问了什么资源”。对外交、国防、航空航天、学术和智库人员而言，来自熟悉机构或熟人账号的邀请也必须通过独立渠道验证。合法登录页面只说明认证步骤真实存在，并不能证明这次授权请求值得批准。