Windowsを標的とするバックドア「TASK#STOMP」は、VBScript、PowerShell、スケジュールタスク、そしてランタイムでのC#コンパイルを組み合わせることで、堅牢な永続化を確立し、業務文書を継続的に窃取します。
このインプラントはスクリーンショットの取得、保存済みWi-Fiパスワードの抽出、クリップボードデータの収集も行うほか、操作者から受け取った任意のコマンドを実行します。
当初の感染経路は確認されていませんが、確認された配置場所からは、フィッシング添付ファイル、ブラウザ経由のダウンロード、アーカイブの展開、リムーバブルメディア、あるいは手動実行など、いずれの経路とも矛盾しません。
Securonixは、プロセスのテレメトリだけでは侵入初期のベクトルを特定できないと強調しています。
VBScriptはインストーラー兼オペレーションコントローラーとして機能します。%LOCALAPPDATA%\WinDefendSvc配下にステージング用ディレクトリを作成しますが、このディレクトリ名は正規のWindows Defender関連サービスを装うよう設計されており、同ディレクトリに保存されたXML定義から4つのスケジュールタスクを登録します。
これらのタスクには「Local Credential Manager」「Network Audio Service」「Windows Display Manager」「Device Credential Handler」といった、いかにも信頼できそうな名前が付けられています。
2回目以降の実行時、TASK#STOMPは同一のタスクXMLファイルを再利用しつつ、表示されるタスク名だけをローテーションさせることができます。これにより、スケジュールタスクの名前のみに依存する検知を無効化してしまいます。
このマルウェアはさらに、msdiag.vbsを現在のユーザーのスタートアップフォルダにもコピーします。
これにより、タスクスケジューラに依存しない追加の永続化経路が確保されます。ユーザーがサインインすると、Windows Script HostがVBSコンポーネントを再起動し、削除されたタスクを再作成し、停止しているプロセスを置き換え、PowerShellペイロードを再起動できるようになるのです。
研究者らは、単一の足がかりを除去しただけでは感染を根絶できない可能性があると指摘しています。残された他の仕組みが感染を復元してしまうためです。
TASK#STOMPは、sys_loader.ps1とwin_conn.ps1という2つの隠れたPowerShellモジュールを、-NoProfile、-ExecutionPolicy Bypass、-WindowStyle Hiddenの各オプション付きで起動します。
その前段階として、インストーラーは実行中のプロセスを列挙し、コマンドラインにsys_loaderまたはwin_connを含む古いインスタンスを終了させたうえで、クリーンなコピーを再起動します。
Securonixの分析によると、この攻撃キャンペーンはエンコードされたVBScript(95c9050t66.vbsとして観測)から始まり、ユーザーがアクセス可能なデスクトップ上のパスからwscript.exeによって起動されます。
TASK#STOMP PowerShellバックドア
これらのスクリプトは、diag_pack.datやwin_conn_cfg.datを含む.datファイルからBase64エンコードされたコンテンツをデコードし、復元したPowerShellコードをメモリ上で実行します。
Win32_Processへの問い合わせにより、スクリプトはpowershell.exeのような一般的なプロセス名だけに頼らず、完全なコマンドラインを検査できます。
エンコードされたペイロード自体はディスク上に残るため、これは完全なファイルレスマルウェアとは言えません。ただし、平文のバックドアは実行前にPowerShellスクリプトとして書き出される必要がありません。
主要モジュールは、Wordファイル、PDF、PowerPointファイル、Excelスプレッドシート、アーカイブなど、業務に関連するファイルを固定ドライブ上で検索します。
最近のファイルを優先し、500MBを超える大容量ファイルはスキップし、すでにアップロード済みのデータを追跡しつつ、ファイルシステム監視によって新規作成または更新された文書を継続的に収集していきます。
いずれのPowerShellブランチも、トークン認証を用いる2つのコマンド&コントロール(C2)サーバー、corecloudfileshare[.]xyzとattachmentsharingdrive[.]xyzと通信します。一方のサーバーに障害が発生した場合、マルウェアはもう一方に切り替える仕組みになっており、基本的な運用上の冗長性を確保しています。
各モジュールはコマンドをポーリングし、実行結果を送信し、窃取したデータをアップロードするとともに、被害者情報や転送状況を記録するローカルファイルを維持管理します。
この攻撃活動で注目すべき要素の一つが、正規の.NETコンパイラであるcsc.exeを通じ、PowerShellのAdd-Typeを使ってランタイムでC#をコンパイルする手法です。
このコンパイル済みヘルパーはTLS証明書検証を無効化するため、攻撃者側のインフラが無効な証明書、自己署名証明書、期限切れ証明書、あるいはホスト名が一致しない証明書を使用していても、バックドアは通信を継続できます。
それぞれのPowerShellブランチは、独自にpowershell.exe → csc.exe → cvtres.exeという実行チェーンを生成します。
デコードされたペイロードからは、TASK#STOMPが文書窃取をはるかに超える機能を備えていることが判明しています。
操作者は、プライマリディスプレイのキャプチャ、netshを使ったWi-Fiパスワードの取得、クリップボードテキストの収集と消去、ホスト情報の取得、そしてInvoke-Expressionを通じた任意のPowerShellコマンドの実行を、コマンドとして指示できます。
今回観測された設定はスパイ活動と継続的なデータ収集に重点を置いたものですが、無制限のコマンド実行機能は、初期侵害後に追加マルウェアを展開したり、認証情報を窃取したり、水平展開(ラテラルムーブメント)を行ったり、破壊的な行動を開始したりする目的にも悪用され得ます。
防御側は、個別の痕跡指標(IOC)よりも相関関係を優先して検討すべきです。ユーザー書き込み可能なAppDataディレクトリから起動される隠れたPowerShell、ScriptBlockへのBase64デコードなどが該当します。
証明書検証を無効化するAdd-Type呼び出し、powershell.exeがcsc.exeを生成する挙動、%LOCALAPPDATA%配下に保存された不審なタスクXML、そしてPowerShellがnetsh wlan … key=clearを呼び出す動作は、いずれも価値の高いシグナルです。
対応措置を講じる前に、スケジュールタスクのXML、スタートアップフォルダ内のスクリプト、PowerShellのスクリプトブロックログ、AMSIのテレメトリ、コンパイラの生成物、そしてステージングされた.datファイルを保全しておくことが極めて重要です。
SOCのアラート調査時間を1件あたり21分短縮。即座のインシデント対応のため、IOCコンテキストをSOCに組み込みましょう: TI LookupをSOCに統合する
翻訳元: https://gbhackers.com/taskstomp-powershell-backdoor/
