【テクニカル・上級編】 インシデント対応におけるタイムライン分析とイベント相関 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

侵入の足跡を暴く:インシデントフォレンジックにおけるタイムライン分析とイベント相関の極意

インシデントレスポンスの現場において、最初に私たちが直面するのは「静寂」だ。アラートが鳴り響き、C2(Command and Control)通信の兆候やランサムウェアの暗号化が検知された瞬間、そこにあるのは断片的なパニックと、バラバラに散らばったログの山だけである。

「いつ、どこから侵入し、権限を昇格させ、どのデータを盗み出したのか?」

この問いに正確に答えられない限り、どれだけ高価なEDRを導入していこうとも、真の封じ込め(Containment)と根絶(Eradication)を成し遂げることはできない。今回は、攻撃者の足跡を完全に復元するための「タイムライン分析」と「イベント相関」の深層について、オフェンシブセキュリティの視点を交えながら実戦的なアプローチを解説しよう。

—

1. タイムライン分析の最大の敵:「時刻の不整合」と「ログの改ざん」

フォレンジック調査の初期段階で最も時間を奪われるのが、タイムスタンプの正規化だ。異なるシステム間、さらには攻撃者が意図的に操作したタイムスタンプの海から真実の時系列を組み上げるには、OSの低レイヤの挙動を理解している必要がある。

タイムゾーンとエポック秒の罠

多くのインシデントハンドラーは、ログを収集した時点でUTC(協定世界時)への統一を試みる。しかし、Active Directory(AD)ドメインコントローラーのKerberosチケット発行時刻(UTC)、LinuxのSyslog(ローカルタイムまたはUTC)、そしてネットワーク機器のSNMPトラップ(ミリ秒単位の独自エポック)をそのまま並べると、数秒から数時間のズレが生じる。

攻撃者は侵入後、しばしばシステムのタイムスタンプを変更する(Timestomping)。特にNTFSファイルシステムにおいては、MFT(Master File Table)の $STANDARD_INFORMATION 属性と $FILE_NAME 属性のタイムスタンプが不一致を起こす現象を検知することが、フォレンジックの第一歩となる。

—

2. イベント相関のアーキテクチャ設計

バラバラのイベントを「攻撃のキルチェーン(Kill Chain)」として結合するためには、単なるタイムスタンプのソートではなく、セッションIDやプロセスツリーに基づいた相関エンジンが必要となる。

例えば、PowerShellの難読化されたスクリプト実行(Event ID 4104)と、直後の不審な外向き通信(Sysmon Event ID 3)を紐付けるには、ProcessGuid をキーにしたイベント相関が不可欠だ。

以下は、Pythonを用いてWindowsのイベントログ(EVTX)とSysmonログをパースし、親プロセスと子プロセスの関係性から不審なプロセスツリーを抽出するロジックの概念実装である。

import xml.etree.ElementTree as ET
from datetime import datetime

def parse_sysmon_process_creation(xml_content):
    """
    Sysmon Event ID 1 (Process Creation) のXMLログを解析し、
    攻撃者の横展開や初期侵入の兆候となるプロセスツリーを抽出する。
    """
    try:
        root = ET.fromstring(xml_content)
        # Windowsイベントログの標準的な名前空間
        ns = {'def': 'http://schemas.microsoft.com/win/2004/08/events/event'}
        
        event_data = {}
        for data in root.findall('.//def:Data', ns):
            name = data.get('Name')
            if name:
                event_data[name] = data.text

        # 抽出したい重要パラメータ
        record = {
            'UtcTime': event_data.get('UtcTime'),
            'ProcessGuid': event_data.get('ProcessGuid'),
            'ProcessId': event_data.get('ProcessId'),
            'Image': event_data.get('Image'),          # 実行ファイルのパス
            'CommandLine': event_data.get('CommandLine'),# 実行時引数
            'ParentImage': event_data.get('ParentImage'),# 親プロセス
            'User': event_data.get('User')             # 実行ユーザー
        }
        
        return record
    except Exception as e:
        print(f"ログパースエラー: {e}")
        return None

# 悪意ある挙動の検知ロジック例
def detect_suspicious_lateral_movement(process_records):
    """
    WMIやPowerShellを用いた横展開(Lateral Movement)のパターンを相関分析する
    """
    suspicious_indicators = ['wmic.exe', 'powershell.exe -enc', 'cmd.exe /c', 'psexec']
    
    for record in process_records:
        cmd_line = record.get('CommandLine', '').lower()
        parent = record.get('ParentImage', '').lower()
        
        # 例:WMI経由でプロセスを生成している挙動の検知 (WmiPrvSE.exe からのcmd起動など)
        if 'wmiprvse.exe' in parent and ('cmd.exe' in record.get('Image', '').lower() or 'powershell.exe' in record.get('Image', '').lower()):
            print(f"[!] 警告: WMIを通じた不審なプロセス起動を検知!時刻: {record['UtcTime']}")
            print(f"    親プロセス: {parent}")
            print(f"    子プロセス: {record['Image']}")
            print(f"    コマンドライン: {record['CommandLine']}")

# 使用例(モックデータ)
sample_sysmon_xml = """
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <EventData>
    <Data Name="UtcTime">202X-10-27 12:34:56.789</Data>
    <Data Name="ProcessGuid">{12345678-90ab-cdef-1234-567890abcdef}</Data>
    <Data Name="ProcessId">4422</Data>
    <Data Name="Image">C:\\Windows\\System32\\cmd.exe</Data>
    <Data Name="CommandLine">cmd.exe /c whoami &gt; C:\\Temp\\out.txt</Data>
    <Data Name="ParentImage">C:\\Windows\\System32\\wbem\\WmiPrvSE.exe</Data>
    <Data Name="User">NT AUTHORITY\\SYSTEM</Data>
  </EventData>
</Event>
"""

parsed = parse_sysmon_process_creation(sample_sysmon_xml)
if parsed:
    detect_suspicious_lateral_movement([parsed])

—

3. ネットワークパケット(PCAP)とホストログの突合

タイムラインの精度を極限まで高めるには、ホスト内部の挙動(EDR/OSログ)と、ネットワーク境界での通信実態(PCAP)を突き合わせる必要がある。

例えば、攻撃者がカスタムC2フレームワークを使用し、TLS通信の内部で独自の暗号化プロトコルを走らせている場合、ホスト側のメモリダンプやAPI呼び出しの履歴とパケットのシーケンス番号を同期させなければ、正確な侵入経路の特定は不可能だ。

高度なインシデント調査における3つの鉄則

1. タイムスタンプのマスタークロックの特定:
調査対象ネットワーク内のNTP同期状況を最初に監査し、どの機器の時計が正確であるかを定義する。Active Directory環境であれば、PDCエミュレーターの時刻を絶対基準とするのが定石だ。
2. メモリ(RAM)フォレンジックの並行実施:
ストレージ上のログは容易に改ざん・削除されうる。Volatiltyなどのフレームワークを使用し、揮発性メモリ内に残存するネットワークコネクション、隠しプロセス、インジェクションされたDLLのタイムスタンプを抽出せよ。
3. アトリビューション(攻撃者特定)への過度な依存の排除:
インシデント初期対応において最も重要なのは「今、どこが破られているか」の把握であり、犯人が誰であるかの特定ではない。タイムライン分析は、敵の戦術・技術・手順(TTPs)をマッピングするための手段として徹底的に活用すべきである。

—

4. 結びにかえて

インシデント対応におけるタイムライン分析とは、過去のデジタル世界における「考古学」に他ならない。攻撃者が残したわずかな痕跡、MFTの微細な不整合、プロセスツリーの歪みを見逃さない鋭敏な洞察力こそが、セキュリティアーキテクトやチーフホワイトハッカーに求められる本質的なスキルである。

次世代の脅威はさらに巧妙化し、AIによる自動化された侵入や、痕跡を極限まで残さない「Living off the Land(Lolbins)」の手法が主流となる。それに対抗するためには、ログの量を誇るのではなく、精緻な相関ロジックと、低レイヤのOS挙動に裏打ちされた深いアナリティクス能力を組織に定着させることだ。防衛の優位性は、いつだって「細部へのこだわり」の積み重ねの上にしか成り立たない。

コメント

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