共有フォルダの「静寂」を破るもの：SMBトラフィック解析でランサムウェアを狩る
ネットワークエンジニアとして現場に立っていると、深夜の監視室で不意に鳴り響くアラートほど心臓に悪いものはない。特に、ファイルサーバーのCPU負荷が急上昇し、ストレージのI/Oが限界突破する際のアラートは、それが「業務のピーク」なのか「悲劇の始まり」なのか、一瞬で判断が求められる。
今日取り上げるのは、ランサムウェアが共有フォルダを食い荒らす際に発生する、あの忌々しいSMBトラフィックの挙動だ。
1. ランサムウェアは「良い子」のふりをしてやってくる
ランサムウェアのファイル暗号化プロセスは、驚くほど「正当な」SMBプロトコルを悪用する。攻撃者は特別なハッキングツールを使うわけではない。Windows APIの CreateFile や WriteFile を呼び出し、ファイルシステムに対して「このファイルを開いて、内容を書き換えてくれ」と要求しているだけなのだ。
ネットワークレベルで見ると、これは以下のシーケンスが狂ったような速度で繰り返されることを意味する。
1. SMB2 TREE_CONNECT：共有リソースへのアクセス権を確保する。
2. SMB2 CREATE：対象ファイルを開く（DesiredAccess を FILE_WRITE_DATA に設定）。
3. SMB2 WRITE：暗号化されたチャンクを書き込む。
4. SMB2 CLOSE：ファイルを閉じる。
正常なオフィスワークであれば、これらのやり取りは人間がマウスを動かす速度に依存する。しかし、ランサムウェアは違う。数ミリ秒の間に数千もの CREATE と WRITE が飛んでくる。この「不自然な高頻度」こそが、我々が検知すべきシグナルだ。
2. パケットに隠された「署名」を見抜く
Wiresharkでランサムウェアの暗号化通信を眺めていると、ある特徴的なパターンに気づくはずだ。
SMB2 CREATE Requestの集中: 短時間に同一ホストから、異なるファイルパス（FileNameフィールド）に対して大量のオープン要求が飛ぶ。CreateDispositionの定数: 既存ファイルを上書きするためにFILE_OVERWRITE(0x00000003) やFILE_SUPERSEDE(0x00000000) が頻発する。- データ構造の画一化: どのファイルに対しても
WRITEのサイズやバッファの埋め方が極めて機械的であること。
これらは、特定の SMB2 ヘッダーを解析することで、IDSやIPS、あるいはSIEMでの相関分析において強力な防御トリガーとなる。
3. 実践：PythonによるSMBトラフィック監視のヒント
もし、あなたがインフラの自動化やセキュリティ監視ツールの内製化に取り組んでいるなら、scapy を使ったパケットキャプチャのプロトタイプ作成をお勧めする。以下は、怪しい SMB2 CREATE 要求の頻度を監視する簡易的なコードの断片だ。
from scapy.all import sniff, TCP
from collections import Counter
# 特定のIPからのCREATE要求をカウントする簡易カウンター
request_counter = Counter()
def analyze_smb_packets(packet):
# SMB2ポート(445)のTCPパケットのみを対象にする
if packet.haslayer('SMB2_CREATE_Request'):
src_ip = packet['IP'].src
request_counter[src_ip] += 1
# 閾値を超えたらアラート（実運用ではバースト検知ロジックを組み込む）
if request_counter[src_ip] > 100:
print(f"[!] 警告: 異常なSMB CREATE要求を検知: {src_ip}")
# ここでファイアウォールのAPIを叩いて接続を遮断する処理を呼ぶ
# ネットワークインターフェースを監視開始
sniff(filter="tcp port 445", prn=analyze_smb_packets, store=0)4. 境界防御を超えた「ゼロトラスト」の考え方
境界防御だけでランサムウェアを防ぎきれる時代は終わった。今求められているのは、ネットワーク内部の「挙動」を常に疑う姿勢だ。
- SMB署名の強制:
Set-SmbServerConfiguration -RequireMessageSigning $trueを設定し、中間者攻撃や不正なパケット注入を防ぐ。 - マイクロセグメンテーション: ワークステーション間でのSMB通信を禁止し、クライアントからサーバーへの通信のみを許可する。
- ファイルシステムの監査ログ: WindowsのイベントID
4663（オブジェクトへのアクセス）を収集し、深夜帯の大量書き込みを監視する。
最後に：エンジニアとしての矜持
ランサムウェアは進化し続けるが、彼らがネットワーク上で「通信」という物理法則に従う限り、必ず痕跡は残る。パケットは嘘をつかない。たとえ暗号化されて中身が読めなくても、その「通信の振る舞い」は、我々に攻撃の兆候を雄弁に語ってくれるはずだ。
皆さんのインフラが、今日も平穏無事であることを願う。もしアラートが鳴ったときは、パニックにならず、まずは落ち着いて最初の SMB2 CREATE パケットがどこから飛んできたのか、そのソースIPを追うことから始めてほしい。それが、戦いの第一歩だ。
コメント