OSINT for Incident Response (Part 1)
| Patterson Cake
作为数字取证和事件响应顾问，工作核心就是解决未解之谜。当与客户接触时，他们知道发生了坏事或正在发生，但不清楚"如何、何时、何地以及为什么"。我们工作的一个重要部分是梳理出"已知的已知"、“已知的未知”，并有效帮助客户回答以下问题：
我们是否已被入侵？ 如果是，那么：
- 我们被入侵多久了？（“驻留时间”）
- 哪些账户和系统受到影响？
- 入侵方法是什么？（“零号病人”）
- 哪些数据被访问和/或外泄？
在最近的几个案例中，开源情报（OSINT）在帮助回答这些问题方面发挥了关键作用。
入侵通常是因为某些变化而发生的，从错误配置到零日漏洞利用，再到最终用户行为，而攻击途径最常见的是互联网。OSINT可以快速、轻松地让我们了解互联网对客户组织的了解。如果互联网知道，威胁行为者就知道，作为事件响应者，我们需要知道！
作为DFIR顾问，参与从客户联系开始。仅基于初步联系，我们就获得了一些关键数据点：组织名称、其电子邮件域以及开始的时间线。在接到通知几分钟后，我甚至在加入首次客户通话之前就会进行OSINT。以下故事较少涉及技术"如何操作"或特定工具/门户，更多的是说明无论您是顾问还是内部资源，用于IR的OSINT都是有价值的，应该成为您调查过程的一部分。
案例#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子网搜索示例
记住，这不是深入分析。阅读这篇文章应该比执行实际查询花费更长时间！我只是做一个快速的"攻击面"直觉检查。有什么明显的吗？有什么可能为进一步调查提供信息的吗？记录一切以供将来参考！
凭借一些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