この号の内容
🌡️ 脅威レベル
⚡ ニュース：押さえておきたいセキュリティ関連の5つのニュース
🔎 ディープダイブ：オフボーディングの抜け穴
🎣 これはフィッシング？
🔬 技術研究：彼らはパスワードを盗んだのではない。偽造したのだ。
🛠️ 今週のツール：管理されたセキュリティ調査のためのTor
👏 今週の人物：Romain Thomas
📅 今週のイベント：Black Hat USA 2026
📚 今週の本：Spycraft
😅 今週のミーム
❓ 最後にひとつ質問
オフボーディング（退職者のアクセス整理）は、外から見れば完了しているように見えることがあります。ノートPCは返却され、入館証は無効化され、お別れのメールも送られ、ケーキもなくなりました。説得力のある幕引きです。
厄介なのは、そのどのステップも、古いセッションや忘れられたトークン、共有ドライブに、その人が去ったことを伝えていない点です。退職の事実がシステムそのものに届かない限り、月曜日がいつもの勤務日であるかのようにアクセスは続きます。
この号はそこから始まります。きれいな別れ、乱雑なアクセスの痕跡、そしてもっと簡単に答えられてしかるべき問い、「正確には、何がまだ機能しているのか」です。
🌡️脅威レベル
⚡ ニュース
信頼されていたAsyncAPIの5つのリリースにマルウェア、正当な来歴証明でも止められず
攻撃者は7月14日にAsyncAPIのリリースワークフローを侵害し、4つのnpmパッケージにわたって5つの悪意あるバージョンを公開しました。これらのパッケージには、影響を受けたシステム上でコマンドを実行できるバックドアMiasmaが仕込まれていました。コードはインストール時ではなくインポート時に起動するため、--ignore-scriptsは防御になりませんでした。チームは依存関係のロックファイル、ビルドキャッシュ、CIログを調べたうえで、影響を受けた可能性のあるビルドからアクセスできた認証情報をローテーションする必要があります。
悪用済みの2つの欠陥により、AD FSとSharePointがMicrosoftの7月のパッチ対応の最優先に
Microsoftの7月のリリースノートには622件の脆弱性が記載されていますが、総数は数え方によって異なります。2つの欠陥はすでに悪用されていました。CVE-2026-56155はActive Directory Federation Servicesでのローカル権限昇格を可能にし、CVE-2026-56164はオンプレミスのSharePointに影響し、認証なしで到達可能です。CISAは両方を既知の悪用された脆弱性（Known Exploited Vulnerabilities）カタログに追加しており、ID基盤と外部に公開されたSharePointサーバーが当面の最優先事項となっています。
SonicWall、SMA 1000の2つの脆弱性に対する実際の攻撃を確認
SonicWallによると、攻撃者はSMA 1000アプライアンスに対してCVE-2026-15409とCVE-2026-15410を悪用しています。1つ目はCVSS 10.0と評価されたサーバーサイドリクエストフォージェリ（SSRF）の欠陥です。2つ目は特定の条件下でコードインジェクションを可能にします。ホットフィックスの適用は最初の一歩にすぎません。SonicWallはフォレンジックレビューも推奨しており、侵害の痕跡が見つかった場合は、信頼できるイメージからアプライアンスを再構築するよう勧めています。
偽のOAuthクライアントIDで、攻撃者はサインインを完了させずにEntraの認証情報を試せる
Proofpointは、攻撃者が偽装したOAuthアプリケーション識別子を大量に生成し、Microsoft Entraのレスポンスを使ってアカウントとパスワードが有効かどうかを推測しているのを確認しました。この試行は通常のサインイン成功を生まないため、従来の監視ルールでは見逃される可能性があります。有用なシグナルとしては、アプリケーション名の欠落、空の識別子、存在しないクライアントIDの異常な量、そして有効な認証情報の試行と並んで現れるAADSTS700016などのエラーパターンが挙げられます。
研究者がClaude for Chromeのワークフローに合成クリックで入り込む経路を発見
Manifold Securityによると、claude.aiへのアクセス権を持つ別のブラウザー拡張機能が合成クリックを生成し、Gmail、Google Docs、Calendar、Salesforceなどのサービスに関わる、事前定義されたClaude for Chromeのタスクを起動できるといいます。報告された攻撃には、悪意のある、または侵害された拡張機能がすでにブラウザーに存在していることが必要です。ブラウザーエージェントをテストしている組織は、拡張機能の権限を見直し、接続するアプリケーションを制限し、機密性の高いワークフローでは無人承認の設定を避けるべきです。
🔎 ディープダイブ
オフボーディングの抜け穴
その従業員が去ってから数週間が経っていました。入館証はもう使えず、メインアカウントは無効化され、退職手続きは完了したように見えていました。
そして、誰かがサーバーログを確認しました。
Appleは、会社のノートPCを返却していなかった元従業員が社内ネットワークに再び入り込む方法を見つけ、機密のハードウェア関連ファイルをダウンロードしたと主張しています。この主張は現在も裁判所で審理中であり、意図の問題はそこで判断されるべきものです。セキュリティチームにとって、より示唆に富む謎は、ダウンロードの前に何が起きていたかです：
Appleのシステムは、何をまだ信頼し続けていたのか？
Reutersがこの申し立てと、相手側の反応を報じています。
第一の容疑者：メインアカウント
従業員が退職するとき、たいてい最初に確認されるのは中央のIDアカウントです。無効化し、アクセスを終了させ、タスクを完了済みにします。
しかし、アカウントは環境に入る方法の一つにすぎません。
アプリケーションがまだアクティブなセッションを保持しているかもしれません。サービスが以前に発行されたトークンを受け入れるかもしれません。会社の端末に有効な証明書が残っているかもしれません。社内スクリプトが、その従業員が作成して別の場所に保存したAPIキーを使っているかもしれません。共有パスワードは、そもそも個人のIDにまったく紐づいていないかもしれません。
メインアカウントが消えた後も、これらはそれぞれ使い続けられる可能性があります。
午前9:00に発行されたトークンを考えてみましょう。従業員のアカウントは正午に無効化されますが、アプリケーションはIDプロバイダーに最新の状態を問い合わせるのではなく、トークンをローカルで検証します。
IDプロバイダーはアカウントが無効化されていることを知っています。アプリケーションが知っているのは、トークンが正しく署名され、有効期限が切れていないということだけです。
どちらのシステムも正常に動作しているように見えます。障害はその間の隙間にあります。
チケットのステータスは緑だった
退職処理の記録は、それでも完璧に見えるかもしれません：
アカウントは無効化された
入館証は返却された
アクセス削除のリクエストは送信された
退職チケットはクローズされた
チケットが証明するのは、ワークフローが想定どおりのアクションを実行したことです。すべてのアプリケーション、デバイス、認証情報が元従業員を受け入れなくなったことを証明するものではありません。
5つのシステムがアクセス権を持っていて、削除を確認したのが4つだけなら、5つ目のシステムは「静かな成功」ではありません。答えの出ていない問いです。
リクエストが届かなかったのかもしれません。システムが処理に失敗したのかもしれません。アクセスは削除されたものの、確認が返ってこなかったのかもしれません。結果がわかるまでは、これらの可能性を同等のものとして扱うのは安全ではありません。
見つからないノートPCが調査を変える
会社のノートPCは、返却を待つ資産というだけではありません。アクティブなセッション、ローカルに保存された認証情報、デバイス証明書、そして社内サービスとの信頼関係の履歴を抱えている可能性があります。
つまり、端末を回収することと、そのアクセスを失効させることは、別々の2つのアクションです。ノートPCが行方不明として記録されている間も、そこに紐づく証明書は有効なままかもしれません。ユーザーアカウントが無効化されていても、アプリケーションはその端末から作成されたセッションを受け入れ続けるかもしれません。
物理的な退職は起きました。しかし技術的な関係が、それとともに終わったとは限りません。
だからこそ、すべてのアカウント、トークン、キー、証明書、信頼済みデバイスについて、3つの情報が必要になります：
誰が、あるいは何が所有しているのか？
どのシステムがそれを受け入れるのか？
どうすれば失効、ローテーション、または期限切れにできるのか？
所有者が不明なら、オフボーディングのワークフローにはその認証情報を対象に含める確かな理由がありません。従業員の退職が自分に関係するとどのシステムも認識しないという、ただそれだけの理由で生き残ることがあるのです。
通常のトラフィックに隠れた手がかり
所有者が退職した3週間後に、古いトークンが使われたとします。監視システムはその重大さを認識するでしょうか？それとも、認証済みリクエストの成功をまた一つ記録するだけでしょうか？
所有者のコンテキストがなければ、そのリクエストはありふれたものに見えるかもしれません。トークンは有効です。証明書は見慣れたものです。端末は以前にも接続しています。
同じイベントに元の所有者と退職日を紐づければ、見え方は変わります。成功したリクエストは、あるアクセス経路が退職後も生き残っていたことを示しているかもしれません。失敗の繰り返しは、忘れられたスクリプト、キャッシュされたセッション、あるいはまだ再接続を試みている端末を明らかにするかもしれません。
これらはいずれも悪意を証明するものではありません。しかし、後片付けが不完全だったことは明らかになります。それこそが、この制御が検出すべきことです。
すべての扉を閉じる
アクセス経路が異なれば、終わらせ方も異なります。共有パスワードはローテーションしなければなりません。デバイス証明書は失効させる必要があるかもしれません。既存のセッションは終了させる必要があります。スタンドアロンのアプリケーションでは、個別のアカウント変更が必要になる場合があります。APIキーは、それを使うサービスを止めずに置き換える必要があるかもしれません。
対処方法は変わっても、求められるエビデンスは一貫しているべきです。
組織がアクセス経路を特定し、それぞれが機能しなくなったことを確認し、再び現れたものを検出できるようになって、はじめて退職処理は完了です。
それまでは、従業員がいなくなっても、そのアクセスの一部はまだ内側に残っているかもしれません。
🎣 これはフィッシング？
正規のドメインだからといって、ワークフローが正規であるとは限りません。自分で生成していないデバイスコードは決して入力しないでください。
🔬 技術研究
彼らはパスワードを盗んだのではない。偽造したのだ。
攻撃者があなたのパスワードをまったく必要としないこともあります。必要なのは、すでにパスワードを持っているとサーバーに信じ込ませることだけです。
それがCVE-2026-55040の不穏な核心です。オンプレミスのMicrosoft SharePoint Serverに存在するクリティカルな認証バイパスで、2026年7月14日に公表されました。発見したのはRapid7 Labsの研究者Stephen Fewerで、実環境で捕捉されたのではなく、Pwn2Own Berlinで初めてライブで実証されたものです。CVSS v3.1スコアは9.1で、SharePoint Server 2016、2019、Subscription Editionに影響します。
信頼はどう崩れるのか
SharePointはIISとASP.NET上で動作し、その認証モデルはクレームベースです。リクエストはIDを主張する署名付きトークンを提示し、バックエンドのモジュールはセッションが確立される前にそのトークンを暗号学的に検証することになっています。この検証ステップこそがセキュリティ境界のすべてです。その下流にあるもの（権限、管理パネル、コンテンツへのアクセス）はすべて、トークンがそこに届く前に正しくチェックされたことを前提にしています。
CVE-2026-55040はその前提を崩しました。SharePointのJWT検証パイプラインに複数の弱点があったため、サーバーは拒否すべきトークンを受け入れるように仕向けられ、生成されたセッションを、実際にリクエストを送った人物のIDではなく、トークンが主張するIDに関連付けてしまいました。パスワードは不要。盗んだセッションCookieも不要。事前の足がかりも不要。サーバーが信じてしまうトークンが一つあれば十分でした。
前提条件は一つだけです。攻撃者は、誰になりすましたいかをあらかじめ知っている必要があります。実際には、これは低いハードルです。ユーザー名は日常的な偵察（ADの列挙、OSINT、過去の侵害データ）で見つかることが多く、パスワードのような意味での秘密ではありません。この脆弱性がしているのは、「ユーザー名を知っている」を「私はそのユーザーであり、完全に認証され、そのユーザーが持つあらゆるアクセス権を持っている」に変えることです。選んだIDがサイト管理者であれば、攻撃者はその管理者の認証情報に一切触れることなく、管理者レベルのSharePoint操作を引き継ぎます。
露出しているサーフェスのせいで、これは典型的な内部限定の欠陥よりも深刻です。関連するエンドポイントはvtibinや_layoutsといったパスの下にあり、デフォルトのSharePoint構成では認証なしでリモートから到達できます。これは攻撃者が足がかりを得なければ届かないニッチな内部APIではありません。インターネットに公開されたあらゆるデプロイメントで、デフォルトで露出しているのです。
なぜ「不正アクセス」で終わらないのか
ここが、単なるパッチノートの一項目ではなく、このニュースレターのセクションで取り上げるべき理由です。Rapid7の研究は認証バイパスで止まりませんでした。同社のチームは、CVE-2026-55040を現時点で未修正の2つ目の脆弱性と連鎖させることで、認証なしの完全なリモートコード実行（RCE）に到達できることを発見しました。ログインも、認証情報も、ユーザーの操作も、管理者のIDさえも不要です。この組み合わせはPwn2Own Berlinのエントリーとして一緒に開発・実証され、その後5月にMicrosoftへ責任ある形で開示されました。（注：この未修正のRCEコンポーネントは、Microsoftが同じく7月14日に修正したデシリアライゼーションのRCEであるCVE-2026-58644とは別個の問題であり、両者を混同すべきではありません。）
Microsoftの開示タイムラインは載せておく価値があります。これがいかに計画的に段階分けされていたかがわかるからです：
2026年5月18日：Rapid7が、認証なしRCEのエクスプロイトチェーン全体をMicrosoftに開示
2026年5月20日：Microsoftが報告内容を確認し、修復を2回の更新サイクルに分割（7月に認証バイパス、8月にRCEコンポーネント）
2026年5月29日：Rapid7が、7月の公表後30日間は技術的詳細を公開しないエンバーゴに同意。ただし、実環境での悪用や第三者による開示が先に起きた場合は早期に公開するという条件付き
2026年7月14日：Patch Tuesdayに、CVE-2026-55040の公表とパッチが同時にリリース
つまり、7月のパッチで話が終わるわけではありません。話を中断させるだけです。2つ目の環が修正される前に、最初の環でチェーンを断ち切るのです。今日CVE-2026-55040にパッチを適用した組織は、現在知られているチェーンからは保護されます。RCEの後半部分には、まず有効な偽造IDがなければ到達できないからです。しかし根底にある教訓、つまり偽造されたIDは一度受け入れられてしまえば本物と機能的に見分けがつかないということは、1回のパッチサイクルで消えるものではありません。そして8月のRCEパッチは、すでにカレンダーに書き込まれた事実上2つ目の期限です。
悪用状況：本稿執筆時点で、CISAとMicrosoftはCVE-2026-55040を実環境で活発に悪用されているものとしてリストに載せていません。Microsoftは悪用確認済みではなく「Exploitation More Likely」（悪用される可能性が高い）とタグ付けしています。これは同じサイクルで修正された他の3つのSharePointのCVE（CVE-2026-32201、CVE-2026-45659、CVE-2026-56164）とは意味のある違いです。これら3つについてCISAは、不正アクセス、RCE、IISマシンキーの窃取、マルウェアの永続化に使われ、活発に悪用されていることを確認しています。CVE-2026-55040の公開された概念実証（PoC）はまだありません。Rapid7は30日間のエンバーゴのもとで技術的な詳細の全容を公開していません。セキュリティチームはこの静かな期間を猶予期間と読み違えるべきではありません。8月に向けた予定済みのカウントダウンなのです。
注視していること
CISAの現在のSharePoint強化アラートは、CVE-2026-55040そのものではなく、すでに活発に悪用されている兄弟CVEを対象に書かれています。しかし、そこに記載された振る舞い（IISマシンキーの窃取、デシリアライゼーションの悪用、永続化、マルウェアの展開）は、このチェーンのRCE部分が公開されたときに当社が想定する侵害後の活動と同じカテゴリです。7月14日以前にSharePointインスタンスがインターネットに公開されていた場合、パッチを適用すれば「まだ脆弱か」には答えられますが、「すでに使われたか」には答えられません。当社による脅威パターンの読み解きに基づき、公開されていたインスタンスについては次の項目を確認する価値があります：
実際のログインイベントと対応しないセッションからの管理操作や、コンテンツ・権限の変更
対応するヘルプデスクや変更管理のチケットがない、新しいサイトコレクション管理者や昇格したロールの付与
パッチ適用前のIISログにある、vtibin / _layoutsへの通常と異なるリクエストや異常なリクエスト
SharePointサービスアカウントやアプリプールのIDを起点とする、ラテラルムーブメントや認証の試行
SharePointサーバー自体から開始された外向き接続や新しいスケジュールタスク
繰り返されるパターン
FortiBleedは、アクセスの持ち主が変わる話でした。認証情報が収集され、検証され、在庫として販売されたのです。今回は、アクセスがそもそも本当には存在しなかったという話です。サーバーがだまされて正当だと信じ込んだセッションであり、窃取はまったく必要ありませんでした。メカニズムは異なっても、結論は同じです。対応すべきものが目に見えるようになった時点で、意味のある侵害はすでにその上流で静かに起きていたのかもしれません。そして今回の場合、チェーンの後半はまだこれからやってきます。
🛠️ 今週のツール
Tor
Torは匿名ブラウジングと結びつけられることが多いですが、セキュリティチームにとって最も有用な役割の一つは、管理された調査です。
どこで役立つのか
ある企業名がランサムウェアのリークサイトに掲載されたとします。その投稿は社内ファイルが盗まれたと主張し、組織に対応の期限を突きつけています。
その主張を確定した侵害として扱う前に、アナリストはページを調べ、何が公開されたかを記録し、サンプルデータが本物かどうかを判断する必要があります。それを通常の社内ブラウザーから行うと、調査対象のインフラに組織のパブリックIPアドレスが知られてしまう可能性があります。
ブラウザーが明かすのはIPアドレスだけではありません。Cookie、拡張機能、フォントなどの特性は、訪問者を互いに区別する手がかりになりえます。調査活動がアナリストの普段のアカウントや閲覧履歴と混ざってしまうこともあります。
Tor Browserは、調査と組織の通常のブラウジング環境との間に分離を作ります。トラフィックを複数のリレーに経由させ、接続先から元のIPアドレスを隠し、ブラウザーのフィンガープリンティングを難しくするための保護機能を備えています。
接続の仕組み
通常のブラウザーは、たいてい接続先に直接接続します。そのためWebサイトは、リクエスト元のパブリックIPアドレスを見ることができます。
Torは、接続先に届く前に複数のリレーを経由させます。各リレーが知っているのは、経路上の直前と直後のステップだけです。接続先に見えるのは、アナリストの会社や自宅のIPアドレスではなく、最後のTorリレーのアドレスです。
この設計により、onionサービスにもアクセスできるようになります。これらのサービスはTorネットワーク内で動作し、プライバシーを重視した正当な情報発信や安全な通信に広く使われていますが、場合によっては犯罪者のリークサイトやアンダーグラウンドフォーラムにも使われています。
実践的なワークフロー
通常の社内ブラウジングから切り離された専用の調査環境の中でTor Browserを開きます。該当するonionサービスにアクセスし、主張の内容、公開時刻、影響を受けた組織、示された期限を記録します。投稿が変更されたり消えたりしてもエビデンスを確認できるよう、ページをキャプチャし、元のURLを保存します。表示されているサンプルは慎重に調べます。データが本物だと結論づける前に、ファイル名、文書の構造、機密でない目印を社内の情報と照合します。何が検証済みで、何が攻撃者の主張にとどまり、何がまだ確認できないかを記録します。不必要に流出したデータをダウンロードしたり再配布したりすることなく、調査結果をインシデント対応プロセスに引き渡します。
このワークフローは、有用な問いへの早い答えを対応チームにもたらします。その投稿は使い回しのノイズなのか、裏付けのない主張なのか、それとも即時の調査を要する信頼できる兆候なのか、という問いです。
ランサムウェア監視の先へ
Torは他の形のセキュリティ調査も支援できます。アナリストは、フィッシングインフラの調査、脅威インテリジェンスの手がかりの追跡、自社ドメインへの言及の監視、盗まれた認証情報やアクセス権がどのように宣伝されているかの調査に使うことができます。
また、研究者が自分の所在地では利用できない、または制限されているセキュリティリソースにアクセスするのにも役立ちます。いずれの場合も、目的は同じです。調査と、それを行う人物の身元やネットワークとの間に距離を作ることです。
置き換えられないもの
Torは完全な匿名性を保証するものではありません。個人アカウントへのサインイン、見慣れたユーザー名の再利用、身元を特定できる情報の開示、見慣れたコミュニケーションパターンでのやり取りは、ネットワーク経路に関係なく研究者を特定しうるものです。
ダウンロードしたファイルには別のリスクがあります。外部のアプリケーションで文書を開くと、Torの外で接続が発生したり、端末に関する情報が漏れたりする可能性があります。疑わしいファイルは、調査セッションから直接開くのではなく、隔離された解析環境で扱うべきです。
また、Torが保護するのは、トラフィックをTor経由で送るよう設定されたアプリケーションだけです。端末からのすべての接続を自動的に保護するわけではなく、別のブラウザーをTorネットワーク経由でルーティングしても、Tor Browserに組み込まれたプライバシー保護は得られません。
隔離された調査用ワークステーション、エンドポイント保護、慎重なエビデンスの取り扱い、法的な助言、明確な調査手順の代わりになるものでもありません。Torが守るのは接続先までの経路です。調査の安全性は、接続の前、最中、後に何が起きるかに引き続き左右されます。
👏 今週の人物
Romain Thomasは、Android、iOS、macOS、Windowsにわたるリバースエンジニアリング、ソフトウェア保護、難読化の分野での仕事で知られるセキュリティエンジニアです。
Romain Tの貢献が特に価値あるものになっているのは、自らが作ったものをより広いセキュリティコミュニティと共有している点です。
Romainが作成したLIEFは、PE、ELF、Mach-Oなどの実行形式を研究者や開発者が解析・変更するのを助けるオープンソースライブラリです。現在、LIEFは多くのリバースエンジニアリング、計装、セキュリティのプロジェクトを支えています。
オープンソースでの彼の仕事には、QBDIとQBDLへの貢献に加え、モバイルアプリケーションの保護を前進させるために彼が始めたプロジェクトOpen Obfuscatorも含まれます。
この表彰は、一つの成功したツールだけに向けたものではありません。複雑なセキュリティの仕事をより身近なものにし、他の研究者がその上に築ける強固な土台を提供してきた長年の歩みに向けたものです。
今週は、その仕事と、その背後にいる人物にスポットライトを当てます。
📅 今週のイベント
今週のイベント：Black Hat USA 2026
Black Hat USAは8月1日（土）に開幕します。最初の4日間は技術トレーニングで、その翌週にサミット、研究ブリーフィング、Arsenalのデモが続きます。
ラスベガスに行かなくても、今週はアジェンダに注目する価値があります。Black Hatで公開される研究は、その後の脆弱性、検知、ツールをめぐる議論を形づくることが多いからです。今年のプログラムでは、自律型AIの脅威、アイデンティティと信頼、インフラセキュリティ、オープンソースの防御ツールに特に焦点が当てられています。
📚 今週の本
Spycraft: The Secret History of the CIA’s Spytechs, from Communism to al-Qaeda
Robert Wallace、H. Keith Melton、Henry R. Schlesinger著
Spycraftは、CIAの技術サービス局（Office of Technical Service）のエンジニアたちが、敵対的な環境のためにカメラ、変装、隠匿装置、通信システムをどのように作ってきたかを明かします。その教訓は今もサイバーセキュリティに当てはまります。技術は変わっても、効果的なセキュリティは、敵、環境、そしてツールを使う人を理解することにかかっています。
😅 今週のミーム
もし今日誰かが組織を去ったとしたら、各システムを手作業で確認することなく、その人に紐づくすべてのアカウント、セッション、トークン、キー、共有認証情報が機能しなくなったことを証明できるでしょうか？
The Breach Brief、Ostorlabチーム：彼らはパスワードを盗んだのではない。偽造したのだ。