「悪意のあるコード分析の実践」実験 - Labs-16
「Malicious Code Analysis Practice」に実験を記録し、関連リンクを提供します。
- 電子書籍のダウンロード
（*＾＾*）
Labs-16-01 実験
サンプル: Lab16-01.exe
静的解析:
- シェルを確認します - シェルではなく、Win32 コンソール プログラムをコマンド ラインから起動する必要があります。
- 入力テーブルの表示 -
KERNEL32.DLL: ファイルの読み取り、書き込み、コピー、削除、文字列比較などの関数
ADVAPI32.dll: サービスのオープン、作成、レジストリの削除、作成などの
関数 SHELLE32.DLL: の関数シェルコマンドの実行
WS2_32.dll : ネットワーク接続および操作関連機能
- 文字列分析 -
文字列 cmd.exe、/c del はコマンドを実行するために cmd を呼び出す可能性があります。
文字列 SOFTWARE\Microsoft\XPS, \kernel32.dll, %SYSTEMROOT%SYSTEM32\ はレジストリ キーであり、レジストリ文字列
HTTP を変更する可能性があります。 /1.0 および GET はアクセス要求を送信する可能性があり、
文字列 -cc、-re、-in は悪意のあるプログラムのオペランド/実行コマンドである可能性があります。
IDA分析
- プログラムは最初にデバッガの判定を実行します。現在のプログラムがデバッガで実行されている場合は、関数 sub_401000() が呼び出され、その中で cmd が呼び出され、自身を削除します。
- 続けてパラメータの数も検出されることがわかります。パラメータが 1 つだけの場合は関数 sub_402C40 が呼び出され、その後デバッガが検出されます。要件を満たさない場合は関数 sub_401000() が検出されます。それ自体を削除するように呼び出されます。
- 関数 sub_402C40() の関数は、主要なレジストリ操作が含まれるため、当面は分析しません。このレジストリ操作は次のコードで初期化されるため、ここから直接開始するのはより困難になります。次のコード (プログラムのインストールと削除に使用されるパラメーター 'in'、'-re'、'-cc') から、この関数の関数が全体のコア関数である必要があることも推測できます。悪質なコード。
- 続けて、入力された最初のコマンド ライン パラメーターが関数 sub_402D70 に渡され、その下で自己削除関数 sub_401000 が呼び出され、この関数が検証関数であることが推測できます。
- この関数に従って、最初にデバッガーの検出を実行し、次に受信パラメータの計算と検証を実行します。アルゴリズムによれば、ターゲット パラメータは文字列「abcb」である必要があります。
- 続いて、コマンド ラインに入力された 2 番目のパラメーターが一致し、一致に応じてさまざまなアクションが実行されます。このうち、「in」は悪意のあるプログラムのサービスの作成または構成ファイルの更新に使用され、「re」はサービスの削除に使用されます。 'c' ' は新しいレジストリ エントリの作成に使用され、'-cc' はレジストリ エントリの出力に使用されます。
- ここでは、「in」パラメータに対応するインストール操作 - sub_402F40() に焦点を当てる必要があります。分析のためにこの関数を入力します。この関数は、最初にサービスが存在するかどうかを確認し、存在しない場合は新しいサービスを作成することがわかります。サービスとサービスのパス システム パスにコピーされる悪意のあるプログラムのパスです。また、レジストリも変更し、文字列「ups」、「http://www.practicalmalwareanalysis.com」、「80」を保存します。レジストリ キーの「Configuration」値に「」と「60」が含まれています。
- インストールプロセスが分析されました。プログラムの主要な機能部分、関数 sub_402C40 を分析しましょう。
- 分析のために関数 sub_402C40 を入力します。デバッガは引き続き関数内で検出され、無限ループが実行されます。ループ本体は 2 つの関数 sub_4014B0 と sub_402880 を呼び出します。
- これら 2 つの関数を個別に分析します。最初に sub_4014B0 を分析します。この関数は、レジストリ キー 'Configuration' の値を照会し、次に 2 番目の値を取り出して入力パラメーター名に渡します。インストール パラメーターが 4 つあることはすでにわかっています。文字列はキー値に保存され、その 2 番目は URL です: "http://www.practicalmalwareanalysis.com"、
- 次に、関数 sub_402880 を分析します。この関数にはパラメータ名 = "http://www.practicalmalwareanalysis.com" があります。関数を分析した結果、この関数はリモート コントロール機能を実装し、異なるパラメータに従って異なる操作を実行することが疑わしいことがわかりました。 。
- サスピシオンは、判定用のパラメータがパラメータ v14 から来ており、このパラメータがパラメータとして関数 sub_402650 に渡されていることが判明したため、このパラメータがこの関数に割り当てられていると推測しました。
- 分析するには関数 sub_402650h に従ってください。この関数はネットワークに接続し、受信したデータを返します。
- したがって、このプログラムのリモート制御機能は確認されており、ネットワーク接続を通じてデータを送信し、受信したデータに応じてさまざまな動作を実行します。このうち、「SLEEP」はスリープ関数を直接呼び出してスリープ動作を実行します。ネットワーク接続を使用して、感染したホスト上にファイルを作成し、指定されたデータをそこに書き込みます。「DOWNLOAD」は、ネットワーク接続を通じて感染したホスト上の指定されたファイルを読み取り、ネットワークを通じて C&C にデータを送信します。「CMD」 " はネットワーク接続を通じて実行されます。シェル リモート コマンドは、実行結果を C&C に送り返します。
- ここまででプログラム全体の解析は終了したので、機能をまとめてみます:
(1) プログラムはコマンドラインから実行を継続する必要があり、パスワードが必要です。そうでないとプログラム自体が削除されます。
(2) プログラムは継続的に実行されます。動作中にデバッガを検出する 存在
(3) プログラム コマンドにはパラメータが必要であり、異なるパラメータに従って異なる操作が実行されます。「in」は悪意のあるプログラム サービスの作成または構成ファイルの更新に使用され、「re」はサービスの削除に使用されます。 「c」は新しい登録を作成するために使用されます。テーブル エントリ、「-cc」はレジストリ エントリを出力するために使用されます
(4) プログラムが正常にインストールされると、プログラムはリモート コントロールの悪意のあるプログラムとなり、ネットワーク接続を介してデータを送信します。そのうち、「SLEEP」はスリープ関数を直接呼び出してスリープ動作を実行し、「UPLOAD」はネットワーク接続を通じて感染ホスト上にファイルを作成し、そこに指定されたデータを書き込む「DOWNLOAD」ネットワーク接続を介して感染ホスト内のファイルを読み取ります ファイルを指定し、ネットワークを介して C&C にデータを送信します。「CMD」はネットワーク接続を介してシェルのリモート コマンドを実行し、実行結果を C&C に送り返します。
動的解析
- モニタリングのために PM と PE を開く
- コマンドラインからプログラムを直接実行する
- PM レジストリ操作を表示 - 不審な操作はありません
- ファイル操作の表示 - cmd を複数回開きます。
- プロセス ツリーを表示します。cmd を呼び出します。cmd によって実行されるコマンドは /c del で、プログラム自体を削除します。
質問
- この悪意のあるコードではどのようなデバッグ対策技術が使用されていますか?
回答: 関連するフラグ (BeingDebugged、ProcessHeap、NTGlobalFlag) が検出され、プログラムがデバッガーで実行されているかどうかが判断されます。 - それぞれのデバッグ対策手法が正常に実行されると何が起こるでしょうか?
回答: プログラムがデバッガーで実行されていることが判明した場合、プログラムは cmd を呼び出して自身を削除します。 - これらのアンチデバッグ技術にどのように対処すればよいでしょうか?
回答: OD 内の該当するジャンプ コードを手動で変更しますが、この方法は関連する検出コードが多数あるため手間がかかりますが、デバッガ プラグインを使用して対応するデータ構造を確認する方法もあります。 - デバッグ中にインストルメントされたデータ構造を手動で変更するにはどうすればよいですか?
回答: 関連するフラグのメモリ アドレスを見つけて、これらのフラグのデータを変更します。 - 悪意のあるコードを回避するのに役立つアンチデバッグ技術を疑う OllyDbg プラグインはどれですか?
回答: OD プラグイン PhantOm、ImmDbg、PyCommand、および hiddenebug
Labs-16-02 実験
サンプル: Lab16-02.exe
静的解析:
- シェルを確認してください - シェルがありません
- レジストリの表示 -
Kernel32.dll: スリープ、スレッドの作成、プロセスの終了、プロセス名の取得、ファイルの書き込み、ライブラリ ファイルのロード、その他の機能
User32.dll: Windows フォームの検索
- TLSコールバックが使用されていることがわかりました
- 文字列分析により、
「パスワードが正しくありません。もう一度お試しください。」という文字列が見つかりました。プログラムを起動するにはパスワードを入力する必要があります。
「OLLYDBG」という文字列が見つかりました。デバッガが検出された可能性があると推測されます。
- 最初に予備的な動的分析を実行し、次に IDA 分析を実行する必要がありますが、悪意のあるプログラムはパスワードを必要とするため、IDA 分析が最初に実行されます。
IDA分析
- IDA はプログラムを開き、main 関数の最初の論理ブロックで実行パラメータの数が検出されたことを検出します。検出に失敗した場合は、文字列「usage: %s <4 文字のパスワード>\n」が出力され、プログラムは終了します。
- 別のブランチを解析します プログラム実行時にパラメータがあればスレッドが作成されます スレッドのオフセットアドレスは「StartAddress」です このアドレスブロックのコードは暗号化モジュールのようなものです
- このアドレス ブロックのコードを脇に置いて、分析を続けましょう。ジャンプ分岐に基づく _strcmp 関数の呼び出しが疑わしいことがわかり、ここでパスワードが検証されます。
- パスワードは、メモリ Byte_48030 に保存されている _strcmp のパラメータであると考えられます。解析のためにメモリ アドレスを追跡したところ、メモリ内に 0xFFh があることがわかりました。データは表示可能な文字ではありません。同時に、右側の 4 文字は多くの相互参照です。前にスキップした暗号化関数を見つけるためにフォローアップしてください。
- 暗号化関数のメモリ計算は依然として比較的複雑であることがわかりますが、現時点では、分析を続けるには 2 つの方法があります: (1) 暗号化アルゴリズムを段階的に分析してパスワードを計算することができます。 strcmp で動的デバッグに OD を使用します。 関数呼び出しにブレークポイントを設定し、メモリ データ内のパスワードを表示します。
- もちろん、OD を使用した方が便利で高速ですが、その前に、strncmp の受信パラメータのアドレスを見つけます - 0040122E Push offset byte_408030; char *
- OD でファイルを開くと、プログラムが入り口で中断し、その後に文字列 "OLLYDBG" が続き、関数 user32.FindWindowA を呼び出していることがわかります。この関数の目的は、OD ウィンドウを検索してデバッガを実行することであることがわかります。デバッガが見つかった場合は、プログラムを終了します。
- 前述の strncmp 受信パラメータのアドレス 0040122E でブレークし、F8 シングルステップ実行して、検出結果を変更します (ここでの OD は中国語バージョンなので、変更せずに検出を通過し、実行を継続します)。その後、実行を継続します。プログラム (F9) - プログラムは 0040122E で中断します。
- この時点でメモリにある文字列は bzqr です。コマンド ラインを使用してプログラムを実行し、パスワードとして「bzqr」と「bzqrp@ss」を入力します。どちらも間違っています。
- OD を使用してデバッグ用のパラメーターを渡し、strncmp にブレークポイントを設定し、実行を継続すると、テストが正常にパスしたことがわかります。では、コマンド ラインの実行時にパスワード エラーが表示されるのはなぜですか?これは、後続のモジュール IDA で慎重に分析してください。
- PEID が分析を行ったときに、TLS セグメントが占有されていることが判明したことを思い出してください。通常の状況では、通常のプログラムは .tls セグメントを必要としないため、悪意のあるプログラムがアンチデバッグ技術を使用していると疑うのに役立ちます。
- IDA を使用して TLS コールバック関数を分析します。Ctrl+E はプログラムのエントリ ポイントを呼び出します。1 つはメイン関数、もう 1 つはコールバック関数のエントリ ポイントです。
- main 関数を分析しました。次に、分析のために TLS コールバック関数を入力します。コードのこの部分では、最初に OLLYDBG ウィンドウも検索します (ここでの文字列「OLLYDBG」は、ウィンドウではなくウィンドウのクラス名を指します) name) が見つかった場合は、直接終了します。それ以外の場合は、次のステップのために関数 sub_401020 を呼び出します。
- この関数をたどると、SetLastError 関数を呼び出してエラー コードを設定し、OutputDebugStringA 関数を呼び出してデバッガと対話して文字列を出力し、次に GetLatError 関数を呼び出して新しいエラー コードを取得していることがわかります。ここで、前の OutputDebugStringA 関数は次のとおりです。デバッガとの対話に使用されます。失敗した場合は、新しいエラー コードが生成されます。デバッガとの対話が成功した場合、エラー コードは変更されません。
- デバッガが検出された場合、メモリ内のデータ byte_40A968 はその後の分析を容易にするためにインクリメントされ、メモリの名前は「TLS_changed」に変更されます。
- メモリ アドレスに対して相互参照解析を実行したところ、_strncmp 関数によるアクセスと、先ほど解析した作成済みスレッド エントリ アドレスの StartAddress のオフセットによるアクセスと、そのアドレスに対するアクセスが他に 2 件見つかりました。
- アドレスに続いて、先ほど StartAddress コード ブロックを分析して暗号化関数であることがわかりましたが、暗号化計算に TLS_changed メモリのデータが追加され、このデータは TLS コールバック関数と検出デバッガに関連しています。また、OLLYDBG から取得したパスワードがまだ間違っている理由についても説明しており、デバッガは TLS コールバック関数でも検出され (ただし、見つかりませんでした)、TLS での検出が関係する暗号化に直接影響したためです。取得した値が間違っているため、この状況にどう対処すればよいでしょうか?
(1) TLS コールバック関数内のデバッガの検出ポイントを手動で変更します。検出戻り値を直接変更するか、検出コードをブロックできます (2) TLS コールバック関数でデバッガが見つかると、メモリ内のデバッガ
byte_40A968データは自動インクリメント操作を実行します。自動インクリメント操作を nop に置き換えて、変更したバイナリ ファイルを再保存できます。 - ここでは 2 番目の方法を使用します。インクリメント操作を nop 命令に置き換え、それをバイナリ ファイルとして保存します。
- 新しく保存したバイナリ ファイルを OD で開き、_trncmp 関数の下で中断します (アドレスは IDA から見つけることができます)。
- プログラムを実行すると、プログラムはブレークポイントで一時停止します。この時点でのスタック内のデータは「12345」と「byqrp@ss」です。「12345」は入力したパラメータで、「byqrp@ss」は正しく復号化されたものです。パスワードは4桁なので、正しいパスワードは「byqr」です。
- 試してみましたが、やはりパスワードが間違っていることが分かりました。
- 暗号化関数のコードブロックに戻って解析したところ、操作に関係するデータにはTLS_changedデータの他にfs:30hデータも含まれていることが分かりました（Lab16-01ですでに解析済み）。このメモリデータがPEBのベースとなるアドレス、アドレスオフセットを2に変更したアドレスがデバッガ検出に使用されるBeingDebugedフラグで、ここにもデバッガ検出があることが判明・真実が判明( •̀ ω • ́)✧
- OD プラグインを使用して上記の PEB 構造でデバッガ検出をシールドし、PhantOm を開いて「PEB から隠す」を選択します。
- プログラムを再実行します (パラメータを入力し、_strncmp を呼び出す前に次のセクションに進みます) 一時停止後、新しいパスワードがスタックに表示されます。
- コマンドラインを使用して再試行してください - 正しいです
動的解析
- コマンドライン実行プログラム - 失敗しました、パスワードが必要です
質問
- コマンド ラインから Lab16-02.exe を実行するとどうなりますか?
回答: プログラムは 4 桁のパスワードを入力するよう求めます。
- Lab16-02.exe を推測されたコマンド引数で実行するとどうなりますか?
回答: 入力したパスワードが間違っています - コマンドラインのパスワードとは何ですか?
回答: 正しいパスワードは byrr です。 - IDA Pro を使用して Lab16-02.exe をロードします。main 関数のどこに strncmp 関数が疑わしく見つかりますか?
回答: strncmp 関数がアドレス 0040123A で見つかりました - この悪意のあるコードがデフォルト設定で OllyDbg に読み込まれるとどうなりますか?
回答: プログラムはすぐに終了します - Lab16-02.exe の PE 構造の特徴は何ですか?
回答: PEID を使用してシェルをチェックしたところ、.tls セクションが占有されていることがわかりました。通常の状況では、通常のプログラムには .tls セクションは必要ありません。この場合、悪意のあるプログラムがアンチデバッグ技術を使用していると疑うことができます。 - コールバックはどこで発生しますか? (ヒント: IDA Pro では Ctrl+E キーの組み合わせを使用します)
回答: コールバック関数はアドレス 00401060 から始まります。 - 悪意のあるコードは、デバッガ内で即座に終了させるためにどのようなデバッグ対策技術を使用しますか? このチェックを回避するにはどうすればよいでしょうか?
回答: FindWindowA 関数は、OD ウィンドウ (クラス名 OLLYDBG のウィンドウ) を検出するために使用されます。 - アンチデバッグ技術を無効にすると、デバッガーに表示されるコマンド ライン パスワードは何ですか?
回答: FindWindowA を無効にした後、strncmp 関数が呼び出されるとき、OD スタックに表示されるパスワードは byqr です。 - デバッガーで見つかったパスワードは、コマンド ラインから実行するときに有効ですか?
回答: 試してみたところ、byqr が間違ったパスワードであることがわかりました。 - デバッガーとコマンドラインに異なるパスワードを設定するというデバッグ対策テクニック? それらに対してどうやって防御すればよいでしょうか？
回答: 解析の結果、PEB 構造体の OutputDebugString 関数と BeingDebugged フラグがデバッガの検出に使用されていることが判明しました。OutputDebugString の検出処理は、関数呼び出しを nop で上書きするか、デバッガ以降のコードを修正することで解決できます。検出ポイント; BeingDebugged フラグの呼び出し、ああ、OD プラグイン PhantOm が防御を実行します。
Labs-16-03 実験
サンプル: Lab16-03.exe
静的解析:
- シェルを確認してください - シェルがありません
- 入力テーブルを表示します。
KERNEL32.DLL: プロセスの作成と終了、プログラム パスの取得、スリープ、ライブラリ ファイルのロード、ファイルの読み取りと書き込みなど。 SHELL32.DLL:
シェル コマンドの実行
WS2_32.DLL: ネットワーク接続、ネットワーク ドメイン名と IPアドレス解決、ネットワークのプログラムによる初期化。
- 文字列分析により、
文字列「cmd」、「/c del」が検出されました。cmd はファイル削除コマンドを実行するために呼び出される可能性があると推測されます。
- 最初に単純な動的解析を実行し、次に IDA 解析を実行します。
IDA分析
- IDA は分析のためにプログラムを開いたところ、文字列が初期化されていることを発見しました。
- さらに下に進むと、関数 sub_4011E0 呼び出しが見つかりました。そのパラメーターはまさに 2 番目の文字列です。
- 関数 sub_4011E0 に続いて、この関数は主に数学的演算を実行していることがわかり、この関数は入力文字列を暗号化する暗号化関数であると同時に、2 つの QueryPerformanceCounter 関数を呼び出して差分計算を実行し、暗号化に影響を与えていると推測されます。プロセス。
- 同時に例外処理も見つかりましたが、デバッガでの例外処理はシステムの例外処理よりも時間がかかるため、デバッガ内でプログラムが動作しているかどうかの判定にパワーを使っているようです。
- main 関数に戻って続行すると、現在のプログラム名が取得されて検出されることがわかりますが、検出された文字列は暗号化されているため、動的デバッグ中にこの文字列を取得する必要があります。
- OD でプログラムを開き、strncmp 関数の呼び出しポイントでブレークします。プログラムがここで実行された後、スタックを確認します。文字列は "peo.exe" です。名前を付けたプログラムは、名前を "peo.exe" に変更する必要があります。実行を続けます。
- プログラムの名前を変更して再実行し、動的分析を実行したところ、不審なレジストリやファイル操作は見つかりませんでした。
- main 関数から分析を続け、一致が成功するとネットワーク接続が初期化されることがわかります。
- 次に、関数 sub_401000 が 2 つのシステム時間関数の間で呼び出されました。
- 分析のためにこの関数を入力すると、この関数が上記の例外処理を使用してデバッガが存在するかどうかを判断していることがわかります。
- メイン関数に戻って続行すると、関数 sub_401300 が呼び出され、戻り値の 1 つを gethostbyname 関数に渡していることがわかります。
- 関数 sub_401300 に続いて、この関数が同じゼロ除算例外メソッドを使用してデバッガが存在するかどうかを判断していることがわかりました。デバッガが存在する場合は、cmd が呼び出されて自身を削除します。デバッガが見つからない場合は、最初に初期化された文字列「lqbz2wsx3edc」が削除されます。とメモリ 0040604C のデータがパラメータとして計算され、gethostbyname 関数のパラメータ名が取得されます。
- ここで OD から name パラメーター (ドメイン名) を取得し、gethostbyname 関数でそれを中断して、ドメイン名 adg.malwareanalysisbook.com を取得します (まず、上記の例外処理をすべて nop に置き換える必要があります) (1) 最初の
place QueryPerformanceCounter 関数が呼び出されるアドレス 00401271 で、デバッガの存在が検出された場合、変数 var_188 にその下の値 2 が割り当てられます。mov 命令を nop に置き換えます (2) 2 つ目は除算ですアドレス
00401595 より上の -by-zero 例外関数 sub_401000 関数の呼び出しについては、ここの call 命令を nop に置き換えます
(3) システム クロックを取得するために rdtsc 命令が 00401360 で呼び出されます。デバッガが見つかった場合、関数はsub_4010E0 は、以下の 00401380 で呼び出され、自分自身を削除します ここで call 文を置き換えます nop に置き換えると、ここにジャンプした後のコードは引き続き正常に実行されます (4) そして、変更したコードを実行可能ファイルとして OD に保存します
。
(5) OD を使用して新しく保存した実行ファイルを開き、gethostbyname 関数呼び出しで中断し、実行を続けると、悪意のあるドメイン名「adg.malwareanalysisbook.com」が取得されます。
- 以下に進み、接続が正常に確立されたら、リモート コントロール機能が実現されます。リモート コマンドを実行します。
- sub_401060 関数は、C&C が受信したデータから新しいプロセスを作成し、cmd を呼び出してリモート コマンドを実行します。
質問
- 静的分析を使用してこのバイナリを分析すると、どのような文字列が表示されましたか?
回答: 文字列「cmd」、「/c del」が見つかりました。ファイル削除コマンドを実行するために cmd が呼び出された可能性があると推測されます。 - このバイナリを実行すると何が起こるでしょうか?
回答：自動終了 - このバイナリが適切に実行されるように名前を変更するにはどうすればよいですか?
回答: peo.exe に名前を変更します。 - この悪意のあるコードではどのようなデバッグ対策技術が使用されていますか?
回答: 例外処理時間 (アンチデバッグ クロック検出手法) は、デバッガーの存在を検出するために異なります: rdtsc、GetTickCount、および QueryPerformanceCounter - あらゆるアンチデバッグ手法と同様に、悪意のあるコードがデバッガーで実行されていると判断された場合、そのコードはどうするでしょうか?
回答:
rdtsc - デバッガが検出された場合、デバッガ自体を削除します
GetTickCount - デバッガが検出された場合、例外を生成し、プログラムをクラッシュさせます
QueryPerformanceCounter - デバッガが検出された場合、必要な文字列を変更します名前が変更されること。 - この悪意のあるコードに対して、なぜアンチデバッグ技術が成功するのでしょうか?
回答: 悪意のあるコードは SHE メカニズムを変更し、2 つのクロック関数の間で独自の例外処理ルーチンを呼び出して例外をキャッチできるようにするため、デバッガでの例外処理はシステムでの処理よりもはるかに遅くなります。 - 悪意のあるコードに使用されたドメイン名は何ですか?
答え：「adg.malwareanalysisbook.com」