OSINT for Incident Response (Part 1)
| Patterson Cake
作为数字取证和事件响应顾问，工作核心往往是解决未解之谜。当与客户接触时，他们知道坏事已经或正在发生，但对“如何、何时、何地以及为何”却不确定。我们工作的关键部分是梳理出“已知的已知”、“已知的未知”，并高效帮助客户回答以下问题：
- 我们是否已被入侵？
- 如果是，那么：
- 被入侵多久了？（“驻留时间”）
- 哪些账户和系统受到影响？
- 入侵方法是什么？（“零号病人”）
- 哪些数据被访问和/或外泄？
在最近的几个案例中，开源情报（OSINT）在帮助回答这些问题方面发挥了关键作用。
入侵通常源于某些变化，从配置错误到零日漏洞利用，再到最终用户行为，而攻击途径最常见的是互联网。OSINT可以快速、轻松地让我们了解互联网对客户组织的了解。如果互联网知道，威胁行为者就知道，而作为事件响应者，我们需要知道！
作为DFIR顾问，参与从客户接触开始。仅基于初步接触，我们就有一些关键数据点：组织名称、其电子邮件域以及开始的时间线。如果有几分钟的预警，我甚至会在加入首次客户通话之前进行OSINT。以下故事较少涉及技术“如何操作”或特定工具/门户，更多的是说明无论您是顾问还是内部资源，OSINT对于IR都是有价值的，应成为您调查过程的一部分。
案例 #1：“从误配置到勒索软件的3天”
像往常一样，电话在周五下午晚些时候打来。所有网络连接的打印机喷出勒索软件通知，这充分表明我的周末计划泡汤了，但我有点跑题了！基于与客户的首次接触，我知道他们的主要TLD（顶级域），并立即开始我的“5分钟OSINT”例行程序。首先（请鼓声响起！），我的电子邮件枚举秘密武器：“名称服务器查找”（ba-dum-bum-ching！）。是的，老好的“nslookup”。我只想枚举他们的邮件服务器。超级快速和简单，从Linux或Windows，指定“MX”（邮件交换器）记录类型和一个可靠的公共DNS源（下例中的Google DNS），然后敲“Enter！”（从头到尾大约15秒）：
|
|
nslookup命令示例
大约98%的时间（我编造了这个统计数字），我会看到类似companydomainname-com.protection.outlook.com的内容，表明他们使用M365处理电子邮件。通常，我想快速排除他们自托管电子邮件的情况，或者准备与客户讨论对其M365/Azure环境的潜在影响（如果指示）。在这个特定的参与中，客户似乎有本地Microsoft Exchange。从“攻击面”的角度来看，这绝对值得注意！超级有价值？对于投入的<15秒，值得快速检查，我获得了一个潜在有价值的线索！
如果我知道客户参与是商业电子邮件泄露（BEC）案例，我可能就此打住。如果不是，我会撒一张更广的网，使用他们的顶级域（TLD）查找使用的IP地址/范围，转向互联网“攻击面”搜索引擎。我喜欢DNS Dumpster进行下一步，因为它快速、易用且易于解释。我最感兴趣的是“ISP分配”的IP块，例如“COMCAST-1234”或“LOCALISP-AS-01”，而不是CLOUDFLARENET、MICROSOFT-CORP等。不是我会忽略后者，但自托管/本地基础设施似乎是更可能的魔鬼游乐场。当然，我会对我学到的一切做大量笔记、截图等，以供将来参考（剧透警报…这对本案很重要！）：https://dnsdumpster.com
DNS Dumpster中感兴趣的IP块
如果DNS Dumpster返回一长串IP块，可以从其TXT记录的SPF部分列出的IP中获取提示开始。如果您跟着玩，您可能还注意到MX记录列在这里，以防您将来想跳过使用“nslookup”直接跳到DNS Dumpster！
接下来，我在本地ISP的上下文中浏览了主机（A）记录，寻找突出项，例如“exchange.companydomainname.com”或“remote.companydomainname.com”。在没有一两个突出条目的情况下，我尝试了客户使用的地址范围，例如“10.1.0.128/25”或“10.1.0.129-140”（这是一个私有地址范围，我在这里只是用作示例），然后前往Shodan.io。
如果您没有Shodan.io账户，那么您不能使用搜索过滤器，这带来了一些挑战。但您仍然可以搜索IP或TLD。最坏的情况，您可以通过替代方案过滤，然后重新访问Shodan.io与感兴趣的IP（见以下选项）：https://shodan.io
Shodan.io IP范围搜索示例
我使用了如上所述的范围，或者您可以使用“net:10.1.0.128/25”过滤器。从那里，我查看了“TOP PORTS”寻找突出项。常见端口如80和443并不令人兴奋，只是记入我的笔记。我更感兴趣的是不寻常的端口或远程访问端口，如445、3389或22。在这种情况下，我看到两个值得注意的：3389（远程桌面协议）和一个看起来像非标准Web服务端口。接下来，我点击端口“3389”查看相关IP地址，然后点击一个IP获取详细信息。检查并记录“最后看到”的日期很重要。大量笔记和截图是您的朋友！
“开放端口”3389截图，包括最后看到日期
“开放端口”3389截图，包括最后看到日期
旁注… Shodan.io当然不是唯一的“攻击面”搜索引擎选项。即使它是您的首选，我强烈建议拥有多个解决方案（见案例研究#2）。Censys和LeakIX是几个选项，两者都提供无需注册的搜索能力，并在免费注册后提供更多功能：
Censys.io示例：https://search.censys.io – ‘ip: [10.1.0.129 to 10.1.0.140]’ 或 ‘ip: 10.1.0.128/25’
Censys上的IP范围搜索示例
LeakIX.net示例：https://leakix.net “Service” – ip:”10.1.0.128/25”
Leakix上的IP子网搜索示例
记住，这不是深度分析。阅读这篇文章应该比执行实际查询花的时间更长！我只是做一个快速的“攻击面”直觉检查。有什么 glaring 吗？有什么可能告知进一步调查的吗？记录一切以供将来参考！
凭借一些OSINT视角，我们启动了客户参与，并最初专注于遏制和根除。事件发生几天后，在进行一些事件日志分析时，我注意到大量来自公共IP源的“4625”事件（表示登录失败）。据客户称，这应该是不可能的，因为他们没有公开可访问的身份验证门户。此外，日期/时间与我们已知的当前事件不符。令人困惑，直到我重新访问我的OSINT笔记，其中指出“远程桌面”在至少一个与客户组织相关的公共IP地址上对互联网开放。在与客户网络工程师快速检查公共IP到私有IP防火墙映射后，我们有了一个特定的主机进行调查。我们进行了分类收集，注意到凌晨3:00从未经授权的账户安装了远程访问软件，从那里展开时间线，找到了“零号病人”（初始入侵点）。
事实证明，几天前，客户更换了主要防火墙（记住“某些东西改变了”公理），迁移并修改了先前的配置。旧配置允许单个非标准端口从互联网入站到Web应用程序（记住我们之前的Shodan.io观察）。在转换到新防火墙的过程中，那个单个入站端口“允许”变成了1:1 NAT（网络地址转换）映射，允许所有端口入站，包括“远程桌面”（如我们通过Shodan.io注意到的）和“SMB”到Web应用程序服务器。不幸的是，这些更改是由第三方进行的，客户对意外的暴露感到不满。他们非常感兴趣我们如何发现“零号病人”，特别是“互联网”意识到此误配置的日期和时间。幸运的是，我抓取了我的Shodan.io探索的截图，这从外部验证的角度有所帮助，显示了“首次看到”和“最后看到”的暴露。正如您可能想象的，这在客户与供应商关于此事件的因果关系和责任的讨论中起到了关键作用！
找到“零号病人”可能极具挑战性，尤其是在大型分布式企业中，但它对于告知IR的修复和恢复阶段至关重要。在这种情况下，如果有足够的时间，我们最终会发现“零号病人”，但“5分钟OSINT”例行程序显著缩短了发现时间，并为客户提供了误配置时间线的宝贵背景。
案例 #2：“元数据与新式银行抢劫”
在“OSINT for IR”的下一部分中，我们将深入挖掘并解开针对金融机构的有针对性攻击。感谢阅读！
享受阅读吗？ 然后查看Patterson当天发布的网络研讨会！ 使用Velociraptor和KAPE进行快速Windows端点调查与Patterson