このページでは、Vectra AI で使用されるネットワークセキュリティメタデータフィールドの体系的なリファレンスを提供します。ここでは、共通スキーマ属性、セッション層の接続性フィールド、プロトコル固有のテレメトリ(DNS、HTTP、SMB、LDAPなど)、認証メタデータ(Kerberos、NTLM、RADIUS)、検出層のマッチ属性、および暗号化通信のフィンガープリント(SSL/TLS、SSH、X.509)について定義しています。 これらの正規化されたメタデータストリームにより、フルパケットキャプチャを必要とせずに、振る舞い 、クロスドメインの相関分析、および暗号化トラフィックの可視化が可能になります。これらが一体となって、ハイブリッドなエンタープライズ環境全体におけるスケーラブルなネットワーク可観測性とセキュリティ調査の基盤を形成します。
これらの正規化されたメタデータストリームは、フルパケットキャプチャを必要とせずに、振る舞い 、ドメイン横断的な相関分析、および暗号化トラフィックの可視化を可能にすることで、脅威ハンティング、メタデータの充実化、およびメタデータフォレンジックを支援します。これらが一体となって、ハイブリッドな企業環境全体におけるスケーラブルなネットワークの可観測性と調査の基盤を形成します。
すべてのテレメトリ・ストリームに共通するネットワーク・メタデータ・フィールド(DHCPを除く)
これらのフィールドは、ほぼすべてのメタデータストリームに含まれており、メタデータタイプ間で共通して使用される接続スキーマを定義します。これらは、発信元および応答元の識別子、ポート、ホスト名、ロケーションフラグ、センサー情報、タイムスタンプ、および安定した接続UIDを記録します。
| フィールド |
説明 |
| id.ip_ver* | IPバージョン |
| id.orig_h | 発信元エンドポイントのIPアドレス |
| id.orig_p | 送信元エンドポイントのTCP/UDPポート |
| id.resp_h | 応答元のエンドポイントのIPアドレス |
| id.resp_p | 応答先のエンドポイントのTCP/UDPポート |
| local_orig | 接続がローカルから発信されたかどうかを示すブール値 |
| local_resp | 接続に対してローカルで応答があったかどうかを示すブール値 |
| orig_hostname* | 発信元エンドポイントのホスト名 |
| orig_huid* | ローカルホストの場合、そのホストの固有識別子 |
| orig_sluid* | 発信元ホストセッションの一意の識別子 |
| resp_hostname* | 応答元のエンドポイントのホスト名 |
| resp_huid* | ローカルホストの場合、そのホストを一意に識別する識別子 |
| resp_sluid* | ローカルホストの場合、応答したホストセッションの一意の識別子 |
| sensor_uid | メタデータレコードを生成した基となるトラフィックを検知したVectraセンサーの固有識別子 |
| ts | メタデータレコードが生成された時刻。日付形式で表示されます(例:2018年5月9日 10:09:25.366)。 |
| uid | 接続の一意のID |
これらのフィールドを基本の結合キーとして扱います。これらは、プロトコル、認証、および検知の記録を同じセッションやエンティティに紐づけることで、メタデータ強化ワークフローの基盤となります。脅威ハンティングやメタデータフォレンジックにおいて、この一貫性により、テレメトリ層をまたいだ信頼性の高いピボッティングが可能になります。
以下に示すプロトコル・テーブルの多くは、この共通のコンテキストを継承しつつ、このスキーマを拡張しています。これにより、ネットワーク・メタデータ・ストリーム全体にわたって、帰属情報の整合性とセッションの継続性が維持されます。
ビーコンのメタデータフィールドと振る舞い パターン
ビーコンのメタデータは、複数のセッションにわたる送信元と受信先間の反復的な通信を記述するものです。以下のフィールドには、ビーコン識別子、時間的境界、セッション数、方向ごとのバイト数、プロトコル/サービスコンテキスト、およびパターンを要約するために使用されるクライアントのフィンガープリントが記録されます。
ビーコン分析は、コマンド&コントロールへのコールバック、自動化ループ、および持続的な外部通信を特定するために、脅威ハンティングで頻繁に利用されます。アナリストはパケットを検査するのではなく、周期性や一貫性を示すメタデータの種類を頼りにしています。
| フィールド | 説明 |
| ビーコンの種類 | ビーコンのタイプ。「single_resp_multiple_sessions」タイプは、1つの宛先に対して複数のセッションで構成されるビーコンを示します |
| beacon_uid | ビーコンの固有のID |
| 期間 | BeaconUidの総有効期間 |
| 最初のイベント時刻 | この beacon_uid に対して最初に観測されたセッションのタイムスタンプ |
| ja3 | クライアントのSSLパラメータに基づくJa3ハッシュ |
| 最終イベント時刻 | この beacon_uid に対して最後に観測されたセッションのタイムスタンプ |
| 元のIPアドレスのバイト数 | この beacon_uid に対して、発信元から応答先へ送信されたバイト数の合計 |
| プロト | L4プロトコルの値。6はTCP、17はUDP |
| proto_name | L4プロトコル名(TCPまたはUDP) |
| resp_domains | このイベントにおけるレスポンダードメイン |
| resp_ip_bytes | この beacon_uid に対して、レスポンダーから発信者へ送信された合計バイト数 |
| サービス | サービス(例:「http」または「tls」) |
| セッション数 | beacon_uid を構成するセッションの数 |
| uid | 報告されたビーコンイベントに対する最初の接続の固有のID |
| ts | メタデータレコードが生成された時刻。日付形式で表示されます(例:2018年5月9日 10:09:25.366)。 |
| uid | 接続の一意のID |
これらのフィールドを使用して、継続時間、頻度、および方向別のトラフィック量を評価します。その後、メタデータフォレンジックにおいてより詳細な振る舞い 把握するために、DNS、HTTP、またはSSL/TLSのメタデータに焦点を移します。
ネットワーク上の異常検知の背後にある「原因」を探し回るのをやめましょう
ビーコン送信は、単なる1つの振る舞い に過ぎません。不審なネットワークメタデータがトリガーされた場合でも、アナリストは、どのエンドポイントプロセスやIDがそれを引き起こしたのかを理解する必要があります。その関連性がなければ、調査は行き詰まってしまいます。
エンドポイントとプロセスの相関関係を参照
DCE-RPC メタデータフィールドとリモートプロシージャコール属性
DCE-RPCメタデータは、Windowsの管理やサービスとのやり取りに一般的に見られるリモートプロシージャコール(RPC)の動作を記録します。これらのフィールドには、ドメインコンテキスト、エンドポイントの解決、呼び出された操作、ユーザー名の属性、およびリクエスト/レスポンスのタイミングが記録されます。
脅威ハンティングにおいて、DCE-RPCメタデータは、エンドポイントのログを必要とせずに、異常なリモート実行シーケンスや特権使用パターンを特定するのに役立ちます。
| フィールド | 説明 |
| ドメイン* | ホストのドメイン |
| エンドポイント | UUID から検索されたエンドポイント名(例:IXnRemote、IWbemLoginClientID) |
| ホスト名* | ユーザーがログインしたホスト名 |
| 操作 | 呼び出し内で確認された操作(例:「RemoteCreateInstance」) |
| rtt | リクエストからレスポンスまでの往復時間 |
| ユーザー名* | ログインしたユーザー名またはアカウント名。「$」で終わる名前はマシン名(ユーザーアカウント名ではありません) |
メタデータフォレンジックを行う際、操作名やユーザー名/ホストのコンテキストを用いて、日常的な管理業務と横方向の移動活動を区別する。
DHCPメタデータフィールドとネットワーク設定属性
DHCPメタデータは、デバイスをネットワークに接続するための動的なアドレス割り当ておよび設定情報を記録します。これらのメタデータは、割り当てられたIPアドレスをMACアドレスやホスト名に関連付けるとともに、リース期間やDHCP/DNSサーバーの情報を記録します。
IPアドレスの変更は調査を複雑にするため、DHCPレコードは、帰属情報の連続性を維持するために不可欠なメタデータの充実化をもたらします。
| フィールド | 説明 |
| 割り当てられたIPアドレス | これに対し、IPアドレスが割り当てられました |
| dhcp_server_ip* | DHCPサーバーのIPアドレス |
| dns_server_ips* | DHCPオプションからのDNSサーバーのIPアドレス。DHCPオプション6 |
| 賃貸期間 | DHCPリース期間。DHCPオプション51 |
| Mac | リクエスト内のMACアドレス |
| orig_hostname* | DHCPオプションからのホスト名。DHCPオプション12 |
| trans_id | トランザクションID |
| ts | メタデータレコードが生成された時刻。日付形式で表示されます(例:2018年5月9日 10:09:25.366)。 |
| uid | 接続の一意のID |
IPアドレスが変更された場合でも調査を安定させるためにDHCPフィールドを活用し、一時的なアドレスではなくデバイスレベルの属性に基づいて識別情報を固定する。
DNSメタデータフィールドとクエリ応答属性
DNSメタデータは、クエリの意図、再帰処理、応答コード、切り捨てフラグ、TTL値、レコード数など、ドメイン解決の挙動を表します。
DNSネットワークのメタデータは、ペイロードの検査を行わなくても、中継インフラ、ドメインの頻繁な変更、偵察活動、および失敗したコールバックの試みを明らかにするため、脅威ハンティングにおいて極めて重要です。
DNSメタデータにより、以下の情報を把握できます:
- どのドメインが検索され、誰が検索したのか
- 再帰が要求されたか、あるいは利用可能だったか
- 権威ある回答がどのように返されたか
- どのようなレスポンスコードとTTL値が確認されたか
| フィールド | 説明 |
| AA | 権威ある回答。サーバーがそのクエリに対して権威を持つ場合に真となる |
| 回答† | クエリに対する回答の一覧 |
| 著者 | クエリに対する公式な回答の一覧 |
| プロト | DNSトランザクションのプロトコル—6(TCPの場合)または17(UDPの場合) |
| qclass / qclass_name | クエリクラスを指定する値(例:1 / Internet [IN]) |
| qtype / qtype_name | クエリタイプ値/説明名(例:A、AAAA、PTR、TXT) |
| クエリ† | クエリの対象となるドメイン名 |
| RA | 再帰クエリが利用可能です。サーバーが再帰クエリをサポートしている場合にtrueとなります。 |
| RD | 再帰処理を希望します。クエリの再帰検索が要求された場合にtrueとなります。 |
| rcode / rcode_name | DNS応答に含まれる応答コードの値(例:NXDOMAIN、NODATA) |
| 却下された | DNSクエリはサーバーによって拒否されました |
| saw_query | 完全なDNSクエリが確認されたかどうか |
| 返信を見る | 完全なDNS応答が確認されたかどうか |
| TC | 切り捨てフラグ。メッセージが切り捨てられた場合にtrueとなる |
| TTL | 回答から得られたTTLの一覧 |
| 回答総数 | 応答メッセージのアンサーセクションに含まれるリソースレコードの総数 |
| 返信数 | 応答メッセージの「answer」、「authority」、「additional」セクションに含まれるリソースレコードの総数 |
| trans_id | DNSクライアントによって割り当てられた16ビットの識別子 |
DNSメタデータのフォレンジック分析を用いて、意図や結果、クエリの内容、返された結果、および解決の成否を解釈し、その後、TLSまたはHTTPメタデータへと分析の範囲を広げていく。
HTTPメタデータフィールドとWebセッション属性
HTTPメタデータは、ペイロード全体を保存することなく、Web層の動作を要約したものです。これらのフィールドには、ヘッダーから導き出されたコンテキスト、メソッド、URI、プロキシ転送の指標、フィンガープリント属性、および方向性のあるバイト/パケットのメトリクスが含まれます。
ネットワークメタデータの調査において、HTTPフィールドは、不審なファイル転送、スクリプトによるコールバック、異常なヘッダー構造など、脅威ハンティングのためのアプリケーション層のコンテキストを提供します。
| フィールド | 説明 |
| 承諾する | リクエスト内のAcceptヘッダーの値(存在する場合)は、256バイトに切り詰められます |
| accept_encoding | リクエストに含まれる場合、Accept-Encodingヘッダーの値は256バイトに切り詰められます |
| クッキー* | Cookieヘッダーの値(256バイトに切り詰められたもの) |
| cookie_vars* | クッキーフィールド内の変数(値を除く) |
| ホスト | Hostヘッダーの値(256バイトに切り詰め) |
| host_multihomed* | ホストヘッダー内のアドレスが、1つ以上のIPアドレスに関連付けられていると確認されたかどうかを示すブール型属性 |
| is_proxied* | プロキシ経由のリクエストを示すブール値 |
| ja4h | HTTPクライアントのJA4Hフィンガープリント |
| メソッド | HTTPリクエストメソッド |
| orig_ip_bytes* | 発信者から受信者へ送信されたバイト数 |
| orig_mime_types | 発信元リクエストのコンテンツタイプヘッダー |
| orig_pkts* | 送信元から受信先へ送信されたパケット数 |
| 投稿日時 | POSTリクエストのボディに含まれるバイナリデータ。2kサイズに切り詰められています |
| プロキシ経由で | 「X-Forwarded-For」ヘッダーの値(例:X-FORWARDED-FOR → 10.10.15.192) |
| リファラー | Referrerヘッダーの値(256バイトに切り詰め) |
| リクエストボディの長さ | リクエスト内のHTTPペイロードバイト数 |
| request_cache_control* | リクエストに含まれるCache-Controlヘッダーの値は、存在する場合、256バイトに切り詰められます |
| request_header_count* | リクエスト内のヘッダーの数 |
| resp_filename | サーバーから返されたファイル名(ある場合) |
| resp_ip_bytes* | レスポンダーから発信者へ送信されたバイト数 |
| resp_mime_types | レスポンスの Content-Type ヘッダーの値(256 バイトに切り詰め) |
| resp_pkts* | レスポンダーから発信者へ送信されたパケット数 |
| response_body_len | レスポンス内のHTTPペイロードバイト数 |
| response_cache_control* | レスポンスに含まれるCache-Controlヘッダーの値は、存在する場合、256バイトに切り詰められます |
| response_content_disposition | Content-Dispositionヘッダーの値(添付ファイルとしてダウンロードされるファイル名を指定します。例:'attachment; filename="filename.jpg"') |
| response_expires* | レスポンスに含まれる場合、Expiresヘッダー |
| response_header_count* | レスポンスに含まれるヘッダーの数 |
| ステータスコード | HTTPレスポンスのステータスコード |
| ステータスメッセージ | ステータスコードに対応するステータスメッセージ |
| uri | リクエストで使用されたURI(512バイトに短縮) |
| user_agent | クライアントからのUser-Agentヘッダーの値 |
HTTPメタデータを使用してWeb上の行動を再構築し、DNSおよびTLSメタデータと照合することで、宛先の身元と暗号化の特性を確認します。
iSessionの接続メタデータおよびセッションレベルのネットワーク属性
iSessionメタデータは、プロトコル間で共通して使用される正規化されたセッションモデルを定義します。これには、接続状態、方向性の信頼度、タイミングマーカー、フィンガープリントのバリエーション、VLANコンテキスト、および方向ごとのバイト数/パケット数が含まれます。
このセッション層の抽象化により、プロトコルに関係なくネットワークメタデータの表現方法を標準化することで、スケーラブルなメタデータの充実化が可能になります。
| フィールド | 説明 |
| 申請 | このセッションに関連するアプリケーション |
| client_luid_proxy | 接続の送信元アドレスがプロキシとして登録されている場合、真となる |
| conn_state | 接続状態。取り得る値:S0、S1、SF、REJ、S2、S3、RSTO、RSTR、RSTOS0、RSTRH、SH、SHR、またはOTH |
| dir_confidence | クライアント/サーバーの割り当て精度(0~100) |
| 期間 | 接続時間(ミリ秒) |
| first_orig_resp_data_pkt* | 送信元から応答先へのパケットの最初の16バイトをBase64エンコードしたもので、文字列として表される |
| first_orig_resp_data_pkt_time* | 発信元から応答先への最初のデータパケットのタイムスタンプ |
| first_orig_resp_pkt_time* | 送信元から受信元への最初のパケットのタイムスタンプ |
| first_resp_orig_data_pkt* | レスポンダーから発信者へのパケットの最初の16バイトをBase64エンコードしたもので、文字列として表される |
| first_resp_orig_pkt_time* | 応答元から発信元への最初のパケットのタイムスタンプ |
| first_resp_orig_data_pkt_time* | レスポンダーから発信者への最初のデータパケットのタイムスタンプ |
| ja4lc | クライアントの光距離のJA4LCフィンガープリント |
| ja4ls | サーバーのライト距離のJA4LSフィンガープリント |
| ja4t | クライアントのTCP SYNパケットのJA4Tフィンガープリント |
| ja4ts | サーバーのTCP SYN-ACKパケットのJA4TSフィンガープリント |
| 元のIPアドレスのバイト数 | 発信者から受信者へ送信されたバイト数 |
| orig_pkts | 送信元から受信先へ送信されたパケット数 |
| orig_vlan_id* | 送信元のVLAN_id(存在する場合) |
| プロト | L4プロトコルの値。6はTCP、17はUDP |
| proto_name | L4プロトコル名(TCP、UDP、またはICMP) |
| proxy_to_internal_dst | プロキシ経由後の実際の宛先が内部IPの場合、真となる |
| resp_domain* | TLS SNI、HTTPホスト、または宛先IP名(この順序で)から算出されます |
| resp_ip_bytes | レスポンダーから発信者へ送信されるバイト数 |
| resp_multihomed* | ドメインが1つまたは複数のIPアドレスに関連付けられていると確認されたかどうかを示すブール型属性 |
| レスポンスパケット数 | レスポンダーから発信者へ送信されたパケット数 |
| resp_vlan_id* | 応答元のVLAN ID(存在する場合) |
| サービス | サービス(例:「smb」) |
| server_luid_proxy | 接続の宛先アドレスがプロキシとして登録されている場合、真となる |
| セッション開始時刻 | セッションが開始された時刻 |
脅威ハンティングにおいては、iSessionを中核的な軸として位置づけてください。これにより、プロトコル、認証、および検出メタデータの種類を問わず、安定したセッションの継続性が確保されます。
接続状態の値とTCPセッションのライフサイクル指標
接続状態の値は、セッションが「進行中」、「確立済み」、「拒否」、「リセット」、「ハーフオープン」、または「未完了」のいずれの状態にあるかを表します。これらの指標は、スキャン、プローブ、通信の不安定、またはセッションの中断などを明らかにする振る舞い の種類です。
| 州 | 説明 |
| S0 | 接続の試みが確認されましたが、応答がありません。 |
| S1 | 接続が確立され、切断されていません。 |
| SF | 通常の確立と終了。これは状態 S1 と同じ記号であることに注意してください。S1 の場合、サマリーにバイト数は表示されませんが、SF の場合には表示されるため、両者を区別することができます。 |
| REJ | 接続の試みが拒否されました |
| S2 | 接続が確立され、発信元による切断の試みが確認された(ただし、応答側からの応答はない) |
| S3 | 接続が確立され、応答側による切断の試みが確認された(ただし、発信側からの応答はない) |
| RST0 | 接続が確立されましたが、発信側が接続を解除しました(RSTを送信しました) |
| RSTR | レスポンダーがRSTを送信した |
| RSTOS0 | 送信元はSYNを送信した後、RSTを送信しましたが、応答元からのSYN-ACKは確認されませんでした。 |
| RSTRH | レスポンダーはSYN ACKを送信した後、RSTを送信しましたが、(名目上の)送信元からのSYNは確認されませんでした。 |
| SH | 送信元はSYNを送信した後、FINを送信しましたが、応答側からのSYN-ACKは確認されませんでした(したがって、接続は「半開」の状態でした)。 |
| SHR | レスポンダーはSYN ACKを送信した後、FINを送信しましたが、発信元からのSYNは確認されませんでした。 |
| その他 | SYNパケットは確認されず、中間のトラフィックのみが確認された(その一例として、後に閉じられなかった「部分的な接続」が挙げられる)。 |
メタデータフォレンジックを行う際には、ライフサイクル状態をタイミングやボリュームのフィールドと組み合わせて使用し、偵察パターンの優先順位付けを行う。
Kerberosのメタデータフィールドと認証チケットの属性
Kerberosのメタデータには、チケットの発行、認証タイプ、権限スコアリング、暗号化方式のネゴシエーション、および成功/エラーの状態が記録されます。これらのアイデンティティ層のメタデータは、認証情報の悪用や権限の昇格を検知するために不可欠です。
Kerberosメタデータにより、以下の情報を把握できます:
- アカウントおよびサービスの権限レベル(低、中、高)
- チケットのリクエストおよび応答の種類(AS、TGT)
- 暗号方式の使用とネゴシエーション
- 認証の成功およびエラー条件
| フィールド | 説明 |
| アカウント権限 | アカウントの権限レベル。スコアは「低(1、2)」「中(3、4、5、6、7)」「高(8、9)」の3つのカテゴリーに分類されます。 |
| アカウントID | アカウントの一意の識別子(principal@REALM 形式) |
| as_rep_padata_count | 切り捨て前にAS-REPで確認されたPA-DATAエントリの総数 |
| as_rep_padata_types | AS-REPメッセージからのPA-DATA型整数(最大12個) |
| as_rep_padata_types_string | AS-REPメッセージ用の、人間が読みやすいPA-DATA型名(最大12個) |
| as_req_padata_count | 切り捨て前にAS-REQで確認されたPA-DATAエントリの総数 |
| as_req_padata_types | AS-REQメッセージからのPA-DATA型整数(最大12個) |
| as_req_padata_types_string | AS-REQメッセージ用の、人間が読みやすいPA-DATA型名(最大12個) |
| クライアント | クライアント名(レルムを含む) |
| データソース | レコードのソース(「ネットワーク」または「ログ」) |
| エラーコード | 成功しなかった場合のエラーコード |
| エラーメッセージ | 成功しなかった場合のエラーメッセージ |
| orig_host_observed_privilege* | この特権レベルは、ホストから操作されていると見なされるアカウントの活動に基づいて算出された、観測された特権を表しています。スコアは、「低(1、2)」、「中(3、4、5、6、7)」、「高(8、9)」の3つのカテゴリーに分類されます。 |
| プロトコル* | L4プロトコル。6(TCP)または17(UDP) |
| rep_cipher | レスポンスチケットの暗号化方式 |
| reply_timestamp* | 返信の日時 |
| req_ciphers | リクエストチケットの暗号化方式 |
| リクエストタイプ | リクエストの種類(AS または TGT) |
| サービス | リクエストされているサービス(レルムを含む) |
| サービス権限 | サービスの優先度。スコアは「低(1、2)」「中(3、4、5、6、7)」「高(8、9)」の3つのカテゴリーに分類されます。 |
| service_uid | サービスの固有識別子(principal@REALM 形式) |
| 成功 | リクエストが成功したかどうか |
| チケット暗号 | AS-REPおよびTGS-REPの応答で確認されたチケット暗号 |
権限カテゴリとリクエストタイプを活用して、影響の大きいアカウントやサービスに脅威ハンティングの焦点を絞り、その後、検証のためにLDAPやセッションテレメトリに分析を切り替えます。
LDAPメタデータフィールドとディレクトリクエリ属性
LDAPメタデータは、クエリの範囲、属性の選択、結果の数、エラー状態など、ディレクトリ検索およびバインドの動作を要約したものです。
ディレクトリのメタデータフォレンジックは、認証悪用につながる列挙攻撃を特定するのに特に有用です。
| フィールド | 説明 |
| 属性 | 検索条件に一致し、検索結果として返されるエントリに含めるよう要求する属性のセット |
| 基底オブジェクト | 検索を限定するサブツリーの基点 |
| bind_error_count | バインドエラーがある場合、そのエラーの数 |
| 期間 | セッションの所要時間 |
| 暗号化されたSASLペイロードの数 | SASL暗号化が使用されている場合、検出された暗号化されたSASLペイロードの数 |
| エラー | エラーが発生した場合のエラーメッセージ(例:「0000208D: NameErr ...」) |
| ログイン失敗エラー数 | ログオンエラーの件数 |
| is_close | クローズが観測されたかどうかを示すブール値のフラグ |
| is_query | リクエスト内でクエリが確認されたかどうかを示すブール値のフラグ |
| 一致したDN | 一致した識別名 |
| メッセージID | メッセージID |
| クエリ | 対象範囲内のどのエントリを返すかを特定するための基準 |
| クエリ範囲 | 対象となるサブツリーのうち、考慮すべき部分(例:wholeSubtree) |
| 応答バイト数 | レスポンスのバイト数 |
| 結果 | このリクエストにおけるクエリの結果 |
| リクエストバイト数 | リクエストのバイト数 |
| 結果コード | レスポンスに含まれる結果コード(成功または失敗) |
| 結果件数 | 結果に含まれるエントリの数 |
脅威ハンティングのワークフローにおいて、結果の量やエラーのパターンを活用し、日常的な検索と大規模な発見を区別する。
Match フィールドとアラートシグネチャの属性をMatch
Match 、生のテレメトリデータではなく、評価済みの検知結果を表します。これらのメタデータタイプは、シグネチャの識別情報、深刻度、リビジョン状態、展開範囲、およびパケットのコンテキストを記述します。
このレイヤーは、検出ロジックによってネットワークメタデータがどのように解釈されたかを反映しています。
| フィールド | 説明 |
| eve_json.alert.category | アラートメッセージのカテゴリ |
| eve_json.alert.gid | 署名グループの固有の識別子。ほとんどの署名では、デフォルト値は 1 です。 |
| eve_json.alert.metadata.影響を受ける製品 | 対象製品の詳細を明記します |
| eve_json.alert.metadata.attack_target | 攻撃対象が「クライアント」、「サーバー」、「両方」、または「その他」のいずれかを指定します |
| eve_json.alert.metadata.created_at | 署名が作成された日付を指定します |
| eve_json.alert.metadata.deployment | 署名を配置する場所を指定します |
| eve_json.alert.metadata.マルウェア_family | 以下を指定します マルウェア シグネチャに関連付けられているマルウェアファミリーを指定します |
| eve_json.alert.metadata.policy | アラートポリシーの詳細を指定します |
| eve_json.alert.metadata.signature_severity | このシグネチャに関連する深刻度を説明します |
| eve_json.alert.metadata.tag | 作成者が署名に割り当てたタグ情報を指定します |
| eve_json.alert.metadata.updated_at | 署名の最終更新日時を指定します |
| eve_json.alert.rev | シグネチャが更新されたかどうかを示すアラートシグネチャの改訂番号 |
| eve_json.alert.rule | アラートを発生させたルールを指定してください |
| eve_json.alert.severity | アラートの深刻度を表す数値 |
| eve_json.alert.signature | ルール名。署名内の「msg」テキストに基づきます |
| eve_json.alert.signature_id | アラート署名識別子 |
| eve_json.alert.xff | 「x-forwarded-for」の値 |
| eve_json.direction | アラートのトラフィックの方向を指定します |
| eve_json.packet | シグネチャをトリガーしたパケットを指定します |
| eve_json.payload | Base64エンコードされたパケットのペイロード情報を提供します |
| eve_json.payload_printable | ASCII形式で表示されたペイロードを提供します |
| eve_json.proto | L4プロトコル名 |
検出がトリガーされた理由を把握するためにマッチのメタデータを活用し、その後、根本的なプロトコルおよびセッションのメタデータに戻って、状況を完全に再構築します。
NTLM メタデータフィールドと認証応答属性
NTLMメタデータには、ホスト、ドメイン、ユーザー名、ステータスコード、成功状態など、認証の試行と結果が記録されます。
NTLMが有効な環境では、これらのメタデータの種類は、フォールバック認証の悪用を特定する上で重要です。
| フィールド | 説明 |
| ドメイン | ホストのドメイン |
| ホスト名 | ユーザーがログインしたホスト名 |
| ステータス | レスポンスのステータスコード |
| 成功 | リクエストが成功したかどうか |
| ユーザー名 | ログインしたユーザー名またはアカウント名 |
繰り返される失敗や異常な成功パターンを脅威ハンティングのシグナルとして活用し、SMBやRDPのメタデータとの相関分析を行う。
RDP メタデータフィールドとリモートデスクトップ セッション属性
RDPメタデータには、クライアントの識別情報、バージョン、表示設定、暗号化フラグなど、対話型リモートセッションの属性が記録されます。
これらのメタデータタイプにより、コンテンツを復号することなく、管理者のアクセスパターンを調査することができます。
| フィールド | 説明 |
| クライアントビルド | クライアントマシンで使用されているRDPクライアントのバージョン。暗号化されている場合は「不明」となります。 |
| client_dig_product_id | クライアントマシンの製品ID |
| クライアント名 | クライアントマシンの名前 |
| クッキー | クライアントマシンで使用されるCookieの値(ユーザー名) |
| デスクトップの高さ | クライアントマシンのデスクトップの高さ。暗号化されている場合は0 |
| デスクトップの幅 | クライアントマシンのデスクトップ幅。暗号化されている場合は0 |
| キーボードレイアウト | クライアントマシンのキーボードレイアウト(言語)(例:「US」、「暗号化キーボードレイアウト」) |
| 結果 | 暗号化されている場合、結果の値は「encrypted」となり、そうでない場合は空になります |
メタデータフォレンジック調査において、リモートアクセスの標準的なパターンを把握し、逸脱を特定する。
RADIUSメタデータフィールドおよび認証アカウンティング属性
RADIUSメタデータレコードには、セッション識別子、セッション時間、パケット/バイトカウンター、アドレス情報、ポリシーマーカーなど、アクセス制御、認証、およびアカウンティングに関する情報が記録されます。
これらのネットワークメタデータタイプは、VPN、NAC、またはワイヤレスシステムを経由したリモートアクセスの経路を追跡するのに役立ちます。
| フィールド |
説明 |
| アカウント認証 |
ユーザーがどのように認証されたかを特定する |
| account_delay_time |
送信者がメッセージの送信を試み始めてからどのくらいの時間が経過しているかを示します |
| account_input_gigawords |
入力時に「Acct-Input」カウンタが何回リセットされたかを特定します |
| アカウント入力バイト数 |
何バイト受信されましたか |
| アカウント入力パケット |
システムが受信したパケットの数 |
| account_output_gigawords |
出力のために「Acct-Input」カウンタが何回ロールオーバーしたかを特定します |
| 出力バイト数 |
何バイトが設定されていますか |
| 送信パケット数 |
システムが送信したパケットの数 |
| アカウント_セッション_ID |
これは、別のパケットで送信されるRADIUSアカウンティングセッションを識別するための固有のIDです。 |
| アカウントのセッション時間 |
ユーザーが受信したサービスの期間 |
| 発信元ID |
これは発信元の識別子です |
| 接続情報 |
接続速度やその他の接続関連情報を確認する |
| 委任されたIPv6プレフィックス |
IPv6アドレスが割り当てられたIPv6アドレスプール |
| dst_display_name |
宛先のDNS名 |
| dst_host_luid |
これは、ホストIDを持つ宛先ホストのIDです |
| dst_luid |
RADIUSサーバーのLUID |
| dst_luid_external |
宛先が外部の場合、値は「True」となる |
| イベントタイムスタンプ |
「ts」と同様ですが、Vectraではなくデバイスからのタイムスタンプです |
| filter_id |
これにより、使用中のACLが特定されます |
| 宛名枠 |
このフィールドは、認証を要求するエンドポイントを識別するリクエストに含まれています |
| フレーム付きインターフェース |
ユーザーがシステムに接続する際に使用されるインターフェースを特定します |
| IPアドレスの範囲 |
システムに接続しているエンドポイントデバイスのIPアドレス |
| IPv6プレフィックスの範囲 |
ユーザーに割り当てられたIPv6プレフィックスを示します |
| framed_protocol |
ユーザーがシステムに接続する際に使用されるフレーム化プロトコルを特定します |
SMB または RDP アクティビティの分析に移る前に、会計および NAS のコンテキストフィールドを使用して、アクセス範囲と期間を検証します。
拡張RADIUSメタデータフィールドおよびネットワークアクセス制御属性
拡張されたRADIUSメタデータには、デバイスおよび適用に関するコンテキストが追加されます。具体的には、NAS識別子とポート、セッションおよびアイドルタイムアウト、トンネルエンドポイント、外部ソースの指標、応答タイミング、および機密フィールド(パスワードなど)が記録されたかどうかの情報です。これらのフィールドは、アクセス決定がどのように実施されたかを解釈するのに役立ちます。
| フィールド |
説明 |
| アイドルタイムアウト |
セッションが切断されるまでのアイドル時間 |
| 記録済み |
このブール型属性は、そのリクエストが以前に記録されたかどうかを示します |
| Mac |
MACアドレスがRADIUSメッセージのフィールドとして含まれている場合 |
| nas_識別子 |
認証を行うクライアントが要求している役割を特定します |
| nas_ip_address |
これはIPアドレスの形式です。実装によっては、デバイス、エンドポイント、または中間システムのIPアドレスとなる場合があります。 |
| nas_port |
ユーザーを認証するデバイスの物理ポート番号 |
| nas_port_id |
クライアントから提供されたポートを識別する文字列 |
| nas_port_type |
これはポートの通信方式です(例:イーサネット、Wi-Fiなど)。 |
| パスワードが表示された |
パスワードが表示されたことを示すブール型属性 |
| 半径の種類 |
この値は、それがアクセス要求かアカウンティング要求かを示します |
| 返信メッセージ |
サーバーからの応答メッセージ。これは、認証を行うユーザーに頻繁に表示されます。 |
| 返信日時 |
返信メッセージを受信した時刻 |
| 結果 |
認証の成功または失敗 |
| サービス種別 |
ユーザーがリクエストしたサービスの種類 |
| セッションタイムアウト |
これはセッションの最大時間です |
| src_display_name |
送信元のDNS名 |
| src_host_luid |
これは、ホストIDを持つSrcのIDです |
| src_luid |
RADIUSクライアントのLUID |
| src_luid_external |
ソースが外部の場合、値は「True」になります |
| ttl |
最初のリクエストから、「Access-Accept」メッセージまたはエラーが発生するまでの時間。このフィールドが空の場合、リクエストまたはレスポンスのいずれかが確認されなかったことを意味します。 |
| tunnel_client |
トンネルの発信元側のアドレス(IPv4、IPv6、またはFQDN)。存在する場合、これはTunnel-Client-Endpoint属性から取得されます。 |
| ユーザー名 |
これは、Radiusメッセージ内で確認されたユーザー名です |
NASおよびトンネルコンテキストを活用することで、アクセスが許可された場所、要求されたサービス、およびその継続時間を特定できます。これは、リモートアクセス経路を追跡して内部のSMB/RDPアクティビティを調査する際に特に有用です。
SMBファイルのメタデータフィールドとファイル操作属性
SMBファイルのメタデータには、作成、名前の変更、閉じた際の削除動作、パスコンテキスト、SMBバージョン、およびユーザー属性など、ファイルレベルの操作情報が記録されます。
これらのメタデータの種類は、ランサムウェアやラテラル・ムーブメントの調査において極めて重要です。
| フィールド | 説明 |
| アクション | 当該ファイルに対する措置 |
| delete_on_close* | delete_on_close 属性が有効かどうかを示すフラグ。有効になっている場合、ファイルの最終的な閉じ操作時に、そのファイルが最後の閉じ操作の対象である場合、ファイルが削除されることがあります。 |
| ドメイン* | SMBサーバーのドメイン |
| ホスト名* | SMBクライアントのホスト名 |
| パス | ツリーファイルから取得されたパスは、以下の場所との間で転送されました |
| 前の名前 | ファイル名の変更が行われた場合、これがそのファイルの以前の名前になります |
| 名前 | ファイル名(見つかった場合) |
| ユーザー名* | ログインしたユーザー名またはアカウント名。「$」で終わる名前はマシン名(ユーザーアカウント名ではありません) |
| バージョン | SMB バージョン(SMBv1 または SMBv2) |
ファイル操作やファイル名の変更パターンを活用し、脅威ハンティング中に破壊的な動作を特定する。
SMBマッピングのメタデータフィールドと共有接続属性
SMBマッピングのメタデータは、ファイル操作が行われる前に、ツリー構造の接続関係と共有へのアクセス権限を捕捉します。
このレイヤーは、ユーザーのIDと共有アクセス環境を関連付けることで、メタデータの充実化を実現します。
| フィールド | 説明 |
| ドメイン* | SMBサーバーのドメイン |
| ホスト名* | SMBクライアントのホスト名 |
| パス | ツリーパスの名前 |
| サービス | ツリーの再生成元の種類 |
| ユーザー名* | ログインしたユーザー名またはアカウント名。「$」で終わる名前はマシン名(ユーザーアカウント名ではありません) |
| バージョン | SMB バージョン(SMBv1 または SMBv2) |
ファイルレベルの操作を分析する前に、マッピングイベントを使用してアクセス履歴を特定してください。
SMTPメタデータフィールドとメールヘッダー属性
SMTPメタデータは、SPF、DKIM、DMARC、TLSの使用状況、送信元IPアドレスなどのメールヘッダー属性や認証結果を収集します。メール関連のネットワークメタデータは、以下の脅威の検知を支援します フィッシング インフラやなりすまし送信者の行動に対する脅威ハンティングを支援します。
| フィールド | 説明 |
| cc | CCヘッダーの内容(カンマ区切りのリスト形式) |
| 日付 | Dateヘッダーの内容 |
| dkim_status | 合格/不合格/なし。「Authentication-results」ヘッダーに基づく |
| dmarc_status | 合格/不合格/なし。「Authentication-results」ヘッダーに基づく |
| 初回受領日 | 最初の「Received」ヘッダーの内容。これは、このメッセージを最初に受信したSMTPサーバー(つまり送信サーバー)を示す。 |
| 出典: | Fromヘッダーの内容 |
| やあ | Heloヘッダーの内容 |
| 返信先 | In-Reply-Toヘッダーの内容 |
| mail_from | 「From」ヘッダーに含まれるメールアドレス |
| msgid | MsgIDヘッダーの内容 |
| rcpt_to | Rcptヘッダーに含まれるメールアドレス。カンマ区切りのリスト形式で表示されます。 |
| 返信先 | ReplyToヘッダーの内容 |
| 受信時刻(秒) | このメッセージを受信した2番目のSMTPサーバーを示す、2番目の「Received」ヘッダーの内容 |
| 件名 | 件名欄の内容 |
| spf_helo_status | smtpの「Received-SPF」ヘッダーに基づきます。このヘッダーはSPF(Sender Policy Framework)のステータスを示します。ステータスには、pass、fail、neutral、softfail、none、temperror、permerrorのいずれかが指定されます。参照:https://tools.ietf.org/html/rfc7208#section-9.1 |
| spf_mailfrom_status | pass/fail/neutral/softfail/none/temperror/permerror のいずれか |
| TLS | 接続がTLSを使用するよう切り替わったことを示します |
| ~に | 「To」ヘッダーの内容(カンマ区切りのリスト形式) |
| user_agent | クライアントからのUser-Agentヘッダーの値 |
| x_送信元IP | X-Originating-IPヘッダーの内容 |
認証結果とリレーチェーンのメタデータを用いて、送信者の正当性をフォレンジック検証する。
SSHメタデータフィールドと暗号化セッションのネゴシエーション属性
SSHメタデータには、クライアント/サーバーのバージョン、鍵交換、暗号化方式の選択、MACアルゴリズム、フィンガープリントハッシュなどのネゴシエーションの詳細が記録されます。これらのメタデータは、異常な管理ツールの使用や、不正なリモートシェル操作の特定に役立ちます。
| フィールド | 説明 |
| クライアント | クライアントのバージョン文字列 |
| 暗号化アルゴリズム | 使用されている暗号化アルゴリズム |
| 圧縮アルゴリズム | 使用されている圧縮アルゴリズム |
| ハッ | クライアントのSSHパラメータに基づくハッシュ値 |
| hassh_server | haashServer:クライアントのSSHパラメータに基づいて生成されたサーバーのハッシュ値 |
| ホストキー | サーバーの鍵のフィンガープリント |
| host_key_alg | サーバーホストキーのアルゴリズム |
| kex_alg | 使用されている鍵交換アルゴリズム |
| mac_alg | 使用されている署名(MAC)アルゴリズム |
| サーバー | サーバーのバージョン文字列 |
| バージョン | SSHのメジャーバージョン(1 または 2) |
アルゴリズムとフィンガープリントのフィールドを使用して、想定される管理ツールの基準値を確立し、異常なクライアントやネゴシエーションパターンを特定した後、セッションの接続状況に焦点を移し、同じSSHセッションの継続時間、通信方向、通信量を把握します。
SSL/TLS メタデータフィールドと暗号化セッション属性
SSL/TLSメタデータは、暗号化セッションにおけるハンドシェイクのネゴシエーションおよび証明書交換の特性を記録します。以下のフィールドには、プロトコルバージョン、選択された暗号スイート、曲線パラメータ、クライアント/サーバー拡張機能、発行者/サブジェクト識別子、SNI、JA3/JA4フィンガープリント、および接続状態が含まれます。
| フィールド | 説明 |
| 申請 | このセッションに関連するアプリケーション |
| 暗号 | サーバーによって選択されたSSL/TLS暗号スイート |
| client_curve_num* | クライアントから送信された楕円曲線番号 |
| client_ec_point_format* | クライアントが提供する楕円曲線ポイント形式 |
| client_extension* | クライアント拡張機能 |
| クライアント発行者 | クライアント証明書の発行者 |
| client_luid_proxy | 接続の送信元アドレスがプロキシとして登録されている場合、真となる |
| クライアント名 | クライアント証明書のサブジェクト |
| client_version* | クライアントから送信されたSSLバージョン文字列 |
| client_version_num* | クライアントから送信されるSSLのバージョン番号 |
| 曲線 | ECDHEの楕円曲線数 |
| 設立された | このSSLセッションが正常に確立されたか、あるいはハンドシェイク中に中断されたかを示すフラグ |
| 発行者 | サーバー証明書の発行者 |
| ja3 | クライアントのSSLパラメータに基づくクライアントのJA3ハッシュ |
| ja3s | サーバーのSSLパラメータに基づくJA3Sハッシュ |
| ja4 | TLSクライアントのJA4フィンガープリント |
| ja4s | TLSサーバー応答のJA4Sフィンガープリント |
| 次のプロトコル | サーバーは、アプリケーション層の「次のプロトコル」拡張機能が存在する場合、それを使用して次のプロトコルを選択した |
| proxy_to_internal_dst | プロキシ経由後の実際の宛先が内部IPの場合、真となる |
| サーバー拡張機能 | サーバー拡張機能 |
| server_luid_proxy | 接続の宛先アドレスがプロキシとして登録されている場合、真となる |
| サーバー名 | SNI値 |
| 件名 | サーバー証明書のサブジェクト |
| バージョン | サーバーが選択したSSL/TLSバージョン |
| バージョン番号 | サーバーが選択したSSL/TLSのバージョン番号 |
| バージョン/バージョン番号 | SSLのバージョン番号 |
TLSフィンガープリントおよびSNI/証明書コンテキストを使用してクライアント/サーバーの実装と宛先の実体を特定し、その後X.509に移行して証明書のプロパティやSANの適用範囲を検査し、より詳細な信頼性分析を行う。
X.509証明書のメタデータフィールドとデジタル証明書の属性
X.509メタデータは、証明書の識別情報および信頼性に関する特性(サブジェクト/発行者の構成、有効期間、SAN値、鍵長、署名アルゴリズム、JA4Xフィンガープリントなど)を記録します。これらのメタデータタイプは、証明書ベースのメタデータフォレンジックや、不審なインフラストラクチャの検出を支援します。
| フィールド | 説明 |
| 申請 | このセッションに関連するアプリケーション |
| basic_constraints.ca | 証明書の対象がCAであるかどうかを示すフラグ |
| basic_constraints.path_len | この証明書を含む有効な証明書パスの最大深さ |
| certificate.cn | 証明書のホスト名を識別する共通名 |
| certificate.curve | Curve(EC証明書がある場合) |
| certificate.exponent | 主要な代表者 |
| 証明書発行者 | 国、組織、一般名、発行者、URIの組み合わせ |
| certificate.key_alg | データ転送に使用される公開鍵アルゴリズムの名称。例:RSA暗号 |
| certificate.key_length | 暗号化に使用されるビット数。例:2,048ビット暗号化 |
| certificate.key_type | 鍵アルゴリズムに応じて、3つの主要なタイプがあります |
| 有効期限 | 証明書が無効になった後の期間 |
| 有効期限前 | 証明書が無効になるまでの期間 |
| self_issued証明書 | 証明書が自己発行か、CAによって発行されたものかを示すブール値のフラグ |
| certificate.serial | 認証局または署名局によって付与される固有のシリアル番号。通常、40文字の16進数で表される |
| certificate.sig_alg | 署名アルゴリズム名 |
| certificate.subject | 証明書の所有者(識別名) |
| certificate.version | サーバー証明書のバージョン(SSL V3、TLS V1、TLS V2 など) |
| client_luid_proxy | 接続の送信元アドレスがプロキシとして登録されている場合、真となる |
| ja4x | X.509 TLS証明書のJA4Xフィンガープリント |
| proxy_to_internal_dst | プロキシ経由後の実際の宛先が内部IPの場合、真となる |
| san.dns | 1つの証明書に対して、SAN(サブジェクト別名)に関連付けられたDNS名とともに、追加のホスト名のリストを指定する |
| san.email | SANに登録されているメールアドレス |
| san.ip | デジタル証明書に記載されているSANのIPアドレス |
| san.その他のフィールド | SAN内のその他のフィールド |
| san.uri | SANに関連付けられたURL名 |
| バージョン/バージョン番号 | SSLのバージョン番号 |
| server_luid_proxy | 接続の宛先アドレスがプロキシとして登録されている場合、真となる |
X.509属性を使用して信頼状態を評価し、パターンを再利用した後、TLSおよびDNSのメタデータと照合することで、調査の連鎖を完結させる。