クラウドの「メモリ」は掴めない？現場で叩き込まれるAWS/Azureフォレンジックの真実
お疲れ様。現場でインシデント対応をしていると、よく「メモリダンプを取って解析したい」という要望が飛んでくる。オンプレミスの物理サーバーなら、ツールを差し込んでダンプを吸い上げるという力技も可能だが、AWSやAzureといったクラウド環境ではその常識が通用しない。
ハイパーバイザーはブラックボックスだ。クラウドベンダーが提供するAPIを通さずに物理メモリに直接アクセスすることは、マルチテナント環境の隔離原則上、絶対に許されない。今日は、クラウド環境におけるメモリフォレンジックの「泥臭い現実」と、攻撃者がそこをどう突いてくるか、そして我々がどう防衛すべきかを解説する。
—
1. なぜクラウドのメモリ取得は「スナップショット」頼みなのか
クラウド環境において、メモリダンプを取得する唯一の現実的な手段は「スナップショット」だ。しかし、これには致命的な制約がある。
- 実行中の整合性: スナップショット取得の瞬間、メモリの状態は保存されるが、ハイパーバイザーレベルのフリーズが発生するため、リアルタイムの挙動追跡には適さない。
- カプセル化の壁: 仮想インスタンス上のOSからメモリを吸い出すツール（
LiMEやAVMLなど）を実行すると、当然ながら攻撃者に「フォレンジック調査中であること」を検知されるリスクがある。
攻撃者はこれを知り尽くしている。彼らは「メモリ常駐型マルウェア（Fileless Malware）」を使い、ディスクに一切の痕跡を残さず、メモリ上のプロセスを改ざんしてバックドアを維持する。メモリダンプを撮ろうとOSにログインした瞬間に、彼らは自身の痕跡を消去（Self-delete）して逃走するだろう。
—
2. 現場の盲点：攻撃者は「IAM」をメモリから盗む
攻撃者がメモリを狙う最大の動機は、インスタンスに付与された「IAMロールの認証情報」だ。
AWSであれば http://169.254.169.254/latest/meta-data/iam/security-credentials/ にアクセスすれば、一時的な認証情報が手に入る。これをメモリ上に展開して横展開（Lateral Movement）を行うのが、最近のインシデントの定石だ。
対策：SSRFを封じ込めるNginx設定
攻撃者はWebアプリケーションの脆弱性（SSRF）を突き、このメタデータサービスを叩く。これを防ぐには、アプリケーション層でのフィルタリングはもちろん、インフラ層での締め付けが不可欠だ。
# Nginx設定: SSRF対策の基本
# メタデータサービスへのアクセスを厳格に拒否する
location / {
# 攻撃者がSSRFでメタデータへアクセスするのを防ぐ
# 内部ネットワークからの不審なリクエストを遮断する設定
proxy_set_header Host $host;
# 外部からのリクエストで、メタデータIPへのプロキシを禁止
if ($http_x_forwarded_for ~* "169.254.169.254") {
return 403;
}
}—
3. 防御の要：Pythonによるメモリ保護とモニタリングの自動化
メモリダンプが取れないなら、メモリに何かを書き込まれる前に検知するしかない。以下は、AWS上で実行中のプロセスリストを監視し、不審なバイナリがメモリを占有していないかチェックする簡易的なモニタリングスクリプト（Python）の断片だ。これを Cron や Systemd で回すだけでも、攻撃者に与えるストレスは劇的に上がる。
import psutil
import logging
# 不審なプロセス名やパスを定義（シグネチャベース）
SUSPICIOUS_NAMES = ['nc', 'nmap', 'python3 -c', 'base64']
def check_memory_processes():
for proc in psutil.process_iter(['pid', 'name', 'cmdline']):
try:
cmd = " ".join(proc.info['cmdline'] or [])
# メモリ上で怪しいコマンドライン引数がないかチェック
if any(s in cmd for s in SUSPICIOUS_NAMES):
logging.warning(f"不審なメモリプロセスを検知: {proc.info['pid']} - {cmd}")
# ここで自動的にプロセス停止やアラート飛ばすなどの処理を追加
except (psutil.NoSuchProcess, psutil.AccessDenied):
continue
if __name__ == "__main__":
# 実際にはここでCloudWatch Logs等に転送する設定を入れる
check_memory_processes()—
4. プロの教訓：調査を前提としたインフラ設計を
最後に、後輩諸君へ伝えたいのは「インシデントが発生してからメモリダンプを取るな」ということだ。
1. ReadOnlyの準備: 事前にメモリダンプツール（AVML など）をS3バケットに格納し、IAMロールで「書き込みのみ」を許可した権限セットを用意しておくこと。
2. ログの外部化: メモリ上の痕跡は消される前提で、すべての実行ログを CloudWatch Logs や Azure Monitor にリアルタイムでストリーミングすること。
3. IAMのガードレール: IMDSv2 を強制すること。これだけで、SSRF経由の認証情報窃取の難易度は跳ね上がる。
クラウドフォレンジックは、物理的な証拠集めというより、「証拠を消させないための先回り」が勝負だ。メモリの中身を覗こうと右往左往する前に、攻撃者がメタデータサービスやメモリ上のプロセスをどう弄ろうとしているか、その設計図を叩き直すことから始めてほしい。
現場からは以上だ。次回のコードレビューで、169.254.169.254 へのアクセス制限が抜けていたら、容赦なく突き返すからそのつもりで。
コメント