日本经济新闻社员工微软 365 账号被入侵，被操控群发 9000 封钓鱼邮件

事件概要：一封「来自日经」的钓鱼邮件

2026 年 10 月 4 日，日本经济新闻社（NIKKEI）在其官网发布通告，披露一起账号入侵事件：公司一名员工使用的微软 Microsoft 365 账号遭第三方非法登录，攻击者借用该员工名义向外发送了约 9000 封钓鱼邮件。

这批邮件于 9 月 30 日发出，内容包含诱导收件人访问恶意网站的链接。收件范围不限于公司内部——还包括大量采访对象、外部信源、以及此前与该员工有过往来的业务联系人。

这正是这类攻击最危险的地方：邮件是从日经的真实账号发出的。收件人看到的是自己认识的、打过交道的那个记者的地址，仅凭发件人这一项，几乎挑不出毛病。

日经方面表示，账号密码已修改，此后未再发现非法登录迹象；公司已逐一联系约 9000 名收件人，要求删除相关邮件，并向日本个人信息保护委员会报告，正在调查影响范围及可能泄露的个人信息数量。

但 IT之家没提的是：同日还有第二起，而且时间更早

IT之家那篇报道只讲了 Microsoft 365 这一起。实际上，日经在同一天（10 月 4 日）发布了另一份独立通告，披露了一起更早发生、潜伏更久的入侵。

两个关键时间点值得单独拎出来说：

• Google Workspace 的非法登录从 7 月下旬就开始了，直到 8 月上旬才由 Google 方通知日经——潜伏期接近两周，而这是靠外部厂商发现、而非自己发现的。
• 从 8 月上旬知晓到 10 月 4 日公开披露，中间隔了约两个月；期间 9 月 30 日又爆出 M365 大规模发信事件。

日经尚未说明这两起事件是否存在关联、是否同一攻击者所为，也未披露第二起事件涉及的具体云服务细节。

真正值得警惕的：这是日经一年内的第四次

把日经官网的公告往前翻，会发现一件比单次事件更值得注意的事——这家日本最大的财经媒体，在过去约 12 个月里，已经至少公开披露了四次账号入侵与信息泄露事件。

把这个时间线连起来看，规律非常清晰：打的是同一个软肋——账号。换的平台（Slack → M365 → Google Workspace → M365）、打的手法（撞库/钓鱼/终端感染窃取凭证），但落点始终是「拿到一个真实员工的登录态」，然后借这个身份向外扩散。

更值得注意的是传播链的变化。2025 年 Slack 那次，入口是员工个人电脑中病毒——业务系统本身没问题，是终端成了跳板。这几乎是所有企业邮箱被攻破的经典剧本：一次凭证泄露，换来的是一整个通讯录的信任关系。

为什么「真账号发出来的钓鱼邮件」特别难防

这件事在技术上的核心难点，值得展开说清楚。

传统的钓鱼邮件防御，很大程度上依赖 SPF / DKIM / DMARC 这套发件人身份验证机制。它的作用是：如果有人伪造你的域名发信，接收方可以识别出来并拒收或标记。这套机制对「外部冒充」非常有效。

但这次不适用。攻击者不是伪造发件人，而是真的登进了那个账号，用真实账号发信。在这种情况下：

• SPF 校验 → 通过（邮件确实从微软的服务器发出）
• DKIM 签名 → 有效（用的是真实账号的真实签名）
• DMARC 策略 → 无异常
• 发件人地址 → 是收件人通讯录里的人

四道防线全部绿灯，但这封邮件就是恶意的。这就是商业邮件诈骗（BEC）里最难处理的一类——账号接管（Account Takeover，ATO），而非域名伪造。

这也解释了为什么日经通告里的措辞是「冒充邮件（なりすましメール）」而不是「伪造发件人」——被冒用的是身份，不是地址。

落到防御上，结论很直接：既然外发环节验不出来，就必须在账号环节拦住。能真正起作用的是这几件事——

1. 多因素认证（MFA）。这是阻止「拿到密码就能登录」最直接的一道闸。且要优先覆盖邮箱、云办公套件、业务聊天工具这类「一旦进去就能冒充你」的系统；
2. 异常登录检测。异地、异常设备、异常时段、异常频率的登录要能告警。本次 M365 事件是靠「大量异常外发」才被发现，说明登录环节可能没有拦住；
3. 外发行为限流。一个账号短时间内群发数千封邮件，本身就是极强的异常信号，应设置阈值与自动阻断；
4. 终端安全。Slack 那次是员工个人电脑中毒导致凭证被盗——个人设备接入业务系统，是凭证泄露的常见源头。

被忽略的风险：邮件正文泄露，比邮箱地址严重得多

日经通告里有一句容易被一笔带过的表述：

「送信先のメールアドレスや氏名のほか、一部メールの内容が漏洩したとみられます。」
（译文：除收件人的邮箱地址和姓名外，部分邮件的内容也疑似已泄露。）

这条信息的严重性被大大低估了。对一个新闻机构来说——

• 泄露的是记者与采访对象之间的往来邮件正文；
• 这些邮件里往往包含尚未发表的选题、未公开的消息来源、企业未披露的经营信息；
• 一旦被利用，威胁的不只是隐私，而是新闻来源的安全——这在新闻行业是最敏感的底线问题。

日经在通报中特别声明，第二起 Google Workspace 事件不涉及读者与取材对象信息。这个补充说明本身，反过来说明他们非常清楚「信源安全」才是这类事件真正的高压线。

另外，日经还主动提醒：未来冒充该公司及集团旗下企业相关人员的钓鱼邮件可能增加。这个判断的潜台词是——已经泄露的通讯关系和邮件内容，可以用于下一轮更精准的攻击。真实的历史往来记录，会让下一封钓鱼邮件的说服力成倍提升。

给国内站长的四点提醒

日本大媒体踩的坑，换成国内中小团队，可复现度其实非常高。下面几条是能立刻上手的：

第一，企业邮箱和后台，必须开二次验证

这是投入产出比最高的一步。腾讯企业邮、阿里云企业邮箱、QQ 邮箱、以及自建邮箱系统，基本都支持二次验证或登录保护，没开的现在就去开。特别注意：只对管理员账号开了 MFA、普通员工没开，等于没开——攻击者挑的就是最弱的那个号。

第二，公司邮箱别用来注册乱七八糟的东西

邮箱泄露最常见的方式不是被攻破，而是被拖库——你在某个小论坛、某个不知名工具站用公司邮箱注册过，那边泄露了，密码又跟企业邮箱一样，撞库就成功了。建议：公司邮箱只用于业务往来，注册第三方服务一律用单独邮箱 + 独立强密码，密码管理器可以帮上忙。

第三，盯住「外发行为」而不只是「外发内容」

绝大多数企业邮箱没有对外发量做限制。一个账号一夜之间发出几百上千封邮件，往往要等到收件人投诉才知道。可行的做法：在邮箱后台设置单账号日发信量阈值，超出即告警或临时冻结；有条件的可以看外发日志，关注异常时段与异常收件人分布。

第四，把「收到可疑邮件」的判断标准改一改

传统的安全教育是「陌生发件人的邮件要小心」。这次事件恰恰说明这个标准不够用——来自熟人、合作伙伴、甚至你自己公司同事的邮件，同样可能是钓鱼。

更可靠的判断依据应该转向内容侧和链接侧：

• 看链接真实地址（鼠标悬停看域名，别只看显示文字）；
• 看诉求是否反常（突然要求点链接登录、下载文件、转账、提供验证码）；
• 看语气与语境（熟人邮件却措辞生硬、没有上下文，本身就是信号）；
• 拿不准就打一个电话确认——尤其涉及资金和敏感信息时，这一条能挡掉绝大多数损失。

顺带说一句：别只做员工教育，也给自己留个「被冒充」预案

日经这次的处理方式值得抄：第一时间改密、逐一通知全部收件人、公开通告、上报监管、并预告后续可能的冒充风险。对一个组织来说，「我的账号被拿去冒充我」这件事，早晚要面对，提前想好对外沟通口径、通知流程和联系窗口，比事后手忙脚乱强得多。

小结

这次事件如果只当成「日经被钓鱼了一次」来读，会错过它最有价值的部分。三条结论：

• 打的是账号，不是系统。日经一年内四次事件，Slack、M365、Google Workspace 轮着中招，入口不同、落点相同——拿到一个真实员工的登录态；
• 「真账号」发出的钓鱼邮件，能穿透 SPF/DKIM/DMARC 三件套。外发环节验不出来，就必须在账号环节用 MFA 和异常登录检测拦住；
• 单点账号失守，代价是整张信任网络的暴露。约 9000 封邮件的收件人是记者多年的采访关系，泄露的邮件正文可能触及信源安全——这也是为什么日经要反复强调「不涉及取材对象信息」。

对国内团队来说，这件事的成本最低的起手式还是那三样：给邮箱和后台开二次验证、给外发量设阈值告警、别提「熟人邮件就不会是钓鱼」这种老观念。

另外提醒一句：如果你或你的同事近期收到声称来自日本经济新闻社及相关人员的邮件，不要点击其中链接，可通过其官网公告页面公布的官方咨询表单核实。

数据来源与说明：本文事实依据日本经济新闻社官网两份正式通告（《サイバー攻撃による情報漏洩、不審メールの送信について》，2026 年 10 月 4 日；《不正ログインによる情報漏洩について》，2026 年 10 月 4 日），并交叉核对 IT之家、共同社、《The Cyber Express》、《Daily Security Review》、《BigGo Finance》等公开报道。历史事件依据日经官网此前的三份公告：Slack 事件（2025 年 11 月 4 日）、日经美国社 M365 事件（2026 年 5 月 7 日）。两起事件是否关联、攻击者身份及最终影响范围，以日经及日本个人信息保护委员会的调查结果为准。