前言

在使用浏览器使用 Azure AD 身份登录时，Microsoft 提供了多种选项，可用作主要身份验证方法。

• 用户名和密码
• 电话号码和短信
• 用户名和无密码手机登录
• 基于证书的身份验证
• Windows Hello 企业版
• FIDO2 安全密钥

使用条件访问，您可以进一步保护帐户，强制要求第二个因素、设备合规性、基于位置的限制和更多配置选项。

多因素身份验证

对于多因素身份验证，您可以使用以下任何方法。

• 短信
• 电话
• TOTP 身份验证器应用程序
• Microsoft 身份验证器应用

请注意，对于无密码手机登录、基于证书的身份验证、Windows Hello 企业版和 FIDO2 安全密钥，您不能强制执行第二个因素，因为这些方法被视为强身份验证方法。

另一方面，目前不支持 SMS 登录，需要第二个因素。

网络钓鱼

重要的是要知道，只有提到的三种方法可以保护您的用户免受网络钓鱼攻击。

• 基于证书的身份验证
• Windows Hello 企业版
• FIDO2 安全密钥

最好使用免费提供的网络钓鱼工具包之一来探索为什么会出现这种情况。一如既往，眼见为实，我总是在修补自己时学得最好。

遇见邪恶的nginx2

evilginx2 是一个中间人攻击框架，用于网络钓鱼登录凭据以及会话 cookie，从而允许绕过 2 因素身份验证保护。

这是evilginx2 GitHub 页面上的官方描述。与Modlishka一起，它是首批易于使用的反向代理之一，这表明仅靠第二个因素并不能保护用户免受网络钓鱼。

这两个项目都没有试图用一个看起来几乎像原始登录网站的网站来欺骗用户，它们使用反向代理技术将实际的登录网站（例如 login.microsoft[.]com）转发给用户。网络钓鱼网站托管在攻击者可以完全控制的某个域上，因此很容易获得有效证书。evilnginx2 甚至使用Let's Encrypt证书服务自动执行此过程。

攻击者现在位于目标服务 (Azure AD) 和用户之间，并且可以完全访问流经代理的未加密数据。

您可以配置 evilnginx2 phishlet 来保护会话 cookie，而不是只从 POST 请求中获取数据，例如用户名和密码。根据会话 cookie 的生命周期，攻击者现在有几天或几个小时的时间来使用此信息来冒充用户。由于初始身份验证是通过第二个因素完成的，因此不会再次要求攻击者提供此信息。

这篇博文没有介绍 evilnginx2 的设置，也没有提供现成的 phishlet。有关如何设置 evilnginx2 测试实例的更多信息， 请参阅原始博客系列或项目站点。

实验室设置

我们的受害者[email protected]收到了一封电子邮件，其中包含一个带有令人信服的诱饵的网络钓鱼链接。Bob 认为他正在访问 OneDrive 文档。

使用的网络钓鱼域portal.demo.nottrustedbutlegit[.]de与login.microsoft[.]com. 真正的攻击者很可能会选择更接近原始域的东西。

攻击者已将 evilnginx2 配置为尽可能捕获会话 cookie 以及用户名和密码。

Azure AD 管理员创建了一个条件访问策略，要求 Bob 在登录任何云应用程序时使用 MFA。

需要多重身份验证

同样为了保护她的用户，她将会话控制“持久浏览器会话”设置为“从不持久”。这可以防止浏览器保存会话 cookie 并在每次启动浏览器时强制进行新的登录。

使用用户名、密码和 2FA 登录

Bob 单击该链接并被请求登录到 Azure AD。他输入他的用户名和密码，然后在 Microsoft Authenticator 应用程序上接收并弹出。

由于他期望这一点，他批准了登录并成功登录。但他被重定向到www.office.com而不是文档。

攻击者不仅捕获了用户名和密码，还捕获了会话 cookie。使用该命令sessions，她可以检查所有这些信息，甚至可以复制会话 cookie 以供将来使用。

无密码手机登录

在这种情况下，鲍勃单击链接，但已将 Microsoft Authenticator 应用程序配置为无密码方法。

无密码手机登录

攻击者“仅”能够捕获用户名和会话 cookie。请继续阅读以了解为什么这没有真正的区别。

无密码手机登录结果

我知道在这个演示中，会话 cookie 仅被部分捕获。我修复了 phishlet 并能够捕获完整的会话 cookie。

使用 FIDO2 安全密钥登录

Bob 正在使用外部 FIDO2 安全密钥或Windows Hello的 Windows 内置 (>1903) FIDO 功能作为一种安全的身份验证方式。

Bob 无法使用 FIDO2 安全密钥登录钓鱼网站。

使用 FIDO2 安全密钥登录

在 Microsoft 的常规网站 (login.microsoft[.]com) 上，他将能够选择他想要使用的凭据，但不能在攻击者使用的假域上选择。

使用 FIDO2 定期登录

因此，攻击者无法捕获任何东西。

使用 FIDO2 安全密钥登录结果

有什么不同？

FIDO2/WebAuthn 使用不同的方法来防止凭据网络钓鱼。在这种攻击中，使用了一种非常简单但超级有效的技术来阻止用户登录。

WebAuthn 客户端（浏览器）将域名与FIDO2 安全密钥中公钥的依赖方标识符 (RP ID)进行比较。如果域字符串匹配，则可以将其用作登录方法。否则用户无法使用存储在密钥中的凭证。

而且由于机器在比较字符串值和另一个字符串值方面要好得多，因此即使使用在人眼看来与目标域完全一样的IDN 域进行“好的”网络钓鱼攻击也无法绕过这种保护。

login.microsoft.com或者你能轻松地看出和之间的区别吗lοɡin.miсrοsoft.com？没那么容易，不是吗？

第二个将读取 punycode：xn–lin-9tb36o.xn–mirsoft-bpf28i.com。

在 Bobs FIDO2 安全性上有两个条目：

只有当网站的 RP ID 与域名 Bob 完全相同时，才能使用他的凭据登录。

如果您想了解有关 FIDO2 和 Windows Hello 企业版的更多信息，我建议您观看 Ignite Session From Strong to Stronger: Phishing Resistant authentication methods (The Blueprint Files)。Inbar Cizer Kobrinsky和Tarek Dawoud在解释概念和技术方面做得很好。

Cookie 接管

如前两种方法所示，攻击者能够检索凭证的多个部分。用户名、密码和会话 cookie 的重要部分 ( ESTSAUTH, ESTSAUTHPERSISTENT, SignInStateCookie)。

evilnginx2 中显示的 Cookie 信息

由于此租户的管理员已制定条件访问策略，要求每次登录都需要 MFA，因此用户名和密码不足以接管该帐户。

但是会话 cookie 包含对用户进行身份验证所需的所有信息，并且由于原始会话已经提供了有效的第二个因素或正在使用像手机登录这样的强身份验证方法，攻击者可以轻松地使用此 cookie。

使用正确的浏览器扩展和 evilnginx2，这就像复制、粘贴和访问 office.com 一样简单。

正如您在此演示中看到的那样，攻击者不仅可以访问受害者正在访问的网站，还可以访问 Azure AD 身份可以访问的任何服务。

攻击者甚至可以访问aka.ms/mysecurityinfo并注册一个 FIDO2 安全密钥作为新的登录方法。由于这属于强身份验证方法，因此攻击者从现在开始无需知道用户的密码即可登录该帐户。即使更改密码也不会阻止攻击者登录。

后门 FIDO2 安全密钥

在这种情况下，管理员将“持久浏览器会话”配置为“从不持久”没有什么意义，evilnginx2 不遵守“浏览会话结束时过期”信息。此设置的唯一区别是，它可以防止攻击者在 24 小时后使用 cookie。

浏览会话结束时 Cookie 过期

如果受攻击的用户能够将设备加入 AAD 甚至将新设备注册到 Intune，则攻击者甚至可以获得合规的“公司”设备，并且现在能够绕过基于设备合规性的安全实施。这是 Microsoft 本身在博客文章Evolved phishing: Device registration trick 添加到网络钓鱼者工具箱中针对没有 MFA 的受害者的攻击。

多阶段网络钓鱼攻击链 - 图片来自 Microsoft.com

结论、缓解和预防

即使攻击者可以通过此类攻击绕过某些 MFA 方法，MFA 仍然是保护您的身份的重要部分。根据微软在 2022 年 2 月发布的Cyber Signals报告，只有[22% 的 Azure Active Directory 身份](https://www.microsoft.com/security/blog/2022/02/03/cyber-signals-defending-against-cyber-threats-with-the-latest-research-insights-and-trends/#:~:text=only 22 percent of customers using Microsoft Azure Active Directory (Azure AD))使用 MFA。因此，目前便利攻击者将针对 78% 的根本不使用 MFA 的用户，而更有针对性的攻击可能会尝试使用此处描述的高级方法。

但这个低数字也意味着 78% 的人可以从比带外 SMS 更好的 MFA 选项开始！

• 基于 SMS 的 2FA 长期以来被认为是不好的，因为SIM 交换等攻击
• 仅基于 TOTP 的 App based 2FA 无法提供额外信息，但如果以下选项均不可用，则绝对使用它
• 带有 Microsoft Authenticator 的基于应用程序的 2FA 是 Microsoft 客户基于应用程序的最佳选择，因为开发人员可以集成新功能，例如附加上下文或基于 GPS 的定位围栏
• FIDO2 是 2FA 方法的黄金标准。

它可以防止用户登录错误的网站，从不通过互联网发送凭据，具有硬件支持的加密密钥，并且需要真正的人工交互才能工作。最棒的是，您很可能已经将它与 Windows Hello 一起内置到您的设备中。FIDO 联盟最近发布了一份新的白皮书，介绍了计划中的后续步骤，例如使用任何智能手机作为 FIDO 密钥，使用蓝牙或 FIDO 凭证漫游。

但是，即使您无法在一夜之间推出强大的 MFA，作为 IDP 的 Azure Active Directory 也有比仅 MFA 更多的选项来保护您的用户。设备合规性也是防止未经授权访问的好工具。

让我们看看你今天可以做什么：

使用 FIDO2 安全密钥

减轻这种网络钓鱼攻击的最佳方法是使用 FIDO2 安全密钥实现无密码。

[你会在这里 找到我关于无密码的博客系列。

由于您最初很可能无法对所有帐户使用 FIDO2，因此您仍然可以通过条件访问和其他方法缓解这些攻击。

要求将设备标记为合规或已加入混合 Azure AD 的设备

由于这些访问控制依赖于来自 Intune 的额外遥测和/或客户端设备上的有效设备证书，因此可以完全防止这种类型的网络钓鱼攻击。

攻击者代理无法提供或中继受害者的设备证书，因此无法成功登录用户。

需要设备合规性时无法登录。

无法在已加入混合 Azure AD 的设备上登录。

使用新的“跨租户访问设置”，您可以将此要求扩展到受信任公司的访客帐户。此功能允许你信任用户的主租户来处理 MFA 并将设备合规性或混合 Azure AD 加入设备状态传递给你的租户。

外部身份的身份验证和条件访问

信息

此功能目前处于预览阶段。

条件访问会话控制

登录频率

将条件访问设置“登录频率”设置为更短的时间不会阻止攻击本身，但会限制攻击者可以使用钓鱼会话 cookie 的时间窗口。仅当从非托管或共享设备访问资源时才应应用此会话控制。否则，您将面临许多登录请求和愤怒的用户的风险。

在配置之前查看文档。

在我的测试中，如果用户选择保持登录状态，或者会话设置“持久浏览器会话”设置为“始终持久”，则会话 cookie 的有效期为 90 天。

笔记

此设置将在条件访问策略处于活动状态时立即应用，如果目标用户的所有会话与定义的时间范围不匹配，则它们将失效。它不仅适用于新会话。

如果您将“持久浏览器会话”设置为“从不持久”，则 cookie 仅在 24 小时内有效，并且浏览器在关闭后将不会存储它。

持久浏览器会话

您应该将此限制应用于所有管理帐户。

笔记

此设置不适用于已建立的会话。您可能需要考虑撤销所有受影响用户的会话以加快部署。

启用号码匹配

为避免受害者只需在验证器应用程序中单击“验证”，数字匹配要求用户输入显示在计算机屏幕上的数字。这并不能阻止攻击，但与“附加上下文”一起，它可以让用户在点击之前猜测两次。

信息

使用无密码手机登录时，号码匹配是默认设置。

在 Microsoft Authenticator 通知中启用其他上下文

附加上下文将基于客户端 IP 地址的粗略位置地图添加到 Microsoft Authenticator 应用程序中的通知。结合数字匹配，这有助于用户识别执行不佳的网络钓鱼攻击。

你能发现 evilnginx2 网络钓鱼攻击和正常登录之间的区别吗？

由于使用了启动客户端的公共 IP 地址，因此在使用中央 VPN 或代理解决方案之类的解决方案或在 Azure 数据中心中使用带有 Internet 分支的 Azure 虚拟桌面之类的 VDI 解决方案时，可能会导致混淆。

我写了“执行不力的网络钓鱼攻击”，这是因为如果你有一个拥有资源的对手，他们可以将网络钓鱼服务器部署在目标附近的某个地方，以避免被轻易检测到。

注册安全信息或其他设备时需要 MFA

遗憾的是，在使用“需要多重身份验证”授权控制时，此条件访问策略并未添加额外的保护。

当使用 MFA 进行初始登录时，不会再次提示用户使用 MFA。

希望这在未来会有所改变。

在那之前，您可以尝试将安全信息注册限制在公司设备上，如果您的一线员工没有公司拥有的设备，这将使入职变得困难。

对于用户操作“注册或加入设备”，只有[“需要多重身份验证”](https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-cloud-apps#:~:text=this user action%3A-,Require multi-factor authentication,-is the only)选项可用。

撤销会话

如果您怀疑某个用户遭到入侵，第一步应该是撤销所有活动会话，检查新添加的 2FA 选项并更改密码。

之后，攻击者无法再使用钓鱼 cookie，无需重新认证。

管理员可以一键撤销所有会话。

要求最终用户重新登录

无效会话的使用也显示在登录日志中

其他方法和信息

Joe Stocker @ITguySoCal几年前就该主题发表了一篇很棒的博客文章，涵盖了其他防御措施，例如使用受信任位置（基于 IP 的访问控制）、Exchange Online 客户端访问规则或使用 . evilnginx2 当时的自定义品牌问题已在此期间得到解决，不应被视为保护。

查看博客文章以获取更多信息。

打猎

您可以使用 KQL 来寻找可能的恶意活动。

可能非法添加安全方法

搜索所有事件，如果用户最初使用一个 IP 地址登录，然后从另一个 IP 地址注册新的安全方法。您可以更改这些事件之间的最大时间差，以最大限度地减少噪音。

let SecurityInfoRegistered = AuditLogs
| where OperationName == "User registered security info"
| extend UserPrincipalName = tostring(TargetResources[0].userPrincipalName)
| extend IPAddress = tostring(InitiatedBy.user.ipAddress)
| project TimeGenerated, UserPrincipalName, OperationName, ResultDescription, IPAddress;
SigninLogs
| where ResultType == 0
| mv-expand todynamic(AuthenticationDetails)
| extend authenticationMethod = tostring(AuthenticationDetails.authenticationMethod)
| where authenticationMethod != "Previously satisfied"
| join kind=inner SecurityInfoRegistered on UserPrincipalName
| project-rename PossibleAttackerIPAddress = IPAddress1, SecurityInfoTimeGenerated = TimeGenerated1, SecurityInfoResultDescription = ResultDescription1, InitialLoginMethod = authenticationMethod
| extend TimeDifference = datetime_diff('second',TimeGenerated,SecurityInfoTimeGenerated)
| where TimeDifference < 0 and TimeDifference > -86400
| project TimeGenerated, TimeDifference, UserPrincipalName, OperationName, InitialLoginMethod, SecurityInfoResultDescription, IPAddress, PossibleAttackerIPAddress,  SecurityInfoTimeGenerated
| sort by TimeGenerated

来自不同 IP 地址的初始登录，而不是用于注册新安全信息的 IP 地址。

不使用 FIDO2 或 WHfB 的管理员

使用 FIDO2 或 Windows Hello 企业版 (WHfB) 以外的登录方法识别每个管理帐户。您将需要一个仅适用于您的管理帐户的条件访问策略才能使用此查询。

我建议使用条件访问中的目录角色功能来创建这样的条件访问策略。

let ConditionalAccessDisplayName = "Require MFA for administrators";
union SigninLogs, AADNonInteractiveUserSignInLogs
| where ResultType == 0
| mv-expand todynamic(AuthenticationDetails)
| extend authenticationMethod = tostring(AuthenticationDetails.authenticationMethod)
| where authenticationMethod !in ("FIDO2 security key","Previously satisfied","Windows Hello for Business")
| mv-expand ConditionalAccessPolicies_dynamic
| where ConditionalAccessPolicies_dynamic.displayName == ConditionalAccessDisplayName  and ConditionalAccessPolicies_dynamic.result != "notApplied"

译文申明

• 文章来源为近期阅读文章，质量尚可的，大部分较新，但也可能有老文章。
• 开卷有益，不求甚解，不需面面俱到，能学到一个小技巧就赚了。
• 译文仅供参考，具体内容表达以及含义, 以原文为准 (译文来自自动翻译)
• 如英文不错的，尽量阅读原文。(点击原文跳转)
• 每日早读基本自动化发布(不定期删除)，这是一项测试

最新动态: Follow Me

微信/微博：red4blue

公众号/知乎：blueteams