Tales From the Incident Response Cliff Face – Case Study 2
在本期《事件响应前线故事》中，我们将回顾一起近期的 engagement，涉及一系列跨越数月的事件。
焦点：具有辅助初始访问的勒索软件。
摘要
初始攻击者侵入受害者环境，建立了全面的立足点，然后在暗网上广告出售。
然而，受害者是一个照顾最脆弱群体的非政府组织（NGO）。出于某种原因——或许是财务激励不足，或许是道德感——受害者环境的访问权限在市场上挂了整整八个月，最终被第二个攻击者购买。
在本报告中，我们将详细阐述毫无准备的受害者是如何为这起勒索软件事件做好准备的，并照常分享一些见解，以帮助您避免陷入同样的陷阱。
简而言之，我们将涵盖：
- 威胁行为者如何通过利用面向公众的服务器上的漏洞获得初始立足点。
- 一种知名技术，允许攻击者几乎在域规模上窃取凭证，并绕过领先的AV/EDR解决方案的检测。
- 我们能够观察到的NoEscape勒索软件操作者的行动。
Proxywhat？
我们的 engagement 在勒索软件引爆近两周后开始。幸运的是，客户设法利用备用备份进行恢复并避免业务中断，但这意味着他们的干预污染了犯罪现场，无法完全看清网络杀伤链。
取证收集的初步分类显示，本地Exchange服务器在威胁行为者的操作中扮演了核心角色，是RDP内部横向移动的源头。
更糟糕的是，自2021年以来缺乏补丁加上暴露在互联网上，几乎可以肯定它已经被ProxySomethingWave击中。
这一直觉很快被证实是正确的。虽然用于追踪这族Exchange CVE的常规日志自2023年8月中旬才可用，且未显示任何利用痕迹，但我们确实在磁盘上找到了两个webshell。我无法确定先前安装的Exchange版本，因此不能自信地说出具体利用了哪个：
- ProxyShell（CVE-2021-34473、CVE-2021-34523和CVE-2021-31207）
- ProxyLogon（CVE-2021-26855、CVE-2021-27065）
- ProxyNotShell（CVE-2022-41040和CVE-2022-41082）
然而，基于这是一个已知CVE的假设，可以安全地假设它一定是其中之一。
这两个webshell经过轻度混淆以避免静态磁盘检测，但保持简单（如下面的图1-4所示）。它们会执行cadataKey请求参数中的任何内容，然后强制返回404或重定向到另一个页面。
我的假设是，这是一种让蓝队操作员更难识别webshell交互的方式，并降低被他们通常使用aspx过滤器和200返回码技术发现的风险。
图1. 混淆的Webshell 1
图2. 去混淆的Webshell 1
图3. 混淆的Webshell 2
图4. 去混淆的Webshell 2
这两个文件的时间戳表明它们创建于2022年12月。此外，如图5所示，我发现一个文件在第一个webshell创建前几秒被创建。
这个文件伪装成ApacheBench命令行实用程序，但很快被证明是一个Meterpreter stager。Meterpreter stager基于一个模板可执行文件构建，允许将恶意shellcode注入到.text节。
图5. 伪装成ApacheBench命令行实用程序的文件
这个stager然后与103.112.232.44:443通信以获取Meterpreter负载的其余部分。然而，在我们的调查中，很明显它不是唯一一个尝试连接的负载（见图6）。 behind that particular IP是一个被入侵的Exchange服务器，用于入侵其他易受攻击的Exchange服务器。
这是从另一个受害者发起攻击的经典案例——因此黑客可以隐藏他们的身份。
图6. 多个恶意软件尝试连接受害者组织的证据
The Eye of Sauron
取证分析显示，NoEscape通过域管理员账户使用RDP进行了横向移动。在确认后者未在受限管理员模式下执行（这只需要NT哈希）后，通常的问题再次出现：攻击者如何获得明文密码？
一个合理的猜测是，攻击者通过利用先前提到的在Exchange服务器上授予本地系统权限的CVE获得了它。如果像这里的情况一样，缺少一个像样的AV/EDR解决方案，从LSASS进程转储凭证将变得轻而易举，并提供对域管理员凭证的轻松访问，这些凭证很可能缓存在Exchange服务器上。
但在这个案例中，合理的猜测并不是正确的猜测！
在这个案例中，LSASS不包含明文凭证，因为WDigest未启用。此外，NTLM哈希也不容易被破解，因为客户确认他使用了复杂的18字符密码。最后，密码没有出现在常见的凭证存储中，也没有出现在简单的文本或脚本文件中。
突然之间，回答攻击者如何实现这一权限提升变得非常有趣。为了找到答案，我们必须回到教科书。
关于窃取明文凭证
我们对明文密码的了解是，它们在现代系统中的生命周期很短。明文密码仅在被获取时存在，但一旦凭证需要被验证（无论是本地还是远程），密码就会被哈希化，明文形式基本上永久丢失。这意味着只有少数其他方式可以获得明文形式。最基本的方式涉及监听交互式登录过程。这就是键盘记录器所做的（顾名思义）通过收集击键。更精细的技术专门针对Windows交互式登录过程。一个著名记录的技术涉及Windows身份验证提供程序，包括两组：安全支持提供程序和网络提供程序。在我们的故事中，我们将专注于后者。
如果您想了解更多关于安全支持提供程序和不同窃取明文凭证技术的信息，请阅读更多这里：
https://www.scip.ch/en/?labs.20220217
通过滥用网络提供程序窃取明文凭证的技术在2020年有一个名为NPPSPY的实现
https://github.com/gtworek/PSBits/tree/master/PasswordStealing/NPPSpy（我还找到了可以追溯到2000年代初的技术描述）
https://www.giac.org/paper/gcih/117/microsoft-network-provider-exploit/101145
TLDR：一个简洁的可视化解释了该技术的工作原理。dll需要在注册表中“注册”才能被调用，通过声明一个网络提供程序。
https://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy
回到手头的案例（研究）：应用理论
该技术的记录步骤意味着攻击者必须在注册表中进行一些更改，这给了我们测试NPPSPY假设的线索。当我们查询注册表以寻找利用痕迹时，我们发现引入了一个新的网络提供程序（见图7）。
图7. 新网络提供程序的证据
如图7所示，我们从调查中发现，ntoskrnl.dll被恶意放置在system32文件夹中（Windows不使用ntoskrnl.dll，只使用ntoskrnl.exe），并创建了一个名为credman的虚拟网络提供程序，指向该dll。有趣的是，注册表的最后写入时间是2023年2月28日。
鉴于该技术需要允许用户在注册表中进行更改的管理员权限（利用Exchange漏洞可以授予），我们将两个利用事件联系起来。
事实上，围绕注册表修改时间的恶意.NET编译工件让我们相信Exchange漏洞可能被多次利用。
下一步是分析恶意dll（ntoskrnl.dll）以确定它在哪里存储了掠夺的文件。关于这个dll的现有威胁情报给了我们这些信息（图8）。
图8. 该dll已经被充分记录
最重要的是，我们可以看到它生成了以下文件“C:\ProgramData\Package Cache\Windows10.0-KB5009543-x64.msu”。在受感染服务器上快速检查文件内容揭示了明文窃取的密码：
图9. 使用NPPSPY技术记录被盗凭证的文件样本
我们在调查方面的很多工作是由我们的直觉驱动的。我们的预感。我们探索这些，看看它们是否带来成果。因此，原本只是对NPPSPY技术的一些管理员用户密码的简单确认激发了我的好奇心：文件中有很多账户，远多于通常在Exchange服务器上看到的（应该只有管理员用户）。似乎每个常规域用户的凭证都存储在这里。他们都交互式登录到它的想法是完全不可信的。
或者我们这么认为……
可能的解释是什么？
从“攻击者如何找到明文密码？”我们转向问题“为什么Exchange服务器上有这么多常规域用户凭证？”
我们怀疑文档中涵盖的技术范围在特定条件下可以广泛扩展。直观的解释是，它必须以某种方式捕获了与邮箱相关的身份验证。查找NPPSPY与Exchange Server的结合，我只找到了一篇博客文章，给了我需要的信息：
https://www.huntress.com/blog/cleartext-shenanigans-gifting-user-passwords-to-adversaries-with-nppspy
这篇文章表明，在Exchange服务器上使用NPPSPY会扫荡所有与邮件相关的身份验证。尽管这可能很有趣，但博客文章没有涵盖为什么、如何或在什么条件下。
这让我寻找进一步的验证，因此我继续在我的实验室中针对全新的默认安装的Exchange Server 2019重现它。
在实验室中重现该技术
我的方法是通过不同方式（OWA、ECP、Powershell等）交互式登录，并查看哪些登录尝试会与掠夺文件交互，从而表明凭证盗窃。
例如，当通过OWA登录时，我得到以下命中（见图10）。
图10. IIS工作进程写入掠夺文件
图11. 证明OWA是操作背后的进程
图11显示启动进程是Microsoft Exchange Outlook WebApp（OWA）。基于我的发现，我检查了堆栈跟踪（图12）。
图12. OWA身份验证后的堆栈跟踪
堆栈跟踪确认OWA身份验证通过了恶意网络提供程序，并调用了NPLogonNotify API for loot.dll。
有趣的是，堆栈跟踪还显示涉及authbas.dll。如下面的图13所示，这证明这个dll负责IIS BasicAuthenticationModule
一旦我意识到这一点，迷雾就清晰了，一切都变得水晶般清晰。
图13. authbas.dll参与的证据
身份验证过程通过调用LogonUserExW进行（见图46。）。这表现得好像身份验证是针对本地计算机进行的，正如我们从NPPSPY与交互式/远程交互式登录的文档中所期望的那样。
图14. 身份验证看起来像是针对本地计算机进行的
在此步骤之后，然后调用Mpr.dll。提醒一下，Mpr.dll代表多路由器提供程序，处理与已安装网络提供程序的通信。Mpr.dll检查注册表以确定哪些提供程序已注册，然后逐个通过它们。
因此，正如我们所想，我们的恶意网络提供程序被调用，我们的dll通过导出的NPLogonNotify被触发。凭证然后传递给它，并最终出现在文本文件中，如对WriteFile的调用所示（上面的图11）。请注意，NPLogonNotify的功能由攻击者任意设置。在这种情况下，攻击者认为仅将凭证写入文本文件就足够了，但他们本可以做更复杂的事情，例如通过网络发送凭证，这将消除磁盘上的任何痕迹。
因此，我们能够确认威胁行为者确实滥用了IIS基本身份验证与NPPSPY技术，将自己置于每个Exchange Web身份验证中。
此Exchange Web身份验证的相应事件日志证实了我们对IIS基本身份验证的观察，因为登录尝试是类型8：网络明文（图15）。
图15. OWA身份验证的相应事件日志
聚焦：检测和响应——如何应对这种攻击
我关注这种攻击的原因是为了探索它包含的新元素，并提供检测和预防指导。
让我们谈谈检测途径
不幸的是，此测试中使用的dll基于NPPSPY存储库，但经过重新编译以避免AV/EDR检测，几乎没有任何复杂性。它确实成功绕过了端点安全解决方案，这说明了这种技术的威力，尽管威胁模型成本高昂，因为它需要管理员权限。请注意，我基于一个假设工作：如果适当的AV/EDR到位，管理员权限绝不应给攻击者自由漫游的能力。
因此，如果AV/EDR目前似乎对此视而不见，我建议专注于启用此攻击的注册表更改。任何攻击者都必须宣布他的网络提供程序以及DLL。这意味着需要密切监视此类更改。我们理解监视需要一些资源承诺，正如我们客户群中进行的注册表更改数量所示，但这就是像长尾分析这样的东西可以筛选出误报的地方。Sysmon和EDR具有命令、进程执行和注册表更改的遥测，可用于狩猎和检测。Windows事件日志也可以利用，但需要显式审计。
有关更多信息，请阅读以下文章：
https://www.manageengine.com/products/active-directory-audit/how-to/how-to-audit-windows-registry-changes.html#:~:text=In%20Event%20Viewer%20window%2C%20go,event%20to%20view%20Event%20Properties
现在，谈谈预防问题
我们希望防止收集登录到Exchange服务器（或任何Windows主机）的用户的凭证，包括通过OWA/ECP进行身份验证的用户。
从交互式登录窃取凭证
对于Windows 11用户，Microsoft发布了2H22安全基线，其中包括一个新设置“为系统启用MPR通知”。如上所述，Microsoft建议将其设置为“禁用”以防止密码泄露给提供程序（例外情况适用）。
这是一个狙击手修复——如果您不使用提供程序，则有用。
https://techcommunity.microsoft.com/t5/microsoft-security-baselines/windows-11-version-22h2-security-baseline/ba-p/3632520
如果您不使用Windows 11，一种方法是使用Active Directory中推荐的受保护用户组。我针对该技术进行了测试，并可以确认它抑制了MPR通知（登录后未生成mpnotify.exe进程）。不幸的是，我无法解释其内部原理，只能从Microsoft关于“受保护用户组”的说明中推断明文凭证过早死亡（图16）。
图16. 明文凭证被快速移除的指示
不过，没有银弹。因此，请记住将用户添加到此组有副作用。
此建议也适用于LSASS凭证转储，因为它们不再被缓存。
https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
从IIS基本身份验证窃取凭证
关于通过使用Outlook on the Web从IIS基本身份验证窃取的凭证。它默认启用，并且是OWA/ECP工作所必需的（图17）。
图17. 默认安装上启用的IIS基本身份验证
免责声明：我不是Exchange管理员
显然，我不是Exchange管理员。但像许多事件响应者一样，我可以消费Microsoft文档。因此，我尝试禁用基本身份验证并启用其他类型的身份验证，但这破坏了功能。我没有花时间挖掘替代方法来确定我是否能使其工作。
然而，Microsoft对本地非混合环境的建议是将Outlook on the Web（OWA/ECP）从基本身份验证移动到带有ADFS的现代身份验证。这也将允许使用更强的身份验证功能，如启用MFA。
如果您这样做，请确保不要在ADFS中使用基本身份验证，因为这只会将问题转移到另一台服务器。
https://learn.microsoft.com/en-us/exchange/clients/outlook-on-the-web/ad-fs-claims-based-auth?view=exchserver-2019
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-2023-h1-cumulative-update-for-exchange-server/ba-p/3805213?WT.mc_id=M365-MVP-9501
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/enable-modern-auth-in-exchange-server-on-premises?view=exchserver-2019
带有红地毯的勒索软件
在第一次Exchange入侵八个月后，我们观察到与webshell的交互，随后在无人值守访问模式下安装了Anydesk，因此不需要用户批准（图18）。
图18. 设置了无人值守访问标志
从Exchange服务器，威胁行为者然后使用Nmap/Zenmap扫描网络和powershell，然后使用PowerView中的Invoker-ShareFinderThreaded枚举域中的共享。
图19. Powershell转录
请注意，这不是第一个使用这种技术的威胁行为者；它不仅广泛用于主机发现，还用于发现公司数据的位置。
威胁行为者然后检查谁登录到服务器，然后使用域管理员账户RDP进入（记住，他通过恶意NPPSPY dll成功窃取了明文密码并将其写在磁盘上）。对执行横向移动的主机的取证分析显示，威胁行为者识别了数据并通过手动打开一些文件检查了其中一些。恢复的环境不会向我们显示数据外泄是如何确切进行的，但防火墙日志确实显示了对属于mega.co域的IP的大量传出流量。
鉴于NPPSPY使用的第一个证据与NoEscape主动参与目标之间有很长的延迟（8个月），勒索软件操作者不太可能是迄今为止引用的利用尝试的幕后黑手。我们相信NoEscape从初始访问经纪人那里购买了明文密码和webshell位置的访问权限。
如果您对经济学感到好奇，请阅读https://www.kelacyber.com/the-secret-life-of-an-initial-access-broker/
图20. 攻击如何展开：恶意行为者、设置和执行
5-建议
在这个事件响应前线故事中，我们调查了一个勒索软件操作者，他能够快速有效地对受害者环境采取行动，但其特权访问是由更早的入侵促成的。
以下是一些简单的事情，您可以做以防止此事件链在您的组织中发生：
- 修补您的环境，尤其是针对关键漏洞
- 通过减少暴露的服务并将它们隐藏在VPN后面来减少攻击面
- 部署最先进的AV/EDR解决方案（在这种情况下，它们本可以帮助防止cve利用和加密）
- 投资安全事件日志记录和监控
- 监控远程访问工具的使用
点击此处下载完整案例研究，包括5条建议。