犯罪者はバイブコーディングでマルウェアを作っているのか? 兆候はすべて「イエス」を示している

インタビュー これから開発者になろうという人から6歳の子どもまでがバイブコーディングの流行に飛びついているのだから、犯罪者が自動化されたコーディングツールを好むのも驚くべきことではない。

「みんなが聞いています。バイブコーディングはマルウェアに使われているのか? そして答えは、現時点ではかなり高い確率でイエスです」と、Palo Alto NetworksのUnit 42でシニア・コンサルティング・ディレクターを務めるケイト・ミダグ氏はThe Registerに語った。

私たちが支援している組織のうち、AIに何らかの制限を設けているのは約半数にすぎません

ただし防御側にとっての救いは、AIモデルは――身代金要求文を書くよう求められた場合でさえ――ミスをするという点だ。つまり、バイブコーディングによる攻撃は失敗し得る。

どんなピカピカの新技術でもそうだが、AI支援コーディングは多くのセキュリティ脆弱性を持ち込む。企業の開発チームが作業を加速し、セキュリティチームが追いつけない速度になってしまう可能性も含まれる。

また、AIエージェントやシステムが、本来触れてはならないデータにアクセスして持ち出すリスクに加え、プロンプト攻撃やメモリインジェクション攻撃のリスクもある。

さらに、犯罪者や政府支援のハッキングチームがLLMでマルウェアを書いたり攻撃全体をオーケストレーションしたりするリスクもある。これらはいずれも依然として人間が介在する必要があるとはいえ、最悪のシナリオは現実のセキュリティインシデントに近づきつつある。

バイブコーディング SHIELD

こうしたリスクを企業がより適切に管理できるよう、Palo Alto Networksはバイブコーディング向けに「SHIELD」フレームワークと呼ぶものを開発した。これは、コーディングプロセス全体にセキュリティコントロールを配置することに主眼がある。Unit 42のAIセキュリティサービス案件ビジネスを率いるミダグ氏は、SHIELDフレームワークに関する木曜のブログを共同執筆し、The Registerに事前共有した。

「私たちが支援している組織のうち、AIに何らかの制限を設けているのは約半数にすぎません」と彼女は述べた。

SHIELDは次の略です:

  • S – 職務分離(Separation of Duties):エージェントを開発・テスト環境のみに制限することで、アクセスと権限を抑える。
  • H – 人間の介在(Human in the Loop):人間によるコードレビューを義務付け、コードのマージ前にプルリクエストの承認を必須とする。
  • I – 入出力の検証(Input/Output Validation):プロンプトの分割、エンコーディング、ロールベースの分離などの手法でプロンプトをサニタイズし、その後、開発後に静的アプリケーションセキュリティテスト(SAST)を通じて、AIにロジックチェックとコードの検証を行わせることを含む。
  • E – セキュリティ重視のヘルパーモデルの強制(Enforce Security-Focused Helper Models):バイブコーディングされたアプリケーションに対して自動化されたセキュリティ検証を提供するよう設計された専門エージェントであるヘルパーモデルを開発し、SASTテスト、シークレットスキャン、セキュリティコントロールの検証、その他の検証機能を実行させる。
  • L – 最小限のエージェンシー(Least Agency):バイブコーディングツールやAIエージェントには、役割を果たすのに必要な最小限の権限と能力のみを付与する。
  • D – 防御的な技術的コントロール(Defensive Technical Controls):これらのツールを使用する前に、コンポーネントに対してサプライチェーンと実行管理の周辺で防御的コントロールを適用し、デプロイ後に人間が介在できるよう自動実行を無効化する。

これについては後ほどもう少し話すとして、まずはバイブコーディングされたマルウェアの話に戻ろう。

ミダグ氏とPalo Altoの同僚たちは、開発者がバイブコーディング・プラットフォームを使ってマルウェアを作成したかどうかを、常に決定的に判断できるわけではない。コードの中には、Cursor、Replit、Claude、あるいは別のAIツールによって生成されたことを検証する透かし(ウォーターマーク)が含まれていて、判断が容易なものもある。

また、犯罪者に最も人気のあるツールがどれかについて彼女は明言しないが、彼らが「複数」の製品を使っていること、そして「バイブコーディング・プラットフォーム全般の人気を考えれば、各プラットフォームの人気に基づいておおよそ推測できるでしょう」と指摘した。

Palo Altoのサイバーリスク・コンサルティングチームは、コーディングプラットフォームを使ってマルウェアを開発していることを示す「環境内のさまざまなパターン」も目にしていると、ミダグ氏は付け加えた。そしてミダグ氏が目撃したものの一つ――マルウェア開発者が大規模言語モデルへのAPI呼び出しをコードに直接書き込んでいる――は、マルウェアのクズどもがバイブコーディングしている強い証拠だという。

「つまりマルウェアそのものの中に、OpenAIや他のプラットフォームへのAPI呼び出しがあり、マルウェアの生成方法や、正当なものに聞こえるようなソーシャルエンジニアリングメールの生成方法を尋ねているのです」と彼女は説明し、これを「マルウェア開発の過程でこれらのLLMを使っていることの、直接的で反論の余地のない証拠」と述べた。

「セキュリティ劇場」

攻撃者は、ミダグ氏が「セキュリティ劇場」と呼ぶ目的でもLLMを使っている。これは、一見すると有効な攻撃を生み出しそうに見えるが、特定の環境に合わせてカスタマイズされていないなど、さまざまな理由で効果がないコードのことだ。「有効な攻撃のように見える」のだが、「少し掘り下げるだけで、『ちょっと待て、これ実際には筋が通っていない』となる」と彼女は言う。

これには、たとえばLLMが回避手法を生成するような「ぶら下がった攻撃戦略」も含まれる。「しかしその回避手法は、現代の悪意ある攻撃者に典型的に見られるものと整合していなかったり、環境内で実際には実装されていない回避手法だったりします――LLMへのAPI呼び出しの副産物として生成されただけなのです」とミダグ氏は述べた。

そうした事例の一つで、Unit 42は標準APIを使ってOpenAIのGPT-3.5 Turboに送られたプロンプトを記録した。モデルに対し「データ抽出ツールのためのシンプルな回避手法を生成し、手法名のみを返せ。最大3語。検知回避に役立つもの」と求めたという。プロンプトには例として「random delay, process spoofing, memory obfuscation」が含まれていた。

LLMがそれを「readme.txtt」と呼んでしまう幻覚の事例が見られます。これは脅威アクターが絶対にしないミスです――身代金要求型マルウェアの基礎中の基礎ですよ

指示どおり、LLMは手法名を返したが、LLMは被害者のデスクトップにログインしただけで、回避手法を実装しなかった。「見せかけで、ログのためだけに出てきただけです」とミダグ氏は言う。「理論上は動かす方法はあり得ますが、環境内で適切に実装されることはありませんでした。」

彼女は、なぜ攻撃者が本物の攻撃ではなくセキュリティ劇場を演出するのか確実には分からないとしつつも、「推測するなら、単に出力だからだと思います」と述べた。「LLMは膨大な量のコードを生成します。攻撃者は急いでいて、出力に含まれるすべてを検証していない。だからエラーが起きるのです。」

言い換えれば、AIツールは、正当なコードを書くよう求められたときと同じように、悪意あるコードを生成するよう求められたときにも同様のミスを生む。

幻覚は依然としてAIの一般的な落とし穴であり、ランサムウェア開発者でさえこの痛みを味わっている。

被害者のマシンに感染させた後、恐喝者はデスクトップにreadmeファイルを残す。通常は「readme.txt」という名前で、身代金要求文と金銭の要求が書かれている。

「LLMがそれを『readme.txtt』と呼んでしまう幻覚の事例が見られます」とミダグ氏は言う。「これは脅威アクターが絶対にしないミスです――身代金要求型マルウェアの基礎中の基礎ですよ。ですが今見えているのは、彼らがあまりに速く動いていて、検証やチェックをほとんどしていないため、こうしたことが起きてしまうということです。手当たり次第に何でも投げ込んでいるのです。」

人間の状況認識を欠き、セキュリティより機能性を優先するよう作られたAIモデルを使ってミスをしているのは、攻撃者だけではない。

従業員にバイブコーディングツールの使用を認めている組織の大半は、これらのツールについて正式なリスク評価を実施しておらず、入力と出力を監視するセキュリティコントロールも整備していない。

「企業であれば、バイブコーディングのリスクを制御し対処する方法はいくつかあります」とミダグ氏は言う。第一歩は、人間のユーザーに対して行うのと同様に、AIツールにも最小権限・最小機能の原則を適用し、業務に必要な最小限の役割、責任、権限だけを付与することだ。

「みんなAIを使うこと、開発者のスピードが上がることに興奮しすぎて、この最小権限・最小機能モデルは完全に置き去りにされています」とミダグ氏は述べた。

次に彼女は、従業員が使える会話型LLMを1つに限定し、他のAIコーディングツールはファイアウォールで全てブロックすることを提案する。そして、環境内でバイブコーディングツールが必要だと判断した組織にとっては、「前進する道はSHIELDフレームワークだ」とミダグ氏は言う。®

翻訳元: https://go.theregister.com/feed/www.theregister.com/2026/01/08/criminals_vibe_coding_malware/

ソース: go.theregister.com