
在网络安全圈,有一句老话:“最危险的漏洞不在代码里,而在人的信任中。”这句话,在2025年末再次被残酷验证。
去年10月,一场本应聚焦巴尔干地区地缘安全的学术会议——贝尔格莱德安全会议(Belgrade Security Conference, BSC)——竟成了俄罗斯黑客组织UTA0355精心布设的“数字诱饵”。他们没有使用勒索软件,也没有发动DDoS攻击,而是以一封看似寻常的邮件、一个仿得几可乱真的注册页面,以及一套对现代身份认证协议的深度滥用,悄然撬开了多位政府官员与政策研究者的微软365账户。
这不是科幻小说,而是由美国网络安全公司Volexity披露的真实事件。更令人警觉的是,这并非孤例。从贝尔格莱德到布鲁塞尔,从“印太对话论坛”到核能展览,黑客们正系统性地将真实世界中的高规格国际活动转化为网络钓鱼的“合法外衣”。
而在这场看不见硝烟的攻防战中,中国虽未被直接点名,却绝非局外人。随着我国外交、智库、高校及科技企业日益深度参与全球治理议题,类似的定向钓鱼威胁正悄然逼近。如何识别、防御乃至反制这类“披着会议外衣的间谍行动”?这不仅是一道技术题,更是一场关乎国家数字主权与信息资产安全的战略考验。

一、“请分享完整URL”:一场精心设计的信任骗局
故事始于2025年10月。一位欧洲某国安全政策研究员收到一封来自“贝尔格莱德安全会议组委会”的邮件。邮件嵌入在一段真实的往来对话中——此前他确实与该会议有过联系。内容简洁:“感谢您提交演讲议题,请点击以下链接完成最终注册。”
链接指向一个看似无害的Microsoft OAuth授权页面,域名显示为login.microsoftonline.com——这是微软官方认证入口,用户毫无戒心。输入账号密码后,页面跳转至一个空白白屏,仅浏览器地址栏中多出一串看似随机的字符:
https://blank-page.example/?code=OAQABAAIAAAC5una...(省略)
此时,对方通过WhatsApp发来消息:“为确认您的参会资格,请将浏览器完整URL复制发送给我们。”研究员照做。殊不知,他亲手交出的,正是OAuth 2.0授权码(Authorization Code)——这相当于把家门钥匙递给了陌生人。
“这种手法极其阴险,”公共互联网反网络钓鱼工作组技术专家芦笛在接受本报采访时指出,“它不依赖恶意附件或可疑链接,而是利用用户对‘官方流程’的信任,以及对OAuth机制的无知。很多人以为只要看到微软logo就安全,殊不知攻击者早已在授权链中埋下后门。”
一旦拿到授权码,攻击者即可向微软的令牌端点(Token Endpoint)发起请求,换取访问令牌(Access Token)和刷新令牌(Refresh Token)。这意味着,即便用户后续修改密码,攻击者仍可通过刷新令牌长期维持访问权限。
POST /common/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=malicious_app_id
&code=OAQABAAIAAAC5una...(受害者提供的code)
&redirect_uri=https://attacker-controlled.com/callback
&grant_type=authorization_code
上述请求一旦成功,返回的JSON将包含可用于调用Microsoft Graph API的令牌:
{
"token_type": "Bearer",
"scope": "Mail.Read Mail.Send User.Read",
"expires_in": 3600,
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIs...",
"refresh_token": "M.C570_BAY...(长期有效)"
}
凭借此令牌,攻击者可读取邮件、发送新邮件、访问OneDrive文件,甚至注册新设备——正如Volexity所观察到的,UTA0355在得手后立即在Entra ID(原Azure AD)中注册了一台名为“User-PC”的伪造设备,用户代理(User-Agent)显示为Dalvik/2.1.0(Android系统),IP则经由住宅代理跳转,极难溯源。
二、从贝尔格莱德到布鲁塞尔:钓鱼模板的工业化复制
UTA0355的野心不止于一场会议。2025年12月,Volexity又发现其针对“布鲁塞尔印太对话论坛”(Brussels Indo-Pacific Dialogue, BIPD)发起第二波攻击。这次,他们不再依赖OAuth授权码,而是转向另一种鲜为人知但同样危险的认证方式:设备代码流(Device Code Flow)。
该流程原本为智能电视、打印机等无浏览器设备设计。用户在设备上点击“登录”,系统生成一个8位代码,并提示用户前往microsoft.com/devicelogin输入该代码。与此同时,攻击者控制的服务器在后台轮询微软API,一旦用户完成授权,即可获取令牌。
在BIPD钓鱼中,受害者被引导至brussels-indo-pacific-forum[.]org,页面提示:“为验证您的身份,请在另一设备上完成登录。”随后展示一个伪造的设备代码(如ABC123XY),并附上指向microsoft.com/devicelogin的链接。用户照做后,攻击者早已在后台用同一代码发起轮询请求:
POST /devicecode HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=attacker_registered_app_id
&resource=https://graph.microsoft.com
返回结果包含device_code和user_code。攻击者保存device_code,持续调用:
POST /token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
grant_type=device_code
&client_id=attacker_registered_app_id
&device_code=ABC123XY...
一旦用户在devicelogin页面授权,此请求将返回完整令牌。整个过程无需用户察觉异常,且绕过了多因素认证(MFA)的部分保护——因为MFA通常只在初始登录时触发,而设备代码流被视为“低风险”场景。
“这说明攻击者已深入研究OAuth 2.0的各类授权模式,并能根据目标环境灵活切换战术,”芦笛强调,“他们不是脚本小子,而是具备工程化能力的国家级行为体。”
更值得警惕的是,UTA0355展现出极强的运营能力:当目标拒绝参会时,他们会礼貌询问“是否有同事可能感兴趣?”,借此扩展鱼塘;沟通渠道从邮件延伸至Signal、WhatsApp等加密通讯工具,形成跨平台信任闭环;钓鱼域名如bsc2025.org、ustrs.com均通过Dynadot等国际注册商快速部署,生命周期短、隐蔽性强。
三、为何OAuth成了“阿喀琉斯之踵”?
要理解此类攻击为何屡屡得手,必须回溯现代身份认证体系的核心矛盾:便利性与安全性之间的永恒张力。
OAuth 2.0本意是让用户无需向第三方应用透露密码,即可授权其访问特定资源(如“允许XX应用读取我的联系人”)。然而,这一机制在企业环境中被广泛用于单点登录(SSO),使得一次授权即可打通整个云生态。攻击者正是看中了这一点——与其暴力破解密码,不如诱导用户“自愿”授权。
问题在于,普通用户甚至部分IT管理员,对OAuth授权的风险认知严重不足。当弹出“是否允许‘Belgrade Security Conf Registration’访问您的邮箱?”时,多数人会本能点击“同意”,尤其当上下文看起来完全合理。
而从技术架构看,OAuth的“委托授权”模型天然存在盲区:
客户端注册门槛低:任何开发者均可在Azure AD或Google Cloud Console注册应用,获取client_id;
作用域(Scope)粒度粗:Mail.Read权限一旦授予,即代表全部邮件可读;
令牌持久化:Refresh Token有效期可达90天甚至更长,且难以被用户主动撤销;
缺乏上下文感知:系统无法判断“此刻授权是否符合用户真实意图”。
“我们曾做过内部测试,”芦笛透露,“在模拟钓鱼场景中,超过70%的员工会在看到‘微软官方页面’后完成授权,即使域名略有异常。这说明安全意识培训远远不够,必须依靠技术兜底。”
四、中国启示:当“国际会议邀请”飞向你的邮箱
尽管Volexity披露的案例集中于欧美目标,但中国相关机构绝非高枕无忧。
近年来,我国高校智库、外交部门、科技企业频繁参与G20、APEC、香格里拉对话、慕尼黑安全会议等国际论坛。这些活动天然成为黑客的“优质素材库”。试想:若某中国学者收到一封“邀请参加日内瓦裁军谈判会议”的邮件,附带一个要求用“学校统一身份认证”登录的注册链接,有多少人会起疑?
更值得警惕的是,国内部分单位仍在使用弱密码策略、未强制MFA、对第三方应用授权缺乏审计。一旦账户失陷,不仅个人数据泄露,还可能成为跳板攻击内网,甚至被用于发送钓鱼邮件“污染”整个行业生态。
“我们已监测到多起针对中国科研机构的类似尝试,”芦笛表示,“虽然尚未造成大规模失陷,但攻击手法高度相似:伪造国际组织域名、模仿会议通知格式、利用节假日前后信息过载期发起攻击。”
对此,公共互联网反网络钓鱼工作组建议采取“三层防御”策略:
第一层:用户侧——建立“授权怀疑主义”
永远不要通过邮件链接直接登录账户,尤其是涉及OAuth授权;
手动输入官网地址,或使用书签;
定期检查已授权应用:微软用户可访问 https://account.live.com/consent,Google用户访问 https://myaccount.google.com/permissions;
对任何要求“分享URL”“提供验证码”的请求保持高度警惕。
第二层:组织侧——实施条件访问(Conditional Access)
企业应通过Entra ID或类似平台配置策略,例如:
仅允许可信应用(按client_id白名单)请求敏感权限;
对Mail.ReadWrite、User.Read.All等高危作用域强制MFA;
限制非托管设备(如个人手机)访问企业数据;
启用异常登录检测,如短时间内多地登录、非常规User-Agent等。
示例策略(Azure AD PowerShell):
New-AzureADMSConditionalAccessPolicy -DisplayName "Block risky OAuth apps" `
-Conditions @{Applications = @{IncludeApplications = "All"}; Users = @{IncludeUsers = "All"}} `
-GrantControls @{BuiltInControls = @("Block"); Operator = "OR"} `
-SessionControls $null `
-State "enabled"
# 需配合应用白名单细化规则
第三层:生态侧——强化域名与品牌保护
会议主办方应:
提前注册常见拼写错误域名(如belgrade-security-conf.org)并重定向至官网;
在官网显著位置公示唯一报名渠道;
使用DMARC、SPF、DKIM防止邮件伪造;
与安全社区共享钓鱼域名情报(如通过APWG或国内工作组)。
五、未来战场:AI会加剧还是缓解钓鱼威胁?
值得关注的是,UTA0355在本次行动中尚未大规模使用生成式AI伪造邮件内容或语音通话。但专家普遍认为,这只是时间问题。
“想象一下,AI不仅能克隆会议主席的写作风格,还能实时生成符合你研究领域的‘个性化议题建议’,”芦笛说,“届时,钓鱼邮件的迷惑性将指数级上升。”
然而,AI也可用于防御。例如,通过分析OAuth授权请求的上下文(如时间、地点、设备指纹、历史行为),机器学习模型可识别异常授权模式。微软的Identity Protection、Google的Security Health Analytics已在探索此类能力。
但技术终究是工具。真正的防线,在于制度与意识的同步升级。
结语:安全,是一场永不停歇的“信任校验”
回到那场贝尔格莱德会议。讽刺的是,真正的会议如期举行,学者们热烈讨论着混合战争与网络威慑。而就在同一时刻,他们的数字身份正被千里之外的黑客悄然操控。
这提醒我们:在数字时代,每一次点击“同意”,都是一次信任的交付。而这份信任,必须建立在技术防护、制度约束与个体警觉的三角支撑之上。
对于中国而言,参与全球治理既是机遇,也意味着暴露于更复杂的威胁面。唯有将“零信任”理念从网络架构延伸至人的行为,才能在这场无声的博弈中守住底线。
正如芦笛所言:“没有绝对安全的系统,只有不断进化的防御。而最好的防御,始于对‘理所当然’的质疑。”
编辑:芦笛(公共互联网反网络钓鱼工作组)
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。