難読化されたラテラル ムーブメント ツールを動的に分析するための Windows ドメインの構成

Suspicious imports news

私たちは最近、難読化された大規模なマルウェア サンプルに遭遇し、いくつかの興味深い分析課題を提示しました。仮想化を使用していたため、静的分析用に完全に解読されたメモリ ダンプを生成できませんでした。仮想化された大規模なサンプルを静的に分析するには、数日から数週間かかる場合があります。この時間のかかるステップを回避することで、FLARE リバース エンジニアリング チームと Mandiant コンサルティング チームとのコラボレーションの機会が得られ、最終的に困難なリバース エンジニアリングにかかる時間を大幅に節約できました。

サンプルは横移動ツールではないかと疑ったため、動的分析に適した環境が必要でした。環境の構成が不可欠であることが判明したため、ドメインを活用するサンプルに遭遇した他のアナリストを支援したいと考えています。ここでは、仮想化された Windows ドメインをセットアップしてマルウェアを実行するプロセスと、マルウェアの機能の一部を確認するために使用した分析手法について説明します。

予備分析

新しいマルウェア サンプルを分析するときは、基本的な静的分析から始めます。多くの場合、それがどのような種類のサンプルで、どのような機能があるかを知ることができます。これを使用して、分析プロセスの後続の段階に通知し、関連データに焦点を当てることができます。 CFF Explorer などの Portable Executable 分析ツールから始めます。この場合、サンプルが 6.64 MB と非常に大きいことがわかりました。これは通常、サンプルに Boost や OpenSSL などの静的にリンクされたライブラリが含まれていることを示しており、分析が困難になる可能性があります。

さらに、図 1 に示すように、インポート テーブルには 8 つの動的にリンクされた DLL が含まれており、インポートされた関数はそれぞれ 1 つだけであることがわかりました。マルウェアが使用する実際の API。

Suspicious imports
図 1: 疑わしい輸入

私たちの文字列分析により、マルウェアを静的に分析するのは難しいという私たちの疑いが確認されました。ファイルが非常に大きいため、考慮すべき文字列は 75,000 を超えました。 StringSifterを使用して、マルウェア分析との関連性に従って文字列をランク付けしましたが、有用なものは特定されませんでした。図 2 は、StringSifter による最も関連性の高い文字列を示しています。

StringSifter 出力
図 2: StringSifter の出力

この種の障害に遭遇した場合、多くの場合、動的分析を利用してマルウェアの動作を明らかにできます。この場合、私たちの基本的な動的分析は希望をもたらしました。実行時に、サンプルは使用法ステートメントを出力しました。

使用法:evil.exe [/S[:str]] [/C] [/R]
/P:str — ペイロード ファイルへのパス。
/S[:str] — 逆コピー用に共有します。
/B:str — 設定を読み込むファイルへのパス。
/F:str — 指定したファイルにログを書き込みます。
/C — ログをコンソールに書き込みます。
/L:str — ホスト リストを含むファイルへのパス。
/H:str — 処理するホスト名。
/T:int — 同時スレッドの最大数。
/E:int — ペイロードが削除されるまでの秒数 (削除を回避するには 0 に設定)。
/R — ホストからペイロードを削除します (/P および /S は無視されます)。
/S が値なしで指定された場合、ランダムな名前が使用されます。
/L と /H は、組み合わせて複数指定できます。少なくとも 1 人は出席する必要があります。
/B は、他のすべてのフラグの後に処理され、指定された値 (存在する場合) をオーバーライドします。
すべてのパラメータは大文字と小文字を区別します。

図 3: 使用法ステートメント

プロセスを一時停止してメモリをダンプすることにより、サンプルの解凍を試みました。マルウェアはほぼ瞬時に終了し、自身を削除したため、これは困難であることがわかりました。最終的に、図 4 のコマンドを使用して、部分的に解凍されたメモリ ダンプを生成することができました。

sleep 2 && Evil.exe /P:”C:WindowsSystem32calc.exe” /E:1000 /F:log.txt /H:some_host

図 4: バイナリを実行するために実行されるコマンド

任意のペイロード ファイルを選択し、ペイロードを削除する間隔を長くしました。また、ペイロード実行用のログ ファイル名とホスト名も提供しました。これらのパラメーターは、強制的に実行時間を遅くするように設計されているため、プロセスが終了する前に中断できます。

プロセス ダンプを使用して、2 秒の遅延後にメモリ スナップショットを作成しました。残念ながら、仮想化は依然として静的分析を妨げており、サンプルはほとんど難読化されたままでしたが、必要なブレークスルーを提供するいくつかの文字列を抽出することができました.

図 5 は、元のバイナリには存在しなかった興味深い文字列の一部を示しています。

dumpedswaqp.exe
psxexesvc
schtasks.exe /create /tn “%s” /tr “%s” /s “%s” /sc onstart /ru システム /f
schtasks.exe /run /tn “%s” /s “%s”
schtasks.exe /delete /tn “%s” /s “%s” /f
サービスアクティブ
ペイロードの直接コピー
ペイロードの逆コピー
ペイロードが削除されました
タスクが作成されました
実行されたタスク
タスクが削除されました
SMオープン
サービスが作成されました
サービス開始
サービス停止
サービスが削除されました
合計ホスト: %d、スレッド: %d
SHARE_%c%c%c%c
共有「%s」、パス「%s」が作成されました
共有「%s」が削除されました
API “%S” のフックでエラーが発生しました
最初の %d バイトをダンプしています:
DllRegisterServer
DllInstall
登録
インストール

図 5: メモリ ダンプからの文字列出力

これまでの分析に基づいて、リモート システム アクセスが疑われました。ただし、ラテラル ムーブメントの環境を提供せずに疑惑を確認することはできませんでした。分析を迅速に行うために、仮想化された Windows ドメインを作成しました。

これにはいくつかの構成が必要なため、この分析手法を使用する際に他のユーザーを支援するために、ここでプロセスを文書化しました。

テスト環境の構築

テスト環境では、クリーンな Windows 10 および Windows Server 2016 (デスクトップ エクスペリエンス) 仮想マシンがインストールされていることを確認してください。ドメイン コントローラーを他のテスト システムから分離できるように、2 台の Windows Server 2016 マシンを作成することをお勧めします。

ホスト システムの VMware Virtual Network Editor で、次の設定でカスタム ネットワークを作成します。

  • [VMNet 情報] で、[ホストのみ] ラジオ ボタンを選択します。
  • 外界への接続を防ぐために、「ホスト仮想アダプターを接続する」が無効になっていることを確認します。
  • 静的 IP アドレスを使用する場合は、「ローカル DHCP サービスを使用する」オプションが無効になっていることを確認してください。

これを図 6 に示します。

仮想ネットワーク アダプターの構成
図 6: 仮想ネットワーク アダプターの構成

次に、このネットワークに接続するようにゲストのネットワーク アダプタを構成します。

  • 仮想マシンのホスト名と静的 IP アドレスを構成します。
  • すべてのゲストのデフォルト ゲートウェイおよび DNS サーバーとして、ドメイン コントローラーの IP を選択します。

図 7 に示すシステム構成を使用しました。

システム構成例
図 7: システム構成の例

すべての構成が完了したら、指定されたドメイン コントローラー サーバーに Active Directory ドメイン サービスと DNS サーバーの役割をインストールすることから始めます。これは、Windows Server Manager アプリケーションを介して図 8 に示すオプションを選択することで実行できます。ロールが追加されると、ダイアログ全体でデフォルト設定を使用できます。

ドメイン コントローラーで必要な役割
図 8: ドメイン コントローラーに必要な役割

役割がインストールされたら、図 9 に示すように昇格操作を実行します。Active Directory ドメイン サービスの役割がサーバーに追加されると、通知メニュー (フラグ アイコン) から昇格オプションにアクセスできます。 testdomain.localなどの完全修飾ルート ドメイン名を持つ新しいフォレストを追加します。他のオプションはデフォルトのままにしておくことができます。昇格プロセスが完了したら、システムを再起動します。

サーバー マネージャーでシステムをドメイン コントローラーに昇格させる
図 9: サーバー マネージャーでのシステムのドメイン コントローラーへの昇格

ドメイン コントローラーが昇格したら、ドメイン コントローラーのActive Directory ユーザーとコンピューターを介してテスト ユーザー アカウントを作成します。例を図 10 に示します。

ユーザー アカウントのテスト
図 10: テスト ユーザー アカウント

テスト アカウントが作成されたら、仮想ネットワーク上の他のシステムをドメインに参加させます。これは、図 11 に示すように、[システムの詳細設定] から実行できます。テスト アカウントの資格情報を使用して、システムをドメインに参加させます。

各ゲストのドメイン名を構成する
図 11: 各ゲストのドメイン名を構成する

すべてのシステムがドメインに参加したら、各システムが他のシステムに ping できることを確認します。テスト環境で Windows ファイアウォールを無効にして、各システムがテスト環境で別のシステムの利用可能なすべてのサービスにアクセスできるようにすることをお勧めします。

すべてのテスト システムで、テスト アカウントに管理者権限を付与します。これは、図 12 に示すコマンドを使用して手動で各システムのローカル管理者グループを変更するか、 グループ ポリシー オブジェクト (GPO)を介して自動化することで実行できます。

ネットローカルグループ管理者 sa_jdoe /ADD

図 12: ユーザーをローカル管理者グループに追加するコマンド

ドメインの動的分析

この時点で、動的分析を開始する準備が整いました。 Wireshark と Process Monitor をインストールして起動し、テスト環境を準備しました。図 13 に示すように、3 つのゲストすべてのスナップショットを作成し、クライアントのテスト ドメイン アカウントのコンテキストでマルウェアを実行しました。

Evil.exe /P:”C:WindowsSystem32calc.exe” /L:hostnames.txt /F:log.txt /S /C

図 13: マルウェアの実行に使用されるコマンド

図 14 に示すように、 hostnames.txtファイルに次の行区切りのホスト名を入力しました。

DBPROD.testdomain.local
client.testdomain.local
DC.testdomain.local

図 14: hostnames.txt のファイルの内容

パケット キャプチャ分析

パケット キャプチャのトラフィックを分析したところ、ホスト リスト内の各システムへの SMB 接続が特定されました。 SMB ハンドシェイクが完了する前に、Kerberos チケットが要求されました。図 15 に示すように、ユーザーに対してチケット保証チケット (TGT) が要求され、サーバーごとにサービス チケットが要求されました。 Mandiant レッドチーム ツール。

Kerberos 認証プロセス
図 15: Kerberos 認証プロセス

マルウェアは、SMB 経由でC$共有にアクセスし、ファイルC:Windowsswaqp.exeを書き込みました。次に、RPC を使用して、サービスの登録と起動に使用されるSVCCTLを起動しました。 SVCCTLswaqpdサービスを作成しました。サービスはペイロードの実行に使用され、その後削除されました。最後に、ファイルは削除され、追加のアクティビティは観察されませんでした。トラフィックを図 16 に示します。

パケット キャプチャで確認されたマルウェアの動作
図 16: パケット キャプチャで観察されたマルウェアの動作

Process Monitor を使用したマルウェアの動作の分析により、この観察結果が確認されました。次に、さまざまなコマンド ライン オプションと環境でマルウェアを実行しました。静的分析と組み合わせることで、リモート ホストへのペイロードのコピー、サービスのインストールと実行、その後の証拠の削除など、マルウェアの機能を確信を持って判断することができました。

結論

大規模で難読化されたサンプルの静的分析には、数十時間かかる場合があります。動的分析は代替ソリューションを提供できますが、アナリストは適切な実行環境を予測してシミュレートする必要があります。この場合、基本的な分析の基礎を仮想化された Windows ドメインと組み合わせて、仕事を成し遂げることができました。 FLARE リバース エンジニアリングの専門知識と Mandiant のコンサルティングおよび Red Team の経験を組み合わせることで、FireEye が利用できる多様なスキルを活用しました。この組み合わせにより、分析時間が数時間に短縮されました。侵害されたホストから必要な指標を迅速に抽出することで、アクティブなインシデント対応調査をサポートしました。この経験を共有することで、他の人がラテラル ムーブメント分析のための独自の環境を構築するのに役立つことを願っています。

参照: https://www.mandiant.com/resources/blog/configuring-windows-domain-dynamically-analyze-obfuscated-lateral-movement-tool

Comments

タイトルとURLをコピーしました