1/19 【緊急レポート】Microsoft社のデジタル署名ファイルを悪 用する「SigLoader」による標的型攻撃を確認 lac.co.jp/lacwatch/report/20201201_002363.html テクニカルレポート　|　 2020年12月 1日 セキュリティ 標的型攻撃 石川 芳浩 【更新情報】2021年1月13日 IOC（Indicator Of Compromised）を追記いたしました。 ラックの石川と松本です。 2020年7月ごろから、Microsoft社のデジタル署名（コードサイニング証明書）されたDLLフ ァイルを悪用するマルウェア「SigLoader」が使われた標的型攻撃を複数確認しています。 攻撃者によって、正規のデジタル署名されたファイルを攻撃に悪用された場合、セキュリテ ィ対策製品による検知をすり抜け、広範囲にわたる攻撃活動を容易に実行される恐れがあり ます。 https://www.lac.co.jp/lacwatch/report/20201201_002363.html https://www.lac.co.jp/lacwatch/report/ https://www.lac.co.jp/lacwatch/security/ https://www.lac.co.jp/lacwatch/targeted_attack/ https://www.lac.co.jp/lacwatch/author_ishikawa/ 2/19 デジタル署名DLLファイルを悪用するSigLoader 今回は、このMicrosoft社のデジタル署名されたファイルを悪用するSigLoaderの特徴を紹介 します。なお、このSigLoaderを利用する攻撃者は、2020年12月1日に、APT10の可能性が あることが@Int2e_氏によってTwitter で報告されています。 ※1 https://twitter.com/Int2e_/status/1333501729359466502 図1は、SigLoaderで悪用されたDLLファイル（wiaky002_CNC1755D.dll）のデジタル署名を WindowsのファイルプロパティまたはSigcheck で確認したものです。 ※2 Sigcheck - Windows Sysinternals | Microsoft Docs 青線枠で示すように、署名の有効期間が2019年7月27日で失効しているため、エラーメッセ ージが出力されていますが、赤線枠のように「Signed」と検証されており、署名は正しいも のであることがわかります。 ※1 ※2 https://twitter.com/Int2e_/status/1333501729359466502 https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck 3/19 図1 Microsoft社のデジタル署名を持つDLLファイルの署名の有効性確認 4/19 また、図2に示すように、このDLLファイルは、Windows 10で利用される「pkeyhelper.dll」 のファイルメタ情報やPDBファイル情報を持つことが確認できます。 図2 「wiaky002_CNC1755D.dll」のファイルメタ情報およびPDBファイル情報（一部抜粋） デジタル署名されたファイルの改ざん手法 SigLoaderは、前述の通りMicrosoft社のデジタル署名されたDLLファイルを読み込み、攻撃 に悪用します。一般的にデジタル署名が有効である場合は、署名した組織が実在することや データが改ざんされていないことなどが証明されており、万一、デジタル署名のあるファイ ルを改ざんした場合、デジタル署名が無効であると検出されます。 しかし、SigLoaderを利用する攻撃者は、デジタル署名されたDLLファイル内に存在する証 明書テーブル（Certificate Table）のサイズを拡張し、そのテーブル内のデータを変更する ことで、デジタル署名に影響を及ぼさずに、DLLファイルを改ざんしています。 Windowsでは、デジタル署名のハッシュ計算にあたって証明書テーブルを対象範囲外として いるため、証明書テーブルを改ざんしたとしてもハッシュ値が一致し、デジタル署名が有効 であると表示されます。この手法は、2009年にHugo氏のブログで報告 されており、その 後、2016年にはBlack Hat USAでも発表 されています。 ※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ファイルに ※3 ※4 https://blog.barthe.ph/2009/02/22/change-signed-executable/ https://www.blackhat.com/docs/us-16/materials/us-16-Nipravsky-Certificate-Bypass-Hiding-And-Executing-Malware-From-A-Digitally-Signed-Executable-wp.pdf 5/19 は存在しない、赤線枠の領域にデータが含まれていることが確認できます。 図3 「pkeyhelper.dll」の比較（上：正規DLLファイル／下：改ざんされたDLLファイル） SigLoaderを使用した攻撃手口の概要 6/19 SigLoaderは、DLL Side-Loadingを悪用して実行されます。正規の実行ファイルによって読 み込まれたSigLoaderは、最初に実行ファイルと同じディレクトリ内にあるMicrosoft社のデ ジタル署名がされたDLLファイル、または暗号化されたペイロード（DATファイル）を読み 込みデータを復号します。その後、復号したペイロードをメモリ領域に展開し実行します。 最終的に実行されるペイロードは、2020年11月20日時点で3種類が確認できています。 図4は、SigLoaderの挙動を示したものであり、SigLoaderを2段階で使用するケース（青矢 印）と1段階のみのケース（赤矢印）の2パターン存在することを確認しています。 図4 SigLoaderの動作概要図（一例） 以降では、VMware製品の正規実行ファイル（ResolutionSet.exe）を悪用して、実行される SigLoader（vmtools.dll）の攻撃手口を詳しくみていきます。 SigLoaderが読み込むファイル SigLoaderには図5に示すように、Sigという文字列を起点に読み込むファイルや暗号化方法 などがファイル内にハードコード されており、このハードコードされた内容を利用してペ イロードが展開されていきます。 ※5 別のSigLoaderでは、Sigという文字列や暗号化方法などが未記載のものも確認していま す。このようなSigLoaderでは、暗号化方法が記載された箇所に暗号化キーなどが含まれて います。 ※5 7/19 図 5 SigLoaderにハードコードされたファイル名や暗号化方法（一例） まずSigLoaderはMicrosoft社のデジタル署名されたDLLファイル 「wiaky002_CNC1755D.dll」を読み込み、ファイル内のオーバーレイ領域に含まれるデータ を取得します。今回のケースでは、先ほど紹介した図3の赤線枠に示すオフセット0xBA488 からデータ末尾（0xF4090）までを読み込み、そのコードをメモリ領域上に展開します。こ のオフセット値0xBA488は、データ末尾から図6に示すように、0x39C08（0x39C05から値 を1増やし8の倍数で割り切れる値）バイト遡った値から算出されています。 図6 読み込むデータの オフセットの計算式（一部抜粋） SigLoaderが利用する暗号化方法 読み込まれたオーバーレイ領域に含まれるデータは、XOR＋カスタムDES＋AESによって 暗号化されています。暗号化キーは図7に示すように、SigLoader自体にハードコードされて おり、AESキーと初期化ベクトル（赤線枠）、カスタムDESで利用するキー（橙線枠）で 8/19 す。また、このSigLoaderには、2段目で利用されるSigLoader（2nd）のAESキーや初期化 ベクトル（青線枠）、カスタムDESで利用するキー（緑線枠）もハードコードされていま す。 図7 SigLoaderにハードコードされている暗号化キー（一部抜粋） SigLoaderはこれらの暗号化キーを使用して、オーバーレイ領域に読み込まれた暗号化デー タを図8の順で復号 し、シェルコードをメモリ領域に展開します。復号は、AESでは鍵長 256ビット、ブロックチェイニングとしてCBCモードを使用し、カスタムDESでは、鍵長64 ビット、ECBモードを使用します。復号後は、Call命令でシェルコードが展開されたメモリ 領域を呼び出します。 ※6 別のSigLoaderでは暗号化アルゴリズムの適用順序や適用回数が異なる可能性がありま す。 ※6 9/19 図8 SigLoaderによるデータ復号（一例） SigLoaderには、XOR、カスタムDES、AESの3種類の暗号化アルゴリズムが実装されてい ます。これらのうち、SigLoaderで実装されているカスタムDESは、使用される定数に異常 はないものの、サブ鍵生成アルゴリズムやラウンド関数などが標準のものと異なっており、 標準の暗号化ライブラリでは暗号化されたデータを復号することができません。 また、これらのデータをエンコードするための処理が多数みられ、サブ鍵生成アルゴリズム やラウンド関数などは、攻撃者が自ら実装している可能性があります。また、コード内に RSAの実装を見据えた箇所があることから、今後RSAの処理に関しても実装される可能性が あります。 シェルコードによる2段目のSigloader（2nd）作成 復号されたシェルコードは、SigLoader（2nd）を作成するために用いられます。図9は、シ ェルコードを一部デコンパイルしたものです。特徴的な文字列ecipekac（Cakepice）をチェ ックするコードが含まれていることが確認できます。 10/19 図9 シェルコード内の「ecipekac」を確認するコード（一部抜粋） このシェルコードには、自身のコード内に以下の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/19 図10 Section Headersおよびプログラムコード（一部抜粋） 図11 MS-DOS Header/StubおよびPE Header 12/19 これらのデータの組み換えに際して、最初に図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に示 した青線枠と緑線枠のものが利用されています。 図12 SigLoader（2nd）にハードコードされたファイル名や暗号化方法（一例） 13/19 図13 「wintrust.dll」のファイルメタ情報およびPDBファイル情報（一部抜粋） シェルコードによる最後のペイロード作成 SigLoader（2nd）によって復号されたシェルコードは、最後のペイロードを作成するため に用いられます。最後のペイロード（図14：青線枠）は、シェルコード内にRC4で暗号化さ れて含まれており、図14の赤線枠で示すRC4キーで復号することで最終的なペイロードをメ モリ領域に展開します。復号後は、Call命令でペイロードが展開されたメモリ領域を呼び出 します。 図14 RC4キーおよび暗号化されたペイロード（一例） 最終的に実行されるペイロード（DelfsCake） 最終的に実行されるペイロード（DelfsCake）は、DLL形式で、C2サーバからデータやペイ ロードなどを受信して実行する機能を有します。 DelfsCakeには、図15に示すようにRSA公開鍵（1024bit）がハードコードされており、この 鍵を使用して送信するデータを暗号化します。初期通信時に送信する内容は、図16の通りで す。ユーザ名やコンピュータ名、プロセスID、OSバージョン、ビルド番号、ソケット名、 実行日時、ランダムに生成した文字列などがC2サーバに送られます。 14/19 図15 DelfsCakeにハードコードされたRSA公開鍵（一例） 図16 送信されるデータの例（暗号化前） DelfsCakeには、表1に示すコマンドが実装されています。なお、コマンド「d」に関して は、コマンドの受信時のデータを使用してライブラリのロードと関数アドレスの取得を行 い、その関数をCall命令で呼び出します。Call命令の際に引数として受信したデータを指定 することから、単純なコマンド実行を行う命令ではないと考えます。 表1 DelfsCakeのコマンド一覧 命令コマンド 説明 d 詳細不明 f C2通信の終了 l Sleep間隔の設定 s シェルコードの実行 また、このDelfsCakeを実際に動作させてみましたが、2020年10月30日に確認した時点で は、図17に示すように、C2サーバに接続後、RSTパケットが戻ってきており、C2サーバか らデータは取得できていないため、最終的にどのようなマルウェアが実行されるか不明で す。 15/19 図17 DLLファイルのC2サーバとの通信例 SigLoaderによって展開される最終的なペイロードは、DelfsCakeの他にも2種類確認してい ます。1つは、ペネトレーションツールであるMetasploit Framework やCobalt Strike で 作成されたシェルコードです（図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 図18 ペネトレーションツールを利用して作成されたシェルコード（一部抜粋） もう1つも、次のステージのマルウェアをダウンロードし、実行することが主な機能と考え られるマルウェア（GreetCake）です。図19に示すようにRC4キーがハードコードされてお り、この鍵を使用して送信するデータを暗号化します。また、表2のような、いくつかのコ マンド機能が実装されています。 ※7 ※8 https://www.metasploit.com/ https://www.cobaltstrike.com/ 16/19 GreetCakeは、C2サーバから特定の命令コマンドを受信することによって、C2サーバから データをダウンロードし、復号後、PEファイルを実行します。図20に示すように、実行す る前にPEファイル内に「hello」という文字列が含まれているか確認するというコードが特 徴的です。 表2 GreetCakeのコマンド一覧 命令コマンド 説明 0x12C C2通信の終了 0x12D スレッドを作成し、PEファイルの実行 0x12F データ送信（詳細不明） 0x130 PEファイルの実行 0x131 - 0x134 C2通信制御の設定（スリープ時間、タイムアウトなど） 図19 GreetCakeにハードコードされたRC4キー（一例） 17/19 図20 文字列「hello」を検索するコード（一部抜粋） これら2種類のペイロードについても、DelfsCakeと同様にC2サーバからダウンロードされ るデータは取得できていないため、最終的にどのようなマルウェアが実行されるかは不明で す。 まとめ 今回は、Microsoft社のデジタル署名されたDLLファイルを悪用するSigLoaderについて紹介 しました。 SigLoaderは、デジタル署名されたDLLファイルの悪用、ペイロードの多段利用や攻撃者が 独自に開発した暗号化方法の利用と高度な技術が組み込まれたローダです。暗号化方法で は、RSAのコードが未実装であり、開発途中の可能性が窺えるため、今後も、さらに機能が 向上したSigLoaderによる攻撃が続く可能性があります。 18/19 加えて、今回のデジタル署名されたファイルの改ざん手法を悪用した攻撃は、実際のサイバ ー攻撃の事例としてあまり報告されておらず、既存のセキュリティー対策製品で検出できな い可能性があり、注意が必要です。 私たちがSigLoaderの攻撃を確認した事例の1つでは、攻撃者は標的組織への侵入経路とし て、SSL-VPN製品の脆弱性を悪用後、端末を侵害しSigLoaderを設置していました。SSL- VPN製品を悪用する攻撃は、標的型攻撃に限らず、金銭目的である攻撃者なども悪用してお り、これらの製品の脆弱性を悪用されないためにも、日々の脆弱性情報の管理と修正パッチ の適用や緩和策の適用などの早急な対応が求められます。 また、2020年10月ごろからZerologonの脆弱性 が標的型攻撃で悪用されていることが、 CISA やSymantec社 から報告されていますので、この脆弱性についても十分に注意す る必要があります。 ※9 CVE-2020-1472 - セキュリティ更新プログラム ガイド - Microsoft - Netlogon の特権の 昇格の脆弱性 ※10 APT Actors Chaining Vulnerabilities Against SLTT, Critical Infrastructure, and Elections Organizations | CISA ※11 Japan-Linked Organizations Targeted in Long-Running and Sophisticated Attack Campaign | Symantec Blogs ラックの脅威分析チームでは、今後もこのSigLoaderを利用する攻撃者について、継続的に 調査し、広く情報を提供していきますので、ご活用いただければ幸いです。 IOC（Indicator Of Compromised） 2021年1月13日 更新 SigLoaderハッシュ値（MD5） bb45da230ee45e25df27a518dac0560a cca46fc64425364774e5d5db782ddf54 42b6ab4bfa271019990960276e5c8176 6c68753503b79998ee29f52ce0f08e72 2e917dfcd0cf13e8c2a1bf4298d30794 ペイロード（MD5） f5061a2b19a6cbe7a93c5c2b8d6fb20e 4638220ec2c6bc1406b5725c2d35edc3 03413d12861a9cd61352e364139ff212 d37964a9f7f56aad9433676a6df9bd19 ※9 ※10 ※11 https://msrc.microsoft.com/update-guide/ja-jp/vulnerability/CVE-2020-1472 https://www.cisa.gov/uscert/ncas/alerts/aa20-283a https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/cicada-apt10-japan-espionage 19/19 DelfsCake（MD5） fd722cfafc12774cebfb2edd3d2a5eff GreetCake（MD5） 78e1f309154fca4341a251bb9cb1e790 da2bd4a55a6291bdb3e8a81a60091611 通信先 85.204.74[.]113 88.198.101[.]58 81.7.7[.]159 この記事は役に立ちましたか？ はい いいえ