ガイドSC

Windows・Linux認証ログとSSH・sudo・永続化の調査

公開: 2026-09-26更新: 2026-09-26
WindowsイベントとLinux認証記録を時系列にし、SSH、sudo、サービスアカウント、ファイル権限と永続化を判断する。

運用端末WS-41からLinuxサーバLX-1へSSH接続した直後、sudoでsystemdサービスが追加された。同じ時間帯にWindowsサーバFS-1にも新しいサービスが作られた。イベントIDやログファイル名だけを暗記しても、誰が認証し、どの権限で何を変えたかは分からない。WindowsとLinuxの観測点、記録の欠落、永続化の証拠を一つの時系列にする。

読む順序は、用語→実際の構成と処理→記録の照合→異常の成立条件→変更・復旧→短答演習です。以下の組織、アドレス、時刻、識別子、ログは教材用の架空例です。観測できた事実と、追加調査が必要な推論を分けて読みます。

1. 用語をこの事案の判断に結び付ける

用語

意味とこの事案での判断の限界

Windowsイベントログ

Security、System、アプリ等のチャネルに認証・プロセス・サービスの記録を残す。監査ポリシーが無効なイベントは発生しても記録されない。

4624 / 4625

Windowsのログオン成功・失敗イベント。LogonType、認証方式、送信元、Logon IDを読み、同一セッションの後続操作へつなぐ。

4688 / 7045

4688は監査設定時のプロセス作成、7045はサービスのインストールを示すSystem側のイベント。サービス作成と実行成功は別。

SSH

Linuxなどへの暗号化された遠隔接続。鍵認証かパスワード認証か、接続元、ユーザー、公開鍵、サーバ側の受入れを確認する。

sudo

許可された利用者が指定コマンドを別権限で実行する仕組み。SSHログイン成功はsudo成功やroot操作の証拠ではない。

サービスアカウント

常駐プロセスやバッチに使うID。人間の共有ログインと混ぜず、権限、ログイン禁止、秘密更新、依存サービスを管理する。

ファイル権限

所有者、グループ、mode/ACLが読み書き実行を決める。`chmod 777`で一時的に動いても全利用者への書込みを許し、永続化の入口になり得る。

永続化

再起動やログアウト後も実行が続く設定。Windowsサービス、スケジュールタスク、Linuxのsystemd unit、cron、SSH authorized_keys等が候補。

journal / auth.log

systemd journalやディストリビューションごとの認証ログ。保存場所・保持期間・転送設定が異なるので、特定ファイルの不存在をイベント不存在としない。

2. 構成と判断する位置

架空のA社ではWS-41が管理者端末、FS-1はWindows共有、LX-1はLinux帳票サーバ。adm-opsがSSH鍵でLX-1へ接続し、sudoでreport-sync.serviceを配置した。一方FS-1にはC:\Temp\sync.exeを指すサービスが登録された。両方に同じ名称があるが、作業票CHG-41はLX-1の更新だけを承認し、FS-1への作業は記載していない。WS-41の端末健全性と同じ人による操作かを調べる。

端末から二つのOSへの操作認証先と変更対象のログをそれぞれ確認する。操作元サーバ証拠1234WS-41LX-1FS-1journalEvent Log
端末から二つのOSへの操作
  1. 1. SSH
  2. 2. Windows管理
  3. 3. sshd・sudo
  4. 4. 4624・7045

認証先と変更対象のログをそれぞれ確認する。

WS-41からの接続元ログだけでは受入れ側の認証成否や変更内容は分からない。LX-1とFS-1で独立にログを取り、時刻差、IP再割当て、アカウント名の同一性を確認する。ログ収集先の保持と改ざん耐性も調べる。

3. 正常時の処理と管理

  1. WindowsではSecurity/Systemの監査ポリシーとイベント保存期間、Linuxではjournald/rsyslogの保存・転送設定を事前に把握する。

  2. SSH公開鍵とsudoersの許可範囲を定義し、サービスアカウントの対話ログインを必要最小限にする。秘密と権限を担当者ごとに分ける。

  3. 変更作業には作業票、接続元、対象、実施コマンド、ファイル差分、再起動、ロールバックを対応付ける。

  4. SSH受入れ、sudo実行、ファイル更新、systemdのreload・起動、サービスの実動作を別々に確認する。

  5. Windows側もログオン、プロセス、サービス登録、サービス実行、外向き通信を連結し、認証だけで実行を断定しない。

sudoログは『コマンドを実行しようとした』記録として有用だが、コマンド内部がどのファイルをどう変更したかは別の記録が要る。systemd unitの配置とenable、startも別の状態である。

4. 設定・記録のフィールドを読む

項目

読み方と注意点

4624 LogonType / Logon ID

Windowsのログオン方式と同一セッション識別子。Type 3はネットワークログオンだが、何を操作したかは後続ログで確認する。

4688 process / parent

プロセス作成と親、コマンドライン。監査設定次第で引数が欠けるため、未記録ならEDR等を照合する。

7045 service / path

新しいWindowsサービス名と実行ファイルパス。登録だけで実行・悪性を断定しない。

sshd Accepted / Failed

Linuxの受入れ・拒否、利用者、送信元、方式。鍵指紋のログは設定に依存し、同一IDでも鍵が複数あり得る。

sudo USER / COMMAND

誰がどの権限で何を要求したか。成功・失敗、TTY、作業票、ファイル差分を結ぶ。

unit ExecStart / enabled

systemd unitの実行先と起動設定。ファイルの所有者、書込み権限、実体のハッシュを確認する。

owner / mode / ACL

ファイルを変更できる主体。全員書込みやサービス実行者によるunit編集は永続化の危険を増す。

以下は架空のWindows・Linuxログを簡略化した。syslogの書式やWindows Eventの内容は製品と監査設定で変わる。

text
09:00 LX-1 sshd Accepted publickey for adm-ops from WS-41
09:03 LX-1 sudo user=adm-ops as=root
  cmd=install report-sync.service result=success
09:04 LX-1 systemd unit=report-sync enabled=true
09:06 FS-1 event=4624 type=3 user=adm-ops src=WS-41
09:08 FS-1 event=7045 service=report-sync
  path=C:\Temp\sync.exe
09:09 FS-1 service=report-sync state=running

LX-1の変更は作業票の範囲かもしれないが、unitの実体・差分とsudo実行結果を確認する。FS-1のサービス登録・実行は作業票外であり優先調査対象。両方のログにadm-opsが出ても、同一人物が操作したとは確定しない。WS-41のプロセス、セッション、資格情報の利用を調べる。

5. 異常が成立する条件と証拠

状態・攻撃

成立条件、証拠、対策の位置

SSH鍵の悪用

authorized_keysに不審な鍵が追加されると再接続経路になる。追加時刻、所有者、鍵指紋、ログイン履歴を照合する。

sudoersの過大権限

特定バイナリの許可がシェル実行や任意ファイル編集につながる場合がある。実際の許可規則とコマンド経路を調べる。

systemd永続化

unitがenableされ再起動後に動く可能性。ExecStartと環境ファイル、書込み権限、実行時ログを確認する。

Windowsサービス永続化

7045で登録され自動起動なら継続実行し得る。実行ファイル、署名、作成者、起動時刻を調べる。

サービスID共有

複数人が同じサービスIDでログインすると個人特定が困難。対話ログイン制限と個別管理IDを使う。

権限緩和

unitや実行ファイルが全員書込みなら、権限の低い利用者が次回起動コードを差し替え得る。ファイル権限と変更履歴を調べる。

`sshd Accepted`はLX-1への認証成功、`sudo`は権限変更したコマンドの試行・実行、`systemd enabled`は将来の起動設定を示す。これらを一つの『侵害成功』イベントとして扱わず、それぞれの前提と後続結果を確認する。

6. 調査で結論を強くする順序

判定段階

必要な証拠と結論の上限

誰が入ったか

SSH鍵・アカウント、Windows Logon ID、端末、MFA、作業票を照合。共有IDなら個人断定を避ける。

何を実行したか

sudo、4688、EDR、シェル履歴の限界を確認し、ファイル・サービス差分を調べる。

永続化したか

unit/サービスの登録、enable、自動起動、実行ファイル、再起動後の動作を分ける。

何が許したか

sudoers、Windows管理者権限、ファイルACL、サービスID権限を確認する。

安全に戻ったか

不正設定削除、秘密更新、正規サービスの動作、再起動試験、監視を確認する。

Windowsの4624はログオン成功を示すが、LogonType 3の一件だけで遠隔実行やファイル改ざんを示さない。7045はサービス登録、4688はプロセス作成であり、別チャネルに分かれる。Logon ID、時刻、プロセス、サービス名を結び、監査が有効だった範囲を明示する。

Linuxの認証ログはディストリビューションや設定によって/var/log/auth.log、/var/log/secure、journal等に残る。journalctlの結果が空でも、保持期間、揮発性保存、フィルタ条件、別ファイルへの転送を確認する。ログがないことをログインがなかった証明にはしない。

SSH鍵認証では『パスワードを使っていないから安全』とは言えない。秘密鍵の窃取、authorized_keysの追加、Agent Forwarding、鍵の使い回しに注意する。サーバ側の受入れログと端末側の鍵保管、作業票、接続先制限を合わせて調べる。

sudoはログインした人がroot権限を得る経路の一つである。`sudo -l`で許可を確認し、コマンド引数や環境変数を経由して想定外のファイルを実行できないか評価する。sudoログのCOMMAND文字列だけではスクリプト内部の全操作は分からない。

systemdのunitはファイルを置いただけでは起動しない。daemon-reload、enable、start、実際のプロセス状態を区別する。自動起動が無効でも手動で一度実行された可能性がある。ExecStartのパスがシンボリックリンクや書込み可能なディレクトリを指す場合、実体を追う。

サービスアカウントを人の作業に流用すると、監査ログで操作主体を区別できなくなる。対話ログインの要否、権限範囲、秘密の保管・更新、依存サービスの一覧を管理する。秘密を更新する際はサービス停止・再起動と待機系への影響を計画する。

ファイル権限の評価では`chmod 777`の有無だけでなく所有者、グループ、ACL、親ディレクトリ、マウントオプション、サービス実行IDを確認する。unitがroot所有でも、そのExecStart先が一般利用者に書込み可能なら次回起動時に悪用され得る。

永続化設定を削除する前に、内容、変更時刻、作成者、実行ファイルのハッシュを保全する。削除後は再起動で戻らないことを確認し、元の侵入経路、盗難資格、他ホストの同じ設定を調べる。名前が正規サービスに似ていても、実際のパスと署名を確認する。

7. 変更・障害・例外運用

運用場面

崩れやすい条件と確認

ログローテーション

短い保持期間で初期侵入が消える。集中転送と保持を定め、転送停止アラートも置く。

時刻ずれ

Windows・LinuxのタイムゾーンとNTP差を補正。収集時刻と発生時刻を混同しない。

正規変更

作業票にないFS-1の操作も緊急作業の可能性はある。担当者確認と操作証拠を取り、無条件に無害化しない。

サービス停止

疑わしいサービスを止める前に依存業務と証拠を評価。攻撃進行中なら緊急停止を優先する。

権限修正

modeやACLを締めた後、正規アプリが動き、非特権者が改ざんできないことを両方試験する。

監査を後から有効にしても過去の操作は記録されない。現時点で取れるログ・バックアップ・ファイル差分から判断し、未観測の期間と結論の限界を明示する。

8. 封じ込めと復旧条件

OSログ調査の順序認証、権限、設定、実行を順に検証する。1認証2権限3変更4実行5復旧
OSログ調査の順序
  1. 1. 認証:対応 接続元とIDを確認/確認する証跡 4624・sshd
  2. 2. 権限:対応 sudoと管理権限/確認する証跡 sudo・ACL
  3. 3. 変更:対応 unitとサービスを比較/確認する証跡 7045・差分
  4. 4. 実行:対応 プロセスと通信/確認する証跡 4688・EDR
  5. 5. 復旧:対応 再起動後も検証/確認する証跡 業務と監視

認証、権限、設定、実行を順に検証する。

認証成功から実行まで各段階の記録が必要。FS-1の作業票外サービスは先に封じ込めを検討するが、LX-1にも同じ実体や書込み権限が残っていないか調べる。

  1. WS-41、FS-1、LX-1のログ、時刻、監査設定、サービス構成、ファイルハッシュを保全する。

  2. adm-opsのログオン先と操作を追い、作業票と照合して不正サービス・unit・SSH鍵を特定する。

  3. 攻撃進行中のサービスを止め、必要な端末を隔離し、関係IDと鍵を失効する。

  4. 不正設定と実行ファイルを除去またはシステムを再構築し、sudoers・ACL・サービス権限を最小化する。

  5. 再起動後に正規サービスが動き、不正自動起動が戻らず、認証・監査が正常に記録されることを確認する。

『サービスを削除した』だけで終了せず、元の接続方法と資格、他ホストの同じ永続化、変更可能なファイル権限を確認する。再起動試験は自動起動設定が本当に消えたかを見つける。

9. 科目B(午後)の解答手順

ログの名称ではなく、認証・権限昇格・設定変更・実行・永続化のどの段階を示すかを書く。WindowsとLinuxで証拠の場所が違い、監査設定に依存する点を明示する。

  • 4624/4625、4688、7045の意味を区別する。

  • sshd Acceptedとsudo成功を別に確認する。

  • unitの配置、enable、start、実行を分ける。

  • サービスIDとファイル権限の過大な範囲を調べる。

10. 短答演習

演習1:4624

条件:FS-1にtype=3の成功。

質問:サービス起動も確定か。

解答:確定しない。7045とプロセス・サービス状態を調べる。

誤答の理由:ログオンを実行結果と混同している。

演習2:SSH鍵

条件:LX-1に公開鍵でAccepted。

質問:本人が操作したか。

解答:鍵の保有端末と作業票、後続sudoを確認する。

誤答の理由:鍵の窃取や共有を考慮していない。

演習3:sudo

条件:adm-opsがsudoでinstallを実行。

質問:どのファイルが変わったか。

解答:コマンドとファイル差分、unit実体を確認する。

誤答の理由:sudoの一行から全変更内容を推定している。

演習4:enabled

条件:report-syncがenabled=true。

質問:現在動作中か。

解答:別にstart・プロセス状態を確認する。

誤答の理由:自動起動設定と現在の実行を混同している。

演習5:7045

条件:FS-1で作業票外のサービス登録。

質問:どう調べるか。

解答:実行ファイル、作成者、起動、通信を保全し、正規緊急作業か照合する。

誤答の理由:名前だけで悪性または無害と決めている。

演習6:全員書込み

条件:unitのExecStart先が全員書込み。

質問:問題は何か。

解答:低権限者が実行内容を差し替え、次回サービス起動で実行され得る。

誤答の理由:unit本体の所有者だけを見ている。

11. 一次資料

Microsoft:Windowsイベント4624

Microsoft:Windowsセキュリティイベント一覧

systemd:journalctl公式マニュアル

MITRE ATT&CK:Windows Service

MITRE ATT&CK:Systemd Service

この記事についてAIに深掘り質問する

ChatGPT、Claude、Perplexityにこの記事を参照させ、要点の確認や疑問点を自由に質問できます。

次におすすめの学習

編集・検証について

編集・検証:IT資格ラボ編集部

IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。

編集方針・情報源・訂正方針を見る
この記事を共有する