Windows

Microsoftがパワーユーザーとプロフェッショナル向けの定番ツール「Windows Terminal」に対し、大規模なビジュアルリデザインとUI刷新を予告した。具体的な変更内容はまだ全容が明らかになっていないが、「大きな」刷新と表現していることからも、単なる見た目のテーマ変更に留まらない内容になりそうだ。 Windows Terminalとは何か Windows Terminalは、PowerShell・コマンドプロンプト・WSL（Windows Subsystem for Linux）・Azure Cloud Shellなど、複数のシェルをタブ形式で統合して利用できるモダンなターミナルアプリケーションだ。2019年にMicrosoftがオープンソースとして公開して以来、開発者コミュニティで急速に浸透し、今やWindowsで本格的な開発・運用作業を行うエンジニアにとって欠かせないツールに成長した。 カスタマイズ性の高さ（フォント・配色・キーバインド・プロファイル管理）と、GPU描画による高速なテキスト表示が特徴。GitやDockerのCLI操作、Kubernetesの管理、Azureリソースの操作など、あらゆるコマンドラインシナリオで活躍している。 今回の「大幅刷新」で何が変わりそうか 今回のティーザーで示されているのは「ビジュアルの大幅リデザイン」と「視覚的なアップグレード」だ。Microsoftが近年推進しているFluent Design 2との統一感を強化し、Windows 11の全体的なUIデザイン言語に合わせた洗練されたルックアンドフィールになると見られる。 また、アクリル素材やWinUIベースのコンポーネントを取り入れた透過効果、アイコン刷新、パネル配置の見直しなども含まれる可能性がある。単なる見た目の変更だけでなく、ウィンドウ管理やペイン操作まわりの使い勝手にも手が入ることが期待される。 実務での活用ポイント 日本のエンジニア・IT管理者が押さえておくべきポイントを整理する。 開発者向け： WSL2と組み合わせたLinux開発環境をWindowsで整えているエンジニアにとって、ターミナルの視認性向上は長時間作業の疲労軽減に直結する 複数プロファイル（本番・開発・ステージング環境ごと）の切り替えUI改善は、誤操作防止にも貢献する フォント・配色の設定体験が洗練されると、チーム全体で共通設定を共有・標準化しやすくなる IT管理者・運用担当向け： PowerShell Coreを使った自動化・設定管理スクリプトの実行環境として日々使っているなら、UIの快適さは生産性に響く Windows Terminal自体はMicrosoft Storeまたはwingetで配布されており、更新管理は比較的容易。刷新版が出た際も迅速に展開できる プロファイル設定はJSON形式で管理されており、Gitで差分管理・チーム共有する運用を取り入れると環境の再現性が高まる 筆者の見解 Windows Terminalは、Microsoftが近年リリースしてきた開発者向けツールの中でも、特に「やって良かった」と胸を張れるプロダクトの一つだと思っている。オープンソース化による迅速な改善サイクル、実際の開発者ニーズに根ざした機能追加、そして使い続けるほどに馴染む設計——このアプローチは本来Microsoftが得意としてきたものだ。 今回のビジュアル刷新が単なるスキン替えではなく、実際の操作体験を底上げするものであれば、大いに歓迎したい。「見た目を変えました」だけで終わるのはさすがにもったいない。これだけのユーザーベースと開発リソースを持っているのだから、UI刷新のついでに長年要望が上がっているセッション復元機能や、より柔軟なレイアウト管理なども前進させてほしいところだ。 正直なところ、Windows Terminalを細かく追い続けることにどれだけ価値があるか、最近は考えることもある。しかし、毎日使うツールが磨かれることの積み重ねは、地味ながら確実に仕事の質を上げる。それがMicrosoftの本来の強みだったはずで、今回のリデザインがその再確認になることを期待している。 詳細な発表が楽しみだ。 出典: この記事は Microsoft teases a big Windows Terminal redesign and visual upgrade の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11の標準アプリに散在していたCopilot関連の機能・ボタン・参照箇所を、順次削除し始めた。NeowinをはじめとするWindowsメディアが伝えたこの動きは、「とりあえずAIを載せる」フェーズの終わりを示すシグナルかもしれない。 何が起きているのか Microsoftはここ数か月で、メモ帳（Notepad）などWindows 11付属の標準アプリに統合されていたCopilotへの導線・UI要素を削除するアップデートを配布し始めた。同社はこれを「有用ではないCopilot参照のクリーンアップ」と説明しており、全標準アプリを対象に段階的に適用される見込みだ。 追加されたのはほんの数か月〜1年前のこと。それが「不要」として撤去されているという事実が、今回のニュースの本質だ。 なぜこれが重要か 「AI統合＝価値」ではなかった 2023〜2024年にかけて、MicrosoftはあらゆるWindows機能にCopilotを組み込もうとしていた。これ自体は戦略的には理解できる判断だった。しかし実際には、多くの統合が「使われない機能」として画面を占有するだけだった。 今回の削除は、ユーザーエクスペリエンスのフィードバックに真摯に応答した結果ともいえる。フォームファクターや文脈に合わないAI統合は、便利どころか邪魔になる——この単純な教訓を、世界最大級のOS企業が公式に認めた格好だ。 整理は「後退」ではなく「精度向上」 機能の削除を後退と捉えるのは早計だ。むしろ「どこにAIを置くと本当に価値が生まれるか」を再定義するプロセスと見るべきだろう。不必要な統合を外し、真に機能する場所にリソースを集中させる——ソフトウェアの成熟として評価できる動きだ。 実務への影響 IT管理者向け: 特にエンタープライズ環境ではCopilot機能の可用性をポリシーで制御していた組織もある。アップデート後にUIが変わることがあるため、ヘルプデスクへの問い合わせが発生するリスクがある。主要な標準アプリのUI変更をリリースノートで事前確認しておきたい。 エンジニア向け: Windows標準アプリのUIに依存したRPA・自動化スクリプトを運用しているなら、今後のアップデートでボタン位置や要素構造が変わる可能性に注意。テスト環境での事前確認サイクルを見直しておく価値がある。 一般ユーザー向け: アプリが以前より「シンプルになった」と感じたとしたら、それはバグではなく意図的な変更だ。Copilotを積極的に使いたいユーザーには、専用のCopilot UIからアクセスする形に収束していくと思われる。 筆者の見解 Copilotが登場してから、私はずっと「もったいないな」という思いを持ち続けてきた。Microsoftが持つ技術力、Azureのインフラ、Officeの深い統合基盤——これほどの資産を持っている会社がAIを届けようとしているのだから、本来ならば圧倒的な体験を作れるはずなのだ。 だからこそ、「とりあえず全部に載せる」アプローチには失望感があった。メモ帳にCopilotボタンが現れたとき、多くのエンジニアが「これは本当に必要か？」と感じたのは私だけではないはずだ。 今回の整理は、その問いへの答えを出した形だ。遅すぎた感はあるが、正しい方向への修正には違いない。大切なのは「どこに統合するか」を徹底的に考え抜くこと——ユーザーの実際のワークフローの中で自然に機能するAIこそが、長期的に価値を発揮する。 Microsoftにはまだそれを実現できる力がある。今回の一歩が、次の精度の高い展開への布石になることを期待したい。「この撤退の話が古いニュースになる日」を楽しみにしている。 出典: この記事は Microsoft begins removing Copilot from Windows 11 apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのCopilot利用規約に、今も「エンターテインメント目的のみ（entertainment purposes only）」という文言が残っていたことが、Redditユーザーによって発見され話題となった。「重要な事項にはCopilotを信頼するな」「自己責任で使用せよ」——いずれも太字で記載されたその文章は、「AIでビジネスを変革する」というMicrosoftの主張と真っ向から矛盾するように見える。 Microsoftの釈明——「Bing Chat時代の古い表現」 Microsoftはこの問題を指摘されると、「エンターテインメント目的という表現は、CopilotがBing Chatとして検索補助サービスの一環で提供されていた頃の名残だ。製品の進化に合わせて近日中に修正する」と回答した。 確かに、法的文書に古い表現が残ることはどの企業でも起こりうる。ただ、今回のケースは単純な「表現の更新漏れ」として片付けにくい面がある。現在もその文書は公開されたままであり、そこには「信頼するな」「自己責任で」という表現が明記されている。AIへの社会的関心が高まるなかで、こうした文書管理の精度は企業の信頼性を直接左右する。 現在のCopilotは何ができるのか Microsoftは現在、Copilotに対してさまざまな機能を追加している。長文テキストからのポッドキャスト生成、ドキュメントの整形・要約、さらにはWindows 11の操作補助など、生産性向上を前面に打ち出している。Microsoft 365 Copilotに至っては、ExcelやPowerPointを横断した作業支援において、実際に業務効率の改善を実感しているユーザーも多い。 一方、個人向けのCopilot（コンシューマー版）については評価が分かれる。ネイティブコードではなくWebViewベースに変更されて以降、使い勝手の面での不満も聞こえてくる。 市場での立ち位置——数字が語る現実 SimilarWebなどの公開データを見ると、WebベースのトラフィックにおいてはスタートアップのPerplexityにも後れを取っているという指摘がある。もちろん、Windowsアプリ、Edge、Microsoft 365への統合など「計測が難しいチャネル」での利用は考慮されておらず、単純な比較はできない。しかし、単独プロダクトとしての求心力という点では、まだ課題が残る状況だ。 実務への影響——IT管理者・エンジニアへのヒント 1. 利用規約の定期確認を習慣に クラウドサービスの利用規約は、サービスの進化に伴って改訂されることが多い。Copilotに限らず、組織で採用しているAIツールの規約は定期的に確認し、実際の用途との乖離がないか把握しておきたい。 2. 期待値のコントロールがカギ 「AIが何でもやってくれる」ではなく、「何が得意で何が苦手か」を把握したうえで使う。Microsoft 365 CopilotをOfficeとの連携タスクに絞って使う、といった「用途を限定した活用」が現時点では安定した成果につながりやすい。 3. コンシューマー版と企業向けは別物と考える 個人利用のCopilotと、Microsoft 365に統合されたエンタープライズ向けCopilotでは、機能・品質ともに差がある。組織導入を検討する際は、コンシューマー版の印象だけで判断しないことが重要だ。 筆者の見解 今回の一件で感じたのは、「惜しい」という言葉に尽きる。 MicrosoftにはAIを真剣に業務へ組み込む技術力も、ユーザーベースも、エコシステムも揃っている。それだけのポテンシャルがあるからこそ、「利用規約の表現が更新されていなかった」という話が余計に目立ってしまう。 製品の信頼は、機能の多さよりも、細部の一貫性から生まれる。法的文書に「娯楽目的のみ」と書いておきながら「ビジネスのあらゆるユースケースに対応」とアピールするのは、ユーザーへのメッセージとして整合がとれていない。Microsoftほどの組織であれば、製品メッセージとドキュメントのライフサイクル管理を一体で動かせるはずだ。 消費者向けCopilotの体験向上は、短期的な数字の競争以上に、「AIを信頼して使ってもらえるか」という長期的な土台を作る話だ。そのことを、Microsoftは誰よりもよく理解しているはずだと信じたい。Copilotが「過去の批評」として笑い飛ばされる日が来ることを、引き続き期待している。 出典: この記事は Microsoft denies Copilot is only for entertainment purpose, after its own document says do not trust AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはWindows 11のホットパッチ更新プログラム「KB5077212」および「KB5079420」を適用したシステムで、「このPCをリセット」機能が正常動作しなくなる不具合を公式に認めた。影響を受けるのはWindows 11 25H2および24H2のシステムで、Microsoftは暫定的な回避策を案内している。 ホットパッチとは——再起動不要の新しいパッチ配信モデル ホットパッチ（Hotpatch）は、Windowsを再起動せずにセキュリティ更新を適用できる仕組みだ。従来の累積更新プログラムはシステム再起動が必要で、稼働中の端末に適用するにはユーザーや管理者が再起動タイミングを調整しなければならなかった。ホットパッチはそのダウンタイムを実質ゼロに近づけるアプローチであり、サーバー管理の分野では以前から使われてきた考え方のクライアントOS版といえる。 Microsoftは2026年5月11日以降、Windows 11 24H2以降の環境でホットパッチをデフォルト有効化すると予告しており、IT管理者の間で注目が集まっていた。そのタイミングで今回の問題が表面化した。 何が起きたか KB5077212とKB5079420を適用したシステムでは、設定アプリから「このPCをリセット」を実行しようとすると処理が途中で止まる、またはエラーが発生するという症状が報告されている。 PCリセットは単なる「初期化ボタン」ではない。端末の廃棄・転用・リカバリー・セキュリティインシデント後の初期化など、IT運用の現場で欠かせない機能だ。特に法人端末の管理においては、ライフサイクル管理の核心に直結する。 MicrosoftはKnowledge Baseを更新して本不具合を公式認定し、回避策として通常の累積更新プログラム（フル更新）を適用することで問題が解消されると案内している。 実務への影響——管理者がすぐ確認すべきこと 影響確認のチェックリスト： 管理下の25H2・24H2端末でKB5077212またはKB5079420が適用済みか確認する 廃棄・転用・リカバリー作業は、フル更新（累積更新プログラム）適用後まで保留にする Microsoft Intuneでホットパッチポリシーを展開している場合は、更新リングの設定見直しを検討する Windowsオートパイロットリセット（Autopilot Reset）を利用している環境は特に注意 5月のデフォルト有効化を前にして： ホットパッチが標準機能として広まる前に、テスト環境での動作確認フローを整備しておくことが今まで以上に重要になった。特にPCリセットを定期メンテナンスに組み込んでいる教育機関・コールセンター・シンクライアント運用環境では、展開前検証を省略してはならない。 筆者の見解 ホットパッチの思想そのものは正しい。再起動なしでセキュリティパッチを適用できることは、可用性とセキュリティの両立という観点から大きな価値がある。この方向性を推進しているMicrosoftのアプローチは素直に評価したいし、5月以降の標準展開にも期待している。 だからこそ、PCリセットという基本機能への影響を見落とした状態でリリースされてしまったのは「もったいない」と感じる。障害対応・端末廃棄・再イメージングといった現場の実務に直結する機能だ。ホットパッチは正面から勝負できる技術的な土台がある。それだけに、品質保証プロセスにさらに力を注いでほしいと思う。 Windows Updateで「数日様子を見てから適用する」という判断が求められる場面は、以前と比べて増えてきた実感がある。今回も結果としてその慎重さが正解だった事例になってしまった。ホットパッチ対応環境が広がっていく中で、こういった不具合が積み重なると、せっかく評価が高まってきた新しい配信モデルへの信頼が揺らいでしまう。MicrosoftにはぜひKnowledge Baseの迅速な更新とともに、根本的な品質改善で応えてほしい。 出典: この記事は Microsoft confirms Windows 11 KB5077212, KB5079420 break PC reset on 25H2 and 24H2 systems の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windowsのカーネル（OS核心部）には、長年にわたり悪用され続けてきた「抜け穴」が存在していた。2026年4月、Microsoftはついにその穴を塞ぐ重要なセキュリティ変更を展開する。古いドライバー署名方式への信頼を終了し、公式の Windows Hardware Compatibility Program（WHCP）による認定ドライバーのみをデフォルトで許可するというものだ。地味に見えるが、現場への影響は決して小さくない。 問題の背景——「クロス署名プログラム」とは何だったか 2000年代初頭、Microsoftはサードパーティ製ドライバーをWindowsカーネルに組み込む仕組みとして「クロス署名ルートプログラム（Cross-signed Root Program）」を導入した。外部の認証局（CA）がドライバーの署名を行うこの仕組みは長年の標準だったが、致命的な弱点を抱えていた。セキュリティチェックが緩く、署名鍵が盗まれたり悪用されたりするケースが相次いだのだ。 攻撃者はこの仕組みを利用し、正規の署名をまとった悪意あるドライバーをカーネルに読み込ませることができた。カーネルに侵入されれば、セキュリティソフトウェアすら無効化される。EDR（Endpoint Detection and Response）製品をドライバーレベルで無効化する攻撃は、実際にランサムウェアグループが採用してきた手口だ。 Microsoftは2021年にこのプログラム自体を廃止した。しかし廃止後も、既存の古いドライバーはWindowsで引き続き受け入れられていた。今回の変更はその「遺産」に対する最後の決着となる。 新ポリシーの仕組み——「評価モード」から段階的に移行 新しいカーネル信頼ポリシーでは、WHCPを通じてMicrosoftが直接審査・承認したドライバーのみがデフォルトで信頼される。マルウェアチェックや互換性検証を含む審査プロセスを経ることで、サプライチェーン経由でのカーネル汚染リスクが大幅に低下する。 ただし移行は即時ではなく、段階的に行われる。具体的には次のような「評価モード」が設けられている： 評価期間中：カーネルはすべてのドライバー読み込みを監査・記録するが、ブロックはしない 移行条件：累計100時間の稼働かつ3回以上の再起動が完了すること 条件クリア後：旧クロス署名ドライバーが一切検出されなければ、新ポリシーが自動的に有効化される 非互換が検出された場合：評価モードのままリセットされ、移行は先送りされる Microsoftはこの判断に、過去2年間で数十億件のドライバー読み込みから収集したテレメトリデータを活用しているという。現場の実情を踏まえた段階的なアプローチは、現実的で評価できる。 実務への影響——IT管理者が今確認すべきこと この変更がとくに影響するのは、以下のようなシナリオだ： 古い周辺機器・産業機器を使っている環境：特定のプリンターやスキャナー、工場系の制御機器などで古いドライバーが使われている場合、評価モードが延長されるか、最悪の場合デバイスが利用不能になる可能性がある。今のうちにベンダーに問い合わせ、WHCP対応ドライバーへの更新可否を確認しておくべきだ。 エンドポイントセキュリティ製品：EDRやDLP（データ損失防止）製品の一部はカーネルドライバーを利用する。大手ベンダーは対応済みのケースが多いが、バージョンによっては問題が生じることもある。事前に動作確認を行っておきたい。 Intune / Windows Update for Business 管理環境：管理対象のデバイスで評価期間がどのように扱われるか、マイクロソフトの公式ドキュメントを追っておくことを推奨する。特例ポリシーの設定が可能かどうかも確認ポイントだ。 Windows 11 Home と Pro の差異：記事によれば、今回の変更は Windows 11 を対象としている。Windows 10 環境の扱いについては引き続き情報を確認されたい。 筆者の見解 カーネルドライバーのセキュリティ強化という方向性は、間違いなく正しい。特権アクセスを悪用したドライバーベースの攻撃は、EDRをすら無効化できる手口として長く問題視されてきた。「信頼できると証明されたもの以外は許可しない」というゼロトラストの思想をカーネルレベルに持ち込む今回の対応は、セキュリティアーキテクチャとして筋が通っている。 2021年にプログラムを廃止してから約5年、既存ドライバーへの後方互換性を保ちながら段階的に移行するという判断も現実的だ。「今日すぐ全部ブロックする」ではなく、評価モードを通じて互換性の問題を事前に炙り出すアプローチは、現場への影響を最小化しようという配慮が感じられる。 一方で気になるのは、こういった地道なセキュリティ強化がなかなか目立たないことだ。派手な新機能と違い、カーネル信頼ポリシーの変更は語りにくい。しかし実際のセキュリティリスクを下げる観点では、こうした基盤部分の改善こそ本質的な価値がある。Windowsはこのような地道な強化の積み重ねで着実に堅牢になってきた。その事実は、公平に評価されるべきだと思う。 現場の管理者にとっては、「5月に突然デバイスが動かなくなった」という事態を避けることが最優先だ。古いドライバーを使う機器の棚卸しと、ベンダーへの確認を今のうちに済ませておくことを強くすすめる。 出典: この記事は Windows is finally fixing a years-old security hole in April の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Adobe Readerにゼロデイ脆弱性が存在し、少なくとも2025年12月から現在に至るまで、実際の攻撃に使われ続けていることが明らかになった。サンドボックス型エクスプロイト検出プラットフォーム「EXPMON」の創設者であるセキュリティ研究者Haifei Li氏が発見し、公表したもので、現時点でAdobe側からのパッチはまだリリースされていない。 何が起きているのか 今回の脆弱性の最も恐ろしい点は、ユーザーがPDFを開く以外の操作を一切必要としないことだ。リンクをクリックする必要も、マクロを有効にする必要もない。ただ、メールに添付されたPDFをいつもどおり開くだけで感染が成立しうる。 この攻撃は「フィンガープリント型エクスプロイト」と呼ばれる高度な手法を採用している。まず被害者の環境情報を収集・識別し、その後に追加の攻撃（リモートコード実行＝RCE、サンドボックス脱出＝SBX）へと展開する多段階の仕組みになっている。情報収集に使われているのはAcrobat内部の特権API（util.readFileIntoStreamおよびRSS.addFeed）であり、本来PDFアプリケーションに用意されている機能が悪用されているのが技術的な肝だ。 ロシア語のおとり文書と標的 脅威インテリジェンスアナリストのGi7w0rm氏が分析したところ、攻撃に使われたPDF文書にはロシア語の内容が含まれており、ロシアの石油・ガス産業に関連する時事的な話題を装っていることが確認されている。これは標的が比較的絞り込まれていることを示唆しており、無差別なばら撒きではなく、特定の組織や業界を狙ったターゲット型攻撃の可能性が高い。 とはいえ、脆弱性の仕組み自体はAdobe Readerの最新バージョンで動作するものであるため、攻撃が転用・拡散される前に対策を取ることが重要だ。 実務での対応ポイント パッチがまだない以上、今すぐ取れる対策は以下の通りだ。 エンドユーザー向け 信頼できない送信元からのPDFは、パッチリリースまで絶対に開かない 特に、業務上覚えのないPDFメールには最大限の警戒を Adobe Readerの自動アップデートを有効にしておき、パッチが出たら即座に適用できる状態にしておく IT管理者・ネットワーク担当者向け HTTPおよびHTTPSトラフィックのUser-Agentヘッダーに "Adobe Synchronizer" という文字列が含まれる通信を監視・ブロックする（Li氏が推奨する緩和策） プロキシやエンドポイント保護製品でこのシグネチャを追加設定することで、通信段階での遮断が可能 EDR（エンドポイント検知・対応）製品のアラートを強化し、Adobe Readerプロセスから不審なネットワーク接続や外部ファイルアクセスが発生していないか監視する ゼロトラスト観点での補足：今回の攻撃はネットワーク境界を突破するものではなく、信頼された内部アプリケーション（Adobe Reader）を踏み台にする手法だ。境界型セキュリティだけでは検知が難しく、アプリケーション層・プロセス層での振る舞い監視が有効性を発揮する場面だ。 筆者の見解 ゼロデイ脆弱性の4ヶ月間放置という事実は、改めてパッチ管理の難しさを突きつける。Adobeの対応スピードについては、公表後の動向を引き続き注視したい。 それ以上に気になるのは構造的な問題だ。「PDFを開く」という日常業務の動作が攻撃面になる以上、ユーザー教育だけでの防御には限界がある。エンドポイント上でのアプリケーション挙動監視と、ネットワーク通信ログの突合による異常検知の組み合わせが、こうした未知の脅威に対して実効性を持つ。 今回の「フィンガープリント型」という手口も興味深い。攻撃者は被害者を識別してから次の段階に進む——つまり、単に悪意あるコードを実行するだけでなく、標的の価値を確認した上で追加投資するかどうかを判断している。高度なAPT（持続的標的型攻撃）に見られる特徴で、無差別ばら撒きとは一線を画す。 パッチが出るまでの間、Haifei Li氏が公開した緩和情報は現時点での最善策だ。「今動いているから大丈夫」ではなく、「まだ動いているが今日はやられるかもしれない」という感覚で臨みたい。 出典: この記事は Hackers exploiting Acrobat Reader zero-day flaw since December の内容をもとに、筆者の見解を加えて独自に執筆したものです。

欧州旅行者に人気の鉄道パスサービス「Eurail」が、2025年12月末に発生した不正アクセスの詳細を明らかにした。被害を受けた個人は308,777人に上り、氏名・パスポート番号・銀行口座IBAN・健康情報・連絡先など、本来なら最も厳重に保護すべき情報が根こそぎ持ち出されたことが確認されている。 何が起きたのか 2025年12月26日、攻撃者がEurailのネットワークに侵入し、ファイルを外部に転送した。Eurailが侵害の事実を公表したのは2026年2月、そして影響を受けた個人への通知が行われたのは3月27日のことだ。発覚から通知まで約3か月を要したことになる。 窃取されたとされる情報の内訳は以下のとおりだ。 氏名・パスポート番号 銀行口座のIBAN（国際銀行口座番号） 健康情報 メールアドレス・電話番号 Eurailは「財務情報やパスポートの写真コピーは侵害されたシステムには保存していなかった」と説明しているが、欧州委員会（European Commission）は別途アラートを発出。EU の「DiscoverEU」プログラム経由でパスを取得した若い旅行者については、健康情報を含む一段広い情報が露出した可能性があると警告している。 窃取されたデータはTelegramで一部サンプルが公開され、ダークウェブ上での売買も試みられていることが確認された。 被害の深刻さはどこにあるか この件で特に問題なのは、「組み合わせの凶悪さ」だ。氏名単体、あるいはメールアドレス単体が漏れた程度であれば、スパムへの警戒程度で済む。だが、氏名＋パスポート番号＋IBANが一組で揃ってしまうと話が変わる。 IBANはEU圏の銀行送金で使う口座識別子であり、不正なダイレクトデビット（口座引落）の試みに悪用されうる。パスポート番号と組み合わせれば、本人確認を伴う詐欺や、フィッシング攻撃の精度向上に使われる可能性が高い。健康情報が加われば、医療保険詐欺への応用も現実的な脅威となる。 実務への影響——エンジニア・IT管理者が取るべき行動 この事案は欧州の事業者が関係しているが、日本のIT現場にも直接的な示唆がある。 ユーザー向け（該当者） Rail Plannerアプリのパスワードを直ちに変更し、同じパスワードを使い回しているサービスでも同様に対処する 銀行口座の明細を定期的に確認し、身に覚えのない引落がないかモニタリングする 件名に「Eurail」「DiscoverEU」「鉄道パス」などを含むメールは、リンクをクリックする前に発信元を厳密に確認する システム設計・運用側の視点 「旅行者の健康情報や旅券情報を同一DBに平文で格納していた」という構造自体が今回の被害を拡大させた。センシティビティに応じたデータ分離と暗号化は、設計段階での必須要件だ DiscoverEUのような政府連携プログラムに個人情報を提供している場合、そのデータが第三者事業者のシステムにどのような形で保管されるかを契約・設計レベルで確認しておく必要がある 侵害検知から被影響者通知まで3か月を要したことは、インシデントレスポンス計画の成熟度を問う事例として参照する価値がある。日本企業でも「発覚したけど何をどの順番でやればいいかわからない」という状態のまま時間が経過するケースは少なくない 筆者の見解 セキュリティの話は細かい議論になりがちで、どちらかというと専門家同士の言い合いになってしまうことも多い。だが、今回のような事案は「技術論」に入る前に、「なぜ不要なデータを持ち続けていたのか」という根本的な問いに立ち戻る必要がある。 IBANや健康情報は、鉄道パスを販売するサービスとして本当に長期保管が必要なデータだったのだろうか。購入処理が完了した後も持ち続ける合理的な理由がなければ、そもそも保持しないというのが最善の防御だ。「攻撃者が盗めないデータは存在しないデータだけ」という原則は、ゼロトラストの文脈でも繰り返し語られてきた基本中の基本である。 日本のエンタープライズでも、気がつけば「いつか使うかもしれない」という理由で個人情報や認証情報がシステムのあちこちに散在しているケースは珍しくない。今回のEurailの事案を、自社のデータ棚卸しを見直す契機として活用することを強くお勧めしたい。 攻撃者が最初のアクセスを得た後、実際にファイルを転送するまでの間に何らかの制御が機能していれば被害は異なっていた可能性がある。ネットワーク層・認証層・認可層を複数重ねた多層防御と、異常なデータ転送を即座に検知するモニタリングの組み合わせ——地味ではあるが、それが「今動いているから大丈夫」という油断に対する唯一の現実的な答えだと思っている。 出典: この記事は Eurail says December data breach impacts 300,000 individuals の内容をもとに、筆者の見解を加えて独自に執筆したものです。

WordPressサイトの運営者・開発者にとって、プラグインのアップデートは「信頼できる行為」のはずだった。その前提が4月7日、根底から崩れた。 スライダー作成プラグイン「Smart Slider 3 Pro」の更新配信システムが第三者に乗っ取られ、バックドアを複数埋め込んだ悪意あるバージョン（3.5.1.35）が正規の更新として配布されたのだ。WordPress向けの無料版だけでも90万以上のサイトで使われているプラグインだけに、影響の広がりは無視できない。 何が起きたのか WordPressおよびJoomlaのセキュリティを専門とするPatchStackの分析によると、問題のバージョンに仕込まれたマルウェアは「完全機能を持つ多層型ツールキット」だという。プラグイン本体の機能は正常に動作したまま、バックドアだけが静かに動き続ける設計になっている点が特に悪質だ。 確認された攻撃機能 1. 認証なしリモートコード実行 HTTPヘッダーを細工するだけで、攻撃者はWordPressにログインすることなくPHPコードやOSコマンドを実行できる。これが最も危険な入口となる。 2. 隠し管理者アカウントの自動生成 wpsvc_というプレフィックスを持つ管理者権限ユーザーがデータベースに作成される。通常の管理画面には表示されない設計になっており、気づきにくい。 3. 多層的な永続化機構 攻撃の巧妙さが際立つのが、この永続化の仕組みだ。 mu-pluginsディレクトリにキャッシュコンポーネントを装ったファイルを設置。「Must-Use Plugin（必須プラグイン）」は管理画面から無効化できず、プラグイン一覧にも表示されない テーマのfunctions.phpに埋め込まれるため、テーマが有効な限り生き続ける wp-includesディレクトリにWordPressコアクラスを偽装したPHPファイルを設置。このバックドアは.cache_keyファイルから認証キーを読み込むため、データベースのパスワードを変えても無効化されない 4. 認証情報の窃取 サイト情報とログイン情報が自動的に外部へ送信される。 影響を受けるバージョンと推奨対応 ベンダーはバージョン3.5.1.35のみが対象と発表。対応は以下の通り。 汚染バージョンを使用していない場合: 3.5.1.36へ更新（または3.5.1.34以前のまま維持） 汚染バージョンを使用していた場合: サイト全体が侵害されたと仮定して行動する 侵害時の対応手順（必須）: 不正ユーザー・ファイル・データベースエントリの削除 WordPressコア・プラグイン・テーマを信頼できるソースから再インストール 全認証情報のローテーション（WordPress管理者・DB・FTP/SSH・ホスティング・メール） WordPressセキュリティキー（ソルト）の再生成 マルウェアスキャンとログレビュー バックアップ復元を行う場合は、タイムゾーンの差異を考慮して4月5日以前のバックアップを使用するようベンダーは推奨している。 実務への影響 IT担当者がすぐ確認すべきこと まず自社・顧客サイトで管理しているWordPress/JoomlaにSmart Slider 3 Proが導入されているか確認する。バージョンが3.5.1.35であれば、即座に侵害対応モードに入る必要がある。 管理しているサイトが多い場合は、WP-CLIで一括確認するのが効率的だ: 出典: この記事は Smart Slider updates hijacked to push malicious WordPress, Joomla versions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セッション盗難という「静かな脅威」に、Googleがハードウェアで応答した Googleは2026年4月、Chrome 146（Windows版）にDevice Bound Session Credentials（DBSC）を正式実装した。狙いはシンプルだ——インフォスティーラーと呼ばれるマルウェアによるセッションクッキーの窃取を、ソフトウェアではなくハードウェアの力で原理的に無効化すること。macOS版は追って対応予定とされており、今後のアップデートで順次展開される。 これはセキュリティ界隈の地味なアップデートに見えるかもしれないが、実際には「パスワードを知らなくてもアカウントに侵入できる」という長年の攻撃手法に対する、構造的な回答である。 なぜセッションクッキーが狙われるのか Webアプリケーションでは、ログイン後にサーバーが発行するセッションクッキーが認証トークンとして機能する。有効期限が来るまでの間、このクッキーさえあればパスワードなしで認証が通る。 問題は、このクッキーがローカルのファイルやメモリに保存される点だ。LummaC2をはじめとするインフォスティーラー型マルウェアは、こうしたデータを組織的に収集してC2サーバーへ送信する手口を洗練させてきた。多要素認証（MFA）を突破しなくても、セッションを「そのまま使い回す」ことで正規ユーザーになりすませてしまう。 Googleが公式見解として「ソフトウェアだけではクッキーの流出を防ぐ信頼できる手段がない」と明言しているのは、この構造的な弱さへの正直な認識である。 DBSCが解決する仕組み DBSCは、セッションをデバイスのセキュリティチップに暗号的にバインドするプロトコルだ。WindowsではTPM（Trusted Platform Module）、macOSではSecure Enclaveが使われる。 仕組みの要点は以下のとおり： セッションごとに固有の公開鍵/秘密鍵ペアをセキュリティチップが生成する 秘密鍵はチップ外にエクスポートできない 新しいセッションクッキーの発行には、Chromeがサーバーに対して「この秘密鍵を保持している」ことを証明する必要がある 秘密鍵を持たない攻撃者がクッキーを盗み出しても、すぐに無効化される 設計上、プライバシーへの配慮もある。セッションごとに異なる鍵を使うことで、複数サービス間での行動追跡に利用されない構造になっている。サーバー側へ送信されるのはセッションごとの公開鍵のみで、デバイス識別情報は含まれない。 このプロトコルはGoogleとMicrosoftが共同開発し、W3Cでオープン標準として策定が進む。Okta等との実証実験では、セッション盗難の件数が顕著に減少したとGoogleは報告している。 日本のエンジニア・IT管理者にとっての実務的意味 管理者が今すぐやるべきこと Chrome 146以降への更新管理を確認する: Intune・GPO等でバージョンポリシーを管理している組織では、DBSC有効化のためにChrome 146以降を対象バージョンに含める必要がある TPMの有効化状態を棚卸しする: DBSCはTPMに依存する。TPMが無効・未搭載のデバイスではこの保護が効かない。特に古い社用PCが混在する環境では要注意だ SaaSのDBSC対応状況を把握する: ウェブアプリ側もバックエンドに登録・リフレッシュ用エンドポイントを追加する必要がある。主要SaaSベンダーの対応ロードマップを確認しておきたい 開発者向けの視点 自社サービスでDBSCを実装する場合、GoogleのDBSC実装ガイドとW3Cの仕様書が公開されている。既存フロントエンドとの互換性を維持しつつ、バックエンドにエンドポイントを追加するだけで対応できる設計になっており、段階的な導入が可能だ。 注意点 DBSCはあくまでセッション盗難後の横展開を防ぐ仕組みであり、マルウェア感染そのものを防ぐものではない。エンドポイント保護（EDR等）との組み合わせが前提となる。「Chromeがアップデートされたから安心」という過信は禁物だ。 筆者の見解 セキュリティの話は正直に言えば得意分野ではないが、このDBSCのアプローチは技術的に筋が通っていると感じる。「ソフトウェアだけではクッキー流出を防げない」というGoogleの認識は、ゼロトラストの文脈で語られてきた「ネットワーク境界では守れない」と同じ構造的な問いへの誠実な回答だ。 TPMやSecure Enclaveといったハードウェアの信頼の根（Root of Trust）を利用してセッションをバインドする発想は、Just-In-Timeアクセスと同じ方向性を持つ。「常時使えるトークンではなく、特定の文脈でのみ有効な証明」という考え方は、特権アカウント管理の理想形に近い。 GoogleとMicrosoftがこのプロトコルを共同で開発し、W3Cで標準化を進めているのも重要な点だ。ベンダー固有の実装ではなくオープン標準として育てることで、SaaSエコシステム全体への普及が現実的になる。 一方で、展開には時間がかかる。TPMが普及していない古いデバイスが残存する環境、DBSCに未対応のSaaS、macOS版の対応待ち——現実の企業環境は「理想の状態」からはほど遠い。この技術が「当たり前の防御層」として機能するには、サーバーサイドの対応が広がるまで数年単位の時間軸で考える必要がある。 その間も、インフォスティーラーの攻撃は止まらない。DBSCを「将来の保険」として認識しつつ、今日できるEDRの強化・TPMの有効化・セッション有効期限の短縮といった対策を地道に積み上げることが、現実的な判断だと思う。 出典: この記事は Google Chrome adds infostealer protection against session cookie theft の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オランダの医療ITソリューション大手ChipSoftが、ランサムウェア攻撃の被害を受けた。同社の電子カルテ（EHR）プラットフォーム「HiX」はオランダ国内の多数の病院で採用されており、患者向けポータルやモバイルアプリを含む主要サービスが緊急停止を余儀なくされた。複数病院で業務への影響が確認されており、医療分野を狙ったサプライチェーン攻撃の典型的な事例として世界中の医療IT関係者に衝撃を与えている。 何が起きたのか ChipSoftは電子カルテシステム「HiX」をオランダ国内の病院に広く提供している。今回の攻撃で同社は「不正アクセスの可能性」を記載した内部メモを医療機関向けに配布し、接続を一時切断するよう呼びかけた。 対応措置として以下のサービスが停止された： Zorgportaal（患者向けポータル） HiX Mobile（モバイルアプリ） Zorgplatform（医療連携プラットフォーム） オランダの医療サイバーセキュリティ対応チーム「Z-CERT」がランサムウェア感染を公式確認し、ChipSoftおよび関係医療機関と連携して影響範囲の特定と復旧支援にあたっている。Sint Jans Gasthuis、Laurentius、VieCuri、Flevo Hospitalなど複数の病院でシステム障害が報告されている。 なぜこれが重要か——医療ITは格好の標的 この種の攻撃が繰り返されるのには明確な理由がある。医療ITベンダーは単なるソフトウェア企業ではなく、複数の医療機関にまたがる情報ハブとして機能している。一点を突破するだけで、契約している全病院の患者データや業務システムへのアクセス経路を得られる可能性があるのだ。 先月も米国のCareCloudで同様のデータ侵害が発生し、3月にはCognizant傘下のTriZetto Provider Solutionsで340万人超の個人情報が流出した。医療IT分野でのサプライチェーン攻撃は、もはや「例外的な事件」ではなく常態化したリスクとして認識すべき段階に入っている。 実務への影響——日本の医療IT担当者が今すぐ確認すべきこと 日本においても、電子カルテや医療情報システムのクラウド化・SaaS化が急速に進んでいる。今回のChipSoft事案から学べる教訓は多い。 ベンダー接続のアクセス制御を見直す ベンダー側システムとの接続は、常時開放しているケースが少なくない。障害発生時に「切断してください」と言われてから対応するのでは遅い。Just-In-Time（JIT）アクセスの概念を取り入れ、必要なときだけ接続を許可する仕組みを構築しておくことが重要だ。 影響範囲を事前に把握しておく ベンダーのシステムが停止したとき、自組織のどの業務が止まるかを事前にマッピングしておく。BCP（事業継続計画）にSaaS・クラウドベンダーの障害シナリオを明示的に含めているか確認したい。 インシデント発生時の通知ルートを整備する ChipSoftは内部メモを医療機関に送付したが、情報到達に時間がかかった病院もあった。契約ベンダーからのインシデント通知を受け取るための連絡経路と、それを受けた際の初動手順を文書化しておこう。 ネットワーク・認証・認可の3層を独立させる ベンダー接続部分だけでも、ネットワーク層（セグメンテーション）、認証層（多要素認証）、認可層（最小権限）の3つを独立して制御できる構成にすることが、被害の横展開を防ぐ上で不可欠だ。 筆者の見解 医療分野でのサイバー攻撃報告が相次いでいる状況を見ていると、問題の本質は「個々の病院のセキュリティ意識」ではなく、SaaS依存のアーキテクチャにおけるリスク設計の甘さにあると感じる。 ベンダーを信頼すること自体は間違いではない。しかし「ベンダーが安全なら自分たちも安全」という前提は、現代の脅威モデルでは通用しない。ゼロトラストの考え方を突き詰めれば、「信頼できるネットワーク」も「信頼できるベンダー接続」も存在しない。すべての接続は疑ってかかり、最小限の権限で、必要な時間だけ許可する——その原則を医療IT分野でも本気で実装する時期が来ている。 日本の大規模医療機関では、レガシーなオンプレミス環境と新しいクラウドサービスが混在する複雑な構成が多い。その状況で「とりあえず動いているから大丈夫」という運用を続けるのは、リスクを積み上げているに等しい。今回のChipSoft事案を対岸の火事と見ずに、ベンダー接続の棚卸しと接続制御の見直しに着手するきっかけにしてほしい。 医療データは人命に直結する。それを預かる責任の重さに見合った防御をするのは、技術の問題である前に、姿勢の問題だと思う。 出典: この記事は Healthcare IT solutions provider ChipSoft hit by ransomware attack の内容をもとに、筆者の見解を加えて独自に執筆したものです。

経営幹部を狙うフィッシング攻撃は年々高度化しているが、2025年末から活動が確認されている「VENOM」は、従来の防御策の前提を根底から崩す仕組みを持つ。MFAを設定しているから安心——そう思っている企業のセキュリティ担当者に、今すぐ読んでほしい話だ。 VENOMとは何か：クローズドな攻撃基盤という厄介な特徴 VENOMはPhaaS（Phishing-as-a-Service）基盤、すなわち「フィッシング攻撃を外注できるサービス」として設計されている。ただし、よくある地下フォーラムでの公開販売は行っておらず、クローズドアクセスで運用されている点が研究者にとって厄介だ。アンダーグラウンドコミュニティへの露出が少ないため、通常の脅威インテリジェンスで捕捉しにくく、発覚が遅れやすい。 攻撃対象はCEO・CFO・VP等のC-Suiteに限定されている。ランダムなばらまきではなく、特定個人をピンポイントで狙う「スピアフィッシング」に分類される。 攻撃チェーンの解剖：3つの巧妙な回避技術 1. UnicodeレンダリングのQRコード 攻撃メールはMicrosoft SharePointの共有通知を装い、高度にパーソナライズされている。QRコードをUnicode文字で描画することでスキャンツールによる検出を回避しつつ、攻撃をPCからモバイルデバイスへ移行させる。モバイルのブラウザはデスクトップに比べてURLバーの視認性が低く、フィッシングページを見分けにくいという特性を悪用している。 2. URLフラグメントへのターゲット情報隠蔽 ターゲットのメールアドレスはURLの#以降（フラグメント部分）にダブルBase64エンコードで格納されている。HTTPリクエストではフラグメントはサーバーに送信されない仕様のため、サーバーサイドのログやURL評価フィードには残らない。ログベースのセキュリティ監視を静かに回避する設計だ。 3. AiTM（Adversary-in-the-Middle）によるMFA突破 本攻撃の核心がここにある。フィッシングページはMicrosoftのログインフローをリアルタイムでプロキシし、入力された認証情報とMFAコードを即座にMicrosoft APIへ中継する。その結果、攻撃者はセッショントークンを取得する。MFAは「パスワード＋ワンタイムコード」を保護するが、このトークンはログイン完了後に発行されるため、MFAを通過した後の「正規のセッション」を横取りできる。 また、デバイスコードフィッシング手法も確認されている。被害者を騙して不正デバイスへのアクセス承認をさせることで、パスワードリセット後も有効なトークンを入手する。この手法は過去1年で37倍に増加しており、VENOMもそのトレンドを取り込んでいる。 実務への影響：「MFAで十分」という時代の終わり VENOMが示すのは、TOTP・SMS・認証アプリといった従来型MFAだけでは、AiTMフィッシングに対して防御不十分という現実だ。実務担当者が今すぐ検討すべき対策を以下に整理する。 ① FIDO2認証への移行 FIDO2（パスキー・YubiKey等）はフィッシングに対してフィジカルに耐性を持つ。デバイスとドメインが紐づく仕組みのため、偽サイトでは認証が成立しない。経営幹部・特権アカウントから優先的に移行を進めることを強く推奨する。 ② デバイスコードフローの無効化 利用していない場合は、Microsoft Entra ID（旧Azure AD）の条件付きアクセスポリシーでデバイスコードフローを無効化する。設定は 条件付きアクセス → 認証フロー → デバイスコードフロー から制御可能だ。 ③ 条件付きアクセスによるトークン悪用防止 トークン発行後の横展開を防ぐには、継続的アクセス評価（Continuous Access Evaluation）やサインイン頻度ポリシーの強化が有効だ。また、準拠済みデバイスからのアクセスのみを許可するデバイスコンプライアンスポリシーも合わせて設定したい。 ④ 経営幹部を対象としたセキュリティ意識トレーニング VENOMはC-Suiteを意図的に狙っている。高度にパーソナライズされたメールを経営幹部が見分けるのは難しいが、「QRコードを使ったMicrosoft認証要求には特別な注意を払う」という啓発は最低限実施しておきたい。 筆者の見解 ゼロトラストの文脈で言えば、「認証済みだから信頼する」という発想がそもそも危うい。VENOMのようなAiTM攻撃は、認証プロセス自体を通過してしまうため、認証後のセッションをいかに継続監視するかが問われる。継続的なアクセス評価と最小権限の徹底、そしてJust-In-Time（JIT）アクセス制御こそが、この種の攻撃に対する根本的な答えだ。 Microsoftのアイデンティティ基盤は、条件付きアクセスの柔軟性やFIDO2サポートなど、対策を打てる素材は揃っている。組織側が「MFAを入れたから終わり」と思考停止するのではなく、その先の一手を打つかどうかが分かれ目になる。デバイスコードフローの無効化などは設定1つでできる話なので、後回しにする理由はない。 クローズドな基盤で活動するVENOMは今後も静かに範囲を広げる可能性がある。「今のところ被害報告がない」で安心している組織ほど、気づかないまま標的にされているリスクを再確認してほしい。 出典: この記事は New VENOM phishing attacks steal senior executives’ Microsoft logins の内容をもとに、筆者の見解を加えて独自に執筆したものです。

台湾のNGO（非政府組織）や大学を標的にした、これまでにない設計思想を持つマルウェアが確認された。Cisco Talosが解析した「LucidRook」は、Lua言語のインタープリタを本体に内蔵するという構造上の工夫によって、高い隠蔽性と柔軟な攻撃能力を両立している。単なる情報窃取ツールにとどまらない、成熟した脅威アクターによる組織的な標的型攻撃（APT）として注目に値する。 LucidRookとはどんなマルウェアか LucidRookの最大の特徴は、Luaインタープリタを丸ごと内蔵したモジュラー設計にある。通常のマルウェアはバイナリ本体に機能を実装するが、LucidRookはLuaバイトコード形式で「第2ステージのペイロード」をC2（コマンド＆コントロール）サーバーから取得・実行する。これにより、攻撃者はコアのDLLを変更することなく、攻撃内容をターゲットごとに柔軟に差し替えられる。 また、LuaバイトコードはC2への配信後すぐに削除できるため、インシデントレスポンス時に「ローダーは入手できたがペイロードが回収できない」という状況を意図的に作り出せる。フォレンジック妨害を設計段階から組み込んでいる点が、このマルウェアを「成熟した脅威アクター」たらしめている。 感染チェーンの2パターン Cisco Talosは2025年10月の攻撃において、2系統の感染経路を確認している。 ① LNKファイル経由 パスワード付きアーカイブを添付したフィッシングメールから始まり、LNKショートカットファイルがドロッパー「LucidPawn」を展開。LucidPawnは正規のMicrosoft Edgeに見せかけた実行ファイルと悪意あるDLL（DismCore.dll）を配置し、DLLサイドローディングの手法でLucidRookを起動する。台湾政府からの文書を模した「おとりドキュメント」を同時表示することで、ユーザーの注意をそらす。 ② 偽セキュリティソフト経由 Trend Micro Worry-Free Business Security Servicesを偽装したEXEファイルを入口とするルート。セキュリティ製品そのものを騙ることで、ユーザーの警戒心を意図的に下げる設計だ。 偵察とデータ窃取の手口 感染後、LucidRookはユーザー名・コンピュータ名・インストール済みアプリ・実行中プロセスといったシステム情報を収集する。収集データはRSAで暗号化されパスワード付きアーカイブに格納されたうえで、FTP経由で攻撃者インフラへ送出される。 関連ツール「LucidKnight」も確認されており、こちらはGmailのGMTPプロトコルを悪用してデータを外部送信する。正規サービスをC2の代替として使う戦術は、ファイアウォールやプロキシによる検知を困難にする。 なぜこれが重要か 台湾のNGOや大学が標的となっているが、日本のIT現場にとっても対岸の火事ではない。 第一に、攻撃グループUAT-10362の「成熟した作戦能力（mature operational tradecraft）」という評価は、標的を絞った持続的な侵入を得意とするタイプであることを示す。研究機関・公益団体・サプライチェーン上流の企業は等しくリスクを負っている。 第二に、Luaバイトコードというアプローチは「ペイロードレス・アーキテクチャ」の一形態であり、従来のシグネチャベース検知が効きにくい。EDR（エンドポイント検出・対応）ソリューションの振る舞い検知に頼ざるを得ない状況を作り出している。 第三に、偽セキュリティソフトによる感染経路は、セキュリティ意識の高いユーザーほど騙されやすいという逆説を突く。「ウイルス対策ソフトのインストール画面だから安全」という先入観が仇となる。 実務での活用ポイント IT管理者・セキュリティ担当者向け LNKファイルの実行制限: グループポリシーまたはMicrosoft Intune（AppLocker/WDAC）でLNKファイルの外部からの実行をブロックする。メールやWebからのLNKは即座に疑うよう啓発する DLLサイドローディング対策: Windowsの「COMオブジェクト登録チェック」や、Defender for Endpointの攻撃面縮小（ASR）ルールでサイドローディングに対する検知精度を上げる FTPアウトバウンドのブロック: 多くの日本企業はFTP送信を許可したままにしがちだが、業務上の必要性がなければ全面遮断が望ましい パスワード付きアーカイブの扱い: ゲートウェイで自動展開できないアーカイブはサンドボックス解析に送るフローを整備する 正規サービス（Gmail等）経由の通信監視: DLP（データ損失防止）ポリシーとCASBを組み合わせ、クラウドサービス経由の大容量データ送信を検知する 筆者の見解 LucidRookが示す最も重要な教訓は、「現在動いているから安全」という前提がいかに危ういかだ。Luaバイトコードをオンデマンドで取得・削除する設計は、ペイロードを常駐させないことで痕跡を最小化する。感染後しばらくは何も起きていないように見える可能性すらある。 ゼロトラスト原則でいう「Never trust, always verify」をエンドポイント内部のプロセス動作にも適用する時代がきている。境界型防御で外からの侵入を防ぐ思想ではなく、内部での異常な振る舞い——たとえば「Microsoft Edge」を名乗るプロセスが意図しないDLLを読み込む動作——を検知するアーキテクチャへの移行が急務だ。 日本の大手エンタープライズを見ると、旧来のネットワーク境界防御と部分的なゼロトラスト実装が中途半端に混在している環境がいまだ多い。LucidRookのようなツールはそのギャップを正確に突いてくる。「層の薄いところを探して入る」のが高度な攻撃者の常套手段だからだ。 セキュリティは好き嫌いの話ではない。インフラを守るための設計思想として、全体最適で見直す機会を今こそ作ってほしい。部分的な対策の積み上げが全体としての脆弱性を生む——これはコストの問題である前に、設計哲学の問題だ。 出典: この記事は New ‘LucidRook’ malware used in targeted attacks on NGOs, universities の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがEdgeブラウザからXSLT（Extensible Stylesheet Language Transformations）のサポートを削除することを明らかにした。XSLT は XML 文書を HTML やテキストなど別形式に変換するための技術で、2000年代に多くの企業システムで採用されていた。長年にわたってEdgeに組み込まれてきた機能だが、いよいよそのサポートに終止符が打たれようとしている。 XSLTとは何か、なぜ今まで残っていたのか XSLT は W3C が策定した XML 変換仕様で、サーバーサイドで生成した XML データをブラウザ上でスタイルシート（.xsl ファイル）を使って HTML に変換する、という仕組みだ。2000年代初頭には「コンテンツとプレゼンテーションの分離」を実現する有力な手段として広く使われた。 しかし時代は変わった。現在のウェブ開発では REST API + JSON + JavaScript フレームワークが主流となり、XSLT を新規採用するケースはほぼ存在しない。それでも Edge に残り続けていたのは、削除すれば既存の業務システムが動かなくなるという、後方互換性への配慮からだ。 Edge の前身である Internet Explorer は XSLT を積極的にサポートしており、IE 向けに構築された社内ポータルや申請フォームが XSLT に依存しているケースは、日本の大企業・官公庁を中心に今も少なくない。 影響を受けるシステムの典型例 社内ポータル・承認フロー: SAP や独自開発の XML ベースデータをブラウザで表示・印刷するシステム 帳票・レポート出力: XML で出力したデータを XSLT で整形して画面表示するレガシー帳票基盤 Web サービス連携画面: SOAP 系 XML を XSLT でレンダリングしていた古い連携 UI Edge の Chromium ベースへの移行（2020年）でも XSLT は残されたが、今回はいよいよ削除が決定されたかたちだ。 実務への影響——日本企業が今すぐやるべきこと 1. 依存システムの棚卸し まず自社ブラウザで .xsl ファイルを参照している URL やアプリケーションがないか調査する。Edge の開発者ツール（F12）のネットワークタブで Content-Type: application/xml や .xsl ファイルへのリクエストを確認するのが手早い方法だ。 ...

GeminiがAIとの対話から直接3Dモデルやインタラクティブチャートを生成できる新機能の一般展開を開始した。単なる画像生成の延長ではなく、「操作・探索できるコンテンツ」をAIが生み出すという方向性は、AIアシスタントの進化における新しい段階を示している。 何ができるようになったのか Geminiのこの新機能では、テキストプロンプトから以下のコンテンツを直接生成できる。 3Dモデル: 分子構造、地形、製品形状などの立体的な可視化 インタラクティブチャート: パラメータを変えながらリアルタイムで操作できる動的なグラフ・図 インタラクティブシミュレーション: フラクタルや物理モデルなど、科学的概念を動的に探索できる環境 注目すべきは「インタラクティブ」の部分だ。従来のAI生成コンテンツは「出力物を受け取って終わり」というフローが基本だった。しかしパラメータを操作しながらリアルタイムで変化を確認できる動的コンテンツが生成できるとなると、情報の「受け取り」から概念の「探索」へとAIとの対話の質が変わってくる。 なお現時点では、Google WorkspaceおよびEducationアカウントを除く一般ユーザーへの展開となっている。企業アカウントでは利用できない状況だ。 なぜこれが重要か この機能が意味するのは、AIアシスタントが「テキストと静的画像を返すツール」から「インタラクティブなコンテンツ生成環境」へ進化しつつあるという流れだ。 エンジニアが設計パラメータをその場で変えながら3Dモデルを確認する、データアナリストがチャートの軸や範囲をリアルタイムで調整する——そういった使い方が現実的になってくる。特に「視覚的に理解するまでに時間がかかる」タイプの技術概念において、動的な可視化は理解のスピードを根本的に変える可能性を持っている。 実務での活用ポイント エンジニア・データサイエンティスト向け プロトタイプ段階での概念検証に使う。完成したコードを書く前に「どんなものを作りたいか」をインタラクティブに確認する用途が現実的 データ可視化の初稿生成ツールとして使い、その後Power BIやTableauなど専用ツールで仕上げる流れが効率的 IT管理者・導入検討者向け 現時点ではWorkspaceアカウントで利用不可のため、企業展開を検討する際はこの制限を把握しておくこと 一般展開されているタイミングで個人アカウントを使ったPoC（概念検証）を先行させておくと、後の企業展開判断の材料になる 教育・技術発信向け 複雑な技術概念の説明資料を作る際、テキストベースの説明を動的な可視化に置き換えることで理解度を高められる可能性がある 筆者の見解 AIが「インタラクティブなコンテンツを生み出す環境」へと進化しつつある方向性は、正しい進化だと思う。情報を受け取るだけでなく、探索・操作できる環境は人間の理解を根本的に変える力を持っている。 ただ、現場で本当に使えるレベルになるかどうかは、ワークフローへの統合次第だ。どれほど高機能でも、既存のツール群との連携がなければ「すごいデモ」で終わる。企業向けアカウントで利用できないという現状は、ビジネス活用を考えるには障壁が大きい。 一方で、一般ユーザーへの展開から始めて現場のエンジニアや研究者が価値を実証してから企業展開へ——というプロセス自体は着実だ。日本のIT現場でも、まず個人アカウントで自分のユースケースに当てはめて試してほしい。 大切なのは「こういう機能が出た」という情報を追いかけることではなく、実際に自分の手で試し、何が使えて何が使えないかを自分の言葉で語れるようになることだ。機能の多さに圧倒されるのではなく、自分の仕事に具体的に役立つ使い方を一つ見つけることの方が、長期的には何倍も価値がある。 出典: この記事は Gemini now lets you generate 3D models and interactive charts, here’s how の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11が登場して4年以上が経つ。しかしいまも「コントロールパネル」はそこにある。新しいプリンターを手動追加しようとすれば、Settingsアプリはあっさりと旧来のコントロールパネルへリダイレクトする。「なぜ消えないのか」——その疑問にMicrosoftが初めて公式に言葉を与えた。 Microsoftデザインリードが公式コメント MicrosoftのPartner Director of Design、March Rogers氏がX（旧Twitter）上で公式に認めた。チームは「すべてのコントロールパネルのコントロールを、モダンなSettingsアプリに移行する作業を進めている」と述べ、その進捗が慎重であることについてこう説明した。 「さまざまなネットワーク機器やプリンターデバイス、ドライバーを壊さないよう確認しながら進めているため、時間がかかっている」 移行の完了時期については明言を避けており、ロードマップの公開もない。 「互換性」という40年分の重力 ことの本質は、Windowsが背負ってきた歴史の重さにある。 macOSはAirPrintへの移行によってベンダー固有のプリンタードライバーを実質的に廃止した。AirPrint非対応のプリンターは新しいmacOSでは単なる「鉄の箱」になる。macOS Catalinaで32ビットサポートが切られたとき、USB-Ethernet変換アダプターやWi-Fiドングルのドライバーが一夜にして動作しなくなった事例も多数あった。 この断行ができるのは、macOSのシェアが比較的低く、企業ユーザーの多様なデバイス依存度も限られているからだ。Windowsはその対極にある。20年前のプリンタードライバーが今日も現役で動いている環境が、日本中の企業に無数に存在する。 現在もDevice Managerはコントロールパネルの一部であり、Settingsアプリから検索はできても、実体はコントロールパネル側にある。ドライバーの手動インストール・更新・ロールバック・削除といった操作は、すべてDevice Manager経由でなければ実質的に行えない。Settingsの「Bluetooth & デバイス」ページは直感的ではあるが、Device Managerほどの網羅性はまだない。 実務への影響——日本のIT現場で何が変わるか 短期的には「何も変わらない」と思っていい。 Microsoftは完了時期を示していない。現場のエンジニアやIT管理者が今すぐ運用を変える必要はなく、コントロールパネルはしばらくの間、引き続き利用できる。ただし、いくつかの点は意識しておきたい。 スクリプト・バッチ処理の棚卸しを始める: コントロールパネルの特定ページへのショートカットや control.exe を直接呼び出しているスクリプトがある場合、将来的に動作しなくなる可能性がある。今のうちにSettingsアプリのURIスキーム（ms-settings: など）への移行計画を立てておくと安心だ ドライバー管理の標準化: 独自ドライバーへの依存度が高い環境は、段階的にドライバーレスまたはクラウド管理型デバイスへの移行を検討するタイミングでもある 新規調達端末では積極的にSettingsを使う: 既存環境はそのままでも、新規導入環境からはSettingsアプリベースの操作フローに慣れておくことが移行摩擦を減らす 筆者の見解 Windowsが「古いものを壊さない」方針を取り続けてきたことは、日本のエンタープライズにとって長年の救いだった。製造業の制御端末、医療機器との連携、官公庁の業務システム——どれもベンダーが「Windows動作確認済み」の太鼓判を押したバージョンで止まっていることが多く、OS側がレガシーを切り捨てられない構造的な理由がある。 その意味で、今回のMicrosoftの「丁寧に進める」という姿勢は正しい。壊すよりも遅い方がいい。 ただ、正直に言えば、もう少し早くても良かった。Windows 11の登場から4年、Settingsアプリの整備ペースはやや物足りない印象がある。技術的な制約があることは理解した上で、「ユーザーが新しいUIを自然と使うようになる状況を作る」というデザインの仕事は、互換性問題とは切り離して前進できるはずだ。 Microsoftにはその力がある。SettingsアプリのUIが成熟すれば、ユーザーはコントロールパネルを探すことなく操作できるようになる。それが実現した日には、「コントロールパネルってまだあったの？」という声が自然と増えていくだろう。その日を待ちながら、現場としては今の環境を着実に整理していくのが現実的な対応策だ。 出典: この記事は Microsoft explains why it still can’t fully kill Control Panel in Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ロシアの国家支援型脅威アクター APT28（別名：Fancy Bear、Forest Blizzard）が展開していた大規模な認証情報窃取キャンペーン「FrostArmada」が、FBI・米司法省・ポーランド政府、そしてMicrosoftとLumenのBlack Lotus Labs（BLL）の連携によって制圧された。MikroTikやTP-LinkといったSOHOルーターを踏み台にDNS設定を書き換え、Microsoft 365のOAuthトークンを横取りするという手口は、「ネットワーク境界を信頼する」という従来型モデルの限界を改めて突きつけている。 FrostArmadaの攻撃メカニズム——シンプルかつ巧妙 攻撃の構造は以下の流れだ。 ルーターへの侵入: インターネットに直接露出しているMikroTik・TP-Link、Nethesis製ファイアウォール、旧型Fortinetモデルを標的に侵入 DNS設定の書き換え: 攻撃者が制御するVPS（仮想プライベートサーバー）をDNSリゾルバーとして設定 DHCPによる横展開: 書き換えられたDNS設定がDHCP経由でLAN内の全デバイスに自動配布 AitM（Adversary-in-the-Middle）攻撃: Microsoft 365など認証関連ドメインへのクエリを横取りし、攻撃者のプロキシに誘導 OAuthトークン収集: ユーザーが認証操作を行うと、有効なOAuthトークンごと攻撃者に渡る 被害者側に見える「サイン」は、TLS証明書の警告ダイアログだけ。「なんか出てきたけどOK押しておこう」の一瞬が致命傷になる構造だ。2025年12月のピーク時には120か国・18,000台のデバイスが感染し、政府機関・法執行機関・IT/ホスティングプロバイダーを中心に被害が拡大していた。 実務への影響——日本のエンジニア・IT管理者に告ぐ まずSOHOルーターを棚卸しせよ MikroTikとTP-Linkは日本のSOHO・中小企業・ラボ環境でも広く使われている。「使い続けているが設定を触ったことがない」という機器が一台でもあれば、今すぐ確認が必要だ。 外部管理インターフェース（Winbox・HTTP・SSH）を閉じる: デフォルトで有効なケースが多い DNSサーバー設定を確認: ISPまたは自社管理の正規リゾルバーを向いているか ファームウェアを最新に: 多くのSOHO機器は自動更新が無効のまま放置されている Microsoft 365環境の保護 条件付きアクセスでデバイスコンプライアンスを必須化: 準拠していないデバイスからのアクセスをそもそもブロック フィッシング耐性のある認証（FIDO2/パスキー）への移行を加速: MFAは最低ライン、その先へ OAuthトークンのライフタイムを短縮: 長命なトークンはAitMの格好の標的になる Microsoft Entra IDの継続的アクセス評価（CAE）を有効化: 異常なセッションをリアルタイムに無効化できる TLS証明書警告は「エラー」ではなく「シグナル」だ エンドユーザー教育として「証明書の警告が出たら絶対に進まない」を徹底することは、技術的対策と同等かそれ以上に重要だ。今回の攻撃はまさにその一瞬の油断を狙っている。 筆者の見解 APT28は今や誰もが名前を知るロシアの国家支援グループだが、今回の手口で特に注目すべきはその「ローテク性」にある。DNS設定を書き換えるだけ、DHCP配布に乗っかるだけ。最先端のマルウェアは一切使っていない。それでも18,000台を落とせた。 SOHOルーターが「ネットワークの入り口を守る機器」として認識されておらず、エンドポイント管理の圏外に置かれてきた現実を突いた攻撃だ。ゼロトラストの文脈では「ネットワーク内にいるから安全」という前提はとっくに崩れているのだが、ルーターそのものが信頼できない設定に書き換えられていたら、その先のすべての努力が砂上の楼閣になる。物理的な境界線を信じたくなる気持ちはわかるが、もうその時代ではない。 今回のFBIによる「裁判所命令に基づくリモートDNSリセット」という対処は興味深い。感染デバイスをリモートから修復するアプローチは、スケールする防衛手段として今後も使われるだろう。民間（Black Lotus Labs・Microsoft）と政府機関の連携が機能した事例として、この協調体制は正しい方向性だと思う。 Microsoft 365はこの種の攻撃の標的になり続ける。それだけ普及しており、アカウントの価値が高いからだ。だからこそ、Entraの認証機能を「設定しっぱなし」にせず、CAE・条件付きアクセス・FIDO2といった層を丁寧に積み上げることが求められる。道のど真ん中——Microsoftの推奨設定通りに、全部ちゃんとやる——が、今も最善の防衛策だ。 出典: この記事は Authorities disrupt router DNS hijacks used to steal Microsoft 365 logins の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントや LLMワークフローを手軽に構築できるオープンソースプラットフォーム「Flowise」に、CVSS スコア 10.0（最高深刻度）のリモートコード実行（RCE）脆弱性が発見され、実際の攻撃への悪用が確認された。セキュリティ研究機関 VulnCheck の観測によると、現時点でインターネット上に公開されている Flowise インスタンスは1万2千〜1万5千台に上るとされており、日本国内の AI 開発現場も決して対岸の火事ではない。 脆弱性の概要：「便利さ」の裏側に潜むリスク 今回の脆弱性は CVE-2025-59528 として追跡されており、Flowise の CustomMCP ノードに起因する。このノードは外部の MCP（Model Context Protocol）サーバーと接続する設定を行う機能だが、mcpServerConfig というユーザー入力値を一切の安全検証なしに JavaScript として評価（eval）してしまう設計上の欠陥がある。 攻撃者がこの入力に悪意ある JavaScript コードを埋め込むだけで、サーバー上で任意コードが実行され、ファイルシステムへのアクセスも可能になる。入力値検証もサンドボックスも存在しない、典型的な「信頼しすぎ」の実装だ。 脆弱性自体は 2025 年 9 月に公開されており、Flowise バージョン 3.0.6 で修正済み。現在の最新版は 2 週間前にリリースされた 3.1.1 だ。VulnCheck の研究者 Caitlin Condon 氏は、自社の Canary ネットワークが本脆弱性の初の悪用を検出したことを LinkedIn で公表した。現時点での攻撃活動は Starlink の単一 IP から発生しており、規模は限定的とのことだが、今後の拡大は十分に想定される。 さらに、Flowise にはこれとは別に CVE-2025-8943 および CVE-2025-26319 も存在し、いずれも野外での悪用が確認されているという。複数の脆弱性が重なっている点は、より深刻に受け止める必要がある。 Flowise とはどんなプラットフォームか Flowise はドラッグ＆ドロップ型の UI で AI エージェントや LLM ベースのワークフローを構築できる、ローコード・オープンソースのプラットフォームだ。チャットボット、自動化パイプライン、ナレッジベースアシスタントなどの用途で、エンジニアから非エンジニアまで幅広いユーザーが利用している。 特に「コードを書かずに AI エージェントを作れる」というアピールポイントから、日本でも PoC（概念実証）や社内ツール構築の場面での採用が増えている。まさに「使いやすさ」が今回の脆弱性リスクを広げている側面もある。 ...

米国の重要インフラを支える産業制御システムが、国家支援のサイバー攻撃の標的になっている。FBI・CISA・NSA・EPA・DOE・米サイバー軍（CNMF）の6機関が2026年4月に共同アドバイザリを発行し、イランと関係するAPTグループによる攻撃が2026年3月以降に拡大していることを明らかにした。標的はRockwell Automation（Allen-Bradley）製のプログラマブルロジックコントローラー（PLC）であり、すでに金銭的損失と業務停止被害が報告されている。 何が起きているのか 攻撃者はインターネットに直接接続された産業用PLCを探索し、HMI（ヒューマン・マシン・インターフェース）およびSCADA（監視制御・データ収集）ディスプレイ上のデータを改ざんしている。機器のプロジェクトファイルが窃取されることも確認されており、「監視して終わり」ではなく、操作介入まで踏み込んでいる点が深刻だ。 対象セクターは政府施設・水処理・廃水処理・エネルギーと、社会基盤の中枢にわたる。2023年にも同系統のCyberAv3ngersグループがUnitronics製PLCを75台以上侵害した前例があり、今回はその延長上にある継続的な攻撃キャンペーンと見られている。 米当局は「今回の攻撃激化は、イランと米国・イスラエルの間の緊張悪化と連動している」と分析している。地政学的なコンテキストが直接サイバー攻撃のタイミングと規模に影響している点は、軍事・外交の動向とセキュリティ運用が切り離せない時代になったことを改めて示している。 根本原因は「インターネット直結のOT機器」 今回の攻撃で最大の問題は、PLCがインターネットに露出していたことだ。IT系のサーバーであれば「外部公開=リスク」という認識はある程度普及しているが、OT（運用技術）機器においては「昔から動いているから」という理由でネットワーク分離が後回しにされてきたケースが多い。 Shodan等のツールを使えば、世界中のインターネット接続PLC・HMIを容易に発見できる。攻撃者にとっては「扉が開いたまま」の状態だ。 実務での対策ポイント 米当局の勧告をもとに、実際に何をすべきかを整理する。 即実施すべき対策 PLCをインターネットから切断するか、ファイアウォールで保護する OTネットワークへのアクセスに多要素認証（MFA）を導入する PLCのファームウェアを最新版に更新する デフォルト認証キーや未使用サービスを無効化する 継続的な監視項目 OT関連ポートへの不審トラフィック（特に海外ホスティング事業者からの接続）を監視する アドバイザリで共有されたIoC（侵害指標）とログを照合する 構造的な改善 ITネットワークとOTネットワークの分離（エアギャップもしくはDMZ構成） OT機器へのアクセスログの一元管理と定期レビュー 日本のOT環境にとっての意味 「これはアメリカの話」で済ませたいところだが、日本の製造業・インフラ事業者も無関係ではない。実態として、レガシーな制御システムがインターネットに接続されたまま運用されている現場は日本にも存在する。 経済産業省のICS向けセキュリティガイドラインや、IPA（情報処理推進機構）が公開している制御システムセキュリティ対策ガイドを参照し、自組織のOT機器の露出状況を確認することを強く推奨する。特に水道・電力・ガスなどの重要インフラ事業者は、今回の米国事例を他山の石と捉えるべきだ。 筆者の見解 OTセキュリティの問題は、「ITとOTが別々に進化してきた歴史」の歪みがここに来て表面化したものだと見ている。IT系では常識となっているゼロトラストの考え方——「信頼しない、常に検証する」——がOT領域にはまだ十分に浸透していない。 「今まで動いていたから大丈夫」という運用文化と、長期間使われ続けるレガシー機器の組み合わせは、攻撃者にとって格好の標的になる。VPNで「守れている気になっている」構成も同様で、ネットワーク境界を信頼し続けるモデルはOT環境でこそ早急に見直すべきだ。 Just-In-Timeアクセス制御の考え方をOT機器にどう適用するかは設計上の難しさがあるが、少なくとも「インターネット直結のPLC」という状態は今すぐ解消できる最も優先度の高い課題だ。インシデントが起きてから動くのではなく、アドバイザリが出た今日を対応開始の起点にしてほしい。 出典: この記事は US warns of Iranian hackers targeting critical infrastructure の内容をもとに、筆者の見解を加えて独自に執筆したものです。

データ分析基盤として多くの企業に採用されているSnowflakeの顧客が、思わぬ経路からデータ窃取被害を受けた。攻撃の起点は自社でもSnowflakeでもなく、SaaS統合プロバイダーという「第三者の連携業者」だった。このインシデントは、現代のクラウド環境が抱えるサプライチェーンリスクの核心を突いている。 何が起きたのか 2026年4月上旬、データ異常検知AIサービスを提供するAnodot（2025年11月にGlassboxが買収）が侵害され、複数のSaaS・クラウドサービスへの認証トークンが窃取された。この窃取されたトークンを使い、攻撃者はSnowflakeを中心とした十数社のクラウドデータ基盤から大量のデータを盗み出すことに成功した。 Snowflakeは「特定の第三者統合サービスに紐付いた、少数の顧客アカウントにおける異常なアクティビティを検知した」と認め、該当アカウントのロックダウンと顧客への通知を行ったことを公表した。同社は自社システムの脆弱性や侵害は一切なかったと強調しており、攻撃ベクターはあくまでも外部統合業者が保持していたトークンだった。 攻撃者はSalesforceへのデータ窃取も試みたが、AIによる検知機能に阻まれ未遂に終わっている。その後、犯行グループとして悪名高いShinyHuntersがBleepingComputerに対し自らの関与を認め、被害企業への恐喝（データ公開をちらつかせた身代金要求）を行っていることが判明した。 なぜこれが重要か——「信頼された接続」の危うさ このインシデントの本質は、「信頼された統合業者」を経由した横断的なアクセス権の悪用にある。 AnodotのようなSaaS統合プロバイダーは、顧客環境のデータにアクセスするために各種サービスへの認証情報やトークンを保持する。これは業務上必要な仕組みだが、裏を返せば「統合業者一社を侵害するだけで、そのテナントとして接続しているすべての顧客環境に横断的にアクセスできる」ことを意味する。 一般的なサプライチェーン攻撃ではソフトウェアパッケージへの悪意ある変更が使われるが、今回は認証トークン窃取という形態だった点が注目に値する。MFA（多要素認証）を突破する必要さえない——有効な認証情報を持っていれば、攻撃者は正規ユーザーとして振る舞える。 実務への影響——IT管理者・エンジニアが今確認すべきこと 1. SaaS-to-SaaS連携の棚卸しを今すぐ行う 自社のSnowflake・Salesforce・その他クラウドデータ基盤に対して、どのサードパーティ統合が認証情報・トークンを保持しているかを把握できているか。多くの企業でこの可視性が欠如している。 Snowflakeであれば SHOW INTEGRATIONS; や SHOW CONNECTIONS; でOAuth統合の一覧を確認できる 不要になった統合・使用頻度の低い統合のトークンは即座に失効させる 統合に付与されている権限スコープを最小権限の原則に照らして見直す 2. 統合サービスへのアクセスをJust-In-Timeに近づける 常時有効なロングライフのトークン・APIキーを発行し続けるのではなく、短命なトークン（短い有効期限＋自動ローテーション）を採用する。Azure AD・AWS IAM・Snowflake OAuth 2.0など、主要基盤はいずれも短命トークンの発行機構を持っている。 3. 異常検知ログを外部依存しない 今回、皮肉なことにデータ異常検知会社自身が侵害の起点となった。異常検知基盤を外部SaaSに丸投げするのではなく、自社の認証ログ（SIEM）でも独立して監視する体制を持つことが不可欠だ。 4. インシデント連絡先を確認する Payoneerは迅速に「影響なし」を確認できた一方、連絡のつかない企業が複数あった。統合業者側でインシデントが発生した際に自社が迅速に通知を受け取れるよう、契約上の通知義務条項とセキュリティ連絡先の整備を確認しておく。 筆者の見解 今回の事案は、「ゼロトラスト」という概念がまだまだ表層的にしか理解されていない現実を突きつけている。 ゼロトラストの本質は「ネットワーク境界の外に出ない」という古典的な境界防御の否定であり、「誰も、何も、デフォルトでは信頼しない」という継続的検証の思想だ。しかし日本の多くのエンタープライズ環境では、社内境界への接続に対しては過剰な制限を課しつつ、SaaS-to-SaaSの連携については「信頼されたパートナー」として実質的にフリーパスを与えているケースが少なくない。これは新旧のセキュリティモデルが中途半端に混在した状態で、かえって死角を生む。 AnodotはAIによるリアルタイム異常検知という、本来ならセキュリティ向上に貢献すべきサービスを提供していた。その基盤が侵害されたという事実は、ツールへの信頼と、そのツール自体のセキュリティ評価を切り分けて考える必要性を改めて示している。サードパーティの評価は導入時の一度きりではなく、継続的なセキュリティアセスメントであるべきだ。 データへのアクセス権を統合業者に付与する際は、「この業者が侵害されたとき、自社にどのような影響が及ぶか」を契約・設計の段階で真剣に考える。これは面倒なプロセスに思えるが、ShinyHuntersのような組織が連絡してきてからでは遅い。 出典: この記事は Snowflake customers hit in data theft attacks after SaaS integrator breach の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国のサイバー犯罪被害総額が2025年に約2.1兆円（208億ドル）に達し、統計開始以来の最高額を更新した。FBIのインターネット犯罪窓口IC3（Internet Crime Complaint Center）が発表した最新年次報告書によると、被害額は前年比26%増という急激な伸びを示しており、年間の苦情件数も初めて100万件を超えた。 この数字は米国単独のものだが、手口・被害構造ともに日本のサイバー犯罪トレンドと強い相関がある。いまのうちに「他山の石」として対策を固めておく価値は十分ある。 被害の内訳：何が「最大の脅威」か 苦情件数で最多だったのはフィッシング攻撃（19万1,000件）、次いで恐喝（8万9,000件）、投資詐欺（7万2,000件）。しかし被害額の規模で見ると順位が大きく変わる点に注意が必要だ。 暗号資産関連詐欺が突出した最大損害源で、18万1,565件で被害総額は1兆円を超える約110億ドル。続いて投資詐欺全体（86億ドル）が全詐欺関連件数の49%を占める。 ビジネスメール詐欺（BEC）は約2万4,700件と絶対数は少ないが、1件あたりの被害額が大きいため依然として企業の最重要防御対象だ。ランサムウェア（3,600件）やSIMスワッピング（971件）も報告されており、インフラへの攻撃では医療・製造・金融・IT・政府施設が上位5セクターに挙がっている。 60歳以上の高齢者が最も狙われており、被害額は77億ドルと前年比37%増。テクニカルサポート詐欺や投資詐欺に誘い込まれるケースが多い。 今回初集計：AI悪用詐欺の実態 今年の報告書で初めて独立カテゴリとして集計されたのがAI関連詐欺だ。2万2,300件の苦情、損害額8億9,300万ドル（約1,400億円）という規模は、登場初年度の数字としては無視できない。 手口の中心は以下の4つ： 音声クローニング（ボイスクローン）：家族や上司を装った音声で緊急送金を迫る フェイクプロフィール：SNS上のなりすましによる投資・ロマンス詐欺 偽造書類：高精度な文書偽造で信頼を獲得 ディープフェイク動画：著名人・経営幹部を装った映像で偽情報を拡散 生成AI技術の急速な普及が詐欺師の「製造コスト」を劇的に下げていることは明白だ。数年前なら高度な技術が必要だった精巧な音声・映像の偽造が、今では安価なツールで誰でも実行できる。 FBIの反撃：「金融フラウド・キルチェーン」で679億円を凍結 被害が拡大する一方、FBIも対策を強化している。2025年に実施した「Financial Fraud Kill Chain（FFKC）」介入は3,900件。攻撃者が狙った11億6,000万ドルのうち6億7,900万円（約1,000億円）の凍結に成功した。 また「Operation Level Up」では暗号資産投資詐欺の被害者候補を事前に特定・警告するプロアクティブなアプローチを展開。通知を受けた3,780人のうち78%が詐欺に遭っていることすら気づいていなかったという事実は衝撃的だ。 実務への影響——日本のエンジニア・IT管理者が今すぐできること BEC対策：メール≠本人確認 「上司から送金指示が来た」「取引先の口座が変わった」系の連絡は、必ずメール以外の手段（電話・Teamsビデオ通話等）で二重確認する運用を徹底したい。BECはメール単体への依存を突いた攻撃であり、帯域外確認（Out-of-Band Verification）がもっとも確実な防衛策だ。 社員へのAI詐欺リテラシー教育 音声やビデオが「本物に見える・聞こえる」ことを前提とした教育に切り替えるタイミングが来ている。コードワード（事前に決めた合言葉）の活用や、緊急送金フローに必ず人的承認ステップを挟む設計が有効だ。 高齢ユーザーへの配慮 B2B企業でも、顧客企業の経営陣や年配の決裁者が標的になるリスクは低くない。カスタマーサポートのフローに「なりすまし確認フェーズ」を組み込む発想が今後は必須になる。 フィッシング耐性認証の導入 パスワードレス＋フィッシング耐性MFA（パスキーやFIDO2）は、フィッシング19万件超という数字を見るとすでに「あると便利」ではなく「ないとまずい」レベルに達している。SMSワンタイムパスワードはフィッシングに無力なので注意。 筆者の見解 2.1兆円という数字は衝撃的だが、私が注目したのは「78%の被害者が自分が詐欺に遭っていることに気づいていなかった」という事実だ。これはセキュリティの問題であると同時に、ユーザー体験の設計問題でもある。 「禁止ではなく安全に使える仕組みを」というのが私の基本スタンスだが、AI詐欺の台頭はまさにその仕組みを問い直す局面に来ている。本物と見分けのつかない音声・映像が日常的に飛び交う世界で、「怪しいと思ったら確認しよう」という啓発だけでは構造的に不十分だ。 組織として求められるのは、怪しいかどうかの判断をユーザーに委ねず、プロセス設計で二重確認を強制する仕組みだ。具体的には、高額送金フローへの帯域外承認の組み込みや、カレンダー招待と突き合わせた会議の正当性確認、フィッシング耐性認証の全面導入などが挙げられる。 日本の大企業のセキュリティ体制は、昔ながらの境界型防御と中途半端なゼロトラストが混在して複雑化しているケースをよく見かける。そこに「AI詐欺を含む新しい脅威をどう統合するか」という課題が加わると、パッチワーク的な対応の限界はさらに顕著になる。 今回のFBI報告は、個別の防衛策を積み上げる発想から、認証・認可・監視の3層を整合させた全体設計に切り替えるべき時期が来ていることを改めて示している。被害額が毎年更新されている間、攻撃者は確実に学習し続けている。守る側も同じスピードで進化しなければならない。 出典: この記事は FBI: Americans lost a record $21 billion to cybercrime last year の内容をもとに、筆者の見解を加えて独自に執筆したものです。