現代のサイバーセキュリティにおいて、EDR（Endpoint Detection and Response）はもはや不可欠な存在となりました。しかし、ただ導入しただけではその真価は発揮されません。私たちは、EDRが生成する膨大なログをどのように読み解き、隠れた脅威の兆候を捉えるべきでしょうか。その強力な羅針盤となるのが、MITRE ATT&CKフレームワークです。
このブログでは、EDRとMITRE ATT&CKを組み合わせた脅威ハンティングの実践について、実務的な視点から解説します。
脅威モデル：標的型攻撃の兆候を探る
まず、私たちがEDRで検出したい脅威とは何か、その全体像を理解することが大切です。多くのサイバー攻撃、特に標的型攻撃は、特定の攻撃段階を経て目的を達成しようとします。MITRE ATT&CKフレームワークは、これらの攻撃者の行動（Tactic）と具体的な手法（Technique）を体系的に整理しており、私たちの脅威モデルの強力な基盤となります。
一般的な標的型攻撃は、以下のTacticに沿って進行することが多いでしょう。
- Initial Access (初期アクセス): 組織のネットワークへの最初の侵入経路を確立する。
- Execution (実行): 攻撃コードやマルウェアを実行する。
- Persistence (永続化): システムの再起動後もアクセスを維持できるようにする。
- Privilege Escalation (権限昇格): より高い権限を獲得する。
- Defense Evasion (防御回避): セキュリティ製品による検出を回避する。
- Credential Access (認証情報へのアクセス): ユーザー名やパスワードなどの認証情報を窃取する。
- Discovery (内部偵察): システムやネットワークの情報を収集する。
- Lateral Movement (横展開): ネットワーク内の別のシステムにアクセスする。
- Collection (収集): 目的の情報を集める。
- Exfiltration (持ち出し): 収集した情報を外部に送信する。
- Impact (影響): データ破壊やシステム停止など、最終的な目的を達成する。
これらのTacticを念頭に置くことで、EDRログから何を監視すべきか、具体的なDetection Engineeringの方向性が見えてきます。
攻撃シナリオ：内部ネットワークへの侵入から情報窃取まで
では、より具体的なシナリオで考えてみましょう。ある組織がフィッシング攻撃を受け、内部ネットワークの情報が窃取されるまでの一連の流れを想定します。
graph TD
A["Initial Access: Phishing T1566.001"] --> B{"Execution: PowerShell T1059.001"};
B --> C{"Persistence: Registry Run Keys T1547.001"};
C --> D{"Credential Access: LSASS Memory T1003.001"};
D --> E{"Lateral Movement: PsExec T1021.002"};
E --> F{"Collection: Data from Network Share T1005"};
F --> G{"Exfiltration: Exfiltration Over C2 Channel T1041"};
このシナリオでは、攻撃者は以下のような手順を踏む可能性があります。
- フィッシングメール (Initial Access – T1566.001): 悪意ある添付ファイル（例：マクロ有効化されたOffice文書）を送りつけ、ユーザーに実行させる。
- PowerShellによるペイロード実行 (Execution – T1059.001): 添付ファイルが、難読化されたPowerShellスクリプトを実行し、バックドアをインストールする。
- レジストリによる永続化 (Persistence – T1547.001): バックドアは、
HKCU\Software\Microsoft\Windows\CurrentVersion\Runなどのレジストリキーに自身を登録し、PC再起動後も起動するように仕向ける。 - LSASSメモリからの認証情報窃取 (Credential Access – T1003.001): 権限昇格後、バックドアは
lsass.exeのメモリダンプを取得し、平文のパスワードやハッシュを窃取する。 - PsExecによる横展開 (Lateral Movement – T1021.002): 窃取した認証情報を用いて、PsExecなどの正規の管理ツールを悪用し、他のサーバーへ侵入する。
- ネットワーク共有からのデータ収集 (Collection – T1005): 侵入したサーバーの共有フォルダや重要なファイルサーバーから機密情報を収集する。
- C2チャネル経由のデータ持ち出し (Exfiltration – T1041): 収集した情報を圧縮・暗号化し、C2サーバーへの通信チャネルを悪用して外部に送信する。
検出と緩和：EDRが捉える痕跡と対応
上記の攻撃シナリオに対して、EDRはどのように脅威を検出し、私たちはどう緩和策を講じるべきでしょうか。
EDRによる検出のポイント
- PowerShellの実行: 不審なPowerShellプロセスの実行、特に難読化されたコマンドライン引数、ネットワーク接続を伴うPowerShellの起動は警戒が必要です。
- EDRはPowerShellのScript Block LoggingやModule Loggingを有効にすることで、スクリプトの内容を詳細に記録できます。
- レジストリ改変: Runキーなど永続化に悪用されやすいレジストリキーへの不審な書き込みを監視します。
- LSASSプロセスへのアクセス:
lsass.exeへのプロセスインジェクションやメモリ読み込みを試みるプロセスは、資格情報窃取の典型的な兆候です。特に、procdump.exeなどの正規ツールであってもlsass.exeをターゲットとする場合は要注意です。 - PsExecの利用:
PsExec.exe自体は正規ツールですが、不審なユーザーやプロセスからの起動、あるいは異常な宛先への接続は横展開の可能性を示唆します。 - 不審なネットワーク通信: C2サーバーへの通信パターン（例：特定のポート、不審なドメイン、異常な通信量）はEDRやネットワークFWで検出可能です。
暗号やプロトコルの誤用と安全な代替
攻撃者は、しばしば安全でないプロトコルや暗号の誤用を悪用します。あるいは、私たち自身のシステムにそうした脆弱性があれば、検出の難易度を上げてしまいます。
誤用例とEDRが捉える兆候
- 平文での認証情報送信:
ftpやtelnetなどの平文プロトコルでのログイン試行や、スクリプト内でパスワードがハードコードされている場合。# 誤用例: FTPで平文パスワードを送信 ftp -inv example.com <<EOF user user_name plain_password put local_file.txt remote_file.txt bye EOF
> Note: EDRは、ftp.exeやtelnet.exeプロセスのコマンドライン引数、あるいはネットワーク通信の内容（SNI/DPI機能があれば）から平文での認証情報送信を検出できる場合があります。また、ファイルシステムのスキャンでスクリプト内のハードコードされたパスワードを発見することもあります。 - 脆弱なハッシュアルゴリズムの利用: ファイルの整合性チェックにMD5などの脆弱なハッシュ関数を使っている場合。攻撃者はこれを悪用し、悪意あるファイルと正規ファイルのハッシュ衝突を引き起こす可能性があります。
# 誤用例: MD5でファイルの整合性をチェック md5sum important_file.zip
> Note: EDRはプロセスの実行ログからmd5sumコマンドの利用を検出できますが、それが脆弱であることまでは直接判断できません。これは「セキュリティベストプラクティスからの逸脱」として運用側で対処すべきです。
安全な代替と推奨されるプラクティス
HTTPS/SSH/SMBv3の利用: 認証情報や機密情報を扱う通信には、TLSで保護されたプロトコル（HTTPS, SSH, SMBv3など）を常に利用します。
# 安全な代替: SSHで安全にファイルを転送 scp -P 22 local_file.txt user@secure.example.com:/path/to/remote_file.txt
# 安全な代替: PowerShellでInvoke-WebRequestを使いHTTPS通信 Invoke-WebRequest -Uri "https://secure-api.example.com/data" -Method Get -UseBasicParsing
- 強力なハッシュアルゴリズムの利用: ファイルの整合性チェックにはSHA256以上の強力なハッシュ関数を利用します。
# 安全な代替: SHA256でファイルの整合性をチェック sha256sum important_file.zip
鍵/秘匿情報の取り扱い
鍵や認証情報は攻撃者が最も狙う対象です。これらの不適切な扱いはEDRログにも痕跡として残ることがあります。
- 誤用例:
- ソースコードや設定ファイルにハードコードされたAPIキーやパスワード。
- 環境変数に平文で設定された秘密情報。
- 共有フォルダに置かれた秘密鍵ファイル。
- EDRが捉える兆候: EDRはファイルシステムのスキャンやプロセスのメモリ内容、コマンドライン引数から平文の秘密情報や不審な鍵ファイルのアクセスを検出する可能性があります。
- 安全な代替:
- 集中型秘匿情報管理 (KMS/Secrets Manager): AWS KMS, Azure Key Vault, HashiCorp Vaultなどのサービスを利用し、アプリケーションから動的に秘匿情報を取得します。
- 最小権限の原則: 秘匿情報へのアクセスは、最小限の権限を持つロールやユーザーに限定し、アクセス元IPや時間帯などの条件も付与します。
- ローテーションの自動化: 鍵やパスワードは定期的に自動でローテーションされる仕組みを導入します。
- 厳格な監査: 秘匿情報へのアクセスログをKMS/Secrets ManagerからSIEMやEDRに連携し、異常なアクセスパターンを監視します。
# 安全な代替: AWS Secrets Managerから秘密情報を取得 aws secretsmanager get-secret-value --secret-id "my-app-secret" --query SecretString --output text
> Note: EDRはKMSやSecrets Managerへのアクセス自体を検出するかもしれませんが、そのアクセスが正当なものかどうかはIAMロールやポリシーと組み合わせて判断する必要があります。不審なプロセスやユーザーからのアクセスは警戒すべきです。
運用対策：現場の落とし穴と継続的な改善
EDRとATT&CKベースの脅威ハンティングは強力ですが、運用にはいくつかの「落とし穴」があります。
誤検知 (False Positive) への対応
正規の管理ツール（PsExec, PowerSploitの一部など）は、攻撃者にも利用されやすいため、EDRが誤って脅威として検知することがあります。
Note: 業務でこれらのツールを使用している場合は、EDR側でホワイトリスト化するか、あるいは「誰が、いつ、どこから、何を対象に」利用したかを厳密に監視するルールを設定し、異常な利用を検出できるようにチューニングが必要です。ベースラインを確立し、逸脱を捉える考え方が大切です。
検出遅延 (Detection Latency) とインシデントレスポンス
EDRがイベントを収集し、サーバーに送信、解析され、アラートが生成されるまでにはタイムラグが発生します。この遅延は、攻撃が進行中の場合、迅速な対応を妨げる可能性があります。
Note: 重要なシステムのアラートは、可能な限りリアルタイムに近い形でSOC/CSIRTに通知されるよう構成し、初期対応（プロセス停止、ネットワーク隔離など）を自動化することも検討しましょう。
可用性トレードオフ (Availability Trade-offs)
EDRエージェントは、システムのCPUやメモリを消費します。特に古いシステムやリソースが限られている環境では、パフォーマンス低下を引き起こし、システムの可用性に影響を与える可能性があります。
Note: 導入前には十分なPoC (Proof of Concept) を実施し、様々なワークロード下でのパフォーマンス影響を評価することが不可欠です。段階的な導入や、システムのタイプに応じた設定調整も有効です。
継続的な脅威ハンティングとインテリジェンス活用
EDRのアラートに頼るだけでは不十分です。既知の攻撃パターンに合致しない、巧妙な攻撃を見つけるためには、プロアクティブな脅威ハンティングが必要です。
Note: 最新の脅威インテリジェンス（TTPs, IoCs）を常に収集し、EDRログと照らし合わせて「何かおかしい」イベントを探し出す習慣をつけましょう。定期的なRed TeamingやPurple Teamingで自組織の防御能力を評価することも大切です。
まとめ
EDRとMITRE ATT&CKを組み合わせた脅威ハンティングは、現代のサイバーセキュリティにおいて非常に効果的なアプローチです。単にツールを導入するだけでなく、攻撃者の心理や行動を理解し、EDRが生成する多様なログを戦略的に分析することで、私たちは隠れた脅威の兆候を捉え、被害を未然に防ぎ、あるいは迅速に最小化できます。
今回触れたように、鍵や秘匿情報の適切な管理、プロトコルの安全な利用といった基本的なセキュリティプラクティスも、検出能力を高め、攻撃機会を減らす上で不可欠です。そして何より、現場の落とし穴に注意し、継続的な改善と学習を続けることが、私たちのデジタル資産を守る上で最も重要な鍵となるでしょう。さあ、皆さんも今日からATT&CKフレームワークを片手に、EDRログを深く掘り下げてみませんか？ きっと新たな発見があるはずです。
