イスラエルの組織を標的とするモジュール型サイバースパイフレームワーク「Project CAV3RN」に、Google Apps Scriptの裏に通信を隠す新たなコマンド&コントロール（C2）設計が追加されたことが分かりました。
このマルウェアはDNSのAレコード応答を利用し、各リクエストをGoogleのリレー経由にするか、攻撃者が管理するHTTPSサーバーに直接送るかを判断します。
今回新たに特定された通信コンポーネント「GoogleService.dll」は、64ビットの.NET 8 NativeAOTモジュールです。
このモジュールはローカルのDLLブローカーと連携して動作し、感染ホストが稼働したままの状態でも、攻撃者側がフレームワークの各コンポーネントを読み込み・管理・更新できるようになっています。この設計により、CAV3RNは柔軟かつ耐障害性の高いアーキテクチャを実現しています。
GoogleService.dllは、コマンドを確認したり結果を送信したりする前に、studiotikva[.]com配下のサブドメインに対してDNSクエリを送信します。
このクエリには、ランダムな値、マルウェアの現在のエラー状態、そして被害者識別子を16進数に変換した値が含まれます。
このDNS応答は単なるドメイン解決以上の役割を果たします。応答に含まれるIPアドレスの最後のオクテットが、マルウェアへの命令として機能するのです。
応答の末尾が120で終わる場合、直前のエラー状態に応じてGoogle Apps Script経由のチャンネル、または直接HTTPSのいずれかが選択されます。
末尾が130の場合は通常、直接HTTPSが選択され、140の場合は強制的に例外処理が発生します。それ以外の値では、概してGoogle Apps Script経由に誘導される傾向にあります。
これにより、攻撃者側は軽量な制御プレーンを手にすることになります。マルウェア自体を更新したり、別のペイロードを展開したりすることなく、通信経路を変更できるのです。
いずれかのチャンネルがブロックされたり、不安定になったり、あるいは監視の目を引いたりした場合、DNSはインプラントを別の経路へと誘導できます。またこのDNSの仕組みは、Google Apps Scriptのデプロイメント IDが依然として有効かどうかも確認します。
マルウェアは、保存されているデプロイメントIDのMD5ハッシュの一部を、別のDNS Aレコード応答に埋め込まれたバイト列と比較します。
値が一致しない場合、マルウェアは一連のDNSクエリを送信し、代替となるデプロイメントIDを小さな断片として少しずつ復元します。復元されたIDは、その後ローカルの設定ファイルに書き戻されます。
この手法により、Googleのリレーは差し替え可能な存在になります。攻撃者は、侵害済みシステム上でマルウェアを稼働させたまま、クラウド側のエンドポイントをローテーションさせることができるのです。
DNSがGoogleモードを選択すると、CAV3RNはscript.google.com/macros/s/{deployment-ID}/execという形式でURLを構築します。
マルウェアはApps Scriptのデプロイメントに対してPOSTリクエストを送信しますが、このリクエストは上流のC2サーバーに対してGETリクエストを発行するようリレーに指示するものだと、securelistは述べています。
注： IPアドレスおよびドメイン名は、誤ってアクセスまたはハイパーリンク化されるのを防ぐため、意図的に無害化表記（例: [.]）としています。再有効化する際は、MISP、VirusTotal、SIEMなど、管理された脅威インテリジェンス基盤内でのみ行ってください。
ANY.RUNのブラウザ内データ検査で、検知・調査・対応をより迅速に。フィッシングの可視性を高め、SOCを強化してMTTRを削減しましょう
翻訳元: https://cyberpress.org/cav3rn-dns-routes-google-c2/
