令和4年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1｜マルウェア解析室から始まる攻防——情報処理安全確保支援士で学ぶ動的解析とペネトレーションの実例

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

• 試験区分: 情報処理安全確保支援士
• 出典: 令和4年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1
• 主なテーマ: マルウェアの動的解析、ファイルレスマルウェア、解析環境の隔離設計、ARPスプーフィング（中間者攻撃）、パスワードハッシュのオフライン解読、ストレッチングとソルト

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

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

セキュリティの仕事というと、攻撃を「守る」イメージが強いかもしれません。しかし実際の現場では、攻撃者の道具であるマルウェアを安全な環境で動かして挙動を観察したり、自社のシステムにわざと攻撃を仕掛けてみて弱点をあぶり出したりする「攻める知識」が欠かせません。今回の情報処理安全確保支援士試験の事例は、まさにその「攻める側の作業」を題材にしています。

この記事では、セキュリティ関連会社の新人アナリストが、3種類のマルウェアを解析環境で動かし、その後に社内の腕試し試験（CTF＝Capture The Flagと呼ばれる、隠された秘密情報を奪い合う実技試験）に挑む物語を追います。マルウェアを安全に観察するための環境設計、ネットワークを盗み見るARPスプーフィングという手口、そして盗み出したパスワードハッシュを解読する流れ——一見バラバラに見えるこれらの論点が、実は「攻撃者がどう考え、どう動くか」という一本の軸でつながっていることが見えてきます。

受験対策としては午後Ⅱの大問を読み解く力が、実務としては「危険なものを安全に扱う設計」の考え方が手に入る事例です。

インシデントの概要

舞台は、従業員200名のセキュリティ関連会社L社です。その中の脅威情報調査部（社内では「Q部」と呼ばれています）は、国内で流行しているマルウェアを解析したり、攻撃者グループの手口を調べたりして、顧客にレポートを提供する事業を行っていました。さらに、四半期ごとに公開レポートも作成しています。つまりQ部は、危険なマルウェアを日常的に「触る」ことが仕事の部署です。

Q部には二つの重要な環境がありました。一つは「解析環境」。マルウェアを実際に動かして挙動を確認するための、サンドボックス（外部から隔離された砂場のような検証空間）用の仮想マシン群で構成されています。各仮想マシンは、動的解析中だけ無線LANルータを経由してインターネットにアクセスできる状態になっていました。

もう一つが「Dシステム」。これは自社開発したハニーポット（攻撃者をおびき寄せるための、わざと攻撃させる囮システム）用の仕組みで、小規模オフィスから大規模オフィスまでを模した「疑似オフィス環境（OF環境）」を10組ほど備えていました。各OF環境はPC、DHCPサーバ、メールサーバ、DNSサーバ、業務用各種サーバといった仮想マシンとルータで構成されており、本物の会社のネットワークそっくりに作られています。

この危険物を扱う部署で、新人アナリストのTさんが、3種類のマルウェアの解析を任されるところから物語は動き出します。

何が起きたのか

TさんがY主任から渡されたのは、国内で感染が確認されている3種類の検体——便宜上、検体α、検体β、検体γと呼ばれるマルウェアでした。Tさんは一つひとつを解析環境で実行し、その挙動を観察していきます。

最初の検体αは、起動すると外部のC&Cサーバ（Command and Control。感染した端末に指令を送る攻撃者の司令塔サーバ）に接続し、そこからプログラムコードをダウンロードしました。Tさんが注目したのは、そのダウンロードされたコードの振る舞いです。コードはディスク（記憶装置）には書き込まれず、メモリ（一時的な作業領域）の中だけに展開されて動いていました。しかもその正体は、キーボード入力をこっそり記録し、定期的にC&Cサーバへ送信するキーロガー（入力盗聴プログラム）だったのです。ファイルとして痕跡を残さないこの挙動に、Tさんは「これは厄介だ」と直感します。

二つ目の検体βは、PC上の特定の拡張子をもつファイルを次々に暗号化していきました。暗号化が完了すると、デスクトップの背景画像を勝手に変更して活動を終えます。利用者のファイルを人質に取る、典型的な身代金要求型の挙動でした。

三つ目の検体γは、もっとも狡猾でした。実行されると自身のデータの一部を削除し、すぐに終了してしまうのです。詳しく追うと、検体γは「自分が仮想マシンの上で動いている」ことを検知すると、システムコール（OSの機能を呼び出す仕組み）を使って自分のプログラム内の攻撃コードを削除してから終了する——つまり、解析されることを察知して証拠を消す「解析回避機能」を持っていました。解析環境が仮想マシンであるかぎり、検体γの本性は決して姿を現しません。

Tさんは結果を報告書にまとめ、Y主任に提出します。ここで会話の中に、ベテランならではの注意が差し込まれました。「検体αの挙動は、来週に再実行したときには、攻撃者による変更で再現できなくなる可能性がある」と。検体αはC&Cサーバから本体コードを取ってくる仕組みなので、攻撃者がそのサーバ上のコードを差し替えてしまえば、同じものはもう手に入らない——だから今の仮想マシンの状態を保存しておこう、というわけです。攻撃の解析は時間との勝負でもあることが、この一言ににじんでいます。

最終的に部内会議で方針が決まります。検体αはDシステムを使って詳細解析する。検体βは詳細解析を見送る。そして検体γは「現在の解析環境（＝仮想マシン）ではこれ以上解析できない」ため、別の環境を構築して解析することになりました。仮想マシンを嫌う検体γには、仮想マシンではない実機環境を用意するしかなかったのです。

物語の後半では、Tさんは1年後、社内の「模擬攻撃試験」を受験します。これは受験者がDシステム内の試験用OF環境に侵入し、隠された秘密情報「flag」を制限時間内にできるだけ多く奪うという、攻撃者の立場に立つ実技試験でした。Tさんは遠隔操作可能な状態のPC（X-PC）から試験を始め、最終的に五つのflagを手に入れます。その過程で使った技術が、ネットワーク盗聴とパスワード解読でした。

最初のflagを取るためにTさんが使ったのが、ARPスプーフィングです。ARP（Address Resolution Protocol。IPアドレスから機器の物理アドレスであるMACアドレスを調べる仕組み）の応答を偽装することで、本来は別のPC（標的PC）宛ての通信を自分のX-PCに引き込み、盗み見る手口です。Tさんは流通しているOSSのARPスプーフィングツール（Aツール）を使い、まず「プローブ機能」で同じネットワーク内の機器情報を集め、続いて「ARPスプーフィング機能」で標的PCとDNSサーバの間に割り込みました。さらに「中継機能」によって、盗み見たあとのパケットを本来の宛先へ転送する——こうして通信を中継しつつ盗聴する、典型的な中間者攻撃（Man-in-the-Middle）を成立させたのです。

五つ目のflagでは、人事サーバへログインするためのシステム管理者のパスワードが必要でした。Tさんは、ファイルサーバに残されていた人事サーバの設計資料や、既知の脆弱性で閲覧できたデバッグログから、ログイン成功時のパスワードハッシュ（パスワードを不可逆変換した文字列）を入手します。しかしそのハッシュは、Blowfish暗号を用い、ソルト（パスワードごとに加える無作為な追加文字列）あり、ストレッチング（ハッシュ化を何度も繰り返して計算を重くする処理）あり、という極めて堅牢な形式で保存されていました。

正攻法は二つとも行き詰まります。人事サーバへ直接ブルートフォース攻撃（総当たり試行）を仕掛ける手は、アカウントロック機能（ログイン失敗が5回連続するとIDがロックされる仕組み）に阻まれる。ハッシュ値から平文を逆引きするレインボーテーブル攻撃（事前計算済みの変換表を使う手法）は、ソルトが入っているため使えない。Tさんはここで発想を変えました。

試験用OF環境のサーバの管理者パスワードは、いずれも「Admin＋5桁の数字」という形式だったのです。この特徴を踏まえれば、候補となるパスワードはわずか10万通り。Tさんは「Admin」に0から順に5桁の数字を結合した候補文字列を生成し、入手済みのソルトとストレッチング回数を使って同じ形式のハッシュを計算し、デバッグログのハッシュと一致するまで照合するプログラムを書きました。これがオフライン攻撃（手元で何度でも試せる解読）です。アカウントロックは「サーバへログインを試みる回数」を制限するものなので、手元でハッシュを計算し続けるオフライン攻撃には効きません。Tさんはついにパスワードを解読し、五つ目のflagを手に入れました。

この解読の流れを、Tさんはプログラムのアルゴリズムとして整理しました。整数の変数nを0から始め、nを5桁の文字列に変換して「Admin」に結合した候補を作る。その候補を、入手済みのハッシュ関数のバージョン・ストレッチング回数・ソルトを使ってハッシュ化し、デバッグログのハッシュ（文字列Z）と比べる。一致すればそれが正解のパスワード。一致しなければnに1を加えて繰り返し、最大値（99999）まで試す——という単純明快な総当たりです。注目すべきは、どれほど堅牢なハッシュ方式でも、平文の候補が10万通りしかなければ、現代の計算機なら短時間で総当たりできてしまう点です。安全性の土台は「ハッシュの強さ」だけでなく「元のパスワードの予測しにくさ」にもあることを、この事例は痛烈に示しています。