掲載日:2020/12/25

Bromium Blog記事

ドロッパー、ダウンローダーとTrickbot :ツールマークを利用してCOVID-19をテーマにしたステルス性の高いキャンペーンを検知する

※ 本ブログは、2020年10月8日にBromium BlogにポストされたDroppers, Downloaders and TrickBot: Detecting a Stealthy COVID-19-themed Campaign using Toolmarksの日本語訳です。

 

イントロダクション

フォレンジックの教義の一つに、犯罪の加害者が行ったすべての行為は痕跡を残すというロカールの交換原理があります[1] 。 これらの痕跡を注意深く収集し、解釈するプロセスを通 じて、捜査官は何が起こったのかを特徴づけ、加害者の能力など犯罪の他の側面について仮説を立てることができるのです。この考え方は、物理的な犯罪現場と同様に、デジタル・フォレンジックにも当てはまります。マルウェアを含むサイバー犯罪では、脅威アクターは目的を達成するために、ターゲットのネットワークのセキュリティ対策を回避するための防御回避技術を使用する必要があります[2]。 ネットワーク防御者にとって朗報なのは、これらの技術にはファイルの操作が含まれていることが多く、これによって痕跡や「ツールマーク」が残り、悪意の兆候として使用したり、特定の脅威アクターを追跡したりすることができるということです。 [3] この記事では、2020年9月にCOVID-19アラートや請求書を装ったステルス型Trickbotキャンペーンが、ファイルにペイロードを暗号化、変更、埋め込みすることで検知を逃れた方法を解説します。

 

バックグラウンド

Trickbotの運営者がドロッパーと戯れる  2020年7月

2020年7月には、バンキング型マルウェアTrickbotを配信する異常なスパムキャンペーンが発生しました。すべてのTrickBotバイナリで使用される設定データにはgtagと呼ばれる識別子が含まれており、マルウェアを配信するために使用されたキャンペーンや配信方法を表しています[4]。 そのキャンペーンでは、gtag「end4」を使用したTrickBotの実行ファイルがMicrosoft Word文書の添付ファイルに埋め込まれていました[5]。 これは、ダウンローダーがリモートサーバーからペイロードを取得して実行するという、TrickBotの運営者が通常好む配信メカニズムとは異なっていました。過去2年間、私たちは、難読化されたVisual Basic for Applications (VBA)マクロを含む、これのバリエーションを見てきました。また、TrickBotは、JScriptダウンローダであるOstapを使って配信されたり、Emotetに感染したシステムを介して配信されたりしています[6]。

 

2014年に初めて確認されたTrickBotは、ロシアから運営されていると考えられているモジュール型のバンキング型トロイの木馬です[7]。 Webインジェクションによる不正取引を行い、銀行の認証情報を盗むための広範な機能を備えています。しかし、2019年6月以降は、特に大企業を相手に、侵入後のツールやRyukランサムウェアを配布するプラットフォームとしても利用されています[8]。

 

攻撃者がドロッパーを選ぶ理由

ドロッパーは、ダウンローダーよりも攻撃者にいくつかの利点を提供しています。

 

マルウェアを外部にホストする必要がない

ペイロードはファイルに埋め込まれているため、外部でホスティングする必要はありません。これにより、ペイロードをホスティングするためのウェブインフラストラクチャの取得と管理に関連する時間とコストが節約されます。攻撃者は、防弾ホスティングプロバイダからウェブサーバを購入したり、正当なウェブサーバを侵害したりする必要はありません。

 

検知された際の露出を減らす

また、ペイロードを文書に埋め込むことで、Web プロキシやネットワーク侵入検知システムなど、ネットワークトラフィックを検査して悪意のある活動を検知するセキュリティ対策によってマルウェアが検知される可能性が低くなります。このため、悪意のある添付ファイルをブロックするために、電子メールゲートウェイへの依存度が高くなります。これらの対策は、特に TrickBot の場合のように、C2 サーバーが定期的にローテーションしている場合には、コマンド&コントロール(C2)トラフィックのブロックにはあまり効果的ではない傾向があります。マルウェアのホスティングに使用されるウェブサーバは、アクティブな期間が長くなる傾向があるため、ブロックされる可能性が高くなります。

 

テイクダウンの影響を受けない

ドロッパーは、ネットワーク防御者によってテイクダウンされることはありません。ダウンローダーの場合、ペイロードをホストするために使用されているウェブサーバは、ホスティングプロバイダやドメインレジストラへの不正使用報告を通じて、テイクダウンの対象となる可能性があります。テイクダウンは、小規模なホスティング・インフラの脅威アクターの活動を中止させるのに特に効果的です。大規模なホスティング・インフラは、テイクダウンに対してより強い耐性を持つ傾向があります。このことは、エンティティ(この場合は、ウエブサーバ、ダウンローダー、ペイロード)間の関係のタイプを分析する[9]、ネットワーク分析によりマルウェア配信ネットワークを調べると明らかになります。

 

脅威アクターが数台のウェブサーバしか持っていない場合、各ホスティングノードとキャンペーンで使用するダウンローダとの結びつきの数が多くなります。これは、ホスティングに使用される各ノードが流通ネットワークの中で高度な中心性を持っていることを意味します。これらのウェブサーバは、オフラインになった場合にマルウェアの配布を厳しく制限する「チョークポイント」を表しています。逆に、多くのウェブサーバで構成される配信ネットワークは、各ホスティングノードとの結びつきが少ないため、テイクダウンに対してより強い耐性を持っています。そのため、攻撃者はホスティング能力が不足している場合には、ダウンローダーの代わりにドロッパーを使用することを決定するでしょう。

 

Ostapをダウンローダーとして使用した2019年7月~8月のTrickBotキャンペーン。最もエッジの多い2つの黄色のノードを削除すると、感染数を大幅に減らすことができる。 図1 - Ostapをダウンローダーとして使用した2019年7月~8月のTrickBotキャンペーン。最もエッジの多い2つの黄色のノードを削除すると、感染数を大幅に減らすことができる。

 

防御者ネットワークにアーテファクトを残さない

また、ドロッパーは、防御者ネットワークにマルウェアの最初のダウンロードと実行に関連した侵害の痕跡(IOC)を残しません。Web サーバ構成、DNS、WHOIS レコード、その他のネットワークアーティファクトは、時間の経過やキャンペーン全体の脅威グループの活動を追跡するための貴重な情報源となります。

 

ドロッパーの欠点

 

ターゲティングおよび運用上のセキュリティ(OPSEC)の悪化

ダウンローダーがドロッパーよりも優れている分野の1つに、OPSECがあります。ダウンローダーを使用すると、脅威アクターは、IPアドレス(ジオフェンシング)、ユーザーエージェント、およびマルウェアをホストするウェブサーバーから取得可能なその他のクライアント情報に基づいて、ターゲットを選択することができます。また、攻撃者はペイロードを自由に切り替えられるため、研究者や防御者がマルウェアをダウンロードして分析する機会を減らすことができます。しかし、これらの OPSEC の利点は、TrickBot のような大規模に展開されたマルウェアファミリーの運用者にとっては、一般的にあまり重要ではないと考えられています。

 

Trickbotマルスパム・キャンペーン 2020年9月

 

COVID-19とインボイス・ルアー

2020年9月16日から、COVID-19アラートや請求書を装った何百もの暗号化されたDOCM添付ファイルにトロイの木馬が埋め込まれている「ONO76」というgtagを使用したTrickBotスパム・キャンペーンを大量に検知しました。

2020年9月からのTrickBotキャンペーンで使用されたフェイク請求書ルアー 図2 - 2020年9月からのTrickBotキャンペーンで使用されたフェイク請求書ルアー

 

低い検知率

VirusTotalでの検知率が比較的高かった(30/61)[5]7月のキャンペーンで使用された文書と違い、今回のキャンペーンで使用されたファイルは、効果的に検知を回避しています。サンプルの70%は4種類以下のスキャンエンジンでしか検知されず、いくつかのファイルでは検知がゼロになっています(図3、4)。

 

検知を回避したTrickBotサンプル、2020年9月 図3 - 検知を回避したTrickBotサンプル、2020年9月

 

 

TrickBotサンプルの低い検知率、2020年9月 図4 - TrickBotサンプルの低い検知率、2020年9月

 

TrickBot ドロッパーのツールマーク

 

文書の暗号化

これらの検知率の低さは、主にMicrosoft Wordの「パスワードで暗号化」機能を使用して文書が暗号化されていたことが原因でした。今回の場合、文書の内容と拡張メタデータは、CBC モードの AES を使用して 256 ビットのキーで暗号化されていました。悪意のある添付ファイルを含む電子メールにはパスワードが参照されており、受信者は文書を復号化して開くことができるようになっていました。このキャンペーンで発見された最も一般的なパスワードは、正規表現[A-Z]{3}\d{2}と一致する5文字の長さのものでした(例:「DLW16」)。パスワードがないと、静的エンジンや行動エンジンはファイルの内容を検査することができません。また、文書のパスワードがわからないと調査が遅くなります。

 

Wordのビルトイン暗号化機能を使ってDOCMファイルを暗号化することの副作用の一つは、fileやexiftoolのようなツールが文書のメタデータを完全に解析できないことです。例えば、このキャンペーンのドキュメントの1つのfileコマンドの出力は次のようになっています。

 

CDF V2 Document, corrupt: Cannot read summary info

 

VirusTotalの「magic」ファイル検索修飾子と組み合わせると、この出力は暗号化されたOffice文書を識別するための便利な方法になります[10]。 例えば、以下のようになります。

 

magic:"CDF V2 Document, corrupt: Cannot read summary info"

 

同様に、exiftool は通常、文書の作成日、作成者、使用した Microsoft Office のバージョンやロケールに関する情報などの広範なメタデータを解析します。今回のキャンペーンでは、ドロッパーがドキュメントの本文に長いVBScriptを保存していたため(図6)、非常に高いワード数(10,000を超える)が通常であればexiftoolによって表示されます。しかしながら、このメタデータは暗号化されているためにアクセスできません。したがって、exiftoolからの限られた出力は、暗号化されているか、メタデータが削除されていることを示す証拠として使用することができ、アナリストはさらに調査するように促されるでしょう。

 

異常なバイトの修正

脅威者が悪意のある文書のテンプレートを作成し、ペイロードやダウンロードロジック部分以外をプログラムで変更しているのをよく見かけます[11][12]。このようなわずかな変更は、各文書が変更の結果としてユニークなハッシュ値を生成するため、ハッシュベースの検知を回避するために行われるのが一般的です。今回のキャンペーンでは、以下の値で変更された2バイトを除いて、400以上のドキュメントが同一であることがわかりました。

 

オリジナルの値 新しい値
0xFFFF 0x9090
0xFFFF 0x1010
0xFFFF 0xE2E2
0xFFFF 0x1717

 

これらのファイルアーティファクトを利用して、ファイルの内容が暗号化されているにもかかわらず、今回のキャンペーンで配布されたTrickBotのドロッパー文書を高い信頼性で検知するYARAルールを記述することができました。

2020 年 9 月から TrickBot ドロッパーのドキュメントに残されたツールマーク。一番下のドキュメントの2バイトが0xE2E2で修正されています。 図 5 - 2020 年 9 月から TrickBot ドロッパーのドキュメントに残されたツールマーク。一番下のドキュメントの2バイトが0xE2E2で修正されています。

 

実行チェーン

すべてのドキュメントには、ルアー画像の後ろに格納されたVBScriptをコピーするAutoOpenマクロが含まれており、これによりファイルが、C:ProgramData内に.VBE(VBScript Encoded File)というファイル拡張子で書き込まれます。

ルアー画像の背後に隠されたエンコードされたTrickBotペイロードを含むVBScript、2020年9月 図6 - ルアー画像の背後に隠されたエンコードされたTrickBotペイロードを含むVBScript、2020年9月

 

 

 C:\ProgramDataにドロップされたVBEファイル 図7 - C:\ProgramDataにドロップされたVBEファイル

 

VBAマクロがTrickBot DLLペイロードを実行する2つの方法を確認しました。一つ目の方法では、マクロは、VBAのSecond、Minute、Hour、Day、Month、Year関数によって返されるシステムの日付と時刻を開始時刻を設定した"Windows Defender "という名前のスケジュールされたタスクを作成して実行します。トリガイベントは、デフォルトのVBEファイルハンドラであるWScript.exe (Windows Script Host)を使用してVBEファイルを実行します。もう一つの方法は、VBEファイルを実行するためにWshShellオブジェクトを作成し、こちらもWScript.exeも使用してファイルをオープンします。

スケジュールされたタスクを使用してドロップされた VBE ファイルの実行 図 8 - スケジュールされたタスクを使用してドロップされた VBE ファイルの実行

 

 

 WshShell オブジェクトを使用してドロップされた VBE ファイルの実行 図 9 - WshShell オブジェクトを使用してドロップされた VBE ファイルの実行

 

VBE ファイルにはジャンクコードと TrickBot のペイロードが含まれており、16 進数値(図 10)または Base64 エンコードされたものが格納されています。スクリプトは C: にディレクトリを作成し、そこに .DLL という拡張子を付けてペイロードを書き込みます。

ドロップされたVBEファイルに16進数で格納されたTrickBotペイロード 図10 - ドロップされたVBEファイルに16進数で格納されたTrickBotペイロード

 

最後に、スクリプトはペイロードをデコードするために certutil を実行し、その後 regsvr32.exe を使用して実行します(図 11)。

 HP Sure Click Enterprise の動作トレースで、regvr32.exe による TrickBot ペイロード (APSLVDFB.dll) の実行を表示 図 11 - HP Sure Click Enterprise の動作トレースで、regvr32.exe による TrickBot ペイロード (APSLVDFB.dll) の実行を表示

 

 

結論

脅威アクターは、システムを侵害する可能性を高めるための方法を常に試行錯誤しています。これには、ダウンローダーの代わりにドロッパーを使用すること、特に小規模なホスティング・インフラを所有していてテイクダウンに弱い場合の、静的解析やふるまい解析を回避するための暗号化、ハッシュ検索を回避するためのファイルの修正などが含まれます。しかし、2020年9月に私たちが見たTrickBotキャンペーンのようなステルス性の高いものであっても、これらの解析対応策は、ネットワーク防御者がマルウェアキャンペーンを識別し追跡するための検知ロジックの構築に利用できるアーティファクトを残します。

 

侵害の痕跡

SHA-256 Hash Context
7FEE0F3ADB6BB5A3ED22AD960709A87893E2512D099F6C8C39946097D9A4122B TrickBot payload DLL using gtag “ono76”
FDFB6706E3F056404DA1928A1A8DC3BCE4AB4B8473F49E1C246B4AB2EDC69AD4
052C9196DFE764F1FBD3850D706D10601235DC266D1151C93D34454A12206C28

 

YARAルール

rule trickbot_maldoc_embedded_dll_september_2020 {
   meta:
       author = "HP-Bromium Threat Research"
       date = "2020-10-03"
       sharing = "TLP:WHITE"

   strings:
       $magic = { D0 CF 11 E0 A1 B1 1A E1 }
       $s1 = "EncryptedPackage" wide
       $s2 = "{FF9A3F03-56EF-4613-BDD5-5A41C1D07246}" wide
       $s3 = { FF FF FF FF FF FF FF FF FF FF ( 90 90 | 10 10 | E2 E2 | 17 17 ) FF FF FF FF FF FF FF FF FF FF }

   condition:
       $magic at 0 and
       all of ($s*) and
       (filesize > 500KB and filesize < 1000KB)
}

 

ファイル名パターン

\d{4,6}170920\d{4,6}\.doc
[A-Z0-9]{2,4}_Inv_[A-Z0-9]{2,4}\.doc
\d{6}\.doc
[A-Z0-9]{8}\.doc
[a-z]{5,10}\d{4,5}\.doc

 

文書のパスワード

INV15
DLW16

 

リファレンス

関連記事