Microsoft Sentinel 基礎その2

Last updated at 2025-07-29Posted at 2025-07-23

SC-200の勉強です。
その１は以下。

インシデントの管理

インシデントの詳細を確認する。

インシデントにかかわりのあるモノはエンティティと呼ばれる。
これらは製品によってIDが異なったりする（Entra IDではUPN、AzureではObject IDとか？）が、Sentinelでは可能な限りMergeして表示してくれる。

ユーザーアカウント (Account)
ホスト
IP アドレス (IP)
マルウェア
ファイル
プロセス
ドメイン名 (DNS)
Azure リソース
ファイル (FileHash)
メールメッセージ
送信メール
等。

偽陽性の扱い

インシデント > 操作 > オートメーションルールの作成から、今後同様のIncidentを抑制するような設定が可能。

条件を設定。

ふるまい情報をIncidentに追加

Settings > Set UEBA(=User and Entity Behavior Analytics)

インシデント調査にActivity Logなどを追加することができる。

Anomaliesの設定

AnomaliesをONにして

そのまま「Go to analytics in oder to configure the anomalies」をクリック。
Analyticsに既存のAnomaliesの一覧がTemplateがあり、それらが有効化された。

例えばこれはアカウントが追加されたことを検知するAnomaly。
「攻撃者は、被害者のシステムへのアクセスを維持するためにアカウントを作成する場合があります。十分な権限があれば、このようなアカウントの作成は、持続的なリモートアクセスツールをシステム上に展開することなく、二次的な認証付きアクセス手段を確立するために利用される可能性があります。」

Perplexityによると、
「この文章は、サイバー攻撃者（adversaries）が被害者組織のシステムに新しいアカウントを作成することによって恒常的なアクセス手段を確保しようとする手法」というのを検知するらしい。

インシデント詳細画面から確認すると、インシデントに関わったエンティティ（この場合はユーザー）のAnomalyの情報も右側にAnomaly Insightsという形で表示されている。

UEBAとAnomalyの違い

UEBAはインシデントに調査する際の情報を付与したり、ポイント制でアラートの根拠のもととなり積みあがる情報。それに比べてAnomaliesはルールで怪しいものを検知する。

UEBAの目的は、「ユーザーやエンティティの“通常”を自動で学習し、そこから外れた異常行動を可視化・スコア化」することです。これ自体はインシデント（アラート）とはならず、アラート調査時の付加情報や根拠として使われます。

アクティビティはスコア化され、最も異常なものは10になる。
1つ1つはたいして怪しくなくてもキルチェーンの中で考えると攻撃として判断できるもの。
例えば

地理的な場所、デバイス、環境をまたがって。
時間と頻度の変化範囲で（ユーザー自身の履歴との比較）。
ピアの動作と比較して。
組織の動作と比較して。

Anomalies（異常検出ルール）は、Sentinelに用意されている組み込みルールや自作の分析ルールによって検出結果が生成され、その結果をもとに条件を満たしたものだけ分析ルール経由でアラートやインシデント化できます。

ちなみに、Anomalyは誤検知も多いらしい。

異常検知は強力なツールですが、ノイズが多いことでも有名です。通常、特定の環境に合わせるための退屈なチューニングや複雑な後処理が必要になります。

Anomalyはトレーニング期間が必要（ものによっては過去30日分のデータ学習とか）なため、すぐには有効にならない。

ASIM Parser

説明を読んだがよくわからない。
Perplexityに質問してみると以下のような理解ができた。

SentinelはAzureだけでなく、AWSやGCP等様々なリソースのログを保管できる。ただ、リソースはどのプラットフォームでも似たようなログ出力している、フィールド名とかが違うだけだ。

そこで、AzureとAWSの監査のログを正規化（＝スキーマ、フィールド名を共通化）してしまい、AzureのログもAWSのログも同じKQLでクエリできるようにしたら便利じゃないか、という発想。そのためにAdvanced Security Information Model (ASIM)パーサーというものを挟んでクエリしよう。

このASIMパーサーはMicrosoftが提供しているものもあるし、カスタムアプリ用に独自に作成することもできる。Microsoftが準備してくれているものは以下から見ることができる。

PerplexityにAzureとAWS両方のログを抽出させるようなASIMパーサーを書かせたらこうなった。あまりネットにも具体例がないらしい。まあこういうこともできるということで。

// AWSのASIMパーサーログとAzureのASIMパーサーログを同時に集計する例イメージ
let AwsLogs = ASimAuthenticationAWSCloudTrail() // AWS CloudTrail ASIM認証パーサー (ユーザ定義関数) の例
    | where TimeGenerated > ago(1d);

let AzureLogs = ASimAuthenticationAzureActivity() // AzureアクティビティログのASIM認証パーサー関数
    | where TimeGenerated > ago(1d);

AwsLogs
| union AzureLogs
| summarize cnt = count() by Identity, bin(TimeGenerated, 1h)
| order by TimeGenerated desc

イメージ的にはなんとなく理解できる。Azureのログも、AWSのログも生データはLog Analyticsに格納されているが、ASIMパーサーにより正規化され、それによりUnionして検索をかけることができるようになっている。

Workbook

Sentinelではダッシュボードのテンプレートが準備されていて、気に入ったものををSaveすることができる。

SaveしたWorkbookを基に編集することもできる。

裏ではWorkbookの個々のグラフのデータがKQLで取得されている。

Hunting

SentinelでいうHuntingとはこのようなサイクルを回す。

仮説をたてることで、
- 何をHuntするのかを明確にする
- 実際に侵害が起こる前に予防する事前対応型ハンティングができる

ハンティング仮説から始める、と言っているがイマイチどうも理解できない。

例えば、新しく発見されて流行しているランサムウェアに組織が管理するDeviceが影響されていないか、というのは仮説ですか

はい、「新しく発見されて流行しているランサムウェアに組織が管理するDeviceが影響されていないか」というのはまさにMicrosoft Sentinelのハンティングにおける仮説の一例です。

ハンティングとは、既知の検出ルールに引っかかっていない潜在的な脅威を能動的に探すために、セキュリティアナリストが「こういう疑いがある」という仮説を立て、それを検証する作業です。流行しているランサムウェアが組織に影響を及ぼしていないかの仮説は、最新の脅威情報や攻撃パターンに基づいて立てる典型的なものです。この仮説をもとに、Microsoft Sentinelで関連のログやイベントをクエリ検索し、感染兆候や異常な動作の有無を調査します。

具体的には、

最新ランサムウェアの特徴的なファイル名や動作パターン、通信先IPアドレスなどのインジケーターを探す

ファイル整合性の変更や異常なプロセス起動ログを調査する
ネットワーク通信ログから疑わしいトラフィックを抽出する
といった調査クエリを実行して検証を行います。

Microsoftのドキュメントでも、マルウェアやランサムウェアの感染兆候を検出するためのハンティングクエリは、こうした仮説（潜在的な脅威に関する仮説や新たな攻撃ベクトルに関する情報）を出発点としていると説明されています。

したがって、ご質問の「新しく流行しているランサムウェア感染状況の有無を調査する」は、ハンティングにおける非常に典型的かつ適切な仮説です。これを基にクエリを設計し検証することで、組織のセキュリティ体制を強化できます。

HuntingとはMicrosoftは予防に使うことを想定していて、何か起きた時に被害範囲などを確認するためのものではない、ということらしい、、、実際には侵害されたユーザーアカウントがどこまでアクセスしてたかとかそういうことを知りたいケースもあると思うが。
追加でPerplexityに質問してみる。

Huntingで得られる知見は、後続のインシデント対応（流出経路の追跡や被害範囲の確認など）への迅速な対応を支援します。つまり、Huntingは主に

潜在的脅威の早期発見や予防に重きを置く調査活動

流出が発生した場合の影響調査や経路解析はインシデント対応やフォレンジックの範疇であり、Huntingの直接的な活動とは区別される
という理解が一般的です。Microsoftのドキュメントでも、ハンティングは「検出されない脅威を先回りして見つけるプロセス」として説明されており、既に発生したインシデントの調査とは明確に区別されていることが多いです。
したがって、「データ流出が発生した場合の流出経路の追跡や被害範囲の確認」はHuntingとは別の目的・段階の作業であり、Microsoft SentinelにおけるHuntingはむしろそのような事件が起きる前に潜在的な脅威を検知し対処するための予防的な調査活動と捉えるのが正確です。

インシデント対応と予防のHuntingは別物らしい。

MITRE ATT&CK

ちょっと長いがそのまま引用する。

攻撃者によって一般的に使用される戦術、手法、手順 (TTP) のパブリックにアクセス可能なナレッジベース。多くの組織は、MITRE ATT&CK ナレッジベースを使用して、環境内のセキュリティ状態を確認するために使用される特定の脅威モデルと手法を開発しています。

偵察。敵対者が、将来の作戦を計画する際に利用できる情報を見つけるために使う戦術。
リソース開発。敵対者が、作戦の支援に利用できるリソースを確立するために使う戦術。リソースには、インフラストラクチャ、アカウント、機能が含まれます。
初期アクセス。敵対者が、公開システムの脆弱性や構成の弱点を悪用することによって、ネットワークに侵入するために使用する戦術。例として、標的型スピアフィッシングがあります。
実行。敵対者がターゲットシステムでコードを実行することになる戦術。たとえば、悪意のあるハッカーが、PowerShell スクリプトを実行して、追加の攻撃者ツールをダウンロードしたり、他のシステムをスキャンしたりする可能性があります。
永続化。再起動や資格情報の変更の後も、敵対者がターゲットシステムへのアクセスを維持できるようにする戦術。永続化手法の例としては、攻撃者がスケジュールされたタスクを作成し、特定の時間または再起動時にコードを実行する場合があります。
特権の昇格。ローカル管理者やルートなど、システムでより高いレベルの特権を取得するために敵対者が使用する戦術。
防御回避。攻撃者が検出を避けるために使用する戦術。回避戦術には、信頼できるプロセスやフォルダー内への悪意のあるコードの隠蔽、敵対者のコードの暗号化または難読化、セキュリティソフトウェアの無効化などがあります。
資格情報アクセス。再利用のためにユーザー名と資格情報を盗むためにシステムやネットワークに展開される戦術。
検出。敵対者が、戦術上の利点のために、悪用または使用したいシステムやネットワークに関する情報を取得するのに使用する戦術。
横移動。攻撃者がネットワーク内のあるシステムから別のシステムに移動できるようにする戦術。一般的な手法としては、ユーザーを認証する "Pass-the-Hash" 方式やリモートデスクトッププロトコルの悪用などがあります。
収集。敵対者が、目的の一部として標的にしていた情報を収集および統合するために使用する戦術。
コマンドとコントロール。攻撃者が、自らの制御下でシステムと通信するために使用する戦術。一例として、攻撃者はセキュリティアプライアンスまたはプロキシによる検出を回避するために、一般的ではない、または番号の大きいポートを介してシステムと通信します。
流出。侵害されたネットワークから、攻撃者の完全な制御下にあるシステムまたはネットワークにデータを移動するために使用される戦術。
影響。攻撃者がシステム、ネットワーク、データの可用性に影響を与えるために使用する戦術。このカテゴリの方法としては、サービス拒否攻撃やディスクワイプまたはデータワイプソフトウェアが含まれます。
プロセス制御を損なう。敵対者が、物理制御プロセスを操作、無効化、または損傷するために使う戦術。
応答を抑制する機能。お客様の安全性、保護、品質保証、オペレーター介入などの機能が、障害、危険、または安全でない状態へ対応することを阻止するために敵対者が使う戦術。
なし。