这个故事讲述了我如何最终通过使用 EWS 错误配置来访问电子邮件收件箱并（有能力）转储全局地址列表，从而使用未注册 MFA 的 AD 帐户。

和往常一样，我会尝试用两种不同的方式来发布这篇文章，它们是：

• 对于那些只需要了解这一发现要点的人（如果读者已经理解了每一个流程，InshaAllah 可以节省大量的时间）——请参阅 TL;DR 部分，并且
• 对于那些需要了解这一发现的执行流程或历程的人来说，InshaAllah，它可以告诉读者一些思维模式，并希望能够帮助人们丰富他们的见解。

请尽情欣赏这个故事。

一、介绍

关于这个问题简单说一下几点：

• 寻找允许通过两种方法登录的目标，即作为员工（使用域帐户）和作为专门为站点本身创建帐户的用户。
• 要使用员工帐户（域帐户）登录，该网站将引导我们到另一个 .TLD（例如：从 .com 到 net）—— ADFS 端点。
• 心态：如果我们可以使用域帐户登录，我们就可以访问这个网站，对吗？
• 使用 .net 域名（而非 .com）在 GitHub 上开始侦察。例如：密码“.target.net”

请参阅Th3g3nt3lman在 Bugcrowd University 上的演讲：Github Recon 和敏感数据暴露或我的一篇文章：从 Recon 到优化 RCE 结果。

• 我发现一个存储库，其中包含多个文件，代码超过 3,000 行。在其中一行中，我发现一个用户名（服务帐户 - svc_nameofsvc）和一个看起来像域帐户的密码。尝试使用该帐户在 ADFS 上登录，但结果显示该帐户未注册所使用的 MFA。简而言之，该帐户必须注册所应用的 MFA 才能登录。当然，我们也需要一个用作 MFA 的“东西”。
• 试图增加其影响力。如果我们报告一个问题，说我们找到了一个有效的密码，但却因为被阻止而无法登录，那就太不公平了。
• 尝试找到 EWS 端点→ .com 和 .net 的子域枚举 → 查找电子邮件子域（常见实现）→ 将 EWS 置于找到的子域后面 → 显示登录提示 → 使用找到的凭据登录 →能够登录- 此端点未实施 MFA（未显示收件箱，请记住，这是 EWS）。
• 对EWS 端点执行MailSniper工具。成功读取收件箱。

请参阅Black Hills Infosec Research：绕过 OWA 和 Office365 门户上的双因素身份验证。有关其研究的 PoC 视频：O365 MFA 绕过信息。

• 制作一份报告（约7页）并将此问题报告给程序所有者。
• 试图再次增强其影响力。告诉他们，如果我们能够利用此漏洞转储“全局地址列表”，那么就有可能实现这一点。这样，我们还可以对
  
  已创建的其他服务帐户进行密码喷洒（使用相同的已找到密码） 。

请参阅“使用 MailSniper 滥用 Exchange 邮箱权限——转储全局地址列表”。以及“使用 MailSniper 攻击 Exchange——密码喷洒”。

• 当天就进行了分类并给予奖励。第二天就修复了。

二、旅程

2.1. 幕后花絮（第一部分）

有一天，我想测试一个包含在范围内资产中的子域。从众多可用资产来看，似乎只有此资产允许用户使用两种方式登录：以员工身份（使用域帐户）登录，以及以专门为此应用创建帐户的用户身份登录。

当时我尝试用一些常见的、被认为强度较低的密码登录，但效果并不好。在几次尝试失败后，我决定尝试用员工账户测试登录方法。

当我们选择使用员工帐户登录时，应用程序会将我们引导至具有另一个 .TLD（例如，从 .com 到 .net）的 ADFS 端点。由此我们可以得出结论：如果我们拥有员工帐户（域帐户），那么我们就可以登录这些应用程序。

那么，我们应该怎么做呢？

好吧，我又想回归本源了。在这种情况下，我开始在 GitHub 上进行侦察，寻找一些可能对我有用的东西。（这个讲座可以作为很好的参考：Github 侦察和敏感数据暴露）。简而言之，我发现了一个有趣的仓库，它让我发现了一些有趣的发现（本文不再讨论）。提交报告后，他们会在两天内进行分类并给予奖励。

关于此侦察部分的另一个参考：我的一篇文章：从侦察到优化 RCE 结果。

2.2. 幕后花絮（第二部分）

那天之后，我发现了另外 2 个简单的问题（也得到了奖励），然后我就不再知道该如何处理现有目标了。

于是，我又回到了 GitHub，想换换口味。我又在 GitHub 上输入了“.target.net”这个密码。在之前的仓库从 GitHub 下架后，我发现另一个有趣的仓库在第一页排名第五。

说实话，这些结果里确实没有密码信息。但就我的经验而言，凭证信息并不总是放在参数后面。正是出于这种想法，我开始探索这个仓库。

2.3. 探索

当我打开那个仓库时，我被代码行数（超过 3000 行）吓了一跳。好吧，我发现这个代码的时候正好是午夜，当时我的状态不太好，无法阅读这么多行代码——别忘了，我做这个 GitHub Recon只是为了呼吸新鲜空气。

但是，当我看到第 6 到第 27 行时，情况发生了变化——关于 AD 帐户和连接字符串（尽管这些行上还没有凭据）。

从这里开始，我希望开发人员犯一个常见的错误，将硬编码凭证放入这个 repo 中。（是的，希望成真）！

在第 394 行，我找到了 2 个我认为是凭证的文本（我怀疑是否有开发人员会提出如此困难的参数）。

字符串表 = “file.xlsx”; XYZEndpoint 端点 = 新 XYZEndpoint（“ username_here ”，“ very_complex_password_here ”）;字符串响应 = 端点.GetCollectionData（表）;

基于这种情况，我立即在 ADFS 端点（使用 .net 域的端点）中使用它。尝试登录后，我什么也做不了。该帐户未在Censored MFA上注册。

（为了避免误解本报告，我删除了所使用的 MFA。我担心人们会认为这是一个 MFA 供应商漏洞——注意：它不是）。

我停下来了吗？还没有。我尝试寻找其他终端（例如 VPN 服务），但仍然无法登录。我尝试了大约 3 个 VPN 终端，但都无法登录。

那么，我停下来了吗？还是一样，还没有。我必须努力扩大它的影响力。如果我们报告一个问题，说我们找到了一个有效的密码，但却因为被屏蔽而无法登录，那就太不礼貌了。

在这种情况下，时间越来越紧迫！为什么？因为我确信，我的国家/地区至少进行了四次以上的尝试，因此一定会触发警报。

2.4. 无需注册受审查的 MFA 即可阅读收件箱信息

2.4.1. Exchange Web 服务 (EWS) 端点！

这种情况几乎毫无希望，那么感谢真主，我想起了 BlackHills InfoSec 发布的一项关于绕过 OWA 门户上的双因素身份验证的研究。

根据他们的研究，他们（BlackHills InfoSec）表示，尽管该帐户已被双重身份验证 (2FA) 封锁（在本例中，该帐户并未被封锁，但尚未在所使用的多重身份验证 (MFA) 上注册），但我们仍有可能阅读该帐户下的所有电子邮件。这可以通过在 EWS 端点上利用常见的配置错误来实现。

我将引用一个很好的解释（并让专家向你解释，包括那些发表精彩演讲的人——尼克兰德斯的《坏人的展望与交流》 ——以及那些发布这项研究的人——来自 Black Hills Infosec 的 Beau Bullock）。

Beau 说：在 DerbyCon 期间，我旁听了 Nick Landers 的演讲，题为“Outlook & Exchange for the Bad Guys”。这是一场精彩的演讲，我强烈推荐大家去听一听。演讲期间，Nick 收到了听众的提问，询问双因素身份验证 (2FA) 能否阻止他在演讲中提到的那些攻击。Nick 的回答让我非常感兴趣。他说：“我看到一些组织在 OWA 上禁用了 2FA。所以当你访问 Outlook Web Access 时，你必须提供令牌才能完成登录。但这并不能阻止很多此类攻击，因为双因素身份验证不适用于 EWS 或自动发现页面上的 NTLM 身份验证。”

那么，EWS 是什么？Beau 的研究报告指出：“ EWS 是在 Exchange 服务器上启用的基于 Web 的 API，微软建议客户在开发需要与 Exchange 交互的客户端应用程序时使用它。该 API 允许应用程序与用户邮箱中的电子邮件、联系人、日历等进行交互。”

简而言之，在一般实施中（感谢程序所有者的解释），即使 ADFS 已受到 MFA 保护，系统所有者有时也会忘记强制其他端点使用 MFA（在本例中为 EWS 端点）。

2.4.2. 查找 EWS 端点 — 子域名枚举！

起初，我并不清楚该目标是否存在 EWS 端点配置错误。因此，我尝试进行子域名枚举。

说实话，我知道公司通常的做法是把这个 EWS 端点放在邮件/电子邮件/网页邮件子域上。但是，进行这种枚举并不浪费时间。至少只需要几分钟。而且，InshaAllah，希望结果以后能对我有用（谁知道呢，也许有一天他们会把 *.target.com 设为范围内的目标）。

注意：在这种情况下，我使用由 Screetsec 创建的Sudomy 子域名枚举工具。

几分钟后，我得到了结果。不出所料，他们有一个“ mail ”子域名。当我第一次访问 mail.target.com 时，这个子域名再次将我定向到 ADFS 端点（.net TLD）。第二次尝试时，我尝试将 EWS 放在 mail.target.com 后面，结果出现了登录提示。

当我把找到的凭证输入到这个提示符下时，我终于成功登录了！我无需提供任何 MFA 即可登录，也无需将此帐户与所使用的 MFA 一起注册。

从这个结果出发，我决定继续我的第一个目标，那就是无需注册所使用的 MFA 即可阅读收件箱。

2.4.3. 准备环境

因此，为了读取这些账户的邮件，我们首先需要下载 MailSniper 工具（https://github.com/dafthack/MailSniper）。这款工具的主要功能是方便用户使用特定关键词搜索邮件数据。此外，它还可以帮助我们在 EWS 环境中读取邮件。

2.4.4. “绕过”

下载工具后，运行 powershell 并执行以下几个命令：

C:UsersYoKoTools> powershell.exe -exec 绕过Windows PowerShell版权所有 (C) Microsoft Corporation。保留所有权利。试用新的跨平台 PowerShell https://aka.ms/pscore6 PS C:UsersYoKoTools> cd .MailSniper-master PS C:UsersYoKoToolsMailSniper-master> Import-Module .MailSniper.ps1 PS C:UsersYoKoToolsMailSniper-master> Invoke-SelfSearch -Mailbox username @ domain.tld -ExchHostname mail.domain.tld -Remote

简而言之，有 2 个命令需要执行，它们是：

• 导入模块 .MailSniper.ps1和
• Invoke-SelfSearch-邮箱用户名@ domain.tld -ExchHostname mail.domain.tld -Remote

请注意，输入命令后，会弹出一个凭证框，要求输入[email protected]的凭证。我们只需再次输入凭证即可。

如果一切正确，那么工具将向我们提供“它们”是否找到收件箱文件夹的信息。

[*]在命令管道位置 1尝试使用 Exchange 版本 Exchange2010 cmdlet Get-Credential为以下参数提供值：凭据[*] 使用 EWS URL https://mail.domain.tld/EWS/Exchange.asmx [***] 找到文件夹：收件箱[*] 现在搜索邮箱：[email protected]中的术语 *password* *creds* *credentials*。

2.4.5. 结果

几分钟后（取决于邮件中搜索到的关键词的数量），我们就能得到结果。在本例中，与该账户的密码、凭证或凭据相关的信息就是社交媒体信息。

为了确保结果正确，我还尝试用相同的账号和密码登录了那些社交媒体。结果，正确！可惜的是，社交媒体行为保护机制要求我输入正确的电话号码（这很正常，因为我尝试过从其他国家/地区登录）。

2.4.6. 再次尝试增强其影响力

也许有人会问，我们无法用这个账户登录VPN，而且我们利用这个账户进行攻击的权限也很有限（因为我们无法用它进入目标内网）。那么，我们还能用这个账户做什么呢？

嗯，至少在我看到 Black Hills Infosec 的 Beau Bullock 发布的另一项研究之前，我也有类似的疑问。简而言之，针对我们的情况，我们还可以做两件事。

2.4.6.1. 全局地址列表转储和整个帐户的密码喷洒

在我们进一步讨论之前，让我问你一个问题，系统所有者在维护多个服务帐户时常犯的错误是什么？（记住，在这种情况下，我找到了一个服务帐户）。

如果您认为系统所有者有可能对另一个服务帐户（或他们管理的另一个帐户）使用相同的密码，那么我可以说答案是正确的。

所以，如果我们能够转储全局地址列表，那么如果真主愿意，我们就有机会找到其他具有相同模式的服务帐户。我们也有机会对所有找到的密码的服务帐户执行密码喷洒攻击（无需测试其他凭据，因为我相信企业中存在速率限制保护。我们只需要测试找到的一个密码）。

为了做到这一点，我们可以看到以下两项研究：

• 第一项研究：利用 MailSniper 滥用 Exchange 邮箱权限。转储全局地址列表的方法可在本研究的“ Invoke-OpenInboxFinder ”部分找到。
• 第二项研究：使用 MailSniper 攻击 Exchange。Beau Bullock 提供的一条实用信息是：“在测试中，我注意到 EWS 密码喷洒方法速度明显更快。Invoke-PasswordSprayOWA 和使用 15 个线程的 Burp Intruder 都花费了大约 1 小时 45 分钟才完成对 10,000 个用户的喷洒。而对 EWS 喷洒相同数量的用户仅耗时 9 分 28 秒。 ” 是不是很棒？

从现在开始，我们就有机会提升它的影响力了！我说“有机会”，是因为我不确定这项技术是否有效。但通过研究报告中提出的方法，我确信它是有效的！

注意：我没有执行此操作。没有任何权限，我们无法执行此操作。（是的，在真正的攻击中，攻击者会在没有请求任何权限的情况下执行此操作，但请注意，在漏洞搜寻中，我们并没有打算进行破解。）

2.4.7. 另一种可能的情况

另一种情况是，外部攻击者可能会将此问题与社会工程活动结合起来。例如，他们假装是这些被发现账户的合法所有者，并尝试通过电子邮件欺骗（target.tld 域名）与受害者进行通信。

然后，攻击者会与内部团队“建立关系”，以确保攻击者能够完全访问该帐户（使用攻击者控制的设备/电话号码等注册MFA）。目前尚不清楚这种情况的有效性，但考虑一下风险或许是值得的。

2.5. 奖励

该报告已在一天内得到分类和奖励，并在第二天得到修复。

三、经验教训

在本节中，我想重新添加我在一篇文章中提到的一些经验教训：

• 以我的简单观点来看（如有错误，请指正），侦察并不总是指资产发现活动。在这种情况下，它还可以指我们尝试了解 API 的工作原理、目标的开发文化等等。

记住，在回复@Mongobug的一条推文时， @NahamSec也用非常简单的语言解释了侦察（recon）的定义之一：“侦察不应该仅限于寻找资产和过时的内容。它还应该理解应用程序并找到那些不易访问的功能。为了取得成功，需要在侦察和传统的应用程序黑客攻击之间取得平衡。”

• 不要放弃阅读你在 GitHub Recon 活动中在 GitHub 仓库中找到的每一行代码。说实话，我还没有完全读完代码。我只是抓住要点，阅读参数，尝试理解流程，看看是否有任何好用的东西。
• 据我经验，凭证并不总是放在参数后面。从这个角度出发，尝试探索你找到的存储库。
• 请尽情享受你的漏洞搜寻活动。也许并非所有人都认同这一点，但不要总是想着赏金（尤其是如果你刚开始接触这个领域，并且从未有过相关经验）。尽量多测试“合法/官方”的目标。如果真主愿意，这可以提升你的知识、方法，以及在寻找赏金目标中的漏洞时提升你的其他方面。

我尝试从那些没有提供赏金（但开放了负责任的漏洞披露计划）的目标那里学习很多我从未接触过的技术。在这一点上，我可以说的是，那些使用的技术并不总是我们每天都会接触到的技术。换句话说，我们需要一个官方的“游乐场”（合法目标）来学习并熟悉它。

• 尝试回归基本原则
• 如果你觉得有人能轻而易举地做到这一点，那就试试@BruteLogic的这句励志话语：“他们以为我们能轻而易举地完成任务。但这需要付出大量的努力，无数个小时的反复试验。我们花了大量时间分析搜索引擎结果，阅读大量毫无用处的信息。最终他们看到的只是表演时间。我们让它看起来很容易，但其实不然。”

• 最后一句是我最喜欢的名言（说真的，这很美）：

这些话确实极大地激励了我去分享，尽管我分享的东西并不总是好的。但在真主的允许下，我得到了很多反馈，激励我改正错误或改进。

好了，我的小文章终于到此结束了。下次再见，InshaAllah。

四、致谢

• Th3g3nt3lman在 Bugcrowd 大学发表演讲：Github Recon 和敏感数据暴露。
• 绕过 OWA 和 Office365 门户上的双因素身份验证— Black Hills Infosec。
• O365 MFA 绕过信息（PoC 视频）— Black Hills Infosec。
• Nick Landers 撰写的《坏家伙的展望与交流》 — DerbyCon 6.0
• 使用 MailSniper 滥用 Exchange 邮箱权限— Black Hills Infosec。
• 使用 MailSniper 攻击 Exchange — Black Hills Infosec。
• MailSniper—— https://github.com/dafthack/MailSniper。
• Screetsec 的Sudomy 子域名枚举工具。
• 从侦察到优化 RCE 结果。

公众号:安全狗的自我修养

bilibili:haidragonx