mcpField
R
re-behavior

re-behavior

github.com/dslsdzcセキュリティ20650 回インストール2 週間前に更新
リポジトリ

re-behavior について

re-behaviorは、サンドボックスで実行したサンプルを調べる動的マルウェア分析スキルです。プロセス、ファイル、レジストリ、ネットワークの証拠を整理し、観察した挙動をMITRE ATT&CKに対応付けます。

主な機能

  1. 01プロセスツリーとインジェクションの分析
  2. 02永続化箇所の確認
  3. 03ファイルとレジストリ操作の記録
  4. 04ネットワークとC2の特徴特定
  5. 05MITRE ATT&CK戦術への対応付け

活用シーン

  1. 01サンプル実行後のシステム変更の調査
  2. 02インジェクションと永続化手法の特定
  3. 03ネットワーク活動からのC2手掛かりの検出
  4. 04ATT&CK対応付けに向けた挙動証拠の整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/dslsdzc/rev-skills --skill re-behavior

インストール後、Claude Code で/re-behaviorを入力して読み込まれたか確認します。

詳細

悪意動作の分析

使用する場合/使用しない場合

  • 使用する場合:サンプルが「何をしているか」を判定する場合——実行後のプロセス/ファイル/レジストリ/ネットワークの動作、永続化とインジェクションの識別、ATT&CK 戦術へのマッピング
  • 使用する場合:動的解析の証拠収集段階([[re-tracing]] と相互補完)
  • 使用しない場合:サンプルがまだサンドボックスで実行されていない場合(まず [[re-sandbox]] を実施してください——動的実行は必須の前提条件です。[[re-analyze/platform-tips]] の最優先原則を参照してください)
  • 使用しない場合:静的な結論のみが必要な場合([[re-triage]]/[[re-binary-core]] ドメインを利用してください)、メモリ内容のみが必要な場合([[re-memdump]] を利用してください)

ツールの準備

このスキルではサンドボックスの実行成果物を分析します。実行環境は事前に [[re-sandbox]] で構築します(サンドボックスのデフォルトに関する最優先原則は [[re-analyze/platform-tips]] を参照してください)。

サンドボックスの成果物(実行環境の前提条件)
  • [[re-sandbox]] で構築:VM スナップショット/コンテナ/firejail + ネットワーク分離(INetSim/fake DNS/ネットワーク切断)
  • 成果物には、動作ログ、プロセスのスナップショット、INetSim のネットワーク記録、メモリダンプ([[re-memdump]])が含まれます
  • 確認:サンドボックス内でサンプルが [[re-sandbox]] の手順に従って実行され、ログが生成されていること
procmon / Process Monitor(Windows の動作記録の主力)
  • Windows:Microsoft Sysinternals —— choco install sysinternals、または Microsoft の公式サイトから Procmon64.exe をダウンロードします
  • Linux/macOS:非対応です(sysdig / bpftrace を使用してください。関数レベルの記録については [[re-tracing]] を参照してください)
  • 確認:管理者として Procmon64.exe を実行し、キャプチャ画面が表示され、イベントを記録できること
  • 追加ツール:Process Explorer(同じスイートに含まれます)でプロセスツリーとハンドルを確認します
sysdig(Linux のシステム動作の追跡)
  • Linux:apt install sysdig / dnf install sysdig / pacman -S sysdig
  • macOS/Windows:非対応です(Linux 専用)。WSL 内では Linux 版を使用できます(root が必要です)
  • 確認:sysdig --version;sysdig -c topprocs_cpu で出力が得られること
  • よく使う方法:sysdig proc.name=target -w out.scap で記録し、後から sysdig -r out.scap で再生します
bpftrace(Linux のカーネルレベル追跡、低オーバーヘッド)
  • Linux:apt install bpftrace / dnf install bpftrace / pacman -S bpftrace
  • カーネルの BTF/トレース機能が必要です。macOS/Windows には対応していません
  • 確認:bpftrace --version;sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { print(comm) }' で出力が得られること
  • 用途:ファイル書き込み、プロセス起動、ネットワーク接続など、高頻度のイベントをユーザー空間の監視より軽量に記録します
MITRE ATT&CK のナビゲーション
Windows/Linux の組み込みコマンド(永続化/ネットワークの確認、インストール不要)
  • Windows:reg query、sc query、schtasks /query /fo csv、netstat -ano、Get-CimInstance Win32_StartupCommand
  • Linux:ps -ef --forest、ss -tnp、cat /etc/crontab、systemctl list-unit-files --state=enabled
  • 確認:各コマンドが正常に出力されること

操作手順

順番に実行し、各手順の結果を記録して証拠(パス+sha256)を保存します。

  1. プロセスツリーとインジェクションの特定:

    • Windows(サンドボックス内で procmon を記録しながらサンプルを実行):Process Name = サンプルでフィルターし、Process Explorer の Tree ビューでプロセスツリーを確認します——子プロセス、ディスクへの書き込み後に新たに起動したプロセス(dropper → payload の 2 段階)
    • インジェクションの特徴的なシーケンス(procmon / sysdig で API をフィルター):
      • DLL インジェクション: OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread(対象プロセスへの書き込み+新しいスレッド)
      • プロセスホローイング: CreateProcess(SUSPENDED) → NtUnmapViewOfSection → WriteProcessMemory → SetThreadContext → ResumeThread
      • APC インジェクション: OpenThread → QueueUserAPC → ResumeThread
    • Linux: sysdig proc.name=target で execve/clone のシーケンスを確認し、ps -ef --forest でプロセスツリーを確認します
    • 結果の記録:インジェクション対象、インジェクション手法、インジェクションされたプロセスの PID
  2. 永続化のチェックリスト(スケジュールされたタスク/WMI は見落とされがちです。落とし穴 3 を参照):

    • Windows:
      reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
      reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
      sc query state= all
      schtasks /query /fo csv
      
      WMI による永続化(最も見つかりにくい):Get-CimInstance -Namespace root\subscription -ClassName __EventConsumer(ActiveScriptEventConsumer / CommandLineEventConsumer はよく使われる悪意ある要素です)
    • Linux: cat /etc/crontab、ls /etc/cron.d /etc/cron.daily、systemctl list-unit-files --state=enabled、/etc/rc.local、/etc/profile.d/*、~/.bashrc
    • 項目ごとに記録:場所、コマンド/パス、サンプルとの関連性
  3. ファイルとレジストリの操作:

    • Windows: procmon で Operation = CreateFile / WriteFile / RegSetValue / RegCreateKey、プロセス = サンプルを条件にフィルターします。%APPDATA%、%TEMP%、%ProgramData%、Startup フォルダーを重点的に確認します
    • Linux: sysdig -c spy_file proc.name=target(ファイルの読み書き)を使用します。関数レベルの呼び出しは [[re-tracing]] の strace で補完します
    • 記録した項目はすべて潜在的な IOC として扱います(設定の書き込み先パス、ダウンロードされたファイルなど)——[[re-ioc]] で使用します
  4. ネットワーク接続と C2 の特徴:

    • Windows: netstat -ano を procmon のネットワークイベントと照合します。サンドボックスの DNS はすでに INetSim を指しています([[re-sandbox]] 手順 2)——INetSim のログにある DNS クエリは C2 ドメインの直接的な証拠です
    • Linux: ss -tnp、sysdig fd.type=ipv4 proc.name=target
    • C2 の特徴のチェックリスト:通常とは異なるポート(>1024 または 443/53 に偽装)、周期的なハートビート(一定間隔の短時間接続)、DNS トンネリング(長くランダムなサブドメイン)、異常な User-Agent、証明書が一致しない未知の IP への HTTPS 通信
    • C2 を発見した場合 → トラフィックの詳細を [[re-protocol]]([[re-netcap]] / [[re-proto-rev]] / [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]])に引き継ぎます
  5. ATT&CK 戦術へのマッピング:

    • 手順 1~4 の挙動を ATT&CK 戦術に分類します:初期アクセス、実行、永続化(T1547 / T1053 / T1543)、防御回避(T1055 インジェクション)、コマンド&コントロール(T1071 / T1568)…
    • 各挙動について「挙動 → 戦術:技術 (ATT&CK ID) → 証拠のパス」の形式で 1 行ずつ記述し、マッピング表にまとめてレポートに含めます([[re-ioc]] のレポート構成で使用します)

挙動監視ツールチェーン(Windows)

Windows 側の挙動収集に使う 4 つのツール:ProcMon(システム全体のファイル/レジストリ/ネットワーク/プロセス)、API Monitor(API レベルの hook)、ETW(カーネル側のイベント)、Process Explorer(リアルタイムのプロセスビュー)。前者 2 つはユーザーランドで収集し、ETW はカーネル側で収集します。この節では収集側の視点を扱い、[[re-evasion]] の回避側を補完します。特に記載がない限り、いずれも Windows 専用ツールです。Linux/macOS では、[[re-tracing]](strace/ltrace/dtruss)と、このファイルの「ツールの準備」にある sysdig/bpftrace を使用します。

ProcMon:フィルター → 注釈 → CSV エクスポート
  • フィルター(Filter ダイアログ、Ctrl+L):ルール = 列 + 条件 + 値。複数の条件を重ねられます。列は Process Name / Operation / Path / Result / PID などを選択できます。条件には is / is not / contains / does not contain / begins with / ends with / less than / more than / excludes などがあります(数値列では大小比較を使用します)。イベントを右クリックすると、ルールをすばやく作成できます(Add to Include filter / Add process and children to Include filter)
  • フィルターは非破壊的です:一致しないイベントもデータベースに保存されますが、表示されないだけです。Drop Filtered Events にチェックを入れた場合にのみ破棄されます(超高頻度のキャプチャでサイズを抑えるために使用しますが、復元できません——完全な証拠チェーンが必要な場合はチェックしないでください)
  • 注釈:Include ルールで注目するイベントを黄色にハイライトし、Highlight(Ctrl+H)でハイライト色をカスタマイズします。Exclude は除外対象をグレー表示します——「ハイライト=重要、グレー表示=ノイズ」として階層的に確認できます
  • CSV エクスポート:File → Save(Ctrl+S)ダイアログで CSV 形式を選択し、範囲に Events displayed using current filter を選択します(先にフィルターしてからエクスポートし、データ量を抑えます)。一括変換にはコマンドライン Procmon64.exe /OpenLog trace.pml /SaveAs out.csv を使用します。ネイティブの PML にはすべてのフィールドとスレッドスタックが保持されるため、別のマシンで調査を再現できます
  • タイムラインの関連付け:Time of Day で並べ替え、Process Create / CreateFile / WriteFile / RegSetValue / TCP-UDP Send-Receive を揃えて、「プロセス → ファイル → レジストリ → ネットワーク」の証拠チェーンを作成します(操作手順 1~4 に対応)。Process Tree ツール(Ctrl+T)でプロセスの親子関係とインジェクションの流れを確認します
  • イベントのプロパティにある Stack タブでは、スレッドのコールスタックを確認できます(シンボルサーバーを設定可能)。インジェクション/永続化 API のシーケンスを検証します(手順 1 および落とし穴 5~7 の実証)
API Monitor:API レベルの hook チェーン
  • 概要:インポートテーブル hook を使ってプロセス内の API 呼び出しをフックし、呼び出しごとに引数(文字列はデコード済み)と戻り値を記録します。呼び出しツリーにはネストされた階層が表示されます——Windows 側では [[re-tracing]] の strace/ltrace に相当します
  • 使い方:管理者として実行 → 対象プロセスを選択 → API クラス(File / Network / Registry / Process / Thread)にチェックを入れる → アタッチします。呼び出しツリーを展開して重要な API(CreateProcess / WriteProcessMemory / RegSetValue / NtWriteFile)の引数の実際の値を確認します
  • ビット数の制限(よくある落とし穴):32 ビット版で監視できるのは 32 ビットプロセスのみで、64 ビット版で監視できるのは 64 ビットプロセスのみです——サンプルのビット数に応じて apimonitor-x86.exe / apimonitor-x64.exe を選択します
  • インストール:公式配布元 rohitab.com(フリーウェア、v2 alpha、zip を解凍するだけで使用可能)。サイトにアクセスできないことがまれにあるため、圧縮ファイルを入手したら、まずチェックサムを確認します
  • 検証:対象プロセスにアタッチした後、呼び出しツリーが表示され、引数と戻り値が記録されることを確認します
ETW:カーネル側のイベント収集(logman / wevtutil)
  • 位置づけ:Windows 組み込みのイベントフレームワークです。セッションの作成とイベントの解析にはシステム標準のコマンド(logman / wevtutil / tracerpt)を使用するため、インストールは不要です。カーネル側の収集はユーザー空間のフックの影響を受けません。syscall を直接通過するインジェクション(落とし穴 8)は、カーネル側のイベントでのみ補完できます。

  • セッションの作成(管理者権限が必要):

    logman create trace bhev -p Microsoft-Windows-Kernel-Process 0x10 -o bhev.etl -ets
    logman stop bhev -ets
    logman delete bhev -ets
    

    -p はプロバイダー(名前または GUID)を指定し、キーワードとレベルも指定できます(例:-p Microsoft-Windows-Sysmon 0xFF 5)。カーネルプロバイダーではキーワードを明示する必要があります。Kernel-Process の 0x10 はプロセスキーワード、0x20/0x40 はスレッド/イメージキーワードです。指定しないとイベントが一切収集されないままになる場合があります。アクティブなセッションは logman query -ets で確認できます。登録済みプロバイダーは logman query providers で列挙できます(パイプで findstr を使って対象を絞り込みます)。

  • よく使うプロバイダー:Microsoft-Windows-Kernel-Process(プロセスの作成/終了)、Microsoft-Windows-PowerShell(スクリプトブロック)、Microsoft-Windows-Sysmon(Sysmon がインストールされている場合は、そのイベントをそのまま利用します)

  • イベントの解析:.etl を CSV に変換するには tracerpt bhev.etl -o out.csv -of csv を実行します。イベントログには wevtutil を使用します:

    wevtutil qe Security /q:"*[System[(EventID=4688)]]" /c:10 /rd:true /f:text
    wevtutil el
    wevtutil epl Security C:\secevt.evtx
    

    /q は XPath フィルター、/c は件数の上限、/rd:true は新しい順、/f:xml|text は出力形式を指定します。

  • re-evasion との相互補完:この節は収集側です。回避側(ETW の無効化と検出)については [[re-evasion]] を参照してください。

Process Explorer:リアルタイムのプロセス表示
  • プロセスツリー:View → Show Process Tree(Ctrl+T)で表示します。親子関係を確認でき、終了したプロセスはグレー表示で保持されます。ProcMon の Process Tree ツールと相互補完します(PE はリアルタイム表示、ProcMon は記録の再確認に使用します)。
  • 下部ペイン:Handles(Ctrl+H)ではプロセスが開いているハンドル(ファイル/レジストリ/ネットワークオブジェクト)を確認でき、DLLs(Ctrl+D)ではロード済みモジュールとマッピングを確認できます。インジェクション DLL が配置されているか、削除されたファイルをどのプロセスが保持しているかを調べます。Hide Lower Pane(Ctrl+L)で閉じます。
  • Find Handle or DLL(Ctrl+F):ファイル/パス/キーから保持しているプロセスを逆引きします。特定のパスを読み書きしているプロセスを探すのに使います。
  • 署名の検証:Options → Verify Image Signatures を有効にすると、プロセス一覧に Verified Signer 列が表示されます。プロセスのプロパティの Image ページにある Verify ボタンで個別に確認できます。システムの正規モジュールと疑わしいインジェクションモジュールをすばやく区別できます(署名の欠如/無効は警告の対象となるため、手順 1 と組み合わせてください)。
OS をまたぐ際の制約
  • 上記のツール(ProcMon / API Monitor / Process Explorer / logman-wevtutil)は、すべて Windows 組み込みまたは Windows 専用です。Linux/macOS では [[re-tracing]](strace/ltrace/dtruss)と「ツールの準備」にある sysdig / bpftrace を使用します。
  • 例外:ProcMon には Microsoft 公式の Linux 移植版(ProcMon-for-Linux、GitHub の microsoft リポジトリ、preview、システムコールレベル、eBPF 系)があります。実験的なため、正式な分析では引き続き sysdig/bpftrace を主に使用します。

ドメイン横断の連携

  • [[re-malware]]:ワークフローのステップ 3。振る舞い分析は悪意のあるサンプルを判定する中心的な工程です。
  • [[re-sandbox]]:このスキルの実行と再実行はすべてサンドボックス内で行う必要があります(必須の前提条件)。
  • [[re-protocol]]:ステップ 4 で C2 が見つかった場合は、トラフィックキャプチャ/プロトコル再構築に移ります。
  • [[re-anti-analysis]]:異常な振る舞い(遅延/インタラクションチェック、サンドボックス検出後の終了)が見られた場合は、アンチ解析対策のドメインに移ります。
  • [[re-tracing]]:Linux では strace 系を使い、sysdig/bpftrace の関数レベルの呼び出し記録を補完します。
  • [[re-evasion]]:ETW の収集側(「振る舞い監視ツールチェーン」の節)と回避側は相互補完の関係です。イベントストリームの中断は、無効化の証拠になります。
  • [[re-ioc]]:ステップ 3/4 で得られる振る舞いの証拠は、IOC の抽出とレポート作成の材料になります。

常见坑与陷阱

  • 行为被沙箱检测绕过:现象——样本在沙箱里只做无害行为或什么都不做,换真实机才发作;原因——沙箱检测(VM 特征、交互检查、延迟触发,见 [[re-sandbox]] 坑 4 与 [[re-anti-analysis]] 域);对策——延长观察窗口(数小时~数天)、伪造交互(输入/鼠标事件)、配合 [[re-sandbox]] 的 INetSim 完整网络、必要时用 [[re-anti-analysis]] 静态还原触发条件
  • 只看进程树漏注入:现象——进程树里只有样本自身,但恶意行为发生在别的进程里;原因——注入型样本自进程表现无害,恶意逻辑在宿主进程执行;对策——必须查注入特征序列(步骤 1 的 API 序列),行为证据以被注入目标进程的内存与模块为准
  • 持久化藏于计划任务/WMI 常被忽略:现象——重启后样本复活,Run 键/服务里查不到;原因——攻击者优先用计划任务(schtasks)与 WMI 事件订阅做持久化,常规检查覆盖不到;对策——持久化清单必须包含 schtasks /query 与 WMI __EventConsumer 查询(步骤 2),逐项核对创建时间与命令内容
  • 隐藏的计划任务常规查询查不到:现象——schtasks /query 与任务计划 GUI 都看不到任务,重启后样本仍复活;原因——攻击者删除任务的安全描述符(SD)注册表值或篡改 Index 元数据,任务从常规查询中隐藏;对策——直接检查 C:\Windows\System32\Tasks\*.xml 与注册表 HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache,SD 缺失即告警
  • 注入检测看系统侧信号,不只盯 API 序列:现象——进程树无异常、API 序列未捕获,注入却已发生;原因——注入目标多为受信任系统进程,API 监控被绕过或覆盖不到;对策——配合 Sysmon 事件:8(CreateRemoteThread)、10(ProcessAccess 带 PROCESS_VM_WRITE/PROCESS_VM_OPERATION/PROCESS_CREATE_THREAD)、7(异常路径 ImageLoaded)、25(ProcessTampering,内存镜像与磁盘不一致=空洞化);空洞化样本用 PE-sieve/Hollows Hunter 扫描(内存 PE 头与磁盘不匹配)
  • 持久化位置超出 Run 键/服务:现象——Run 键与服务清单干净,登录/启动后样本仍执行;原因——攻击者用 Winlogon Userinit、AppInit_DLLs、IFEO、COM 劫持、服务失败恢复"Run a Program"等位置(Autoruns 扫描 18+ 类 ASEP);对策——持久化清单补全上述位置(步骤 2),逐项核对路径、签名与创建时间
  • KernelCallbackTable 注入(回调表重定向):现象——进程树正常、常规注入 API 序列(OpenProcess→VirtualAllocEx→WriteProcessMemory→CreateRemoteThread)一条都抓不到,注入却已发生;原因——攻击者克隆 PEB 的 KernelCallbackTable 并把某回调(如 __fnCOPYDATA)重定向到载荷,用窗口消息(WM_COPYDATA)触发,执行借合法进程身份隐藏(ATT&CK T1574.013,Lazarus/FinFisher 在用,有现成 Sigma 检测规则);对策——API 序列之外补查回调表指针指向与回调函数地址(dt _PEB KernelCallbackTable)、Sysmon 10 对目标进程的写入事件,配合 T1574.013 Sigma 规则与内存扫描
  • 直接/间接系统调用注入(直通 syscall):现象——procmon/API Monitor 等用户态 hook 监控不可见;Sysmon 10/25 等内核 ETW 事件仍可捕获,注入却已发生;原因——DirectSyscalls/IndirectSyscalls 不经 ntdll 用户态导出(或借合法模块做跳板)直发系统调用,绕掉安全产品的用户态 hook;对策——监控降级到内核侧(ETW、Sysmon 25 进程篡改、内核驱动级事件),别只依赖用户态 API 事件
  • Linux 侧注入监控盲区:现象——Linux 样本 ps -ef --forest 进程树正常、sysdig 无异常 execve,恶意代码已在目标进程里跑;原因——Linux 注入不落盘:process_vm_writev 无痕写目标内存、攻击者读 /proc/<pid>/syscall 拿目标 RSP 后在栈上构造 ROP 调 dlopen(DD 面向对象注入 PoC 公开于 2024)、LD_PRELOAD 在监控启动前已注入;对策——审计 /etc/ld.so.preload(auditd 规则盯其写入),audit 记录 process_vm_writev/process_vm_readv/ptrace 调用,对比磁盘文件与 /proc/<pid>/maps 映射来源一致性

コメント