k2-ornata（個人的「やってみたこと」ブログ）

AVDを起点としたランサムウェアによるファイルサーバやM365上のデータ破壊（T1486）について調べてみた

—

by

上記についてわかったことを適宜記録していく。

１．File write spikes（Lantern Home）

以下のサイトには Windows イベントを対象にしたSPLが書かれています。

File write spikes（Lantern Home）
https://lantern.splunk.com/Security/UCE/Guided_Insights/Threat_hunting/Detecting_a_ransomware_attack/File_write_spikes

これをベースに ChatGPTでM365用を作成してもらったのが以下。

Microsoft 365 (M365) 上のファイルに対して T1486（データの暗号化）に相当する攻撃を検知する SPL を作成するには、SharePoint や OneDrive のようなクラウド上でホストされるファイルストレージに対する異常なファイル操作をモニタリングする必要があります。

以下は、M365 ログを使用して、異常なファイル操作（大量のファイル作成や変更）を検知する SPL の例です。特に SharePoint や OneDrive のファイル操作を対象としています。

spl

index=m365 (source="o365:sharepoint" OR source="o365:onedrive") 
| stats count BY _time, user, file_name, action 
| eval file_create_or_modify=if(action="FileCreated" OR action="FileModified", 1, 0)
| timechart span=1h sum(file_create_or_modify) AS file_operations BY user 
| eventstats max(_time) AS maxtime 
| stats count AS num_operations max(eval(if(_time >= relative_time(maxtime, "-1d@d"), sum(file_create_or_modify), null))) AS "count" avg(eval(if(_time < relative_time(maxtime, "-1d@d"), sum(file_create_or_modify), null))) AS avg stdev(eval(if(_time < relative_time(maxtime, "-1d@d"), sum(file_create_or_modify), null))) AS stdev BY user 
| eval upperBound=(avg + (stdev * 4)), isOutlier=if(((count > upperBound) AND (num_operations >= 20)),1,0)
| search isOutlier=1

このクエリの内容：

    データの収集：
        index=m365 (source="o365:sharepoint" OR source="o365:onedrive") では、Microsoft 365 の SharePoint および OneDrive のログを対象としています。
        stats count BY _time, user, file_name, action で、ファイル操作（ファイルの作成や変更）をカウントします。

    ファイル作成や変更の検出：
        eval file_create_or_modify=if(action="FileCreated" OR action="FileModified", 1, 0) で、ファイルが作成または変更された場合にフラグを立てています。

    異常検出：
        timechart span=1h sum(file_create_or_modify) AS file_operations BY user により、1時間ごとのファイル操作数をユーザー別に集計しています。
        過去1日のファイル操作数を現在の操作数と比較し、標準偏差の4倍以上の異常な活動があった場合に isOutlier=1 としてフラグを立てています。

クエリの目的：

    このクエリは、M365 上での大量のファイル作成や変更が通常よりも急激に増加した場合、異常として検知します。これにより、T1486 のような攻撃、特にファイルの暗号化を伴うランサムウェア攻撃の兆候を捉えることができます。

このクエリを活用することで、M365 上のファイルに対する攻撃をリアルタイムでモニタリングし、早期に対処できる可能性が高まります。

２．Server Message Block (SMB) traffic connection spikes

以下のサイトにはSMBを利用した検知方法が記載されています。

Server Message Block (SMB) traffic connection spikes
https://lantern.splunk.com/Security/UCE/Guided_Insights/Threat_hunting/Detecting_a_ransomware_attack/Server_Message_Block_(SMB)_traffic_connection_spikes

これについて、Azure上でも利用可能かChatGPTに確認してみました。

このSPLクエリは、Azure環境でも適用可能ですが、いくつかの注意点があります。特に、Azure Virtual Desktop (AVD) と Azure Files との通信に関して、Azureのログの取り扱いが異なる場合があります。
1. データソースの確認：

Azure 環境では、SMB や他のネットワークトラフィックに関連するデータが Azure Monitor や Log Analytics から取得されます。Splunk でAzureのネットワークデータを解析するためには、以下のようなデータソースを確認する必要があります。

    Azure Monitor によるNSGフローログ（Network Security Group Flow Logs）など、ネットワークトラフィックデータを収集することが必要です。
    Azureのファイル共有である Azure Files に対しても、SMBプロトコルを使用してアクセスするため、SMBの通信を監視することが可能です。

2. Azureのログを使った調整：

Azureのログ形式に応じて、データモデルやフィールド名の変更が必要になります。以下は、Azure環境（AVD と Azure Files の通信）に適応させた例です。

spl

index=azure_network_traffic (destination_port=139 OR destination_port=445 OR application="smb") 
| stats count BY _time span=1h, src_ip 
| eventstats max(_time) AS maxtime 
| stats count AS num_data_samples max(eval(if(_time >= relative_time(maxtime, "-70m@m"), count, null))) AS count avg(eval(if(_time<relative_time(maxtime, "-70m@m"), count, null))) AS avg stdev(eval(if(_time<relative_time(maxtime, "-70m@m"), count, null))) AS stdev BY src_ip 
| eval upperBound=(avg + (stdev * 2)), isOutlier=if(((count > upperBound) AND (num_data_samples >= 50)),1,0) 
| where isOutlier=1 
| table src_ip, count

3. Azure環境に適応するための変更点：

    index=azure_network_traffic: Azureのネットワークトラフィックログを収集するインデックスです。SplunkでAzureからデータを収集するためには、Azure Monitor や Azure Network Watcher からデータを取り込む必要があります。
    destination_port=139 OR destination_port=445: Azure Files に対するSMB通信は、通常これらのポートを使用します。
    src_ip: AVD や他のAzureリソースのIPアドレスに基づいて通信元を特定します。

まとめ：

このクエリは、Azure環境でのSMB通信を監視し、AVDとAzure Files間の異常なファイルアクセスやファイル共有に関連する通信の急増を検知するのに役立ちます。Azureの特定のログソースを活用することで、T1486に関連する活動の検知に応用できます。

Comments

コメントを残すコメントをキャンセル