2026 年 4 月にはてな (3930) で発生した最大 11 億 7,900 万円の資金流出事案について、同社は 6 月 12 日、この被害額を 2026 年 7 月期第 3 四半期の特別損失として計上すると発表した。通期純損益は 1 億 100 万円の黒字予想から、7 億 6,700 万円の赤字へ下方修正されている。中堅 IT 企業が BEC (ビジネスメール詐欺) 一発で年度赤字に転落する、日本では稀に見るインパクトの事案だ。
何が起きていたか — 「虚偽の送金指示」が刺さった経路 #
4 月 21 日に取引銀行から不審送金の通知を受けて発覚。調査の結果、4 月 20〜21 日に 社内の従業員が外部口座への送金を複数回実行していたことが判明した。担当者はその時点で、社内の権限者からの送金指示だと信じていたという。
実態は、攻撃者がメールや社内ツールを介して経営層になりすまし、「至急・秘密に・今日中に」のいわゆる CEO フラウド型 BEC の典型パターンに合致する。なお本事案で 顧客データや個人情報の漏洩は無い ことが公式に確認されており、あくまで「会社の銀行口座から金が出ていった」インシデントだ。
なぜ「単一者送金」が成立したのか #
発生時の保有現預金は約 17.8 億円。そのうち 11.8 億円が一連の流れで外部口座へ流出している。これは攻撃手口の巧妙さでは説明がつかない。
コールバック 確認が運用に組み込まれておらず、担当者の判断だけで送金が通った。ハッカー視点 — 攻撃者は技術ではなく "稟議の流速" を狙う #
BEC は技術的にはほぼ何もしていない。マルウェアもゼロデイも不要で、攻撃者が突くのは「社内稟議のスピード感」と「上長指示への忖度」という、極めて人間的な経路だ。XDR や EDR は当然反応しない。
防御は業務フロー側に置くしかない。一定額以上の振込は 2 名以上承認を物理的に強制する。送金指示は登録済み番号への折り返し確認を例外なく必須化する (メール内の番号は使わない)。不定期な大口送金にリアルタイムアラートを仕込む — これは銀行 API でも自社内部でも実装可能だ。11.8 億円は結果論で、本質は「承認導線が単一者で閉じていた」設計の問題。製品ではなく経理フローを棚卸ししたい好機と言える。
COMMENTS 0
No comments yet — be the first to leave one.