pentest-outbound-interaction-oob-detection

出站交互与 OOB 检测

用途

当假设需要回调证据，而非即时带内响应时，使用此技能进行出站交互和带外验证。

主要使用场景：

• SSRF 回调确认
• 盲 XSS 信标
• 盲 XXE
• Webhook 传递验证
• DNS、HTTP 或 HTTPS 回调关联
• 异步服务端交互证明
• 与反向 Shell 相关的出站测试，目标是验证回调，而非处理 Shell

如果可以完全通过带内方式确认发现，请改用带内验证技能。

操作规则

• 将 OOB 验证视为证据收集，而不仅仅是载荷投递。
• 为每个测试用例生成唯一的关联令牌。
• 将对照载荷与测试载荷分开。
• 确认发现前，先根据令牌、子域名或路径以及时间戳关联事件。
• 将会话状态和回调日志保存在磁盘上。
• 让监听器运行足够长时间，以捕获延迟交互。
• 使用能够验证假设的最少协议。
• 不要根据后台流量或未关联的回调声称已确认。
• 不要在回调载荷中发送真实机密。

激活触发条件（肯定）

当请求或观察到的行为包含以下内容时，使用此技能：

• ssrf callback
• blind xss
• webhook abuse
• oob
• dns interaction
• asynchronous callback
• xxe out of band
• blind xxe
• http callback
• https callback
• egress validation

移交标准

• 在进行 OOB 回调关联前，将 XSS 上下文、浏览器接收点分析和载荷构造工作移交给 pentest-xss。
• 将解析器、XXE、SSRF 或请求变更工作移交给 pentest-input-protocol-manipulation。
• 仅在确认出站行为具有确定性后，才移交给 pentest-exploit-execution-payload-control。

验证标准

仅当以下条件全部满足时，才确认发现：

1. 载荷投递前已为每项测试生成唯一令牌。
2. 被测载荷中嵌入了预期的回调标识符。
3. 在允许的测试时间窗口内观察到了交互。
4. 观察到的交互与令牌、路径或子域名以及时间戳相匹配。
5. 对照用例无法解释相同信号。

判定结果：

• confirmed：存在确定的关联
• inconclusive：有部分信号，但关联证据不足
• not confirmed：没有匹配的交互，或对照结果使该主张无效

说明

1. 发送载荷前，为每项测试生成唯一的关联标识符。
2. 确保回调监听器的范围和保留时间足以捕获延迟事件。
3. 确认前，按令牌、路径和时间窗口关联回调。
4. 区分嘈杂的后台流量与测试相关的交互。
5. 使用对照载荷减少误报。
6. 将已确认的原语及完整关联证据交给漏洞利用或逻辑分析技能。

验证关卡

• 将 OOB 验证视为证据规范，而不仅仅是载荷发送。
• 保留不可变的回调日志，以便审计。
• 同时记录正向和负向对照结果。
• 仅在存在确定关联时确认。
• 不相关的测试应使用新令牌。
• 回调载荷中不得包含真实机密。

标准工作流

1. 明确假设和预期的出站行为。
2. 选择能够验证假设的最简回调机制。
3. 为本次评估启动一个监听器会话。
4. 为每次探测生成一个唯一令牌。
5. 将带令牌的回调端点嵌入载荷。
6. 发送载荷，并记录时间戳和来源上下文。
7. 在预期时间窗口内监控匹配的交互。
8. 与对照结果比较后再作出判定。
9. 将已确认的原语及完整证据交给漏洞利用或逻辑滥用工作流。

监听器组件

如果可用，请使用 interactsh-client 或等效的受控回调服务，验证 DNS、HTTP 和 HTTPS 回调。

启动模式参考：

RUN_DIR="/tmp/interactsh-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$RUN_DIR"

interactsh-client \
  -json \
  -o "$RUN_DIR/interactions.jsonl" \
  -sf "$RUN_DIR/session.txt" \
  -ps \
  -psf "$RUN_DIR/payloads.txt" \
  -pi 5 \
  >"$RUN_DIR/stdout.log" 2>&1 &

echo $! > "$RUN_DIR/interactsh.pid"
sleep 2
cat "$RUN_DIR/payloads.txt"

监听器处理规则：

• 每次评估运行启动一个后台监听器，除非隔离要求单独使用一个会话。
• 持久保存 interactions.jsonl、会话状态、生成的载荷域名和标准输出日志。
• 在整个验证窗口期间保持监听器运行。

每项测试的令牌生成

为每个测试用例生成一个唯一令牌：

TEST_TOKEN="$(tr -dc 'a-z0-9' </dev/urandom | head -c 10)"
BASE_DOMAIN="$(head -n1 "$RUN_DIR/payloads.txt" | tr -d '\r\n')"
CALLBACK_FQDN="${TEST_TOKEN}.${BASE_DOMAIN}"

echo "$TEST_TOKEN $CALLBACK_FQDN $(date -Iseconds)" >> "$RUN_DIR/test_tokens.log"

printf '%s\n' "$CALLBACK_FQDN"

规则：

• 不要在无关测试之间重复使用令牌。
• 记录令牌、载荷目标、来源向量和时间戳。
• 在有用时，除基于子域名的关联外，还要使用基于路径的关联。

协议选择

选择与假设相符的协议：

• DNS：出口流量证明、解析器行为、低影响的 SSRF 或 XXE 验证
• HTTP：Webhook 投递、SSRF、应用层回调验证
• HTTPS：目标可能强制要求仅通过 TLS 出口连接时使用

优先选择最少且有用的协议。除非测试需要，否则不要向所有协议发送请求。

与反向 Shell 相关的出口检查

仅当目标是确定目标能否通过 80 或 443 等常见出口通道访问外部端点时，才使用此技能进行与反向 Shell 相关的验证。

规则：

• 使用此技能验证出站可达性和协议行为，而非处理 Shell。
• 如果之后确认可以执行具备 Shell 能力的操作，请移交给漏洞利用执行工作流。

要捕获的证据

对每个测试用例，记录：

• 假设
• 载荷向量
• 生成的令牌
• 回调端点
• 请求时间戳
• 对照载荷
• 观察到的回调时间戳
• 观察到的协议
• 来源上下文
• 判定结果

输出架构

返回：

• 关联表，包含 token、payload path or subdomain、timestamp、source context
• 验证判定：confirmed、not confirmed 或 inconclusive
• 仅基于已确认的出站行为提出后续机会
• 提供足够详细的复现步骤，以便其他操作人员重新运行测试

工具说明

• 如果缺少 interactsh-client 或等效的监听器，请明确说明，建议在下一次运行时使用缺少的工具，并停止进一步确认 OOB 声明。
• 不要用假设取代确定性关联。
• 保留日志，确保基于回调的声明可供审计。