Microsoft Azure フォレンジック調査のメモ

Posted on by Tony3

Microsoft Azure フォレンジック調査のメモ。

Azureの構成要素

  • Tenant: Microsoft Entra ID (旧Microsoft Azure Active Directory)のインスタンス。
  • Management Group (オプション): subscription (後述)をグループ化したもの。Management Groupを利用するとグループに属する全てのsubscriptionに対して適用可能なポリシーを作成できる。あくまでオプションであり必須ではない。
  • Subscription: resource (後述)の管理に使われる。通常、Subscription毎に課金が発生する。
  • Resource Group: 関連するresourceをグループ化したもの。Resource Groupを利用すると、グループ内の全てのresourceを一括でデプロイ、更新、削除できる。
  • Resource: 仮想マシン、ネットワーク、ストレージ、データベースなどのリソースを指す。

Azure Resource Manager

リソースの作成、更新、削除を行う管理レイヤー。AzureポータルやPowerShell、CLI、REST等からAzure Resource Managerに命令を送ってリソースを操作する。Azure Resource ManagerはRBAC (後述)に基づいてリソースを操作する。テンプレートをサポートしており、リソースの継続的なデプロイが可能。

Azure URIの書式

Azure URIの書式は以下の通り。

/subscription/<SubscriptionID>/resourceGroups/<resourcegroupname>/providers/<providername>/<resourceType>/<resourcename>

仮想マシンのURIの例

/subscription/d841fb8e-c0c7-46fd-ad91-3689e704d1fd/resourceGroups/Research/providers/Microsoft.Compute/virtualMachines/MiningVM

OSディスクのURIの例

/subscription/d841fb8e-c0c7-46fd-ad91-3689e704d1fd/resourceGroups/Research/providers/Microsoft.Compute/disks/MiningVM_disk1_213aa18e15cb44a68812d435fff3c508

ネットワークインターフェースのURIの例

/subscription/d841fb8e-c0c7-46fd-ad91-3689e704d1fd/resourceGroups/Research/providers/Microsoft.Network/networkInterfaces/miningvm106

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC)は、どのユーザーが、どのリソースに対して、どのような操作が出来るかを規定する。以下の3つの要素で構成される。

  • Security Principal
    • リソースにアクセスできるユーザーやグループ。
  • Role Definition
    • パーミッション (read, write, delete)の集合体。
    • 最も一般的なロールはContributer、Owner、Reader。
  • Scope
    • どのロールがどのリソースやリソースグループにアクセスできるかを規定する。
    • management group, subscription, resource group, resourceの4つのレベルで規定できる。

Azureへのアクセス方法

Azureへは以下の4つの方法でアクセスできる。

  • Azure Webポータル
  • Azure CLI
  • PowerShell
  • Graph API

ログの種類

Tenantレベルのログ

パスワード・スプレー攻撃やログイン・ブルートフォースなど、クレデンシャル情報に対する攻撃活動やアプリケーション、ユーザー、Service Principalの作成・変更などのイベントを調査したい場合は、Tenantのログを参照する。以下はログの例。

  • insights-logs-auditlogs
  • insights-logs-signinlogs
  • insights-logs-managedidentityusersigninlogs
  • insights-logs-noninteractiveusersigninlogs
  • insights-logs-serviceprincipalsigninlogs

Sign-in Log

サインインに関するログが記録される。こちらも併せて参照。以下はフォレンジック調査で注視すべきフィールド。

  • Time: イベントの発生時刻。 (UTC表示)
  • OperationName: どのようなオペレーションが行われたかを表す。
  • ResultType: オペレーションの成否を表す。成功なら0、失敗ならそれ以外の数字。
  • CallerIPAddress: サインインの送信元IPアドレス。
  • CorrelationId: イベントの識別子。CorrelationIdを取っ掛かりにして関連するほかのイベントを把握することができる。
  • UserDisplayName, UserPrincipalName, UserId: いずれもサインインを試みたユーザー名を表す。
  • AppId, AppDisplayName: サインインに使用されたクライアントアプリケーションを表す。
  • AuthenticationDetails: 認証方式 (プライマリーとセカンダリーの両方)を表す。

Audit Log

アプリケーション、ユーザー、Service Principalの作成・変更などが記録される。こちらも併せて参照。以下はフォレンジック調査で注視すべきフィールド。

  • Time: イベントの発生時刻。 (UTC表示)
  • OperationName: どのようなオペレーションが行われたかを表す。
  • ResultType: オペレーションの成否を表す。成功なら0、失敗ならそれ以外の数字。
  • CallerIPAddress: オペレーションの送信元IPアドレス。
  • CorrelationId: イベントの識別子。CorrelationIdを取っ掛かりにして関連するほかのイベントを把握することができる。
  • InitiatedBy: オペレーションを実行したユーザー名を表す。
  • TargetResources, ModifiedProperties: 変更された内容の詳細を表す。

Subscriptionレベルのログ

不審なリソースの作成、削除、開始、停止などを調査したい場合は、Subscriptionのログを参照する。以下はログの例。

  • insights-activity-logs

Subscription Log / Activity Log

Subscription LogはActivity Logとも呼ばれる。以下の8つのカテゴリーに分けられる。

  • Administrative
  • Service Health
  • Resource Health
  • Alert
  • Autoscale
  • Recommendation
  • Security
  • Policy

上記のうち、フォレンジック調査において重要なのはAdministrativeである。(リソースの作成、変更、削除を記録する)

以下はフォレンジック調査で注視すべきフィールド。

  • Time: イベントの発生時刻。 (UTC表示)
  • Category: ログのカテゴリー。
  • ResourceId: 操作対象のリソース。URI形式で表される。
  • OperationName: リソースに対してどのようなオペレーションがされたかを表す。
  • CallerIPAddress: オペレーションの送信元IPアドレス。
  • CorrelationId: イベントの識別子。CorrelationIdを取っ掛かりにして関連するほかのイベントを把握することができる。
  • UPN (User Principal Name): オペレーションを実行したユーザー名を表す。
  • ResponseBody: オペレーションの結果を表す。

Resourceレベルのログ

ネットワーク通信のフロー情報やストレージへのアクセス状況などを調査したい場合は、Resourceのログを参照する。以下はログの例。

  • insights-logs-networksecuritygroupflowevent
  • insights-logs-storageread

Operating Systemレベルのログ

OSレベルのイベント(ホストからの水平展開など)を調査したい場合は、Operating Systemのログを参照する。以下はログの例。

  • WADWindowsEventLogsTable
  • LinuxSyslogVer2v0

Applicationレベルのログ

アプリケーションのログ。AzureはIISのログを提供しており、Webサーバーへの攻撃活動を調査したい場合は以下のログを参照する。

  • wad-iis-logfiles

Log Analytics Workspace

データレイクのようなもの。resourceログ、Subscriptionログ、Entra IDログなどのAzure関連のログだけでなく、非Azureのログも保管できる。Log Analytics Workspaceに保管されたログはKusto Query Language (KQL)を使って調査できる。以下はKQLの例。

SiginLogs
| where TimeGenerated >= ago(30d)
| summarize CountPerIPAddress = count() by IPAddress
| order by CountPerIPAddress desc
AzureActivity
| where OperationNameValue contains "COMPUTE"
| distinct OperationNameValue

Storage Account

データの保管に使われる。以下の4種類のストレージがある。

  • Blob Storage: 非構造化データの保管に使われる。
  • File Storage: ファイルシステムの保管に使われる。Network File System (NFS)のようなもの。
  • Queue Storage: メッセージの保管と受信に使われる。主にEvent Hub (後述)に使われる。
  • Table Storage: 主にCosmos DBに使われる。

Storage Accountを作成すると、以下のURLでデータにアクセスできる。

https://<storage-accountname>.blob.core.windows.net

そのほかにもAzure Storage Explorerを使ってStorage Account上のデータにアクセスできる。

Blobの種類

BlobとはBinary Large Objectの略で、大量の非構造化データを保管するための仕組みである。動画や画像、テキストの保管に適している。Blobには以下の3種類がある。

  • Block blobs: テキストおよびバイナリデータの保管に適している。
  • Append blobs: データの追加に最適化されており、データの記録に適している。
  • Page blobs: Virtual Hard Drive (VHD)やOSのデータの保管に適している。

Storage Accountにおけるデータ漏洩の調査

Storage Accountのログはデフォルトでは有効化されていないので、手動で有効化する必要がある。
ログは以下の3種類。

  • StorageRead
  • StorageWrite
  • StorageDelete

データへのアクセスの有無を確認するには、StorageReadログを有効化してGetBlobオペレーションに注目する。

また、Subscription LogにてLISTKEYS/ACTIONオペレーションの有無も確認すること。このオペレーションはStorage Accountのアクセスキーが列挙されたことを表す。

MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION

Event Hub

データをリアルタイムで送信するための仕組み。Event Hubを利用すると SIEMなどの非Azure媒体にデータを送信できる。

Virtual Machine

以下はAzureが提供する仮想マシンの種類の例。

Aシリーズ

  • エントリーレベル。開発環境や通信量の少ないwebサイトなどに向いている。
  • 名前の例： A1 v2, A1 v2, A4 v2, A8 v2

Bシリーズ

  • 高負荷時にCPUパフォーマンスを向上させる機能を備えている。
  • 名前の例： B1S, B2S, B4MS, B12MB, B16MS, B20MS

Dシリーズ

  • 本番環境の使用に向いている。
  • 名前の例： D2a v4, D2as v4, D2d v4, D2ds v4, D2s v4

Fシリーズ

  • 計算作業に向いている。
  • 名前の例：F1, F1s, F2s v2

E, G, Mシリーズ

  • データベースなど大量のメモリを必要とするアプリケーションに向いている。
  • 名前の例： E2a v4, E2as v4, E2ds v4, G1, G1s, M8ms, M208s

Lシリーズ

  • 高スループットかつ低遅延。NVMeをサポートしている。
  • 名前の例：L8s v2, L4s

Nシリーズ

  • GPUをサポートしており、仮想化やディープラーニング、予測分析に向いている。
  • 名前の例： NC6, NC6s v2, NC4as T4, NV6, NV12s, NV4as v4, ND6s, ND40rs v2, ND96asr

Hシリーズ

  • 経済リスク・モデリングや遺伝子研究など、高度なマシンパフォーマンスを必要とするアプリケーションに向いている。
  • 名前の例： H8, HB60rs, HB120rs v2, HC44rs

上記のうち、攻撃者の標的になりやすいのがGPUをサポートしているNシリーズの仮想マシンである。攻撃者はマイニング目的でNシリーズの仮想マシンを立ち上げることが多々ある。

作成された仮想マシンの種類を確認するにはMICROSOFT.COMPUTE/VIRTUALMACHINES/WRITEオペレーションのresponse_bodyよりvmSizeフィールドに注目する。

vmSize: "Standard_L8s_v2"

上記はLシリーズの仮想マシンが作成されたことを示す。

仮想マシン作成時に記録されるその他のオペレーション

仮想マシンを作成すると、同時にnetwork security groupや仮想ネットワーク・インターフェース、IPアドレス、そしてOSディスクが作成される。以下は仮想マシンの作成時に記録されるオペレーションの例。

MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/WRITE
MICROSOFT.NETWORK/NETWORKWATCHERS/WRITE
MICROSOFT.NETWORK/VIRTUALNETWORKS/WRITE
MICROSOFT.NETWORK/PUBLICIPADDRESSES/WRITE
MICROSOFT.NETWORK/NETWORKINTERFACES/WRITE
MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE
MICROSOFT.RESOURCES/DEPLOYMENTS/WRITE
MICROSOFT.COMPUTE/DISKS/WRITE

前述したCorrelationIdでフィルターすることで、仮想マシンの作成に伴うその他のオペレーションを確認できる。

Virtual Network (VNet)

Azureのリソース間の通信や外部ネットワークへの通信を可能にする。VNetを作成すると、大抵の場合10.0.0.0/24のIPアドレスが付与される。この内部IPアドレスは仮想マシン間の通信に使用される。

VNetには任意の内部IPアドレスやパブリックIPアドレスの範囲を付与できる。

VNetはひとつのSubscriptionおよびRegionにしか所属できない。リソース間が通信するには全てのリソースが同一のRegionに所属していなければならない。

VNetと外部ネットワークの通信

仮想マシンが外部ネットワークと通信するためにはパブリックIPアドレスを付与しなければならない。パブリックIPアドレスにはNATが使用され、仮想マシンは自身に付与されている内部IPアドレスのみ把握している。

外部ネットワークとの通信には以下の3種類の方式がある。

  • Point-to-site VPN: VNetと単一のコンピュータ間の通信。
  • Site-to-site VPN: オンプレミスの VPN機器とVNet にデプロイされた Azure VPN ゲートウェイ間の通信。
  • Azure ExpressRoute: ExpressRouteパートナーのネットワーク網を介した、オンプレミス機器とAzure間の通信。プライベート通信であり、インターネットを経由しない。

Network Security Group (NSG)

VNet内のAzureリソース内外へのネットワーク通信を制御するための仕組み。以下の要素に基づいたステートフル・パケットインスペクションを行う。

  • 送信元IPアドレス
  • 送信元ポート
  • 宛先IPアドレス
  • 宛先ポート
  • プロトコル

NSGのルールを作成する際は、以下の2つを指定する。

  • Priority: ルールの優先順位。100~4096の範囲で指定する。100が最も優先度が高く、4096が最も優先度が低い。65000番台はAzureが使用する。
  • Action: Allow or Deny (許可または拒否)

フロー・ログは1分ごとに収集される。このインターバルは変更できない。

SSHとRDPの通信はデフォルトで許可されていることに注意。

NSGルールの作成はSubscription (Activity)ログに記録されるが、ルール自身によって生成されたログはResourceログに記録される。

NSG Logs vs NSG Flow Logs

  • NSG Logs: 通信に適用されたNSGルールの概要や通信の方向、通信が許可されたか否か (allow or block)を記録するが、IPアドレスの情報は記録されない。
  • NSG Flow Logs: 通信に適用されたルール名、送信元IPアドレス、送信元ポート、宛先IPアドレス、宛先ポート、プロトコル (T for TCP, U for UDP)、通信の方向 (I for inbound, O for outbound)、通信が許可されたか否か(A for allowed, D for denied)を記録する。

よって通信の詳細を知りたい場合はNSG Flow Logsを参照する。

NSG Flow Logs version 2

version 2では通信のスループット情報が記録される。

  • Flow state: 通信の状態。
    • B: Begin, 通信の開始を表す。
    • C: Continuing, 通信が継続中であることを表す。
    • E: End, 通信の終了を表す。
  • Packets Sent: 送信したパケット数の合計。
  • Bytes Sent: 送信したパケットのバイト数の合計。
  • Packets Received: 受信したパケット数の合計。
  • Bytes Received: 受信したパケットのバイト数の合計。

NSG Flow Logsの注意点

NSG Flow LogsはVNet内にあるAzureのリソース (仮想マシンなど)への通信のみ記録する。VNetを経由せずに通信が行われた場合、その通信はNSG Flow Logsに記録されない。（例えば、インターネットから直接Storage Accountにアクセスした場合など）

Network Virtual Appliance

Azureは以下のネットワークソリューションを提供している。

  • Azure Load Balancer: 受信した通信をリソースグループごとに均等に分散する。
  • Azure Firewall: ステートフルネットワークレベルのフィルタリングとアプリケーションレベルのフィルタリングを提供。
  • Application Gateway: Web系の脆弱性からアプリケーションを保護する。
  • VPN Gateway: オンプレミスネットワークとAzureを接続する。

Azure Monitor Agent

仮想マシンの状態を監視するエージェント。

収集されるデータは以下の通り。

  • イベントログ
  • パフォーマンス

収集したデータの送り先は以下の通り。

  • Azure Monitor Logs
  • Azure Monitor Metrics

Windows Azure Diagnostics (WAD)

仮想マシンの状態を監視するエージェント。

収集されるデータは以下の通り。

  • イベントログ
  • パフォーマンス
  • ETW (Event Tracing for Windows) イベント
  • ファイル関連のログ
  • IISおよび.NETのログ
  • クラッシュダンプ

収集したデータの送り先は以下の通り。

  • Azure Storage
  • Azure Monitor Metrics
  • Event Hub

WADのログはテーブル形式で保管される。
フォレンジック調査において最も重宝するのは、WADWindowsEventLogsTableである。このテーブルにはWindowsのイベントログが格納されている。
Linux関連のログはLinuxSyslogVer2v0に格納される。

テーブルへのアクセスにはAzure Storage Explorerを使うのが一般的。

Azure VM Run Command

仮想マシンに対して任意のスクリプトやコマンドを実行する。Azureポータルではシステム管理目的のスクリプトがあらかじめ用意されているが、ユーザー (あるいは攻撃者)が自前で用意したスクリプト (PowerShellまたはBash)も実行可能。スクリプトはデフォルトで高権限ユーザーとして実行される。

Azure VM Run Commandを使用するにはユーザーがMicrosoft.Compute/virtualMachines/runCommand/writeパーミッションを有している必要がある。このパーミッションはVritual Machine Contributorロールを始めとした高レベルのロールに含まれている。

以下はPowerShellのInvoke-AzVMRunCommandコマンドレットを使って、Azure VM Run Commandを実行する場合の例。

Invoke-AzVMRunCommand -ResourceGroupName <Name of resource group with target system> -Name <Name of target system> -CommandId 'RunPowerShellScript' -ScriptPath <Name of the script to execute>

Azure VM Run Commandの痕跡

Azure VM Run Commandの送信元ホスト

  • C:\Users\<username>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

Azure VM Run Commandの標的ホスト (Windows)

  • Microsoft-Windows-PowerShell Operational.evtxより、Event ID 4100
  • Windows PowerShell.evtxより、Event ID 600
  • C:\Windows\Packages\Plugins\Microsoft.Cplat.Core.RunCommandsWindows\1.1.15\Status
    • Run Commandのステータスメッセージが保管される。
  • C:\Windows\Packages\Plugins\Microsoft.Cplat.Core.RunCommandsWindows\1.1.15\Downloads
    • Run Commandによって最後に実行されたスクリプトが保管される。

Azure VM Run Commandの標的ホスト (Linux)

  • /var/log/azure/run-command/handler.log
    • スクリプトの実行履歴が記録される。
  • /var/lib/waagent/run-command/download
    • Run Commandによって実行された全てのスクリプトが保管される。
    • このフォルダにアクセスするにはroot権限が必要。

IT業従事者。2018年10月末よりシンガポール在住。2025年にシンガポールにて住宅（コンドミニアム）を購入。

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.