事件响应实战：从Zimbra漏洞到横向移动的完整攻击链分析
引言
在本系列中，我们将介绍Kudelski安全事件响应团队（KSIR）处理的近期事件响应案例。这不是深入的技术分析，而是分享特定事件中的具体建议，帮助您提高网络入侵事件的应对准备。
Watson，我们遇到问题了
客户怀疑其DMZ区域的Zimbra webmail服务器"看起来不太对劲"近一个月后联系了KSIR。快速检查发现：
- Zimbra web文件夹确实包含Webshell后门；客户已删除他们容易发现的部分
- 客户虽然部署了EDR解决方案，但不幸未部署在Linux服务器群中
- Web服务器日志已被轮换，客户未保留副本（无SIEM或集中日志记录）
我们的第一个行动是在Linux服务器上部署EDR代理。这将为我们提供可见性，并能够在攻击者仍在网络中或设置了任何超级高级持久性机制时准备响应。
警报#1：我的Webshell在哪里？
两天后，在部署代理时，威胁行为者确实返回了，我们在Zimbra服务器上收到了警报。在整个调查过程中，威胁行为者似乎按计划工作：UTC+1时间午夜至凌晨5点的工作时间内，每4-5天一次。
虽然我们怀疑暴露的互联网资产是攻击者的入口点，但通过将证据按时间线拼接，我们能够证明这一点。在搜索Webshell后，攻击者在部署的Java页面/opt/zimbra/jetty_base/webapps/zimbra/public/jsp/Startup3.jsp上收到状态代码"200"（见图1），并通过执行一些枚举命令开始与之交互（见图2 - 查看谁登录以及他们在做什么）。
威胁行为者后来检查其他Webshell是否仍然存在。这为我们提供了攻击者存储后门位置的线索。前两个命令（见图3）甚至显示了攻击者如何使用不同的base64编码库进行混淆。
找到目标后，威胁行为者篡改了文件的时间戳元数据以更有效地隐藏它们，使它们看起来像是在之前的时间点存在，如果管理员查找最近的修改，这些文件将不会被注意到（图4）。
对主机的进一步自定义取证揭示了其他Webshell：
/opt/zimbra/jetty_base/webapps/zimbra/public/jsp/Zimbre.jsp
由于Web服务器日志回溯时间不够长，证明哪个CVE被利用以在Zimbra Web服务器上获得立足点并不简单。然而，对产品漏洞的快速搜索显示了不同的Zimbra RCE漏洞如何在野外被积极利用，特别是当时确认已过时的服务器版本。详情参见：https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-228a。
警报#2：权限提升利用
大约在我们收到Zimbra Web服务器的EDR警报时，我们从内部Web服务器收到了另一个警报，表明受感染的用户正尝试下载以下内容：
|
|
这是针对Linux发行版上本地权限提升的CVE-2021-4034的自包含漏洞利用。我们确认客户的基础设施存在漏洞。
为了确定横向移动的范围，我们开始在本地Web服务器上使用狙击取证提取工件，因为EDR技术仅在部署后有效，对调查过去的活动无用。
在收到两个警报后，我们转向遏制。 在此阶段，我们从两个警报中获得了关于攻击者的可靠信息：时间范围、用户名和利用习惯。由于攻击者在启动ssh会话时利用CVE-2021-4034，一种狩猎此行为的方法是在auth.log（secure.log）文件中查找以下行（图5）。这与使用该工具包的漏洞利用正相关。
这个迭代过程使我们发现威胁行为者来自承包商VNC网关，并利用凭据（我们后来发现已被泄露）尝试登录尽可能多的主机，成功进入其他6台主机。 此外，取证分析显示后门二进制文件被投放到两台服务器上。 该后门被许多AV引擎成功检测到，并被标记为trojan.linux/rekoobe（图6）。
文件的静态分析显示硬编码的C2 IP：94.158.247.102，连接将在端口443上建立（图7）。
连接孤岛：攻击者如何从Zimbra移动到VNC网关？
虽然理论上可能有两个不同的威胁行为者在同一环境中，但我们想了解攻击者如何从邮件服务器移动到其他主机。 我们确认了假设：受感染用户的明文密码通过电子邮件发送，并以明文形式存储在Zimbra webmail服务器上。本质上，客户需要假设攻击者可以访问电子邮件中驻留的其他敏感数据。
随着调查的继续，我们能够确定该帐户属于承包公司的一名前雇员，该雇员未正确离职。 其帐户的最新活动发生在事件的时间线内。这使我们能够自信地建立Zimbra作为patient-0与承包商的VNC网关作为横向移动杀伤链中第一台主机之间的联系。
最小化中断并支持修复
那么，退一步说，这是我们目前的情况： 我们了解到Web服务器存在关键CVE漏洞，其中一个很可能被利用。虽然推荐的修复方法是通过更新应用程序来修补，但客户方面没有足够的带宽执行此类操作。此外，业务中断是不可容忍的，因此隔离主机是不可能的。
因此，在清理任何已识别的持久性后，我们建议临时缓解措施，使客户能够保持服务运行。建议如下：
- 使Zimbra应用程序的源文件夹不可变，理由是任何成功的利用都需要在调用之前在磁盘上投放文件（Webshell）。如果我们仔细禁止在应用程序文件夹中写入，那么任何已记录的CVE的利用都将失败
- 如果当时Web服务器上运行着未识别的后门，阻止服务器发起的任何传出连接（更新服务器和其他必要适用的主机以排除）
我们还明确表示——如果发生意外情况——我们的托管检测和响应以及IR服务随时可用，24/7帮助他们摆脱困境。 值得指出的是，客户感谢我们围绕他们的业务需求进行调查。我们的方法从不千篇一律。在构建响应之前，我们总是考虑他们的实际限制和操作要求。
受感染的备份根本不是备份
受感染的Zimbra服务器被遏制并保留用于调查，而客户则致力于启动新映像。不幸的是，新服务器是从受感染的快照生成的，这使攻击者能够找到隐藏的Webshell后门。这次攻击者直接删除了所有用户帐户。我们相信破坏行为是由于操作暴露而加速的。
幸运的是，客户有最近的备份。用户的中断很小（停机时间少于1小时），登录仅在恢复前暂时被阻止。
MITRE映射
除了常见的战术、技术和程序外，相关违规还包括更具体的部分：
- 在DMZ Web服务器上获得初始立足点（Mitre：T1190）
- 使用不安全凭据进行横向移动（Mitre：T1552.001）
- 利用第三方信任（Mitre：T1199）
- 利用权限提升（T1068）
- Web Shell后门（T1505.003）
- 使用SSH进行横向移动 T1021.004
- 时间戳篡改 T1070.006
经验教训
- 保存调查中的任何证据。您以后可能需要专家意见。
- 一致部署安全解决方案并根据最佳实践进行配置。这样，您将避免产生错误的安全感。
- 没有日志，在违规后回答问题很困难。考虑制作日志的原始副本并将其保存在安全的地方。
- 如果您进行备份，可以避免业务中断。确保频繁备份关键服务。
- 强化提供非常高的投资回报率，当与EDR结合时，安全性会提高几个数量级。考虑在关键资产上实施基本强化配置，尤其是暴露的资产。
- 在事件期间至少利用了两个CVE（来自互联网和本地网络）。保持应用程序和基础设施更新。
- 确保正确离职员工，无论是您的还是合作伙伴的。
- 安全性取决于最薄弱的环节：在这个特定案例中，承包商的薄弱安全卫生（不当离职+缺乏MFA）使攻击者能够深入客户的基础设施。
[点击此处下载完整案例研究，包括8个关键要点。]