Nicholas-Kloster/menlohunt

# menlohunt ### GCP 外部攻击面管理 (EASM)

大多数云安全工具 (CSPM) 需要管理员权限：IAM 凭证、服务账号或代理程序。它们只告诉你配置显示了什么——**而不是攻击者实际能看到什么。** **menlohunt** 为你的 Google Cloud Platform (GCP) 边界提供了一种零知识、“由外向内”的视角。它会模拟有动机的对手的侦察阶段，以发现内部工具遗漏的架构泄露。 **无需凭证。无需代理。无需云账号。只需一个 IP 和十五秒。** ## 为什么选择 menlohunt？ 如果你仅仅依赖内部仪表板，你就会陷入**“内部偏见”**。**menlohunt** 的存在是为了解决三个关键问题： ### 1. 验证“边界假象” 防火墙规则非常复杂。在层级策略、网络标签和负载均衡器代理规则之间，控制台显示为“关闭”的端口实际上可能是可达的。**menlohunt** 不看你的规则；它尝试直接“推门进去”。它为你提供暴露面的**真实情况**。 ### 2. 发现“连接组织” 传统的扫描器只能孤立地查看单个 IP。**menlohunt** 从 TLS 证书和反向 DNS 中提取名称候选以进行支点探测。如果它在证书上发现了一个项目名称，它会立即探测属于该项目但未托管在该 IP 上的相关 GCS 存储桶或 Firebase 数据库。 ### 3. 消除“警报疲劳” 标准的扫描器会把 400 个“中等”严重级别的发现塞进一份让你头大的 PDF 中。**menlohunt** 使用**数学子集和算法**来关联发现的漏洞。它认识到共享 `kubernetes` 标签的五个“低”危发现并不是噪音——它们是一条高优先级的**攻击链**。 ## 核心功能 - **GCP 原生智能：** 专为 GCP 打造。它能区分标准的 403 响应和公开但受限制的 GCS/Firebase 端点。它了解 GCP Metadata API 和 Cloud Run URL 的特征。 - **攻击链发现：** 使用数学评分自动将 2-4 个相关的发现分组为可行的攻击路径。 - **超轻量级：** 单个 10MB 的 Go 二进制文件。零依赖。不需要 500MB 的模板库或 Python 运行时。 - **速度：** 大约在 15 秒内执行五阶段扫描（端口、协议、HTTP、TLS 和 GCP 攻击面）。 - **离线与便携：** 旨在放入侦察目录中。为 SIEM 管道 (Splunk, ELK) 提供 JSON 就绪的数据。 ## 五阶段扫描 1. **端口发现：** 感知 L7 的 TCP 探测，可识别甚至在“静默”云防火墙后面的端口。 2. **协议探测：** 与 Redis, MongoDB 和 Memcached 进行原始线路协议交互，以确认未经身份验证的访问。 3. **HTTP 指纹识别：** 针对 Kubelets, Docker Daemons, MLflow 等进行优化的路径分组检查。 4. **TLS 分析：** 从主题备用名称 (SAN) 中提取内部 IP 泄露和 GCP 项目标识符。 5. **GCP 攻击面检查：** 使用发现的名称候选主动探测暴露的 Metadata API、GCS 存储桶和 Firebase 数据库。 ## 安装 使用 Go 构建。无外部依赖。 ``` git clone https://github.com/Nicholas-Kloster/menlohunt cd menlohunt go build -o menlohunt *.go ``` ## 使用方法 ### 1. 扫描目标 ``` ./menlohunt scan -ip 34.120.X.X -out report.json ``` ### 2. 生成人类可读报告 ``` ./menlohunt report -in report.json ``` ### 3. 搜索与过滤 ``` # 搜索与 "docker" 相关的任何内容 ./menlohunt search -in report.json -q docker # 筛选 Critical 漏洞 ./menlohunt search -in report.json -sev CRITICAL ``` ## 攻击链的工作原理 一个开放的 SSH 端口是一个 `LOW` 严重级别的发现。泄露的内部 IP 是 `MEDIUM` 级别。 **menlohunt** 认识到，如果它们共享相同的主机和一个 "remote-access" 标签，它们就代表了一条相关的路径。该工具使用子集和阈值（默认为 15）来展示这些链，将扁平的噪音列表转换为按优先级排序的待发生违规事件清单。 ## 语义智能：menlohunt 的与众不同之处 大多数扫描器生成网络映射图。**menlohunt** 生成逻辑蓝图。 ### 1. 端口 → 基础设施（而不仅仅是“端口 8082 已开启”） - **Nmap:** “端口 8082 已开启。” - **menlohunt:** “这是一个 WireGuard 管理节点，它正在从名为 `[COMPANY]-prod-usw2-catalog` 的 GCS 存储桶中读取其对等列表。” 其他工具给你的是网络拓扑图。menlohunt 给你的是其背后的架构。 ### 2. 基于提取的支点探测（GCP 连接） 通用工具扫描完 IP 就停止了。menlohunt 执行**基于提取的支点探测**：它使用在 `/debug/vars` 中找到的名称（存储桶名称、项目 ID、区域）在第 4 阶段自动探测相关的 GCS 存储桶和 Firebase 数据库。 你在一个 Compute Engine VM 上发现了一个漏洞。而战利品却在 GCS 存储桶中。其他工具将它们视为两个独立的宇宙。menlohunt 将它们视为一条攻击路径。 ### 3. 管理平面与数据平面感知 云安全工具存在**端口偏见**：它们看到 WireGuard 端口 (51820) 是关闭的，就会报告“你的 VPN 是安全的”。 现实情况是：数据平面没问题。而管理平面——*控制* VPN 的代码——却暴露了。开发人员经常忘记对 8082/8086 这样的二级端口设置防火墙，因为他们认为指标数据没有危险。menlohunt 证明了**指标数据与 shell 访问权限一样危险**。 ### 4. 配置与现实（绕过 IAM 盲点） Wiz 和 Prisma Cloud 等工具会读取你的 Google Cloud API 设置。 - **它们看到的：** “防火墙规则允许了 8082。” 标记为中等。 - **它们漏掉的：** 开发人员将明文存储桶名称作为命令行标志传递。 这些工具告诉你的是*规则*很糟糕。menlohunt 证明了*有效载荷*是致命的——它提供的证据能将抽象的警告转化为紧急事件。 ### 5. `/debug/vars` 的语义解析 Nuclei 有一个针对 `/debug/vars` 的模板。它会报告：“Found expvar.” menlohunt 解析 `cmdline` 数组并提取匹配 `-bucketName`, `-dbPath`, `-secretKey`, `-region` 的字符串。它对暴露的端点执行关键字提取，以呈现 GCP 资产——全自动完成。 ## 致红蓝团队 - **红队：** 将其用于“首次打击”侦察。在几秒钟内映射出攻击面，而不会触发沉重的基于内部 IAM 的警报。 - **蓝队：** 用它来“信任但要验证”。向利益相关者证明你的“仅限内部”服务确实对公共互联网隐藏了。 ## 真实案例研究：突破管理平面 在对一家基于 GCP 原生的基础设施提供商进行零知识外部扫描期间，**menlohunt** 识别出两个响应 HTTP 的非标准端口。无需凭证。无需云控制台。无需事先了解目标。 ### 扫描输出 ``` [menlohunt] v0.3.0 target=34.X.X.X timeout=4s retries=1 [menlohunt] open ports: [8082, 8086] [menlohunt] phase 2 — protocol probes + HTTP fingerprinting… [menlohunt] phase 3 — TLS certificate analysis… [menlohunt] phase 4 — GCP surface (GCS, Firebase, metadata, Cloud Run)… [menlohunt] phase 5 — attack chain detection (threshold=15)… [menlohunt] done — 8 findings, 10 chains in 9.1s [C:0 H:4 M:4 L:0 I:0] ``` ### 核心发现 `/debug/vars` (Go expvar) 在端口 8082 上开放。它返回了完整的进程命令行： ``` { "cmdline": [ "/opt/app/bin/catalog-sync", "-logLevel", "info", "-bucketName", "[COMPANY]-prod-usw2-catalog", "-bucketPrefix", "peers/", "-region", "us-west-2" ] } ``` ### 这告诉了你什么 | 发现 | 意义 | |---------|-------------| | `/opt/app/bin/catalog-sync` | 二进制路径确认这是一个托管节点，而非蜜罐 | | `[COMPANY]-prod-usw2-catalog` | GCS 存储桶名称——用于对等表枚举的即时支点探测目标 | | `us-west-2` | 在没有任何云凭证的情况下确认了区域和节点层级 | | 内部端口 `8085` (来自 8086 expvar) | 暴露了私有监听器——无需触碰即可映射拓扑 | ### 攻击链 ``` [chain 1] score=21 tags=[info-disclosure, metrics, management-plane] MH-0004 → Management metrics exposed on port 8082 (Prometheus) MH-0006 → Go expvar /debug/vars leaked full process cmdline (port 8082) MH-0008 → Go expvar /debug/vars leaked full process cmdline (port 8086) ``` ### 为什么其他工具会遗漏这些 | 工具 | 它所看到的 | |------|-------------| | **Nmap** | “端口 8082 已开启。” 到此为止。| | **Wiz / Prisma Cloud** | 防火墙规则被标记为中等。端点从未被拉取。| | **Nuclei** | `/debug/vars` 模板触发——报告“Found expvar”。没有提取。| | **menlohunt** | 拉取 `/debug/vars`，解析 `cmdline` JSON，提取映射整个后端拓扑的 GCS 存储桶名称。无需云凭证。| **数据平面 已被妥善设置防火墙。而 管理平面 却赤裸裸地暴露着。** 大多数工具到“端口 8082 已开启”就停止了。**menlohunt** 会读取响应，将其识别为管理服务，从进程标志中提取隐藏的 GCS 存储桶名称，并检查该存储桶是否公开暴露。它将网络扫描转变成了云资产发现引擎。 *免责声明：此工具仅供授权的安全审计和教育用途使用。*

标签：CSPM, EASM, EVTX分析, Firebase, GCP, GCS存储桶, GitHub, Google Cloud Platform, GraphQL安全矩阵, TinkerPop, TLS证书分析, 云安全态势管理, 前端应用, 反向DNS, 外部攻击面管理, 子集和算法, 安全合规, 安全扫描器, 实时处理, 密码管理, 攻击模拟, 攻击链检测, 数据展示, 无凭证扫描, 日志审计, 红队, 网络代理, 网络安全, 自动化安全评估, 隐私保护, 零知识侦察, 驱动签名利用