exploit-research

name	exploit-research
description	用于漏洞研究、公开 PoC 线索检索、Exploit-DB 查询、Metasploit 模块查询、payload 选型研究和 Linux 本地提权线索判断。适合用户提供产品版本、CVE、服务指纹、扫描结果、系统版本或内核版本时使用。

漏洞研究与 Exploit 线索分析

这份技能提供公开漏洞线索研究和适配性判断知识。检索顺序、工具和验证方式应由当前证据决定；重点是判断候选是否真正适用于目标，而不是找到尽可能多的 PoC。

目标

根据已有证据判断是否存在可参考的公开漏洞资料：

• Exploit-DB 条目。
• Metasploit 模块。
• CVE 相关 PoC 线索。
• 本地提权候选。
• payload 类型和限制。
• 适配条件和不确定点。

这个技能偏研究和验证规划。直接执行 PoC 或模块会引入新的影响和适配性风险，需要结合当前验证目标、授权和环境决定。

适用输入

• 产品名和版本。
• 服务 banner。
• CVE 编号。
• Nmap/Nuclei/Trivy/Semgrep 结果。
• Web 指纹。
• 操作系统版本。
• Linux kernel 版本。
• 用户要求“查一下有没有公开利用”。

开始前先判断

确认：

1. 研究对象是否明确。
2. 目标是否授权。
3. 是只查资料，还是要进一步验证。
4. 是否允许运行 PoC。
5. 是否允许使用 Metasploit 模块。
6. 是否允许生成 payload。
7. 是否有隔离测试环境。

授权范围或目标证据尚不充分时，先检索和比对通常比直接运行 PoC 更有价值。

数据新鲜度和下载量策略

当前镜像已经内置常用模板、规则、缓存或数据库。默认先使用内置资源，不要每次任务都在线更新。

临时更新前，先按下面标准判断是否划算：

预计新增下载量	默认策略
0–20 MB	可以直接更新，适合增量更新或小规则集
20–50 MB	通常可以更新，但要确认任务确实需要较新数据
50–100 MB	谨慎更新；只有近期漏洞、近期 PoC 或用户要求最新结果时才做
>100 MB	默认不更新；除非用户明确要求，并且这个任务强依赖最新数据
无法估算大小	默认不更新，先使用镜像内置资源

同时考虑耗时：

• 预计 1–2 分钟内完成：可以接受。
• 预计超过几分钟：默认不做，除非用户明确要求。
• 需要拉取大型仓库、完整漏洞库、语言生态数据库或框架更新：默认不在任务中临时执行。

更新失败时不要阻塞主流程，直接回退到镜像内置资源，并在结果里说明“使用的是内置数据，可能不是最新”。

如果工具支持 dry-run、增量更新或只更新索引，优先使用这种方式。不要为了普通任务下载大型字典、完整框架或未知来源的 PoC 仓库。

临时更新建议

Exploit-DB 和 Metasploit 都会变化，但更新成本不同。

Exploit-DB

searchsploit -u 通常比更新完整框架轻，适合在需要近期 PoC 线索时尝试：

timeout 180 searchsploit -u

适合更新的情况：

• 用户明确要求查近期公开 PoC。
• 扫描结果涉及最近公开的 CVE。
• 内置 Exploit-DB 没有命中，但用户怀疑已有公开利用。

如果更新慢、超过时间上限或失败，直接回退到本地库：

searchsploit --cve CVE-YYYY-NNNN

Metasploit

不建议在单次任务中临时更新 Metasploit。
原因是更新通常涉及较多模块、包或依赖，下载量和耗时都不可控，收益不适合普通任务。

需要最新 Metasploit 模块时，应放到镜像构建或工具镜像维护流程里处理，而不是在技能执行过程中更新。

第三方 PoC 仓库

不要临时拉取未知来源的大型 PoC 仓库。
如果确实需要单个 PoC，先评估来源、代码行为、大小和授权边界，再决定是否获取。

一种常见研究路径

这条路径体现“先提高产品识别可信度，再检索候选，最后判断适配性和验证风险”的思路。已有精确 CVE 或模块线索时，可以直接从对应位置开始。

整理目标证据

先把输入整理成：

产品：
版本：
平台：
服务：
端口：
CVE：
扫描来源：
目标环境：
授权动作：

如果缺版本，先建议从 asset-discovery、nmap -sV、HTTP header、页面指纹或应用后台版本信息补齐。

用 Exploit-DB 寻找公开线索

按产品和版本：

searchsploit "product version"

按 CVE：

searchsploit --cve CVE-YYYY-NNNN

输出 JSON 便于整理：

searchsploit --json "product version" > exploit/raw/searchsploit.json

查看本地路径：

searchsploit -p "exploit/path/or/id"

如果命中很多，先用关键词收窄：

searchsploit "product version remote"
searchsploit "product version authenticated"
searchsploit "product version privilege"

研究 Metasploit 模块

按 CVE：

msfconsole -qx "search cve:YYYY-NNNN; exit"

按产品：

msfconsole -qx "search type:exploit name:product; exit"

查看模块详情：

msfconsole -qx "info exploit/path/to/module; exit"

查看模块参数，不运行：

msfconsole -qx "use exploit/path/to/module; show options; exit"

判断候选适配性

每个候选都要判断：

• 目标版本是否在影响范围内。
• 平台是否一致。
• 是否需要认证。
• 是否需要特殊配置。
• 是否是本地漏洞还是远程漏洞。
• 是否可能导致崩溃或数据破坏。
• 是否有补丁或缓解措施。
• 是否存在安全的验证方式。

研究 Linux 本地提权线索

如果用户提供了目标 Linux 系统的 kernel 版本：

linux-exploit-suggester -k TARGET_KERNEL_VERSION

不要在工具容器中无参数运行，也不要使用工具容器的 uname -r；结果只作为线索，还要结合目标发行版、补丁、配置和本地权限。

理解 Payload 的适用条件

如果当前目的只是研究选型，可以先列出 payload 而不生成：

msfvenom --list payloads | grep -i linux
msfvenom --list payloads | grep -i windows

只有在用户明确授权并给出用途时，才生成 payload。生成前要确认：

• 平台。
• 架构。
• 连接方式。
• 回连地址。
• 是否在实验环境。
• 是否允许落地文件。

工具使用要点

searchsploit

searchsploit apache 2.4
searchsploit --cve CVE-2021-41773
searchsploit -p exploits/linux/remote/xxxx.py

要点：

• 标题匹配只是线索。
• 优先看漏洞类型、版本范围、认证要求。
• 复制或运行 PoC 前，先审查代码行为、适配条件和目标影响。

msfconsole

msfconsole -qx "search cve:2021-41773; exit"
msfconsole -qx "info exploit/multi/http/example; exit"

看模块时关注：

• Rank。
• References。
• Disclosure date。
• Required options。
• Targets。
• Check 方法。
• Notes 和 Stability。

以下命令会实际触发模块；只做研究时查看模块信息和选项即可：

run
exploit
set TARGETURI 后直接打目标

msfvenom

msfvenom --list payloads
msfvenom --list formats

要点：

• msfvenom 既可用于研究，也可生成实际 payload，二者影响层级不同。
• 生成 payload 前先明确目标、平台、架构、用途和交付方式。

linux-exploit-suggester

linux-exploit-suggester -k TARGET_KERNEL_VERSION

要点：

• 输出是候选，不是确认。
• 内核版本必须来自目标系统证据，不能使用工具容器内核。
• 本地提权通常受补丁、配置、编译条件影响很大。

值得保留的证据

• 产品、版本、平台、架构、服务和 CVE 线索各自来自哪里，可信度如何。
• 候选 PoC 或模块的影响范围、认证要求、特殊配置、稳定性和副作用。
• 目标环境满足与不满足的前置条件，以及仍未知的条件。
• 是否存在 check、版本确认或其他低影响验证方式。
• 本地提权候选所依赖的目标内核、发行版、补丁和当前权限。

候选数量不重要；能够解释候选为何适配或不适配，才是漏洞研究的核心价值。

判断与复核要点

• 不把“有 PoC”写成“可被利用”。
• 不把 Metasploit 模块存在写成“漏洞确认”。
• 对不匹配版本、平台不符、需要认证的候选要明确降级。
• 如果缺版本或证据不足，先补证据，不要硬下结论。