GrimResource - 初期アクセスと回避のためのMicrosoft管理コンソール

Overview

Microsoftがインターネットソースのドキュメントに対してOfficeマクロ をデフォルトで無効に した後、JavaScript、MSIファイル、LNKオブジェクト、ISOなどの他の感染ベクトルの人気が急上昇しています。 ただし、これらの他の手法は防御者によって精査され、検出される可能性が高くなります。 成熟した攻撃者は、新たに公開されていない感染ベクトルを利用して、防御を回避しながらアクセスを試みています。 最近の例では、北朝鮮の攻撃者がMSCファイルで新しいコマンド実行技術を使用しました。

Elasticの研究者は、GrimResourceと呼ばれるMSCファイルも活用する新しい感染手法を発見しました。 これにより、攻撃者は、ユーザーが特別に細工されたMSCファイルをクリックした後、 mmc.exe のコンテキストで完全なコードを実行することができます。 GrimResource を利用した サンプル は、6 月 6 日に初めて VirusTotal にアップロードされました。

重要なポイント

• Elasticセキュリティの研究者は、特別に細工されたGrimResourceと呼ばれるMSCファイルを活用した、新しい実在するコード実行手法を発見しました
• GrimResource を使用すると、攻撃者は Microsoft 管理コンソール (mmc.exe) で任意のコードを実行でき、セキュリティ警告は最小限に抑えられるため、初期アクセスを取得して防御を回避するのに最適です
• Elasticは、コミュニティが自分自身を守れるように、手法の分析と検出ガイダンスを提供しています

分析

GrimResource 手法の鍵は、apds.dll ライブラリに存在する古い XSS の欠陥を使用することです。細工されたMSCファイルの適切なStringTableセクションに脆弱なAPDSリソースへの参照を追加することで、攻撃者は mmc.exeのコンテキストで任意のjavascriptを実行できます。 攻撃者は、この手法を DotNetToJScript と組み合わせて、任意のコードを実行することができます。

本稿執筆時点では、野生で同定されたサンプルは、VirusTotalで 0 回の静的検出が行われています。

このサンプルは、最近の無関係な マクロサンプルで観察された transformNode 難読化手法から始まります。 これにより、ActiveX のセキュリティ警告を回避できます。

これにより、以下に再構築するように、難読化された埋め込みVBScriptが発生します。

VBScript は、一連の環境変数でターゲット ペイロードを設定し、 DotNetToJs 手法を利用して組み込み .NET ローダーを実行します。 このコンポーネントをPASTALOADERと名付け、将来的にはこの特定のツールに関する追加の分析をリリースする可能性があります。

PASTALOADER は、前の手順で VBScript によって設定された環境変数からペイロードを取得します。

最後に、PASTALOADER は dllhost.exe の新しいインスタンスを生成し、ペイロードを注入します。 これは、 DirtyCLR 手法、関数のアンフック、および間接的なシステムコールを使用して、意図的にステルスな方法で行われます。 このサンプルでは、最終的なペイロードは Cobalt Strike です。

検出

このセクションでは、このサンプルの現在の動作検出を検証し、手法プリミティブを対象とした新しい、より正確な動作検出を示します。

Microsoft Common Console による疑わしい実行

この検出は、この新しい実行手法が発見される前に確立されていました。 もともとは、同じ MSC ファイルの種類を利用してコンソール タスクパッドのコマンド ライン属性を使用してコマンドを実行する 別の方法 (ユーザーが MSC ファイルを開いた後にタスクパッドをクリックする必要がある) を識別するために設計されました。

process where event.action == "start" and
 process.parent.executable : "?:\\Windows\\System32\\mmc.exe" and  process.parent.args : "*.msc" and
 not process.parent.args : ("?:\\Windows\\System32\\*.msc", "?:\\Windows\\SysWOW64\\*.msc", "?:\\Program files\\*.msc", "?:\\Program Files (x86)\\*.msc") and
 not process.executable :
              ("?:\\Windows\\System32\\mmc.exe",
               "?:\\Windows\\System32\\wermgr.exe",
               "?:\\Windows\\System32\\WerFault.exe",
               "?:\\Windows\\SysWOW64\\mmc.exe",
               "?:\\Program Files\\*.exe",
               "?:\\Program Files (x86)\\*.exe",
               "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.EXE",
               "?:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe")

ここでトリガーされるのは、このサンプルが dllhost.exe の犠牲インスタンスを生成して挿入することを選択したためです。

非標準の Windows スクリプト インタープリタで作成された .NET COM オブジェクト

このサンプルでは、Windows スクリプト ホスト (WSH) スクリプト エンジン (Jscript または Vbscript) の代わりに .NET から RWX メモリ割り当てを探す別の検出をトリガーする DotNetToJScript 手法を使用しています。

次のEQLルールは、.NETローダーを介した実行を検出します。

api where
  not process.name : ("cscript.exe", "wscript.exe") and
  process.code_signature.trusted == true and
  process.code_signature.subject_name : "Microsoft*" and
  process.Ext.api.name == "VirtualAlloc" and
  process.Ext.api.parameters.allocation_type == "RESERVE" and 
  process.Ext.api.parameters.protection == "RWX" and
  process.thread.Ext.call_stack_summary : (
    /* .NET is allocating executable memory on behalf of a WSH script engine
     * Note - this covers both .NET 2 and .NET 4 framework variants */
    "*|mscoree.dll|combase.dll|jscript.dll|*",
    "*|mscoree.dll|combase.dll|vbscript.dll|*",
    "*|mscoree.dll|combase.dll|jscript9.dll|*",
    "*|mscoree.dll|combase.dll|chakra.dll|*"
)

次のアラートは mmc.exe RWXメモリの割り当てを示しており、 process.thread.Ext.call_stack_summary は vbscript.dll から clr.dll への割り当ての起点をキャプチャします。

MMC コンソール ファイルによるスクリプトの実行

前の 2 つの検出は、GrimResource メソッド (DotNetToJS と子プロセスの生成) を武器化するための特定の実装選択によってトリガーされました。 これらの検出は、OPSECに安全な代替手段を使用することで回避できます。

mmc.exeロードjscript.dll、vbscript.dll、msxml3.dllなど、最初は疑わしいと思われる可能性のある他の動作は、無害なデータと比較して明確にすることができます。vbscript.dllを除いて、これらのWSHエンジンは通常、mmc.exeによってロードされることがわかります。

このメソッドの主な側面は、 apds.dll を使用してXSS経由でJscriptを実行することです。 この動作は、 CreateFile 操作としての mmc.exe Procmon 出力で明らかです (apds.dll はライブラリとして読み込まれません)。

Elastic Defendファイルオープンイベントを使用して、ターゲットファイルが apds.dll され、 process.name が mmc.exeである次の検出を追加しました。

次のEQLルールは、MMCコンソールからのスクリプトの実行を検出します。

sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  process.executable : "?:\\Windows\\System32\\mmc.exe" and process.args : "*.msc"]
 [file where event.action == "open" and file.path : "?:\\Windows\\System32\\apds.dll"]

MMC コンソール ファイルによる Windows スクリプトの実行

別の検出およびフォレンジック アーティファクトは、APDS XSS リダイレクトの結果として redirect[*] という名前の一時 HTML ファイルが INetCache フォルダーに作成されることです。

次の EQL 相関を使用して、この動作を検出しながら msc ファイル パスをキャプチャできます。

sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  process.executable : "?:\\Windows\\System32\\mmc.exe" and process.args : "*.msc"]
 [file where event.action in ("creation", "overwrite") and
  process.executable :  "?:\\Windows\\System32\\mmc.exe" and file.name : "redirect[?]" and 
  file.path : "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*\\redirect[?]"]

提供されている動作ルールと共に、次の YARA ルールを使用して、類似のファイルを検出できます。

rule Windows_GrimResource_MMC {
    meta:
        author = "Elastic Security"
        reference = "https://www.elastic.co/security-labs/GrimResource"
        reference_sample = "14bcb7196143fd2b800385e9b32cfacd837007b0face71a73b546b53310258bb"
        arch_context = "x86"
        scan_context = "file, memory"
        license = "Elastic License v2"
        os = "windows"
    strings:
        $xml = "<?xml"
        $a = "MMC_ConsoleFile" 
        $b1 = "apds.dll" 
        $b2 = "res://"
        $b3 = "javascript:eval("
        $b4 = ".loadXML("
    condition:
       $xml at 0 and $a and 2 of ($b*)
}

まとめ

攻撃者は、細工されたMSCファイルを使用してMicrosoft管理コンソールで任意のコードを実行する新しい手法を開発しました。 Elasticの既存のすぐに使えるカバレッジは、Elasticの多層防御アプローチがこのような新たな脅威に対しても効果的であることを示しています。 防御者は、当社の検出ガイダンスを活用して、この手法がコモディティ脅威グループに拡散する前に、自分自身と顧客を保護する必要があります。

Observables

すべてのオブザーバブルは、ECS形式とSTIX形式の両方で ダウンロードすることもできます 。

この研究では、次の観測量について議論しました。