Instiq
第3章 · ホストベース分析·v1.0.0·更新 2026/7/20·読了目安 約16分

変更要約: 初版

3.2OS構成要素の識別(Windows/Linux)

この節の要点

調査シナリオで意味を持つWindowsの構成要素(プロセス/サービスレジストリイベントログスケジュールタスクtasklist/netstat)とLinuxの構成要素(プロセス/デーモンsystemd/etc 設定・/var/log ログ・cronps)を対応づけ、「この痕跡はどのOSのどこを見れば分かるか」という調査判断として学びます。

ホストの侵害を調べるとき、「どこを見れば実行中のプロセス・自動起動の仕掛け・設定変更・履歴が分かるか」をOSごとに即答できることが、調査の速さを決めます。WindowsとLinuxは思想も名前も違いますが、「プロセス」「サービス/デーモン」「永続化(自動起動)」「設定」「ログ」という機能の対応を押さえれば、片方の知識をもう片方に写像できます。この節は用語の暗記ではなく、痕跡の在りかを両OSで対応づけることを目標にします。

3.2.1Windowsの構成要素

  • プロセスとサービス=実行中プログラムは tasklist やタスクマネージャで、常駐するサービスservices.msc/sc query で確認する。不審な親子関係(例:winword.exe の子に cmd.exe/powershell.exe)は侵害の手掛かり。開いている通信は netstat -ano でPIDと紐づけて追える。
  • レジストリ=OSとアプリの設定を階層的に保持するデータベース。マルウェアは自動起動のために HKLM\...\Run/HKCU\...\Run などのRunキーに登録することが多く、永続化の主要な痕跡になる。
  • イベントログとスケジュールタスクイベントビューアSystem/Application/Security の各ログを保持し、Security ログはログオン/権限使用(例:イベントID 4624ログオン成功、4625失敗)を記録する。定期実行のスケジュールタスクschtasks/Task Scheduler)も永続化に悪用される。

3.2.2Linuxの構成要素

  • プロセスとデーモン=実行中プロセスは ps aux/top で、常駐サービス(デーモン)は多くのディストリで systemdsystemctl status)が管理する。開いている通信とプロセスの対応は ss -tulpn(旧 netstat)で確認する。/proc/<PID> から実行ファイルや起動引数を辿れる。
  • 設定と永続化=システム/サービスの設定は主に /etc 配下のテキストファイル(例:/etc/passwd/etc/ssh/sshd_config)にある。定期実行は croncrontab -l/etc/cron.*)や systemdタイマ/ユニットが担い、これらは永続化の悪用先になる。
  • ログ=多くは /var/log 配下のテキスト。認証は /var/log/auth.log(Debian系)や /var/log/secure(RHEL系)、一般は /var/log/syslog//var/log/messagesjournalctlsystemd ジャーナルを横断検索でき、last/lastb はログイン履歴を示す。
試験ポイント

「Windows:プロセス=tasklist、通信=netstat -ano、永続化=RunキーとスケジュールタスクとSecurityイベントログ(4624/4625)」「Linux:プロセス=ps/top、通信=ss、常駐=systemd/デーモン、設定=/etc、ログ=/var/log(auth.log/secure・syslog/messages)、定期=cron」が頻出です。機能の対応(プロセス/サービス/永続化/設定/ログ)でWindows⇔Linuxを写像できるように練習しましょう。

あなたは、外部C2への定期的な接続がNetFlowで見つかった2台のホスト——Windowsサーバ1台とLinuxサーバ1台——を並行して調べています。C2は「毎日同じ時刻に短時間だけ発生」しており、これはスケジュールされた永続化の典型です。ここで「両OSとも同じ場所を見ればよい」と考えるのは誤りで、機能は同じでも見る場所がOSごとに違うことを押さえるのが調査判断の要です。Windows側では、まず tasklistnetstat -ano で当該時刻に外部接続を持つプロセスのPIDを特定し、その実体がスケジュールタスクschtasks /query)から起動されていないか、そして自動起動のRunキーHKCU/HKLM\...\Run)に不審なエントリが無いかを確認します。さらに Security イベントログでその時刻のログオン(4624)や権限使用を突き合わせます。Linux側では、同じ「毎日同時刻」という手掛かりから真っ先に crontab -l/etc/cron.*、および systemd のタイマ(systemctl list-timers)を確認し、ps aux/ss -tulpn で接続元プロセスを、/var/log/auth.log(または /var/log/secure)で不審な認証を辿ります。もし「WindowsだからLinuxの /var/log を探す」「LinuxなのにレジストリのRunキーを探す」といったOSの取り違えをすれば、痕跡はそこに無く時間を浪費します。要は、「定期実行の永続化」という同じ攻撃概念を、Windowsならタスク/Runキー/Securityログ、LinZならcron/systemd timer/auth.logという「そのOSの実装」に翻訳して探す——この写像ができることが、両OS混在環境での調査速度を決めます。

機能WindowsLinux調査での意味
実行中プロセス`tasklist`/タスクマネージャ`ps aux`/`top`不審な親子関係・引数を確認
通信とPIDの対応`netstat -ano``ss -tulpn`外部接続の主体プロセスを特定
永続化(自動起動)Runキー・スケジュールタスク`cron`・`systemd` タイマ/ユニット定期C2・再起動後の生存を疑う
設定レジストリ`/etc` 配下のファイル改ざんされた設定を突き止める
ログイベントログ(Security 4624/4625)`/var/log`(auth.log/secure)ログオン/認証の異常を追う
注意

ひっかけ: 「Linuxホストの自動起動マルウェアはWindowsレジストリのRunキーを調べれば分かる」は誤りです——レジストリはWindows固有で、Linuxの永続化は cron/systemd タイマや /etc 配下、~/.bashrc 等を見ます。逆に「Windowsの認証失敗は /var/log/auth.log にある」も誤り=Windowsの認証はSecurityイベントログ(失敗=4625)に記録されます。機能は同じでもOSごとに在りかが違う点に注意。

Windowsのレジストリ/イベントログとLinuxのsystemd/var-logの対応図。
この痕跡はどのOSのどこで分かるか

3.2.3この節のまとめ

  • プロセス/通信はWindows=tasklist/netstat -anoLinux=ps/ssで特定し、不審な親子関係や外部接続の主体を追う
  • 永続化はWindows=Runキー/スケジュールタスクLinux=cron/systemdタイマ——定期C2や再起動後の生存を疑ったらここを見る
  • 設定/ログはWindows=レジストリ/イベントログ(Security 4624・4625)Linux=/etc//var/log(auth.log・secure)。機能は同じでも在りかがOSで違う

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. NetFlowで、あるWindowsサーバが毎日ほぼ同一時刻に短時間だけ外部C2へ接続していることが判明した。この定期的な永続化の仕掛けを特定するために最初に確認すべきWindows構成要素として最も適切なものはどれか。

Q2. Linuxサーバで、外部への不審な接続を維持しているプロセスのPIDと実行ファイルを特定したい。用いるコマンドの組み合わせとして最も適切なものはどれか。

Q3. ある業務時間外に、あるアカウントで繰り返しログオンに失敗し、その後成功した形跡があるWindowsホストを調べている。このログオン/認証の異常を追うために参照すべきログとして最も適切なものはどれか。

理解度を確認第3章「ホストベース分析」の問題を解く