令和5年度 春期 情報処理安全確保支援士試験 午後 問2｜ログが語る侵入の足跡——情報処理安全確保支援士で学ぶライブラリ脆弱性と不正アクセス調査の実例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和5年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問2
• 主なテーマ: ライブラリの脆弱性、不正アクセス調査、FW・ps・netstatログ分析、FTPのアクティブ/パッシブ、バインド/コネクトシェル、DNS TXTレコードの悪用（C2通信）、暗号資産マイニングマルウェア

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

侵入されたあと、調査員に残された手がかりはログだけです。ファイアウォールの通信記録、稼働中のプロセス一覧、ネットワーク接続の状態——一見すると数字と記号の羅列でしかないこれらを読み解き、「攻撃者がどこから入り、何をしたか」を再構成する。それが不正アクセス調査（フォレンジック）の現場です。

今回の情報処理安全確保支援士試験の事例は、製造業の会社で起きた不正アクセスを題材に、調査員がログを突き合わせて攻撃の全貌を暴いていく過程を描いています。きっかけは「1分間に10回以上のログイン失敗」という一通のアラート。そこから受付サーバの乗っ取り、工場ネットワークへのポートスキャン、そしてDNS（ドメイン名とIPアドレスを対応づける仕組み）のTXTレコードを悪用した巧妙な指令通信まで、攻撃の連鎖がログから浮かび上がります。

この記事を読むと、FTPの通信モードやバインド/コネクトといった通信の方向の概念、ログの突き合わせで攻撃を立証する手順、そしてDNSが攻撃インフラに転用される手口が見えてきます。受験者にはログ分析問題の解き方が、運用担当者には「侵入後に何を調べるか」の実践知が得られる事例です。

インシデントの概要

舞台は、精密機器の部品を製造する従業員250名の中堅製造業者R社です。本社に隣接した場所に工場があり、ネットワークは本社のDMZ（インターネットと社内の中間に置く緩衝地帯）、利用者LAN、工場LANに分かれていました。各サーバはLinux OSで稼働し、ログはログ管理サーバで一元管理されています。

DMZには、取引先からの受注情報を扱う「受付サーバ」が置かれ、Webアプリケーションプログラムが稼働していました。受付サーバは受注情報をDBサーバに保管し、DBサーバはそれをファイルに変換してFTP（ファイル転送のための通信規約）で工場の製造管理サーバに送る——という業務の流れがありました。これらのアプリは10年以上の稼働実績がありました。

ファイアウォール（FW）はステートフルパケットインスペクション型（通信の状態を追跡して許可・拒否を判断する方式）で、インターネットから受付サーバへの通信は443/TCP（HTTPS）だけを許可し、受付サーバからインターネットへの通信もOSアップデート用に443/TCPだけを許可していました。一見、堅牢な構成です。

DMZ上のサーバのログは常時監視され、いずれかのサーバで1分間に10回以上のログイン失敗が発生するとアラートがメールで通知される仕組みになっていました。物語は、この監視の網に一つの異常が引っかかるところから始まります。

何が起きたのか

ある日、情報システム課のMさんがアラートを受信しました。確認すると、受付サーバからDBサーバとメールサーバに対する、SSH（暗号化された遠隔操作の通信）でのログイン失敗によるものでした。しかも、受付サーバからこれらへのSSHログイン成功の記録はありません。「受付サーバが、社内の他のサーバに不正なログインを試みている」——Mさんは不審に思い、U課長に相談して、FWのログと受付サーバを調査することにしました。

FWのログを調べると、攻撃の輪郭が見えてきます。受付サーバから工場LANのIPアドレスに対してポートスキャン（どのポートが開いているか総当たりで調べる偵察行為）が行われていました。受付サーバから製造管理サーバへはFTP接続が行われ、データコネクション（FTPで実データを流す通信路）が確立されていました。FWのログから、このFTPがパッシブモードでのデータコネクションを使っていたことも読み取れました。本来は受注情報を受け渡すだけのはずの受付サーバが、社内を偵察し、内部のサーバへアクセスを広げていたのです。

Mさんは受付サーバ自体に踏み込みます。ps コマンド（稼働中のプロセス一覧を表示）と netstat コマンド（ネットワーク接続状態を表示）を実行すると、「srv」という名称の見慣れないプロセスが動いていました。srv ファイルのハッシュ値（ファイルの中身から計算される指紋のような値）を調べると、インターネット上で公開されている攻撃ツールであることが判明します。このツールは、C&Cサーバ（攻撃者の司令塔）から指示を受けて子プロセスを起動しポートスキャンを行い、SSHやFTPのポートが開いていれば利用者IDとパスワードの辞書攻撃（よくある組み合わせを次々試す攻撃）を仕掛け、SNMP（機器を監視・管理するための通信規約）のコミュニティ名「public」を使って機器のバージョン情報を取得する——といった多彩な機能を持っていました。

srv の通信モードには二つありました。外部からの接続を待ち受ける「バインドモード」と、外部に自ら接続しに行く「コネクトモード」です。Mさんはログとプロセス情報を突き合わせ、攻撃者の動きを推理します。攻撃者は最初、srv をバインドモード（8080番ポートで待ち受け）で動かしてC&Cサーバとの接続を試みましたが、FWでそのポートへの通信が拒否され失敗しました。そこで攻撃者はコネクトモードに切り替え、受付サーバから外部のC&Cサーバへ自ら443番ポートで接続しに行き、今度は成功します。FWは受付サーバからインターネットへの443/TCPを許可していたため、その「許可された通信」に紛れて指令通信が通ってしまったのです。接続成功後、攻撃者はポートスキャンを実行しました。

この推理を支えたのが、psとnetstatの出力でした。psの結果には、srvが「-mode bind」で8080番ポートを開く子プロセスと、「-mode connect」で外部へ接続しに行く子プロセス、そして「-range」でIPアドレス範囲を走査する子プロセスが並んでいました。netstatの結果と突き合わせると、8080番はLISTEN（待ち受け）状態のまま外部とつながっておらず、一方で443番経由の接続はESTABLISHED（確立済み）になっていた。バインドは空振りし、コネクトは成功した——この対比が、攻撃者の試行錯誤をくっきりと浮かび上がらせたのです。さらに、ポートスキャンを担う「-range」のプロセスは、コネクト成功後に動き出した親子関係にあり、その識別番号（PID）をたどることで「いつ・どのプロセスが偵察を実行したか」まで特定できました。

Mさんは受付サーバが不正アクセスを受けていることをU課長に報告し、ネットワークから切断します。さらにMさんは、攻撃者が受付サーバの設定を変更していないか調べました。すると、巧妙な仕掛けが見つかります。機器の起動時にDNSリクエストを発行して、あるドメイン（△△△.com）のDNSサーバからTXTレコード（DNSに任意の文字列を登録できる種別）のリソースデータを取得し、その内容をそのままコマンドとして実行する cron エントリ（定期実行の予約）が仕掛けられていたのです。dig コマンド（DNS情報を問い合わせる）で実際に取得すると、攻撃ツール本体を外部からダウンロードして実行する命令文が現れました。攻撃者はDNSのTXTレコードを、指令を配る「掲示板」として悪用していたのです。

Mさんは、この logd というファイル（DNS経由で取得・実行される攻撃ツール）をマルウェア対策ソフトベンダーに解析してもらおうと考えました。当初はWebブラウザで攻撃者のURLからダウンロードしようとしましたが、U課長から「ダウンロードしたファイルは解析対象として適切ではない」との指摘を受けます。攻撃者のサーバ上のファイルは差し替えられている可能性があり、受付サーバで実際に稼働しているものと内容が異なるかもしれないからです。Mさんは指摘を踏まえ、調査対象の logd を受付サーバ（実際に稼働している現物）から取得して解析を依頼しました。解析の結果、logd は暗号資産マイニング（仮想通貨を採掘するために計算資源を勝手に使う）の実行プログラムであることが分かりました。

幸い、工場LANへの侵害はありませんでした。Webアプリのログ調査から、受付サーバのWebアプリが使用しているライブラリ（外部の部品プログラム）に脆弱性が存在し、それが悪用されて侵入されたと結論づけられます。R社はシステムの復旧計画を策定し、過去に開発されたアプリとネットワーク構成をセキュリティの観点で見直すことにしました。