この記事では、マルウェアインシデントを調査するための典型的なシナリオを共有し、ログで何を検索するかを教え、調査の成功の可能性を高めるための情報セキュリティツールの構成方法に関する技術的な推奨事項を示します。
マルウェアに関連するインシデントに対応するための古典的なプロセスには、検出、封じ込め、復旧などの段階が含まれますが、実際には、すべての機能は準備段階で決定されます。 たとえば、感染の検出率は、会社で監査がどの程度適切に構成されているかに直接依存します。
従来のSANSインシデントレスポンスサイクル
一般的に、調査中のアナリストの行動は次のとおりです。
- インシデントの原因を説明するバージョンの生成（たとえば、「ユーザーがフィッシングメールからマルウェアを起動したため、マルウェアがホストにインストールされた」または「ユーザーが管理サーバーと同じホスティングにある正当なサイトを訪問したため、インシデントは誤報です」マルウェア」）。
- 確率の度合いによるバージョンの優先順位付け。 確率は、過去のインシデントの統計、インシデントまたはシステムの重要度、および個人的な経験に基づいて計算されます（かなりふりをします）。
- 各バージョンの研究、それを証明または反証する事実を検索します。
もちろん、少なくとも時間に限りがあるため、考えられるすべての仮説をチェックすることは意味がありません。 したがって、ここでは、マルウェアインシデントを調査するための最も可能性の高いバージョンと典型的なシナリオを見ていきます。
シナリオ1
重要ではないシステムがマルウェアに感染していると思われます。 システムの重要性が低いため、検証に少し時間が割り当てられています。ほとんどの対応エンジニアが最初に行うことは、ウイルス対策チェックを実行することです。 しかし、私たちが知っているように、アンチウイルスは回避するのがそれほど難しくありません。 したがって、次の非常に可能性の高いバージョンを作成して解決する価値があります。マルウェアは別個の実行可能ファイルまたはサービスです。
このバージョンの開発の一環として、次の3つの簡単な手順があります。
- イベント4688でセキュリティログをフィルタリングします-開始したすべてのプロセスのリストを取得します。
- イベント7045でシステムログをフィルター処理します。したがって、すべてのサービスのインストールの一覧を取得します。
- 以前システムになかった新しいプロセスとサービスを特定します。 これらのモジュールをコピーし、悪意のあるコードを分析します（複数のウイルス対策ソフトウェアでスキャンし、デジタル署名の有効性をチェックし、コードを逆コンパイルします）。
イベントログエクスプローラーで実行中のすべてのプロセスとサービスを一覧表示する
理論的には、これはかなり簡単なプロセスです。 ただし、実際には、いくつかの落とし穴があります。
まず、標準のWindows監査設定はプロセス起動の事実を記録しないため（イベント4688）、ドメイングループポリシーで事前に有効にする必要があります。 この監査が事前に含まれていないことが発生した場合は、 Amcacheレジストリなど、他のWindowsアーティファクトから実行可能ファイルのリストを取得してみてください。 AmcaheParserを使用して、このレジストリファイルからデータを抽出できます。
Amcache.hveからプロセスを開始する事実を抽出する例
ただし、この方法はプロセスがいつ、何回開始されたかについて正確な情報を提供しないため、あまり信頼できません。
第二に、 cmd.exe、powershell.exe、wscript.exeおよびその他のインタープリターなどのプロセスの起動の証拠は、プロセスが開始されたコマンドラインに関する情報なしではほとんど役に立ちません。 潜在的に悪意のあるスクリプトファイルへのパスが含まれています。
起動されたスクリプトに関する情報なしでスクリプトインタープリターを実行する
Windowsのもう1つの機能は、起動されたプロセスのコマンドライン監査が、ドメイングループポリシーを個別に構成することによって実行されることです。 コンピューターの構成->ポリシー->管理テンプレート->システム->プロセス作成の監査->プロセス作成イベントにコマンドラインを含める 同時に、かなり人気のあるWindows 7/2008では、 KB3004375更新プログラムがインストールされていないとコマンドラインがログに記録されないため、事前に配置してください。
事前に何も設定していないか、更新を忘れた場合は、 プリフェッチファイル（ 支援するユーティリティ ）でスクリプトの場所を確認してください。 これらには、最初の10秒間にプロセスにロードされたすべてのファイル（主にDLL）に関する情報が含まれています。 そして、インタープリターのコマンドライン引数に含まれるスクリプトは確かにそこに存在します。
プリフェッチで「失われた」コマンドライン引数を見つける例
ただし、この方法はまったく信頼できません。次にプロセスを開始すると、プリフェッチキャッシュが上書きされます。
調査の準備：
- プロセスの作成と完了の高度な監査を含めます。
- プロセスのコマンドライン引数のログを有効にします。
- Windows 7 / Server 2008に更新KB3004375をインストールします。
シナリオ2
マルウェア管理サーバーへのアクセスが境界ルーターに記録されました。 悪意のあるサーバーのIPアドレスは、セキュリティが中程度の脅威インテリジェンスサブスクリプションから取得されました。以前の記事の1つで、 TIのアナリストは、マルウェアコントロールセンターと正当なWebサイトの両方をホストするサーバーのIPアドレスを侵害の兆候のリストに追加することで罪を犯したと述べました。 応答プロセスを策定し始めたばかりの場合、最初の段階では、ユーザーが正当なWebサイトに入ろうとする試みはすべて本格的なインシデントのように見えるため、このようなインジケーターの使用を放棄する方が適切です。
このようなアラームに対応するためのオプションの1つは、どのプロセスが接続を行ったかを確認することだけです。インターネットブラウザーの場合、侵害を示す他の事実がない場合、インシデントは誤ったアラームと見なされます。
どのプロセスが接続を開始したかを調べるには多くの方法があります。netstatを実行して現在のソケットを確認するか、メモリダンプを収集してから、 揮発性を設定します。 しかし、これはすべて長く、スケーラブルではなく、最も重要なのは信頼性がありません。 Windowsセキュリティログから必要な情報をすべて取得する方がはるかに信頼できます。
HPE Arcsight SIEMシステムの「悪意のあるIPアドレスへのアクセス」イベントとWindowsセキュリティログの対応するプロセスの相関
調査準備
ユーザーマシンでこのシナリオを実行するには、すべてのネットワーク接続のセキュリティのログを有効にする必要があります。 これは、フィルタリングプラットフォームの監査イベントとパケットドロップ監査に基づいて実行できます。
同時に、マガジンがすぐに詰まり始める可能性があるため、サイズを2〜3 GBに増やします。 経験上、通常のユーザーホストでは、この量はすべてのソケットを記録するのに約3日間で十分であり、この期間は調査を成功させるのに十分です。
ドメインコントローラー、Webサーバーなどの負荷の高いサーバーでは、これを行うべきではありません。ログははるかに速くオーバーフローします。
シナリオ3
NG / ML / Anti-APT異常検出システムは、30人のホストが同じアカウントを取得しようとしていると報告しています。新しいネットワークに入ると、攻撃者は通常、そこに存在するサービスと使用されているアカウントを見つけようとします。これは、インフラストラクチャに沿ってさらに移動するプロセスで非常に役立ちます。 特に、この情報は、 net user / domainコマンドを使用してActive Directory自体から取得できます。
潜在的なインテリジェンスが1つのホストから実行される場合、実行中のプロセスのログを使用するなど、調査することができます。 ただし、多数のホストがあり、攻撃が同じタイプ（同時に発生するか、ADから同じエンティティセットが要求された）である場合、まず典型的な誤検知を除外することは理にかなっています。 これを行うには、次のバージョンを作成して確認します。
- ネットの正当なユーザーである管理者がnetコマンドを起動したため、同じADオブジェクトの30個のホストでインテリジェンスが修正されます。
- 同じ合法的なソフトウェアを作成したため、同じADオブジェクトの30のホストでインテリジェンスが修正されます。
ログの統計分析は、これらのノードポイント（一般的なユーザーまたはプロセス）の検出に役立ちます。 DNSサーバーログに適用される以前の記事で、この方法を示しました。 ただし、データの保存が事前に編成されていない場合、このような効果的な調査方法は使用できません。
調査準備
一般的なネットワークサービスログから少なくとも次のデータの長期保存を整理する必要があります。
- ドメインコントローラー-ログイン、ログイン、チケット発行Kerberos（詳細監査設定のカテゴリーアカウントログオン ）。
- プロキシ-アドレス、送信元および外部サーバーのポート、および完全なURL。
- DNSサーバー-成功したDNSクエリと失敗したDNSクエリ、およびネットワーク内のソース。
- 境界ルーター-すべてのTCP / UDP接続、および論理アクセスルールに違反しようとする接続（たとえば、企業のDNSサーバーをバイパスして直接DNSクエリを外部に送信しようとする接続）の構築およびティアダウン。
シナリオ4
ドメインが危険にさらされており、攻撃者がDCShadowテクニックを使用してインフラストラクチャの足場を獲得することを心配しています。
ひどいことが起こったとしましょう：ドメイン管理者アカウントが危険にさらされていることがわかります。
このようなインシデントへの対応には、このアカウントでコミットされたすべてのアクションの分析など、非常に大きな作業層が含まれます。 この調査の一部は、ドメインコントローラーのログのみを使用して実行できます。 たとえば、Kerberosチケットの発行に関連するイベントを調べて、このアカウントの下でどこから来たのかを理解できます。 または、重要なADオブジェクトの変更に関連するイベントを分析して、高度な特権を持つグループ（同じドメイン管理者）の構成が変更されたかどうかを確認できます。 当然、これにはすべて事前に構成された監査が必要です。
ただし、ドメイン管理者権限を持つ攻撃者が、ドメインコントローラ間のレプリケーションメカニズムに基づくDCShadowテクニックを使用してADオブジェクトを変更できるという問題があります。
その本質は、攻撃者自身がドメインコントローラーであるように見え、ADに変更を加えた後、これらの変更を正当なコントローラーに複製（同期）し、それらに設定されたオブジェクト変更の監査をバイパスすることです。 このような攻撃の結果、ドメイン管理者のグループにユーザーを追加したり、 SID履歴属性を変更したり、 AdminSDHolder ACLオブジェクトを変更したりすることで、巧妙なバインディングを行うことができます。
ADのコミットされていない変更の存在についてバージョンを確認するには、コントローラーのレプリケーションログを調べる必要があります。ドメインコントローラー以外のIPアドレスがレプリケーションに関与していた場合、攻撃が成功したと自信を持って言うことができます。
ADレプリケーションから不明なドメインコントローラーを削除する
調査の準備：
- 侵害されたアカウントによってコミットされたアクションを調査するには、事前に含める必要があります。
- DCShadow攻撃の可能性に関連するバージョンを調査するには：
- ディレクトリサービスレプリケーションの詳細監査を有効にします。
- イベント4928/4929の長期保存を整理します。イベントソースは正当なドメインコントローラーではありません（DCShadow属性）。
おわりに
この記事では、情報セキュリティインシデントを調査するためのいくつかの典型的なシナリオとそれらの予防的準備のための対策について説明しました。 このトピックに興味があり、さらに先に進む準備ができている場合は、 このドキュメントに注意を払うことをお勧めします。 このドキュメントでは、どのWindowsイベントで一般的なハッキングテクニックの使用の痕跡を見つけることができるかを説明しています。
最後に、サイバーセキュリティ会社に関する最近の調査からの引用で終わりたいと思います。
「ほとんどの場合、情報セキュリティのロシアのディレクターは悲観的な答えを出す傾向があります（調査の質問に対して）。 このように、半分（48％）は予算は決して変わらないと考えており、15％は資金が削減されると考えています。個人的には、これは、新しい年の残りの予算を、機械学習検出器や別の次世代IDSなどの新しい形式のSZIの購入ではなく、既存のSZIの微調整に費やす方が良いというシグナルです。 そして、最高のSZIはWindowsログを正しく構成することです。 私見。