研究者Alex Teixeira氏によると、Microsoft Defender XDRで新たに発覚した検知の隙間により、セキュリティチームがコマンド・アンド・コントロール(C2)トラフィックをはじめとする悪意ある外部通信を、気づかないまま見逃している可能性があるといいます。
この欠陥は、DefenderのDeviceNetworkEventsテーブルがIPv4マップドIPv6アドレスをどう分類するかという点に起因します。これはWindowsシステムのデュアルスタックネットワーキングにありがちながら、見落とされやすい現象です。
DefenderのDeviceNetworkEventsテーブルを基にした検知クエリやハンティングクエリの多くは、インターネット向け通信を絞り込むためにRemoteIPType == "Public"という条件で外部トラフィックをフィルタリングしています。
Teixeira氏がこの手法に偽陰性を生む問題を発見したのは、あるパープルチーム演習中のことでした。Webプロキシによる制御を回避するC2チャネルを捕捉するはずのアラートが、攻撃トラフィックがログに記録されていたにもかかわらず発火しなかったのです。
根本原因は、現代のWindowsアプリケーションが頻繁にデュアルスタックソケットを生成し、IPv4とIPv6の両方で同時に通信を行っている点にあります。
この場合、宛先IPが正真正銘の公開アドレスであっても、Defender XDRはその接続のRemoteIPTypeを「Public」とはタグ付けしません。代わりに、RFC 4291に定めるIPv4マップドIPv6アドレス(::ffff:8.8.8.8のような形式)を示すFourToSixMappingとしてレコードを分類します。
RemoteIPType == "Public"のみで厳密にフィルタリングするクエリや検知ルールは、すべてのFourToSixMappingレコードを暗黙のうちに除外してしまい、潜在的なC2トラフィックを含む外部通信全般に対して構造的な盲点を生み出します。
Teixeira氏は、公開先へのトラフィックをすべて検知するKQLクエリをAIチャットボットにどう書かせるかについても検証しました。提案されたクエリは、プライベートIPを除外するために組み込み関数のipv4_is_private()に依存していました。
ところが、::ffff:プレフィックス付きのFourToSixMapping形式のアドレスにこの関数を適用すると、trueやfalseではなくnullが返されます。
KQLはnullを真とも偽とも扱わないため、これらのイベントは結果から除外されてしまいます。つまり、AIが生成したクエリであっても、同じ検知の隙間を再現してしまうということです。
Teixeira氏は、検知エンジニアに向けて次の2つの是正策を推奨しています。
同氏はまた、一定の時間枠内で両方のタイプにまたがるRemoteIPの値を突き合わせ、対応する「Public」レコードを持たない「FourToSixMapping」のみのエントリーを洗い出す診断用KQLクエリも公開しました。これは、防御側が自らのテナントで見逃されたイベントを監査するための実践的な手段となります。
FourToSixMappingを考慮せずにリモートIPの分類だけを頼りに構築された検知ルール、ベースライン、KQLクエリはすべて、C2ビーコニングやデータ窃取といった攻撃者による外部向けトラフィックを見逃すリスクを抱えています。これはまさに、攻撃者がプロキシやEDRの可視性を回避するために悪用する類の隙間なのです。
より強固な予防的防御で、重大インシデントと金銭的損失を未然に防ぎましょう。15,000のSOCが利用するライブ脅威フィードを統合
翻訳元: https://cyberpress.org/microsoft-defender-xdr-blind-spot/
