こんにちは！セキュリティの世界へようこそ。インシデントレスポンスの現場で日々、サイバー攻撃の痕跡と格闘しているアナリストです。
セキュリティのニュースを見ていると、「不正アクセスによって画面が盗み見られた」「機密情報がキャプチャされて持ち出された」といった物騒な話を耳にすることがあると思います。「自分のPCや開発しているシステムは大丈夫かな…」と不安になりますよね。
今回は、そんな画面キャプチャ攻撃の証拠をメモリ（RAM）の中から見つけ出す「メモリフォレンジック」という、ちょっとディープで最高にスリリングな技術について、身近な例えを交えながら一歩ずつ優しく解説していきますね！
—
1. 家の防犯に例える「画面キャプチャ攻撃」の仕組み
まずは、私たちが普段使っているWindowsパソコンの中身を、一軒の「お家」に例えて考えてみましょう。
- ハードディスク（HDD / SSD）： 大切な書類やアルバムをしまっておく「金庫や本棚」です。
- メモリ（RAM）： 家の中で今まさに広げて作業をしている「リビングのテーブル」です。
あなたがパソコンで機密書類を開いたり、パスワードを入力したりしているとき、その画面の映像は一時的に「リビングのテーブル（メモリ）」の上に広げられます。
泥棒（攻撃者）の手口とは？
通常のセキュリティソフトは、玄関（ネットワーク）や金庫（ハードディスク）の鍵はしっかりと見張っています。しかし、悪意あるプログラム（マルウェア）がすでにPCの中に侵入している場合、彼らはリビングのテーブルにこっそり忍び込みます。
そして、テーブルの上にある映像（今見えている画面）をこっそりデジカメでパシャリと撮影していくのです。これが画面キャプチャ攻撃の正体です。
このとき、Windowsのシステム側では「画面を撮影するぞ！」という命令が出た瞬間、GDI（Graphics Device Interface）オブジェクトという特別な「写真のフィルム」や「作業用の付箋」のようなメモリー上の部品が一時的に大量に作られます。攻撃者がどんなに巧妙に証拠を隠滅したつもりでも、この「使われた形跡（GDIオブジェクト）」は、しばらくの間メモリというテーブルの片隅にポツンと残されてしまうのです。私たちフォレンジック調査員は、まさにこの「現場に残された足跡」を探しています。
—
2. メモリフォレンジックでGDIオブジェクトを探す
「じゃあ、そのメモリのテーブルをどうやって覗き見るの？」と思いますよね。
現場では、パソコンの電源を切る瞬間（あるいは強制的に保存したメモリのダンプファイル）から、専用のツールを使って中身を解析します。
ここでは、実務でよく使われるオープンソースのメモリ解析フレームワーク「Volatility（ボラティリティ）」などをイメージしながら、Python風の疑似コードを使って、メモリ上から怪しいGDIの痕跡を探すアプローチを覗いてみましょう。
実務で使える！メモリからGDIオブジェクトをスキャンする概念コード
以下のコードは、メモリダンプファイルからWindowsのGUI描画に関連する構造体をスキャンし、不審な画面キャプチャの痕跡がないかを検証するイメージのスクリプトです。
import struct
def scan_gdi_objects(memory_dump_path):
"""
メモリダンプファイルからGDIオブジェクトのシグネチャをスキャンし、
画面キャプチャに関連する不審な構造体を特定するサンプル関数
"""
print(f"[*] 解析対象のメモリダンプ: {memory_dump_path}")
# GDIオブジェクトの識別子や特定の構造体ヘッダー（例としてのダミー値）
# 実際の現場では、Windowsのバージョンに応じたオフセットやプールタグを使用します
GDI_TAG = b'GDIc' # 想像上のGDIオブジェクトを示すタグ
try:
with open(memory_dump_path, 'rb') as f:
# メモリをチャンク（塊）ごとに読み込んでスキャン
chunk_size = 4096
offset = 0
while True:
chunk = f.read(chunk_size)
if not chunk:
break
# チャンク内にGDI関連のタグが存在するか検索
pos = chunk.find(GDI_TAG)
if pos != -1:
actual_address = offset + pos
print(f"[+] 発見: メモリ上の怪しいGDIオブジェクトをオフセット 0x{actual_address:X} で検出しました！")
# ここで周辺のメモリデータ（幅、高さ、ピクセル情報など）を解析し、
# 画面全体がキャプチャされた痕跡がないかを深掘りします。
offset += len(chunk)
except FileNotFoundError:
print("[-] エラー: 指定されたメモリファイルが見つかりません。パスを確認してください。")
# スクリプトの実行例
if __name__ == "__main__":
target_dump = "suspect_machine_memory.dmp"
# scan_gdi_objects(target_dump)
print("[*] インシデントレスポンスの準備完了。安全な環境で解析を進めてください。")このように、OSが画面を描画するために使った「道具の貸出台帳（GDIオブジェクト）」をメモリの奥底から引っ張り出すことで、「この時間に、このプログラムが画面をキャプチャしたな」という動かぬ証拠を掴むことができるのです。
—
3. 開発者・インフラ担当者が今すぐできる防御の心得
「メモリを解析する技術があるのは分かったけれど、そもそも攻撃者に画面を見られないようにするにはどうすればいいの？」
ここが一番気になるところですよね。新人のIT担当者や開発者であるあなたが、今日から現場で意識できるポイントを3つにまとめておきます。
① 不審なプロセスの「画面キャプチャ権限」を監視する
Windowsには、他のアプリの画面を覗き見るためのAPI（BitBlt や GetDC など）が用意されています。EDR（Endpoint Detection and Response）などのセキュリティ製品を導入している場合は、「本来画面キャプチャをする必要がないバックグラウンドプログラムが、突然画面の画像データを取得していないか」というアラートに目を光らせておきましょう。
② 機密画面には「DRM・保護フラグ」を正しく実装する
Webアプリケーションやデスクトップアプリを開発する際、パスワード入力欄やクレジットカード情報入力画面などでは、OSレベルで画面キャプチャ（スクリーンショット）を禁止するフラグ（例：Androidの FLAG_SECURE や、Windows環境におけるウィンドウの表示保護設定など）を適切に活用することが重要です。
「見せちゃいけない画面は、そもそも撮影できないように鍵をかける」のが鉄則です。
③ 最小権限の原則を徹底する
もし万が一、社内のPCがマルウェアに感染したとしても、そのプログラムが「管理者権限」を持っていなければ、メモリの深部を覗き見たり、他のアプリケーションが描画しているGDIオブジェクトを勝手に盗み出すハードルはぐっと上がります。
普段の開発作業や日常業務では、必要以上の強い権限（Administrator権限など）でログインしたままにしない、という基本中の基本が、実は最強の盾になります。
—
おわりに
今回は、メモリ上のGDIオブジェクト解析という、ちょっとコアなDFIR（デジタルフォレンジック）の世界を覗き見してみました。
難解な用語や見慣れないプログラムコードが出てくると身構えてしまいますが、「パソコンというお家の中で、誰がどんな足跡を残したか」を地道に探っていく泥臭い謎解きなのだと分かれば、少し親しみが湧いてきたのではないでしょうか？
セキュリティ対策に「絶対大丈夫」はありません。しかし、万が一インシデント（事故）が起きたときでも、今回のような仕組みを知っていれば、「どこに証拠が眠っているか」を冷静に突き止めることができます。
一歩ずつ、確実に知識をアップデートしていきましょう！あなたの安全な開発ライフとインフラ運用を、現場の第一線から応援しています。
コメント