DinDoorバックドア、DenoおよびMSIインストーラーを悪用して検出を回避

DinDoorは、JavaScript実行時Denoおよびエムアイファイルを悪用して、従来の検出制御をこっそり回避しながら攻撃者が制御するコードを実行する新たに文書化されたバックドアです。

信頼できるランタイムと一般的なWindowsツールに隠れることで、脅威アクターはエンタープライズ環境にファイルレスまたは低フットプリントマルウェアを展開する柔軟な方法を得られます。

従来のコンパイル済みインプラントを提供する代わりに、DinDoorは多くの組織が開発者向けに許可リストに登録している正当な署名付きランタイムであるDenoで実行される難読化されたJavaScriptを配信します。

このシフトにより、PowerShell、Python、またはNode.jsアクティビティに対して徹底的に調整されているが、Deno ベースの実行に可視性がない環境に盲点が生まれます。

DinDoorは2026年3月に初めて公開で名付けられました。履歴的にNode.jsに依存していたJavaScriptリモートアクセスツールであるTsundere botnetの変種として追跡されています。

複数のベンダーと独立した研究者は、最近のDinDoorキャンペーンをイラン系APTグループSeedworm（MuddyWaterとも呼ばれる）にリンクさせており、このグループは米国および他のグローバル組織をフィッシングとコラボレーションプラットフォームの罠で標的にしてきました。

同じインフラストラクチャとツーリングのエコシステムは、CastleLoader/CastleRATを含む、より広範なマルウェアアズアサービスプラットフォームと重なり、オペレーターに共有されたマルチテナントバックエンドを提供します。

MSIおよびDenoを介した配信

DinDoorは主にフィッシングメール、ドライブバイダウンロード、またはメッセージングプラットフォームのソーシャルエンジニアリング経由で配信される悪意のあるMSIインストーラーを通じて到着し、多くの場合ドキュメントまたはビジネスソフトウェアになりすまします。

実行すると、msiexec.exeはJuliet_widget15.ps1をAppData\Local\documents\にドロップし、cmd.exeで起動します。このとき、表示されるウィンドウを非表示にし、プロファイル読み込みをスキップし、実行ポリシーエンフォースメントを無効にするフラグが使用されます。

実行時、MSIはmsiexec.exeを使用して中間スクリプト（PowerShellおよび/またはVBScript）をステージングし、感染チェーンの残りの部分を処理します。

これらのスクリプトは最初にユーザープロファイルディレクトリにDenoが存在するかどうかをチェックし、存在しない場合は管理者権限を必要とせずに正当なdl.deno[.]landエンドポイントからサイレントにダウンロードします。

観察された1つのバリアントでは、PowerShellスクリプトがbase64デコードされたJavaScriptペイロードをディスクに書き込んでdeno.exeで呼び出しますが、別のバリアントはdata:application/javascript;base64URIをDenoに直接渡すため、ペイロードはメモリ内でのみ実行されます。

このメモリ内オプションはディスク上にスクリプトファイルを残さず、フォレンジック成果物を大幅に減らし、多くのファイル中心のアンチウイルス検出をバイパスします。

deno.exeが制御を引き継ぐと、DinDoorはまずlocalhostのTCPリスナーをバインドし、10044または10091などの固定ポートを使用し、ポートが既に使用中の場合は終了し、同じホスト上の複数感染を防ぐシンプルなミューテックスとして機能します。

その後、マルウェアは、ユーザー名、ホスト名、総RAM、OSリリースなどのプロパティをハッシュして、すべてのコマンド&コントロール（C2）リクエストに添付される一意の16文字の16進識別子を取得することで、被害者を指紋認証します。

DinDoorはC2をプローブし、短いタイムアウトGETリクエストを/healthエンドポイントに送信し、次のステージに進む前にHTTP 200と本体「ok」を期待します。

あるMSIサンプルでは、C2 URLパスは固定されたJSON Webトークン（JWT）セグメント（例：/mv2/<JWT>/<victim_hash>）を埋め込みます。これはキャンペーンメタデータを開示し、アクティビティを以前は国家が後援するオペレーターと犯罪オペレーターの両方に関連付けられていた共有ドメインserialmenot[.]comに結びつけます。

他のバリアントは/eventなどの代替パスとより重い JavaScript難読化を使用していますが、同じコア指紋認証とビーコンロジックを維持しています。

インフラストラクチャと検出機会

Hunt.ioの研究者は、DinDoor HTTPレスポンスが十分に一貫性があり、インフラストラクチャ発見のピボットとして使用できることを示しました。特にポート80上のサーバーは404 Not Foundを返し、Content-Length: 13およびVia: 1.1 Caddy, 1.1CaddyおよびX-Request-Idのヘッダーを含みます。

これらの特性に基づいて構築された単一のHuntSQLクエリは、約15の自律システム全体で約20個のアクティブなDinDoorサーバーを表示し、多くは遅い悪用処理または「防弾」サービスとして知られているホスティングプロバイダー上にあります。

追加の確認は/healthエンドポイントのクエリと「ok」レスポンスのチェックで可能であり、動作の変更は休止中または再構成されたインフラストラクチャを反映する可能性があることに注意してください。

防御の観点からは、DinDoorのチェーンは複数の遮断ポイント（AppLockerまたはWDACを介したMSI実行の厳密化、PowerShellまたはwscriptによって生成された予期しないdeno.exeプロセスの監視、data: URIからbase64 JavaScriptを直接実行するDeno コマンドラインのアラート）を提供します。

ネットワークチームは、特徴的なCaddyヘッダー、serialmenot[.]comまたは関連するホスティングプロバイダーへの予期しないトラフィック、およびDeno開始アウトバウンド接続に関連する異常についてのログもレビューする必要があります。

IOCs