攻撃者はRailway顧客の認証情報を悪用してAIを不正利用しました。盗まれたマシンID（機械が保有する認証情報）がモデル蒸留に利用され、その費用が正規の顧客に分散して押し付けられる実態が浮き彫りになっています。
AIモデルの学習や蒸留が増える中、AIトークンは攻撃者にとって「引く手あまた」の通貨になりつつあります。
クラウドホスティング事業者のRailwayは、この脅威を身をもって知ることになりました。同社は、攻撃者が販売目的でAIプロバイダーの認証情報を狙い、モデル蒸留に使われるAIの「中継ステーション」に流していたとして、約26時間に及ぶ攻防を認めました。攻撃者は盗んだ認証情報で約74万ドルのAI不正利用料金を発生させており、最大10万件のワークスペース認証情報にアクセスできた可能性もあります。
Railwayによると、攻撃者はデータベース検索でまずAIプロバイダーのキーを名前で探しており、一部のクエリはクラウド、データベース、決済サービスの認証情報も標的にしていました。
同社はこのインシデントを10月22日に公表し、今週続報となるレポートを公開しました。調査が続いているため、悪用された脆弱性の詳細や規模は明らかにできないとしています。そのうえで、10月21日より前にRailwayへ保存した機密性の高い環境変数については、無効化して再設定するよう利用者に呼びかけています。
Beauceron SecurityのDavid Shipley氏（LinkedIn）は、「AIの認証情報は新たなクレジットカード番号になりつつあります。いわゆるLLMジャッキングは、安価で拡張しやすい金儲けの手段として、クリプトジャッキングに取って代わると見られています」と指摘します。
26時間に及ぶ攻防
攻撃は10月20日に始まりました。ハッカーはRailwayのビルド基盤にあった未知の脆弱性を突き、ファイルシステムの分離機能を回避して内部の認証情報を入手しました。この認証情報を使って保存されたビルド履歴にアクセスし、Railwayの内部ソースコードのコピーを取得しました。さらにそのコードを分析し、侵入を広げるための別の経路を探りました。
続いて攻撃者は、信頼関係の設定不備に関する別の脆弱性を悪用しました。これによりRailwayのインフラへのアクセスをさらに拡大し、顧客の環境変数の復号に使われる認証情報も手に入れました。
Railwayのエンジニアリングチームは約26時間にわたり、交代制で24時間体制の対応にあたりました。状況は悪化の一途をたどり、同社の説明では「エージェント同士の速度競争」の様相を呈したといいます。攻撃者はさまざまな脆弱性を連鎖させて複数のシステム間を横展開し、「多くの侵入経路を並行して探り」ました。防御側もこれに対抗し、経路を並行して堅牢化していきました。
Railwayは「これは、1回の侵害に1回の修正で対応すれば済む事案ではありませんでした」と記しています。
攻撃者は10月21日に「完全に排除」されましたが、システム内にいる間に、顧客の変数の「一部」を入手して復号していました。その数は約10万件、割合にして「多くとも」ワークスペース全体の1.85%です。また、74万ドル分のAI不正利用料金も発生させました。顧客からは、自分のキーが、身に覚えのないコーディングに関する質問への回答や学習データ関連のタスクに使われていたとの報告が寄せられています。Railwayは顧客への補償を進めており、プロバイダーが返金に応じない料金についても対象とする方針です。
ニュースレター
AIに関するニュース、分析、インサイト
AIのリスクとメリットに向き合うIT責任者向けに、各サイトの編集者がお届けする特別シリーズです。
最新のAI情報を毎週火曜日に配信
この侵害では、1,850人を超えるユーザーの連携アカウントトークンも流出しました。GitHubやOAuthのトークンが含まれており、Railwayはこれらをリセットしたとしています。同社はGitHub、GitLab、Anthropic、OpenAI、OpenRouter、SpaceXSI、Stripeなどと迅速に連携し、侵害された可能性のあるキーを無効化しました。
攻撃を受け、顧客には次の対応が推奨されています。データベースへの公開ネットワークアクセスを削除すること、機密性の高い変数とキーをローテーションすること、GitHubアカウントの監査ログを確認してすべてのアプリのアクセス権を見直すこと、Dockerhubなどのレジストリ内の監査ログを確認することです。
自社システムについては、侵害された可能性のある内部ツールをすべて停止し、全キーを更新したうえで、侵入者を完全に締め出したことを確認してから「再度更新した」といいます。さらに、新世代のインフラへ移行し、インフラ運用に使うツールを再構築しました。今後、不審な動きがあった場合にRailwayアプリの権限を一括で無効化できる機能も追加しました。
攻撃者がAIキーを狙う理由
Shipley氏は、AIの認証情報は大規模に収集しても低コストだと指摘します。攻撃者は1社ずつ狙う代わりに、Railwayのようなプロバイダーを攻撃すれば済むからです。入手したアクセス権は、いわゆるAIルーター経由で転売して収益化できます。AIルーターは、利用者が本来なら高額で手が出ない、あるいはそもそも使えないモデルへのアクセスを提供するものです。
このため、こうしたアクセス権はdistillation（蒸留）といった用途で引く手あまたとなっています。蒸留は、大きなモデルの知識を小さなモデルに移し、コストを抑えつつ効率を高める手法です。
Dickson ResearchのFrank Dickson氏によると、あるモデルを別のモデルの回答で大規模に学習させるには数百万件の質問が必要で、1つのアカウントが数百万件も質問すれば目立ちます。盗んだキーを使えば、その質問を何千もの実在の顧客に分散できます。
Dickson氏は「他人の図書館カードを使い、教科書を1ページずつ複写するようなものです」と説明します。最先端のAIは購入すると高額ですが、請求を受けるのはキーの持ち主で、盗んだ側はコストゼロで計算資源を手に入れます。
同氏は「2026年版のクリプトマイニングです。手口は同じで、得られるものが違うだけです」と述べました。
マシンが大半を保有する時代のID管理
Dickson氏は、事実は厳しいものの、Railwayの「驚くほど率直なレポート」は評価に値すると強調します。同社は設定ミスを自ら認め、攻撃者が作成したアカウントをすべて把握できたかは断言できないと認めています。さらに、今後は問題をより迅速に顧客へ伝えると約束しました。
Railwayは現在、有効期間の短い認証情報への移行と、すべての復号操作のログ記録を進めています。Dickson氏は、これは正しい対策であり、顧客のシークレットを預かるすべてのプラットフォームが見習うべきだと話します。
同氏は「Railwayの顧客は、ローテーションするまで、プラットフォームに保存したシークレットをすべて盗まれたものとして扱うべきです」と述べます。ただし、そのローテーションは攻撃者の動きより早く終える必要があります。Wizの調査では、盗まれたキーは窃取から30分以内に動作確認され、4～7日後に大量のトラフィックを浴びせられたことが判明しています。
同氏は、まずAIプロバイダーのキーから着手し、その後にクラウド、データベース、決済の認証情報をローテーションするよう助言します。AIプロバイダーの請求書と利用ログを調べ、社内チームが発生させていないトラフィックがないか確認し、不正な請求があればRailwayに報告します。見覚えのないアドレスからの呼び出しがあれば、アラートを出すようにします。
さらに、1つのキーが与えうる被害を限定することも重要だと言います。すべてのAIキーに厳格な利用上限額と利用アラートを設定し、各キーのスコープをプロバイダーが許す限り絞り込みます。これは実際に効果があります。Wizが調べた事例では、限られたモデルプロファイルに制限していたキーは、攻撃者のトラフィックの大半が制限されました。
一方、Railwayを使っていない企業も、プラットフォーム事業者に2つの質問をすべきです。シークレットはどのように保存されているのか、誰が復号できるのか、という点です。標準的な良い対策は、発行するキーを減らすことです。Dickson氏は「キーのローテーション中に、もっとキーを発行しておけばよかったと言った人は一人もいません」と指摘します。
結局のところ、盗まれたAIキーは本物の金を使い果たし、いまやキーの大半はマシンが保有しているとDickson氏は言います。同氏は「マシンIDは現金のように守ってください。泥棒にとっては、まさに現金そのものなのですから」と訴えました。
