セキュリティ調査の流れ

既述のアラートメール設定により、緊急対応が必要なアラートメールを受信した場合に実施する調査ステップの例を示します。　

「脆弱性防御」イベントの調査

脆弱性攻撃で、重大度がCritical且つActionがAlert(ブロックされていない)攻撃が発生した場合の調査の流れです。

PA FirewallのWebUIにログインします。

a)「Monitor」 → ログの下のb)「脅威」をクリックします。

フィルタリングで、c)「( subtype eq vulnerability ) and ( severity eq critical ) and ( action eq alert )」を指定してログを絞り込みます。

d)のアイコンをクリックして、詳細を表示します。

詳細ログビューです。

• a-1)、a-2)で通信の向きを確認します。TCP 3WAYハンドシェークのTCP SYNを発した方が送信元になります。
• a-3)を見ると、「サーバからクライアント」にチェックが入っているので、本攻撃はサーバ→クライアント＝外部→内部への攻撃であることが分かります。
• a-1)が被害を受けたIPアドレスなので、このIPを持つ端末がどのような用途で使用されているのかを確認します。
  本例では、おそらくクライアントPCであろうことが想像されます。
• b)の脅威名から、Microsoft Internet Explorer関連の脅威であることが分かります。
• c)で、アプリケーションはWebブラウジングであることが分かります。

この例では、クライアントPCがWebブラウザであるサーバにアクセスした通信が、外部(インターネット)から内部に対しての通信で、Microsoft Internet Explorer関連の脆弱性(Vulnerability)をつく攻撃であるとして検知しています。

重大度はCriticalでありながら、防御設定が行われてないため、調査が必要です。

攻撃の名前にカーソルを合わせるとマークが出るので、それをクリックして、現れた「例外」をクリックします。

脅威の詳細が確認できます。

本例は、CVE-2015-0036で報告されている脆弱性であることが分かります。

脆弱性の詳細を、ベンダー(本例ではMicrosoft社)のサイトまたは外部サイトで確認します。

外部サイトの例：JVN (Japan Vulnerability Notes)

JVNサイト(http://jvndb.jvn.jp)はJPCERTとIPAが共同で運営しています。

このサイトでCVE番号を用いて検索することで、その脆弱性に関する以下のような詳細情報を日本語で確認できます。

ベンダーまたは外部サイトが推奨する対策が、脆弱性をつく攻撃を受けたIPアドレスの端末で施されているかを確認します。
(脆弱性については、ソフトウェアパッチがリリースされていることが多いので、対策としては、その端末に該当パッチを充てるか、対策済みの最新バージョンを適用する、という場合が多いと思います。)

→対策済みの場合は影響なしと判断できます。

「アンチウイルス」イベントの調査

ウィルスを、POP3 / IMAPで検知した場合の調査の流れです。

a)「Monitor」 → ログの下のb)「脅威」をクリックします。

フィルタリングで、c)「 (subtype eq virus) and (action eq alert) and ((app eq pop3) or (app eq imap)) 」を指定してログを絞り込みます。

d)のアイコンをクリックして、詳細を表示します。

詳細ログビューです。

• a-1)、a-2)で通信の向きを確認します。TCP 3WAYハンドシェークのTCP SYNを発した方が送信元になります。
• a-3)を見ると、「サーバからクライアント」にチェックが入っているので、本攻撃はサーバ→クライアント＝外部→内部への攻撃であることが分かります。
• c)で、メールの送信者やサブジェクトが分かります。

b) の”ID”の右横にある「View in Threat Vault」をクリックします。

THREAT VAULTサイト (https://threatvault.paloaltonetworks.com/) にて、a)該当ID：219723564の情報が表示されます。
(※THREAT VALUTへのアクセスには、別途パロアルトネットワークスのCustomer Support Portalのアカウントが必要です。アクセスできない場合は、購入元の販売代理店にお問合せください。)

上記b)のハッシュ値をコピーして、今度はそれを上記a)の検索フォームにペーストして、c)「Search」ボタンを押します。

d)のVirusTotalをクリックします。

このファイルは、VirusTotal内の59社のウィルス対策製品のうち、20社がウィルスと判定した、という結果となりました。

自社で導入しているクライアントPCのウィルス対策製品がこの一覧に含まれていれば、感染は防止できている可能性が高いと考えられます。

［参考］ これ以降は、被害者IPアドレスを持つ端末に対して、以下のような処置を行います。

• アンチウィルスソフトウェアで端末をスキャンし、駆除を行います。
• アンチウィルスソフトウェアが導入されていない場合には、クリーンインストールまたはバックアップからの復元を検討します。

「WildFire」イベントの調査

未知のファイル(＝シグネチャにヒットしないファイル)を受信して、Wildfireが攻撃 (Malicious) として検知した場合の調査の流れです。

a)「Monitor」 → ログの下のb)「Wildfireへの送信」をクリックします。

フィルタリングで、c)「 (verdict eq malicious) and ( severity eq high ) 」を指定してログを絞り込みます。
(重大度がInformationalのログについては、後述します。)

d)のアイコンをクリックして、詳細を表示します。

詳細ログビューです。

• a-1)、a-2)で通信の向きを確認します。TCP 3WAYハンドシェークのTCP SYNを発した方が送信元になります。
• a-3)を見ると、「クライアントからサーバ」にチェックが入っているので、本攻撃はクライアント→サーバ＝内部→外部への攻撃であることが分かります。
• b)の詳細を確認します。(本例は、ファイルタイプから、スクリプトファイルであることがわかります。)
• c)から、メールによってこのファイルがクライアントからサーバへ送信されたことが分かります。
• d)「Wildfire分析レポート」タブをクリックします。

Wildfire分析レポートです。

レポート内のa)「VirusTotal」をクリックして、他社アンチウイルスでこのファイルをウィルスとして検知しているかどうかを確認します。

このファイルは、VirusTotal内の59社のウィルス対策製品のうち、42社がウィルスと判定した、という結果となりました。

この場合は、アンチウイルスの調査の場合と同様の対処を行ってください。

ファイルによっては、VirulTotalでファイルが見つからない＝他社アンチウィルスで検知していない、という結果になる場合があります。

この場合は、ゼロデイ攻撃である可能性があります。

端末がマルウェアに感染している場合は、次のフェーズとしてC&Cサーバへの通信を試みることが予想されます。

Wildfire分析レポートの内容を確認し、その端末がNetwork Activity欄に記載されている宛先へ通信を開始した形跡があるか、またはその他の宛先であっても、その端末がDNSシグネチャやURLフィルタリングにヒットする宛先へ通信していないか、脅威ログで確認します。

(Wildfire分析レポートで攻撃の詳細を確認する方法は、既述の「Wildfireログの使い方」を参照してください。)

それらへの通信の形跡があれば、感染の可能性が高いといえます。

それらへの通信が行われていなければ、その端末の経過観察を行ってください。

感染の可能性が高い場合、は被害者IPアドレスを持つ端末に対して、以下のような処置を行います。

• その端末をネットワークから切り離します。
• クリーンインストールまたはバックアップからの復元を検討します。

［参考］ 判定が「Malicious」でありながら、重大度が「Informational」のログについて

PAN-OS8.0より、WildFireプロファイルを設定してファイル送信を有効にした場合、未知のファイルだけでなく、アンチウイルスシグネチャでブロックされたファイルも送信するようになりました。

このことで、WildFireはマルウェアの亜種 (＝既知のマルウェアから変異した類似のもの) から貴重な情報を抽出できます。

アンチウイルスシグネチャは、亜種と一致する場合が多いので、PA Firewallがこれまでに見たことのない亜種もブロックすることができます。

それはそれで利点でもありますが、ブロックしただけだと、その亜種が動作した際に通信する宛先URL、ドメイン、IPアドレスの情報は取得できない、ということになります。

そこで、ブロックされた亜種ファイルもWildFireに送信することで、それらを取得することができるようになり、その情報からURLフィルタリングやDNSセキュリティなどのシグネチャを生成することも可能になります。

その結果、副次的に、そのブロックしたファイルも「WildFireへの送信」ログで詳細を確認できるようになりました。

これが、判定が「Malicious」でありながら、重大度が「Informational」のログの正体です。

詳細はこちら：
WildFire Analysis of Blocked Files
この動作を止めたい場合の設定も用意されている：
How Do I Disable WildFire Forwarding of Blocked Files?

「アンチスパイウェア」イベントの調査

スパイウェアで、重大度が高く(Critical)且つActionがAlert(ブロックされていない)攻撃が発生した場合の調査の流れです。

a)「Monitor」 → ログの下のb)「脅威」をクリックします。

フィルタリングで、c)「(severity eq critical) and (subtype eq spyware) and (action eq alert)」を指定してログを絞り込みます。

d)のアイコンをクリックして、詳細を表示します。

詳細ログビューです。

• a-1)、a-2)で通信の向きを確認します。TCP 3WAYハンドシェークのTCP SYNを発した方が送信元になります。
• a-3)を見ると、「クライアントからサーバ」にチェックが入っているので、本攻撃はクライアント→サーバ＝内部→外部への攻撃であることが分かります。
• b)の脅威名から、WireLurkerに関連したC&Cへの通信であることが分かります。
• c)で、Webブラウジングを使って、通信が行われていることが分かります。

脅威ログ一覧の画面に戻って、名前にカーソルを合わせて表示されたプルダウンから「例外」を選択します。

表示された以下画面のDescriptionから、送信元端末は、マルウェア「WireLurker」に感染して、外部と通信している可能性が高い、と判断できます。

「WireLurker」がどのようなマルウェアなのかは、一般的なインターネット検索で調査してください。

［参考］ これ以降は、被害者IPアドレスを持つ端末に対して、以下のような処置を行います。

• その端末をネットワークから切り離します。
• アンチウィルスソフトウェアで端末をスキャンし、駆除を行います。
• アンチウィルスソフトウェアが導入されていない場合には、クリーンインストールまたはバックアップからの復元を検討します。

「自動相関」イベントの調査

自動相関で、重大度が高い(Critical)攻撃が発生した場合の調査の流れです。

自動相関エンジンは、ネットワーク上のパターンを追跡し、疑わしい動作への拡散を示しているイベントや、有害なアクティブティに達したイベントの相関付けを行います。

相関オブジェクト

相関エンジンは、相関オブジェクトを使用して、相関されたイベントを生成します。

これにより、関連がないように見えるいくつかのネットワークイベント間の共通点を追跡できるようになります。

(※環境の都合により、本セクションではPanoramaの画面を使います。)

自動相関オブジェクトは、a)「Monitor」 → 自動相関エンジン下のb)「相関オブジェクト」で確認できます。

無効化 / 有効化の設定は可能ですが、内容を変更・追加することはできません。

相関されたイベント

相関オブジェクトで定義された内容にヒットした場合に、この相関されたイベントが出力されます。

a)「Monitor」 → 自動相関エンジン下のb)「相関されたイベント」をクリックします。

d)のアイコンをクリックして、詳細を表示します。

詳細ログビューです。

a)「一致情報」タブをクリックします。

• b)には、「詳細な説明： この相関オブジェクトは、最近登録されたドメインまたはダイナミックDNSドメインへの繰り返しのアクセス、同じ場所からの繰り返しのファイルダウンロード、不明なトラフィックの生成など、コマンドアンドコントロール（C2）ビーコンに似たアクティビティに基づいて侵害された可能性のあるホストを検出します。」との記載があります。
• c)には、「サマリー: ホストが既知のマルウェアURLにアクセスしました（100回）。」との記載があります。

d)「一致の証拠」タブをクリックします。

• e)は、この”相関されたイベント”の根拠となる複数のログです。多数のURLへの通信を行っていることがわかります。
• f-1)、f-2)で通信の向きを確認します。TCP 3WAYハンドシェークのTCP SYNを発した方が送信元になります。
• f-3)を見ると、「クライアントからサーバ」にチェックが入っているので、本攻撃はクライアント→サーバ＝内部→外部で検知したものであることが分かります。

本例では、送信元端末がマルウェアに感染してしまい、C2と思われるサーバに何度もアクセスを試みている状況と考えられます。

よって、この端末を一旦隔離し、マルウェアへの感染状況を調査する必要があります。