投稿者 global-ai-media 
サイバーセキュリティ企業のCybleが、リモートアクセス型トロイの木馬（RAT）である「SURXRAT」の亜種がHugging Faceから大規模言語モデル（LLM）モジュールをダウンロードしていることを報告しました。この事例は、単なるマルウェアの機能拡張にとどまらず、企業が信頼するAIプラットフォームがサイバー攻撃の隠れ蓑として利用されるリスクを浮き彫りにしています。
Hugging Faceを通信の隠れ蓑にする手口
Cybleの調査によると、ArsinkRATのコードをベースにしたマルウェア「SURXRAT」の最新バージョンにおいて、Hugging FaceのリポジトリからLLM関連のファイルをダウンロードする挙動が確認されました。この挙動の意図するところは、単にローカルでAIを動かすことだけではない可能性が高いと考えられます。
攻撃者の視点に立つと、Hugging Face（huggingface.co）のようなドメインは、多くの企業のファイアウォールやセキュリティ製品において「信頼できる通信先」としてホワイトリストに登録されています。特に現在、多くの企業がLLM活用を推進しており、開発部門やデータサイエンス部門からHugging Faceへの通信量は増大する一方です。攻撃者はこの「正規の業務通信」にマルウェアの通信を紛れ込ませることで、検出を回避しようとしているのです。
AI開発環境特有のサプライチェーンリスク
今回の事例は、AI開発におけるサプライチェーンリスクの一端に過ぎません。日本国内の企業においても、Hugging Face上のモデルを安易に社内環境へダウンロードし、利用するケースが増えています。しかし、そこには以下の2つの大きなリスクが潜んでいます。
一つ目は、今回のようにプラットフォーム自体が攻撃インフラの一部として悪用される「通信の正当性」の問題です。セキュリティ監視チーム（SOC）が「AI開発だから」という理由でHugging Faceへの大容量通信を無条件に許可している場合、データの持ち出しやC2サーバー（指令サーバー）からのペイロードダウンロードを見逃す可能性があります。
二つ目は、「モデルファイルそのものの安全性」です。Pythonで一般的に使われるモデル保存形式（Pickle形式）には、読み込み時に任意のコードを実行できる仕様が含まれています。攻撃者がHugging Face上に「高性能な最新モデル」を装って悪意あるコードを含んだモデルを公開し、それをエンジニアがダウンロードして実行することで感染する「AIサプライチェーン攻撃」のリスクは、理論上だけでなく現実の脅威となりつつあります。
日本企業におけるガバナンスの課題
日本の組織文化として、現場の改善活動やPoC（概念実証）が先行し、IT部門の正式な承認プロセスを経ずにオープンソースソフトウェア（OSS）が利用される「シャドーIT」ならぬ「シャドーAI」が発生しやすい傾向にあります。
「有名なHugging Faceにあるモデルだから安全だろう」「GitHubのスター数が多いから問題ないだろう」という性善説に基づいた判断は危険です。また、開発者が利便性を優先し、社内ネットワークから外部のリポジトリへ直接接続することを強く要望するケースも多く、セキュリティ部門との間で摩擦が生じることもあります。
日本企業のAI活用への示唆
今回のSURXRATの事例を教訓に、日本企業は以下の対策を検討すべきです。
- 通信制御の見直しと可視化： Hugging Face等のAIプラットフォームへの通信を全許可するのではなく、必要に応じて特定の組織やモデルリポジトリのみに制限する、あるいは通信内容を検査する仕組みを導入する。
- モデル形式の安全確保： 原則として、任意のコード実行リスクがあるPickle形式（.bin, .pklなど）ではなく、より安全な「Safetensors」形式のモデル利用を推奨・強制する運用ルールを策定する。
- 社内リポジトリの構築： 外部から直接モデルをダウンロードさせるのではなく、一度セキュリティチェックを通したモデルのみを配置する「社内版モデルリポジトリ」を構築し、開発者はそこから利用するフローを確立する。
- セキュリティ部門とAIチームの連携： 開発のスピードを阻害しないよう、AI特有のリスク（プロンプトインジェクションやモデル汚染など）を理解したセキュリティガイドラインを策定し、現場への啓蒙活動を行う。
AIの活用は企業の競争力を左右する重要な要素ですが、同時に新たな攻撃経路を開くことにもなります。「信頼できる場所」こそが攻撃者に狙われるという認識を持ち、ゼロトラストの原則をAI開発環境にも適用していくことが求められます。