----- A deep-dive analysis of LockBit2.0 Ransomware 2021 年10 月22 日 # はじめに 2021 年10 月22 日現在、すでに多くのニュースや公開記事で言及されているように､｢LockBit2.0｣はリー クサイトを持つ暴露型ランサムウェア攻撃グループの中で現在(2021 年後半)最も活発である攻撃グループで す｡LockBit2.0 のリークサイト上では､いきなり窃取データが暴露されるのではなく､｢被害組織名｣とともに ｢暴露までの残り時間｣をリアルタイムでカウントし被害組織に圧力をかけます｡そのため､リークサイトに初め て掲載された時点においては被害組織と攻撃者間で金銭の支払いに関する交渉が行われているかもしくは交渉 前の段階にあるケースが多いものと考えられます｡ LockBit2.0 の開発者は自身のサイト上で､LockBit2.0 のランサムウェアが世界で最も暗号化速度が速く他の ランサムウェアよりも優れていると､攻撃の実働部隊であるアフィリエイトに向け詳細にアピールしており､加 えて他のランサムウェアには無い新しい技術も搭載しているという趣旨のコメントを掲載しています｡(それを 補足する関連情報として､海外で行われたLockBit2.0 の代表者へのインタビューでは｢攻撃が速く実行される ほど､攻撃が撃墜されるリスクは少なくなる｣と答えています｡) 今回我々はこうした点を踏まえ、当該攻撃グループが使用するランサムウェア「LockBit2.0」本体に着目し詳 細解析を実施、本記事でその全ての解析結果を共有します。 なお、LockBit2.0 ランサムウェアに関する解析記事については海外ベンダーなどからすでに幾らか公開され ていますが、それらの記事において言及されていない事実や、解析が及んでいない挙動などが多くあることを 確認しました。 本記事では、そうした他の解析記事では触れられていない詳細情報や、全世界初となる情報なども多数盛り込 み、“世界で最も詳細なLockBit2.0 ランサムウェアの解析記事”(※)となるよう意識しました。 （※本記事執筆時点(2021 年10 月)かつ公開されている範囲において） また、海外のみでなく日本国内においても多くの被害が出ていると想定される状況下において、LockBit2.0 ラ ンサムウェアに関する日本語オリジナルによる詳細解析記事自体が依然ほとんど存在しない状況であるため、 今回公開した本記事が幾らか国内を中心とした皆様の、お役に立てば幸いです。 ----- A deep-dive analysis of LockBit2.0 Ransomware ## 目次 - 要 .......................................................................................................................................... 4 - 層解析 ................................................................................................................................... 5 - 解析機能（解析を妨害する機能） ............................................................................................ 6 - 染環境の言語チェック .......................................................................................................... 13 - AC Bypass による権限昇格 .................................................................................................. 15 - 重起動を防ぐミューテックス（Mutex）の作成 ........................................................................ 28 - 意のシャットダウンに備えた暗号化の再開手口 ..................................................................... 28 - ャットダウン時に最後まで居残る手口 ................................................................................... 29 - ロセスの強制終了とサービスの停止 .................................................................................... 30 - ミ箱を空にする ................................................................................................................... 34 - しパーティションのスキャンと強制ドライブマッピング .......................................................... 35 - ァイル暗号化処理の高速化 ................................................................................................... 36 - I/O 完了ポート」の採用による処理の高速化 .......................................................................... 37 - AES-NI」の活用による暗号化処理の高速化 ........................................................................... 40 - ァイルの先頭部分のみの暗号化による高速化 ....................................................................... 41 - ockBit2.0 のファイル暗号化ロジックの詳細 ........................................................................... 43 - き込みが禁止されているファイルの属性変更 ....................................................................... 53 - ァイルの暗号化から除外する対象 ......................................................................................... 55 - ockBit2.0 に暗号化されたファイルのアイコン ........................................................................ 55 - ockBit2.0 のバグ（暗号化が途中で失敗するミス） .................................................................. 58 - ockBit2.0 のバグ（多重暗号化を発生させるミス） .................................................................. 58 - ockBit2.0 のバグ（「.lock」ファイルのチェックミス） ................................................................. 62 - メインコントローラでの動作 ................................................................................................. 66 ----- A deep-dive analysis of LockBit2.0 Ransomware - ockBit2.0 のバグ（作成されたタスクのミス） .......................................................................... 85 - スクトップ壁紙の変更 .......................................................................................................... 88 - 迫文が記述されたテキストファイルの作成 ........................................................................... 94 - TA ファイルによる脅迫文の表示 .......................................................................................... 95 - リンタを利用した脅迫文の物理的な印刷（約一万枚） ............................................................ 99 - ンシデント対応や復旧作業を妨害する処理 ......................................................................... 107 - ォレンジックを意識した自身の抹消処理 ............................................................................. 107 - &D（drag and drop）に対応 ................................................................................................. 110 - ockBit2.0 が隠し持つ GUI(隠しウインドウ)の発見 .............................................................. 112 ※以降の文中において「LockBit2.0」と記載した場合、攻撃グループ名ではなくランサムウェアを指します。 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■概要 はじめにLockBit2.0 の特徴をまとめると、以下のような項目があげられます。 ・ I/O 完了ポートの採用による暗号化処理の高速化 ・ ファイルの一部のみを暗号化することによる暗号化処理の高速化 ・ AES-NI が利用可能なCPU 認識＆活用による暗号速度の高速化 ・ 楕円曲線暗号（ECC）方式を採用したことによる暗号速度の高速化 ・ プリンタを利用した物理的な脅迫文の印刷（プリンタ一台当たり約1 万枚） ・ デスクトップ壁紙を利用したインサイダー（内部者）募集 ・ グループポリシーによるドメイン配下の全端末への自動展開 ・ 全ローカルドライブのネットワーク共有化 ・ 効果的な解析妨害（難読化、デバッガ検知、スレッドのステルス化など） ・ あまり詳細が知られていないUAC Bypass による権限昇格 ・ 入念なフォレンジック対策（単純な削除ではなく自身をハードディスクから抹消） ・ 入念な感染継続性（暗号化中に端末がシャットダウンされることに備えた再開処理） ・ 隠しパーティションのスキャンと強制ドライブマッピング など LockBit2.0 が自身のサイト上で自負しているランサムウェアの高速性については、詳細解析の結果、実際に ファイルの暗号化を高速化させる複数の高度なテクニックが実装されていることを確認しました。 また、様々な手口のアイデアが機能として盛り込まれており、特に、ドメインコントローラ感染時に特別に発 生させる「グループポリシーによる自身の拡散」という仕組みは、暴露系ランサムウェアとしては史上初の新 機能であり、従来のアフィリエイト（攻撃の実働部隊）が手動で行っていた作業を置き換えることで、攻撃能 力に個人差があるアフィリエイトの手動作業をできるだけ自動化し攻撃の質を平準化させる試みが感じられま す。 また今回の解析で、LockBit2.0 が世界的に知られていないグラフィカルなインターフェイス（GUI）である 「隠しウインドウ」を実装していることや、LockBit2.0 が複数の致命的なバグを抱えており、検体や被害環 境によっては多重暗号化が発生することで、たとえ復号ツールが入手できたとしても復号が困難となるシチュ エーションが存在することなど、多くの新事実も発見しました。 これらを含む、LockBit2.0 詳細解析の全貌は以下の解説をご覧ください。 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■表層解析 LockBit2.0 はVisual Studio 2017 で作成され、構造上はGUI アプリケーションとしてビルドされていま す。ただし実際には実行されても画面上には何も表示されずサイレントに感染が行われます。 また、単純な表層解析の範囲では一般的なGUI コンポーネントなどのリソースデータはEXE ファイルから確 認することはできません。 図 1 LockBit2.0 の開発情報 セクションとしては以下の2 つの構造を持ち、一般的なGUI アプリケーションにみられるリソースセクショ ンなども存在しません。 図 2 LockBit2.0 のセクション情報 ----- A deep-dive analysis of LockBit2.0 Ransomware アドレス空間配置のランダム化であるASLR は無効化された状態でビルドされています。 図 3 LockBit2.0 のEXE 設定情報 その他、デジタル署名やプロパティ情報などは基本的に付与されていません。 ## ■耐解析機能（解析を妨害する機能） LockBit2.0 は解析を困難とするためにいくつかの耐解析機能（解析妨害テクニック）を実装しています。 LockBit2.0 は起動すると、すぐに自身がデバッグされていないかどうかをチェックし、デバッグ中であると 判断すると無限ループし動的解析を妨害します。 具体的には、プロセス内に存在する様々な情報が格納されたPEB（Process Environment Block）という 構造体の中の「NtGlobalFlag」という項目をチェックします。プロセスがデバッグ中の場合はこのNtGlobal Flag が0x70 という値になるため、LockBit2.0 はNtGlobalFlag の値を取得し、「0x70」と比較すること でデバッグ中であるかを判断します（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 4 NtGlobalFlag による解析妨害 また、LockBit2.0 は動作中、複数のスレッド（マルチスレッド）により処理を行っていきますが、その際にデ バッガからスレッドを解析できないよう、スレッドをステルス化することで解析を妨害します。 このテクニックは新しいものではありませんが、非常に効果的な解析妨害方法であり、このアンチデバッグテ クニックはBlackMatter 等の高度なランサムウェアでも確認されています。 具体的には、NtSetInformationThread 関数を使用し、指定したスレッドに ThreadHideFromDebugger （0x11 という値）という特殊なフラグを設定する文書化されていない呼び出し方法により実現します。この 値が設定されると、デバッガは該当フラグが設定されたスレッドからの情報を取得できなくなるため該当ス レッド上のコードの解析ができなくなり、実質的にデバッガからスレッドを隠すのと同じ効果を得られます（該 当スレッドを解析しようとしてもデバッガが素通りしてしまう上、無理やり解析を進めようとするとクラッ シュします）（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 5 ThreadHideFromDebugger による解析妨害 またLockBit2.0 は、Windows API を名前ではなくハッシュ値で求める手法を採用し、Windows API を隠 蔽することで静的解析を妨害するテクニックも実装しています（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 6 WindowsAPI のハッシュ比較による解析妨害 例えば、「Kernel32.dll」のアドレスは、以下のようにPEB のInLoadOrderModuleList から辿りハッシュ 値をチェックすることにより導き出します（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 7 Kernel32.dll のアドレスの割り出し処理 例えば、「gdiplus.dll」というDLL を「LoadLibraryA」でロードする際の一連の処理は、以下のような流れ になります（下図参照）。LoadLibraryA のアドレスがハッシュ値で導き出された後、難読化されていた「gd iplus.dll」という文字列が復号され、引数に渡されます。 つまり、API はアドレスをハッシュ値で参照し、API で使用する文字列などは毎回復号して使用します。 その他、動作中に使用する全ての文字列についても同様に難読化されており、都度復号して使用します。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 8 gdiplus.dll をLoadLibraryA でロードする際の処理例 文字列の復号は一つの関数で行われるわけではなく、文字列ごとにそれぞれ異なる復号方法を使用しています。 以下の図は例として「Advapi32.dll」というDLL 名の復号と、「user32.dll」というDLL 名の復号処理の一 部を抜粋したものです（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 9 それぞれの文字列の復号は複数の異なる復号方法を使用する ----- A deep-dive analysis of LockBit2.0 Ransomware 以上のような複数の対策により、動的解析・静的解析の両面の観点からの解析を妨害します。決して数多くの 耐解析機能が実装されているわけではありませんが、少ない中でより効果的な耐解析テクニックを組み合わせ て利用しているといえます。 ## ■感染環境の言語チェック LockBit2.0 は感染端末の言語設定を取得し、CIS（独立国家共同体）を含むロシアを中心とした旧ソ連諸国の 言語が設定されていないかどうかをチェックし、設定されている場合は感染せずに終了します（下図参照）。 この点については、開発者も自身のサイト上で”LockBit2.0 はポスト・ソビエト国家には感染しない”と明言 しています。 言語チェックは、GetSystemDefaultUILanguage 関数とGetUserDefaultLangID 関数が用いられます。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 10 特定の言語環境かどうかをチェックする処理とチェックする言語の一覧 なお一般的にあまり知られていませんが、こうした言語チェックを行わないLockBit2.0 の個体も一部存在す ることを今回の調査の中で確認しています。つまり、検体によっては言語チェックの機能自体が実装されてい ないケースがあり、ロシア語などの言語が設定された端末であっても以下の図のように感染してしまいます（下 図参照）。 これは攻撃の実働部隊であるアフィリエイトがランサムウェアを攻撃対象組織に合わせチューニングしたうえ で簡単にEXE を生成できるような仕組みを提供するRaaS(Ransomware as a Service)において、ランサ ムウェアに持たせる各機能の有効化/無効化をビルド時の設定で選択できる仕組みが背景にあるものと考えら れ、そうした中で言語チェックを有効にしない状態でビルドされた検体が一部存在するものと推測しています。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 11 ロシア語端末でLockBit2.0 が感染した様子 ## ■UAC Bypass による権限昇格 LockBit2.0 は、自身が管理者権限を持っていない状態で起動した場合、UAC(ユーザーアカウント制御)の昇 格プロンプトを回避し管理者権限に昇格するテクニックである「UAC Bypass」を行います。 コード上では、以下のように管理者権限で実行された場合と、ユーザ権限で実行された場合で異なる遷移を取 る分岐点があります（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 12 UAC Bypass に関わる処理の分岐箇所と終了処理の構造 なお、この分岐点を解析作業時に容易に見つけ出すためには、実行時に通過したコード領域の差分分析を行う カバレッジログ分析が有効です。 以下のように「管理者権限で動作したコード領域」と「ユーザ権限で動作したコード領域」の差分を取り、「ユー ザ権限でのみ動作したコード領域」を抽出させることで、UAC Bypass のコード箇所が抽出され特定できま す（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 13 カバレッジログを用いたUAC Bypass 処理箇所の抽出と特定 LockBit2.0 は、上記のカバレッジログ分析において明らかとなった「ユーザ権限でのみ動作するコード領域」 において、あまり広く詳細が知られておらず文書化されていない特定のCOM(Component Object Model) インターフェイスを悪用するUAC Bypass テクニックを用います。 以降では、そのUAC Bypass の流れを詳細解説します。 まずLockBit2.0 は自身が管理者権限で実行されているかどうかを確認します。 具体的には以下の方法で行います。 ZwOpenProcessToken 関数にTOKEN＿QUERY(0x8)アクセス権を指定した上でNtQueryInformation Token 関数を呼び出しプロセストークンの構造体(TokenInformation)を取得、その際TokenInformationCl ass の「TokenElevation(0x14=20)」を引数に指定することでTOKEN_ELEVATION 構造体を取得しま す。 その後、取得したTOKEN_ELEVATION 構造体のメンバ変数である「TokenIsElevated」の値が0 かどうか をチェックすることで管理者権限かどうかを判断します（下図参照）。 （自身が管理者権限で実行されていると判断した場合、[Process created with admin rights]という難読 化された文字列をメモリ上に復号したのち、メインの処理を継続します） ----- A deep-dive analysis of LockBit2.0 Ransomware 図 14 管理者権限かどうかを確認するためにプロセストークを取得 自身が管理者権限で起動していないと判断した場合、自身がUAC Bypass を行うことができる環境にあるか を確認する作業を行います。 まず先ほどと同様、ZwOpenProcessToken 関数にTOKEN_QUERY(0x8)アクセス権を指定した上でNtQ ueryInformationToken 関数を呼び出し、プロセストークンの構造体(TokenInformation)を取得します。 続いてCreateWellKnownSid 関数に「WinBuiltinAdministratorsSid」(0x1A=26)という引数を指定する ことで「BUILTIN\Administrators」グループに対応するSID(セキュリティ識別子)を取得(作成)したのち、C ----- A deep-dive analysis of LockBit2.0 Ransomware heckTokenMembership 関数を利用して、呼び出し元のプロセストークン内で「BUILTIN\Administrator s」グループのSID が有効になっているかどうかを確認することで、Administrators グループに属している かどうかをチェックします（属していない場合は本処理を終了します）。 つまりこの時点で、現在のユーザが”管理者権限を持たずAdministrators グループに属しているユーザであ る”と判断できることになります。 なお、Windows ではAdministarators グループに属しているユーザがログオンする際、対となる2 つのトー クン（管理者としてのフルアクセストークンと制限されたユーザのトークン）が発行されます。 この2 つのトークンのうち、現在の対となるトークンをTokenLinkedToken 関数で取得することができま す。 LockBit2.0 は自身のプロセスが管理者権限を持たず、かつ実行したユーザがAdministrators グループに属 していると判断すると、NtQueryInformationToken 関数の引数に「TokenLinkedToken」(0x13=19)を 指定することで、対となるトークン、つまり、フルアクセストークンを取得できるか確認します。 (この処理が失敗した場合、つまり対となるフルアクセストークンが存在しない場合は「Process created w ith limited rights」という文字列を復号しメモリ上に展開し、UAC Bypass の処理を終了します) 図 15 Administrators グループに属しているかどうかをチェック 次に、LockBit2.0 はこれから行うUAC Bypass が利用できるOS バージョンであるかを確かめるため、G etVersion 関数でWindows のメジャーバージョンを取得し、「5」(Windows XP/2000/Server2003/ Server2000)という値と比較、Windows のメジャーバージョンが「5」ではない場合のみ処理を継続します （下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware （もし「5」に該当した場合は「Process created with limited rights」という文字列を復号しメモリ上に 展開し、UAC Bypass の処理を終了します) 図 16 Windows のメジャーバージョンを「5」と比較 以上の処理により、LockBit2.0 は自身がUAC Bypass を行うことができる環境にあると判断し、UAC By pass の主たる処理に遷移します。 今回UAC Bypass にも利用される「COM」(Component Object Model)は、Process Status API（P SAPI）を使用して、プロセスのPEB という構造体のprocessParameters に含まれる実行パスに関する情 報を読み取ることでCOM の呼び出し元プロセスを識別します。 そのため前準備として、LockBit2.0 は自身のプロセスが持っている実行パス情報を、以降で解説する方法に より信頼できるプロセスの一つである「Explorer」の実行パスに強制的に書き換えることで偽装します。 （こうしたプロセスの偽装処理を「マスカレード」と呼びます） そのため、まず以下のようにExplorer.exe のフルパス文字列を生成します（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 17 マスカレード処理で使用するExplorer のパスを生成 続いて、LockBit2.0 はRtlInitUnicodeString 関数を使用し、”C:¥Windows¥Explorer.exe”という文字 列を自身のPEB のprocessParameters 項目にあるImagePathName に、また、“Explorer.exe”という ----- A deep-dive analysis of LockBit2.0 Ransomware 文字列を自身のPEB のprocessParameters 項目にあるCommandLine の項目に上書きします（下図参 照）。 PEB のprocessParameters の各項目はUNICODE_STRING という構造体の形式を取りますが、この際、 LockBit2.0 はPEB の書き換えにRtlInitUnicodeString 関数をそのまま使用することでUNICODE_STRI NG に変換しつつ直接書き換えるという二つの作業を同時に行います。 図 18 LockBit2.0 が行う「マスカレード」（プロセス情報偽装）処理 つまり、これにより以下のようにLockBit2.0 のPEB にあるプロセスパラメータのパス情報がExplorer のパ スに偽装（マスカレード）されます（下図参照）。 またこのマスカレード処理を、自身がロードしている全てのモジュール(DLL)に対しても同様に行います。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 19 マスカレード処理によって改変されExplorer に偽装したLockBit2.0 のプロセス情報 続いてLockBit2.0 は、CoInitializeEx 関数でCOM インターフェイスの使用準備をしたのち、CoGetObjec t 関数で以下2 つの特定のCLSID を指定し、対応するオブジェクト名を作成します（下図参照）。  指定されるCLSID： {3E5FC7F9-9A51-4367-9063-A120244FBEC7}  作成されるオブジェクト名(COM 昇格モニカ)：”Elevation:Administrator!new:{3E5FC7F9-9A51-4 367-9063-A120244FBEC7}”  指定されるCLSID： {D2E7041B-2927-42fb-8E9F-7CE93B6DC937}  作成されるオブジェクト名(COM 昇格モニカ)：”Elevation:Administrator!new:{D2E7041B-2927 42fb-8E9F-7CE93B6DC937}” これらのCLSID はUAC Bypass の観点で脆弱であることが一部で知られている、それぞれCMSTPLUA と IColorDataProxy という自動昇格が有効なCOM インターフェイスに紐づいています。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 20 COM 昇格モニカの作成 上記のオブジェクト名(COM 昇格モニカ)がCoGetObject 関数の引数に渡され呼び出されることで、COM の ホストプロセス（COM サロゲートプロセス）である「Dllhost.exe」（正規プロセス）が以下の引数で起動し ます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 21 COM サロゲートプロセスが起動する様子 その後、LockBit2.0 は（Dllhost.exe を経由し）以下のレジストリ(今回利用するCOM に関連したDisplay Calibrator というレジストリ)を書き換えることで、LockBit2.0 のEXE がUAC Bypass を行える状態にし ます（下図参照）。 図 22 LockBit2.0 がUACbypass のために書き換えるレジストリ場所 以下は、書き換える処理と、書き換え前後のDisplayCalibrator のレジストリ値を比較した様子です（下図参 照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 23 LockBit2.0 により書き換えられる前後のレジストリ値「DisplayCalibrator」 その後上記設定が反映される関連されたCOM 処理を呼び出すことで管理者権限に昇格したdllhost.exe がL ockBit2.0 を起動させます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 24 DllHost.exe がLockBit2.0 を起動する様子 その際管理者権限が継承され、結果的にLockBit2.0 が自動的に権限昇格した状態で新たなプロセスとして起 動することになります（下図参照）。 図 25 UAC Bypass により権限昇格が行われた瞬間の様子 以上が、LockBit2.0 が用いる、あまり広く詳細が知られておらず文書化されていない特定のCOM インター フェイスを悪用したUAC Bypass のテクニックの仕組みです。 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■多重起動を防ぐミューテックス（Mutex）の作成 LockBit2.0 は、アプリケーションが多重起動を防止する際によく使用するミューテックス（Mutex）を作成 することで、自身のプロセスが多重に起動することを防ぎます（下図参照）。 図 26 LockBit2.0 が作成するミューテックス ## ■不意のシャットダウンに備えた暗号化の再開手口 LockBit2.0 は、ユーザがインシデントに気付き端末を急いで強制的にシャットダウンするケースに備え、端 末が再起動された際も暗号化が再開できるよう、レジストリにあるHKCU のRun キーに自身のパスを登録す ることで、自動起動設定を行います。この自動起動のためのレジストリ設定は、暗号化がすべて完了すると削 除されます。つまり、暗号化の途中でシャットダウンされても端末の再起動後に暗号化が再開できるようにし ており、念を入れて執拗にすべてを暗号化しようとする攻撃者の意図が垣間見えます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 27 再起動時に再開できるようにRun キーを一時的に設定 ## ■シャットダウン時に最後まで居残る手口 またLockBit2.0 は、ユーザが端末をシャットダウンしようとした際に最後まで居残ることができるようにし ます。 具体的には、SetProcessShutdownParameters 関数を使用し、自身のプロセスがシャットダウン時に終了 するプロセスの中で最後となるよう、シャットダウン時の終了順序を設定します。 これにより、端末のシャットダウン時に最後までシステムに居残ることで、できるだけ多くのファイルを暗号 化しようとします。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 28 シャットダウンパラメータの変更 ## ■プロセスの強制終了とサービスの停止 LockBit2.0 は動作中、繰り返し実行されるスレッドの中でプロセスの強制終了を定期的に行います。 強制終了の対象プロセス名となる137 個の文字列をメモリ上に復号/展開して用意します（下図参照）。 図 29 強制終了対象プロセスの展開 ----- A deep-dive analysis of LockBit2.0 Ransomware プロセスの強制終了は、ネイティブAPI であるZwTerminateProcess が利用されます。 図 30 プロセスの強制終了処理 以下は、LockBit2.0 が強制終了対象とする137 個のプロセス名一覧となります（下図参照）。 これらには、インシデント調査に使用されるプロセスや、業務アプリケーション、データベース系アプリケー ションなどのプロセスが含まれており、これらのプロセスを強制終了させることでLockBit2.0 の暗号化作業 がスムーズに行われるようにします。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 31 LockBit2.0 が強制終了する対象プロセス名リスト また、サービスの停止も行いますが、その際ControlService 関数にSERVICE_CONTROL_STOP を引数と して渡すことで実施します（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 32 サービスの強制停止処理 LockBit2.0 が停止させるサービス名は以下の79 個であり、データベース系アプリケーション、バックアッ プ系アプリケーション、セキュリティ製品などのサービスが含まれています（下図参照）。 図 33 停止対象となる79 個のサービス名一覧 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■ゴミ箱を空にする LockBit2.0 にはごみ箱を空にする挙動があり、全てのドライブにあるごみ箱をSHEmptyRecycleBin 関数 で空にしていきます（下図参照）。 図 34 全てのごみ箱を空にする処理 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■隠しパーティションのスキャンと強制ドライブマッピング LockBit2.0 は、FindFirstVolumeW およびFindNextVolumeW で、ローカルドライブにマッピングされて いない隠しパーティションを含むコンピュータ上の全てのボリュームをスキャンし、マウントされていない場 合はSetVolumeMountPointW で空きのあるドライブ名を指定しドライブマッピングしていきます。 これにより以下のように通常は論理ドライブとして見えない隠しパーティション領域も強制的に論理ドライブ としてマウントされてしまいます。この結果、隠しパーティションであってもLockBit2.0 の暗号化対象とし て認識されるようになります（下図参照）。 図 35 隠しパーティションの強制ドライブマッピング ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■ファイル暗号化処理の高速化 冒頭で触れた通り、LockBit2.0 の開発者は自身のサイト上で、ほかのランサムウェアと比較しLockBit2.0 が世界で最も高速であると自負しアピールしています（下図参照）。 図 36 最も高速であると自負するLockBit2.0 のサイト上のアピール文 そのため、LockBit2.0 のファイルの暗号化に関わる処理を詳しく調べたところ、実際にファイルの暗号化処 理を高速化するための複数のテクニックが実装されていることを確認しました。 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■「I/O 完了ポート」の採用による処理の高速化 まず一つ目に挙げられるのは、「I/O 完了ポート」（I/O Completion Port, IOCP）の採用によるマルチス レッドの高速化です。 「I/O 完了ポート」とは、マルチスレッドの処理において、ファイルの読み書きなどCPU の範囲外での待機が 発生するような、CPU から見ると時間を要する入出力処理(I/O)でCPU を無駄に待機させず、空き時間でほか の処理に効率的にリソースを割り振り管理するための仕組みで、サーバアプリケーションなどで採用されてい る高速化の仕組みです（下図参照）。 図 37 LockBit2.0 で使用されている「I/O 完了ポート」の概念と仕組み 従来の一般的なマルチスレッドによる並列方法ではスレッドが消費するリソースやスレッドの開始・終了に伴 うコスト（OS にイベントが飛ぶなど）、スレッドの切り替えに伴うコストなどがあり、CPU に対する負担が 大きく、また特に、CPU の世界よりも圧倒的に遅いハードディスクへのアクセスなどの入出力処理(I/O)にお いて、処理を待機している時間CPU を占領させることが非効率であるとも言えます。 ----- A deep-dive analysis of LockBit2.0 Ransomware そこでLockBit2.0 は、そうした観点が考慮された仕組みである「I/O 完了ポート」を採用することで効率化 を図っています。I/O 完了ポートを利用することで、CPU の世界から見て時間の要する入出力処理（I/O）が 完了するまでCPU リソースを他の処理のために一旦開放し、入出力処理（I/O）が完了したタイミングでスレッ ドプール（複数のスレッドを待機させつつ空いたスレッドに適宜処理させる仕組み）に処理依頼(キュー)を渡す という流れでCPU に処理を再開させることができ、CPU の占有を抑えることで効率的にCPU リソースを活 用したマルチスレッドを実現できます。また、同時にアクティブとなるスレッドの数を指定することができる ため、プロセッサ数以上のスレッドを動作させないといった制御が可能です。 このため、多数のI/O を並行発生させることで高速化したい「ランサムウェア」というプログラムにとってI/ O 完了ポートの採用は効果的な選択であると言えるでしょう。 具体的には、ネイティブWindows API であるNtCreateIoCompletion、NtSetInformationFile、ZwRem oveIoCompletion、ZwSetIoCompletion という関数群を呼び出すことで実現しています。 下図は、実際にLockBit2.0 がファイルを暗号化する際に使用するI/O 完了ポートの利用流れを図示したもの です。ファイルを暗号化する際の入出力処理（I/O）において、I/O 完了ポートが一元管理することでCPU の 処理が効率化されます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 38 I/O 完了ポートを利用したLockBit2.0 のファイル暗号化処理の高速化の仕組み つまり、I/O 完了ポートの採用により、実際に暗号化処理の高速化が期待できるといえます。 また、LockBit2.0 はファイルの暗号化処理だけでなくその他の機能においてもマルチスレッドでサブルーチ ン化しておりそれぞれにおいてI/O 完了ポートを活用した高速化を行なっています。 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■「AES-NI」の活用による暗号化処理の高速化 インテルとAMD の一部のCPU には、AES の暗号処理を高速に行う為の「AES-NI」（Advanced Encrypt ion Standard New Instructions）という仕組みが実装されています。AES-NI は、AES の暗号化/復号処 理のために特別に用意された専用の命令セットをハードウェアに実装することで大幅な高速化が行われる機能 です。 LockBit2.0 はファイルの暗号化にAES を使用するため、AES-NI を活用することでファイルの暗号化処理を 高速化しています。 具体的には、LockBit2.0 はまず感染端末のCPU の種類を示す「CPUID」やCPU の製造ベンダーを示す「ベ ンダーID」を確認することで、AES-NI に対応したCPU であるかを確認します。さらにAES-NI をサポート しているCPU であるかどうかをチェックします。 これらのチェックの結果、AES-NI に対応していると判断した場合は、LockBit2.0 はAES-NI 専用に用意さ れた命令セットである「aesenc」命令を使用して暗号化します（下図参照）。 図 39 AES-NI を活用したLockBit2.0 のファイル暗号化処理の高速化 つまりこのAES-NI の利用により、実際に暗号化処理の高速化が期待できるといえます。 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■ファイルの先頭部分のみの暗号化による高速化 LockBit2.0 は、暗号化する対象ファイルの中身全てを暗号化せず、ファイルの先頭部分4KB のみを暗号化す ることでファイルの暗号化を高速化しています。以下の図は、LockBit2.0 に暗号化される前のファイルと暗 号化された後のファイルの先頭部分を比較した様子ですが、先頭4KB のみが暗号化されていることがわかり ます（下図参照）。 図 40 LockBit2.0 に暗号化される前後のファイルの先頭部分の比較 また別の例として1GB のファイルサイズを持つ巨大なファイルを用意し実験した結果が以下ですが、LockBi t2.0 によって暗号化された後のファイルを確認すると、先頭4KB しか暗号化されていません（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 41 LockBit2.0 により暗号化された1GB のファイルの状態 確かに、他のランサムウェアにおいて、多数の大きなサイズのファイルが暗号化されるようなシチュエーショ ンでは、暗号化スピードが大幅に減速することをこれまでしばしば目にしてきました。Conti の解析記事 (詳 しくは [ここをクリック してご覧ください) においても、ファイルの拡張子やサイズによって暗号化処理を分](https://www.mbsd.jp/research/20210413/conti-ransomware/) けていることが分かっており、ランサムウェアにとってこの減速が課題であることは明らかです。LockBit2.0 が採用したこの方法のように、ファイルの先頭4KB のみを暗号化するという割り切りは、暗号化スピードの向 上の観点においては非常に効果的なアイデアであると感じます。 また、4KB とはいえ、プレーンテキストの種類のファイルでない限り、ファイルの先頭4KB を暗号化された 場合は元の状態に復元することは非常に困難であり、結果的にファイル全体を暗号化された場合と同等の影響 を被害組織に与えられる手口であるともいえます。 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■LockBit2.0 のファイル暗号化ロジックの詳細 ここでは、LockBit2.0 が行うファイルの暗号化のロジックを詳細解説します。 LockBit2.0 のファイル暗号化のロジックを次の図にまとめましたので、図に沿って解説します（下図参照）。 まず、LockBit2.0 の攻撃者側は公開鍵暗号方式である「ECC」（楕円曲線暗号）鍵のペア（これを「マスター ECC 公開鍵」と「マスターECC 秘密鍵」と呼びます）を生成し、「マスターECC 秘密鍵」を攻撃者側の手元 で管理しています。 そして、LockBit2.0 のEXE 本体にこの「マスターECC 公開鍵」がハードコードされています。 次に、LockBit2.0 は感染時、感染端末ごとに一意となる別のECC 鍵のペア（これを「セッションECC 公開 鍵」と「セッションECC 秘密鍵」と呼びます）をローカルで生成します（※）。 （※）なおLockBit2.0 はECC（楕円曲線暗号）の楕円曲線に「Curve25519」を使用しています。RSA よ り処理速度の早いECC を採用している点で高速化を狙った意図等が考えられます。 一方で、LockBit2.0 は暗号化対象のファイルを暗号化する際AES 暗号で暗号化しますが、その際に使用され るAES 鍵（暗号鍵＆IV）はファイルごとに動的生成されます。つまり、AES 鍵（暗号鍵＆IV）はファイルご とに異なります。 ではファイルを暗号化する際のロジックを見ていきましょう。 LockBit2.0 はあるファイルを暗号化する際、そのファイルのフッタに、「セッションECC 公開鍵」で暗号化 した「AES 鍵（暗号鍵＆IV）」と、「マスターECC 公開鍵」で暗号化した「セッションECC 秘密鍵」を追記 して書き込みます。 したがって、「マスターECC 秘密鍵」があれば、対となる「マスターECC 公開鍵」で暗号化された「セッショ ンECC 秘密鍵」が抽出でき、さらにその「セッションECC 秘密鍵」があれば、対となる「セッションECC 公開鍵」で暗号化された「AES 鍵（暗号鍵＆IV）」を取り出すことができます。 つまり、ファイルの復号は「マスターECC 秘密鍵」を持った攻撃者のみが行えることを意味します。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 42 LockBit2.0 の暗号化ロジック図 上図にも一部記載していますが、LockBit2.0 はセッション鍵のペア（「セッションECC 公開鍵」と「セッ ションECC 秘密鍵」）を生成した際にレジストリに書き込むことで記録します（下図参照）。 なお、レジストリに記録されるセッションECC 秘密鍵は暗号化された状態で書き込まれ、メモリ上に生成され ていたセッションECC 秘密鍵はすぐに0xFF で上書きされ消去されます。 図 43 レジストリに書き込むセッション鍵のペア ----- A deep-dive analysis of LockBit2.0 Ransomware この背景ですが、LockBit2.0 は起動した際、上記レジストリが存在した場合は前回の暗号化処理が途中であ ると判断し、これらのセッション鍵のペアを読み込むことで続きの暗号化に利用します。つまり、途中で端末 がシャットダウンされるなどで中断された場合においても同じセッション鍵で暗号化が再開できるようにして いると考えられます（下図参照）。 図 44 起動時にセッション鍵を読み込む処理 なお、ファイルを暗号化する際のAES 暗号鍵の作成方法ですが、BcryptGenRandom 関数を使用し32 バイ トのランダムなバイト列を生成します。この時点で鍵長が32 バイト＝256 ビットである可能性が考えられま したが、BcryptGenRandom を使用し生成した32 バイトのランダムなバイト列のうち、最初の16 バイト をIV(初期化ベクトル)として、残りの16 バイトをAES 暗号鍵として使用することが確認され、この時点で1 28 ビットの鍵長であることがわかりました（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 45 AES 暗号鍵の作成方法 さらにファイルの暗号化に使用するAES のアルゴリズムにおいて、10 個のラウンド定数による10 回のラウ ンド処理が確認でき、これも鍵長が128 ビット（128 ビットはラウンド10 回）であることを意味します。 また、前回暗号化した列との排他的論理和の処理が確認されるため、この特徴はCBC モードを意味します（後 述）。暗号化するデータを16 バイトごとに暗号化（異なる暗号化鍵で10 回処理）し、それを256 回繰り返 します。この結果、16*256=4096 バイト暗号化することとなり、前述したとおりファイルの先頭を4KB しか暗号化しないことを意味します。 初期化ベクトル（IV）としての利用部分と上記のラウンド処理が確認できたことから、暗号アルゴリズムは「A ES128 ビット」「CBC モード」であると断定できます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 46 ファイルの暗号化に使用するAES のアルゴリズム なお、上記で「前回暗号化した列との排他的論理和の処理」がAES 暗号におけるCBC モードの特徴であるこ とに触れましたが、CBC モードの具体的な処理の流れは以下のようになります。暗号化するデータの最初の1 6 バイトは、IV(初期化ベクトル)と暗号鍵が使用されますが、2 ブロック目以降の16 バイトは、1 つ目の暗 号化ブロックをIV(初期化ベクトル)の代わりに使用します（下図参照）。 このように前回暗号化した列を入力値とする排他的論理和の処理があれば、CBC モードと判別できる一つの特 徴であるといえます。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 47 AES 暗号／CBC モードの仕組みと特徴 以上の暗号化処理により、LockBit2.0 が暗号化したファイルのフッタ構造は以下の図のようになります。51 2 バイトあるフッタ全体のうち、後方に「セッションECC 公開鍵」で暗号化した「AES 鍵（暗号鍵＆IV）」 と、「マスターECC 公開鍵」で暗号化した「セッションECC 秘密鍵」を追記します（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 48 LockBit2．0 に暗号化されたファイルのフッタの全体構造 上記図にも記載した通り、フッタの末尾にはランサムウェアの「検体」を識別するための8 バイトのマーカー が記載されます。この8 バイトの値はLockBit2.0 の本体（EXE ファイル）のバイナリ部分にハードコード されており、検体に依存する値であるため、検体識別用に使用可能なデータであるといえます。使用した検体 が特定できれば、攻撃者側で使用されているマスター鍵の識別が可能であると想定されます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 49 フッタの末尾に含まれる「検体」識別用マーカー そしてもう一つ、フッタの末尾には「端末」を識別するための8 バイトのマーカーが記載されます。この8 バ イトの値は、LockBit2.0 が作成したレジストリの「Public」に格納されたセッションECC 公開鍵の先頭8 バイトとなっており、セッションECC 公開鍵はLockBit2.0 が最初に実行された際に生成されるものである ため、攻撃者側で端末を識別する際の目安として使用できるデータであるといえます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 50 フッタの末尾に含まれる「端末」識別用マーカー なお、上記レジストリキーの命名規則は、LockBit2.0 の実行ファイルにハードコードされたバイナリ値から 特定の場所をピンポイントで抽出したものが使用されています（下図参照）。 図 51 レジストリキーの命名規則 ----- A deep-dive analysis of LockBit2.0 Ransomware LockBit2.0 はこうしたファイルの暗号化を、GetDriveTypeW 関数で書き込み可能と判別した全てのドライ ブ配下のファイルに対して実施していきます（下図参照）。 図 52 書き込み可能な全ドライブのチェック なお、LockBit2.0 はネットワーク共有に設定されたリソース先もアクセスし暗号化する能力を持っています。 WNetOpenEnumW 関数およびWNetEnumResourceW 関数を使用して感染端末からアクセス可能な全て のネットワーク共有を列挙し、発見されたネットワーク共有ごとに新しいスレッドを作成しリソース先に存在 する全てのファイルに対し暗号化を行っていきます（下図参照）。また、WNetAddConnection2W 関数を利 用したネットワーク共有へのアクセスについても試みます。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 53 ネットワークリソースの暗号化処理 ## ■書き込みが禁止されているファイルの属性変更 LockBit2.0 はできるだけ多くのファイルを暗号化するために、「読み取り専用」属性がついているファイル （つまり書き込みが禁止されているファイル）を発見した場合、該当の属性を削除します。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 54 読み取り専用属性が削除される様子 具体的には、個々のファイルを暗号化する際GetFileAttributes 関数でファイルの属性をチェックし「読み取 り専用」属性が設定されているファイルであると判断すると、SetFileAttributes 関数に「0x80=FILE_ATT RIBUTE_NORMAL」の引数を渡し、属性が設定されていない状態に変更します。 これによりたとえ「読み取り専用」属性が付与され書き込みが禁止されているファイルであっても、書き込み 可能な状態にしたうえで暗号化を行うことが可能となっています。 図 55 SetFileAttributes 関数による属性変更の処理 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■ファイルの暗号化から除外する対象 ファイルを暗号化する際、以下に挙げる「ファイル名」「フォルダ名」「拡張子」を暗号化対象から除外しま す。これらにはシステムが動作するために最低限必要なファイルやフォルダ、および攻撃者とコミュニケーショ ンするためのブラウザなどが含まれています（下図参照）。 図 56 LockBit2.0 がファイルの暗号化から除外する対象 ## ■LockBit2.0 に暗号化されたファイルのアイコン LockBit2.0 は、以下のレジストリを改変することで「.lockbit」という拡張子（暗号化したファイルにつける 拡張子）を持つファイルのデフォルトアイコンを、自身が作成したLockBit2.0 のデザインのアイコンに設定 します。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 57 アイコンファイルの作成と設定 そして、設定したアイコンをすぐにシステムに適用させるため、SHChangeNotify 関数を呼び、システムのア イコン描画をリフレッシュさせます。 図 58 登録したアイコンのシステムへの即時反映の処理 ----- A deep-dive analysis of LockBit2.0 Ransomware その結果、LockBit2.0 に暗号化されたファイルは全てアイコンが以下のように変化します。 図 59 LockBit2.0 に暗号化されアイコンが変化したファイルの一覧 ただし、一部の検体において、アイコンが変化しないケースが存在することが複数の検体を解析することで明 らかとなりました。そのため、LockBit2.0 の検体によっては、感染したアイコンが変化しない場合も存在し ます。 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■LockBit2.0 のバグ（暗号化が途中で失敗するミス） LockBit2.0 には、環境によってファイルの暗号化処理が途中で失敗してしまうバグを持つ検体が存在するこ とが今回の調査の結果新たに判明しました。これは本検証時において最新のWindows Update を適用した後 のWindows 10 で確認されており、LockBit2.0 がシステムに関わる特定の特殊フォルダへのアクセス権が ないことで、該当のシステムフォルダへアクセスした時点でファイルの暗号化スレッドがクラッシュし無限 ループに陥るか、LockBit2.0 のプロセス自体がクラッシュして終了します。 このシチュエーションに該当する環境では、ファイルが途中まで暗号化されているものの、LockBit2.0 の後 半の挙動で行う処理である「デスクトップの壁紙変更」、「デスクトップ上の脅迫文(HTA)の作成」などが発生 しません。 そのため、実際の被害組織の中にはデスクトップ壁紙がLockBit2.0 を示すわかりやすい画像に変更されず、 また脅迫文も目が届くデスクトップなどに作成されないことから、LockBit2.0 という種類のランサムウェア に感染したこと自体を把握できていないケースがあるものと推測されます。 この場合、C ドライブ直下のアルファベット順で比較的前方にあるフォルダ内を確認し、ファイルの拡張子が 「.lockbit」のものが存在するかどうかで、LockBit2.0 に感染し一部のファイルが暗号化されたかどうかを判 別することが可能です。 ## ■LockBit2.0 のバグ（多重暗号化を発生させるミス） LockBit2.0 には、シチュエーションによってファイルを多重に暗号化してしまうバグを持つ検体が一部存在 します。 LockBit2.0 は、暗号化済みのファイルかどうかをチェックする際、ファイル内部のフッタなどは確認せず単 純に「.lockbit」という拡張子の有無でのみ判別しますが、ネットワーク共有フォルダなどネットワーク経由で 暗号化を行う場合に限り、暗号化したファイルの拡張子を「.lockbit」に変更しないというバグを抱える検体が 存在します。 そのため、感染端末が存在するローカルネットワーク上には、拡張子が「.lockbit」でないにも関わらず暗号化 されたファイルが存在する可能性があり、状況によっては多重に暗号化される可能性があります（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 60 ネットワーク越しで暗号化されたファイルの拡張子は変化しない 多重に暗号化されることを確かめるため、実際に次の検証を行いました。 以下はネットワーク共有したフォルダを持つ端末α上でLockBit2.0 に感染させた際の検証結果を図示したも のです。端末α上の共有フォルダには「ファイルB」が配置しており、「ファイルB」はすでに他の端末β上 の”バグを持つ検体”により暗号化されている状況となります。上記で述べた通り、バグを持つ検体によりネッ トワーク経由で暗号化された「ファイルB」は、暗号化されているものの拡張子が「.lockbit」ではない状態に なっています。 この状況下で、端末αをLockBit2.0 に感染させたところ、「ファイルB」は想定通り2 重に暗号化されるこ とが確かめられました（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 61 バグを持つ検体の動作 上記の検証結果を踏まえると、例えば以下のように、多数の感染端末からアクセス可能な共有フォルダが存在 する状況下でバグを持つLockBit2.0 に感染した場合、3 重4 重と感染端末の数だけ多重に暗号化されてしま う可能性があるといえます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 62 LockBit2.0 に多重暗号化される可能性とシチュエーション このバグを抱えるLockBit2.0 の個体に感染し、ファイルが多重に暗号化されてしまっていた場合、たとえ攻 撃者から復号ツールを提供され復号しようとしても、実際は復号できないという状況が発生すると想定されま す（復号ツールも拡張子で判別すると考えられるため）。 もちろん理論上、ファイルフッタの構造を都度判別し多重に暗号化されていることを想定して元のファイルに なるまで繰り返し復号するツールを作れないわけではないですが、そこまで煩雑な復号ツールを作るのであれ ば、はじめから多重暗号化が発生しないようにランサムウェア側を実装したほうが現実的といえます。 つまり、ファイルが多重に暗号化されてしまうシチュエーションがあるというこの事実は、LockBit2.0 の攻 撃者が想定しているとは考えられず、ファイルの復元が困難となる致命的なバグの一つであると考えられます。 ただし、比較的新しくビルドされたLockBit2.0 において、このバグが修正されている個体も存在することを その後確認しました。以下の図の通り、バグが修正された個体ではネットワーク経由で暗号化した場合も正常 にファイルの拡張子を「.lockbit」に変更するように修正されているため、多重に暗号化されるという上記問題 が解消されています。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 63 バグが修正された検体の動作 バグを持つ個体とバグが修正された個体はビルド日時が比較的近いため、現時点でLockBit2.0 に攻撃されて いる被害組織の中には、多重暗号化により復元を困難とさせてしまうバグを持つ個体が実際に使用されている ケースも少なくないものと想定され、注意が必要です。 ## ■LockBit2.0 のバグ（「.lock」ファイルのチェックミス） LockBit2.0 は多重暗号化を防ぐため、プロセスの起動中はドライブ直下に「.lock」というファイルを作成し 常に開いた状態にします。「.lock」のファイル名部分の文字列は「セッションECC 鍵」のペアを記録したレ ジストリキー名の最初の4 バイトが使用されます。 LockBit2.0 は起動時に該当の「.lock」ファイルがCreateFile で開けるか（ハンドルがとれるか）をチェッ クし、直前のエラーコードを「0xB7」(ERROR_ALREADY_EXISTS)と比較、該当した場合は自身を終了さ せます。 もしエラーコードが「0xB7」に該当しなかった場合は、処理を継続し「.lock」ファイルのハンドルを動作中 は常に開いたままの状態にします。 ----- A deep-dive analysis of LockBit2.0 Ransomware ローカルにおける多重感染防止は前述のとおりミューテックスで実現されていることから、この「.lock」ファ イルの役割は該当ドライブがネットワーク越しで暗号化される場合を想定した多重暗号化防止の役割を持つこ とが想定されます。つまり、「.lock ファイルのハンドルが開けない」＝「すでに該当の端末（ドライブ）では 他のLockBit2.0 が動作し暗号化している最中である」と判断し、ファイルが多重に暗号化されることを防ぎ たいのだろうと考えられます（下図参照）。 図 64 「.lock」ファイルのハンドルオープン処理 しかし、今回の解析の結果、ここにもバグが存在することが発見されました。 LockBit2.0 は直前のエラーコードを「0xB7」(ERROR_ALREADY_EXISTS)と比較していますが、「.loc k」ファイルのハンドルが開かれた状態で感染させると、実際にはOS から「0x50」(ERROR_FILE_EXIST S)というエラーコードが応答されます。そのため、実検証では「.lock」ファイルのハンドルが開かれた状態で あっても処理は止まらず暗号化は継続されてしまいました。 ----- A deep-dive analysis of LockBit2.0 Ransomware また、一部のLockBit2.0 には前述した通り、ネットワーク越しで暗号化したファイルの拡張子を「.lockbit」 に変更しないというバグも存在します。 つまり、これらのバグが組み合わさることで、他の端末上のLockBit2.0 からネットワーク越しで並行して暗 号化が行われた場合、結果的に排他制御ができず、共有フォルダのみでなく共有化された各端末のドライブに おいても多重の暗号化が発生してしまう可能性があることを意味します。 この結果はコードの実装を見る限り開発者にとって想定外である可能性が高く、「多重暗号化を防ぎたい」と いう本来の意図を推し量るとLockBit2.0 の開発者はこの比較対象のエラーコードを「0xB7」ではなく「0x 50」という値にしたかった可能性があります（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 65 LockBit2.0 のエラーコードの比較処理に含まれるバグ ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■ドメインコントローラでの動作 LockBit2.0 にはドメインコントローラで行う特別な挙動が存在します。以降ではその挙動を解説します。 LockBit2.0 は感染時、GetComputerName 関数を使用してコンピュータ名を取得したのち、NetGetDCN ame 関数によりプライマリドメインコントローラの名前を取得できるか確かめます。もしプライマリドメイン コントローラの名前が取得できた場合、その名前の先頭から”¥¥”（バックスラッシュ）を2 つ削除した文字 列と、先ほど取得したコンピュータ名の文字列を比較することで、感染した端末がドメインコントローラであ るかどうかをチェックします（下図参照）。 図 66 ドメインコントローラの名前を取得し判別する処理 ----- A deep-dive analysis of LockBit2.0 Ransomware ドメインコントローラであると判断した場合、以下の処理を継続します。 LockBit2.0 は自身のプロセスの実行アカウントが「DomainAdmins」(ドメイン管理者グループ)に属してい るかどうかをチェックします。 具体的には次の方法で行います。 ZwOpenProcessToken 関数にTOKEN＿QUERY(0x8)アクセス権を渡すことで現在のプロセスのトーク ンを取得したのちNtQueryInformationToken 関数で現在のSID を取得、取得した現在のSID から、GetW indowsAccountDomainSid 関数を使用してドメインSID を取得します（下図参照）。 図 67 ドメインSID を取得する処理 ----- A deep-dive analysis of LockBit2.0 Ransomware 取得したドメインSID とWellKnownSidType として知られる「WinAccountDomainAdminsSid」（0x2 9=41）という値をCreateWellKnownSid 関数に渡すことでDomainAdmins(ドメイン管理者グループ)の SID を取得(作成)、最後にCheckTokenMembership 関数を利用して、呼び出し元のトークン内でDomain Admins(ドメイン管理者グループ)のSID が有効になっているかどうかをチェックします（下図参照）。 (※もしDomainAdmins に属していないと判断すると「Don’t have admin rights」という文字列をログ 用にメモリ上に作成します) 図 68 DomainAdmins に属しているかどうかのチェック処理 DomainAdmins に属していると判断すると、LockBit2.0 はDomainAdmins のアカウント名（ドメイン管 理者）を取得します。 具体的には次の方法で行います。 先ほどと同じくZwOpenProcessToken 関数にTOKEN＿QUERY(0x8)アクセス権を渡すことで現在のプ ロセスのトークンを再度取得したのち、NtQueryInformationToken 関数で現在のSID を取得、LookupAcc ountSidW 関数を使用し、取得したSID に対するアカウント名（Administrator）とアカウント名が見つかっ たドメイン名（例：ADTEST）を取得します（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 69 DomainAdmins のアカウント名とドメイン名を取得する処理 以上により、ドメインコントローラであることの確認およびドメインコントローラの情報を取得できた後、Lo ckBit2.0 は、グループポリシーを作成し、ドメイン配下の全てのクライアント端末にランサムウェアを配布す る挙動を行います。 このグループポリシーによる自身の拡散という仕組みは、暴露系ランサムウェアとしては史上初の新機能であ ると考えられます。 LockBit2.0 がドメイン内の各端末に配布するグループポリシーは以下に挙げる6 つです（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 70 LockBit2.0 が配布するグループポリシー それぞれについて、以降で詳細解説していきます。 LockBit2.0 は、まずCreateFile でグループポリシー設定ファイルである「GPT.ini」を作成します（下図参 照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 71 LockBit2.0 により作成される「GPT.INI」 続いてCreateGPOLink 関数により、指定したGPO（グループポリシーオブジェクト）とOU(Active Dire ctory でアカウント管理の最小単位となるアカウント・コンピュータ・リソースの集合)をリンクさせグループ ポリシーの適応先を設定（下図参照）、ADSI 関数(Active Directory サービスインターフェイス)であるAD SGetObject 関数を使用した上でグループポリシーの属性(gPCMachineExtensionNames やgPCUserEx tensionNames などの拡張属性)の設定を行います。ADSGetObject 関数はアプリケーションがActive Di ----- A deep-dive analysis of LockBit2.0 Ransomware rectory(AD)にアクセスするための専用API であり、この関数によりAD 内のオブジェクトの検索・閲覧・編 集・削除などが実行できるようになります。 図 72 グループポリシーをOU にリンクさせる処理 その後、ドメイン内のクライアントに配布するための複数のグループポリシーファイルを作成していきます。 まずは、「LockBit2.0 本体をドメイン配下に一斉配布するグループポリシー」を作成します。 あらかじめ、ドメインコントローラにあるSYSVOL フォルダ内scripts フォルダに自身のコピーを作成した 上で、「Files.xml」というグループポリシー設定ファイル(xml)を作成します。 作成された「Files.xml」には、ドメインコントローラのscripts フォルダに作成したLockBit2.0 の本体EX E を、ドメイン配下の各クライアント端末のデスクトップ上にコピーするよう指示するポリシーが記述されて います（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 73 LockBit2.0 の本体をドメイン配下に一斉配布するポリシー 上記のグループポリシーをより分かりやすく表示し直したものが以下です（下図参照）。 つまり、この「File.xml」のグループポリシーが適用された瞬間に、ドメイン配下の全ての端末のデスクトップ にLockBit2.0 のEXE ファイルがコピーされます。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 74 ドメイン配下端末へのLockBit2.0 のEXE ファイルの一斉配布が指定されたポリシー 続いて、「ScheduledTasks.xml」というグループポリシー設定ファイル(xml)を作成します。 この「ScheduledTasks.xml」には、2 つのスケジュールタスクがまとめて記述されています。「Schedule dTasks.xml」の前方に「①プロセスの強制終了」に関するスケジュールタスクが、「ScheduledTasks.xm l」の後方に「②EXE ファイルの実行」に関するスケジュールタスクが設定されています。 ----- A deep-dive analysis of LockBit2.0 Ransomware ----- A deep-dive analysis of LockBit2.0 Ransomware 図 75 LockBit2.0 が作成する「ScheduledTasks.xml」 上記のグループポリシーをより分かりやすく表示し直したものが以下です。 「プロセスの強制終了」に関するスケジュールタスクには、インシデント調査ツールや、データベースアプリ ケーション、サーバアプリケーションなど、暗号化の邪魔となるプロセスの名前が並び、taskkill コマンドによ り即時強制終了されるよう設定されていることがわかります（下図参照）。 図 76 指定した多数のプロセスを強制終了させるスケジュールタスク また、「ScheduledTasks.xml」にある「EXE ファイルの実行」に関するスケジュールタスクには、さきほど の「File.xml」によってあらかじめ作成されたデスクトップ上のEXE ファイル（LockBit2.0 本体のコピー） を即時実行するルールが記述されています（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 77 配布したEXE を実行させるためのスケジュールタスク 以下は、上記のグループポリシーにより、クライアント端末上に実際に配布されたスケジュールタスクの中身 ですが、上記で解説したものと同じものがスケジュールタスクとして設定されていることがわかります（下図 参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 78 実際にクライアント端末側に作成されたスケジュールタスク また、クライアント端末上のタスクスケジューラから確認したものが以下ですが、「プログラムの開始」とし てデスクトップ上のLockBit2.0 の本体のEXE パスが設定されていることがわかります（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 79 タスクスケジューラで確認した様子 続いて、「Services.xml」と「NetworkShares.xml」という2 つのグループポリシー設定ファイル(xml)を 作成します（下図参照）。 図 80 作成されるサービスとネットワーク共有に関するポリシー設定ファイル ----- A deep-dive analysis of LockBit2.0 Ransomware 上記で作成された「Services.xml」には、クライアント端末上の複数のサービス（暗号化の邪魔となるサービ スなど）を停止させる処理が記述されています（下図参照）。 図 81 LockBit2.0 が作成した「Services.xml」 ----- A deep-dive analysis of LockBit2.0 Ransomware もう一つ作成される「NetworkShares.xml」には、クライアント端末上の全てのドライブドライブをネット ワーク共有に設定するためのポリシーが記述されています（下図参照）。この結果、他の感染端末からネット ワーク越しに、それらのネットワーク共有されたドライブ内のファイルが暗号化されてしまう状況に陥ります。 図 82 LockBit2.0 が作成した「NetworkShares.xml」 続いて、「Registry.pol」というグループポリシーファイルを作成します（下図参照）。 この「Registry.pol」には、Windows Defender を無効化するための複数のレジストリ設定が記述されてい ます。このポリシーが配布され適用されることにより、ドメイン配下の全てのクライアント端末上でWindow s Defender が無効化される可能性があります。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 83 LockBit2.0 が作成した「Registry.pol」 ----- A deep-dive analysis of LockBit2.0 Ransomware そして最後に、LockBit2.0 はPowerShell コマンドにより、強制的にグループポリシーをドメイン配下の全 端末へ一斉配布します（下図参照）。 図 84 PowerShell コマンドによりグループポリシーが一斉配布される様子 上記のPowerShell のコマンドは以下のような構成となっており、「指定したOU に存在する全ての端末を取 得」し、見つかった各端末に「グループポリシーを即時強制適用させる」コマンドであることがわかります（下 図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 85 グループポリシーを一斉配布させるPowerShell コマンドの構成 上記のPowerShell が実行された瞬間に、ドメインコントローラ上ではコマンドプロンプトが開き、グループ ポリシーが更新される旨のメッセージが表示されます。またその直後、ドメイン配下にあるクライアント端末 上でも同様にグループポリシーが更新されるプロンプトが表示されます（下図参照）。 （この際、LockBit2.0 は自身の内部で「Run on all domain(waiting 1 min)」というログをメモリ上に展 開します。） 図 86 ドメインコントローラおよびクライアント端末上でグループポリシーが更新される様子 上記のポリシーが強制的に適用された瞬間、クライアント端末上のデスクトップにはコピーされたLockBit2. 0 のEXE ファイルが作成され実行されます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 87 グループポリシーの適用後デスクトップ上に作成されるEXE（LockBit2.0 の本体） グループポリシーによる不正処理の一斉展開の仕組みは以上となります。 ドメインコントローラでのグループポリシーを利用したランサムウェアの展開の様子を動画に収録し、以下の YouTube で公開していますので併せてご覧ください。 [https://www.youtube.com/watch?v=Co8mRfd0iPM](https://www.youtube.com/watch?v=Co8mRfd0iPM) ## ■LockBit2.0 のバグ（作成されたタスクのミス） なお、「ScheduledTasks.xml」に記載されていたデスクトップ上のEXE ファイルを実行させるタスクです が、調査の結果、複数の検体において、グループポリシーで配布されたEXE の実行が、クライアント端末側で 失敗する個体が存在することを確認しました。 LockBit2.0 は、各クライアント端末に「ドメイン管理者アカウント」（Administrator）が前提条件として 「ログオンしている必要がある」タスクを設定してしまっており、現実的にはこの起動条件が満たさせること は通常はあまり起こりえません。 ただし、このタスク内の権限設定が「ドメイン管理者アカウント」（Administrator）ではなく「SYSTEM ア カウント」または「ユーザアカウント」が指定されていれば、攻撃者の意図する状況が成功していたものと考 えらえます。実際に、LockBit2.0 が作成した「ScheduledTasks.xml」の中の権限設定の記述を手動で書き 換え、「SYSTEM アカウント」を指定したものを配布するようにした場合、ポリシーが配布された直後にLo ckBit2.0 がタスクにより実行され自動感染することが確認されました（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 88 LockBit2.0 のスケジュールタスクに発見されたバグと想定される設定 ただし、一連の調査を進めた後、新しく出現したLockBit2.0 の検体において、このバグが修正されている個 体を発見しました。 古い検体と新しい検体によって作成された「ScheduledTasks.xml」の記述をそれぞれ比較すると、上記でバ グであると推測していた部分の記述が以下のようにしっかりとピンポイントで修正されていることがわかりま す（下図参照）。 そのため、この新しいLockBit2.0 の個体においては、ドメイン配下のクライアント端末上でスケジュールタ スクによってEXE が正常に実行され、自動的に感染が発生することも確認されました。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 89 新しいLockBit2.0 の検体でタスクのバグが修正されていることが確認された様子 このように、LockBit2.0 の開発者はバグを随時修正しながら攻撃に使用していることが明確に確認できたた め、検体の挙動における個体差（揺れ）があり、挙動にバグがあったとしても既に修正されたバージョンが出 回っている可能性は高く、安心できる状況ではありません。 LockBit2．0 がグループポリシーで自身を拡散させる様子は動画に収録し以下のYouTube リンクで公開し ていますのでご覧ください。 [https://www.youtube.com/watch?v=Co8mRfd0iPM](https://www.youtube.com/watch?v=Co8mRfd0iPM) ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■デスクトップ壁紙の変更 LockBit2.0 は、感染した端末のデスクトップの壁紙を脅迫文が記載されたものに変更する挙動がありますが、 他のランサムウェアにみられるように単純にあらかじめ用意された画像を取り出して使用するのではなく、感 染端末のディスプレイサイズに合わせたデザインとなるように、わざわざ「Windows GDI+」（Graphics D evice Interface）を用いて、一から画像を描画して壁紙を動的に生成します（下図参照）。 図 90 壁紙を一から描画して生成 ----- A deep-dive analysis of LockBit2.0 Ransomware 以下のように壁紙に表示させる文字列も復号して用意し、Windows GDI+のAPI を用いてテキストとして描 画します（下図参照）。 図 91 復号したテキスト文字列（脅迫文）を生成した画像に描画する処理 LockBit2.0 は一時フォルダ（%temp%）内に、上記の流れで生成した画像を一時ファイルとして作成します （下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 92 壁紙に設定する画像の出力 作成した画像のフルパスを壁紙の設定に関わるレジストリ値を書き換えることで設定します。またその際、ディ スプレイサイズに合わせて壁紙が見やすくなるように、いくつかの設定を行います（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 93 生成した画像パスなどをレジストリに設定する処理 ----- A deep-dive analysis of LockBit2.0 Ransomware 上記の操作により、設定された壁紙に関わるレジストリ設定は以下となります（下図参照）。 図 94 LockBit2.0 により改変された壁紙に関わるレジストリ設定 上記のレジストリを設定しただけではすぐに壁紙の変更がシステムに反映されないため、LockBit2.0 はSys temParametersInfoW 関数を使用することで即時壁紙の変更を反映させます（下図参照）。 図 95 SystemParametersInfoW による壁紙変更の即時反映 以上により、動的に生成した壁紙がデスクトップに反映されます。 なお、このデスクトップの壁紙には、インサイダー（内部者）を募集する記載が書き込まれるタイプの検体が存在し ます（この壁紙を設定しない検体も存在します）。 ----- A deep-dive analysis of LockBit2.0 Ransomware インサイダーを募集する壁紙には「あなたも数百万ドルを稼ぎませんか？」と記載されており、この壁紙を見た人物 に、どこかの会社の内部情報を知っている場合は攻撃者に提供すれば金銭を得られることを示唆する文章が並びます （下図参照）。 こうしてインサイダーを募集する壁紙を設定するという挙動は他のランサムウェアに見られないため、LockBit2.0 が持つ新規性の高い挙動の一つといえます。 これまでのRaaS においてはアフィリエイトなどが初期アクセスブローカーからの認証情報の購入に頼っていた側 面もありますが、新しい攻撃手口のアイデアとしてインサイダーからの情報提供を初期アクセスのきっかけにしよう とする企みが垣間見えます。この企みが成功した場合、攻撃者の侵入経路として非常に効果的な手段を提供する新た な脅威となる可能性があります。 図 96 インサイダーを募集する壁紙が設定された感染端末の様子 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■脅迫文が記述されたテキストファイルの作成 LockBit2.0 は、暗号化したファイルが含まれるすべてのフォルダの中に、脅迫文が記述された「Restore-M y-Files.txt」というテキストファイルを作成します。この脅迫文には、組織内のデータが盗まれてすでに暗号 化されている旨と、身代金を支払わなければデータがダークウェブ上に暴露されるリスクがある点などが記述 されています。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 97 全てのフォルダに作成されるテキスト形式の脅迫文 ## ■HTA ファイルによる脅迫文の表示 LockBit2.0 は、脅迫文を提示する別の方法として、デスクトップにHTML で記述されたアプリケーションで あるHTA（HTML Application）ファイルを作成し利用します（下図参照）。このHTA ファイルには”ファ イルを復元するには攻撃者へコンタクトを取るしか道はない”という趣旨のコメントと、どのような手順でコ ンタクトを取れば良いかが記載されています。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 98 デスクトップに作成され脅迫文を表示するHTA ファイル また、作成したHTA ファイルが端末の再起動時に常に自動的に起動するようにレジストリのRun キーに設定 します（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 99 HTA ファイルを自動起動に関わるレジストリに設定する様子 続いて、「.lockbit」という拡張子を持つファイルをユーザが開いた場合、該当のHTA ファイルが自動的に開 くようにレジストリに設定を行います（下図参照）。 図 100 暗号化されたファイルを開くとHTA ファイルが開くように設定されたレジストリ ----- A deep-dive analysis of LockBit2.0 Ransomware そして、ShellExecuteW でHTA ファイルを起動し表示させます（下図参照）。 図 101 感染後にHTA ファイルを自動的に開く処理 これにより、以下のように自動的にHTA ファイルが開かれます。画面サイズいっぱいに開かれるため、一見デ スクトップの壁紙に見えますが、これはHTA が表示するウインドウです（下図参照）。なお、このウインドウ は[Alt]+[F4]キーで閉じることができます。 図 102 感染後にモニター上に表示されるHTA ファイルが生成するウインドウ ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■プリンタを利用した脅迫文の物理的な印刷（約一万枚） LockBit2.0 の特徴的な挙動の一つが、プリンタを利用した脅迫文の物理的な「印刷」です。 印刷を行うランサムウェアの出現は初めてではなくEgregor という別のランサムウェアが過去に実装しては いたものの、ランサムウェア全体から見るとほとんど存在せず非常に珍しい挙動といえます。 LockBit2.0 は「あなたのデータは盗まれた上に暗号化された。身代金を支払わなければデータが公開される」 という文言が並んだ脅迫文を、感染端末からアクセス可能なネットワークプリンタを含む全てのプリンタで印 刷しようとします。 図 103 LockBit2.0 に感染し脅迫文をプリンタで印刷される様子 ＜余談＞ 以下の記事で解説していくように、ランサムウェアの解析結果を通した理論上においては、プリンタの印刷機 能が特定され印刷機能を持っていることが把握できたのですが、実際にプリンタで印刷されるのか実検証した ところ、想像以上に行き詰りました。 ----- A deep-dive analysis of LockBit2.0 Ransomware また、こうした物理的なデバイスに絡む挙動は仮想解析環境+仮想プリンタなどでは実機とは異なった結果と なる場合があり、実際に「仮想プリンタ」を用いた検証ではLockBit2.0 に感染させても印刷が発生しません でした。 そのため、プリンタの実機を使用した検証を行うことにしました。プリンタ実機を感染端末に接続すればすん なり印刷されるものと想定していましたが実際には印刷が発生せず、複数台のプリンタを用いての数日間をま たいだ長い検証の結果、LockBit2.0 が送信する印刷データに対応しているプリンタ実機と、対応していない プリンタ実機があるという結論に達しました。 他社の解析記事においてはLockBit2.0 の印刷機能に触れているもの自体が少ないですが、記載されている場 合も「LockBit2.0 は脅迫文を印刷する」という程度にしか触れられておらず、実際には印刷されるプリンタ とされないプリンタがあるという新たな事実が今回の検証を通して判明したことになります。 静的解析でコードを見ただけでは「印刷する」という挙動は判るものの、印刷されないプリンタが存在すると いう事実は実際に実機を用いて検証しないとわかり得ない結果であるといえます。以上の検証結果から、実際 の被害組織においても印刷が発生した環境と、印刷が発生しなかった環境があるものと考えられます。 LockBit2.0 は、プリンタ関連のAPI を使用するため、それらのAPI を提供する「Winspool.drv」をロード します（下図参照）。 図 104 Winspool.drv をロードする処理の一部 ----- A deep-dive analysis of LockBit2.0 Ransomware その後、EnumPrinters 関数で感染端末からアクセス可能な全てのプリンタを列挙し取得します（下図参照）。 図 105 感染端末上で利用可能な全てのプリンタを列挙する処理 見つかった全てのプリンタに対し、それぞれOpenPrinter 関数で開き操作可能な状態にした上で、StartDoc Printer 関数でページの印刷を通知します（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 106 見つかったプリンタを開き印刷するページを通知する処理 ----- A deep-dive analysis of LockBit2.0 Ransomware その後、プリンタで印刷するための脅迫文の文字列を復号しメモリ上に展開します（下図参照）。 図 107 全てのプリンタに印刷させる脅迫文の文字列を復号する処理 そして、WritePrinter 関数で指定したプリンタに上記のデータを送信し印刷を指示します（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 108 指定したプリンタにデータを送る処理 1 ページ分のデータの送信が完了したのち、EndDocPrinter 関数で指定されたプリンタの印刷ジョブを終了 した上で、ClosePrinter 関数でプリンタオブジェクトを閉じます（下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 109 印刷終了の処理 以上が1 ページ分の処理ですが、LockBit2.0 はこの処理を約1 万枚（9,999 ページ）分繰り返します（下 図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 110 約一万枚印刷されるようにこれまで解説した一連の印刷処理を繰り返す つまり、プリンタ一台当たり9,999 枚印刷するよう指定されており、この操作を感染端末からアクセス可能 なネットワークプリンタを含む全てのプリンタに対して行うため、途中でプリンタを急いで停止しない限り、 延々と大量に脅迫文が印刷され続けてしまうことになります。 従来のランサムウェアが行ってきたようにモニター上で提示する脅迫文だけでなく、物理的なデバイスを用い て脅迫するというこの手法は、やはり被害組織に与える恐怖やインパクトはより大きいものになるだろうと想 像します。 LockBit2.0 が実機プリンタで脅迫文を印刷する様子は動画に収録し、以下のYouTube で公開していますの で併せてご覧ください。 [https://www.youtube.com/watch?v=zfh-FqPdXI4](https://www.youtube.com/watch?v=zfh-FqPdXI4) ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■インシデント対応や復旧作業を妨害する処理 LockBit2.0 は以下のコマンドをcmd の引数として実行することで、システムのバックアップ（ボリューム シャドウコピー）や、イベントログを削除し、インシデント対応や復旧作業を妨害する処理を行います。 なお、以下のうち上から4 つ目のコマンドには実効性がありませんが、他の一部のランサムウェアやマルウェ アでも同コマンドが確認されているため、開発者が参照した際に記述ミスのままコピーして使用しているもの と推測されます。 図 111 LockBit2.0 がインシデント対応や復旧作業を妨害する処理 ## ■フォレンジックを意識した自身の抹消処理 LockBit2.0 は全ての活動が終了すると、自身のEXE ファイルを削除しますが、その際、単純な削除（Delet e）ではなく、LockBit2.0 のEXE ファイルが存在するハードディスクの位置の先頭から512KB 分のハード ディスク領域を直接0 で埋め尽くすことでファイルを破損させ完全に破壊した上で削除します。具体的には、 fsutil コマンドを使用し「Data offset」と「length」によってサイズ範囲を指定した上で0 埋めした後De l コマンドによってファイルを削除します。（※なお、これらのコマンド処理は外部プロセスであるcmd.exe に依頼するため、実際にはLockBit2.0 のプロセスが終了した後で実施されます） このことから、フォレンジック調査時にランサムウェア本体が正常に復元されないよう意識し、念入りに自身 を抹消していることがわかります（以下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 112 ハードディスク上から自身のファイルの一部を破壊した上で消去するLockBit2.0 加えて、上記のDel コマンドが失敗した場合に備え、Windows の再起動時に自動的にOS によってLockBit 2.0 のEXE ファイルが削除されるよう、システムに予約設定を行います。具体的には、MoveFileExW 関数に MOVEFILE_DELAY_UNTIL_REBOOT の引数を渡すことでシステムに予約を行います（以下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 113 システム起動時に自動的にOS によって削除されるように設定するLockBit2.0 これらの2 つの方法で執拗に、不要になった自身のEXE を抹消しようとするランサムウェアは珍しい部類で あるといえ、復旧作業でランサムウェアを入手させないように入念な隠蔽工作を行おうとする意図が感じられ ます。 これら一連の処理を行った後、LockBit2.0 はExitProecss により自身の処理を終了させます（以下図参照）。 図 114 全ての処理を終えた後に自身を終了する処理 ----- A deep-dive analysis of LockBit2.0 Ransomware LockBit2.0 の挙動は以上となります。 以降では、LockBit2.0 が実装しているその他の機能をご紹介します。 ## ■D&D（drag and drop）に対応 LockBit2.0 のEXE ファイルは、ファイルやフォルダのD&D(drag and drop)に対応しています。この点に 触れた解析記事は確認した範囲においては存在せず、世界的にも知られていないようです。 LockBit2.0 は起動した際、CommandLineToArgW 関数を使用し実行引数の数が「2」であるかどうかを チェックします。引数の数が「2」である場合はD&D(drag and drop)の処理に遷移し、指定されたファイル または指定されたフォルダ内にあるすべてのファイルに対する暗号化処理のみを行います（以下図参照）。 つまり、LockBit2.0 は、自動的に動作するランサムウェアとしてだけでなく、攻撃者が指定した対象（ファイ ルやフォルダ）のみを暗号化したい、というシチュエーションでも活用できるよう、「暗号化ツール」として利 用できるようにも開発されていることがわかります。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 115 D＆D に対応したLockBit2.0 のEXE 本体 ----- A deep-dive analysis of LockBit2.0 Ransomware ## ■LockBit2.0 が隠し持つGUI(隠しウインドウ)の発見 冒頭の表層解析で解説した通り、LockBit2.0 のEXE がGUI アプリケーションとしてビルドされていたのに も関わらず、一般的な表層解析の範囲ではGUI コンポーネントなどのリソースデータが確認できなかったこと が筆者は気がかりになっており、その観点でLockBit2.0 の起動中のプロセスを念入りに調査しました。 その結果、起動中のプロセス内には表層解析では見えなかったリソースが出現しており、button やListView などのGUI コンポーネントを持った非表示の”隠しウインドウ“が作成されていることを発見しました。隠し ウインドウは「LockBit2.0 Ransom」という文字列を持っており、「LockBit_2_0_Ransom」というウイ ンドウクラスを持つことがわかります（以下図参照）。 図 116 LockBit2.0 のプロセスに隠されたGUI コンポーネントの発見 また、該当の隠しウインドウの状態を調べるとStyle が「4CF0000」(hidden,enabled)となっていることか ら、ウインドウの作成はされているが非表示になっているということがわかります（以下図参照）。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 117 ウインドウが隠し状態に設定されている様子 この結果から改めて静的解析したところ、確かにCreateWindowExW 関数でウインドウを生成している処理 が確認されました（以下図参照）。 図 118 LockBit2.0 がウインドウを生成する処理 また、作成したウインドウをShowWindow 関数で表示する際、引数として非表示を意味する「0」が渡され ていることも確認できました（以下図参照）。つまり、ウインドウが生成されてはいるものの非表示になって いるという先ほどの動的解析結果と一致することがわかります。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 119 生成したウインドウを非表示状態で表示させる処理 そのため、非表示となっている隠しウインドウを無理やり表示させるようLockBit2.0 ランサムウェアのバイ ナリを変更したところ、これまで世界的にも公に知られていなかったLockBit2.0 の隠しウインドウが表示さ れ姿を現しました（以下図参照）。 表示されたウインドウは、複数のタブを持ちGUI コンポーネントが整然と並ぶグラフィカルなインターフェイ スとなっており、感染端末上のドライブ一覧や現在暗号中の状況がリアルタイムに表示される様子がわかりま す。また、右クリックメニューも用意され、暗号化処理の停止や再開などが選択できるようになっています。 ----- A deep-dive analysis of LockBit2.0 Ransomware 図 120 姿を現したLockBit2.0 のGUI （本来隠されたウインドウ） 以下は、「Log」タブを表示させた様子ですが、動作に関わる細かなログがリアルタイムに出力されていきま す。 （これらのログ文字列は、該当する各処理の中で随時にメモリ上に展開されSendMessage 関数で送信され ます） ----- A deep-dive analysis of LockBit2.0 Ransomware 図 121 LockBit2.0 のGUI におけるLog タブの様子 先ほど解説した通り､ShowWindow 関数の引数は変数ではなく0 で固定化(ハードコード)されているため､そ れはLockBit2.0 のEXE ファイルがコンパイルされた後に該当の値を動的に変更する仕組みを持たない可能 性が高いということを意味します｡つまり､RaaS(Ransomware as a Service)の中で､アフィリエイトに提 供されるLockBit2.0 のバイナリのビルド画面にこのGUI の表示に関わるオプションが用意されていると推 測され､画面の表示/非表示があらかじめアフィリエイトによって設定された上でビルド(コンパイル)されてい るものと考えられます｡ 攻撃者がランサムウェアを被害組織内に展開し感染させる際は基本的にGUI 画面が表示されるべきではないた め､このGUI オプションが有効になったバイナリが出回ることはほとんどないと想定され､そうした背景がLo ckBit2.0 の隠しウインドウの存在が一般的に知られていない理由の一つであるといえます｡ 以上､今回弊社の解析により公で初めて明らかとなったLockBit2.0 のGUI が実際に動作する様子は､動画で 収録し以下のYouTube にて公開しています｡ [https://www.youtube.com/watch?v=-LEKTd4rJTU](https://www.youtube.com/watch?v=-LEKTd4rJTU) ----- A deep-dive analysis of LockBit2.0 Ransomware その他､ドメインコントローラでのグループポリシーを利用したランサムウェアの展開の様子や､プリンタによ る印刷動画についても､それぞれ動画に収録し､以下のYouTube で公開していますので併せてご覧ください｡ [https://www.youtube.com/watch?v=Co8mRfd0iPM](https://www.youtube.com/watch?v=Co8mRfd0iPM) [https://www.youtube.com/watch?v=zfh-FqPdXI4](https://www.youtube.com/watch?v=zfh-FqPdXI4) ※動画が記事の理解のお役に立てた際はぜひ｢いいね!｣を押してフィードバックいただけますと幸いです｡ ※本記事で解析に使用した全てのLockBit2.0 のハッシュ値: 0545f842ca2eb77bcac0fd17d6d0a8c607d7dbc8669709f3096e5c1828e1c049 0906a0b27f59b6db2a2451a0e0aabf292818e32ddd5404d08bf49c601a466744 4bb152c96ba9e25f293bbc03c607918a4452231087053a8cb1a8accb1acc92fd 4edbf2358a9820e030136dc76126c20cc38159df0d8d7b13d30b1c9351e8b277 bcbb1e388759eea5c1fbb4f35c29b6f66f3f4ca4c715bab35c8fc56dcf3fa621 717585e9605ac2a971b7c7537e6e311bab9db02ecc6451e0efada9b2ff38b474 73406e0e7882addf0f810d3bc0e386fd5fd2dd441c895095f4125bb236ae7345 a7591e4a248c04547579f014c94d7d30aa16a01bb2a25b77df36e30a198df108 acad2d9b291b5a9662aa1469f96995dc547a45e391af9c7fa24f5921b0128b2c b3faf5d8cbc3c75d4c3897851fdaf8d7a4bd774966b4c25e0e4617546109aed5 d089d57b8b2b32ee9816338e96680127babc5d08a03150740a8459c29ab3ba78 f32e9fb8b1ea73f0a71f3edaebb7f2b242e72d2a4826d6b2744ad3d830671202 3cbdd9250d50cf9e5c9aa6c0ade4dde2995e1319e96a160ba6730e063e86f5bc 6edbe66b81f7168fa9d4b087c28409d6dfc98d560760369da4ed4ca2262abd33 【ご注意】 - ホワイトペーパーは2021 年10 月19 日に公開した弊社ブログ記事（https://www.mbsd.jp/rese arch/20211019/blog/）を再編集したものです。● このホワイトペーパーに掲載されている情報、画 像、デザイン、レイアウト、ロゴマーク、商標等に関する全ての知的財産権は、三井物産セキュアディレク ション株式会社(MBSD)又はMBSD にその利用を認めた権利者に帰属しています。● 不許複製 ### 三井物産セキュアディレクション株式会社 https://www.mbsd.jp © 2021 Mitsu Bussan Secure Directions, Inc. All Rights Reserved. -----