*本ブログは自動翻訳です。詳細は英語版を参照ください。
包括的でタイムリーなアクティビティログは、クラウドにおけるセキュリティモニタリングとインシデントレスポンス を可能にする強力なツールです。しかし、Azure のログを調査している間、Vectraのリサーチャーは、ユーザーアクションの理解を複雑にし、攻撃者をすり抜ける可能性さえある、多くの欠陥に気づきました。この投稿では、これらの問題点とBlue チームの作業への影響について説明します。
Azure Monitor Logsを研究する理由
プロバイダー固有の詳細を説明する前に、クラウドとオンプレミス環境ではログの重要性が異なることに注意すべきです。
管理者は、オンプレミスのセットアップでいくつかの選択肢があります。
1. ネットワークトラフィックをタップしてアクティビティを監視したり、ネットワークエッジや個々のマシンでログを収集したりすることができる
2. ロギングとモニタリングのソリューション (ハードウェアとソフトウェア) は交換可能であり、特定のベンダー製品がうまく機能しない場合は、別の製品をインストールすることができる
クラウドではそのようなオプションはなく、プロバイダーが利用可能なログを完全に制御します。 高品質であれば、素晴らしいです。 ただし、問題がある場合は、プロバイダーが問題を解決するかどうかに左右されます。 ベンダーに問題を報告して修正を期待するか、可能であれば回避することを試みることができます。
クラウド環境での活動を監視している間、いくつかの期待があります。
- ログの構造や内容を予告なしに変更しない
- イベントのタイムリーな記録
- 完全で正確なログ記録(欠落や破損のない値）
- ログに記録されたイベントの完全なドキュメント
- 異なるログ間でイベントとユーザーセッションを関連付ける簡単な方法
- インシデント分析に使用する脅威指標のセット
アクティビティを分析する場合、すべてのログソースおよびすべてのイベントタイプで、以下のデータが一貫して利用可能である必要があります。
- 作戦名と内容
- ユーザーIDとセッション情報
- 知的財産権
- ジオロケーション
- デバイス情報
- 脅威と評判の指標
本質的には、誰がいつ何をしたか (そして他に何をしたか) を把握できるようにする必要があります。 残念ながら、これらの期待はAzureログで常に満たされるとは限りません。
Azureのイベント監視方法
Azureには、成熟したイベント分析とモニタリングの製品群があります。
Microsoft Sentinelは、様々なソースからログを取り込むネイティブのSIEM製品です。ビルトインの検出セットがあり、カスタム検出を定義することもできる。
Azure Log Analyticsは 、不審なイベントのアドホックな調査に最適なログ分析プラットフォームです。
どちらも、強力なログクエリおよび分析言語であるKustoをサポートしています。 さらに、サードパーティのソリューションを使用してログを監視し、解釈することもできます。
Azure のログインフラストラクチャは広大で、数百とは言わないまでも数十のログソースがあります。 これらすべてを説明するのは不可能なので、Azure の IAM ソリューションである Azure AD (現在の Entra ID) とクラウド SaaS オフィス スイートである Microsoft 365 によって生成されたログに焦点を当ててみましょう。
Entra ID ログカバー：
- サインイン：インタラクティブユーザー、非インタラクティブユーザー、サービスプリンシパル、および管理されたアイデンティティのサインインアクティビティを網羅する複数のログ
- 監査：重要なディレクトリ操作の記録
- プロビジョニング：第三者サービスによるユーザーのプロビジョニングに関するデータ
これらのログはグラフAPIを通じてアクセス可能で、現在、基本バージョン (1.0) とベータ版が存在し、それぞれ異なるスキーマを持ちます。
Microsoft 365 アクティビティ ログは、Management Activity API を通じて消費され、さまざまな種類のイベントに対していくつかのログが提供されます。
- Audit.AzureActiveDirectory：Entra ID サービスからのイベント(Graph API 経由で利用可能なものと同様）
- Audit.Exchange：Exchangeイベント
- Audit.SharePoint：SharePointのアクティビティ
- Audit.General：他のどのログにも当てはまらないその他のほとんどの行動
- DLP.All：情報漏洩防止イベント
Azure Monitor Logの既知の問題
Azure Log Monitoring の重要性について説明したので、これらのログで発生したいくつかの問題を詳しく掘り下げてみましょう。それらを認識すると、より適切な分析クエリを作成し、なぜ物事がそのように動作するのかを考えるのに無駄な時間を費やすことが少なくなる可能性があります。
すべてのセキュリティアナリストとアーキテクトが注目すべき具体的な課題には、次のようなものがあります。
- 流動的なスキーマ
- ログフロー
- イベント遅延
- 見つからないイベント
- Logging tax
- ログに記録されないイベント
- 不十分な文書
- 予告なしの変更
- IDの不一致
- IPの不一致
- 地理位置情報の不一致
- デバイス情報の不一致
- 壊れた値
それぞれの詳細を見てみましょう。
流動的なスキーマ
一部のログ (管理アクティビティ API など) のスキーマは「流動的」です。 これは、新しい操作の一意のパラメータが新しい列としてログに追加されることを意味します。
そのため、Log Analytics であっても管理が困難になります。(「最大 500 列の制限に達しました」というエラーが表示されることが確認されています)。 外部 SIEM でイベントを使用することを検討している場合は、使用する列を選択する必要がある場合があります。また、Azureが追加する新しい列を予測することは不可能です。
より良い方法は、すべてのログに静的スキーマを使用し、変動性を処理するために構造フィールド (JSON など) を追加することです。
ログフロー
Azure では時折ログの停止が発生します。 実際、私たちは過去数年間にいくつかの光景を目にしました。1 件は数週間続き、偶然に発見されましたが、Microsoft は通常、そのような状況で顧客に通知するのが得意です。
問題は、停止中は環境内のアクティビティがまったく見えなくなる可能性があることです。 停止のアナウンスを見逃した場合でも、問題があることを示すものは何もありません。 Azure のサービスの健全性を常に把握し、場合によってはログ フローを追跡する監視ソリューションに投資することが重要です。
停止は意図的に行われる場合もあります。 ログ構成はインバンドで制御されており、管理者のアカウントが侵害されると、攻撃者が大規模に (例: Set-AdminAuditLogConfig 経由)、またはよりきめ細かくステルス的に (例: Set-Mailbox-AuditEnabled 経由) でログを無効にする可能性があります)。
このような問題を軽減するには、ログ フローと構成の変更を監視することが不可欠です。 少数の許可されたユーザーだけがログ設定を変更できるようにする必要があります。 偶発的または意図的なログの無効化によって重大な悪影響が生じるため、Azure がログ構成にさらに多くの制御を追加することが望ましいと考えられます。
イベント遅延
Microsoft は、ログ イベントが利用可能になる予想時間を公開しています。 グラフ API の取り込み時間は3 分未満であると主張されています。 私たちの経験では、これらのソース内のイベントが表示されるまでに最大 30 分かかる場合があります。
Management ActivityAPI イベントの公開されている一般的な可用性は60～90 分です。 実際には、私たちが観察した遅延はさらに重大です。 最近取得した最大値のいくつかを以下に示します。特定の時間は 24 時間をはるかに超えています (max_delay 列には、イベントの作成からログに記録されるまでの最大時間が含まれます)。
このような遅延時間は持続不可能です。 一部の攻撃者は非常に素早く動きます。 検出ツールによる処理、外部 SIEM による取り込み、SOC 担当者による反応に必要な時間を考慮に入れると、多くの場合、青チームが遅れることは明らかです (ほぼ仕様通り)。
攻撃者がツールを自動化すればするほど、状況はさらに悪化します。Azure は、ログの高速可用性を優先する必要があります。そうしないと、防御側はインシデントに対応することしかできず、インシデントを阻止することはできません。ログ レコードが外部SIEMに転送される場合、イベントの遅延に対処するのはさらに難しくなります。Log API 呼び出しは時間範囲をパラメーターとして受け取るため、遅延イベントを見逃さないように、レコードの損失を受け入れるか、重複する時間範囲をクエリして重複レコードを削除する必要があります。
見つからないイベント
いくつかのイベントタイプは、複数のログで見つかるかもしれない。例えば、サインインの記録は、Graph API と Management Activity API の両方で利用可能です。両方のソースで同じイベントのレコードを比較すると、時折違いが明らかになります。
最近の事件調査から抜粋した次の例を考えてみましょう。 これらはすべて攻撃者による同じアクションに対応していますが、ログに記録されたレコードは正確には一致しません。
Graph API (ベータ版 - Azure Portal内)：
グラフAPI(v1.0）：
管理アクティビティ API の AuditAzureActiveDirectory：
この種の不一致は再現したり説明したりするのが困難ですが、ログ分析を行う際には注意する必要があります。 記録が失われる可能性があり、何が起こったのかをより完全に把握するには複数のログの分析が必要になる場合があります。
Logging tax
多くのロギング・イベント・タイプと詳細は、より高い料金のティア(E5やP2など）でしか利用できません。例えば、MailItemsAccessedイベント、サインインログのリスク詳細などです。これは多くのお客様にジレンマをもたらします - 低コストか環境内のアクティビティに対するより良い可視性のどちらかを選択することを意味します。
これは強制される良い選択ではなく、基本的なセキュリティ機能 (ログなど) はすべてのクラウド顧客が利用できるべきであると私たちは考えています。 米国上院議員ロン・ワイデンが最近述べたように、「ハッキングされないために必要なプレミアム機能のために人々に料金を請求することは、車を売ってからシートベルトやエアバッグに追加料金を請求するようなものです。」
この可視性の欠如により、私たちが調査しなければならなかった Vectra AI 顧客の多くのインシデントで困難が生じました。 Microsoft 自体が対処しなければならなかった APT Storm-0558による最近の公的な侵害により、この問題が明るみに出ました。 この事件の結果、Microsoft はこの秋にすべての顧客にログへのアクセスを拡大することに CISA と合意しました。
すぐに改善されることを願っています。その間に、あなたがライセンスを通じてアクセスできるロギングが、あなたの組織のIRニーズにとって適切であることを確認する必要があります。そうでなければ、アップグレードの時期です。重要なデータが利用できない場合、その一部(IPレピュテーションやジオロケーション情報など）はサードパーティのソースから取得することができます。
ログに記録されないイベント
Azure は「偵察天国」であり、まれな例外を除いて、構成やデータの読み取りに対応する「get」タイプのイベントが発生します。 2023 年 10 月の時点で、Graph API 呼び出しを記録する新しいログが導入され、偵察操作の一部がカバーされています。 ただし、他の API を介した列挙は防御者には見えないままです。
これは、攻撃者がクラウド環境にアクセスすると、防御側に見られることなく、ほとんどの情報 (ユーザー、サービス、構成) を列挙できることを意味します。 これには大きな盲点があります。私たちのテストでは、ほとんどのオープンソース M365/AAD 列挙ツールはログに痕跡を残しませんでした。
スペースを節約するためかもしれませんが、このようなイベントをログに記録しないという決定がなされた理由は不明です。 残念ながら、顧客がこの種のイベントを確認したい場合でも、そのようなログを有効にするオプションはありません。 つまり、攻撃者が環境に変更を加え始めるまでは、暗闇の中にいるということになります。
不十分な文書
Azure API は十分に文書化されていますが、ログ イベントに関する文書は不足しています。多くのイベントでは、文書化されているのは操作名だけですが、個々のフィールドとその意味は謎であることがよくあります。何が起こっているのかを理解するには、ブログや掲示板をくまなく調べなければなりません。
フィールドの目的が不明確であることに加えて、個々のデータ値もまた文書化されていないことがある。具体的な認証タイプ、ステータスコード、操作のサブタイプ、その他のデータが記述されていないのを見たことがある。徹底的な調査を行っても、これらの値のいくつかは明確にならなかった。
いくつかのフィールドや値を理解していないため、インシデントの調査中やレスポンス 、それらを監視したり解釈したりすることができない。
予告なしの変更
クラウドの機能が進化するにつれて (頻繁に行われますが)、新しいイベント タイプが予告なくログに表示されます。例えば、私たちが文書化したパスワードレスサインインの失敗について、新しいエラーコードが追加されました。Vectra AI セキュリティ研究チームは、原因を理解するまでに調査に時間を費やす必要があり、それまで、私たちの監視クエリはそれを認識できませんでした。
さらに厄介なのは、既存のイベントも消滅したり、形式が変わったりする可能性があることだ。 最近の例には次のようなものがあります。
- 追跡していて、Exchange ログから静かに消えた MailboxLogin イベント
- 偵察活動の初期段階をキャッチするために追跡していた、存在しないユーザー名のサインインエラーは、サインインログに書き込まれなくなりました。
特定のイベントを検索する監視および分析クエリがある場合、これらの変更により警告なしに機能が停止します。 これは最悪の種類の失敗です。問題があることにさえ気づいていないときです。 ログの整合性を監視し、ログの内容とドキュメントの変更を注意深く監視するためのロジックに投資する必要がある場合があります。 残念ながら、ほとんどのディフェンダーは忙しすぎて、そのことに時間を費やすことができません。
IDの不一致
ユーザー ID は常に「安定」しているわけではありません。 コンテキストと操作の種類に応じて、同じユーザーが異なる「ユーザー プリンシパル名」(UPN) でログに表示されることがあります。 たとえば、ユーザーは次のようにログオンされる可能性があります。
- john.smith@company.com
- John.Smith@company.com (大文字と小文字の違いに注意)
- AN045789@company.com
M365 Exchangeは、以下のようなレガシーな名前 (その他) を追加することで、仕事を台無しにしています。
"NAMPR07A006.PROD.OUTLOOK.COM/マイクロソフトExchangeホスト組織/ company.onmicrosoft.com/0cf179f8-0fa4-478f-a4cc-b2ea0b18155e" を代表して
名前の可変性の場合、異なるイベントを同じユーザーに関連付けることは難しくなる。UPNによってイベントを関連付けることは最初の衝動かもしれませんが、一意の内部IDによってそれを行うことは、より強固な戦略かもしれません(しかし、まだ確実ではありません）。
困難は続きます。
- 異なるログの異なる名前は、異なる意味を持つフィールド名と重複する場合がある。例えば、user_idは、あるログではユーザーGUIDを意味し、別のログではUPNを意味する。
- ユーザーIDは、ユーザーの姓名、アプリケーション名、アプリケーションGUID、その他の変わった名前や固有のIDを表す値を持つことがあります。
- ユーザーIDが空であったり、"Not Available"、"Unknown"、"No UPN "などの無駄な名前が含まれている可能性があります。
防御側としては、ユーザー ID フィールドでこの (あまり役に立たない) 情報を確認し、それに応じてクエリ機能を構築する準備をしておく必要があります。
IPの不一致
すべてのログレコードには、有効な IPアドレスが基本的に期待されます。 有効なIPv4およびIPv6アドレスはほとんどの場合ログエントリで利用できますが、理解するのが難しく、分析に使用するのが難しい IP が見つかることがあります。
- ポート番号付きIP(v4とv6の両方）
- 空のIP
- ローカル＆プライベートIP:127.0.0.1、192.168.*、10.*)
- オールゼロIP：0.0.0.0
- IPの代わりにIPマスク:255.255.255.255
- 操作を実行するユーザーではなく、Azure インフラストラクチャに対応する IP
一部の操作では IP をサインイン レコードに関連付けることができないため、インシデント分析が複雑になります。 IP リスクと評判の指標が利用できる場合もありますが、「logging tax」の対象となります。
防御側としては、ハンティングクエリやアラートを作成する際にこれらの特殊なケースを想定し、ロジックにそれらを組み込む必要があります。
地理位置情報の不一致
現在、Microsoft はサインインレコードの地理位置情報のみを提供しています。 アクティビティを特定のサインインレコードに常に関連付けることができるとは限らないため、これは他のログソースにとっては役に立ちます。
この機能は完璧ではありません。 場合によっては、問題が発生することがあります。
- 同じIPが複数の場所に解決される (モバイル機器に関連している可能性が高い)
- レコードの地理情報が誤っている。
- 地理情報が欠落している：
地理位置情報は、TOR、VPN、プロキシ、クラウド プロバイダーの IP にも簡単にだまされるため、割り引いて考える必要があります。
デバイス情報の不一致
デバイスの詳細は、Microsoft が判断するのが複雑です (登録済みのデバイスを扱っている場合を除く)。 プラットフォームとブラウザの情報は通常、ユーザー エージェント (UA) から解析されます。
残念ながら、ここにも矛盾があります。
- ログによっては、UAを解析して断片的に提供するものもあれば、UA全体の文字列を提供するものもある。
- すべてのログでデバイス情報が利用できるわけではない
- 解析された値は必ずしも一貫していない(例："Windows "と "Windows 10"）
攻撃者はユーザー エージェントを簡単に偽造できますが、目立たずに変更できるほど十分に訓練されている人ばかりではないため、調査には依然として価値があります。
壊れた値
一部のログ フィールドは複雑な構造 (JSON など) を持っており、ハンティング クエリやモニタリング クエリでは特定のサブフィールドを参照するためにそれらを解析する必要があります。
場合によっては、サイズ制限によりこれらの値が切り捨てられ、構造が壊れる場合があります。 たとえば、Set-ConditionalAccessPolicy 操作に関してログに記録された次の値を考えてみましょう。 その一部が切り取られ、3 つのピリオド (「...」) に置き換えられます。これにより、JSON パーサーが混乱します。
このようなレコードに遭遇した監視クエリは失敗し、盲点が生じる。
このような場合、正しく解析された値に依存することは最善の戦略ではない可能性があり、部分文字列検索の方がうまく機能する可能性があります。
ログの品質を向上させるには何が必要か
Azure のログ品質を批判しているのは私たちだけではありません (同様の問題は以前CrowdStrikeやEricWoodruffも指摘) 。なぜこれほど多くのログ品質が存在するのかについては推測することしかできません。
通常、ログはソフトウェア開発において優先的に他の機能より後回しにされます。 開発チームが主要な製品機能をリリースする必要がある場合、バックエンド サービス機能が犠牲になる可能性があります。
Azure のような巨大な製品エコシステムでは、複数の独立した (場合によってはレガシーな) 製品がまとめられています。 一般的なロギング アーキテクチャですべての機能に適切なシグナルを提供することは難しい場合があり、この機能は厳密には「顧客対応」ではないため、それに関する苦情は優先順位が低くなる可能性があります。
理由が何であれ、クラウド環境には代替手段がないため、ログの問題は従来のオンプレミス設定よりもはるかに深刻になります。 防御側には、ログの欠陥を認識し、その一部を回避しようとする以外に他の選択肢はありません。 この機能は Microsoft が所有しており、それを改善するかどうかは Microsoft の責任です。
私たちは、Azureチームによって、多くの非侵入的な変更が可能である（そして、そうすべきである）と考えています。
- すべてのイベント、フィールド、および列挙値は、ログ解析の手間を省くために、完全に文書化されなければなりません
- ログの構造と内容は、APIのように扱われるべきである。ログの照会機能を壊す可能性のある変更は、管理された方法で導入されるべきであり、顧客は変更に対応するための時間を与えられるべきである
- 伐採された作業の追加や特に撤去はすべて、明確に公表されなければなりません
- 記録は、現在よりもはるかにタイムリーに、数分や数時間ではなく数秒単位で配信されなければならず、イベントが遅れたり、順番通りに届かないことがあってはなりません
- 記録される値はすべて、有用で、正しく、曖昧であってはならない
- ログには、インシデントレスポンス (例えばIPレピュテーション）に役立つ豊富な情報が含まれていなければならない
理想的には、ロギング アーキテクチャをリファクタリングして (AWS や Oktaで利用可能なものと同様に) より合理化すると有益です。
レッドチームにとっての収穫
ここまでは、これらの問題がチームにもたらす困難についてだけ話してきた。しかし、防御者の損失は攻撃者の利益であることを忘れてはならない。有能なブラックハット、APT、およびレッドチーマーは、Azure ロギングの特殊性を利用して自分の行動を隠し、ブルーチームの取り組みを複雑にすることができます。
攻撃者が使う可能性のあるテクニックをいくつか紹介します。
- あまり文書化されていない、あるいは理解されていない特殊な操作を使用する
- 壊れた値や文書化されていない値をログに注入するアクションを実行し、分析を複雑にする
- IPまたは地理的情報が正しく記録されていない場所からの接続
- 取り込みの遅延を利用したり、関連イベントの検知を複雑にするためのタイミング操作
もちろん、ロギングの欠陥を強力な回避手法に変えるには、さらなる研究が必要になります。
ディフェンダーとしての仕事は大変だ。 攻撃を迅速に検出して修復しようとすることは大仕事であり、問題をマインドログして回避する必要がある場合はさらに手間がかかります。
クラウドにおけるセキュリティの向上は夢物語ではありません。それを実現する方法の 1 つは、高品質のログを提供することです。 プロバイダーにはこれを実現する力がありますが、それを優先度の高い目標にする動機が欠けている可能性があります。 そこで私たちの出番です。セキュリティ研究コミュニティがより多くの情報を公開し、より多くの圧力をかければかけるほど、ログの品質の向上に近づくことができます。
ぜひ本課題に対する会話に参加してください。このブログ記事やその他のトピックについて 、 Vectra AI セキュリティ・リサーチ・チームとRedditで直接やりとりすることが可能です。