企业官网建设流程全解析

BBOT 内部模块（Internal Modules）完全指南：常驻扫描引擎的 speculate、excavate、dnsresolve 与 cloudcheck

【免费下载链接】bbotThe recursive internet scanner for hackers. 🧡项目地址: https://gitcode.com/GitHub_Trending/bb/bbot

导读

BBOT（递归互联网扫描器）中的**内部模块（Internal Modules）**是一组默认常驻运行、无需显式启用的核心功能模块，负责 DNS 解析、被动数据挖掘、云厂商标记与数据推断等基础工作。本文基于 docs/modules/internal_modules.md 展开，结合源码逐一剖析aggregate、cloudcheck、dnsresolve、excavate、speculate等模块的职责、配置开关与底层实现，帮助读者掌握如何按需禁用、调优这些模块，并理解 BBOT 扫描管线中"数据如何被推断、挖掘与流转"的关键机制。

什么是内部模块？

内部模块（Internal Modules）与普通模块（Scan Modules）行为类似，区别在于：

• 始终运行：它们不需要显式启用，每次扫描都会默认加载；
• 可显式禁用：如果某些功能不需要，可以通过根级配置将其关闭。

在 bbot/modules/internal/base.py 中，所有内部模块继承自BaseInternalModule，其核心属性为：

class BaseInternalModule(BaseModule): in_scope_only = False _type = "internal" # Priority, 1-5, lower numbers == higher priority _priority = 3

其中_type = "internal"是内部模块的标志，扫描器在加载时会据此将其与普通模块区分。从 bbot/scanner/scanner.py 的加载逻辑可以看到，内部模块与普通模块分开加载并统计：

internal_modules = sorted([m for m in self.preset.internal_modules if m in succeeded]) self.verbose(f"Loading {len(internal_modules):,} internal modules: {','.join(internal_modules)}") loaded_internal_modules, failed_internal = self._load_modules(internal_modules) self.modules.update(loaded_internal_modules)

这些模块承载着典型 BBOT 扫描中"必不可少"的核心功能，例如 DNS 解析、被动信息挖掘、事件推断等。禁用的方式非常简单——在根级配置中把对应选项设为False即可（详见 bbot/defaults.yml）：

# Infer certain events from others, e.g. IPs from IP ranges, DNS_NAMEs from URLs, etc. speculate: True # Passively search event data for URLs, hostnames, emails, etc. excavate: True # Summarize activity at the end of a scan aggregate: True # DNS resolution dnsresolve: True # Cloud provider tagging cloudcheck: True

注意：以上配置键是**根级（root-level）**选项，直接写在配置文件顶层即可生效，无需嵌套在modules:之下。

从源码结构看，内部模块目录 bbot/modules/internal/ 目前包含 7 个模块文件：aggregate.py、base.py、cloudcheck.py、dnsresolve.py、excavate.py、speculate.py和unarchive.py。下面逐一介绍各模块的功能。

aggregate：扫描结束时的统计汇总

aggregate模块的功能是在扫描结束时汇总统计数据，也就是打印一张扫描统计表。如果你不希望看到这张表，可以禁用aggregate: False。

其实现位于 bbot/modules/internal/aggregate.py，它继承了BaseReportModule（报告类模块），核心逻辑非常简洁：

class aggregate(BaseReportModule): watched_events = [] flags = ["passive", "safe"] meta = { "description": "Summarize statistics at the end of a scan", "created_date": "2022-07-25", "author": "@TheTechromancer", } async def report(self): self.log_table(*self.scan.stats._make_table(), table_name="scan-stats")

可以看到，它把scan.stats中收集的统计信息（事件数量、各模块产出等）格式化为一组表格行，并以scan-stats为表名输出。由于它不监听任何事件（watched_events = []），只在扫描收尾阶段执行一次report()，因此不会对扫描过程产生任何干扰。

cloudcheck：云厂商标记与云资源识别

文档中称之为cloud模块，在配置中对应键为cloudcheck。它的职责有两方面：

1. 云厂商标记：检查事件关联的主机/IP 是否属于某个云厂商（如 AWS、Azure、GCP 等），并据此为事件打上对应标签；
2. 云资源识别：识别某些特定云资源，例如存储桶（Storage Bucket）。

实现位于 bbot/modules/internal/cloudcheck.py，CloudCheck继承自BaseInterceptModule，监听所有事件（watched_events = ["*"]），并设置scope_distance_modifier = 2，即可对距离目标最多 2 跳的事件进行标记：

class CloudCheck(BaseInterceptModule): watched_events = ["*"] meta = { "description": "Tag events by cloud provider, identify cloud resources like storage buckets", "created_date": "2024-07-07", "author": "@TheTechromancer", } # tag events up to and including distance-2 scope_distance_modifier = 2 _priority = 3 async def setup(self): self._cloud_hostname_regexes = None self._cloud_hostname_regexes_lock = asyncio.Lock() # perform a test lookup during setup to force signature update await self.helpers.cloudcheck.lookup("8.8.8.8") return True

setup()阶段会主动做一次cloudcheck.lookup("8.8.8.8")测试查询，以强制更新云端签名（该能力封装在 bbot/core/helpers/helper.py 的helpers.cloudcheck中，底层依赖cloudcheckPython 库）。

在handle_event中，它会对事件的原始主机及所有已解析主机（resolved_hosts）逐个执行helpers.cloudcheck.lookup(host)，然后根据返回的 provider 信息为事件添加标签：

• 通用标签：tag与{tag}-{provider_name}；
• IP 主机：额外打上{provider_name}-ip；
• 域名主机：原始主机打上{provider_name}-domain，其余解析出的子主机（通常为 CNAME 链上的节点）打上{provider_name}-cname。

对于距离在max_scope_distance以内的事件，它还会用云厂商提供的STORAGE_BUCKET_HOSTNAME正则逐一匹配主机名，一旦命中（例如bucket-name.s3.amazonaws.com），就会从中提取存储桶名与域名，合成 URL 并发射STORAGE_BUCKET事件：

bucket_name, bucket_domain = match.groups() bucket_url = f"https://{bucket_name}.{bucket_domain}" await self.emit_event( { "name": bucket_name, "url": bucket_url, "context": f"{{module}} analyzed {event.type} and found {{event.type}}: {bucket_url}", }, "STORAGE_BUCKET", parent=event, )

这些云资源正则通过cloud_hostname_regexes()从cloudcheck库的providers中动态收集并编译缓存，便于后续其他模块（如 bucket 枚举类模块）消费。

dnsresolve：DNS 解析与通配符检测

文档中称之为dns模块，配置键为dnsresolve。它控制 BBOT 执行的基础 DNS 解析行为，以及通配符检测等配套机制。它是内部模块中优先级最高的模块之一（_priority = 1），实现位于 bbot/modules/internal/dnsresolve.py。

核心职责

DNSResolve监听所有事件（watched_events = ["*"]），产出DNS_NAME、IP_ADDRESS、RAW_DNS_RECORD事件。其工作流程大致为：

1. 找到或创建 DNS 父事件：通过get_dns_parent()在事件祖先链中寻找同主机的IP_ADDRESS/DNS_NAME事件，找不到则新建；
2. 最小化解析：先解析A/AAAA（IP 事件则为PTR）记录用于范围判断，检查解析结果是否命中白名单/黑名单；
3. 完整解析：对于在dns_search_distance范围内的事件，解析其余所有记录类型（TXT、MX、NS、CNAME、SOA等）；
4. 通配符检测：对新建事件调用handle_wildcard_event()，通过helpers.is_wildcard()进行通配符验证；
5. 发射 DNS 子事件：将各记录类型中提取的主机作为DNS_NAME子事件发射（单跳内标记为affiliate），必要时发射RAW_DNS_RECORD原始记录事件；
6. 标签处理：对无法解析的主机打上unresolved标签并转换为DNS_NAME_UNRESOLVED类型；对解析距离过长的"失控 DNS 链"打上runaway-dns-{distance}标签并停止继续解析。

相关的 DNS 配置

dnsresolve的行为受 bbot/defaults.yml 中dns:配置段控制，常用的有：

dns: # Completely disable DNS resolution (careful if you have IP whitelists/blacklists, consider using minimal=true instead) disable: false # Speed up scan by not creating any new DNS events, and only resolving A and AAAA records minimal: false # How many instances of the dns module to run concurrently threads: 25 # How far away from the main target to explore via DNS resolution (independent of scope.search_distance) # This is safe to change search_distance: 1 # Limit how many DNS records can be followed in a row (stop malicious/runaway DNS records) runaway_limit: 5 # DNS query timeout timeout: 5 # How many times to retry DNS queries retries: 1 # Completely disable BBOT's DNS wildcard detection wildcard_disable: False # How many sanity checks to make when verifying wildcard DNS wildcard_tests: 10

在 bbot/modules/internal/dnsresolve.py 的setup()中，这些配置被读取并生效：threads决定并发解析线程数；minimal=True时只解析A、AAAA、CNAME三种记录；search_distance决定向目标外探索几跳。从源码看，module_threads属性直接返回self.dns_config.get("threads", 25)，默认 25 个并发线程。

通配符处理

handle_wildcard_event()是通配符检测的核心。它对每个 DNS 记录类型判断是否为通配符：

• 若某类型确认为通配符，事件会被打上wildcard或wildcard-{类型}标签；
• 若事件所有记录均为通配符且不是扫描目标（无target标签），事件数据会被改写为_wildcard.{父域名}形式，例如www.evilcorp.com→_wildcard.evilcorp.com，从而避免对海量通配子域进行无效扫描。

excavate：从扫描数据中被动挖掘"宝藏"

excavate是内部模块中最复杂、信息产出最丰富的一个。它被设计用于从 HTTP 响应数据中被动提取有价值的信息，主要使用YARA 正则进行匹配，并对 YARA 命中结果进行后处理，最终发射出多种类型的事件。实现位于 bbot/modules/internal/excavate.py。

工作机制概览

excavate监听HTTP_RESPONSE与RAW_TEXT两类事件，声明产出URL_UNVERIFIED和WEB_PARAMETER。其核心流程是：

1. 对响应 body、响应头字符串分别运行编译好的 YARA 规则集（self.yara_rules.match(data=...)）；
2. 每个命中的规则名在yara_preprocess_dict中查找对应的预处理函数，把 YARA 原始命中结果转交给对应子模块（ExcavateRule子类）做后处理；
3. 后处理产物统一通过report()发射为事件。

在 bbot/modules/internal/excavate.py 中有一段颇具风格的"BBOT 正则戒律"注释，概括了该模块的性能原则：

1) Thou shalt employ YARA regexes in place of Python regexes, save when necessity doth compel otherwise. 2) Thou shalt ne'er wield a Python regex against a vast expanse of text. 3) Whensoever it be possible, thou shalt favor string matching o'er regexes.

即：优先使用 YARA 正则而非 Python 正则、绝不对大段文本跑 Python 正则、能用字符串匹配就尽量不用正则——这保证了 excavate 在海量响应数据上依然高效。

setup()阶段会遍历扫描中的所有模块，通过find_subclasses()收集所有继承ExcavateRule的子模块并注册它们的 YARA 规则，然后将全部规则一次性编译（并打印编译耗时）。此外还会读取parameter_blacklist与parameter_blacklist_prefixes（见 bbot/defaults.yml），用于过滤掉__VIEWSTATE、PHPSESSID、BIGipServer*、utm_*这类无价值参数。

URLs：爬虫的一半

通过从所有访问过的页面中提取 URL，excavate 实际上已经完成了半个网络爬虫的工作——另一半"递归"能力内置于 BBOT 底层。为了防止递归失控导致扫描无限蔓延，BBOT 默认通过web_spider_distance和web_spider_depth设置加以限制（对应 bbot/defaults.yml 中的web.spider_distance与web.spider_depth）：

web: # Set the maximum number of HTTP links that can be followed in a row (0 == no spidering allowed) spider_distance: 0 # Set the maximum directory depth for the web spider spider_depth: 1 # Set the maximum number of links that can be followed per page spider_links_per_page: 25

从源码看，URL 提取由URLExtractor子模块负责：url_full规则匹配完整 URL，url_attr规则匹配带href/src/action属性的 HTML 标签，提取出的相对 URL 会通过urljoin与源页面 URL 重组为绝对地址，再经过严格校验后发射为URL_UNVERIFIED事件。若一页内提取的链接数超过web_spider_links_per_page，事件还会被打上spider-max标签以限制爬取。不过在合适的场景下，受控使用爬虫能力会非常强大——例如配合spider预设进行深度目录挖掘。

Parameter Extraction：Web 参数提取

参数提取功能从 HTTP 响应中识别并提取关键 Web 参数，产出WEB_PARAMETER事件。覆盖范围包括：

• GET / POST 请求中的参数（直接解析 URL query string）；
• HTML 表单参数（GetForm/PostForm子模块解析<form>标签内的input、select、textarea、button元素）；
• jQuery 请求参数（GetJquery/PostJquery/AjaxJquery子模块解析$.get()、$.post()、$.ajax()调用）；
• Location 重定向头与 Set-Cookie（重定向 URL 中的参数、服务端下发的 Cookie 也会被提取）；
• 自定义 Header/Cookie（当参数提取启用时，配置的http_headers/http_cookies会被发射为WEB_PARAMETER）。

值得注意的是，参数提取是按需启用的：setup()中会检查当前扫描是否有模块监听WEB_PARAMETER事件，只有在存在消费者时才加载parameter_extraction规则。从源码注释看，目前WEB_PARAMETER事件主要被hunt模块使用，paramminer模块也会在有限程度上使用它们，而未来的功能将大量依赖这类事件。

excavate 还提供两个相关选项：

• speculate_params（默认False）：启用后会对 JSON/XML 内容进行推测性参数提取（发射SPECULATIVE类型的WEB_PARAMETER）；
• parameter_blacklist/parameter_blacklist_prefixes：过滤无价值参数名。

Email Extraction：邮箱提取

EmailExtractor子模块通过 YARA 正则/[^\W_][\w\-\.\+\']{0,100}@[a-zA-Z0-9\-]{1,100}(\.[a-zA-Z0-9\-]{1,100})*\.[a-zA-Z]{2,63}/检测HTTP_RESPONSE数据中的邮箱地址，并发射EMAIL_ADDRESS事件。

Error Detection：错误信息检测

ErrorExtractor子模块扫描 HTTP 响应与原始文本数据中的冗余错误信息。通过识别来自各种编程语言与框架的特定错误签名，帮助发现配置错误、调试信息残留与潜在漏洞。内置签名覆盖了以下平台（见 bbot/modules/internal/excavate.py）：

• PHP：如Fatal error:、.php on line [0-9]+；
• Microsoft SQL Server：如[ODBC SQL Server Driver|SQL Server|ODBC Driver Manager]；
• Java：如.java:[0-9]+、.java(Inlined )?Compiled Code；
• Python：如File "[...]", line [0-9]+, in；
• Ruby：如.rb:[0-9]+:in；
• ASP.NET：如Exception of type、--- End of inner exception stack trace ---；
• Perl：如.pm line [0-9]+。

命中后统一发射FINDING事件，描述中包含具体签名标识（如(PHP_1)）。这类信息对定位 Web 应用的薄弱点或异常极为有价值。

CSP 提取：从 Content-Security-Policy 中发现域名

CSPExtractor子模块聚焦于从Content-Security-Policy响应头中提取域名。通过分析 CSP 头，BBOT 可以发现更多域名并反馈回扫描流程（发射为DNS_NAME事件），从而扩展资产覆盖面。

序列化检测：识别危险的反序列化对象

序列化对象是严重安全漏洞的常见来源。SerializationExtractor子模块旨在检测 Java、.NET、PHP 应用中出现的序列化数据，其内置特征包括：

• Java：rO0...（Java 序列化魔术头）；
• Ruby：BAh...；
• .NET：AAEAAAD//...；
• PHP（数组/字符串/对象）：YTo...、czo...、Tzo...；
• 疑似压缩数据：H4sIAAAA...（gzip 魔术头）。

命中后发射FINDING事件并标注具体类型。

功能性检测：定位易受攻击的功能点

FunctionalityExtractor子模块查找特定的 Web 功能元素，帮助 BBOT 定位可能需要进一步安全审查的区域，包括：

• 文件上传字段：<input type="file">标签；
• WSDL URL：匹配https?://[^\s]*\.wsdl，并利用emit_match把命中的 URL 内容包含进事件描述中。

非 HTTP Scheme 检测：发现其他攻击向量

NonHttpSchemeExtractor子模块提取带有非 HTTP scheme 的 URL（如ftp、mailto、javascript等）。命中后会发射两类事件：

1. FINDING（描述为Non-HTTP URI: ...）；
2. PROTOCOL事件（携带协议名与主机，若有端口则一并给出）。

同时，规则内置了 scheme 黑名单（javascript、mailto、tel、data、vbscript、about、file），并参考 bbot/wordlists/valid_url_schemes.txt 中的合法 scheme 列表进行校验。通过识别这些 URL，BBOT 可以揭示额外的攻击面或信息泄露向量。

其他提取器

• JWTExtractor：匹配eyJ...形式的 JSON Web Token（emit_match开启时会把 token 原文写入事件描述）；
• HostnameExtractor：基于扫描目标动态生成 YARA 规则，从响应中提取目标域名的子域/相关域名（发射DNS_NAME）；
• LoginPageExtractor：检测同时包含用户名与密码输入框的登录页面，并为事件打上login-page标签。

自定义 YARA 规则

excavate 支持使用自定义 YARA 规则，它们会在扫描开始前被合并进其他规则中一并编译。有两种提供方式：

1. 命令行选项：--custom-yara-rules/-cy（定义于 bbot/scanner/preset/args.py），后跟存放规则的本地文件路径；
2. 配置项：excavate.custom_yara_rules模块选项，值可以是规则文件路径或规则内容本身。

从 bbot/modules/internal/excavate.py 的setup()逻辑可以看到加载细节：若路径指向文件则读取文件内容，否则把配置值当作规则内容；每条规则先经yara.compile()验证语法，再从规则体中提取规则名，注册到CustomExtractor中；加载成功后打印Successfully added N custom Yara rule(s)。

自定义规则的编写与 meta 选项（description、tags、emit_match）的详细用法，参见 docs/modules/custom_yara_rules.md，核心要点如下：

• description：规则的描述，会出现在最终事件的 description 字段中；
• tags：逗号分隔的字符串，会被原样传递到产出事件的标签上；
• emit_match：设为true时，YARA 正则命中并提取的内容会包含在FINDING事件中。

一个最简单的规则示例：

rule find_string { strings: $str1 = "AAAABBBB" condition: $str1 }

配合命令使用：

bbot -m httpx --custom-yara-rules=test.yara -t http://example.com/

另外，excavate 模块还有两个可调选项（见 bbot/modules/internal/excavate.py）：

• yara_max_match_data（默认 2000）：单个 YARA 正则最多可提取的文本长度；
• speculate_params（默认 False）：是否从 JSON/XML 内容中做推测性参数提取。

需要留意：YARA 使用自己的正则引擎，与 Python 正则并非一一对应，现有 Python 正则往往需要改造才能工作；但 YARA 引擎速度极快，远胜 Python 正则。

speculate：基于常识的数据推断

speculate模块的核心思想是"用一种数据类型推断另一种数据类型"，尤其是在未启用端口扫描器等工具时。对于大多数 BBOT 扫描而言，这是必不可少的功能——它允许在仅有 DNS 目标列表（且没有端口扫描器）的情况下发现 Web 资源，通过利用现有信息弥合数据缺口，提供更全面的目标视图。实现位于 bbot/modules/internal/speculate.py。

关键选项

options = {"max_hosts": 65536, "ports": "80,443", "essential_only": False} options_desc = { "max_hosts": "Max number of IP_RANGE hosts to convert into IP_ADDRESS events", "ports": "The set of ports to speculate on", "essential_only": "Only enable essential speculate features (no extra discovery)", }

• max_hosts（默认 65536）：IP_RANGE 转 IP_ADDRESS 时最多转换的主机数上限；
• ports（默认80,443）：推测开放端口时使用的端口集合；
• essential_only（默认 False）：只启用必要推测功能（关闭额外发现）。

setup()中还会动态判断：若当前扫描没有启用主动端口扫描器，则默认假定这些端口开放，并打印No portscanner enabled. Assuming open ports: 80, 443；若目标主机数超过max_hosts且无端口扫描器，会给出启用portscan模块的强烈建议。

推测规则明细

IP_RANGE → IP_ADDRESS

将 IP 网段展开为单个 IP 地址，发射为IP_ADDRESS事件。展开前会做随机打乱（random.shuffle），避免对同一网段的连续 IP 按固定顺序探测。

DNS_NAME → 父域名

从 DNS 名称生成父域名（如sub.example.com→example.com），发射为新的DNS_NAME事件。

URL / URL_UNVERIFIED → OPEN_TCP_PORT 与子目录推测

• 从 URL 推断开放的 TCP 端口（OPEN_TCP_PORT事件）——若该端口不在默认推测端口集合中；
• 从已验证的 URL 推测其子目录 URL，发射为URL_UNVERIFIED（继承父事件的web_spider_distance，不递增）。

通用 URL 推测

对URL事件或任何带有url属性的字典型事件，若该 URL 尚未出现在事件历史中，则发射URL_UNVERIFIED事件。

IP_ADDRESS / DNS_NAME → OPEN_TCP_PORT

若未启用主动端口扫描，则为 IP 或已解析的 DNS_NAME 推测开放端口（发射OPEN_TCP_PORT，标记为内部事件）。

ORG_STUB 推导

从以下来源推导组织代号（ORG_STUB）事件：

• TLD 域名：对距离为 0 的DNS_NAME，通过tldextract提取公共后缀下的主域部分（含 punycode 解码与 unidecode 规范化）；
• SOCIAL 事件：取stub字段；
• AZURE_TENANT 事件：取tenant-names字段列表。

USERNAME → EMAIL_ADDRESS

将用户名转换为邮箱地址——若该用户名能通过邮箱软校验（validators.soft_validate），则发射为EMAIL_ADDRESS事件（标记affiliate）。

从 bbot/core/event/base.py 的注释可知，speculate 产生的大量OPEN_TCP_PORT属于内部事件（internal=True）：它们只用于模块间的正常流转，不进入输出模块，避免干扰扫描结果的可读性，同时支撑诸如sslcert等模块对 distance-1 端口的需求。

unarchive：文件解压（补充）

除文档列出的 5 个模块外，从源码目录 bbot/modules/internal/ 还可以看到第 6 个内部模块unarchive。它监听FILESYSTEM事件，将下载的压缩文件解压到文件系统文件夹中并重新发射FILESYSTEM事件，以便后续模块（如 extractous、excavate 的 RAW_TEXT 管道）继续处理解压出的内容。

其支持的压缩格式见 bbot/modules/internal/unarchive.py：zip、bzip2、xz、7z、tar、gzip，分别调用7z或tar完成解压，并有 1GB 的解压大小上限保护；Java Archive（JAR）与 Android APK 默认跳过（交由jadx等专用模块处理）。

如何管理内部模块

通过配置文件禁用

在配置文件的根级（如 bbot/defaults.yml）将对应项设为False：

speculate: False # 关闭数据推断 excavate: False # 关闭被动挖掘 aggregate: False # 关闭扫描结束统计表 dnsresolve: False # 关闭 DNS 解析（谨慎：会影响白/黑名单判断，可考虑 dns.minimal=true） cloudcheck: False # 关闭云厂商标记

使用注意事项

• dnsresolve关闭会显著影响扫描的范围控制能力，若仅想提速，官方建议优先使用dns.minimal: true（只解析 A/AAAA 记录、不创建新 DNS 事件）而不是完全禁用；
• excavate关闭后，--custom-yara-rules也将失去作用；
• speculate关闭后，仅凭 DNS 目标列表且无端口扫描器的扫描将很难发现 Web 资源；
• 上述配置项均以根级配置键的形式出现，与普通模块的modules: {name: {...}}嵌套结构不同。

小结

BBOT 的内部模块构成了扫描的"基础设施层"：

理解这些模块的职责与配置，是掌控 BBOT 扫描行为、定制扫描范围与性能的关键一步。它们默认全开、按需可关，合理的组合（例如配合dns.minimal、speculate.essential_only、excavate 的自定义 YARA 规则）可以让扫描在速度、深度与覆盖面之间取得理想的平衡。若想进一步了解自定义 YARA 规则的 meta 选项与正则编写技巧，可直接阅读 docs/modules/custom_yara_rules.md；更多扫描预设与配置细节可参考 docs/scanning/presets.md 与 docs/scanning/configuration.md。

【免费下载链接】bbotThe recursive internet scanner for hackers. 🧡项目地址: https://gitcode.com/GitHub_Trending/bb/bbot