チュートリアル: UEBA データを使用したインシデントの調査
この記事では、通常の調査ワークフローでユーザー エンティティ行動分析 (UEBA) を使用する一般的な方法とサンプル手順について説明します。
重要
この記事に記載されている機能は、現在プレビュー段階です。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用されるその他の法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。
注意
このチュートリアルでは、上位の顧客タスク (UEBA データを使用した調査) のシナリオベースの手順について説明します。 詳細については、「Microsoft Azure Sentinel でインシデントを調査する」を参照してください。
前提条件
調査時に UEBA データを使用する前に、Microsoft Azure Sentinel で [ユーザー/エンティティ行動分析 (UEBA)] を有効にする必要があります。
UEBA を有効にしてから約 1 週間待ってから、マシン パワーを利用した分析情報の検索を開始してください。
エンティティ データでプロアクティブなルーチン検索を実行する
詳細な調査を行う手がかりを得るため、ユーザー アクティビティについて調べる定期的なプロアクティブ検索を実行することをお勧めします。
Microsoft Azure Sentinel のユーザー/エンティティ行動分析ブックを使用し、次のようなデータに対してクエリを実行できます。
- 危険度の高い上位のユーザー (異常または付随するインシデントに関係)
- 特定のユーザーに関するデータ。対象が実際に侵害されたかどうか、またはユーザーのプロファイルから逸脱したアクションによって内部関係者による脅威が発生したかどうかを判断します。
さらに、UEBA ブックで非定型的なアクションをキャプチャし、それらを使用して異常なアクティビティやコンプライアンスに準拠していない可能性のある活動を見つけます。
異常なサインインを調査する
たとえば、次の手順では、それまでに使用したことがない VPN に接続したユーザー (異常なアクティビティ) の調査を行います。
Sentinel の [ブック] 領域で、ユーザーおよびエンティティ行動分析ブックを検索して開きます。
調査する特定のユーザー名を検索し、 [調査する上位ユーザー] テーブルでそれらのユーザーの名前を選択します。
[インシデントの詳細] と [異常の詳細] テーブルを下にスクロールして、選択したユーザーに関連付けられているインシデントと異常を表示します。
表示した異常 ( [異常なログイン成功] のような名前) で、表に示されている調査すべき詳細を確認します。 次に例を示します。
手順 説明 右側の説明を確認する 各異常には説明と、詳細を参照できる MITRE ATT&CK ナレッジ ベースへのリンクがあります。
例:
初期アクセス
敵対者はネットワークに侵入しようとしています。
初期アクセスは、さまざまなエントリ ベクトルを使ってネットワーク内に最初の足掛かりを得る手法で構成されています。 足掛かりを得るために使用される手法には、標的型スピア フィッシングや、公開されている Web サーバー上の脆弱性の悪用などがあります。 最初のアクセスで得た足掛かりをもとに、有効なアカウントや外部リモート サービスを利用して継続的にアクセスできるようにしたり、パスワードを変更することによって制限付きで使用できるようにしたりします。[説明] 列のテキストを確認する [異常] 行で、右にスクロールして追加の説明を表示します。 リンクを選択して、すべてのテキストを表示します。 例:
敵対者は、初期アクセスを得るための手段として、資格情報アクセス手法を使って特定のユーザーやサービス アカウントの資格情報を盗む場合や、ソーシャル エンジニアリングによって偵察プロセスの初期段階で資格情報を取得する場合があります。 たとえば、APT33 には初期アクセスに有効なアカウントを使っています。 次のクエリを使うと、ユーザーが接続元として使ったことがない、またピアでもない新しい地理的な場所から成功したサインインの出力を生成できます。UsersInsights データを確認する [異常] 行をさらに右にスクロールすると、アカウントの表示名やアカウント オブジェクト ID などのユーザーに関する分析情報データが表示されます。 テキストを選択すると、右側に完全なデータが表示されます。 証拠データを確認する [異常] 行をさらに右にスクロールすると、異常に関する証拠データが表示されます。 テキストを選択すると、以下のフィールドのように、右側の完全なデータが表示されます。
- ActionUncommonlyPerformedByUser
- UncommonHighVolumeOfActions
- FirstTimeUserConnectedFromCountry
- CountryUncommonlyConnectedFromAmongPeers
- FirstTimeUserConnectedViaISP
- ISPUncommonlyUsedAmongPeers
- CountryUncommonlyConnectedFromInTenant
- ISPUncommonlyUsedInTenant
ユーザーおよびエンティティ動作分析ブックにあるデータを使用して、ユーザー アクティビティが疑わしいものかどうか、さらにアクションが必要かどうかを判断します。
UEBA データを使用して擬陽性を分析する
調査でキャプチャされたインシデントが擬陽性であることがあります。
擬陽性の一般的な例として、あるユーザーが同じ時間帯にニューヨークとロンドンの両方からアプリケーションまたはポータルにサインインしたなど、不可能な移動アクティビティが検出された場合があります。 Microsoft Azure Sentinel では不可能な移動を異常として警告されたものの、そのユーザーについて調査すると、ユーザーが実際にいた場所とは別の場所で VPN が使用されていたことが判明することがあります。
擬陽性を分析する
たとえば、不可能な移動インシデントの場合、そのユーザーについて VPN が使用されたことを確認した後、インシデントからユーザー エンティティのページに移動します。 そこに表示されるデータを使用して、キャプチャされた場所がユーザーの一般的な場所に含まれるかどうかを判断します。
例:
ユーザー エンティティ ページは、[インシデント] ページ自体と調査グラフからもリンクされています。
ヒント
インシデントに関連付けられている特定のユーザーのユーザー エンティティ ページでデータを確認した後、Microsoft Azure Sentinel の [ハンティング] 領域にアクセスして、ユーザーのピアがいつもは同じ場所から接続しているかどうかも把握できます。 そうするならば、これらの情報によって、擬陽性について、より明確な根拠に基づいて判断を下せます。
[ハンティング] 領域で、異常な地理的な場所でのログオンに関するクエリを実行します。 詳細については、「Microsoft Azure Sentinel で脅威を検出する」を参照してください。
分析ルールに IdentityInfo データを埋め込む (パブリック プレビュー)
攻撃者は多くの場合、組織独自のユーザーとサービス アカウントを使用するため、アナリストにとっては、ユーザー ID や特権など、それらのユーザー アカウントに関するデータが調査中に重要です。
IdentityInfo テーブルのデータを埋め込み、ユース ケースに合わせて分析ルールを微調整し、擬陽性を減らし、場合によっては調査プロセスを高速化します。
次に例を示します。
IT 部門外の誰かがサーバーにアクセスした場合にトリガーされるアラートで、セキュリティ イベントを IdentityInfo テーブルに関連付けるには:
SecurityEvent | where EventID in ("4624","4672") | where Computer == "My.High.Value.Asset" | join kind=inner ( IdentityInfo | summarize arg_max(TimeGenerated, *) by AccountObjectId) on $left.SubjectUserSid == $right.AccountSID | where Department != "IT"
特定のセキュリティ グループのメンバーではないユーザーがアプリケーションにアクセスした場合にトリガーされるアラートで、Microsoft Entra サインイン ログを IdentityInfo テーブルに関連付けるには:
SigninLogs | where AppDisplayName == "GitHub.Com" | join kind=inner ( IdentityInfo | summarize arg_max(TimeGenerated, *) by AccountObjectId) on $left.UserId == $right.AccountObjectId | where GroupMembership !contains "Developers"
IdentityInfo テーブルでは、Microsoft Entra ワークスペースと同期して、ユーザー メタデータ、グループ情報、各ユーザーに割り当てられた Microsoft Entra ロールなど、ユーザー プロファイル データのスナップショットを作成します。 詳細については、『UEBA エンリッチメント リファレンス』で「IdentityInfo テーブル」を参照してください。
上の例で使用されている次の項目の詳細については、Kusto ドキュメントを参照してください。
- Where 演算子
- join 演算子
- summarize 演算子
- render 演算子
- sort 演算子
- iff() 関数
- ago() 関数
- now() 関数
- bin() 関数
- startofday() 関数
- count() 集計関数
- sum() 集計関数
KQL の詳細については、「Kusto 照会言語 (KQL) の概要」を参照してください。
その他のリソース:
パスワード スプレーとスピア フィッシングの試行を識別する
多要素認証 (MFA) が有効になっていない場合、ユーザーの資格情報は、パスワード スプレーまたはスピア フィッシングの試行によって攻撃しようとしている攻撃者に対して脆弱になります。
UEBA 分析情報でパスワード スプレー インシデントを調査する
たとえば、UEBA 分析情報でパスワード スプレー インシデントを調査するには、次の手順を実行して詳細を確認できます。
インシデントの左下にある [調査] を選択して、攻撃の対象となる可能性があるアカウント、マシン、およびその他のデータ ポイントを表示します。
データを参照すると、ログオン エラーの数が比較的多い管理者アカウントが表示される場合があります。 これは疑わしいですが、詳細を確認せずにそのアカウントを制限したくないと思うかもしれません。
マップで管理ユーザー エンティティを選択し、右側にある [分析情報] を選択して、時間のかかるサインインのグラフなどの詳細を確認します。
右側の [情報] を選択し、 [詳細の表示] を選択してユーザー エンティティ ページに移動し、さらに詳しく調べます。
たとえば、これがそのユーザーの初めての潜在的パスワード スプレー インシデントであるかどうか、またユーザーのサインイン履歴を監視してエラーが異常だったかどうかを確認します。
ヒント
異常な失敗ログオンのハンティング クエリを実行して、組織の異常な失敗ログインすべてを監視することもできます。 クエリの結果を使用して、パスワード スプレー攻撃の可能性について調査を開始します。
zURL デトネーション (パブリック プレビュー)
Microsoft Azure Sentinel に取り込まれたログに URL がある場合、これらの URL はトリアージ プロセスを加速するために自動的にデトネーションされます。
調査グラフには、デトネーションされた URL のノードと、次の詳細が含まれています。
- DetonationVerdict。 デトレーションからの高レベルのブール値の決定。 たとえば、Bad は、サイドがマルウェアまたはフィッシング コンテンツのホストとして分類されたとします。
- DetonationFinalURL。 元の URL からすべてのリダイレクトが行われた後の、観測された最後のランディング ページ URL。
次に例を示します。
ヒント
ログに URL が表示されていない場合は、セキュリティで保護された Web ゲートウェイ、Web プロキシ、ファイアウォール、またはレガシ IDS/IPS に対して URL ログ (脅威ログとも呼ばれる) が有効になっていることを確認します。
さらに調査するために、カスタム ログを作成して、関心のある特定の URL を Microsoft Azure Sentinel にチャネル化することもできます。
次のステップ
UEBA、調査、ハンティングの詳細については、以下をご覧ください。