✔️
脆弱性の見つけ方 - 攻撃者の思考で捉える “ペネトレーションテスト”と“内製ASM”- イベントレポート
本記事は、 「脆弱性の見つけ方 - 攻撃者の思考で捉える “ペネトレーションテスト”と“内製ASM” -」 というオンラインイベント（2025年1月28日開催）のレポートです。
ペネトレーションテストとASM（Attack Surface Management）の視点からセキュリティや脆弱性を捉え、実践的な対策を行うための知見が満載となりました。
当日は500名近くの申し込みがあり、技術・セキュリティ関係者が多く参加しました。会場（配信）ではチャットにも多くの質問・コメントが寄せられ、非常に盛り上がったセッションとなりました。
セッション1: ベールに包まれたぺネトレーションテストの正体とは？〜EDRの回避方法を添えて〜（ 小竹さん）
1. ペネトレーションテスト vs 脆弱性診断
小竹さんは、脆弱性診断とペネトレーションテストの違いについて「攻撃者目線という点は共通しているが、対象範囲や目的で区別される」と述べました。
脆弱性診断
システム全体を満遍なくチェック
既知の脆弱性がないかを発見するためにツール or 手動で行う（ツール診断 / 手動診断）
攻撃シナリオに縛られず、幅広いチェックリストをカバー
ペネトレーションテスト
攻撃者が狙いそうなシナリオ（例: 特定システムへの侵入、機密情報の奪取など）に基づき、侵入可能性を深堀り
“突破できるか” “実際にどの程度侵害可能か” を重視
限られた時間の中で、目的達成を試みる
「攻撃者がどのように侵入・横展開をするのか、ストーリーに基づいて実施するのがペネトレーションテスト」と強調。 一方で、実際のサービスやベンダー名でも「脆弱性診断」「ペネトレーションテスト」は混在しがち。今回はあくまで一般的に解釈される内容として紹介したとのこと。
2. EDR（Endpoint Detection & Response）の回避手法
小竹さんの後半では、企業端末に導入されることの多いEDRを、攻撃者はどう攻略してくるのかという話題に踏み込みました。
EDR回避（EDR Bypass）
標的PCにEDRがインストールされていても、攻撃者はEDRが信頼するプロセスや署名を悪用して回避を試みる
実際の攻撃シナリオでも、侵入後にEDRを無力化して横展開することは珍しくない
具体的な手法として、以下4つの例が挙げられました。
サポートが不十分な言語を使う
EDRはバイナリ系の解析に強いが、スクリプトやPHPなどは未対応の場合あり
例えばPHPインタプリタを持ち込んで実行すると、検知されない場合がある
脆弱なカーネルドライバを悪用（BYOVDテクニック）
正規署名付きだが脆弱性を含むドライバを手動インストール → その脆弱性でカーネル権限を取得
EDRプロセスやフックを無効化
Dockerコンテナを用いる
EDRはホスト側プロセスを監視するが、コンテナ内部の活動までカバーしない場合がある
ホスト上でDockerを利用できれば、コンテナの中でマルウェアを動かし外部サーバへ通信
Windows Sandbox
Win10/Win11の「サンドボックス機能」で隔離環境を実行し、そこに攻撃コードを展開
EDRが監視対象外のため検知を回避
サンドボックス終了とともに痕跡が消える
「これらの回避手段は攻撃者が実際に使うものであり、防御側やペネトレーションテスト側も把握しておかないと、“EDR入れとけば大丈夫” という誤解が生じる」と解説。 今後の対策としては、BYOVDドライバをブロックリストで管理したり、コンテナやサンドボックスを見越したディフェンスを検討すべきと訴えました。
ポイント
・EDRだけでは完全防御が難しい。攻撃者はOS標準機能や正規署名などを利用して回避
・ペネトレーションテストでは、こうしたEDR迂回技術まで試すことで、実際の高度攻撃に近い検証ができる
・企業は「EDRの盲点」を理解し、他のセキュリティ層・ガバナンスと組み合わせて多層防御を整える必要
セッション2: 攻撃者の目線で社内リソースはどう見えるのかをASMで実現する（hikae さん - freee）
1. ASM（Attack Surface Management）の必要性
freee では、会計・人事労務など多数の SaaS プロダクトを展開しており、アタックサーフェイス（攻撃可能領域）も広い。 ホワイトボックス視点で 「実際に攻撃者が行う偵察を、社内でより高度にやりたい」 という目的で、ASMを内製化したとのこと。
攻撃者の流れ
偵察フェーズ：OSINTなどで攻撃対象のドメインやネットワーク、社員情報を特定
武器調達：攻撃スクリプトやフィッシングメールを作成
侵入・横展開：発見した脆弱性を狙い本番データを奪取
「社内外から見えているサービスを、継続的に洗い出し、危険度や削除漏れを発見して早期対処したい」―― これが ASM 導入の背景。
2. freee が内製した ASM “fASM (仮) ” のアーキテクチャ
コレクター（Discovery）
AWS Route53 や ALB、CloudFront、あるいは Entra ID などの各APIを叩き、
レコード・IP・エイリアスを収集 → どのリソースがどのドメインに紐付いているか を一元管理
スキャナー（Scan & Enrich）
httpx や Nuclei などのOSSスキャナを駆使し、ドメインごとに http ポートや Web技術を検出
Subdomain Takeover（CNAMEが404等）やHTTP misconfigなどを自動検知
差分検知 & 通知
ダイナモDBで過去状態を保持し、新規に増えたリソース、逆に削除漏れのリソースが見つかると、Slack 通知
LLM で差分を要約し、危険度を推定する試みも
3. 具体的なリスク事例
サブドメインテイクオーバー
例）
C.freedomain.co.jpの CNAME先が Github Pages なのに、404エラー → 攻撃者が同名レポジトリを作ると乗っ取り可能過去には
go.jpドメインでも類似の問題が起こっており、特に廃止済みドメイン/キャンペーンサイト は要注意削除したはずの IP / 開発環境 が依然として公開状態
攻撃者が再割り当てされたIPを取得し、 そこへCNAMEを指す形で悪用
ポイント
・ホワイトボックスアプローチ（社内クラウドAPIを参照）でスキャン精度を高める
・ドメイン収集・ポートスキャンだけでなく、 “なぜそのリソースが存在するのか” まで可視化しないと運用が大変
・ASMを内製し、1日1回の差分チェック + LLMで要約し、速やかに対処
Q&A ダイジェスト
小竹さんに対して
Q. EDRの監視を回避するDocker/Windows Sandboxへの対策は？
現状、ホストEDRはコンテナ/サンドボックス内部までは見えない
対策には「ネットワーク段階での制御」や「最初にコンテナ利用を発見」する監視仕組み等が考えられるが、確立した手法は多くない
Q. パスキーを悪用したペネトレーション事例はある？
まだ明確には把握していない。攻撃側が端末や鍵を直接奪取しない限りは難しい印象
hikaeさんに対して
Q. ASMでウェブアプリ診断も可能？
現状はあくまでサブドメイン・ポート・CNAMEなどの偵察が中心だが、スキャン結果を外部のダストツールと連携し自動診断を計画中
Q. 差分をLLMで解析しているが、誤検知などはどう？
誤検知はある程度あるため、最終的には手動バリデーションが必要
ただし、LLMのおかげで「重要そうな差分」を優先的に人間がチェックでき、運用効率は上がった
Q. DNSレコードを他部門が勝手に増やした場合は？
route53などTLD管理をSREが centralized に行うことで、勝手に増えたリソースも収集対象になる
収集した情報を差分管理することで、他部門のオペレーションもキャッチアップ可能
まとめ・所感
ペネトレーションテスト
脆弱性診断とは一味違い、目的達成シナリオに重きを置く
EDR等を含む実践的な防御突破を試すことで、本当の攻撃シナリオに近い検証が可能
EDR回避手法（BYOVD・Docker・Windows Sandboxなど）は現実的に攻撃者が使っている
内製ASM
攻撃者が最初に行う“偵察フェーズ”を社内で先取りする仕組み
単なるドメイン列挙だけでなく、クラウドAPIをホワイトボックス的に収集 → 差分監視 → 改修
Subdomain Takeover や開発環境の不備にいち早く気づき、事故を防ぐ
Yardでは、AI・テック領域に特化したスポットコンサル サービスを提供しています。
興味がある方は、初回の無料スポットコンサルをお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...