目录导航
在过去的几周里，许多研究人员警告说，一场新的大规模网络钓鱼活动正在使用中间对手 (AiTM) 技术绕过多因素身份验证。继Zscaler 研究人员Sudeep Singh 和 Jangadeeswar Ramanukolanu 之后，该活动旨在吸引专注于 Microsoft 服务的企业中的最终用户。上个月，Microsoft 威胁情报中心 (MSTIC) 分享了有关这种新方法和即将推出的网络钓鱼方法的更多信息。
推荐阅读：
什么是 AiTM 网络钓鱼？
Adversary-in-the-middle (AiTM) 网络钓鱼并不新鲜。已经被攻击者使用几年了。网络钓鱼仍然是最常见的攻击类型。MFA 提供了一个额外的安全层来防止凭证盗窃。不幸的是，攻击者也在寻找绕过额外安全层（MFA、2FA）的新方法。
根据我们的威胁数据，自 2021 年 9 月以来，AiTM 网络钓鱼活动试图针对 10,000 多家组织。
@微软MSTIC
传统的凭据网络钓鱼站点会收集用户的凭据，并且永远不会完成身份验证过程。为用户启用 MFA 后，它会阻止攻击者使用被盗凭据登录帐户。
Adversary-in-the-middle (AiTM) 网络钓鱼攻击用于绕过多因素身份保护。AiTM 攻击完成身份验证过程并捕获令牌。目前，有三种广为人知的主要开源 AiTM 网络钓鱼工具包：
所有 Aiworkts 都充当受害者和目标站点之间的代理。每个现代 Web 服务都会在成功验证后实现与用户的会话，因此每个新页面都不需要重新验证。会话功能是身份验证服务提供的会话 cookie 的一部分。带有 AiTM 网络钓鱼工具包的 Web 服务器代理 HTTP 数据包，基于此技术，该网站与原始网站相同。只有 URL 是网络钓鱼站点和实际 Microsoft 登录站点之间唯一可见的区别。
下图解释了 AiTM 网络钓鱼过程（来源：Microsoft）
Evilginx2
注意：Evilginx2 的配置不是这篇博文的一部分。多个在线资源描述了 Evilginx2 的安装/配置。官方项目网站 提供了更多信息和细节。
Evilginx2 是最受欢迎的 AiTM 网络钓鱼工具包之一。Evilginx2 不像传统的网络钓鱼攻击那样提供自己的 HTML 相似页面。Evilginx2 是一个中间人攻击框架，用于钓鱼登录凭据和会话 cookie。Evilginx2 的一部分是内置的 HTTP 和 DNS 服务器，这使得配置非常容易——SSL 证书是 Lets Encrypt 的一部分，并且是自动生成的。
演示配置
对于 Evilginx2 演示，环境是根据以下信息配置的；
- IP：20.25.240.232
- 域名：logincyberdemo.com
- 服务器位置：美国中北部
- 服务器操作系统：Linux Debian 11
Evilginx2 基于黑名单配置，避免自动爬取和拦截。Office 365 phishlet 重定向到官方 portal.office.com URL。为避免被列入黑名单，可以使用身份验证密钥访问网络钓鱼站点。Cmdlet lures get-url <id> 可用于查看完整的 URL 路径。cmdlet Lures 显示所有启用的 phishlet 和 ID。
配置后，phishlet 在域 + 路径上处于活动状态；https://login.logincyberdemo.com/acBAlkzp
登录页面
登录页面捕获默认 login.microsoftonline.com 样式。使用客户凭据登录时，将应用客户租户品牌。这使得围绕客户品牌的意识毫无用处。
默认微软：
租户品牌登录：
捕获会话令牌
捕获受 MFA 保护的会话非常容易。输入网络钓鱼 URL 后，会为用户提供 Office 365 登录屏幕。输入用户名后，公司品牌将直接从 AzureAD 收集。提供密码和 MFA 后，将捕获会话令牌和凭据。
Cmdlet Sessions<Id> 显示附加信息和令牌。
导入被盗令牌
使用浏览器或应用程序可以重放令牌。比如使用插件；用于导入会话令牌的Cookie 编辑器。
防范 AiTM 网络钓鱼
随着 MFA 越来越多的启用/采用，预计 AiTM 网络钓鱼将在未来几年增长（攻击者使用新技术）。防范 AiTM 网络钓鱼很重要。
可以根据各种配置进行保护：
- 抗网络钓鱼 MFA 解决方案（FIDO/基于证书的身份验证）
- 使用条件访问保护攻击
- 使用 Microsoft 365 Defender/Azure AD 身份保护进行监控/保护
- 内置警报规则
让我们从基于网络钓鱼解决方案、受保护的 2FA/MFA 方法、条件访问的保护部分和 Microsoft 安全产品/功能的概述开始。哪些功能/设置可以防止 AiTM？
✅ = 受 AiTM 保护
❌ = 不受 AiTM 保护
抗网络钓鱼 MFA 解决方案（FIDO/基于证书的身份验证）
Microsoft 提供了大量选项，可用作主要身份验证方法；目前，可以使用以下方法：
- FIDO2 安全密钥
- Windows Hello 企业版
- 基于证书的身份验证
- 无密码电话登录
- 电话号码和短信
- 用户名和密码
条件访问可用于更深入地保护帐户。在没有额外的条件访问保护的情况下，以下方法受/不受AiTM 保护：
| 方法 | 抵御 AiTM |
|---|---|
| FIDO2 安全密钥 | ✅ |
| Windows Hello 企业版 | ✅ |
| 基于证书的身份验证 | ✅ |
| 无密码电话登录 | ❌ |
| 电话号码和短信 | ❌ |
| 用户名和密码 | ❌ |
只有 FIDO2、Windows Hello 企业版和基于证书的身份验证受到 AiTM 网络钓鱼的保护。用户名和密码可以通过额外的条件访问保护来丰富。
受保护的 2FA/MFA 方法
检查不同的 2FA/MFA 方法时；以下是针对非无密码方法之上的 AiTM 攻击的保护。
✅ = 受 AiTM 保护
❌ = 不受 AiTM 保护
| 方法 | 抵御 AiTM |
|---|---|
| 短信 | ❌ |
| 电话 | ❌ |
| 微软认证应用 | ❌ |
| 微软认证应用+号码匹配 | ❌ |
| Microsoft 身份验证应用程序 + 附加上下文 | ❌ |
| Microsoft 身份验证应用程序 + 号码匹配 + 附加上下文 | ❌ |
受保护的条件访问和其他控制
答案很简单；只有 2FA 或 MFA 没有保护；只有当增加了额外的条件访问时，才会有保护。以下条件访问控制提供针对 AiTM 的保护。
✅ = 受 AiTM 保护
❌ = 不受 AiTM 保护
| 方法 | 抵御 AiTM |
|---|---|
| 要求将设备标记为合规 | ✅ |
| 要求将设备标记为已加入混合 Azure AD 的设备 | ✅ |
| 条件访问会话控制 | ❌（限制时间窗口） |
| 条件访问受信任位置 | ✅ |
| 持续访问评估 CAE | ❌（仅在用户条件发生变化时实时撤销访问权限 |
额外保护
AzureAD 和 Microsoft Security 的其他保护服务部分不提供针对 AiTM 的直接保护。由于支持 Evilginx2 自定义租户品牌。
| 方法 | 抵御 AiTM |
|---|---|
| 自定义租户品牌 | ❌ |
| Azure AD 身份保护 | ❌（仅提醒） |
| 用于终结点的 Microsoft Defender | ❌ |
| 适用于云应用的 Microsoft Defender | ❌（仅提醒） |
| 适用于 Office 365 的 Microsoft Defender | ❌（仅删除包括钓鱼链接的电子邮件） |
撤销会话和 MFA 注册
可以通过 portal.azure.com 为所有活动会话撤销会话。当会话被撤销时，攻击者不能再使用已经被盗的钓鱼 cookie。检查新添加的身份验证选项并直接更改密码始终很重要。
撤销会话会删除当前的身份验证；这不是尝试后的预防。在分析过程中始终执行更多步骤。如果攻击者注册了其他 MFA 方法怎么办？
攻击者可以轻松访问aka.ms/mysecurityinfo 并将 FIDO2 安全密钥注册为新方法。下次攻击者可以使用 FIDO2 安全密钥，这被认为是一种强大的方法。始终检查是否为特定用户注册了新的身份验证因素。
无密码电话登录
无密码电话登录听起来安全吗？Evilginx2 支持从无密码配置的用户捕获令牌。无密码电话登录不受 AiTM 保护。Evilginx 没有捕获密码——令牌被捕获并且可以轻松使用。
结果是 Evilginx；密码为空 – 令牌可见。
使用条件访问进行预防
如上所述，条件访问会阻止 AiTM 网络钓鱼尝试（仍会捕获纯文本密码）
以下条件访问策略很重要；成功阻止了 AiTM。这些访问控制依赖于额外的遥测，这在代理登录期间不可用。
访问控制
- 要求将设备标记为合规
- 要求将设备标记为已加入混合 Azure AD 的设备
健康状况
- 条件访问受信任位置
使用条件访问的结果– 兼容设备或加入 AzureAD 的设备
视频显示了使用条件访问兼容设备或加入 AzureAD 时的行为。
仍会捕获密码（仅未捕获其他会话/MFA 令牌）。提示:不要根据特定应用限制条件访问。
使用条件访问的结果– IP 位置过滤器
视频显示了使用条件访问 IP 块时的行为。阻止除受信任的 IP 位置之外的访问。
仍会捕获密码（仅未捕获其他会话/MFA 令牌）。提示:不要根据特定应用限制条件访问。
使用 (PIM) 特权身份管理进行保护？
常见问题；启用特权身份管理 (PIM)，并为每个配置的管理员角色附加 MFA；这种行为是否受 MFA 保护？答案是:不
使用被盗令牌后，MFA 已包含在内 – 这不会为全局管理员角色或其他特权角色提供额外的 MFA 验证。
下面的视频显示了以下内容：
- 使用 Cookie 编辑器导入会话 cookie
- 使用 cookie 登录
- 激活 PIM 角色（需要额外的 MFA）
Microsoft Defender 警报和检测
Microsoft 365 Defender 的一部分是针对 AiTM 网络钓鱼的额外保护。Defender 使用交叉信号功能来检测被盗的会话 cookie。带有名称的警报；在以下情况下会生成被盗会话 cookie ； Cookie 使用 Microsoft Edge 浏览器被盗，攻击者试图回复被盗会话 cookie 以访问 Exchange Online。
以下警报对于检测 AiTM 网络钓鱼很重要：
- Microsoft 365 Defender
- 使用了被盗的会话 cookie
- 云应用防御者
- 可疑收件箱操纵规则
- 不可能的旅行活动
- 来自罕见国家的活动
- Azure AD 身份保护
- 异常令牌
- 不熟悉的登录属性
- 会话 cookie 的不熟悉的登录属性
- 匿名 IP 地址
- Office 365 防御者
- 包含恶意文件的电子邮件在发送后被删除
- 来自营销活动的电子邮件在发送后被删除
- 创建转发/重定向规则
- 端点防御者
- 潜在的钓鱼网站
4/5 天后，用于测试的域在“潜在网络钓鱼网站”警报中可见。
归功于微软；下面的高级搜索查询可用于检测被盗会话 cookie。更多信息可以在这里建立。
let OfficeHomeSessionIds =
AADSignInEventsBeta
| where Timestamp > ago(1d)
| where ErrorCode == 0
| where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca" //OfficeHome application
| where ClientAppUsed == "Browser"
| where LogonType has "interactiveUser"
| summarize arg_min(Timestamp, Country) by SessionId;
AADSignInEventsBeta
| where Timestamp > ago(1d)
| where ApplicationId != "4765445b-32c6-49b0-83e6-1d93765276ca"
| where ClientAppUsed == "Browser"
| project OtherTimestamp = Timestamp, Application, ApplicationId, AccountObjectId, AccountDisplayName, OtherCountry = Country, SessionId
| join OfficeHomeSessionIds on SessionId
| where OtherTimestamp > Timestamp and OtherCountry != CountryAADSignInEventsBeta
| where Timestamp > ago(7d)
| where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca" //OfficeHome application
| where ClientAppUsed == "Browser"
| where LogonType has "interactiveUser"
| summarize Countries = make_set(Country) by AccountObjectId, AccountDisplayName 转载请注明出处及链接