2020年7月ごろから、Microsoft社のデジタル署名（コードサイニング証明書）されたDLLファイルを悪用するマルウェア「SigLoader」が使われた標的型攻撃を複数確認しています。攻撃者によって、正規のデジタル署名されたファイルを攻撃に悪用された場合、セキュリティ対策製品による検知をすり抜け、広範囲にわたる攻撃活動を容易に実行される恐れがあります。
今回は、このMicrosoft社のデジタル署名されたファイルを悪用するSigLoaderの特徴を紹介します。なお、このSigLoaderを利用する攻撃者は、2020年12月1日に、APT10の可能性があることが@Int2e_氏によってTwitter※1で報告されています。
※1 https://twitter.com/Int2e_/status/1333501729359466502
図1は、SigLoaderで悪用されたDLLファイル（wiaky002_CNC1755D.dll）のデジタル署名をWindowsのファイルプロパティまたはSigcheck※2で確認したものです。
※2 Sigcheck - Windows Sysinternals | Microsoft Docs
青線枠で示すように、署名の有効期間が2019年7月27日で失効しているため、エラーメッセージが出力されていますが、赤線枠のように「Signed」と検証されており、署名は正しいものであることがわかります。
また、図2に示すように、このDLLファイルは、Windows 10で利用される「pkeyhelper.dll」のファイルメタ情報やPDBファイル情報を持つことが確認できます。
デジタル署名されたファイルの改ざん手法
SigLoaderは、前述の通りMicrosoft社のデジタル署名されたDLLファイルを読み込み、攻撃に悪用します。一般的にデジタル署名が有効である場合は、署名した組織が実在することやデータが改ざんされていないことなどが証明されており、万一、デジタル署名のあるファイルを改ざんした場合、デジタル署名が無効であると検出されます。
しかし、SigLoaderを利用する攻撃者は、デジタル署名されたDLLファイル内に存在する証明書テーブル（Certificate Table）のサイズを拡張し、そのテーブル内のデータを変更することで、デジタル署名に影響を及ぼさずに、DLLファイルを改ざんしています。
Windowsでは、デジタル署名のハッシュ計算にあたって証明書テーブルを対象範囲外としているため、証明書テーブルを改ざんしたとしてもハッシュ値が一致し、デジタル署名が有効であると表示されます。この手法は、2009年にHugo氏のブログで報告※3されており、その後、2016年にはBlack Hat USAでも発表※4されています。
※3 Changing a Signed Executable without Altering Windows Digital Signatures | Aymeric on Software
※4 Certificate Bypass: Hiding and Executing Malware from a Digitally Signed Executable | Deep Instinct
図3は、Microsoft社のデジタル署名された正規の「pkeyhelper.dll」とSigLoaderが悪用するMicrosoft社のデジタル署名された「wiaky002_CNC1755D.dll（pkeyhelper.dll）」を比較したものです。SigLoaderが悪用する改ざんされたDLLファイルには、正規のDLLファイルには存在しない、赤線枠の領域にデータが含まれていることが確認できます。
SigLoaderを使用した攻撃手口の概要
SigLoaderは、DLL Side-Loadingを悪用して実行されます。正規の実行ファイルによって読み込まれたSigLoaderは、最初に実行ファイルと同じディレクトリ内にあるMicrosoft社のデジタル署名がされたDLLファイル、または暗号化されたペイロード（DATファイル）を読み込みデータを復号します。その後、復号したペイロードをメモリ領域に展開し実行します。最終的に実行されるペイロードは、2020年11月20日時点で3種類が確認できています。
図4は、SigLoaderの挙動を示したものであり、SigLoaderを2段階で使用するケース（青矢印）と1段階のみのケース（赤矢印）の2パターン存在することを確認しています。
以降では、VMware製品の正規実行ファイル（ResolutionSet.exe）を悪用して、実行されるSigLoader（vmtools.dll）の攻撃手口を詳しくみていきます。
SigLoaderが読み込むファイル
SigLoaderには図5に示すように、Sigという文字列を起点に読み込むファイルや暗号化方法などがファイル内にハードコード※5されており、このハードコードされた内容を利用してペイロードが展開されていきます。
※5 別のSigLoaderでは、Sigという文字列や暗号化方法などが未記載のものも確認しています。このようなSigLoaderでは、暗号化方法が記載された箇所に暗号化キーなどが含まれています。
まずSigLoaderはMicrosoft社のデジタル署名されたDLLファイル「wiaky002_CNC1755D.dll」を読み込み、ファイル内のオーバーレイ領域に含まれるデータを取得します。今回のケースでは、先ほど紹介した図3の赤線枠に示すオフセット0xBA488からデータ末尾（0xF4090）までを読み込み、そのコードをメモリ領域上に展開します。このオフセット値0xBA488は、データ末尾から図6に示すように、0x39C08（0x39C05から値を1増やし8の倍数で割り切れる値）バイト遡った値から算出されています。
SigLoaderが利用する暗号化方法
読み込まれたオーバーレイ領域に含まれるデータは、XOR＋カスタムDES＋AESによって暗号化されています。暗号化キーは図7に示すように、SigLoader自体にハードコードされており、AESキーと初期化ベクトル（赤線枠）、カスタムDESで利用するキー（橙線枠）です。また、このSigLoaderには、2段目で利用されるSigLoader（2nd）のAESキーや初期化ベクトル（青線枠）、カスタムDESで利用するキー（緑線枠）もハードコードされています。
SigLoaderはこれらの暗号化キーを使用して、オーバーレイ領域に読み込まれた暗号化データを図8の順で復号※6し、シェルコードをメモリ領域に展開します。復号は、AESでは鍵長256ビット、ブロックチェイニングとしてCBCモードを使用し、カスタムDESでは、鍵長64ビット、ECBモードを使用します。復号後は、Call命令でシェルコードが展開されたメモリ領域を呼び出します。
※6 別のSigLoaderでは暗号化アルゴリズムの適用順序や適用回数が異なる可能性があります。
SigLoaderには、XOR、カスタムDES、AESの3種類の暗号化アルゴリズムが実装されています。これらのうち、SigLoaderで実装されているカスタムDESは、使用される定数に異常はないものの、サブ鍵生成アルゴリズムやラウンド関数などが標準のものと異なっており、標準の暗号化ライブラリでは暗号化されたデータを復号することができません。
また、これらのデータをエンコードするための処理が多数みられ、サブ鍵生成アルゴリズムやラウンド関数などは、攻撃者が自ら実装している可能性があります。また、コード内にRSAの実装を見据えた箇所があることから、今後RSAの処理に関しても実装される可能性があります。
シェルコードによる2段目のSigloader（2nd）作成
復号されたシェルコードは、SigLoader（2nd）を作成するために用いられます。図9は、シェルコードを一部デコンパイルしたものです。特徴的な文字列ecipekac（Cakepice）をチェックするコードが含まれていることが確認できます。
このシェルコードには、自身のコード内に以下の3つのコードが分割されて含まれており、これらを組み合わせて、次のDLLファイルを読み込む2段目のSigloader（2nd）を作成します。分割されたデータの組み合わせ方法は、シェルコードに含まれる文字列ecipekacを起点に行われます。
また、この文字列以降の16バイトには、PEファイルを作成する際のメモリ領域を確保する際のサイズ0x39000（図10：橙線枠）およびSection Headersおよびプログラムコードのサイズ0x038E18（図10：紫線枠）が指定されています。
- Section Headersおよびプログラムコード（図10：緑線枠）
- NT Header（PE Header）（図11：青線枠）
- MS-DOS Header/Stub（図11：赤線枠）
これらのデータの組み換えに際して、最初に図11に示すように赤線枠のMZヘッダが含まれるMS-DOS Header/Stub（0xE0バイト）を事前に確保したメモリー領域にコピーし、次に青線枠のPE Header（0x108バイト）、最後にtextセクションなどが含まれるSection Headersおよびプログラムコード（0x038E18）をコピーし、PEファイル（SigLoader）を作成します。その後は、Call命令で2段目のSigLoaderが展開されたメモリ領域を呼び出します。
SigLoader（2nd）が読み込むファイルと暗号化方法
2段目のSigLoader（2nd）は、前述したSigLoader（1st）とほぼ同様な作りです。SigLoader（2nd）は、図12に示すように、正規実行ファイルと同じディレクトリにあるMicrosoft社のデジタル署名されたDLLファイル「c_apo_ipoib6x.dll」のオーバーレイ領域に含まれるデータを読み込み、データを復号します。その後、復号したシェルコードをメモリ領域上に展開し、Call命令で呼び出します。
このDLLファイルは、図13に示すように、Windows 10で利用される「wintrust.dll」を改ざんしたものです。展開されたシェルコードは、SigLoader（1st）によって作成された文字列Cakepiceを含むシェルコードとは異なります。
なお、データの暗号化方法については、SigLoader（1st）と同様のものが利用されており、データの復号順序は、SigLoader（1st）とは逆順のAES＋XOR(Key=0x0)＋カスタムDES＋XOR(Key=0xBC)です。また、AESおよびカスタムDESの暗号化キーについては、図7に示した青線枠と緑線枠のものが利用されています。
シェルコードによる最後のペイロード作成
SigLoader（2nd）によって復号されたシェルコードは、最後のペイロードを作成するために用いられます。最後のペイロード（図14：青線枠）は、シェルコード内にRC4で暗号化されて含まれており、図14の赤線枠で示すRC4キーで復号することで最終的なペイロードをメモリ領域に展開します。復号後は、Call命令でペイロードが展開されたメモリ領域を呼び出します。
最終的に実行されるペイロード（DelfsCake）
最終的に実行されるペイロード（DelfsCake）は、DLL形式で、C2サーバからデータやペイロードなどを受信して実行する機能を有します。
DelfsCakeには、図15に示すようにRSA公開鍵（1024bit）がハードコードされており、この鍵を使用して送信するデータを暗号化します。初期通信時に送信する内容は、図16の通りです。ユーザ名やコンピュータ名、プロセスID、OSバージョン、ビルド番号、ソケット名、実行日時、ランダムに生成した文字列などがC2サーバに送られます。
DelfsCakeには、表1に示すコマンドが実装されています。なお、コマンド「d」に関しては、コマンドの受信時のデータを使用してライブラリのロードと関数アドレスの取得を行い、その関数をCall命令で呼び出します。Call命令の際に引数として受信したデータを指定することから、単純なコマンド実行を行う命令ではないと考えます。
| 命令コマンド | 説明 |
|---|---|
| d | 詳細不明 |
| f | C2通信の終了 |
| l | Sleep間隔の設定 |
| s | シェルコードの実行 |
また、このDelfsCakeを実際に動作させてみましたが、2020年10月30日に確認した時点では、図17に示すように、C2サーバに接続後、RSTパケットが戻ってきており、C2サーバからデータは取得できていないため、最終的にどのようなマルウェアが実行されるか不明です。
SigLoaderによって展開される最終的なペイロードは、DelfsCakeの他にも2種類確認しています。1つは、ペネトレーションツールであるMetasploit Framework※7 やCobalt Strike※8で作成されたシェルコードです（図18）。シェルコードは、C2サーバと通信を確立した後、Cobalt Strike Beaconなど次のステージのマルウェアをダウンロードし、実行します。このシェルコードには、特徴的な文字列（baidu.com）が複数ハードコードされていることが確認できます。
※7 Metasploit | Penetration Testing Software, Pen Testing Security | Metasploit
※8 Adversary Simulation and Red Team Operations Software - Cobalt Strike
もう1つも、次のステージのマルウェアをダウンロードし、実行することが主な機能と考えられるマルウェア（GreetCake）です。図19に示すようにRC4キーがハードコードされており、この鍵を使用して送信するデータを暗号化します。また、表2のような、いくつかのコマンド機能が実装されています。
GreetCakeは、C2サーバから特定の命令コマンドを受信することによって、C2サーバからデータをダウンロードし、復号後、PEファイルを実行します。図20に示すように、実行する前にPEファイル内に「hello」という文字列が含まれているか確認するというコードが特徴的です。
| 命令コマンド | 説明 |
|---|---|
| 0x12C | C2通信の終了 |
| 0x12D | スレッドを作成し、PEファイルの実行 |
| 0x12F | データ送信（詳細不明） |
| 0x130 | PEファイルの実行 |
| 0x131 - 0x134 | C2通信制御の設定（スリープ時間、タイムアウトなど） |
これら2種類のペイロードについても、DelfsCakeと同様にC2サーバからダウンロードされるデータは取得できていないため、最終的にどのようなマルウェアが実行されるかは不明です。
まとめ
今回は、Microsoft社のデジタル署名されたDLLファイルを悪用するSigLoaderについて紹介しました。
SigLoaderは、デジタル署名されたDLLファイルの悪用、ペイロードの多段利用や攻撃者が独自に開発した暗号化方法の利用と高度な技術が組み込まれたローダです。暗号化方法では、RSAのコードが未実装であり、開発途中の可能性が窺えるため、今後も、さらに機能が向上したSigLoaderによる攻撃が続く可能性があります。
加えて、今回のデジタル署名されたファイルの改ざん手法を悪用した攻撃は、実際のサイバー攻撃の事例としてあまり報告されておらず、既存のセキュリティー対策製品で検出できない可能性があり、注意が必要です。
私たちがSigLoaderの攻撃を確認した事例の1つでは、攻撃者は標的組織への侵入経路として、SSL-VPN製品の脆弱性を悪用後、端末を侵害しSigLoaderを設置していました。SSL-VPN製品を悪用する攻撃は、標的型攻撃に限らず、金銭目的である攻撃者なども悪用しており、これらの製品の脆弱性を悪用されないためにも、日々の脆弱性情報の管理と修正パッチの適用や緩和策の適用などの早急な対応が求められます。
また、2020年10月ごろからZerologonの脆弱性※9が標的型攻撃で悪用されていることが、CISA※10やSymantec社※11から報告されていますので、この脆弱性についても十分に注意する必要があります。
※9 CVE-2020-1472 - セキュリティ更新プログラム ガイド - Microsoft - Netlogon の特権の昇格の脆弱性