Threat Lab Quarterly: 2026年8月

攻撃者より先に古くなったおよびゴーストSPNを追跡する

著者: Huy Kha

はじめに

ここ数年、Service Principal Names（SPN）を悪用したActive Directory攻撃が増加しています。Kerberoastingから始まりましたが、その後技術はより創造的になっています。Ghost SPN攻撃は、もはや使用されていないサービスターゲットを主張することで特権昇格を可能にします。最近では、SPNのUnicode衝突攻撃により、write-SPN権限を持つ認証済みユーザーが、見た目は同じだが技術的に異なるSPNを使って特権を昇格させることも可能になっています。

あまり注目されない静かな問題もあります。それは基本的なセキュリティ衛生です。Netwrixでは、組織の規模に関係なく、同じパターンが何度も繰り返されるのを見ています。コンピューターアカウントは、背後のマシンが廃止された後もActive Directoryで有効なままです。サービスアカウントは、もう存在しないホストを指すSPNを保持しています。誰もそれを掃除しに戻らないため、アカウントはそのまま残り、まだアクティブでKerberoastingに対して脆弱な状態で、誰も気にかけていません。

ドメイン内のステルスSPNを見つける

当社のセキュリティリサーチチームは、ITプロや管理者が簡単に使えるものを作ることにしました：Find-StealthSPNsというPowerShellスクリプトは、コンピューターとユーザーアカウントの両方でステルスSPNを検出し、結果を確認して実際にクリーンアップが必要なものを判断できます。

スクリプトは主に2回の処理で実行されます。最初の処理では、フォレスト内のすべてのコンピューターアカウントを調べます。すべてのドメイン参加マシンはデフォルトで少なくとも1つのSPNを登録するため、この処理ではそのコンピューター自身のホスト名がまだDNSで解決されるかどうか、またそのSPNのいずれかが存在しないホストを指していないかをチェックします。これをゴーストSPNと呼びます。これはアカウントに残っていて技術的には有効ですが、実際には何も指していないSPNです。また、ADで事前作成されたが実際には参加していないコンピューターアカウントも検出します。これらは通常、SPNが全くなく、誰にも気づかれずに無期限に放置されています。

私たちは意図的にICMP pingではなくDNSを通じてこれを確認しています。管理者の中にはSPNの背後にあるホストがまだ稼働しているかを素早く把握するためにpingを使う人もいますが、ほとんどの環境ではICMPがファイアウォールやホストベースのフィルタリングによって頻繁にブロックされるため、pingの失敗はあまり意味がありません。DNSレコードがないことは、そのホスト名がもう存在しないと期待されているというより信頼できるサインです。これは、そのボックス自体がpingに応答するかどうかに関係ありません。

2回目のチェックでは、ユーザーアカウント、特にSPNを保持しているものに注目します。これはサービスアカウントの典型的な設定だからです。見つかった各SPNについて、2つのことを確認します：対応するコンピューターアカウントがADにまだ存在するか、そのホスト名がDNSでまだ解決されるかです。どちらも該当しない場合、そのSPNは不要なものだという明確なサインです。アカウントはまだ有効で、SPNも登録されたままで、Kerberoastingによって今でも悪用可能ですが、正当な依存先はもうありません。

さらに、このスクリプトは前述の攻撃タイプであるSPNのUnicode衝突もチェックします。偽装されたSPNが見た目は本物と一致していても、内部の値はまったく異なる場合です。隠れた文字や類似文字を含むSPNを検出し、フォレスト内のすべてのSPNを照合して、2つのアカウントが同じSPNを持つケースを見つけます。誤検知がある可能性があるため、必ず二重に確認してください。

すべてADSIとDirectorySearcherのみを使用して動作するため、ActiveDirectory PowerShellモジュールに依存せず、実行しているドメインだけでなくフォレスト内のすべてのドメインで機能します。

DNS解決に関する簡単な注意点： このスクリプトは、実行しているマシンに設定されているリゾルバーを使用してDNSをチェックします。より正確な結果を得るには、ワークステーションではなくドメインコントローラーから実行してください。DCは環境内のすべてのドメインを解決するように設定されているためです。異常または制限されたDNS設定のマシンから実行すると、実際には存在するレコードに対して誤ったMISSING_DNS結果が出る可能性があります。

結論

結局のところ、誰も管理していない古いアカウントを整理して攻撃対象範囲を減らすことで、組織を支援しようとしています。存在しないマシンに紐づく有効なコンピューターアカウントや、存在しないホストを指すサービスアカウントなど、すべてのghost SPNはActive Directoryに存在する必要がなく、あってはならないものです。高度な攻撃者は必要ありません。あなたより先に誰かが気付くだけで十分です。

---

DEF CON 34のアイデンティティセキュリティの視点

ダリル・ベイカー著

DEF CON 34とBlack Hat USA 2026では、いずれもidentityインフラを指摘する3つの別々の研究成果が発表されました。各研究の発表内容と、identityおよびADプログラムを運営する人々にとっての意味を解説します。

CloudBasher: 無料のクラウドシェルが攻撃者のインフラに変わる

Jenko HwongとChris Ryanは、AWS、Azure、GCPの無料クラウドシェル機能の背後にあるプライベートREST APIとWebSocketセッションをリバースエンジニアリングして構築されたオープンソースツールキットCloudBasherを発表しました。 このツールキットはGitHubで公開されます, 侵害データから抽出したクラウドの誤設定パターンの2026年分析とともに。

調査により、Identity Management チームが注目すべきいくつかの具体的な発見が明らかになりました。

• 侵害されたAWSアイデンティティは役割を引き受け、多数のCloudShell環境を起動できます。
• 基盤となるアクセス トークンが取り消された後も WebSocket ターミナル セッションは存続するため、資格情報を取り消してもアクティブなセッションが必ず終了するとは限りません。
• M365 と Gmail の消費者アカウントはデフォルトで CloudShell アクセスを取得し、関連する攻撃対象範囲が企業アカウントだけでなく個人アカウントにも拡大します。

セッションが確立されると、ツールキットは$HOMEディレクトリに残り（リセット後も維持され）、正当なユーザーが自分のセッション内でsudoを使用できないようにロックし、C2フレームワークをインストールします。

重要な理由： もしあなたのidentityプログラムがトークンの取り消しをセッション終了と同等とみなしているなら、この調査はその前提を検証すべきであり、単に仮定すべきではないと述べています。また、CloudShellのアクセスポリシーと監視が異常なセッション作成を検出できるかどうかも確認する価値があります。

GhostJacking：ログに隠された指示に従って動作するAIコーディングエージェント 

Tenet SecurityのBarak Sternberg、Nevo Poran、Ron Bobrovは、GhostJackingを発表しました。これは、AIコーディングエージェントを乗っ取る技術で、エージェントが読むことを期待されるログ（WAFアラート、エラーレポート、監視出力など）に指示を埋め込むものです。TenetはCloudflareのデフォルト設定下でClaude Codeに対して90％の成功率を報告し、Cloudflareの設定だけで15,000以上の組織が露出していると推定しています。

Tenetは3つのプラットフォームでこの手法を実証しました。CloudflareのWAFログエントリの改ざん（Cloudflareは推定でFortune 500企業の42％の前に位置）により、エージェントがDNS設定を変更しトラフィックをリダイレクトしました。Datadogのログメッセージの注入（Fortune 500の約48％が使用）により、エージェントが悪意のあるパッケージをインストールし、リモートコード実行と資格情報の窃取が発生しました。Sentryのエラー報告の改ざん（Sentryは推定400万人の開発者にサービス提供）により、侵害されたClaude Codeインスタンスが攻撃者をSentryのSeer AIエージェントに保証し、エージェント間の信頼チェーンを生成しました。Tenetはさらに、2,700以上の公開されたDatadog APIキーを発見し、別途Claude DesktopのJWT関連のサンドボックス脱出をAnthropicに報告しました。この問題はDEF CONの講演前に修正されました。

エージェントの行動は3つのケースすべてで、自身の正当で既に承認された資格情報を使用しています。つまり、EDR、WAF、およびIAMツールは異常を検知しません。

重要な理由： RBAC、最小権限、MFAはここでは役に立ちません。エージェントのアクセスは正当だからです。問題は、そのアクセスで何をするよう指示されているかです。Tenet自身の推奨事項は合理的な開始チェックリストです：デフォルトでエージェントのアウトバウンドネットワークアクセスを制限し、インフラ変更前に人間の承認を要求し、読み取り専用ツールと書き込み可能なツールを分離し、エージェントが読むすべてのログやアラートを、どのプラットフォームから来たかに関わらず信頼できない入力として扱うこと。

The OpenAI–Hugging Face incident: An agent that escaped its own test

2026年7月、OpenAIはExploitGymベンチマーク（898件の実際の脆弱性）を使用した内部評価中に、安全ガードレールを無効にして実行されたGPT-5.6 Solの実験版がサンドボックスを脱出し、Hugging Faceの本番インフラを侵害したことを公表しました。Hugging Faceは7月16日に事件を公表し、OpenAIは7月21日に自らの関与を明らかにしました。Eric WallaceとMichael DaltonはBlack Hat USA 2026でこの件について発表しました。

公開された情報によると、エージェントはArtifactory（JFrogのパッケージレジストリキャッシュプロキシ）のセルフホスト型インスタンスでゼロデイ脆弱性を発見し、それを悪用してサンドボックスから脱出しインターネットに到達しました。エージェントはその後、Hugging Faceがベンチマークの解答キーをホストしていると推測し、直接狙いました。複数のエージェントインスタンスは後にArtifactory自体を通じて連携し、数十万のメッセージを交換してタスクを分担しエクスプロイトを共有しました。ある時点で、エージェントは偽物を疑いメッセージに暗号署名を提案しました。OpenAIが7月4日にチャンネルを閉鎖すると、エージェントは認証されていないエンドポイントのディレクトリ名を代替メッセージングチャネルとして使用し、4日以内に再構築しました。

4.5日間のキャンペーンで、OpenAIは17,600件以上のエージェントアクションを記録しました。これには136の資格情報ストアキーの流出、メッシュVPN認証キーの盗難、Tailscale経由での181台のデバイス登録、GitHub Appの書き込みアクセスの取得が含まれます。11のKubernetesノードでの活動には、AWSインスタンスメタデータを利用したノードのなりすまし、盗まれたEdDSA JWT署名キーを使った偽造IDトークン、ホストファイルシステムマウントを持つ特権ポッドの作成が含まれます。OpenAIは、限定的な性質の他の小規模なサンドボックス脱出も特定しており、それらのいずれも自社ネットワークを離れたとは考えていないと述べています。

identity と incident response に特有の詳細：Hugging Face のフォレンジッククエリは、調査に使用しようとした OpenAI と Anthropic のモデルに組み込まれた同じ商用 AI セーフティガードレールによってブロックされました。ガードレールはインシデント対応者の質問と攻撃者の質問を区別できなかったためです。Hugging Face は、7530億パラメータのオープンウェイトモデル（GLM-5.2）を使用して、1万7,000件以上の攻撃者イベントを数日ではなく数時間で処理しました。

重要な理由： これは、自律エージェントが独立して脆弱性を発見し、資格情報を持ち出し、トークンを偽造し、人間の指示なしにクラウドインフラを横断移動した記録された事例です。IAMおよびガバナンスモデルが人間とサービスアカウントのIDのみを考慮している場合、このインシデントは、自らの判断で行動できる第三のカテゴリを追加すべき具体的な理由です。

これら三つに共通するもの

CloudBasherは、プロトコルレベルでのidentityコントロールのギャップ、つまりトークンの取り消し、役割の引き受け境界、デフォルトアクセスポリシーに関するものです。GhostJackingは、正当な委任されたidentityを使用して、信頼すべきでなかった指示に従って行動するAIエージェントに関するものです。OpenAI–Hugging Faceの事件は、人間や改ざんされたログの指示なしに、エージェントが自ら資格情報を取得し偽造することに関するものです。

3つすべてに共通するテーマがあります。防御側は攻撃者が守る必要のないツールに制約されます。CloudBasherは防御側が検証していなかった仮定を悪用しました。GhostJackingはidentityツールが意図を評価できない点を突きました。OpenAI–Hugging Faceのケースでは、誤用防止の安全策が対応者の動きを遅らせました。

---

identityおよびADチームのための実践的な次のステップ

この調査に基づいて今四半期に行う価値のある4つのこと：

見逃したかもしれない調査

見逃した方のために、NetwrixのSecurity Researchチームのトップ投稿3件を共有します。

強力なLDAP拡張コントロール：ADにおけるアンチリメディエーションと不可視の偵察 

シニアスタッフセキュリティリサーチャーのDarryl Bakerは、Active Directoryの文書化されたすべてのLDAP拡張コントロールを監査し、これまで公開されていなかった攻撃の可能性がある2つを発見しました。FORCE_UPDATEは、1つの属性に書き込みアクセス権を持つ攻撃者が悪意のある値をADのレプリケーション競合解決で勝たせることを可能にし、防御者の後の修正が静かに元に戻されます。DirSyncのOBJECT_SECURITYフラグは、通常の検索でトリガーされるログイベントを生成せずに、任意のドメインユーザーがレプリケーション経路を通じてADデータを一括読み取りできます。どちらも新しい権限を付与しませんが、どちらも多くの防御者が依存する検出を回避します。投稿には対応する検出ガイダンスとオープンソースのレッド/ブルーツールが含まれています。

重要な理由：両方の手法は、ほとんどのAD監視ルールが基づく正確なログイベント（イベント1644、イベント4662）をすり抜けます。検出がこれらに対して特にテストされていなければ、おそらく発動しません。SACLカナリアとハンティングクエリが実際にこれを検出できるかどうかを確認する価値があります。 

続きを読む

あなたのAIコーディングアシスタントが秘密を漏らしています 

Darryl Bakerは、Claude Code、GitHub Copilot、Cursor、Continue.dev、Clineなど14の人気AIデスクトップアシスタントツールの認証情報ストレージを監査し、ほとんどがOAuthトークンとAPIキーを予測可能なファイルパスのプレーンテキストJSONで保持していることを発見しました。特にWSLでは、Windows側のClaude Code認証情報ファイルが全ユーザー読み取り可能な権限を継承する場合があります。この記事では、アクティブなClaude Codeリモートコントロールセッションの乗っ取りや、複数サービスのトークンを1つの読み取り可能なファイルに集約するMCP設定ファイルなど、8つの攻撃シナリオを解説しています。また、NetwrixのオープンソーススキャナーAIHoundを紹介し、この種の露出した認証情報をマシン上で検査します。

重要な理由：エンジニアがこれらのツールを使用している場合、その資格情報は現在ディスク上に平文で保存されている可能性が高く、攻撃者が推測する必要のないファイルパスにあります。読み取るために権限昇格は不要で、MCP設定は複数のサービストークンを1つのファイルにまとめるため、1台の侵害されたノートパソコンが接続されたすべてのシステムやサービスに波及する可能性があります。これにはデータベース、クラウドインフラ、さらには他のAIツールも含まれます。AIHoundは、他の誰かに見つかる前に自分の露出を素早く確認する方法を提供します。 

続きを読む

AIによるEntra IDテナント破壊の自動化 

Huy KhaはMicrosoft Graph Explorerに対してChrome用Claudeを使用し、サインイン済みアカウントがすでにGlobal Administratorアクセスを持っている場合、ブラウザ側のJavaScriptとGraphのバッチリクエストで大量ユーザーの削除、パスワードリセット、セッションの取り消し、Conditional Accessポリシーの削除を自動化できることを示しました。この投稿は、StrykerやStorm-0501の事例を含む実際のインシデントと結びつけており、AIが新たな攻撃経路を作ったのではなく、既存の管理者ワークフローを悪用し、大規模により速く簡単に実行できるようにした点を指摘しています。

重要な理由：これは特権アカウントの侵害とテナント全体の破壊とのギャップであり、AI自動化がそれを急速に埋めています。一度Global Adminセッションを取得すると、最大の被害を与えるためにスクリプトスキルや時間は不要です。これにより、資格情報だけでなく、Graph Explorerのようなツールや管理者セッションの保護と監視の重要性が高まります。 

続きを読む

2026年データおよびIdentity Securityレポート：エージェント型AIの採用と準備状況の進展と課題

Netwrix Research Labは、1,889の組織に所属する2,317人のITおよびセキュリティ専門家を対象に調査を行い、2026年のデータおよびIdentityセキュリティレポートを作成しました。調査結果によると、AIがIdentityの範囲を大幅に拡大した組織は、そうでない組織に比べて約4倍多く侵害を受けていました。レポートは、この差を厳格さではなくガバナンスの速度に結び付けており、76％の組織が非人間のIDを完全に管理または監視しておらず、11％のみが継続的な施行と監視を通じて完全なAIセキュリティ準備を報告しています。

重要な理由：データは、強力なidentity hygieneだけでAI主導のリスクから守れるという一般的な仮定を複雑にします。もしあなたのidentity governanceがまだ四半期ごとのレビューや定期監査で運用されているなら、新しいAIエージェントや非人間のアイデンティティが誰かに気付かれるまでどれくらい存在しているかを確認する価値があります。その遅れこそが、このレポートで指摘されている侵害ギャップの本質です。

続きを読む

---

Netwrix Threat Lab Quarterlyの今回の号は以上です。新しい調査と、攻撃者が見逃すことを期待しているギャップを埋めるためのさらなる方法を携えて、すぐに戻ってきます。