VSCodeに偽の拡張機能 prettier-vscode-plus-「Prettier – Code formatter」に偽装|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2025年11月27日更新日時: 2025年11月27日

2025年11月21日、Visual Studio Code（VSCode）の公式Marketplaceに、人気拡張「Prettier – Code formatter」に酷似した拡張機能が公開されました。名前は prettier-vscode-plus、拡張IDは publishingsofficial.prettier-vscode-plus で、一見すると本家Prettierの強化版や公式派生版のように見える作りになっていました。

1 概要
2 攻撃者の狙い：Prettierブランドを使った開発者だまし
3 攻撃チェーンの全体像：拡張からAnivia Stealer起動まで
4 Anivia Stealerの役割とマルウェア・アズ・ア・サービス化
5 なぜ検知が難しいのか：ファイルレスと正規コンポーネントの悪用
6 情報システム部門・開発組織が取るべき対策

概要

Checkmarxが偽のパッケージprettier-vscode-plus、拡張ID：publishingsofficial.prettier-vscode-plus の内部コードを調査すると、この拡張は正規のPrettier拡張（esbenp.prettier-vscode）をフォークしたうえで、情報窃取マルウェア「Anivia Stealer」を落とし込むためのコードが追加された悪性パッケージであることが分かりました。

公開から約4時間で報告・削除が行われたため、ダウンロード数は6件、インストールされたのは3件にとどまったとされています。数だけ見ると小さなインシデントですが、攻撃手法そのものは再利用可能であり、開発環境をどう守るかを考えるうえで見逃せない事例です。

攻撃者の狙い：Prettierブランドを使った開発者だまし

開発者は日常的に新しい拡張を試すことが多く、VSCodeのMarketplaceに並んでいる拡張については「ある程度の信頼はおける」という前提でインストールしてしまいがちです。アイコンや説明に違和感が少なく、名前にprettierが含まれていれば、深く疑わず導入してしまう人も多いはずです。

その一方で、開発者端末にはソースコードリポジトリの認証情報やクラウド環境へのアクセス権限、VPNや各種管理コンソールのパスワードなど、組織の中でも特に価値の高い情報が集中しています。ここを突破できれば、単なる端末1台の問題では終わらず、ソフトウェアサプライチェーン全体への侵入経路にもなり得ます。

攻撃チェーンの全体像：拡張からAnivia Stealer起動まで

Checkmarx が偽Prettier拡張を解析すると、単純に不正な実行ファイルをダウンロードして保存するだけではなく、複数のステージに分かれた多段攻撃になっていることが分かりました。その目的は、できる限りディスクに痕跡を残さず、従来型のアンチウイルス製品による検知をすり抜けることです。

最初のステージでは、拡張機能のコードがGitHub上の特定のコミットパッチにアクセスし、Base64エンコードされたデータの塊を取得します。

見た目は単なる文字列データにしか見えませんが、実際にはAESで暗号化されたマルウェア本体のバイナリをBase64化したものです。

復号に使用するAESキーは、拡張コード内に固定文字列として埋め込まれており、攻撃者はこのキーを使って後続のステージでペイロードを復号するよう設計していました。

次のステージでは、VBScriptが起動役として利用されます。拡張はWindowsスクリプトホストを通じてVBScriptを生成し、%TEMP% 配下に一時的なファイルとして保存します。このVBScriptは、さらにPowerShellスクリプトを一時ファイルとして生成し、powershell.exe -ExecutionPolicy Bypass -NoProfile -File <temp.ps1> という形で非表示実行します。数秒ほど待機した後で、自身が作成した.ps1ファイルを削除するため、ディスク上に残るファイルは短時間の一時ファイルだけになります。

PowerShellは、暗号化されたペイロードを復号してメモリ上に展開する役割を担います。

スクリプト内では、まずBase64文字列として埋め込まれたキーと暗号データをデコードし、暗号データの先頭16バイトをIV（初期ベクトル）、残りの部分を暗号文として切り分けます。そのうえでAES-CBCとPKCS7パディングを用いて復号処理を行い、実行形式相当のバイト配列を取り出します。復号されたバイト配列は [Reflection.Assembly]::Load() に渡され、.NETアセンブリとしてプロセスのメモリ空間にロードされます。

ここまでの流れでは、マルウェア本体のEXEファイルがディスクに書き出されることは一度もありません。最後にPowerShellスクリプトがリフレクション機能を使い、ロードされたアセンブリ内から特定のクラスとMainメソッドを探し出して呼び出すことで、Anivia Stealerの起動に至ります。この一連のステップが、偽Prettier拡張からAnivia Stealerの実行までの大まかな流れです。

Anivia Stealerの役割とマルウェア・アズ・ア・サービス化

偽Prettier拡張の最終的な目的は、Anivia Stealerを感染させることでした。

AniviaはWindows環境を対象にした情報窃取型マルウェアで、ブラウザに保存されたパスワードやクッキー、システム情報や各種メタデータだけでなく、メッセージングアプリのチャットログ（報告ではWhatsAppなど）といった個人情報まで盗み出す機能を持つとされています。

近年のインフォスティーラーに共通する特徴として、マルウェア・アズ・ア・サービス（MaaS）の形で提供されている点があります。

Aniviaも例外ではなく、月額や買い切りといった形態で販売され、攻撃者は料金を支払うことでこのマルウェアと付随するインフラを利用できると報告されています。開発者と利用者が分業することで、マルウェア本体の機能は継続的にアップデートされやすく、検知回避機能が強化され続ける構造になっています。

今回観測されたチェーンの中でも、Anivia側にはサンドボックスや解析環境を避ける工夫が組み込まれていました。例えば、CPUコア数や利用可能なメモリ容量を確認し、あまりにもリソースが小さい環境では本格的な挙動を控えることで、セキュリティベンダーの解析用環境で本性を見せないようにしていたとされています。このような手口が組み合わさることで、従来型の静的解析や簡易的な動的解析では本来の脅威を捉えにくくなっているのが現状です。

なぜ検知が難しいのか：ファイルレスと正規コンポーネントの悪用

今回の攻撃が厄介なのは、ディスクに典型的なマルウェアファイルを残さない点と、使われている部品がいずれも正規コンポーネントである点にあります。VSCode拡張自体は、IDEの一機能として動作するJavaScriptやTypeScriptのコードに過ぎず、外部から見れば単なる開発ツールの一部です。ペイロードを取得する先は、怪しい独自ドメインではなく、普段から開発者が利用しているGitHub上のリポジトリです。

中間に登場するVBScriptとPowerShellも、Windowsに標準搭載された正規のスクリプト実行環境です。

いわゆる「LoLBins（Living off the Land Binaries）」と呼ばれるものであり、本来は管理や自動化に便利な機能ですが、攻撃者に悪用されると検知やブロックが難しいコンポーネントになってしまいます。マルウェア本体はPowerShellのAES復号処理とリフレクション機能を通じてメモリ上にのみ存在し、EXEファイルとして落とされないため、シグネチャベースのファイルスキャンでは見つけようがありません。

こうした条件がそろうと、頼りになるのはプロセスの振る舞いや親子関係、PowerShellスクリプト内での暗号処理の利用状況、GitHubへの不自然な通信といった「挙動のつながり」を監視するタイプの仕組みです

。IDEからスクリプトエンジンやPowerShellが呼び出され、その中で暗号処理とインメモリ実行が行われているようなパターンを捉えられるかどうかが、組織としての検知力を左右します。

情報システム部門・開発組織が取るべき対策

ここからは、情報システム部門やセキュリティ担当、開発組織として、今回の事例を踏まえてどのような対策を取るべきかを整理します。

まず、VSCode拡張の利用ポリシーを明確にすることが重要です。公式Marketplace以外の経路でインストールされる拡張については、原則として禁止する方針を打ち出すことをおすすめします。そのうえで、組織として利用を許可する拡張の一覧を作成し、拡張IDとパブリッシャーIDをセットで管理します。新しい拡張を導入したい場合は、開発チームから申請してもらい、セキュリティ担当が簡易なレビューを行ったうえで許可する流れを用意すると、無制限な拡張インストールを抑えやすくなります。

次に、EDRによる振る舞い検知の強化が欠かせません。具体的には、VSCodeなどIDEプロセスを親として wscript.exe や powershell.exe が起動していないか、PowerShellプロセスの内部でAES暗号化クラスや[Reflection.Assembly]::Loadが組み合わさって使われていないか、といった観点で監視することが有効です。IDEからスクリプトエンジンを経由してPowerShellが呼び出され、メモリ上でアセンブリがロードされるような流れは、日常業務では頻繁に出てくるものではありません。このようなプロセスチェーンを検知・アラート対象にする設定を検討するとよいでしょう。

出典

Checkmarx Zero Takes Down Malicious “Prettier” Alternative Found In VSCode Marketplace