情報処理安全確保支援士 2022年 秋期 午後2 問01

解答の論理構成

1. 検体αの挙動から注目すべき特徴
   【問題文】表4 に「ダウンロードしたプログラムコードは、①ディスクには展開されずメモリ内だけに展開される。」と明記されています。
2. この特徴が示すマルウェアの種別
   ファイルシステム上に実体を残さず RAM 上だけで動作するものは、一般に “ファイルレス” と呼ばれます。したがって該当する解答群の選択肢は「エ：ファイルレスマルウェア」となります。
3. 結論
   メモリ内でのみ動作し、痕跡を残しにくい性質から、解答は「エ」です。

誤りやすいポイント

• 「キーボード入力を記録する」という記述から「ウ：トロイの木馬」と誤認するケースがありますが、トロイの木馬はファイルとして常駐する例が多く、メモリだけに展開される点が決定的な相違です。
• 「C&C サーバに接続」という文言で“ランサムウェア”など遠隔操作系を連想しやすいものの、ファイルレスかどうかは別問題である点に注意が必要です。
• “ファイルレス”のキーワードが見当たらなくても、「ディスクには展開されず」という表現＝ファイルレス、と直結させる読み取り力が問われます。

FAQ

解答の論理構成

1. 検体αの挙動
   【問題文】表4より
   「検体α：『C&C サーバに接続し、プログラムコードをダウンロードした。』」
   ─ 検体αは外部の C&C サーバと通信して初めてキーロガー機能を実行します。
2. 攻撃者が変更し得る要素
   近年の攻撃では、発覚を避けるため C&C サーバの所在を頻繁に変える手口が一般的です。IP アドレスを切り替えれば、旧アドレスへアクセスしても応答がなくなり、マルウェアはプログラムコードを取得できません。
3. 下線②の主旨
   【問題文】
   「『今日確認した検体αの挙動が、検体αを週明けに再実行した時には、攻撃者による変更によって再現できなくなる』」
   ─ 再現不能になる原因は、検体αがアクセスする C&C サーバ側の情報が週末の間に書き換わるケースを想定しています。
4. 保存指示の理由
   仮想マシンをスナップショット保存しておけば、アクセス先の IP アドレスや DNS 解決結果を含むネットワーク状態を保持できます。これにより、月曜に旧アドレスが既に無効化されていても、保存した環境で再現試行が可能です。
5. 以上から、攻撃者が変更することで挙動が再現できなくなるものは
   「C&CサーバのIPアドレス」です。

誤りやすいポイント

• 「C&Cサーバそのもの」と答えてしまう
  物理サーバ移転ではなく“所在情報”の変更が本質です。
• 「ダウンロードするプログラムコード」と誤解する
  コード内容が変わっても接続自体は再現できます。挙動が再現不能になる決定的要因は接続先の IP アドレス変更です。
• 「ドメイン名」と答える
  多くのマルウェアは直接 IP アドレスで通信するか、DNS キャッシュを利用するため、ドメインより IP が重要となります。

FAQ

解答の論理構成

1. 現在の解析環境の特徴
   【問題文】表1「解析環境」には“サンドボックス用の複数の仮想マシンで構成されている”と記載されています。
2. 検体γが解析できなかった理由
   表4の検体γの簡易解析結果には“自身が仮想マシン上で動作していることを検知すると…終了する”とあります。これは仮想環境での解析を回避する典型的機能です。
3. 会議で決まった対応
   本文では“検体γは現在の解析環境ではこれ以上解析できないので、③別の環境を構築して解析することが決定した”とあります。
4. したがって「別の環境」とは、仮想マシン依存を回避できる実機環境を指すと導けます。
5. 以上より模範解答は「仮想マシンではない実機環境を使う」となります。

誤りやすいポイント

• 「ネットワークを外部と切り離す」など通信面の違いと誤解する。実際の焦点は“仮想/実機”の違いです。
• 解析ツールを変えるだけと判断しがちですが、検体γは仮想マシン自体を検知して終了するため環境全体を実機に替える必要があります。
• “高性能な仮想化基盤”や“別のハイパーバイザ”では同じく検知される可能性があり根本解決になりません。

FAQ

解答の論理構成

1. 手順を追加する目的
   問題文には「解析ファイルの転送は、必ず検疫PCを経由させる。」「検体の実行後、検疫PC以外のOF機器と、ファイルシェアサーバとは直接通信させない。」とあります。したがって、 • OF機器 → 検疫PC → ファイルシェアサーバ という一本化された流れを作り、 • その都度 PFW を開閉して最小権限を維持する
   という設計方針になります。
2. a の決定
   まず OF機器から検疫PCへファイルを渡す必要があります。PFW は通常「検疫PCと管理 Web サーバとの間の通信だけ」を許可しているため、一時的にポリシーを緩める必要があります。解答群「ア」は「検疫PCにログインし、検疫PCのPFWの設定を変更して検疫PCとOF機器との間の通信を許可する。解析ファイルをOF機器から検疫PCに転送する。」であり、設計方針と合致します。
3. b の決定
   OF機器→検疫PC への転送が終わったら、感染源になり得る OF機器を隔離します。解答群「ウ」は「検疫PCを除くOF機器をシャットダウンする。」であり、要件「検体の実行後、検疫PC以外のOF機器と、ファイルシェアサーバとは直接通信させない。」を満たします。
4. c の決定
   次に外部との経路を物理的に閉じるため、ルータを “内部モード” に戻す必要があります。既存手順（図4）でもファイル取得後に「使用したOF環境内のルータを内部モードに切り替える」としており、新手順でも同じタイミングで実施します。解答群「エ」はその操作を示します。
5. d の決定
   最後に検疫PC→ファイルシェアサーバ へ転送するため、再度 PFW を一時的に緩める必要があります。解答群「イ」は「検疫PCにログインし、検疫PCのPFWの設定を変更して検疫PCとファイルシェアサーバとの間の通信を許可する。解析ファイルを検疫PCからファイルシェアサーバに転送する。」であり、設計方針「解析ファイルの転送では、検疫PCがマルウェアに感染していないことを確認」にも合致します。

誤りやすいポイント

• PFW の変更タイミングを逆にしてしまい、検疫PCが先にファイルシェアサーバへ接続できる状態にしてしまう。これでは OF機器が残っている間に横展開する恐れがあります。
• 「内部モード」への切替を手順の最初に配置してしまうと、OF機器から検疫PCへの転送自体が不可能になります。
• 検疫PCのマルウェアスキャン（手順5）を省略すると、安全確認という要件を満たせません。

FAQ

解答の論理構成

1. eは「ネットワーク内の機器の情報を得たいと考え」て実行した機能です。
   ――【問題文】“(3) ネットワーク内の機器の情報を得たいと考え、表5中の項番eの機能を実行した。”
2. 機器情報の取得は、ARP 要求をブロードキャストし応答を収集する作業に相当します。
3. 表5を確認すると、項番“1”の“プローブ機能”の説明に
   ――【問題文】“OS標準の機能を用いて同一セグメント内にARP要求を出し、応答を記録する。”
   とあり、まさに機器情報（IP と MAC の対応）を得るための処理です。
4. よって、eに入るのは項番“1”となります。

誤りやすいポイント

• “ARPスプーフィング機能”を選んでしまう
  └ 機器情報を得る目的ではなく、偽情報を送って通信を乗っ取るための機能。説明文にも“機器がARP要求を出した際に…不正なARP応答を送る”とあり目的が異なる。
• “中継機能”を選んでしまう
  └ これはスプーフィング成立後に盗聴を成立させるための機能であり、ARP テーブル調査とは無関係。
• ARP テーブルの変化＝スプーフィング開始と早合点
  └ まず機器一覧を把握しなければ標的選定ができない。順序を意識すること。

FAQ

解答の論理構成

1. 前提となる各機器の MAC アドレス
   • 図6には
   － X-PC：XX-XX-XX-fb-44-25
   － 標的PC：XX-XX-XX-23-46-4a
   － DNSサーバ：XX-XX-XX-f9-48-1b
   が示されています。
2. ARPスプーフィングの狙い
   問題文の「標的PCからDNSサーバへの通信を盗み見る準備を整えた。」より、X-PCは
   ① 標的PCの「DNSサーバ → MAC」の対応を自分の MAC に書き換える
   ② DNSサーバの「標的PC → MAC」の対応も自分の MAC に書き換える
   ことで中間者(MITM)を成立させています。
3. X-PC の ARP テーブル（表7）の決定
   X-PC 側は正しい宛先へパケットを転送しなければならないため、 ・192.168.15.51（標的PC）→ 標的PC本来の MAC XX-XX-XX-23-46-4a
   ・192.168.15.98（DNSサーバ）→ DNSサーバ本来の MAC XX-XX-XX-f9-48-1b
   と保持します。
   よって
   f：ア（XX-XX-XX-23-46-4a）
   g：イ（XX-XX-XX-f9-48-1b）
4. 標的PC の ARP テーブル（表8）の決定
   標的PCには攻撃者 MAC を注入するので、 ・192.168.15.50（X-PC）→ 当然 X-PC の MAC XX-XX-XX-fb-44-25
   ・192.168.15.98（DNSサーバ）→ X-PC の MAC XX-XX-XX-fb-44-25（偽情報）
   となります。
   よって
   h：ウ（XX-XX-XX-fb-44-25）
   i：ウ（XX-XX-XX-fb-44-25）

誤りやすいポイント

• 「攻撃者の ARP テーブルも改ざんされる」と勘違いし、f・g に攻撃者 MAC を入れてしまう。攻撃者は転送のために正しい対応表が必要です。
• 標的PCの 192.168.15.50 を“自分自身”と誤解して別の MAC を選択するケース。IP が X-PC であることを把握しましょう。
• ブロードキャスト MAC XX-XX-XX-ff-ff-ff を選びがちですが、ARP では要求時にのみ使われ、テーブルには登録されません。

FAQ

解答の論理構成

1. 事前情報の整理
   ・図6より
   ― Ｘ-ＰＣ：IP“192.168.15.50”、MAC“XX-XX-XX-fb-44-25”
   ― 標的ＰＣ：IP“192.168.15.51”、MAC“XX-XX-XX-23-46-4a”
   ― ＤＮＳサーバ：IP“192.168.15.98”、MAC“XX-XX-XX-f9-48-1b”
   ・Ａツールの“ARPスプーフィング機能”は【問題文】「標的の機器がARP要求を出した際に…自身のMACアドレスを含んだ不正なARP応答を送る」とある。
   ⇒ 標的ＰＣもＤＮＳサーバも、互いのIPアドレスをＸ-ＰＣのMAC“XX-XX-XX-fb-44-25”と誤認する。
2. パケット流れの推定
   (1) 標的ＰＣ → ＤＮＳサーバ（クエリ）
   ・IPヘッダは送信元“192.168.15.51”／宛先“192.168.15.98”
   ・宛先MACは誤認によりＸ-ＰＣ“XX-XX-XX-fb-44-25”
   ・送信元MACは標的ＰＣ自身“XX-XX-XX-23-46-4a”
   (2) Ｘ-ＰＣ → ＤＮＳサーバ（中継）
   ・IPヘッダはそのまま転送
   ・送信元MACはＸ-ＰＣ“XX-XX-XX-fb-44-25”
   ・宛先MACはＤＮＳサーバ“XX-XX-XX-f9-48-1b”
   (3) ＤＮＳサーバ → Ｘ-ＰＣ（応答）
   ・送信元MACはＤＮＳサーバ“XX-XX-XX-f9-48-1b”
   ・宛先MACはＸ-ＰＣ“XX-XX-XX-fb-44-25”
   (4) Ｘ-ＰＣ → 標的ＰＣ（応答を中継）
   ・送信元MACはＸ-ＰＣ“XX-XX-XX-fb-44-25”
   ・宛先MACは標的ＰＣ“XX-XX-XX-23-46-4a”
3. 表9 と照合
   【問題文】表9は送信元IP/宛先IPがすべて“192.168.15.51”→“192.168.15.98”またはその逆で固定。
   行ごとに上記(1)〜(4)を対応させると
   ・1行目＝(1) → j＝標的ＰＣMAC“XX-XX-XX-23-46-4a”、k＝Ｘ-ＰＣMAC“XX-XX-XX-fb-44-25”
   ・2行目＝(2) → l＝Ｘ-ＰＣMAC“XX-XX-XX-fb-44-25”、m＝ＤＮＳMAC“XX-XX-XX-f9-48-1b”
   ・3行目はすでに数値で固定（ＤＮＳ→Ｘ-ＰＣ）
   ・4行目＝(4) → n＝Ｘ-ＰＣMAC“XX-XX-XX-fb-44-25”、o＝標的ＰＣMAC“XX-XX-XX-23-46-4a”
4. 解答
   j：ア　k：ウ　l：ウ　m：イ　n：ウ　o：ア

誤りやすいポイント

• 「送信元IP＝192.168.15.51 なら送信元MACも同一」と早合点し、ARPスプーフィング後の中継パケット（送信元MACがＸ-ＰＣ）を見落としやすい。
• ブロードキャストMAC“XX-XX-XX-ff-ff-ff”はARP要求のときだけ現れる。表9はDNSトラフィックなので該当しない。
• DNS応答の最終中継（Ｘ-ＰＣ→標的ＰＣ）を逆方向の通信と勘違いし、MACを入れ替えてしまう。

FAQ

解答の論理構成

1. 図7には「利用者が設定したパスワードは、Blowfish暗号を用いた、ソルトあり、④ストレッチングありのハッシュ関数を用いて出力した文字列」と記載されています。
2. 「ストレッチング」は、パスワードのハッシュ計算を多数回繰り返すことで計算量を増やし、⑤ブルートフォース攻撃に対抗する機能を強化する技術として用いられます。
3. したがって、④は「同じハッシュ処理を反復して実行し、計算コストを高めること」を指します。
4. 以上より模範解答「ハッシュ化を繰り返す処理」となります。

誤りやすいポイント

• ソルトとストレッチングを混同し、単に「ランダム値を付与」と答えてしまう。
• 「鍵長を伸ばす」「暗号化を複数回」など、ハッシュではなく暗号処理と誤解してしまう。
• ストレッチングの目的を「ハッシュ値を長くする」と捉え、反復計算である点を外してしまう。

FAQ

解答の論理構成

1. 表10の項番「1」では、ブルートフォース攻撃を断念した理由として
   「⑤ブルートフォース攻撃に対抗する機能があるから」
   と明示している。
2. その“機能”が具体的に何かは、図7の設計資料に示されたログイン制御に着目すると判明する。図7には
   「ログイン失敗が『5回』連続した場合は当該利用者ＩＤによるログインを『10分間』ロックする」
   という仕様が記載されている。
3. 連続失敗回数と時間でアカウントを一時的に停止する挙動は、辞書／総当たりを阻止する典型的な防御策であり、これが⑤で求められている機能である。
4. したがって解答は
   「ログイン失敗が5回連続した場合に当該利用者IDをロックする機能」
   となる。

誤りやすいポイント

• 「CAPTCHA表示」や「IPアドレスを遮断する機能」と誤解しやすい。⑤は“利用者ＩＤ”単位のロックであり、ネットワーク層での遮断ではない。
• 「パスワードリトライ回数を制限する機能」とだけ書くと、時間によるロックを明示していないため減点対象になる。
• 5回→10分の具体値を示さず抽象表現（例：一定回数でロック）にすると根拠不足になりやすい。

FAQ

解答の論理構成

• 表10の項番2には、 「文字列Zに含まれるハッシュ値から平文を得るために、p攻撃を行う。」
  とあり、その困難理由として
  「文字列Zの生成にはソルトが用いられているから」
  と説明されています。
• ソルトは、同じ平文パスワードでもユーザごとに異なるハッシュ値を生成させ、あらかじめ計算済みのハッシュ一覧表を無効化します。
• 事前計算済みのハッシュ一覧表を利用して逆引きする代表的な攻撃が「レインボーテーブル攻撃」です。
  ソルトによって「レインボーテーブルの事前計算が成立しない」ため、困難になるという理由と完全に一致します。
• したがって、p に入る攻撃は解答群「エ：レインボーテーブル」と判断できます。

誤りやすいポイント

• 「Pass the Hash」はハッシュそのものを再利用する横取り型であり、ソルトの有無で困難さはほとんど変わらない点を見落としやすいです。
• 「既知平文攻撃」は暗号文と対応する平文が既に手元にある前提の手法で、ソルトとは直接関係しません。
• ソルトは辞書攻撃全般を遅延させますが、特に「事前計算型」であるレインボーテーブル攻撃に強いことを押さえておく必要があります。

FAQ

解答の論理構成

• 【問題文】図7‐3には「システム管理者のパスワードは、いずれも “Admin［数字5桁］”」と明記されています。
• 図8‐ＳＴＥＰ2では「⑥システム管理者のパスワードとして n番目の候補となる文字列 を生成する」と示されています。
• したがって、候補生成は“Admin”の後ろに 0〜99999 をゼロパディングした5桁の数字を連結する処理になります。
• この連結結果こそが下線⑥で求められている「具体的な文字列」です。

誤りやすいポイント

• 「5桁」のゼロパディングを忘れ、桁数可変の数字列を付けてしまう。
• ⑥をハッシュ値や暗号文と誤解し、H文字列を答えてしまう。
• “Admin”以前にソルトを付けるなど、パスワード形式を勝手に拡張してしまう。

FAQ

解答の論理構成

1. 報告書には「二つ目の方法は、重要な PC や狙われやすいサーバについて、ARP スプーフィングが実行されていないか常時監視する方法である。例えば、各 PC 及びサーバの ARP テーブルを常時監視して、⑦ARP テーブルの不審な状態を確認した場合には…」と記載されています。
2. 直前の設問群では、Tさんが「ARP スプーフィング機能」を用いて標的 PC と DNS サーバの双方に対し、自身（X-PC）の MAC アドレスを示す不正な ARP 応答を送りました。
   • 表7「ARP スプーフィング機能実行後の X-PC の ARP テーブル」では、192.168.15.51 と 192.168.15.98 の両方に対して同一の MAC アドレス（X-PC のもの）が登録される結果となります。
3. このように「複数の IP アドレスが同一の MAC アドレスへひも付けられる」状態は、本来別々の機器であるはずの IP に同一の MAC が割り当てられているため不自然であり、ARP スプーフィング成立の典型的兆候となります。
4. よって、報告書中の「⑦ARP テーブルの不審な状態」とは「同一のMACアドレスのエントリが複数存在する状態」と判断できます。

誤りやすいポイント

• 「MAC アドレスが変化した状態」とだけ答えると、具体性が不足し減点対象になります。
• IP 重複（同一 IP に複数 MAC）が不審と思いがちですが、今回の攻撃は「一つの MAC アドレスが複数 IP を名乗る」点が要注意です。
• “不審” を通信量やパケット数の急増と解釈してしまい、監視対象を誤るケースがあります。

FAQ

解答の論理構成

1. 図7の情報には「デバッグログには、ログインした利用者IDごとの、セッション情報、H文字列を含む認証情報…が出力されていた。」と明記されています。
2. Tさんはこの「H文字列を含む認証情報」を利用し、図8のオフライン攻撃でシステム管理者のパスワードを解読して5番目のflagを取得しました。
3. 従って、同様の攻撃を防ぐための最も直接的な運用改善は、デバッグログから認証情報自体を取り除くことです。
4. 図9は改善提案の(3)ログの観点でqを求めています。ここには「デバッグログに認証情報を出力しないこと」と記載することで、上記の問題点を根本から解消でき、攻撃の再現を防止できます。

誤りやすいポイント

• 「ログを暗号化する」「アクセス制御を強化する」なども有効ですが、設問は“デバッグログに記録される内容”を直接改善する提案を求めています。
• 「パスワードをハッシュ化して保存する」は既に実装済み（Blowfish＋ソルト＋ストレッチング）であり、本問の焦点ではありません。
• 「H文字列をマスクする」と書くとハッシュ以外の認証情報は残ってしまうため不十分です。

FAQ