北京
那天晚上，CoreStack 的办公室几乎空了。Leo 一个人坐在工位上，翻看几个月前布置的一个被动探针日志。探针监听着一组与 Automated Compliance Lab（ACL）相关的 IP 段——这是他在 FinOptima 事件之后悄悄留下的。几个月来一直沉寂，今晚他只打算例行检查一下是否还在正常运行。
然而日志缓冲区的最后几行，并不是他预想中的回显。
一条来自外部 IP 的出站查询出现在记录里：目标地址指向一个 ACL 的内部收集器端点，请求使用 HTTPS，服务器名称标识是 acl-collector.internal。更关键的是，请求头部携带了 ACL 的数据源头标记——x-data-origin: acl-meta-signature:v1，消息体里还嵌着 acl-collector/v3.2 版本标签。随后处理元数据时，又出现了 Apex-Lens/v2.0.0 的字样。
一个不在 ACL 已知网络内的节点，正在向 ACL 收集器发送数据，并且在握手的瞬间，它的工具泄露了 ACL 的元数据签名。这不是一次直接的扫描，而是一个查询数据格式的 HTTPS 探针，恰好撞进了 Leo 的监控范围。
Leo 把椅子往前拽了拽。他没有贸然行动，只发了一个无害的 HTTP 请求：GET /health。这个操作没有携带任何探测性的载荷，只是确认端点是否存活。
就在这同一秒，工程师 Derek 的端口活动日志也弹出了一条信息性告警。
告警显示，一个来源为金融网络内网段（10.88.*.47）的 IP，对 Derek 的沙箱节点发起了三次连续扫描，间隔 12 秒，覆盖了 TCP 22、443、8080 端口，被系统归为自动资产发现行为。Derek 扫了一眼告警，随即去查对应的出站记录——他的沙箱在那一小时确实有一个预定任务：每 72 小时向 ACL 收集器端点发送一次格式验证查询。因为收集器不在数据流中发布 schema 元数据，你必须主动敲门去验证格式有没有漂移。测试工程师的习惯罢了。那个查询在 23:41 发出，而告警的时间戳同样是 23:41。
Derek 正要关掉日志窗口，手指突然停住了。一条三天前的异常访问记录引起他的注意：来源未知，路径是 /pulse/ingestion/，没有携带任何 payload……
两个线索像被吸进同一个坐标。Leo 的探针捕获到的正是 Derek 沙箱发出的格式验证请求，而 Derek 看到的那个来源 10.88.*.47 的扫描，正是 Leo 发来用于健康检查的 GET 请求。一个试图弄清数据格式，另一个试图确认节点存活性。两人此前从未通过气，却各自盯上了 ACL 的数据管道。
谁能想到，深夜的两行日志，竟把两个从未交流的工程师推到了同一条调查线上。他们要查的，也许是同一个敌人。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
