境界防御の終焉：VPNログとAD認証の「微細な不整合」を突くフォレンジック・アーキテクチャ
VPNのログを見ていると、時折、非常に「居心地の悪い」接続履歴に遭遇する。地理的に不可能なログイン？ そんなものは現代のC2プロキシを噛ませた攻撃者にとって、もはやノイズにもならない。
真のインシデントレスポンス（IR）は、VPNゲートウェイが記録する「接続元IP」と、Active Directory（AD）が生成する「認証成功イベント」の間の、わずか数百ミリ秒のズレや、プロトコル層に隠されたメタデータの不一致を突くところから始まる。今日は、表層的なログ監視を超えて、アカウント侵害を確実に炙り出すための「突き合わせ」の技術論を語ろう。
—
1. ログの断絶と「認証の影」を追う
多くの組織が陥る罠は、VPNログ（セッションログ）とADログ（認証ログ）を個別に相関分析しようとすることだ。攻撃者は、VPNセッションの確立と、内部リソースへの認証要求の間に、あえて遅延を挟むことがある。また、現代の洗練された攻撃者は、VPNセッションを確立したIPアドレスと、ADへKerberosチケットを要求する際のソースIPを、巧妙に論理分割する。
ここで重要になるのが、「VPNセッションID」と「ADのLogonID（4624イベントのTargetLogonId）」の動的マッピングだ。
認証イベントの分析戦略
VPNのログにある Client-Source-IP が、ADのセキュリティイベントID 4624 の IpAddress と完全に一致することを前提にしてはならない。むしろ、以下の項目を多次元で突き合わせる必要がある。
- Workstation Name: VPNクライアントのホスト名と、認証リクエスト元のワークステーション名が不一致でないか。
- Authentication Package:
NTLMかKerberosか。VPN経由で突然NTLMが増えた場合、それはKerberosのチケットキャッシュをクリアせざるを得ない状況、つまり「別環境からの侵入」を強く示唆する。 - Source Port: VPNセッションの確立に使用されたソースポートの挙動。頻繁にポートがローテーションされる場合は、自動化された攻撃スクリプトが背後に存在することを疑うべきだ。
—
2. メモリフォレンジックによる認証プロセスの「真実」
ログが改ざん、あるいは削除されている可能性を考慮すれば、最終的な判断基準はライブメモリ上の lsass.exe 内にある。
特に、攻撃者が mimikatz 等を用いてKerberosチケットを抽出（Pass-the-Ticket）している場合、メモリ上のチケットキャッシュには、VPNゲートウェイを経由した「正規の認証」とは異なる痕跡が残る。Volatility を使用したメモリ解析において、以下のプラグインで何を見るべきか。
# lsass.exeプロセスのダンプと、認証に関連するモジュールの抽出
# 攻撃者が利用した不正なセッションキーの有無を確認する
volatility -f memory.dmp --profile=Win10x64_XXXXX lsadumpここで注目すべきは、認証に使用された Logon Session の権限レベルだ。VPN経由の正当なユーザーであれば、通常は「ネットワークログイン」の権限が割り当てられるが、アカウント侵害者は、メモリ上で Interactive や Batch と誤認させるためのトークン操作を行うことが多い。
—
3. 実践：相関分析のためのクエリ設計
SIEMやログ分析基盤（Elasticsearch等）で、VPNとADの乖離を特定するためのクエリロジックを提示する。ポイントは、「VPNセッション開始の直後にAD認証が発生しているか」だけではなく、「AD認証の後にVPNセッションが切断されているか」といった逆説的な相関だ。
// Azure Sentinel (KQL) での相関分析例
// VPNログインの直後に発生した不自然なAD認証を抽出する
let VpnLogs = SigninLogs
| where AppDisplayName == "VPN_Gateway_App"
| project TimeGenerated, UserPrincipalName, IPAddress, CorrelationId;
let AdLogs = SecurityEvent
| where EventID == 4624
| project TimeGenerated, TargetUserName, IpAddress, LogonId;
VpnLogs
| join kind=inner (AdLogs) on $left.UserPrincipalName == $right.TargetUserName
| where TimeGenerated > TimeGenerated1 - 5m // VPN確立から5分以内の認証のみを抽出
| where IPAddress != IpAddress // IPが一致しない＝プロキシ経由の可能性
| project TimeGenerated, UserPrincipalName, IPAddress, IpAddress—
4. 防御のアーキテクチャ：次なるフェーズへ
もはや単なる「多要素認証（MFA）」は十分な防壁ではない。攻撃者はMFAプロンプトを執拗に送り続ける「MFA Fatigue」や、セッションCookieの奪取によってMFAをバイパスする。
今後の防衛アーキテクチャは、「認証時」の検証から「セッション継続時」の継続的検証（Continuous Access Evaluation）へシフトしなければならない。
- デバイスポスチャの統合: VPNゲートウェイが、単に認証の成否だけでなく、クライアントのメモリ状態やパッチ適用状況をリアルタイムでAD（Azure AD）の条件付きアクセスと同期させる。
- 耐量子暗号（PQC）への準備: 現在のVPNプロトコル（IKEv2/IPsec）の鍵交換プロセスは、将来的な量子コンピュータによる攻撃に対して脆弱だ。現時点では、ハイブリッド暗号アルゴリズム（例：Kyber）の導入をロードマップに組み込み、通信レイヤでの「傍受後の解読」を防ぐ準備が必要だ。
最後に：フォレンジックは「違和感」の収集である
インシデントレスポンスの現場で最も信頼できるのは、ツールが出力する自動検知アラートではなく、アナリスト自身の「違和感」だ。ログの突き合わせで乖離が見つかったとき、それは単なる設定ミスかもしれないし、高度なAPT攻撃の端緒かもしれない。
だが、エンジニアとして常に意識してほしい。攻撃者は、我々が「正常」だと信じている境界線の中を、我々の正規のプロトコルを使って歩いているという事実を。その足跡を特定するには、ログの海を深く潜り、メモリの底に沈む断片を拾い上げる執念が必要だ。
セキュリティとは、終わりのない泥臭い作業の積み重ねである。しかし、その先にしか、真の堅牢なインフラは存在しない。
コメント