Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年5月20日に Lydia Graslie が投稿したブログ (https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap) を元に日本語に翻訳・再構成した内容となっております。
2026年4月上旬、Sysdig 脅威リサーチチーム（TRT）は、Azure VMのパスワードリセットおよびVMAccessの命名処理にまつわる検知上の欠陥を特定しました。この欠陥により、攻撃者はAzure VMの拡張機能（extension）に任意の名前を付けることができ、読み取り/書き込みアクセスの取得、パスワードの変更、そして被害環境への永続化を、検知されないまま行えるようになります。さらに、Sysdig TRTは、Azure Threat Matrixがこの検知のために文書化しているテレメトリが、イベント発火時にまったく出力されないことも確認しました。私たちは特定後すぐにこれらの問題をMicrosoftに報告しました。Microsoftの公式回答は以下のとおりです。
"Upon investigation, we have determined that this is not considered a security vulnerability because resource names are always user specified."（調査の結果、リソース名は常にユーザーが指定するものであるため、これはセキュリティ脆弱性とはみなされないと判断しました。）
本レポートでは、Sysdig TRTの調査結果の詳細と、検知のための推奨事項について解説します。
攻撃対象領域としてのVM拡張機能
Azure VM拡張機能は、仮想マシン上で動作し、デプロイ後の構成や管理タスクを実行するプログラムです。VM上で昇格された権限で実行され、Azureのコントロールプレーンを通じてデプロイされます。つまり、適切なARM（Azure Resource Manager）権限を持つ人であれば、OSレベルのアクセスがなくてもVMにコードや構成変更をプッシュできる、ということです。
セキュリティ研究者たちは、これまでVM拡張機能の悪用について多くの事例を文書化してきました。NetSPIは、CustomScriptExtensionやRunCommandなどの拡張機能をAzure環境でのラテラルムーブメントやコード実行に使う手法について研究結果を公開しています。Microsoft自身のAzure Threat Matrixのマッピングでも、VM拡張機能は実行と永続化のためのベクトルとして認識されています。さらに、Sysdig Secureのようなエンタープライズ向けクラウドセキュリティツールには、不審な拡張機能のデプロイに対してアラートを発する検知ルールが標準で組み込まれています。
VMAccess拡張機能は特に機微なものです。VM上のパスワードやSSHキーをリセットする機能であり、今回の欠陥を通じて、攻撃者はパスワードをリセットし、環境内で永続化を維持できてしまいます。Linuxでは拡張機能のタイプはVMAccessForLinux（パブリッシャー：Microsoft.OSTCExtensions）、WindowsではVMAccessAgent（パブリッシャー：Microsoft.Compute）です。これらは異なるパブリッシャーから提供される別々の拡張機能ですが、概念上は同じ操作を行います。
VMAccessに対する検知ルールは通常、アクティビティロギングのresourceIdまたはentityフィールドにある拡張機能のリソース名をマッチさせ、enablevmaccess、VMAccessForLinux、VMAccessAgentといった文字列を探しに行きます。
Azure VMでのパスワードリセット検知における欠陥
理屈の上では、Azure VMのパスワードリセットはシンプルなはずです。Azure Resource Manager（ARM）のコントロールプレーンを経由し、Azure Activity LogにMicrosoft.Compute/virtualMachines/extensions/writeとして書き込まれます。パスワードリセットを担うVM拡張機能の名前は既知です。その名前にマッチする検知ルールを書けば仕事は完了。しかし、理屈の上で正しいことが、実運用でも正しいとは限りません。
このVM拡張機能には、既知の名前が1つだけあるわけではありません。少なくとも3つの名前があり、それらが入れ替わりで使われています。さらに調査を進めると、リセットに使うツールによっては、検知ルールが決してマッチしない名前を含め、本当にどんな名前でも付けられることがわかりました。命名のクリエイティビティに制限はないのです。
事態をさらに複雑にしているのは、拡張機能の書き込みが成功した際のアクティビティロギングには、拡張機能のパブリッシャーもタイプも含まれていない、という点です。識別に使える情報は、呼び出し側が制御するリソース名と、汎用的な操作文字列だけです。VM拡張機能を書き込める攻撃者なら誰でも、認証情報をリセットし、その操作に好きな名前を付けられます。そしてデフォルトの検知ルールは、それを一切捕捉しません。
VMのホストレベルおよびネットワークレベルのログ（例：Windowsイベントログや/var/log）も、デフォルトではAzureに送られません。VMごとに個別に設定する必要があります。つまり、VMの制御を奪われた場合、事前にこの追加ログを設定しておかない限り、攻撃者がそのVMの内部で何をしているかをAzureが知らせてくれることはありません。
Azure Threat Matrixによると、このパスワードリセットは、操作名「Validate Deployment」を含み、Properties_dに「vmaccesswindowspasswordreset」が含まれるイベントで検知されることになっています。しかし、Sysdig TRTが2026年4月に実施したいずれのテストでも、この検知は発火しませんでした。
3つのチーム、3つの名前
VM拡張機能がARM API経由でデプロイされる際、URLは次のパターンに従います。
PUT .../virtualMachines/{vm}/extensions/{name}末尾の{name}セグメントが拡張機能のリソース名であり、アクティビティロギングに現れる値です。Microsoftの3つのツールは、この名前が何であるべきかについて見解が一致していません。
Azure Portal
Portalは、LinuxでもWindowsでも、すでに何がインストールされているかに関係なく、VMAccessを常にリソース名enablevmAccessでデプロイします。
Azure CLI
Azure CLIのソースコード（azure-cli/src/azure-cli/azure/cli/command_modules/vm/custom.py）では、2016年7月2日（PR #482）以来、同じenablevmAccessがハードコードされています。
# Use the same name by portal, so people can update from both cli and portal
# (VM doesn't allow multiple handlers for the same extension)
_ACCESS_EXT_HANDLER_NAME = 'enablevmaccess'しかし、2017年3月（PR #2395）、CLIチームは_get_extension_instance_name()という関数を追加しました。この関数は、VMにすでに別名で同じ拡張機能がインストールされているかをチェックし、もしあればハードコードされた定数の代わりにその名前を再利用します。その理由は「Otherwise, vm agent might reject for more than 2 handlers.（さもなくば、VMエージェントが2つを超えるハンドラーを拒否する可能性があるため）」とされています。つまりCLIは、VMの履歴次第でenablevmaccessを送ることも、VMAccessAgentを送ることもある、ということです。
ドキュメント
VMAccessに関するMicrosoft Learnの公式ドキュメントは、CLI、PowerShell、ARMテンプレートのいずれの例においても、enablevmaccessを使ったことが一度もありません。2016年4月の最初のバージョン（commit 2fde0e40bf）に遡っても、すべての例で拡張機能のタイプ名、すなわちLinuxにはVMAccessForLinux、WindowsにはVMAccessAgentが使われています。
文字列enablevmaccessがドキュメントに登場するようになったのは2025年3月以降で、しかもトラブルシューティング表に記載されたAzureのエラーメッセージそのままの引用としてであり、推奨される名前としてではありません。
このドキュメントはCLIの定数より3か月先行しており、命名運用が分裂してきた経緯がはっきり見て取れます。
そこから生じる問題
Azureには「VMごとに、ハンドラータイプごとに拡張機能リソースは1つだけ」という制約があります。PortalでenablevmAccessとしてVMAccessをインストールしたあと、ユーザーがドキュメントに従ってVMAccessForLinuxでデプロイしようとすると、Azureは400 BadRequest「Multiple VMExtensions per handler not supported.」でリクエストを拒否します。
一方で、名前そのものは恣意的に決められるものでもあります。複数ツールを横断的にテストしてみると、拡張機能のリソース名はツールによって変わることが確認できました。そこでSysdig TRTが次に追求したのは、「Azureはこの名前を検証しているのか？」という問いでした。
既存のVMAccessハンドラーが存在しないクリーンなLinux VMに対して、AZ CLI経由で、完全に任意のリソース名を指定してVMAccess拡張機能をデプロイしてみました。
az rest --method PUT \
--url ".../extensions/my-custom-name-12345?api-version=2024-07-01" \
--body '{
"location": "eastus",
"properties": {
"publisher": "Microsoft.OSTCExtensions",
"type": "VMAccessForLinux",
"typeHandlerVersion": "1.5",
"autoUpgradeMinorVersion": true,
"settings": {},
"protectedSettings": {
"username": "azureuser",
"password": "********"
}
}
}'Azureはmy-custom-name-12345を受け入れ、パスワードはリセットされ、拡張機能はインストールされました。本来これを捕捉するはずだった検知は、アラートを発しませんでした。
アクティビティロギングに現れる内容
このパスワードリセット成功時のアクティビティロギングエントリ（抜粋）は以下のとおりです。
{
"operationName": {
"value": "Microsoft.Compute/virtualMachines/extensions/write"
},
"resourceId": ".../extensions/my-custom-name-12345",
"status": {
"value": "Succeeded"
},
"properties": {
"entity": ".../extensions/my-custom-name-12345",
"message": "Microsoft.Compute/virtualMachines/extensions/write"
}
}拡張機能のパブリッシャー（Microsoft.OSTCExtensions）もタイプ（VMAccessForLinux）も、書き込み成功時のアクティビティロギングには含まれていません。識別に使える情報は、呼び出し側が任意に指定したリソース名と、汎用的な操作名Microsoft.Compute/virtualMachines/extensions/writeだけです。
検知ギャップ
アクティビティロギング、resourceId、entityフィールドの既知の拡張機能名にマッチさせる検知ルールは、別の拡張機能リソース名を選ぶだけで回避できてしまいます。
たとえば、Microsoft.Compute/virtualMachines/extensions/write権限を持つ攻撃者は、次のことができます。
- VMAccessを使ってVMのパスワードをリセットする
- 拡張機能に任意の名前を付ける。たとえば
AzureMonitorUpdate、compliance-check、その他無害そうな文字列など - アクティビティロギングには任意の名前と汎用的な
extensions/write操作だけが記録される enablevmaccess、VMAccessForLinux、VMAccessAgentにマッチする検知ルールは発火しない
総じて、このAzureコントロールプレーン上のテレメトリは、MITRE ATT&CKのテクニックT1036（Masquerading／なりすまし）の明確な事例を構成しています。
Microsoftは、Azure Threat MatrixのテクニックAZT501.3「Azure VM Local Administrator Manipulation」を通じて、この活動の検知に関する追加のガイダンスも提供しています。同社のドキュメントによれば、「リセット成功後にログ『Validate Deployment』が作成されます。具体的には、スコープ内でパスワードリセットが『VMAccessWindowsPasswordReset』として言及されます」とのことです。また、想定される2つのイベント、すなわち先に挙げたMicrosoft.Compute/virtualMachines/extensions/writeイベントと、もう1つのMicrosoft.Resources/deployments/validate/actionイベントを含むLogsテーブルも存在します。
しかし、この活動をテストしている最中、Microsoft.Resources/deployments/validate/actionイベントは一度も発生しませんでした。つまり、Microsoftが提供している検知ガイダンスは、ここでは有効に機能しなかったのです。
推奨事項
resourceIdパスにある拡張機能のリソース名は、検知シグナルとして信頼できるものではありません。代わりに、以下の代替策をご検討ください。
- マッチ対象を操作名にする。
Microsoft.Compute/virtualMachines/extensions/writeは、命名にかかわらずすべての拡張機能デプロイを捕捉します。有効ではありますが、エンジニアが日常的に行う操作でもあるため、ノイズが多く、誤検知（false positive）も増えがちです。 - Azure Resource Graphや拡張機能APIと相関させる。
Microsoft.Compute/virtualMachines/extensionsを問い合わせると、インストール済みの拡張機能について実際のパブリッシャーとタイプが返ってきます。 - 機微なVMへの拡張機能書き込みすべてにアラートを出す。本番環境や重要度の高いVMでは、リソース名にかかわらず拡張機能のデプロイそのものが調査対象に値します。
まとめ
MicrosoftのPortal、CLI、ドキュメントの各チーム間での命名の不一致は、最終的にさらに深い課題として表面化しました。すなわち、拡張機能のリソース名は検証されない、呼び出し側が制御する文字列であり、意味的な制約をまったく持たない、ということです。MSFTが提供する検知ガイダンスは、効果的に機能しません。この不整合は、検知ルールが複数のツール表面からのテレメトリにマッチする必要が生じて初めて顕在化し、そしてそれらのルールは、ごく簡単に回避できるものであることが判明しました。最新のマルチクラウド組織は複雑であり、クラウドとのレガシーな接続に起因する別種の問題も今後も発生し続けるでしょう。
開示タイムライン
本件は2026年4月7日にMicrosoft Security Response Center（MSRC）へ報告されました。2026年5月11日、Microsoftは「調査の結果、リソース名は常にユーザーが指定するものであるため、これはセキュリティ脆弱性とはみなされないと判断しました（Upon investigation, we have determined that this is not considered a security vulnerability because resource names are always user specified.）」と結論付けました。
付録：脅威ハンター向けの既知のAzure VM拡張機能名
拡張機能のリソース名、すなわち/virtualMachines/{vm}/extensions/{name}の{name}セグメントは、アクティビティロギングに現れる値です。Azureはこれを検証も制約もしません。以下の名前は、Microsoft自身のツールがデフォルトで使用しているものです。このリストにない拡張機能リソース名は、外れ値として調査に値します。
参考資料：
- Azure VM拡張機能の概要
- Linux向けVM拡張機能
- Windows向けVM拡張機能
- Azure CLIソース — custom.py（現行）
- Azure CLI PR #482 — enablevmaccess定数の導入（2016年7月）
- Azure CLI PR #2395 — 名前の動的な再利用を追加（2017年3月）
- Azure CLI Issue #11626 — VMAccessAgentのバージョン不一致
- Microsoft Learn — Linux向けVMAccess
- Microsoft Learn — Windows向けVMAccess
- MicrosoftDocs/azure-compute-docs — vmaccess-linux.md履歴
- MITRE ATT&CK T1036 — Masquerading
- MITRE ATT&CK T1098 — Account Manipulation