30秒で理解する

ペネトレーションテストの現場で長く使われてきたPDF検証ツールが malicious-pdf（jonaslejon、GitHub 3.8kスター・BSD-2-Clause）だ。1回の実行で67種類のテストPDFを生成し、PDFビューア・PDF変換処理・サーバ側のPDFパーサが、JavaScript実行や外部通信、認証情報の送信といった「危険な仕様」をどう扱うかを一括で検証できる。本記事は攻撃の手順やペイロードを一切掲載せず、何が攻撃面になり、どう検出・無害化するかという防御側の視点だけで整理する。

この記事のポイント
  • ・malicious-pdfは「攻撃ツール」だが、価値の本質は自社の防御（CDR・メールゲートウェイ・SOC検知）の実効性を測る的（まと）として使えること。
  • ・PDFは静的文書ではなく、JavaScript・起動アクション・外部リソース参照・フォーム送信という能動的な仕様を持つ。これらが攻撃面になる。
  • ・防御の本命は検知型ではなくCDR（Content Disarm and Reconstruction）。危険な構造を除去して再構築するため、未知のペイロードにも構造的に強い。
  • ・ビューア（Adobe / Foxit / Chrome / Preview）でJavaScript・外部通信の既定挙動が大きく違う。設定とバージョン管理が効く。
  • ・利用は自社環境・隔離サンドボックス・書面で許可されたテストに限定。許可なき送信は不正アクセス・業務妨害になり得る。

このツールは2020年代を通じて更新が続き、CVE再現テストやBurp Collaborator/Interactshとの連携を前提に設計されている。「攻撃のためのコード」としてではなく、「自分たちのPDF処理が壊れていないかを確かめる定期点検」として読むのが、本記事の立場だ。

PDFが攻撃面になる理由

「PDFはただの文書フォーマット」という思い込みが、最大の弱点になる。PDF仕様（ISO 32000）は、文書の表示以外に多くの能動的機能を含んでいる。代表的なものを挙げる。

・JavaScript：PDF内に埋め込まれたスクリプトが、文書を開いた時・特定の操作をした時に実行される。Acrobat独自のJS APIは数十種に及ぶ
・起動・URIアクション：外部プログラムの起動要求やURLへのアクセスを文書側から指示できる
・外部リソース参照：別のPDFや外部ファイルを読み込む参照（GoToEなど）を持てる
・フォーム（AcroForm / XFA）：入力データを外部のサーバへ送信する仕組みを持つ
・埋め込みファイル・メタデータ：添付ファイルやXML系メタデータを内包でき、ここがインジェクションの足場になる

これらが「便利な機能」であると同時に、攻撃者にとってはフォンホーム（外部への通信）・認証情報の送信・SSRF・スクリプト実行の入口になる。とくに業務PDFはメールで日常的にやり取りされ、利用者が中身を疑わずに開くため、攻撃面として狙われやすい。

業務の文脈がリスクを増幅する点も見逃せない。請求書・契約書・採用応募書類・帳票といったPDFは「開いて当然」のものとして扱われ、受信者が警戒しないまま能動コンテンツを実行してしまう。さらに、人事や経理のように外部から不特定のPDFを受け取る部署ほど、攻撃者にとって都合のよい入口になる。送信元の偽装（なりすまし）と組み合わされると、技術的な防御がない環境では検知が難しい。だからこそ、利用者の注意力に依存せず、ゲートウェイとライブラリの設定で構造的に止める発想が要る。攻撃面が「人」ではなく「処理系の設定」にあると捉え直すことが、PDF防御の最初の一歩だ。

PDFはAIエージェントが「読む」外部コンテンツの代表でもある。間接型プロンプトインジェクションの運び手になり得る点を含め、脅威モデルの全体像は上位ピラーのAIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイドで俯瞰している。本記事はそのうち「PDFという攻撃面の防御検証」を担当する各論だ。

外部コンテンツに仕込まれた指示でLLMやエージェントが乗っ取られる構造はプロンプトインジェクションとは？攻撃手口・実例・防御策をLLM開発者向けに徹底解説｜OWASP LLM01で詳説している。また「テスト専用ツールだから安全」という前提が崩れる例として、テストランナーのRCEを扱ったVitest RCE脆弱性（CVE-2026-47429ほか）｜影響バージョンの確認・パッチ適用・SCA検知の手順も、PDFパーサの「無害だと思っていた処理系」が攻撃面になる話と地続きだ。

前提の確認
「PDFは開いても安全」は、JavaScriptと外部通信が無効化されたビューアでのみ成り立つ条件付きの真です。既定で能動機能が有効なビューア＋未パッチの脆弱性、という組み合わせでは前提が崩れます。だからこそ「自社環境で実際にどう動くか」を検証する必要があります。

malicious-pdfで生成できる67種の分類

67種のテストPDFは、攻撃の「目的」で分類すると全体像がつかみやすい。以下はカテゴリ名だけの防御用タクソノミーで、具体的なペイロードやコードは意図的に掲載していない。検証者が「自社の防御がどのカテゴリを取りこぼすか」をチェックリスト化するための地図として使ってほしい。

flowchart TB PDF["malicious-pdf
67種テストPDF"] --> CB["コールバック系
フォンホーム検証"] PDF --> CRED["認証情報窃取系
NTLM / UNCパス"] PDF --> SSRF["SSRF系
フォーム / 画像参照経由"] PDF --> EXT["外部ファイル参照系
GoToE / URI / Launch"] PDF --> SCRIPT["スクリプト実行系
JavaScriptトリガ"] PDF --> EXFIL["データ持ち出し系
XFAフォーム送信"] PDF --> INJ["インジェクション系
XXE / XSLT / 注釈XSS"] CB --> D1["防御: 外向き通信遮断
DNS監視"] CRED --> D2["防御: SMB/UNC外部遮断
NTLM送信禁止"] SSRF --> D3["防御: パーサのネットワーク無効化"] EXT --> D4["防御: 外部参照のサニタイズ"] SCRIPT --> D5["防御: JS無効化 / CDR"] EXFIL --> D6["防御: フォーム送信先制限"] INJ --> D7["防御: XML安全パース / 入力検証"]

各カテゴリを防御の観点で要約する。

・コールバック系（フォンホーム）：文書を開いた事実を外部に通知する通信。DNSやHTTPの外向き通信を検知・遮断できるかが論点。Burp CollaboratorやInteractsh連携は、この「通信が成立したか」を観測するための仕組み
・認証情報窃取系：UNCパス参照などを介してWindowsのNTLM認証情報が外部へ送られる経路。境界での外向きSMB/445遮断と、NTLM送信ポリシーが効く
・SSRF系：サーバ側でPDFを処理する変換サービスに対し、内部リソースへアクセスさせる経路。パーサのネットワークアクセス無効化が要
・外部ファイル参照系：別ファイルや外部プログラムの起動・参照を促すアクション。ビューアの起動アクション無効化とサニタイズが効く
・スクリプト実行系：埋め込みJavaScriptの実行を試すテスト。JavaScript無効化とCDRが本命
・データ持ち出し系：XFAフォームなどを介した外部送信。フォーム送信先のホワイトリスト化が論点
・インジェクション系：XXE・XSLT・注釈経由のXSSなど、XMLやレンダリング処理の不備を突くテスト。安全なXMLパース設定と入力検証が要

重要なのは、67種すべてを個別に潰す必要はないということだ。後述するCDRやビューア設定のように、カテゴリ横断で効く構造的な防御を一つ入れると、多くのカテゴリを一度に無力化できる。検証は「どの構造的防御が、どのカテゴリ群をカバーしたか」を測るために使う。

導入と基本的な生成コマンド

防御検証の再現性のために、最小限・非破壊の導入手順だけ示す。生成されるのは自社の検証用テストファイルであり、外部に送信しない限り何も起こさない。必ずインターネットから隔離した検証セグメント、もしくはローカルのサンドボックスで実行する。

# 1. 取得（公式リポジトリ）
git clone https://github.com/jonaslejon/malicious-pdf.git
cd malicious-pdf

# 2. 依存のインストール（仮想環境を推奨）
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

# 3. ヘルプを確認（まず挙動を把握する）
python3 malicious-pdf.py --help

コールバック検証では、生成時に「通信の戻り先」となるリスナーのホスト名を渡す。ここには必ず自社管理のリスナー（自前のInteractshサーバや、検証ネットワーク内のDNS/HTTPシンク）を指定する。第三者のサービスや本番ドメインを指定してはならない。

# 自社管理の検証用リスナーを指定して生成（出力は output/ に test1.pdf … として保存される）
python3 malicious-pdf.py your-internal-listener.test.local

# 出力ディレクトリを明示し、帰属メタデータを残す既定で生成
python3 malicious-pdf.py --output-dir ./pentest-samples your-internal-listener.test.local

生成されたPDFは「検査対象」であって配布物ではない。検証が終わったら確実に削除し、誤って共有ストレージやメールに載せないよう、ファイル名やディレクトリに DO-NOT-DISTRIBUTE のような印を付けて隔離する運用をおすすめする。

難読化オプションは「検知の強さ」を測るために使う
malicious-pdfには難読化レベルの指定があります。これは攻撃を巧妙にするためではなく、自社のサンドボックスやアンチウイルスが「難読化されても検知できるか」の段階的なテストに使うものです。レベルを上げてもすり抜けず検知・無害化されるか、をログで確認するのが正しい使い方です。

検出された場合の防御・サニタイズ

ここが本記事の中心だ。テストPDFが「すり抜けた」場合に何を直すか、層ごとに整理する。

1. ビューア側：能動機能を無効化する

最も費用対効果が高いのが、ビューアでJavaScriptと外部通信を切ることだ。

・Adobe Acrobat / Reader：拡張セキュリティ（Enhanced Security）と保護モード（Protected Mode / Protected View）を有効化し、JavaScriptをオフにする。組織配布ではグループポリシー（GPO）やレジストリで一括強制する
・外部接続の許可リスト：信頼するサイトのホワイトリスト以外への外部アクセスをブロックする設定にする
・自動更新の徹底：PDF処理系の脆弱性は継続的に発見される。ビューア・OSのレンダラ・サーバ側ライブラリを最新に保つ

2. ゲートウェイ側：CDRで無害化する

検知をすり抜ける未知のペイロードに対する本命がCDR（Content Disarm and Reconstruction）だ。CDRはファイルを「検知」しない。すべてのPDFを信頼しない前提で、JavaScript・埋め込みファイル・起動アクション・能動的な注釈アクションを除去し、安全な要素だけで再構築する。これにより、シグネチャを持たないゼロデイにも構造的に強くなる。

CDRが除去する代表要素
・埋め込みJavaScriptとAcrobat JSアクション
・起動アクション（Launch）・外部参照アクション（GoToE）
・埋め込みファイル・添付
・自動発火する注釈アクションやフォーム送信アクション
除去後はテキスト・画像・レイアウトといった「見える文書」だけが残るため、利用者の体験を保ちつつ攻撃面を消せます。

3. ネットワーク側：外向き通信を遮断する

コールバック系・認証情報窃取系・SSRF系は、最終的に「外部への通信」で成立する。境界で次を遮断・監視する。

・外向きSMB/445・NetBIOSの遮断：NTLM認証情報の外部送信経路を断つ。クライアントのNTLM送信ポリシーも併せて制限
・外向きDNS/HTTP(S)の監視：PDFを開いた直後に発生する不審な名前解決・接続をSIEMで検知し、フォンホームを可視化する
・サーバ側PDFパーサのネットワーク隔離：PDF変換・サムネイル生成サービスは、内部リソースへ到達できないネットワークセグメントで動かし、SSRFの被害範囲を限定する

4. メールゲートウェイ：隔離と要確認

PDFの主要な配送経路はメールだ。ゲートウェイで次のポリシーを敷く。

・能動コンテンツ（JavaScript・起動アクション・フォーム送信）を含むPDFは隔離し、CDR後に配信
・外部宛のフォーム送信先を含むPDFはブロックまたは要確認
・サンドボックスでの開封挙動解析を通し、外向き通信が観測されたら配送を停止

5. アプリ・ライブラリ側：PDFパーサを安全に設定する

自社サービスがサーバ側でPDFを処理している場合（アップロード受付、変換、OCR、サムネイル生成、帳票生成など）、利用するPDFライブラリの設定が攻撃面を直接左右する。検証で頻繁に見つかる論点を挙げる。

・外部エンティティの無効化：XML系の処理を伴う場合、外部実体参照（XXE）を無効化する。XMLパーサのDTD・外部実体読み込みを明示的にオフにする
・ネットワークアクセスの遮断：PDFライブラリやレンダラが外部URL・外部ファイルを取りに行く機能を無効化する。SSRFと外部参照系を一括で潰せる
・JavaScript・起動アクションの無効化：サーバ側レンダリングでスクリプトや外部プログラム起動を実行しない設定にする
・リソース上限の設定：巨大・深くネストしたPDFによるメモリ枯渇（DoS）を避けるため、ページ数・オブジェクト数・処理時間に上限を設ける
・処理プロセスの隔離：PDF処理は最小権限のサンドボックス（コンテナ・seccomp・読み取り専用FS）で動かし、万一の脆弱性でも被害範囲を限定する

検証の着眼点
サーバ側のPDF処理は「利用者のビューアが堅いから安全」という思い込みの死角になりがちです。malicious-pdfで生成したSSRF系・外部参照系・インジェクション系のテストPDFを自社のアップロード受付や変換APIに（隔離環境で）通し、外向き通信や内部リソースへの到達が発生しないかを確認するのが有効です。

これらの層は排他ではなく多層防御として重ねる。malicious-pdfの各カテゴリは、この5層のどこで止まったかを確認するための入力になる。1つの構造的防御（CDRやライブラリのネットワーク無効化）が複数カテゴリを同時にカバーするため、「層ごとにどのカテゴリ群を引き受けるか」を表にして可視化すると、抜けが見つけやすい。

主要PDFビューア（Adobe / Foxit / Chrome / Preview）の挙動差

同じPDFでも、開くビューアで挙動は大きく変わる。下表は一般的な傾向であり、設定とバージョンで変動する点に注意してほしい。組織標準のビューアと設定を決める際の判断材料として使う。

観点 Adobe Acrobat/Reader Foxit Reader Chrome（PDFium） macOS プレビュー
JavaScript対応 あり（設定で無効化可・保護モード推奨） あり（設定で制御） 既定で実質無効寄り 基本的に非対応
外部リソース取得 設定・信頼リストに依存 設定に依存 厳しめに制限 ほぼ行わない
フォーム送信 対応（送信前に確認が入る設定が可） 対応 限定的 限定的
起動アクション 既定で警告/ブロック寄り 警告あり 実行しない 実行しない
機能の豊富さ 最も多機能（=攻撃面も広い） 多機能 ビューア機能に限定 最小限
防御運用のしやすさ GPOで一括統制しやすい 企業向け統制あり サンドボックス前提で堅い 機能が少なく事故りにくい
運用の指針
「閲覧専用で十分」な用途では、機能が少ないビューア（ブラウザ内蔵ビューアやプレビュー）ほど攻撃面が小さく事故りにくい傾向があります。Acrobatのフル機能が必要な部署では、保護モード＋JavaScript無効＋GPO統制をセットにします。「多機能＝便利」と「多機能＝攻撃面が広い」は表裏一体だと捉えるのが実務的です。

注意したいのは、ブラウザ内蔵ビューアが「閲覧」では堅くても、サーバ側でPDFを処理する別のパーサ（変換・OCR・サムネイル生成）が攻撃面として残る点だ。利用者の画面だけでなく、バックエンドのPDF処理系も検証対象に含める。

SOC/QAでの活用

malicious-pdfは、ブルーチームにとって「自社の防御を定期的に殴ってくれる、安全な的」になる。攻撃の練習ではなく、検知・無害化・隔離が想定どおり発火するかの回帰テストとして組み込むのがポイントだ。

flowchart LR G["1.生成
隔離セグメントで
67種を生成"] --> S["2.投入
メールGW/CDR/
サンドボックスへ"] S --> O["3.観測
検知/無害化/隔離/
外向き通信をログ化"] O --> M["4.集約
すり抜けカテゴリを
Faradayで管理"] M --> F["5.改善
設定・ルールを修正"] F --> G

検証ワークフロー

・生成：インターネットから隔離した検証セグメントで67種を生成。コールバック先は自社リスナーに固定
・投入：自社のメールゲートウェイ・CDR・サンドボックス・EDRに、各カテゴリのテストPDFを通す
・観測：どの層で「検知」「無害化」「隔離」が発火したか、あるいは何も起きずに外向き通信（自社リスナーへのコールバック）が成立したかをログで確認
・集約：すり抜けたカテゴリを脆弱性管理プラットフォームに登録し、対応状況をチームで共有
・改善：設定・ルールを修正し、次サイクルで再検証する

検証を回すためのKPI

検証は「やった／やらない」ではなく、定点観測できる指標に落とすと改善が回る。実務で使いやすい指標を挙げる。

・カバレッジ：7カテゴリのうち、検知・無害化・隔離のいずれかが発火したカテゴリの割合
・すり抜け件数：何も発火せず外向き通信（自社リスナーへのコールバック）が成立したテストの数
・無害化率：CDRを通したPDFのうち、能動要素が確実に除去された割合
・平均検知時間：投入から検知・隔離ログが出るまでの時間。短いほどSOCの応答性が高い
・回帰：前サイクルで潰したカテゴリが、設定変更後も止まり続けているか

これらを四半期ごとに比較すると、ビューア更新やゲートウェイ設定変更が防御を強めたのか弱めたのかが定量的に分かる。「何となく安全」を「測れる安全」に変えるのが検証の目的だ。

検証結果の集約には、80以上のセキュリティツール出力を一元管理できるFaraday徹底解説：6.5kスターの脆弱性管理プラットフォームOSS、80+セキュリティツール統合のようなプラットフォームが向く。各テストPDFの結果を「対応必要／無害化済み」として追跡でき、回帰テストの履歴が残る。

検証作業自体をAIエージェントで補助する流れも広がっている。認可されたテスト工程をサブエージェントで分担する設計はpentest-ai-agents｜Claude Code向け35の攻撃セキュリティ専門サブエージェント解剖が参考になる。ただし実行は必ず認可範囲に閉じるという前提は、PDF検証でもまったく同じだ。

観測されない＝安全、ではない
テストで「何も起きなかった」場合、防御が効いたのか、単にそのビューア/環境でそのカテゴリが発火しなかっただけなのかを区別してください。ログ（検知・無害化・隔離のいずれが動いたか）が残っていないと、「たまたま動かなかった」を「防げた」と誤認します。防御は発火した記録がある状態を目標にします。

法的・倫理的な利用範囲

malicious-pdfはBSD-2-Clauseの合法ツールだが、使い方を誤れば違法行為になる。以下を厳守してほしい。

・許可なきテストは禁止：自分が管理権限を持たないシステム・メールゲートウェイ・第三者のサーバに、許可なくテストPDFを送付・投入しない。不正アクセス禁止法・電子計算機損壊等業務妨害などに問われ得る
・対象は自社環境か書面許可の範囲：自社の検証環境、隔離サンドボックス、または書面（Rules of Engagement / 委託契約）で範囲・期間・対象が明確化されたペネトレーションテストに限定する
・コールバック先を外部に向けない：生成時のリスナー指定は自社管理のものだけ。第三者のドメインやサービスに通信を発生させない
・責任ある開示：検証で第三者製品の脆弱性を発見した場合は、悪用ではなくベンダーへの責任ある開示（Coordinated Disclosure）の手順に乗せる
・生成物の管理：テストPDFは隔離保管し、検証後に削除する。誤って共有・配布しない

境界線
「自社のセキュリティを良くするため」という動機があっても、対象が自社の管理下にない、あるいは事前の許可がない時点で、それは攻撃です。動機ではなく権限と許可の有無が合法・違法を分けます。迷ったら法務・情報システム部門に確認し、Rules of Engagementを文書化してから着手してください。

類似ツールとの比較

PDFセキュリティのツールは「生成（攻撃面の再現）」「解析（中身の検査）」「無害化（CDR）」の3系統に分かれる。malicious-pdfは生成系であり、防御運用では解析系・無害化系と組み合わせて初めて回る。

ツール 系統 役割 防御運用での位置づけ
malicious-pdf 生成 67種のテストPDFを生成 防御の実効性を測る的（入力）
pdfid / pdf-parser 解析 PDF内の能動要素（JS・起動等）を可視化 何が仕込まれているかの一次切り分け
peepdf 解析 PDF構造の対話的解析 詳細な構造調査・教育
CDR製品（各種） 無害化 能動要素を除去し再構築 配布前の本命防御
アンチウイルス/EDR 検知 既知の悪性ファイルを検知 多層防御の一層

つまり実務では、malicious-pdfで的を作り → 解析系で中身を確認し → 無害化系（CDR）と検知系がちゃんと止めるかを観測するという分業になる。生成系単体は「攻撃の再現」しかできないので、必ず解析・無害化とセットで導入する。

malicious-pdfは「攻撃の道具」ではなく「防御の物差し」として運用する。物差しだけでは家は建たない。CDR・解析・検知という工具とセットで初めて、PDF防御という建物が立つ。

よくある落とし穴

・本番・外部に向けて実行してしまう：最も重大な事故。コールバック先や投入先を本番ドメイン・第三者に向けると、検証が攻撃になる。必ず隔離環境＋自社リスナー
・「検知ゼロ＝安全」と誤認する：何も起きなかったのが防御の成果なのか、単にそのカテゴリが発火しなかっただけなのかをログで区別する
・ビューアだけ見てサーバ側を忘れる：利用者のビューアが堅くても、サーバ側のPDF変換・OCR・サムネイル生成が攻撃面として残る。バックエンドも検証対象に含める
・CDRを入れて満足する：CDRは強力だが万能ではない。ネットワーク遮断・ビューア設定・パッチ適用と多層で重ねる
・生成物を放置・共有する：テストPDFを共有ストレージやメールに載せると二次被害になる。隔離保管と確実な削除を運用に組み込む
・許可・範囲を文書化しない：口頭合意だけで第三者環境に投入しない。Rules of Engagementを文書化してから着手する

まとめ
malicious-pdfは、PDFという見過ごされがちな攻撃面を「自社の防御がどこまで止められるか」で可視化するための、ペネトレーションテスト由来の検証ツールです。攻撃手順を覚えるためではなく、CDR・ビューア設定・ネットワーク遮断・メールゲートウェイという多層防御の実効性を定期的に測る物差しとして使うのが正しい姿勢です。利用は自社環境と許可された範囲に厳格に限定し、検証結果を脆弱性管理に集約して改善サイクルに乗せましょう。PDFは「ただの文書」ではなく、設計次第で安全にも危険にもなる動的なフォーマットだという前提に立つことが、防御の出発点になります。

参照ソース

・jonaslejon/malicious-pdf（GitHub公式リポジトリ・README） — 67種のテスト分類、難読化オプション、Burp Collaborator/Interactsh連携、ライセンス（BSD-2-Clause）の一次情報
・What is Content Disarm and Reconstruction (CDR)? — OPSWAT — CDRの基本概念と、検知に頼らずファイルを無害化・再構築する仕組み
・Technical Deep Dive: Content Disarm and Reconstruction (CDR) for SOC & Blue Teams — StartupDefense — SOC/ブルーチームにおけるCDR運用とサンドボックス併用のベストプラクティス
・Encoded Malware in PDFs: Hidden Threats in Document Annotations — Sasa Software — PDF注釈・ストリームに潜む脅威と、動的解析・無害化の必要性