NESTCTF 2026 Ghost in the Queue：四把钥匙之后，权限和遥测还差两步

GhostCloud 的最终 flag 锁在 vault 中，需要六把 key。10 月 31 日的会话已经从早期的 2/6、3/6 推进到 4/6；延续到 11 月 1 日凌晨的日志仍显示 complete=false。这篇把已验证的四条链和剩余两处卡点分开记下来。

当前最可靠的进度

凌晨 fullchain.log 中的最终响应为：

1

{"complete":false,"total":6,"unlocked":["k1","k3","k4","k6"]}

先把传输层修对

HTTP API 和 MQTT 是两条不同通道，平台给的 nc 中继实际需要 TLS。早期客户端还出现过 username/password 标志位、CONNACK 返回码、QoS0 PUBLISH 变量头及 topic 偏移错误。

这些错误会把“客户端编码不正确”误判成“服务拒绝认证”。后续用正确的 MQTT 帧确认连接后，才开始把 API、租户主题和 public 状态广播对应起来。

k1：审批编号有效，不代表当前任务被审批

先通过 API 提交合法的 echo 任务，拿到有效 approval_id，再向 tenant/alice/jobs/submit 投递改变了 type、role 的事件。

调度器接受了编号，却没有把它与原先审批的任务类型和角色绑定，因而能执行 get_key1 并在任务结果主题返回 key。根因是审批对象和执行对象之间缺少完整绑定。

k6：取消订单缺乏幂等保护

对同一订单并发取消，出现了多次退款相关事件。对账服务发现异常后向 tenant/alice/alerts 发送 integrity.alert，其中包含 k6。

这里要区分两件事：异常告警可以拿到 key，但退款进入的是 pending_refunds。旧实例里 pending 长时间不结算，并不能当成可立即消费的余额。

k3 与 k4：资金问题后来已经解决

旧笔记中“余额只有 30，买不起 crown”是过时状态。新实例中利用 topup claim 首次使用后的约 90 秒窗口，改变 topup_id 重复入账，会话记录余额达到 23,000。

有了可用余额，购买 crown 取得 k4；完成两笔单价至少 150 的已支付订单后晋升 GOLD，在 alerts 中收到 k3。早期还验证过 GHOST60 一次性券的并发问题，但最新进度不再依赖旧实例被冻结的退款。

这部分的顺序很关键：先处理短时有效的 claim，再做购物与告警收集。不能把很早之前领取过、已经 burn 的 claim 当成可重放的新凭证。

中继桥已经打通，但不等于拿到全部内部权限

自动化网关限制 target 为 internal/audit/*，但 audit ingest 又根据 payload.forward 转发 body，形成第二跳。记录中借此触达内部 shipping 和 telemetry 通道，并拿到过 ops-toolkit。

这说明入口校验的地址与真正的最终目的地不是同一层。然而某些消费者仍有商品白名单、身份和令牌检查；能发到 topic 不等于消费者一定接受操作。

还没做完的 k2

badge 下单后被取消，原因是：

1

restricted item: admin role required

即使余额已经足够、k1 已提交，限制也没有自动消失。直接添加 role 字段、猜运维任务类型和向订单命令主题投递事件，没有形成可确认的 badge 发货记录。

下一步需要追踪履约服务的角色来源：它信任哪个事件、哪个字段，是否存在与审批链不同的身份绑定缺口。当前不能把“消息里写了 admin”当成权限已经提升。

还没做完的 k5

遥测采用 54 4d 01 ... 开头的 TLV 帧。0x30 诊断分支已经能到达，但返回 diag auth failed，说明仍缺 boot session token。

public 状态流中主要看到周期健康信息；restart 任务返回的成功文本也不足以证明代理真的重启或播出了 token。旧记录还试过注解长度回显、配置注入和多种 token 候选，没有得到有效诊断认证。

应继续确认 token 的生成、保存和启动期发送位置，保留重启前后的原始帧，而不是只看 job 的一句成功输出。

后续检查点

每次推进都以 /api/vault 为准，避免把上一实例的进度混到新实例里。当前保留的断点是 k1/k3/k4/k6 已接受，k2/k5 未完成，没有完整 flag。

资料来源

依据 default-workspace 的 ghost 笔记、ntf 工作区 10 月 31 日会话及 fresh_watch.log、fullchain.log 整理；凌晨日志作为跨日补记单独说明。gitq / gitq_handout 的题面内容也是 Ghost in the Queue，归入同题，没有另算一题。文中未公开个人 API 密钥或完整会话转储。