SesameOp: Using the OpenAI Assistants API for Covert C2 Communication
2025/11/04 gbhackers — OpenAI Assistants API を悪用する高度なバックドア型マルウェア SesameOp が、従来とは異なる Command-and-Control (C2) 通信経路を用いていることを、Microsoft の Detection and Response Team (DART) が明らかにした。この種の脅威は、正規のクラウド・サービスを悪用して通信を隠蔽する手法へ急速に適応しており、既存のセキュリティ対策による検知を著しく困難にしている。
この発見が浮き彫りにするのは、悪意のトラフィックを正規の API 通信に紛れ込ませることで、従来のセキュリティ制御を回避しようとする、脅威アクターの戦術が進化していることだ。
Microsoft DART の研究者たちが 2025年7月に発見したバックドアは、従来のマルウェアの C2 通信の手法から大きく逸脱するものだ。具体的に言うと、SesameOp を背後で操る脅威アクターは、C2 専用のインフラを構築する代わりに、OpenAI Assistants API を悪用して悪意のコマンドを保存／中継／取得する。
この手法は、信頼できるサービス・プロバイダへの正規の API 通信内に、悪意の C2 通信を隠蔽するものであり、従来のネットワーク監視による検知は極めて困難となる。こうして確立された通信経路を通じて、ストレージおよび中継メカニズムとして API を悪用するマルウェア・コンポーネントは、侵害したシステム上で暗号化された悪意のコマンドを取得／実行する。
DART の調査により、この脅威アクターは検出される数か月前から、標的環境内に潜伏していたことが判明した。さらに分析を進めた結果、複雑かつ永続的な攻撃インフラには、悪意のプロセスから中継されるコマンドを実行するための、内部 Web シェルが含まれていることも分かった。
これらのプロセスは、複数の Microsoft Visual Studio ユーティリティを悪用するものだが、高度な防御回避技術である .NET AppDomainManager インジェクションを介して、それらのユーティリティは攻撃者により事前に侵害されていた。この多層的な手法により、攻撃者は長期間にわたり検出されることなく、深いレベルでの永続性を維持していた。
技術アーキテクチャと感染チェーン
SesameOp の感染チェーンは、連携して動作する２つの主要コンポーネントで構成される。Eazfuscator.NET を用いて高度に難読化されたローダー・コンポーネント “Netapi64.dll” は、.NET AppDomainManager インジェクションを介してホストの実行時にロードされる。
この DLL は Windows の “temp” ディレクトリにマーカー・ファイルを作成し、メモリ内で単一のインスタンスだけを実行するためのミューテックスを確立する。このローダーは “temp” ディレクトリ下のファイルを列挙し、拡張子 ”.Netapi64″ を持つファイルを検索し、それらのファイルを XOR 復号化して実行する。
続いて、このバックドアの主要コンポーネント “OpenAIAgent.Netapi64” により、隠蔽操作が進められる。その名称は OpenAI SDK との統合を示唆しているが、実際には OpenAI Assistants API を純粋に通信チャネルとして利用するものだ。
起動時において、.NET リソース・セクションに埋め込まれた設定データが読み取られるが、そこに含まれるのは、OpenAI API キー／辞書キー名／プロキシ設定などである。
その後に、このバックドアはハードコードされた API キーを使用して OpenAI からベクター・ストアを照会し、そこに感染させたマシンのホスト名が含まれることを確認する。もし、該当するストア名が存在しない場合には、侵害したシステムのホスト名を用いて、初回の通信時に新規のベクター・ストアを作成する。
このコードは、コンフィグレーション３番目の部分で、プロキシ・アドレスの指定の有無を確認する。アドレスが存在する場合には、それが使用されるが、プロキシ情報が存在しない場合には、デフォルトの Web プロキシが利用される。
さらに、このマルウェアは OpenAI アカウントで作成されたアシスタントのリストを取得し、アシスタント ID／名前／説明／指示などのプロパティを解析する。その説明フィールドはコマンド・セレクタとして機能し、SLEEP／Payload／Result のオプションのいずれかを取り込んでいる。SLEEP に設定されている場合に、バックドアは指示フィールドからスレッド ID とメッセージ ID を抽出し、OpenAI からタイミング・コマンドを取得する。
その一方で、Payload コマンドの場合には、暗号化されたメッセージを取得して OpenAI から削除した後に、複数の復号化レイヤーを通じて処理する。
暗号化と難読化技術
OpenAI のコンテキストにおける Assistants とは、特定のタスク・ワークフロー・ドメインに合わせて、開発者や組織がカスタム AI エージェントを作成するための OpenAI プラットフォーム内の機能を指す。
それに対して、SesameOp は高度な多層暗号化を採用し、それにより受信コマンドと送信データの双方を保護する。
この通信で取得されるメッセージには 32-Byte の AES キーが含まれており、このキーは Base64 デコードされた後に、マルウェアに埋め込まれたハードコード済みの RSA 秘密キーで復号される。
実際のペイロードは Base64 デコードされ、派生キーを用いて AES アルゴリズムで復号され、さらに GZIP で解凍される。このような、対称暗号化と非対称暗号化を圧縮と組み合わせた階層化アプローチにより、通信のセキュリティを最大化しながらペイロード・サイズを最小化している。
復号と解凍が完了した後のペイロードは、追加処理を経て辞書構造に変換される。続いて、このバックドアは、URL デコードおよび解析技術を用いてメッセージをキーと値のペアに変換する。さらに、埋め込みの .NET モジュールがリフレクションで動的にロードされ、Microsoft JScript VsaEngine が初期化された後に、Eval.JScriptEvaluate によりペイロードが実行される。
この実行結果は、GZIP 圧縮／AES 暗号化され、Base64 エンコードされた後に、新規メッセージとして OpenAI へポストされる。最終的に、このバックドアはホスト名をエンコードした新規の Assistants を作成し、その説明フィールドを “Result” にコンフィグすることで、実行結果の取得準備が整ったことを攻撃者に通知する。
緩和策
Microsoft と OpenAI は、この脅威に関する共同調査を実施し、攻撃者が使用したとみられる API キーおよび関連アカウントを特定／無効化した。そこで判明したのは、OpenAI からのレスポンスに含まれる timeSLEEP フィールドを、このバックドアが解析し、その値を用いてスレッドのスリープを操作することだ。
調査の結果として確認されたのは、侵害されたアカウントが実行するのは限定的な API 呼び出しのみであり、OpenAI のモデルやサービスとのインタラクションが、C2 通信以外において行われていないことだった。
この深刻な状況を受け、両社は引き続き協力することで、脅威アクターが新興テクノロジーを悪用しようとする手法を解明／阻止していく方針であるという。
Microsoft が強調するのは、この脅威が OpenAI プラットフォームの脆弱性を示すものではなく、正当な機能の悪用であるという点だ。なお、OpenAI Assistants API は 2026年8月に廃止予定である。
Microsoft が推奨するのは、SesameOp および類似の脅威に対抗するための、包括的なセキュリティ対策の実施である。したがってユーザー組織は、インターネットに公開されている全システムを把握した上で、ファイアウォールおよび Web サーバのログを頻繁に監査する必要がある。
さらに、Windows Defender のファイアウォール／侵入防止システム／ネットワークファイアウォールを用いたネットワーク・セグメンテーションの実施により、エンドポイント間の C2 通信をブロックし、横方向の移動 (ラテラル・ムーブメント) を軽減できるという。それに加えて、境界ファイアウォールおよびプロキシの設定を確認し、非標準ポート経由での不正アクセスを制限する必要がある。
また、Microsoft Defender for Endpoint の改ざん防止機能を有効化すれば、攻撃者によるセキュリティ制御の無効化を阻止できる。加えて、エンドポイント検出と対応をブロックモードで実行することで、他のアンチウイルス・ソリューションが脅威を検出できない場合であっても、Microsoft Defender は不正なアーティファクトをブロックできる。
さらに、調査と修復を完全自動モードに設定し、クラウド提供型の保護を有効化すべきである。それにより、急速に進化する攻撃者のツールや手法に対する効果的な防御が実現できる。
この問題の核心は、正規のクラウドサービス (OpenAI Assistants API) を C2 チャネルに悪用し、正当な API 通信に悪意を紛れ込ませる攻撃者の戦術的進化にあります。それに加えて、.NET の AppDomainManager 注入や、多層暗号化／難読化／内部 Web シェルによる深い潜伏が検出を遅らせ、永続化を容易にしている点が懸念されます。従来の通信ベースの検知だけでは見落としが生じやすくなっていると、この記事は指摘しています。ご利用のチームは、ご注意ください。よろしければ、OpenAI で検索を、ご参照ください。
IoT OT Security News 
You must be logged in to post a comment.