Project CAV3RNのツール群における大きな進化として、AzureCommunication.dllと名付けられた新たな.NET Native AOT通信モジュールが展開されました。これは同フレームワークがこれまで使用していたHTTP/WebSocketベースのC2コンポーネントを置き換えるものです。
このモジュールは、Microsoft Graphを介したOutlookカレンダーイベントを悪用するステルス性の高い通信チャネルと、Microsoft 365の認証情報を対象としたDNSベースの復旧メカニズムを備えています。
この変化は、CAV3RNがモジュール型のサイバースパイ活動プラットフォームとしての性格を一段と強めていることを裏付けるものです。同時に、Microsoftがホストするサービスを秘匿性の高いC2の伝送経路として利用するというOilRig(APT34)の大きな傾向とも合致します。
その後、Check Pointが2026年7月に公表した調査でもこのモジュール型フレームワークの存在が確認されていますが、今回解析対象となった最新の通信レイヤーについては、まだ触れられていませんでした。
今回新たに確認されたAzureCommunication.dllモジュールは、コントローラー側とのインターフェースを従来のまま維持しており、QueryInterfaceという単一のエクスポート関数を公開しています。これはこれまでと同様のget/send文字列形式でコマンドを受け付け、互換性維持のためだけに残された旧来のURLパラメータもそのまま利用可能です。
しかし機能面では、HTTP/WebSocketを完全に廃止し、Microsoft Graphを基盤としたカレンダー操作へと移行しています。これによりCAV3RNの攻撃者は、C2通信を正規のMicrosoft 365トラフィックに紛れ込ませる、完全にクラウドホスト型のチャネルへと切り替えることが可能になっています。
AzureCommunication.dllには、Microsoft Entraのテナント識別子、OAuthクライアント資格情報、侵害済みのOutlookメールボックスに関する情報を含む設定オブジェクトが組み込まれています。
さらに、DNSブートストラップ用ドメイン(cloudlanecdn[.]com)や、C2通信の保護に用いられるRSA鍵ペアも含まれており、初回実行時にはこれらの情報がローカルのlogAzure.txtファイルにシリアライズされます。
このモジュールはAzure Identityスタックを利用し、クライアント資格情報フローを通じてOAuthトークンを取得します。その後、graph.microsoft.comの組織エンドポイントへの照会によってアクセス権を検証したうえで、カレンダー操作へと処理を進めます。
Project CAV3RNに関するKasperskyの2026年6月の非公開レポートでは、専用のWebSocket対応DLLであるn-HTCommp.dllがC2通信を担う一方、コントローラー(uxtheme.dll)が7文字のエージェントIDを介してプラグインへコマンドを発行・ルーティングするという、コントローラーベースのアーキテクチャが説明されていました。
今回のモジュールは、侵害されたメールボックスの既定カレンダーをデッドドロップ型のC2チャネルとして悪用します。すべての活動は2050年5月13日(UTC 22:00〜23:00)という固定された1時間の枠内に限定されており、通常の表示ではイベントが事実上見えないようになっています。
オペレーターからエージェントへのコマンドは、件名が「Event ID: <agent-id>」という形式のイベントとして保存されます。一方、ハートビートおよび結果を示すイベントの件名は、それぞれ「Boss update ID: <agent-id>1500」「Boss Report ID: <agent-id>1500」となっており、この「1500」はエージェントIDの一部ではなく固定の接尾辞として機能しています。
CAV3RNモジュール、WebSocketによるC2を置き換え
受信側のタスク処理では、get操作によってMicrosoft GraphのcalendarViewクエリが実行され、対象エージェント固有の件名でフィルタリングされます。続いて関連する添付ファイルが取得され、タスクパッケージの取得が完了すると同時にイベントは即座に削除されます。
file0.txtという名称の添付ファイルにはオペレーターからエージェントへのコマンドが格納されており、複数のチャンクに分割されたうえでハイブリッド暗号方式によって保護されています。具体的には、256バイトのRSA-OAEP-SHA256ブロックによって32バイトのAES鍵が伝送され、ペイロードの残りの部分は12バイトのnonceと16バイトの認証タグを用いたAES-256-GCMによって保護されています。
ペイロードの復号と認証を終えると、このモジュールは再構築したJSON形式のコマンド、例えば「cmd 003_;;,_」として符号化されたデバッグログの切り替え指示などを、QueryInterfaceを介してコントローラーに返します。コントローラーはこれをローカルのハンドラーやプラグインへ振り分けます。
送信側の結果報告では、この処理が逆の順序で行われます。モジュールは新たなAES-256-GCM鍵を生成し、コントローラーの出力を暗号化したうえで、その鍵自体も保護します。
鍵の保護には設定済みのRSA公開鍵が用いられ、暗号化されたフラグメントはFile0.txt、File1.txtという形で順にアップロードされます。処理完了後、イベントの件名は「Boss Report ID: <agent-id>1500」に変更され、完了を示す合図となります。
エージェントの生存確認は、「Boss update ID: <agent-id>1500」という件名を持つ定期的なハートビートイベントによって行われます。モジュールは2050年のカレンダー枠内に存在する既存のエントリを削除したうえで新たなプレースホルダーイベントを作成し、その件名を後からMicrosoft Graph経由で書き換えることでこの仕組みを更新しています。
ハートビートイベントには添付ファイルが含まれておらず、外部から観測可能な痕跡を最小限に抑えつつ、インプラントが依然として稼働中であることをオペレーターに示す信号としての役割は保っています。
Microsoft Graphの認証やテナント検証に失敗した場合、AzureCommunication.dllはcloudlanecdn[.]comを利用したDNS AAAAレコードベースの復旧プロトコルにフォールバックします。
このドメインは、独自の権威ネームサーバーが2026年5月に稼働を開始したもので、単一のAS(自律システム)配下でホストされています。これは、論理的には冗長性を持たせつつも、中央で一元的に管理されているインフラであることを示唆しています。
このモジュールはAAAAレスポンスを16バイトのコンテナとして利用し、まず「.p.」クエリを通じて各フィールドの長さを復元します。その後、「.q.」を用いたセグメント化クエリによって、TenantId、ClientId、ClientSecret、UserEmailの各値を再構築します。各エージェントのIDは大文字の16進数として符号化され、すべての復旧リクエストに埋め込まれています。
CAV3RNフレームワークについては、以前からOilRig(APT34)との関連が暫定的に指摘されてきました。今回の新モジュールは、C2にMicrosoft がホストするサービス(EWS、Office 365の下書き機能、Microsoft Graph)を利用するという、これまで文書化されてきたOilRigの手口との行動面での一貫性をさらに補強するものです。
調査担当者は、コードの直接的な再利用やインフラの重複は確認されていないとしていますが、手口の収斂は関連性の低信頼度の評価をより強固なものにしています。特に、侵害された地域のMicrosoft 365メールボックスが価値の高いスパイ活動の標的として再利用されている点は、この評価を裏付ける材料となっています。
防御側にとって、この進化はMicrosoft Graphへのアクセスパターンをめぐる詳細なテレメトリと異常検知の重要性を改めて浮き彫りにしています。具体的には、遠い未来の時間枠で行われるカレンダー操作、想定外のOAuthクライアントID、リスクの高いメールボックスにおける添付ファイルを多く含む不審なイベントなどへの監視が求められます。
また組織は、cloudlanecdn[.]comのような攻撃者が管理するドメインに対する、符号化された識別子やオフセットを含む構造化されたAAAAクエリについても、DNSトラフィックを監視すべきです。こうしたクエリは、クラウド中心型のC2インプラントによる設定復旧の試みが進行中であることを示す兆候となり得ます。
𝗔𝗜 𝗦𝗢𝗖 𝘃𝘀 𝗠𝗗𝗥 𝘃𝘀 𝗠𝗦𝗦𝗣 2026年、どちらが最適か? コスト、自動化、対応力を比較: 無料ガイドをダウンロード
翻訳元: https://gbhackers.com/cav3rn-module-replaces-websocket-c2/
