
AIエージェントがGitHubの流出認証情報でクラウドに侵入
Microsoftは2026年11月5日、攻撃者がAIエージェント型の攻撃ツールで公開GitHubリポジトリを探索し、流出した認証情報を悪用していると報告しました。リポジトリはGitHub上でコードを保管する場所です。攻撃に使われたツールとして、MicrosoftはARTEXを名指ししています。
従来は、攻撃者がリポジトリの中身を確認し、発見した鍵を悪用するまでに時間がかかっていました。公開コードから鍵を探す手口は以前からありましたが、AIエージェントは探索から次の攻撃までを自力で進めるため、攻撃者の手作業は大きく減少しました。
ARTEXは10月にも、中国系の集団による攻撃で使われたとMicrosoftが発表しています。Googleも、恐喝グループとスパイ集団の両方がARTEXを使っていると報告しました。

"Searching open code repositories for exposed credentials, secrets, keys, and other authentication material is a well-documented technique that has historically been limited by the time required for human operators to find code repositories, review the data in the repositories, and leverage authentication material for further action." / "However, agentic tooling like ARTEX allows threat actors to not only scan for secrets across multiple repositories at a quicker pace but also use the agents to analyze the output and conduct follow-on attacks, cutting down on the need for the threat actor to have hands-on-keyboard interactions throughout the attack chain." — 冒頭の概要より公式情報を見る →
8月から探索を重ね、10月28日からサインインに成功
Microsoftによると、AIの攻撃ツールは2026年8月からGitHubへ大量のクエリを送信していました。探していたのはログイン情報とアプリの認証情報、それにAIサービスのAPIキーでした。
クエリの多くには標的組織の名前と鍵を探すためのキーワードが含まれており、AIエージェントは狙った組織の鍵を探索していました。 クラウドサービスやAIサービスの名前を組み合わせたクエリも多く見られました。
10月28日からは、盗んだアプリの認証情報によるサインインが、複数テナントで成功し始めました。攻撃者の名前と、被害を受けた組織の数は公表されていません。
"Starting in August 2026, Microsoft observed threat actors using an agentic AI offensive framework to submit large volumes of queries to GitHub for secrets." / "The queries submitted by the AI framework often included the name of a target organization, keywords for secrets, a keyword linked to cloud services, or a keyword linked to another AI service provider." / "As early as October 28, 2026, Microsoft began observing successful service principal sign-ins from the IP address 199.19.77[.]84 involving multiple application IDs across some impacted customers" — 「From exposed secrets to cloud compromise」と冒頭の概要より公式情報を見る →
探索開始から5分で鍵の保管庫からデータを持ち出し
少なくとも1件では、AIエージェントがGitHubで鍵の探索を始めてからわずか5分で、Azure Key Vaultのデータを持ち出しています。Azure Key Vaultは、パスワードや鍵をまとめて保管するAzureのサービスです。
鍵が公開されてから悪用されるまで、数分しかかからない場合もあります。 Microsoftは、公開リポジトリで鍵の流出が判明した組織に対し、その鍵と関連アプリがすでに侵害されている前提で対応するよう勧めています。
"In at least one case, Microsoft observed an AI agent advance from scanning GitHub for secrets to exfiltrating data from Azure Key Vault in just five minutes." / "Organizations that find their secrets exposed in public repositories must assume that the exposed secrets and associated applications are compromised." — 冒頭の概要と「From exposed secrets to cloud compromise」より公式情報を見る →
侵入後はアプリになりすまして鍵とファイルを持ち出し
AIエージェントは盗んだアプリの認証情報で、Microsoftのログイン基盤であるEntra IDのテナントへサインインしました。そこからテナントにつながるAzureとMicrosoft 365のリソースへ侵入し、複数テナントで数十のアプリになりすましています。
狙ったのは、ストレージの鍵や接続文字列、Kubernetesの認証情報などを取得できる操作です。1つの鍵で別の鍵を引き出す手順を繰り返し、侵入範囲を広げていきました。 Azureの契約や権限、AIモデルの配備状況も一覧にして、環境の全体像をつかんでいます。
"The agent successfully conducted service principal sign-ins on dozens of associated applications across multiple tenants." / "The threat actor targeted operations that return credentials, including storage account keys, App Service settings, connection strings and publishing credentials, AI and machine learning (ML) connections and datastores, and Azure Kubernetes Service (AKS) user credentials." — 「Credential abuse via Entra ID」より公式情報を見る →
盗んだ認証情報でSharePointのファイルやメールを閲覧
乗っ取られたアプリは、標的組織のSharePointとOneDriveからファイルをダウンロードし、メールボックスの中身にもアクセスしました。どちらも、そのアプリにもともと与えられていた権限の範囲で行われています。
アプリとしてサインインしたため、ユーザーのパスワードを盗まなくてもファイルとメールを読むことができました。
同じ組織にあるOAuthアプリのトークンを取り、そのアプリとして組織内のクラウドリソースを一覧にした例もあります。OAuthアプリは、OAuthという仕組みで許可を受けて組織のデータにアクセスするアプリです。AIエージェントはAzure DevOpsでも鍵を探索し、Azureの仮想マシンでスクリプトを実行するRun Commandという機能まで使いました。
"The compromised applications subsequently accessed SharePoint and OneDrive in the targeted organization tenants, including file downloads and mailbox-item access." / "The agents once authenticated have also searched Azure DevOps for secrets." / "The agents also used the compromised OAuth application to use the Run Command , which runs scripts in Azure VMs." — 「Credential abuse via Entra ID」と「OAuth application abuse」より公式情報を見る →
AIサービスの鍵や、アプリ提供元の認証情報も狙われる
AIエージェントが繰り返し狙ったのは、大手AIサービスのAPIキーです。Foundry Tools(旧Azure Cognitive Services)を使えるOAuthアプリの鍵も、同じく標的になりました。乗っ取ったAzureのAIサービスを呼び出せるか試し、攻撃に利用しようとした形跡もあります。
多くの組織が使うアプリの提供元で認証情報が盗まれ、そのアプリを導入していた複数企業のテナントに侵入された例もありました。自社から鍵が流出していなくても、使っているアプリの提供元から流出すれば侵入されます。
"During this activity, the AI agents repeatedly demonstrated a focus on credentials that provide access to AI services, such as API keys for major AI service providers and OAuth applications with access to Foundry Tools (previously known as Azure Cognitive Services)." / "including cases where a multitenant application credential was compromised at the source (vendor-owned application) and used to access multiple downstream tenants." — 「OAuth application abuse」と冒頭の概要より公式情報を見る →
AIエージェントは失敗しても方法を変更して再試行を重ねる
AIエージェントはAzureへの要求が失敗すると、書き方を変更して再試行し、成功させていました。書き方の誤りで失敗した3種類の要求は、いずれも約80秒以内に通っています。
攻撃の途中でエラーが出ても止まらないため、1回の失敗を防御の成果と見なすことはできません。 Microsoftはこの動きを、失敗を受けて手順を修正する適応的な振る舞いと分析しました。
"Additionally in this attack the agent’s operations on a victim’s Azure Resource Manager (ARM) instance originating from 199.19.77[.]84 demonstrated sequences consistent with adaptive troubleshooting, where failed cloud API requests were followed by changes to HTTP methods or API versions and subsequent HTTP 200 responses" — 「Cloud API adjustments indicative of adaptive behavior」より公式情報を見る →
APIのバージョンの誤りを約28〜80秒で修正
失敗から成功までの時間(Microsoft Security Blogより)
| 対象 | 失敗した要求 | 成功までの時間 |
|---|---|---|
| Azure Key Vault | 鍵一覧の取得 | 約28秒 |
| Azure SQL | ファイアウォール設定の取得 | 約60秒 |
| Application Insights | ログの問い合わせ | 約80秒 |
Key Vaultでは、最初の失敗から約28秒で、バージョンだけを変更した要求が成功しています。Azure SQLは約60秒、Application Insightsは約80秒で、同じ修正を終えていました。AIエージェントは原因調査に時間をかけず、APIのバージョンを変更して同じ操作をすぐに再実行しました。
"Approximately 28 seconds after the first failed response, a batch rerun began against the same vault resource paths using the ARM API version 2023-07-01 and returned HTTP 200." / "Approximately 60 seconds after that request, a matching GET began using a supported version and subsequently returned HTTP 200." / "Approximately 80 seconds after the failed request, another POST began against the same endpoint, specifying a supported API version, and subsequently returned HTTP 200." — 「Cloud API adjustments indicative of adaptive behavior」より公式情報を見る →
送信元IPでは防げず、おとりの仕組みで攻撃が減る
ARTEXはデフォルトで、Nmapやcurl、wget、Playwright経由のヘッドレスChromiumなど、既存の侵入テスト用ツールを使います。これらのツールの通信には、デフォルトのユーザーエージェント文字列が付くのが特徴です。
ただし、IPアドレスやユーザーエージェントは、AIエージェントがすぐに変更できます。短い時間に多種類の要求を送り、同じ手口を少しずつ変えながら繰り返す動きのほうが、見分けるポイントになります。送信元のIPアドレスは変更されるため、動きの特徴で見分け、おとりで時間と予算を使わせる方が効果的です。
Microsoftが勧める仕掛けは3つあります。AIエージェントを誘い込むおとりの標的(ハニーポット)、時間と予算を浪費させる仕組み、攻撃が成功したと誤認させる偽装の応答です。Microsoftの試験では、本物の資産に到達する攻撃トラフィックが減少しています。
"For example, ARTEX by default uses Nmap, curl, wget, Python HTTP clients, Norma SDK WebFetch, and headless Chromium through Playwright, among others." / "While blocking network traffic with these characteristics will not stop an attack by an AI agent, which will quickly change them, identifying them can alert defenders to the activity." / "In Microsoft’s testing, these controls helped reduce the attack traffic reaching real assets and produced high-confidence, attribution-quality signal." — 「Defending against agentic AI attacks」より公式情報を見る →
開発者とクラウド管理者がいま確認すること
侵入経路はコードに残った鍵で、被害範囲を左右したのはアプリ権限でした。したがって、開発者は鍵をコードに置かない仕組みへ移行し、クラウド管理者はアプリ権限とサインインログを点検します。
JPCERT/CCの注意喚起とセキュアコーディング規則も、鍵をコードに直接書かないこと、権限を最小限にすること、流出した鍵をすぐ無効化することを対策に含めています。

AIツールの設定ファイルからも、鍵がGitHubへ流出しています。Claude Codeの許可設定に書かれていた認証情報が、公開リポジトリから見つかりました。経緯は関連記事(Claude Codeの許可設定から認証情報2,539件がGitHubに漏えい)にまとめてあります。
"API利用者やAPIトークンには必要最小限の権限のみを付与する" / "APIトークンには適切な有効期限を設定し、長期間有効なトークンの使用を避ける" / "不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする"公式情報を見る →
開発者は流出した認証情報を再発行し、コードから削除
開発者がコードから鍵を消しても、編集履歴やキャッシュ、アーカイブにある鍵の写しは消えません。したがって、流出した鍵は作り直したうえで、コードに鍵を置かない仕組みへ移します。
公開リポジトリに含まれる認証情報を洗い出す
GitHubは公開リポジトリに含まれる鍵を自動スキャンしています。設定すれば自社の鍵が他人の公開リポジトリに流出した場合も検出できるので、自社のリポジトリと合わせて検出対象にしてください。
見つかった認証情報は削除するだけでなく無効化して再発行
編集履歴やキャッシュに写しが残るため、コードから消した鍵も、無効化するまでは攻撃者が使い続けることができます。鍵を無効化したら、新しい鍵を発行してアプリに再設定してください。
プッシュ保護とマネージドIDでコードに鍵を置かない
GitHubのプッシュ保護は、鍵を含むコミットの送信を事前に阻止する機能です。マネージドIDは、コードに鍵を置かずにアプリを認証させるAzureの仕組みで、Microsoftは鍵による認証からの移行を勧めています。
鍵をコードに書かなければ、攻撃者がリポジトリを探索しても発見される鍵はありません。JPCERT/CCの規則MSC18-Cにも、機密情報をプログラムにハードコードしないという規定があります。

"In addition to removing the secrets from the code base, affected organizations should immediately rotate any exposed keys or credentials." / "Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure." / "Push protection can also block supported secrets before they’re pushed." / "While storing long-lived application client secrets in code is a common practice, using managed identities for application authentication eliminates the possibility of secret exposure in code, manual processes associated with secret management, and barriers to securely scaling applications." — 対策の節より公式情報を見る →
"プログラム内に機密情報をハードコードしない。"公式情報を見る →
クラウド管理者はアプリ権限とサインインログを確認
今回の攻撃者はアプリとしてサインインし、そのアプリにアクセス権限があるリソースからデータを持ち出していました。つまり、アプリに与える権限が広いほど、鍵の流出で持ち出されるデータは増えます。
アプリ権限を必要最小限にする
持ち出されたKey VaultとStorageのデータは、乗っ取られたアプリにアクセス権限がある範囲に限られていました。アプリのアクセス範囲を限定しておけば、鍵を盗まれても持ち出されるデータを最小限に抑えられます。アプリに与える権限は、そのアプリが必要とするリソースと操作だけにしてください。
公表されたIPアドレスからのサインインをログで確認
199.19.77[.]84と199.19.77[.]18からのサインインは、失敗した分も含めてサインインログで確認できます。エラーコードAADSTS7000215(無効な鍵)やAADSTS7000222(期限切れの鍵)が出ていれば、誰かが自社アプリの鍵を持っています。失敗の直後に成功が続くサインインは、すでに鍵が使われている兆候なので、至急の対応が必要です。
アプリを登録できる人を限定
ユーザーによるアプリ登録を「いいえ」に設定し、アプリ開発者のロールを特権ユーザーだけに与えれば、テナントに作られるアプリ数を抑えられます。管理者が把握していないアプリが少ないほど、鍵の流出経路も少なくなります。有効期限の無い長期トークンを使わないことも、JPCERT/CCの注意喚起に含まれる対策です。
"Organizations can reduce exposure by protecting workload identities and secrets, enforcing least privilege, safeguarding recovery resources, and enabling relevant Microsoft Defender for Cloud protections." / "Review Entra service principal and non-interactive sign-in logs for 199.19.77[.]84 and 199.19.77[.]18 including failed attempts." / "Sign-in errors AADSTS7000215 (invalid secret) or AADSTS7000222 (expired secret) indicate someone holds a credential for your app; a failure followed by a success is urgent." / "This can be achieved by setting the ability for users to register apps to “No” and limiting the application developer role to privileged users." — 対策の節と「Detection and hunting」より公式情報を見る →



