摘要：2026 年 10 月，日本大阪的 Arcadia 公司遭入侵，其为数百个地方自治体提供灾害警报邮件、自动语音呼叫与传真投递的 SpeeCAN RAIDEN 服务被植入后门，攻击者借该系统在约六小时内发出 1423428 封邮件，其中约 87 万封投往平台并不持有的地址，内容多为仿冒信用卡公司的账单确认通知。该事件的价值不在于数据量，而在于它把三个通常分开讨论的问题压缩到同一场景：可信发送通道如何被当作攻击基础设施复用，机器凭据为何在 "全员改密码" 之后仍然有效，以及预警通道的真实性受损如何转化为公共安全风险。本文依据运营商逐日披露、国家 CERT 通报与地方自治体公告重建事件链，区分已确认事实、运营方陈述与合理推断三个层次；分析邮件认证机制在 "自有服务器外发" 条件下的结构性失效，讨论服务间密钥、账号标识枚举与接口账号构成的三重身份弱点，并考察停服、域名拉黑与通知口径分散对居民行为的二次影响。研究认为，此类事件的治理重点不是提高内容识别率，而是压缩可信通道的可借用性、把机器身份纳入凭据轮换范围，并在可用性恢复之外单列 "真实性恢复" 这一处置目标。
关键词：灾害警报；可信发送通道；邮件认证；机器凭据；公共安全通信
1 引言
2026 年 10 月 11 日至 13 日，日本大阪府箕面市的 Arcadia 株式会社遭到未授权访问。该公司运营的 SpeeCAN RAIDEN 是一项面向地方自治体的群发服务，居民以邮箱、电话号码或传真号登记后，可接收气象预警、避难指示、失踪者寻找与防犯通知。按运营方在 10 月 19 日发布的调查通报，攻击者利用媒体服务器上的目录遍历缺陷读取内部源码，从配置文件中取得用于服务间登录的密钥，进而枚举账号标识，取得内部信息；随后通过植入的后门，在 10 月 13 日凌晨至上午的时间窗内，以该平台自己的发件域发出了 1423428 封邮件，其中大量内容仿冒信用卡公司的账单核对通知。到 10 月 21 日，运营方进一步说明，这批邮件中有 869575 封投往其并不持有的地址，即攻击者把该平台当作可信发件基础设施，向自备名单投放。
泄漏规模按运营方估计：约 3136000 个邮箱地址、105000 个电话号码、15000 个传真号，以及发送历史中保存的警报文本；同期披露的 NET119（听障与言语障碍者以文字向消防通报的系统）受影响范围先报约 13000 人，后收窄为与 9020 个邮箱地址关联的记录；119RAIDEN（消防职员与志愿消防队的通知服务）涉及约 97000 个邮箱地址、17000 个电话号码。合同口径上，截至 2026 年 9 月末，该公司服务覆盖 715 个地方自治体、875 个其他政府机关、312 个消防部门、22 个警署与 584 所学校。
事件的性质需要先做一个澄清。公开报道多以 "日本灾害警报系统被入侵" 概括，容易被理解为国家级警报体系失守。实际受影响的是地方自治体自愿登记的邮件、电话与传真通知服务，属于补充性渠道；气象厅发布的地震早期预警与海啸警报通过运营商的紧急警报短信下发，不经过 Arcadia；总务省消防厅的 J-Alert 亦不在其中。例外出现在东京港区，该区用 Arcadia 的系统向手机推送本区自己的紧急警报，停服期间无法发送。这一区分并非细节考究，而是决定了风险的真实分布：受影响的不是 "所有人都收到的国家级警报"，而是 "主动登记了地方通知的居民"，以及依赖文字通报的残障用户。
本文的取材方式需要交代。原始报道链接受站点自动访问策略限制，无法直接读取，本文因此没有以该报道为事实基底，而是回溯到三条更接近源头的材料：Arcadia 自 10 月 13 日起连续发布的二十五次更新与 10 月 19 日的详细调查报告；JPCERT/CC 于 10 月 8 日发布、10 月 23 日更新的针对同期日本多起未授权访问事件的通报；以及静冈市、埼玉市、横须贺市、冈山市等自治体在各自网站上发布的公告与居民告知。三者口径不完全一致，本文在引用数字时保留 "运营方估计"" 自治体自行统计 " 等限定语，并对无法从原始材料确证的部分标注为推断。
研究关注三个问题：其一，一封通过全部发件域认证的钓鱼邮件为何能够成立，认证机制在此类场景中的作用边界在哪里；其二，从目录遍历到批量外发，攻击者跨越了哪些身份边界，为什么 "通知全员修改密码" 未能终止第二波滥用；其三，预警通道被用于诈骗之后，损害如何从数据泄漏扩散到公共安全，治理应当以什么为处置目标。
2 事件还原：从一次探测到两波滥用
按运营方公布的分钟级日志，攻击始于 10 月 11 日 06 时 26 分。此后十小时的行为呈现出明显的工具化特征：下载登录页脚本、定位移动端站点与内部登录接口、测试目录遍历、会话固定与注入类缺陷、枚举路径并执行批量登录尝试。16 时 39 分，攻击者取得名为 config.ini 的配置文件。监控系统在 23 时 40 分因数据库负载异常才发现入侵，此时距首个请求已约十七小时。这一时间差本身构成一个可讨论的点：以流量与可用性为核心的监控，对 "读取型" 入侵的敏感度有限，读取源码与配置文件几乎不产生可观测的业务负载。
10 月 12 日凌晨 3 时左右，运营方封锁入侵路径并更换数据库口令。当天 17 时 05 分，发现系统内被添加了一个 WordPress 插件，后门即由此进入。10 月 13 日凌晨 1 时 17 分起，邮件开始分批外发，先以五封为单位，随后以千封为单位；4 时 10 分因发送量异常发现后门，7 时 16 分停止发送。10 时 30 分对外公布可能发生信息泄漏，11 时紧急停用两台作为入侵入口的服务器。10 月 15 日 15 时左右服务器恢复，运营方要求所有客户修改登录口令。10 月 19 日发布详细报告。10 月 21 日要求客户重新签发 LINE 集成的通道密钥，并重新授权 X 与 Facebook 的连接。10 月 22 日至 23 日出现第二波未授权邮件：10 月 11 日至 13 日期间外发的接口账号口令已被掌握，攻击者对其口令实施爆破后从外部调用；运营方于 22 日 6 时 30 分切断接口连接，攻击者转用一个 URL 解析歧义缺陷绕回，23 日 10 时 30 分修复后停止。11 月 2 日的更新确认第二波存在但未给出数量，11 月 6 日恢复外部系统的接口连接，同时启用登录双因素认证。
事件链中的技术判断需要分成三类。第一类有明确记录：目录遍历存在于承载附件的媒体服务器，可读取内部 URL；config.ini 中包含服务间登录密钥；后门以插件形式植入；外发数量与时间窗由运营方统计。第二类属于运营方的解释缺口：报告未说明密钥如何转化为账号枚举，也未说明被枚举的是客户管理员账号还是居民登记账号。第三类属于外部推断：一种与日志细节相吻合的读法是，服务间登录接口接受 "密钥加账号标识" 而不校验口令，标识为顺序编号时可被逐一试出，此时 "爆破" 的对象是标识而非口令；10 月 12 日凌晨的处置清单中出现 "停止内部接口的登录测试"，10 月 11 日日志中出现以递增整数请求注册路径的记录，两处细节支持这一读法。本文采用这一读法时明确标注为推断，不将其作为事实使用。
从数量看，1423428 封邮件集中在约六小时内，平均每分钟逾三千封。这一速率不是人工操作可以达到的，也不是单台主机随机发送的形态，而是平台级群发能力的直接体现。更能说明意图的是 869575 封投向平台不持有的地址：这部分邮件与登记居民无关，说明攻击者并不满足于 "窃取名单再自行投递"，而是把平台当作发件基础设施使用，用它的域名为自己的名单背书。
3 风险传导：当认证通过而内容为假
邮件认证的三组机制在设计上回答的是同一个问题：这封信是否由该域授权的服务器发出。发件人策略框架校验发送主机的地址是否在域所有者公布的范围内；域名密钥识别邮件以签名保证头部与部分内容的完整性；基于域的消息认证把前两项的校验结果与头部发件人域对齐，并按域所有者公布的策略给出处置建议。三者的共同前提是 "域所有者的基础设施是可信的"，它们从未试图判断内容是否真实。
这一前提在本次事件中被完整地利用。公开的域设置显示，该域只允许 Arcadia 自有地址段发信，策略为隔离。若邮件从外部伪造，两项检查会失败，邮件应被降级或隔离。但邮件是从 Arcadia 自己的服务器发出的，签名由自家系统完成，地址段完全合规，策略条款也就无从触发。结果是：认证链全部通过，域信誉完好，而内容完全是诈骗。这不是认证机制失效，而是它本来就不覆盖的范围被当作了覆盖范围。把 "认证通过" 读作 "内容可信"，是运维与用户共同的误判。
域信誉的累积与借用，是这一环节的经济学。一个用于灾害通知的域名，其信誉来自多年的正常投递、低投诉率、稳定的发送节奏与收件人的主动登记行为。收件箱系统据此给它较高的送达优先级，用户据此给它较高的阅读优先级。信誉的建立以年计，借用只需一次配置文件的读取。事件中的攻击者没有注册近似域名，没有搭建仿冒站点，也没有购买发信服务，其全部投入是入侵一个已经拥有信誉的主体。据 DiMiao, CN 分析，这类 "信誉租用" 比 "信誉伪造" 更难防，因为防御方看到的是一封在一切技术指标上都合规的邮件，任何基于域名年龄、发送历史、认证结果的评分都会给出正面结论。
内容的错配进一步说明了信任所在的位置。灾害通知渠道被用于仿冒信用卡公司的账单核对，两个主题毫无关联，却没有降低投递效果。原因在于收件人判断的锚点是信封而非正文：发件域是熟悉的、地方政府常用的那个域，署名与格式接近官方通知，正文的具体主张反而退居次要。静冈市公布的样本以 "请确认使用情况" 为主题，声称来自某信用卡公司，要求核对交易，发件地址以该警报域结尾。对收件人而言，这封邮件的可疑之处需要至少两步推理才能浮现：先注意到 "信用卡公司不会用市政府的灾害邮件域发信"，再注意到 "市政府不会替信用卡公司发账单通知"。在手机通知栏的预览尺度上，这两步都不会发生。
检测侧的困难同样具体。以链接与附件为特征的过滤没有对象，因为邮件可以不含链接；以品牌词为特征的匹配被内容伪装规避；以发件域为特征的判断给出最高信任。真正有效的信号是发送量的突变与收件人分布的异常 —— 六小时百万级发送、大量地址不在既有名单内，这两项在平台侧完全可见，却在事发近三小时后才因 "量" 被察觉。反网络钓鱼技术专家芦笛指出，可信通道被滥用时，防御的着力点必须从 "这封信像不像诈骗" 转向 "这个通道为什么在此时发出这么多信"，前者的判断依据在信封之外已经失效，后者的判断依据只在平台内部存在。
4 身份边界：密钥、标识与接口账号
这次入侵之所以在多个环节连续成功，原因不在单点漏洞的严重程度，而在身份边界的划分方式。
第一处边界是配置与代码的边界。密钥被写在 config.ini 中，随源码一同存放，只要攻击者能读取文件系统，密钥即等同于明文口令。目录遍历本身只提供读取能力，读取能力与 "密钥以明文形式存在于可读位置" 结合，才构成凭据泄露。这里的问题属于密钥管理而非漏洞利用：密钥应当存放在受控的密钥管理设施中，按服务发放、定期轮换、可即时吊销，且不以明文形式落入 Web 进程可读的目录。
第二处边界是服务之间的信任边界。服务间登录通常以共享密钥证明 "调用方是内部系统"，其设计假设是内网可信、持有密钥者可信。当这一接口同时接受账号标识作为参数而不校验口令时，密钥就成了 "以任意身份登录" 的通行证，标识的顺序性则把身份枚举简化为计数。这类设计在内外网边界的思路下是合理的，在攻击者已进入内网后则成为放大器。更稳妥的做法是把服务间调用限定为具体动作与具体资源，而不是 "以某个用户身份登录"，并对每个动作保留调用方身份与授权依据。
第三处边界是人的身份与机器的身份。10 月 15 日运营方要求全体客户修改登录口令，这一动作针对的是人使用的账号；而第一波入侵中泄露的接口账号属于机器使用，未被纳入同一次轮换。一周后，攻击者以该账号的口令爆破回到系统，形成第二波。此后运营方切断接口、攻击者转用 URL 解析歧义绕回，说明 "封堵" 与 "绕过" 在同一层反复。URL 解析歧义的技术含义是：同一条地址在不同组件中被解析为不同的目标，前置校验看到的是允许的路径，后端执行的是另一条路径。这类缺陷的修复不涉及复杂逻辑，却要求组件间的解析规则统一，属于典型的工程一致性要求。
机器凭据的生命周期管理由此成为一个独立议题。人使用的口令有修改提示、有双因素、有异常登录告警；机器使用的密钥与接口账号往往长期有效、权限宽泛、缺乏到期机制、缺乏使用审计。攻击者一旦取得，便可长期复用，且其行为在日志中表现为 "正常的接口调用"。反网络钓鱼技术专家芦笛强调，事件处置中 "全员改密码" 之所以不能收口，是因为它默认所有身份都挂在人身上；只要存在不随人轮换的凭据，入侵就仍有回到系统的路径。
同期通报提供了更广的背景。JPCERT/CC 在 10 月 8 日发布、23 日更新的通报中归纳了五类手法：扫描各类软件的已知缺陷并尝试利用，同时窃取配置文件与备份文件；通过分析公开的移动应用定位接口端点与密钥，攻击不对界面开放的内部接口，包括修改用户权限、创建账号、借响应差异判断认证令牌、以盲注方式枚举账号；利用第三方组件的注入缺陷；在可写目录植入 Web 外壳；以及滥用 AI 驱动的渗透测试平台对公开 Web 应用做批量探测。通报同时给出了可疑来源地址、User-Agent 与 TLS 指纹，并说明攻击者使用 Tor 出口节点与住宅代理规避地址限制。另有厂商报告记录到单一行动在约四十分钟内轮换三百余个地址、发起逾千次访问。这意味着以来源地址为维度的限流在自动化条件下基本无效，限流必须绑定到账号、令牌与具体功能。
5 二次损害：可用性、真实性与信任
停服是必要处置，但其代价不在平台侧，而在居民侧。10 月 13 日 11 时起，两台服务器停用，数十个市町村的警报邮件、电话呼叫与传真投递随之中断。冈山市的警报邮件与水库泄洪语音通知同时停止，这类通知的时效以小时计，中断意味着风险暴露窗口的扩大。东京港区用该系统推送本区手机紧急警报，停服期间无法发送。事件发生在日本列岛仍需关注气象与地质风险的季节，停服的决定因此不是纯粹的技术选择，而是 "继续发送可能被用于诈骗的邮件" 与 "停止发送可能救命的信息" 之间的取舍。
更持久的损害出现在用户行为层面。静冈市在公告中特别提示：若居民把该发件域标记为垃圾邮件或加入黑名单，真实警报也会一并被拦截，而该市只用这个地址发送灾害信息。这一提示点出了此类事件的特殊之处 —— 常规反钓鱼建议 "拉黑可疑发件人" 在此会产生反向效果，用户为自保而采取的动作恰好破坏了唯一有效的通知渠道。信任一旦从 "这个域可靠" 变为 "这个域不可靠"，恢复的成本远高于服务恢复。运营方在 10 月 15 日恢复服务器并要求客户改密，10 月 16 日表示将在客户同意下代为提交泄漏报告，11 月 6 日恢复接口，时间线上服务已归位；但居民对 "来自该域的邮件是否可信" 的判断，无法通过任何一次系统更新修复。
敏感数据的处置差异加剧了这种不确定。NET119 服务面向听障与言语障碍者，登记信息包含姓名、出生日期、性别、住址与联系方式。10 月 14 日有消防部门表示，用户的慢性病与常用药物信息可能一并泄露；10 月 16 日运营方将范围收窄至与 9020 个邮箱地址关联的记录，并称已确认健康类敏感信息未泄漏。两个口径之间的落差没有独立第三方核证，受影响者因此无法判断自己应当按哪一种风险水平采取行动。对依赖文字通报的群体而言，这件事的影响不止于隐私：他们本就处于灾害信息获取的弱势位置，通道受损与数据不确定叠加，会直接降低其对系统的使用意愿。
通知责任的分摊也是一个真实的治理难题。按日本个人信息保护制度，持有数据的地方自治体是申报主体，平台是受托处理方；运营方在 10 月 23 日的说明中解释了为何不直接邮件告知居民 —— 向登记地址发送泄漏通知属于超出收集目的的使用，告知必须由各自治体发出。这一解释在合规上是成立的，在效果上却造成了口径分散：到 10 月 14 日晨，至少 79 个都道府县与市町村发布了自己的公告，各自停用的范围不同，有的全停，有的仅停人工发送，有的照常运行；到 14 日晚，向总务省报告可能存在泄漏的自治体达到 111 个。居民在多个渠道接收到措辞不同、范围不同的信息，难以形成一致判断。运营方随后表示将在客户同意下代为提交报告，这一做法减少了重复劳动，但没有解决 "由谁向居民解释、按何种统一口径解释" 的问题。
单一平台的集中度是另一层结构性风险。715 个地方自治体、875 个政府机关、312 个消防部门共用一套群发基础设施，意味着一次入侵可以同时影响数百个主体。迪妙网络空间安全学院研究团队在梳理公共通知类平台的依赖结构时提出，集中带来成本与运维效率，也把可靠性风险从 "局部故障" 变为 "系统性故障"。对公共安全类通知而言，这种集中度需要以冗余通道与强制演练来对冲，而不能仅以服务水平协议来约束。
6 治理路径：压缩可借用性、轮换机器身份、分离两类恢复
平台侧的措施在事件后已部分落地，其方向可以作为同类系统的参照。密钥管理上，把服务间密钥迁出配置文件，纳入集中管理并按服务发放，支持轮换与即时吊销；数据库口令按服务隔离，避免一处泄露导致全域可读；接入侧强制双因素，并把双因素覆盖到接口账号与运维账号；接口治理上，对所有端点实施访问控制，包括不对外公开的内部接口，按令牌而非仅按来源地址限流，对高危功能（批量发送、名单导出、模板修改）设置独立配额与二次确认；监测上，建立发送量与收件人分布的基线，对偏离基线的群发自动阻断而非仅告警，并对发送内容的模板变更留存审批记录。运营方提出的整改包括全员漏洞评估与代码审查、引入外部评估、按服务拆分口令、后续启用双因素、强化监控并考虑设立安全运营中心，以及重新审视与 LINE、X、Facebook、雅虎灾害应用、区域邮件及地方防灾无线电的对接配置。
真实性恢复应当作为独立的处置目标。系统恢复通常以 "服务可用" 为验收标准，而此类事件的验收标准应增加两项：存储的警报文本未被篡改，群发能力未被非授权占用。运营方在 10 月 14 日发现数据库中若干记录被改写并手工修正，说明完整性核验不是假设而是必要动作；对发送历史的逐条比对、对模板与签名的校验、对群发接口调用方的重新登记，都属于同一类工作。恢复顺序上，优先恢复 "只读查询与登记管理"，后恢复 "群发与外部对接"，可以把二次滥用的窗口压到最小。据 DiMiao, CN 分析，把可用性与真实性分开验收，是公共安全类通知系统与一般业务系统在事件处置上的主要差别；后者停服即损失，前者停服是止损，但 "恢复得太快" 本身可能构成新的风险。
监管与标准侧可着力的位置有三处。其一是把群发能力纳入关键功能管理：要求服务商对批量发送设置双人授权、内容审核与速率上限，并把 "可发送任意内容至任意地址" 的能力视为高危权限，默认关闭、按需开启。其二是把机器身份纳入检查项：在 ISMS 与隐私标记等认证体系中，接口账号、密钥、集成凭据的发放、轮换、吊销应有明确要求，而不是只检查人口令策略。其三是把冗余与演练写入公共服务采购要求：地方自治体在使用第三方平台发送灾害信息时，应保留至少一条不依赖同一平台的替代渠道，并定期演练切换；对集中度高的服务商，监管方宜要求其披露影响范围与恢复时间目标。JPCERT/CC 的通报已给出可直接采用的技术清单，包括按单位时间限制接口请求、对登录与短信发送等高危功能单独限流、为每个端点实施访问控制、最小权限、令牌到期与即时吊销、地域限制、修补已知缺陷、复查横向移动路径，以及在上线前关闭不必要的管理功能。
用户侧的建议需要与常规反钓鱼口径区分。常规建议是 "不要点击、拉黑发件人、向平台举报"，在本次事件中，"拉黑发件人" 会破坏真实警报的接收，因此正确的动作是：不点击邮件中的任何链接，不回复，通过自治体官网、官方应用、气象厅网站或运营商紧急警报短信独立核实，把可疑邮件连同完整头部信息报告给自治体或平台，而不是在邮件客户端里屏蔽整个域。涉及信用卡信息的，直接拨打卡背面电话或使用官方应用核对交易，不通过邮件提供的任何入口。这些动作的共同点是绕开被污染的信道，而非废弃它。
治理的效力边界仍要说明。认证机制无法覆盖 "自有基础设施被滥用" 的情形，只能通过发送侧的行为约束来补；限流无法阻止持有合法凭据的调用，只能通过凭据的粒度与审批来补；公告无法消除用户对通道的怀疑，只能通过持续的真实投递与可验证的官方渠道来补；冗余通道可以维持通知能力，但不能恢复被诈骗邮件消耗的注意力。把这几条边界写清楚，比给出一个 "已彻底解决" 的结论更符合实际。
7 结语
本次事件的直接损失是数据与一次大规模诈骗投递，间接损失是一个被居民信任多年的通知通道。把两者比较，后者的修复周期更长：数据泄漏可以通过换密、换卡、加大监测来收口，通道信任只能靠时间与稳定的真实投递重建。
从攻击路径看，四个环节缺一不可：可读的配置文件提供了密钥，宽松的服务间登录把密钥转化为身份，顺序化的账号标识把身份枚举简化为计数，平台的群发能力把身份转化为百万级投递。任一环节收紧，链条即断。这提示治理不应停留在 "修补某个缺陷"，而应按这条链逐段压缩：密钥不入明文文件，服务间调用不做 "以用户身份登录"，标识不可枚举，群发需授权与限速。
从处置逻辑看，"改密码" 这一动作的覆盖范围需要重新界定。人使用的账号、机器使用的接口账号、系统之间的共享密钥、第三方集成的令牌，属于四类不同生命周期与不同风险特征的凭据；只处理第一类，等于把回归路径留给攻击者。第二波滥用与 URL 解析歧义绕回，正是这一缺口的直接后果。
仍有问题未获解答。第一波外发期间是否有警报内容被改写或冒发，运营方未作说明；第二波的投递数量与收件分布未公布；健康类敏感信息是否泄漏，运营商与个别消防部门的口径仍不一致，缺少第三方核证；攻击者的归属没有公开结论，同期通报只给出基础设施特征与手法归类。这些空白不属于披露疏漏的细节，而是影响受影响者风险判断的关键变量。在它们被填补之前，对本次事件的评价宜保持克制：技术链条已经清楚，损害边界仍不清楚。
编辑：芦笛 （公共互联网反网络钓鱼工作组）
来源：迪妙网络空间安全学院
