ビデオ会議の出席者全員がAI偽物だった「英Arup 38億円送金事件」と3秒音声クローン・BEC（偽振込先変更）対策

保有していた株を勝手に売られて見知らぬ外国株などを買わされる被害が急増しました。

【急増問題②：街中のポスターや駐車場の『偽QRコード重ね貼り（クイッシング）』】メールのURLを警戒する人が増えたため、犯人はコインパーキングの精算看板やイベントチラシの本物のQRコードの上に「偽のQRコードシール」を貼り、スマホで読み取らせて偽のカード決済画面へ誘導する手口を広げています。

【急増問題③：『＋（プラス）』から始まる国際電話とニセ警察ビデオ通話】スマホに「+1」や「+44」などから始まる着信があり、出ると自動音声や警察官を名乗る人物から「あなたの口座が犯罪に使われている」とLINEへ誘導され。

偽の警察手帳や逮捕状画像を見せて資産を振り込ませる手口が20代〜30代の若い世代でも急増しています。

【急増問題④：SNSの『ホワイト案件・即日高収入』を装う闇バイト】SNSで「書類を運ぶだけ」「簡単なデータ入力」と募集し、応募時に運転免許証や自宅・家族の情報を送らせたあとで「自宅に行くぞ」と脅迫して強盗や詐欺の受け子に加担させる卑劣な犯罪です。警察庁は「応募して身分証を送ってしまっても。

犯罪をする前に #9110 へ相談すれば必ずあなたと家族を保護する」と呼びかけています。

メールへの返信で確認すると犯人が「はい、間違いありません」と返してくるため、**必ず『従来の台帳に登録されている電話番号』へ電話をかけて確認する**ルールを徹底してください。

【職場の危機②：パソコンのファイルが開けなくなり英語の脅迫文が出た（ランサムウェア感染）】この瞬間、焦って「パソコンの電源を切って再起動する」のはNGです（メモリ上の証拠が消えたり、再起動時に暗号化がさらに進んだりすることがあります）。正解は**『電源は切らずに。

直ちにLANケーブルを抜く（またはWi-FiをOFFにする）』**ことです。

【職場の危機③：社内から不審なメールが取引先へばら撒かれた】社員のID・パスワードが盗まれたサインです。直ちに該当アカウントのパスワード変更と「全セッションの強制ログアウト」を行い、お助け隊窓口や専門機関へ連絡します。

さらに近年では、社長や取引先の声・顔映像をAIでそっくりに合成する「AIディープフェイク音声・ビデオ通話」を使った緊急送金詐欺や、職場・家庭で長年放置された古いWi-Fiルーター・VPN機器を乗っ取って攻撃の踏み台（ボットネット）にする被害も急増しているため、送金指示は必ず既存の登録電話番号への折り返し（コールバック）で確認し、サポート終了ルーターは速やかに更新することが重要です。

動が混乱したこと」の3点に集約されます。

経営層が事前に確立しておくべき絶対原則は、『いかなる場合も犯罪組織へ身代金（ランサム）を支払わない』という方針と、それを裏付ける『不変スナップショット（OpenZFS等）による数分〜数時間での自律復旧体制』です。

身代金を支払ってもデータが完全に戻る保証はないばかりか、犯罪組織への資金提供（反社会的勢力・制裁対象組織への利益供与リスク）となり、再標的化される確率が高まるため、事前のバックアップ隔離に投資する方が100倍合理的です。

犯人が使用しているのは、EvilginxやModlishkaなどに代表される『AiTM（Adversary-in-the-Middle：中間者リバースプロキシ）フィッシングキット』です。

従来のフィッシングサイトは単なる偽のHTMLフォームでしたが、AiTMプロキシは「被害者と正規の証券会社・クラウドサーバーの間に割り込む中継サーバー」としてリアルタイムに動作します。

被害者が偽ドメイン（例：`login-sec-example.com`）にアクセスしてID・パスワードと6桁のワンタイムパスワードを入力すると、AiTMプロキシはそれを即座に背後の正規サーバー（`example.co.jp`）へ転送し。

正規サーバーが発行した「認証済みセッションCookie」を横取り（Session Hijacking）します。

これにより、たとえ6桁の数字が30秒で変わるワンタイムパスワードであっても、その30秒以内に自動中継されるため構造的に無力化されてしまいます。

このAiTM攻撃を構造的に無力化できる唯一の標準技術が『FIDO2 / WebAuthn（パスキー）』です。パスキーではブラウザ自身が現在開いているURLのオリジン（`https://login-sec-example.com`）を暗号学的にハッシュ化して署名に含めるため。

AiTMプロキシがそれを正規サーバー（`https://example.co.jp`）へ中継しても、オリジン不一致として数学的に100%拒絶されます。

現代のランサムウェア攻撃は、単にファイルを暗号化するだけでなく、暗号化を開始する直前に必ず①バックアップの破壊（`vssadmin.exe delete shadows /all /quiet`、`wmic shadowcopy delete`。

`bcdedit /set {default} recoveryenabled No`）、②ネットワーク上のNASや共有フォルダの列挙・暗号化、③脆弱な署名付きドライバを悪用したEDRプロセスの強制停止（BYOVD：Bring Your Own Vulnerable Driver）を実行します。

したがって、Windowsサーバー自身のローカル機能（ボリュームシャドウコピー：VSS）や、Active Directoryのドメイン管理者権限でアクセス可能なNASは、攻撃者にとって「最初の数秒で消去できる対象」に過ぎません。

これを完全に防ぐアーキテクチャが、Windows/ADドメインから物理的・論理的に独立した **FreeBSD + OpenZFS ストレージ基盤（`db01.ok.st` 等）** を設置し、バックアップサーバー側から本番側へ読み取り専用でデータを引き抜く（Pull型レプリケーション）とともに。

取得したスナップショットに対してカーネルレベルで削除禁止ロック（`zfs hold`）をかける設計です。

【第1定理：FIDO2 / WebAuthn Level 3 における AiTM 不成立証明】正規の Relying Party オリジンを $O_{\text{legit}}$。

攻撃者の AiTM リバースプロキシオリジンを $O_{\text{aitm}} \neq O_{\text{legit}}$ とします。クライアントブラウザは TLS チャネル上で観測した実際の接続先オリジン $O_{\text{aitm}}$ を `clientDataJSON.origin` に記録し。

認証器（Authenticator）は $\text{rpIdHash} = \text{SHA-256}(\text{rpId}(O_{\text{aitm}}))$ を含むデータに対して秘密鍵 $sk_{O_{\text{aitm}}}$ で署名 $\sigma = \text{Sign}_{sk}(\t

ext{authData} \parallel \text{SHA-256}(\text{clientDataJSON}))$ を生成します。

攻撃者がこの $(\sigma, \text{authData}, \text{clientDataJSON})$ を正規サーバー $O_{\text{legit}}$ へ中継した場合。

①もし内容を改変しなければ $\text{rpIdHash} \neq \text{SHA-256}(\text{rpId}(O_{\text{legit}}))$ により決定論的に拒絶され。

②もし `origin` や `rpIdHash` を書き換えれば EUF-CMA（選択メッセージ攻撃下での存在的偽造不能性）

を満たす署名検証 $\text{Verify}_{pk_{O_{\text{legit}}}}(\sigma')$ が確率 $1 - \text{negl}(\lambda)$ で失敗するため。

AiTM攻撃の成功確率は暗号学的に無視可能（$\Pr[\text{AiTM}] = \text{negl}(\lambda)$）となります。

【第2定理：OpenZFS 128-byte `blkptr_t` Merkle Tree と $O(1)$ ロールバック不変性】OpenZFS において、ファイルシステムの全状態はルートブロック（`uberblock_t`）を根とする有向非巡回グラフ（Merkle DAG）として表現され。

各親ブロックポインタ（128バイト `blkptr_t`）は子ブロック自身の256ビットチェックサム $H(B_{\text{child}})$ を格納します。

Copy-on-Write（CoW）原則により、いかなる書き込みトランザクション（TXG）も既存ブロックを上書きせず新規ブロックを割り当てるため、過去のスナップショット時点 $t_s$ のルート `uberblock_t` が指す部分木 $T(t_s)$ はディスク上で完全に不変（Immutable）

に保たれます。したがって、仮に時刻 $t > t_s$ にランサムウェアが全ファイルに対して暗号化書き込みを行っても、時刻 $t_s$ の木 $T(t_s)$ へのポインタ切り替え（`zfs rollback`）はデータ量 $N$ に依存しない定数時間 $O(1)$ で完了し、データ損失はゼロとなります。