捨てられた拡張機能名：Azure VMAccess命名の混乱、パスワードリセット、および検出ギャップ

攻撃対象としてのVM拡張機能

Azure VM拡張機能は、仮想マシンで実行され、展開後の構成と管理タスクを実行するプログラムです。これらはVM上で昇格された権限で実行され、Azure制御プレーンを通じて展開されます。つまり、適切なARM（Azure Resource Manager）権限を持つ者は誰でも、OSレベルのアクセスを必要とせずにVMにコードまたは構成の変更をプッシュできます。

セキュリティ研究者はVM拡張機能の悪用を広く文書化しています。NetSPIはCustomScriptExtensionおよびRunCommandなどの拡張機能をAzure環境でのラテラルムーブメントとコード実行に使用することに関する研究を公開しています。Microsoft自体のAzure脅威マトリックスマッピングはVM拡張機能を実行と永続化のベクトルとして認識しています。さらに、Sysdig Secureのようなエンタープライズクラウドセキュリティツールは、疑わしい拡張機能の展開についてアラートを発行する検出ルールを備えています。

VMAccess拡張機能は特に機密性が高いものです。VM上のパスワードとSSHキーをリセットし、このフローを通じて、攻撃者はパスワードをリセットして環境内で永続化を維持することができます。Linuxでは、拡張機能の種類はVMAccessForLinuxです（パブリッシャー：Microsoft.OSTCExtensions）。Windowsでは、VMAccessAgentです（パブリッシャー：Microsoft.Compute）。これらは2つの異なるパブリッシャーからの2つの異なる拡張機能かもしれませんが、概念的には同じ操作です。

VMAccess検出ルールは通常、アクティビティログのresourceIdまたはentityフィールド内の拡張機能リソース名に一致し、enablevmaccess、VMAccessForLinux、またはVMAccessAgentのような文字列を探します。

Azure VM上のパスワードリセット検出のフロー

理論的には、Azure VMのパスワードリセットは簡単なはずです。Azure Resource Manager（ARM）制御プレーン経由で実行され、Microsoft.Compute/virtualMachines/extensions/writeとしてAzureアクティビティログに書き込まれます。パスワードリセットを有効にするVM拡張機能には既知の名前があります。名前に一致する検出ルールを作成して完了です。しかし、理論的に真実は実際には常に真実ではありません。

VM拡張機能は単一の既知の名前を持つだけではありません。互いに交換可能に使用する3つ以上の名前を持っています。そして、パスワードをリセットするために使用されるツールに応じて、どの検出ルールも一致しない名前を含め、完全に任意の名前を持つことができることが判明しました。つまり、ここでの命名の創造性に制限はありません。

さらに複雑にするために、成功した拡張機能書き込みのアクティビティログには、拡張機能パブリッシャーまたはタイプが含まれていません。唯一の識別情報は、呼び出し元が制御するリソース名と汎用操作文字列です。VM拡張機能を書き込むことができる任意の攻撃者は、認証情報をリセットし、操作に任意の名前を付けることができます。デフォルト検出ルールはこれを見ることはありません。

VM上のホストおよびネットワークレベルのログ（例：Windowsイベントログと/var/log）もデフォルトではAzureに渡されません。代わりに、各VMに対して構成する必要があります。つまり、VMの制御を失った場合、事前に追加ログを設定していない限り、Azureは攻撃者がVM内で何をしているかについての通知を行いません。

Azure脅威マトリックスによると、ユーザーはこのパスワードリセットを「Validate Deployment」の操作名を含むイベント経由で検出することになっており、Properties_dに「vmaccesswindowspasswordreset」があります。しかし、この検出は2026年4月のSysdig TRTが実行したテスト中に決して発火しませんでした。

3つのチーム、3つの名前

VM拡張機能がARM APIを通じて展開されるとき、URLは次のパターンに従います：

PUT .../virtualMachines/{vm}/extensions/{name}

最後の{name}セグメントは拡張機能リソース名であり、アクティビティログに表示される値です。3つのMicrosoftツールはその名前が何であるべきかについて異なります。

# ポータルと同じ名前を使用して、両方のCLIとポータルから更新できるようにします# （VMは同じ拡張機能に対して複数のハンドラーを許可しません）_ACCESS_EXT_HANDLER_NAME = 'enablevmaccess'

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": "********"
      }
    }
  }'

{
"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"  }
}

検出ギャップ

アクティビティログ、resourceId、またはentityフィールド内の既知の拡張機能名に一致する検出ルールは、別の拡張機能リソース名を選択するだけで回避できます。

たとえば、Microsoft.Compute/virtualMachines/extensions/write権限を持つ攻撃者は：

1. VMAccessを使用してVMパスワードをリセットします
2. 拡張機能に任意の名前を付けます。例えば、AzureMonitorUpdate、compliance-check、またはその他の無害な文字列
3. アクティビティログは任意の名前と汎用extensions/write操作のみを表示します
4. enablevmaccess、VMAccessForLinux、またはVMAccessAgentに一致する検出ルールは発火しません

全体として、このAzure制御プレーンテレメトリはMITRE ATT&CKテクニックT1036（マスカレード）の明確な例です。

Microsoftはまた、Azure脅威マトリックステクニックAZT501.3：Azure VM Local Administrator Manipulationを通じてこのアクティビティを検出するための追加のガイダンスを提供しています。彼らのドキュメントによると：「成功したリセット後、ログ「Validate Deployment」が作成されます。具体的には、スコープ内で、パスワードリセットが「VMAccessWindowsPasswordReset」で言及されます。また、2つの予想されるイベントを含むログテーブルもあります。前に記載したMicrosoft.Compute/virtualMachines/extensions/writeイベント、および2番目のイベント：Microsoft.Resources/deployments/validate/action

ただし、このアクティビティのテスト中に、Microsoft.Resources/deployments/validate/actionイベントは決して発生しませんでした。つまり、Microsoft提供の検出に関するガイダンスはここで有効ではありませんでした。

推奨事項

resourceIdパス内の拡張機能リソース名も信頼できない検出シグナルです。代わりに、以下の代替案を検討してください：

• 一致させる – 操作名で。Microsoft.Compute/virtualMachines/extensions/writeは命名に関わらずすべての拡張機能展開をキャプチャします。有効ですが、エンジニアはこのようなことをしばしば行うため、ノイズが多くなり、偽陽性を生成します。
• 関連付ける – Azure Resource GraphまたはExtensions APIと。Microsoft.Compute/virtualMachines/extensionsのクエリは、インストールされた任意の拡張機能の実際のパブリッシャーとタイプを返します。
• アラート – 機密VMへの任意の拡張機能書き込み。本番環境または高価値のVMの場合、リソース名に関わらず、任意の拡張機能展開は調査を保証します。

結論

Microsoftのポータル、CLI、およびドキュメントチーム間の命名の矛盾は、最終的には、より深い課題に帰結しました。拡張機能リソース名は、検証されていない、呼び出し元が制御する文字列で、セマンティック的な意味がありません。MSFTが提供する検出ガイダンスは効果がありません。この矛盾は、検出ルールが複数のツール表面からのテレメトリに一致する必要があったときにのみ可視化され、それらのルールは自明に回避可能であることが判明しました。モダンなマルチクラウド組織は複雑で、クラウドとのレガシーな相互接続に関連する追加の問題は引き続き発生します。

開示タイムライン

この調査結果は2026年4月7日にMicrosoft Security Response Center（MSRC）に報告されました。2026年5月11日、Microsoftは「調査の結果、リソース名は常にユーザーが指定するものであるため、これはセキュリティ脆弱性と見なされない」と結論付けました。

付録：脅威ハンターのための既知のAzure VM拡張機能名

拡張機能リソース名（/virtualMachines/{vm}/extensions/{name}の{name}セグメント）はアクティビティログに表示されるものです。Azureはそれを検証または制約しません。以下の名前はMicrosoft自体のツールがデフォルトで使用するものです。このリストにない拡張機能リソース名は外れ値であり、調査価値があります。