作为一名防守者，这总是让我感兴趣，因为我想知道一个局外人可以在不接触基础设施或与内部人员接触的情况下学到什么。现在，我最常希望利用此类数据来准备内部知识的集合，我可以将其用作社会工程的基础，或者一旦进入网络，就可以更好地了解我所在的网络。
有许多数据点需要考虑，但本文将重点关注网络目标（例如 IP 地址、域和系统），同时略微涉及收集人员信息（例如电子邮件地址、姓名、职位）。这是我在准备一个新项目时首先要寻找的东西，然后我使用收集到的数据来决定下一步要挖掘什么。
管理所有这些数据的关键是自动化。通过使初始研究阶段自动化，手动研究变得更加简单和容易组织。自动化和报告将在最后的“第 4 阶段”中讨论。让我们先从要寻找的内容开始。
第 1 阶段：映射网络
开始发现过程需要一个目标。虽然目标可能不容易在网上找到，但大多数组织都会有一个名称和至少一个用于电子邮件的“主”域，因此名称和域是一个很好的起点。入门所需的基本信息是名称（例如 Blizzard Entertainment, Inc.）和至少一个域（例如 blizzard.com）。
Full Contact 营销数据库和 API 是一个很好的起点。它可以根据名称和域提供有关组织的基本信息。Full Contact 跟踪“关键人物”（例如高管）、社交媒体资料、员工人数大致等。这些细节很好，必须为尚未收集的数据提供一些公司背景和背景。这也可以从公司的 LinkedIn 个人资料等来源收集。
域
收集到背景信息后，下一站是域和子域。可以使用反向 WHOIS 查找来发现其他域。WhoXY 是一项可靠的服务，它提供了一个反向 WHOIS API 端点，该端点接受公司名称和关键字来执行对 WHOIS 记录的搜索。这些搜索可以返回数百个额外的域。
whoxy.com
此时最好暂停并考虑这些新域。一些组织将购买其域名的变体，以避免域名抢注者的问题。这些域保持“停放”或只是将访问者转发到主域和公司网站。挑选结果并选择一些看起来很有趣的域以继续进行，然后继续下一步，子域发现。
请记住，如果某个人的姓名在域中，例如 Henry Dorsett，并且该姓名足够常见，则反向 WHOIS 查找可能会返回数百甚至数千个不相关的结果。因此，不要急于求成，盲目地包含每个反向 WHOIS 结果。
此外，WhoXY 搜索只返回完全匹配。如果查询查找与“Blizzard Entertainment Inc”关联的域，则结果将不包括与“Blizzard Entertainment, Inc”甚至“Blizzard Entertainment Inc.”关联的任何域。（末尾有句号）。好消息是公司倾向于在其域名注册记录中使用其名称的一种变体，因此如果从 WHOIS 记录中提取一个名称，则该名称是反向 WHOIS 搜索的安全选择。
子域
censys.io
有许多工具可以执行子域发现和暴力破解，例如 Aquatone 和 Sublist3r。暴力破解可以揭示可能从未发现过的子域，但是您必须与通配符 DNS 抗衡，并且在这些早期阶段没有必要。DNS Dumpster和Netcraft可能有大量用于目标域的编目子域。此外，从 crt.sh 或 censys.io 提取的 TLS 证书通常会显示这些服务尚未看到或记录的其他新子域。具体来说，可以从证书的备用名称中提取子域。
例如，搜索“blizzard.com”的 Censys 证书会返回具有以下名称的证书：
Censys.io 将从证书中解析名称，并将它们作为易于消化的列表提供，无论是在 Web UI 中还是通过 API。
证书往往会产生最多的子域，并且搜索它们的速度很快。但是，在 censys.io 上搜索诸如“blizzard.com”之类的域会产生一些不相关的结果，例如 iran-blizzard.com，即包含查询字符串的任何域。像这样的域可以与目标公司有关，但是更有可能的是，这些结果中的许多结果将是不相关的，只会污染数据集。
搜索“.blizzard.com”或使用正则表达式不适用于 Censys，但可以搜索特定字段。搜索parsed.names: blizzard.com会将结果限制为仅针对“blizzard.com”子域颁发的证书。
此外，证书透明度日志可能会提供更多可以使用 Google 透明度报告工具搜索的子域：
https://transparencyreport.google.com/https/certificates
DNS 记录和 IP 地址
这个大的域和子域列表需要解析为 IP 地址。这很容易通过 Python 套接字（或 Go、Ruby 等）和检查 DNS 记录来完成。由于某种原因，某些域无法解析，这很好。退休的子域和那些来来去去的子域（比如那些可能指向上升和下降的云资产的子域）仍然很有用，但稍后会详细介绍。
DNS 记录都有不同的用途。A 记录提供 IP 地址，其他记录提供一些有趣的情境信息。同样，这个 DNS 解析步骤很容易用 Python 和其他语言编写脚本。对于手动检查，dnsstuff.com可以方便地进行快速 DNS 记录和域所有权检查。
DNS 记录：MX 和 TXT
DMARC 和 SPF 记录（或缺少记录）将有助于确定电子邮件欺骗是否存在于任何社会工程活动的卡片中。许多组织者不设置 DMARC，而那些经常使用弱 SPF 记录和/或弱 DMARC 策略（例如p=none）的组织者。这最终意味着组织的电子邮件保护无法打开，并且不会采取任何措施来防止欺骗性电子邮件。本文很好地涵盖了这些电子邮件安全设置的一些陷阱。
几乎所有的邮件传输代理，包括 Gmail 和 Microsoft Exchange Server 使用的代理，默认都依赖 DMARC 来指导在电子邮件未通过 SPF 或 DKIM 时应采取的措施。如果发送域没有 DMARC 记录或策略为 none 的记录，则邮件服务器将无法打开并传递电子邮件。 这意味着如果一个域没有 SPF、DKIM 和严格的 DMARC 记录，它就可能被欺骗。 ——福克斯主教的亚历克斯·德弗里斯，上面的链接
DKIMValidator.com是用于分析 SPF 和 DKIM 记录的便捷实用程序。如果看起来可能存在电子邮件欺骗，则欺骗到 dkimvalidator.com 地址的电子邮件将显示 SpamAssassin 分数以及它是否通过了 SPF 检查。
作者注：这听起来可能是一件小事，但如果被误解，它可能是一个严重的问题。有一次，在与客户合作时，他们不得不应对令人讨厌的网络钓鱼事件。攻击者非常令人信服地将他们的电子邮件地址欺骗给员工和其他组织。这种对 DMARC 和 SPF 记录的简单检查帮助他们了解发生了什么。他们认为 SPF 和供应商提供的电子邮件安全解决方案在锁定时具有欺骗性，因此他们转向下一个合乎逻辑的假设，即帐户已被盗用。但是，他们从未设置过 DMARC 记录。对于许多组织来说，欺骗是一件非常困难的事情，因为电子邮件安全性经常被误解，营销、公关、自动警报电子邮件和其他合法使用欺骗性电子邮件的情况有很多例外。
此外，名称服务器可能容易受到 DNS 缓存窥探的攻击，而 MX 和 TXT 记录可能会泄露组织使用的服务（例如 Proofpoint、Survey Monkey）。这些都是老技巧，但仍然可以产生一些有趣的信息。
DNS 记录：CNAMES
这也是寻找 DNS 记录中提到的内容交付网络 (CDN) 和云服务的时候了。这些记录将显示域是否指向资产，例如用于 Web 托管的 S3 存储桶。此外，一些子域可能可用于域前端或容易受到该子域的接管（例如，已删除的 S3 存储桶的悬空 DNS 记录）。
如果这些是新想法，那么探索这些项目将作为读者的作业。这是一个很好的入门资源。此外，flAWS.cloud是学习检测和滥用许多常见 AWS 错误配置的绝佳资源，这些错误配置也可以转化为其他云服务（例如 Google、Azure）。
其他网络信息
最后，RDAP和Shodan可以填补为所有这些 IP 地址和域名收集的信息中的一些空白。
RDAP 可以为每个 IP 地址提供一些有用的信息，例如所有者和网络块。就其本身而言，知道一个 IP 地址属于亚马逊并不是那么有趣，但知道一个目标 65% 的 IP 地址归亚马逊所有，这表明他们充分利用了亚马逊网络服务。它也可能表明组织拥有哪些资产，哪些资产是租赁/外部托管的。这就是一些逻辑飞跃和推理可能开始发挥作用的地方。
shodan.io
最后但同样重要的是，Shodan 可能会提供更多关于 IP 地址和域名的详细信息。Shodan 可以提供主机名、操作系统、开放端口和服务横幅数据等信息，所有这些都无需触及任何基础设施。hostname:foo.barShodan 还可以使用已发现的网络块和域（例如和）的关键字搜索来显示其他主机和域名ip:1.1.1.0/24。
所有这些步骤都将创建大量信息，任何人都很难以理智的方式整理这些信息。此时最好将这些数据放在一边，直到报告阶段。
第 2 阶段：发现联系人
猎人.io
此阶段涉及目标组织的人员。现在可能已知一些其他域，搜索引擎（例如 Google、Yahoo、Bing）可用于搜索与组织用于其业务的每个域相关联的电子邮件地址。顾名思义，Email Hunter 的 API 也可用于查找域的电子邮件地址。它旨在供销售人员查找潜在客户的联系人和销售线索，但任何人都可以使用它并收集电子邮件地址。有时 Hunter 也有姓名、职位和电话号码。
超越电子邮件地址
电子邮件地址为网络钓鱼和密码喷洒提供了机会，但可以更进一步。通过根据 Troy Hunt 的 HaveIBeenPwned 等服务或安全漏洞和泄露密码的私人数据库检查电子邮件地址，员工可以与他们过去使用的服务进行匹配。
与迄今为止收集的大多数数据一样，这些数据本身并不是非常有趣。但是，它可以表明每个员工在公司工作了多长时间（假设他们此时还没有离开），甚至可以暗示他们在那里做什么以及组织内部使用的服务种类。当然，这也意味着他们的旧密码可能可用，并且可能会重新用于商业帐户。
此外，通过粘贴站点（例如 pastebin、ghostbin、slexy）寻找电子邮件地址可以产生一些特别多汁的信息。HaveIBeenPwned 还有一个粘贴 API，用于快速搜索链接到电子邮件地址的预索引粘贴。有些粘贴可能会导致死胡同，但并非总是如此，有时这些粘贴包含密码、安全问题的答案和其他信息。这是情报数据的福音，但也是一个直接的发现，并且在报告中绝对值得一提。如果已删除粘贴，则值得检查 Google 的网络缓存和 Wayback Machine 的缓存版本。
作者注：粘贴还可能显示电子邮件地址是未在 HaveIBeenPwned 等网站上列出的特别“敏感”违规的一部分，例如 Ashley Madison 违规。这很有趣，因为这意味着该电子邮件地址已被用于非公司业务和帐户，但报告密码来自此类违规行为是有问题的。在面向客户的可交付成果中盲目地平等对待所有粘贴之前，请使用良好的判断力。
社交媒体资料
在情报收集过程的这一点上，放松社交媒体通常是一个很好的计划。争吵可能是数十或数百个社交媒体资料对于早期侦察来说有点多。但是，在发现电子邮件地址的同时从 LinkedIn 和 Twitter 获取一些潜在客户并不难。这些可以使用许多与电子邮件地址相同的技巧从搜索引擎结果中抓取。
一些基本的谷歌搜索site:linkedin.com COMPANY将返回LinkedIn 个人资料，其中可能还包含电子邮件地址、职位和有趣的信息（例如“我管理公司对Cylance Protect 的部署”或“我是Splunk 管理员”）。这不是一门精确的科学，搜索会产生死胡同（即返回的个人资料是针对其他已离开公司但在工作历史中提及的人），但它可以帮助您收集一些姓名和信息以帮助您入门。此外，Email Hunter 将返回 LinkedIn 个人资料链接，如果它知道的话，应该是预先验证的。
Twitter 句柄也可以成为重要的情报来源，Twitter API 可以帮助验证配置文件。就像 LinkedIn 个人资料和电子邮件地址一样，这些句柄将在搜索 twitter.com 时返回。
首先收集一些潜在的 Twitter 句柄，然后使用 Twitter API 验证个人资料是否仍然存在并收集关注者数量、位置、传记和真实姓名等信息。虽然这些数据中的大部分是由用户提供的，并且可能会丢失、不完整或不真实，但它确实可以很容易地快速浏览名称和传记，以寻找任何看起来有希望作为以后更认真狩猎的良好起点的东西。假设这会返回少数合法账户，一些基本的链接分析可能会在以后揭示更多账户。
社交媒体注意事项
社交媒体最好留到以后的一个原因是它需要一些思考和仔细分析。在搜索真人时，假设他们有在线存在，确定某人是谁以及他们的兴趣是什么并不难。虽然并非总是如此，但他们的真实自我经常反映在社交媒体上。
然而，研究可能会产生一个更像公众或专业角色的实体，或者可能是一个完全捏造的身份。社交媒体资料不反映帐户背后的一个或多个人，因此不能从表面上看待这些信息。
CEO 可能在 Twitter 和 LinkedIn 上有一个高度策划的角色，这使得很难了解更多关于头衔和个人资料背后的人。人工分析可能会导致 CEO 的私人助理在 Twitter 或 Facebook 上拥有更“诚实”的公众形象。
有时删除一两个步骤比更高价值的目标更好。它们更容易被访问，不太可能被仔细监控，并且可以更方便地访问高价值目标。
第 3 阶段：云
到目前为止，大多数低悬的 OSINT 果实已经被采摘，但还有一些更基本的搜索来完善可用数据。
挖掘文件
许多公司网站在其域下都有大量文件。这些文件可能是多年积累的，包括从 Office 文档到 PDF 和其他杂项文件的所有内容。基本的谷歌搜索，就像site:company.com filetype:pdf会揭示它们。这些文档可以自动下载并分析元数据，其中可能包括软件信息（例如 Office 2013）或用户名。
如果有人对网站的 Web 根目录不小心，那么其他文件扩展名（例如 .key 或 .cert 更敏感文件）的命中并非闻所未闻。也有可能有人上传了面向少数受众的文档，而没有意识到任何人都可以下载它们。如果搜索引擎将它们编入索引，则可以找到它们。
寻找水桶
说到不适合互联网的文档，Amazon S3 存储桶因此而臭名昭著。猎桶现在很热门，但不要忽视Digital Ocean 的“Spaces”。Digital Ocean 推出了自己的类似于 S3 的服务，并将其称为 Spaces。方便的是，Digital Ocean 在设计新服务时遵循了行业标准 S3 存储桶。换句话说，空间的运作方式与水桶完全一样，如果将水桶指向数字海洋，则用于狩猎的工具将适用于空间。
可以通过 Web 请求检查存储桶的存在。向 Amazon 或 Digital Ocean 发出 Web 请求（例如https://fubar.s3.amazonaws.com / 或https://fubar.nyc3.digitaloceanspaces.com/），服务返回一些 XML 指示存储桶是否存在. 如果存在，XML 将指示是否有任何数据可公开访问。这就是它的总和。寻找这些只是使用词表创建新的网络请求的问题。
注意： Web 请求适用于空间，但可能会丢失一些 S3 存储桶。最好使用 Amazon 的awscli或 boto/boto3 Python 库（使用 awscli）来检查存储桶。这些工具使用亚马逊账户进行身份验证，一些存储桶可能会拒绝来自浏览器的匿名访问，同时允许“经过身份验证的用户”查看他们的一些内容。
由于目标是针对特定组织，因此词表应与公司相关。至少，尝试包括公司名称、他们使用的任何首字母缩略词或缩写、他们可能拥有的备用名称、子公司以及他们在纳斯达克上市（如果他们有的话）。
如果公司使用与其业务相关的其他术语，则可以并且应该扩展该词表。例如，暴雪娱乐以用数字命名团队而闻名（例如，Team 1、Team 2、Team 3）。每个数字都与他们的一场比赛相关联。他们还喜欢使用经常从他们的魔兽争霸和星际争霸传说中提取的代号。如果目标是 Blizzard，那么将 team1、team2、arthas、townportal 和其他与 Blizzard 相关的术语添加到列表中是有意义的。
检测到核发射：改进单词表以更好地定位和增加找到有趣事物的机会。
存储桶名称必须是全局唯一的，因此最好使用关键字的不同变体。一种简单的选择是使用各种前缀和后缀，或“修复”。一些常见的修复是 qa、doc、legacy、uat 和 bak。这些可以添加到关键字的开头和结尾，以检查存储桶名称的常见变体。例如，“tychus”和一些修复结合起来创建了几个新的关键字，如“qa-tychus”和“tychuslegacy”。
值得注意的是，存储桶名称除了连字符之外还可以包含句点，因此即使“blizzard.com”也是有效的存储桶名称。事实上，托管在 S3 存储桶中的资源或网页的存储桶名称会解析为 hearthstone.blizzard.com.s3.amazonaws.com 之类的名称。
此外，一些公司可能会在存储桶名称中添加垃圾以使其更难被发现，例如 tychus-79a9ba8b089e4c022c32b964cacf6b13f2aa6d9a（tychus 的 shasum）。它们不是不可发现的，但如果对目标进行更密集的斗式搜索，它们肯定会更加困难，并且需要稍后考虑。
这种词汇表方法旨在捕捉可能导致某些信息泄露的低悬的果实。为了提供可以找到的示例，此过程曾经确定组织开发人员使用的“内部” git 存储库。桶里装满了密码、公司源代码和其他敏感信息。它之所以公开，是因为该公司错误地让“任何经过身份验证的 AWS 用户”可以访问它，认为这意味着他们经过身份验证的 AWS 用户，而不是任何 AWS 用户。亚马逊已经改进了 Web 控制台 UI 以添加警告并使其更难犯此错误，但它仍然会发生。
准备好单词表和修复列表后，将它们粉碎在一起并开始搜索。
第 4 阶段：报告和自动化流程
对于每个项目，手动完成所有这些都是非常乏味的。如果您是一名防御者或漏洞赏金猎人，希望执行持续的资产发现，那么这真的不是您想要重复或使用单个工具做的事情。这就是为什么许多人已经解决了所有这一切的自动化问题。一些值得注意的工具是 Recon-ng 和 Discover Scripts。我在一个名为 ODIN 的工具中尝试了将上面列出的所有内容自动化：
重新发明轮子？
我有一个当时可用的工具无法满足的需求。我不想/不想运行多个模块来获取所有数据或依赖正在安装的外部工具。我对 ODIN 的目标是，并且仍然是，创建一个可以在 Windows、MacOS 或 Linux 上仅使用 Python 3 运行的工具。不仅如此，我希望该工具能够自动进行基本分析，即通过以下方式连接一些点做一些事情，比如检查 DNS 记录中的某些字符串。ODIN 实现了这一点，使分析师能够对数据做更多的事情，同时要求他们做更少的工作来获取数据。
ODIN 的报告和组织
ODIN 将其收集的所有数据存储在 SQLite3 数据库中，以供以后分析。或者，根据这些数据构建多页 HTML 报告，使浏览信息就像在 Web 浏览器中打开报告一样简单。这对于随意的评论和参考很有用，但是使用这些数据来可视化外部周边可能会让人大开眼界。
进入 Neo4j
为绘制在此 OSINT 收集过程中发现的所有各种实体和资产之间的关系而开发的基本模式。
我为收集上述数据时可能遇到的外部资产开发了一个简单的 Neo4j 图形数据库模式。一旦 ODIN 将 SQLite3 数据库转换为图形数据库，就可以创建外部边界的地图。这是一个非常 基本的例子：
从一个根域分支出来的小型网络图。
大多数节点类型都在此图中表示。本例中 ODIN 是在小型实验室环境中运行的，因此 IP 地址是内部地址，没有任何 Shodan 数据（即开放端口）。
您有一个与域（紫色）和该域的子域（绿色）相关联的组织（蓝色）。证书（红色）及其与域和子域的关系显示了哪些节点共享证书。您还可以查看子域解析的 IP 地址（黄色）。
包含多对一关系、众多 IP 地址和多个域的大型组织的完整、未经过滤的图表可能非常密集。
附加分析
这些图表非常适合进行可视化分析和挑选有趣的资产，但不仅仅是图表。Cypher 查询使获取统计信息和创建表变得快速和容易。例如：
MATCH (p:Port) RETURN DISTINCT p.Organization
上述查询匹配来自 Shodan 的开放端口并返回组织列表。换句话说，它制作了一个表格，显示数据库中的组织，例如 Cloudflare 或 Amazon.com。这是了解组织使用的网络提供商的快速方法。
此查询将映射网络，同时排除从未解析为 IP 地址的子域：
代码语言：javascript复制MATCH (org:Organization)-[r1:OWNS]->(dom:Domain)-[:RESOLVES_TO]->(add:IP)
MATCH (sub:Subdomain)-[r2:SUBDOMAIN_OF|:RESOLVES_TO]->(n )
MATCH (add)-[r3:HAS_PORT]->(p:Port)
RETURN org,dom,sub,add,p,n,r1,r2,r3此查询首先仅匹配具有 :OWNS 和 :RESOLVES_TO 关系的组织、域和 IP 节点。然后它将与任何节点具有 :SUBDOMAIN_OF 或 :RESOLVES_TO 关系的子域匹配。最后，它将任何具有 :HAS_PORT 关系的 Port 节点与匹配的 IP 节点之一匹配。
结论
上面详述的过程并没有接近收集人们可能收集到的关于组织的每一条信息。一旦您开始与非常大的组织或其中包含不同组的组织打交道，情报收集就会变得复杂。但是，您必须从某个地方开始，而这个过程对我很有帮助。
收集到的数据对攻击者有价值，我认为仅此一点就对防御者有价值。预先警告是预先准备好的，即知道可用数据向外部人员暗示或直接告诉有关您的组织的信息可以极大地告知内部安全意识计划并帮助识别薄弱环节。至少，这个过程帮助我识别了一个组织认为已退役、与互联网隔离或关闭的资产。在成为问题之前抓住潜在的弱点（例如被遗忘的服务器）可能是一场轻松的胜利。
当然，OSINT 是一个有机过程，通常会在此处详述的基本阶段之外继续进行。例如，在 GitHub 上搜索主机名、密码和机密信息通常是值得的。这些步骤值得他们自己发帖。目前，此处概述的流程将有助于揭示有关组织的更多信息、发现资产，并帮助指导未来和整个运营过程中的工作。
通过使用 ODIN 自动执行此过程，您可以在短短 10 分钟左右的时间内将名称和域转换为更多内容。ODIN 与多处理并行运行多个任务，因此根本不需要很长时间。如果它的功能引起了您的兴趣，请尝试一下。该项目是开源的，可以接受反馈。我鼓励防御者利用 ODIN 或其他工具/手动分析来可视化其外部网络以监控其资产并密切关注有关其组织和员工的公共数据。
