2023年10月13日

NECサイバーセキュリティ戦略統括部セキュリティ技術センターの加来です。
今回は、Elastic Security [1]を用いて、内部不正の攻撃シナリオに対する調査・対応を行ってみました。
本ブログでは、その攻撃のシナリオに沿ってElastic Securityの機能を紹介していきます。

Elastic Securityとは

Elastic Securityを使用することで、組織内のマシンから収集した情報を可視化して、効率的なインシデント対応を行うことができます。
例えば以下の様な機能があります。

Elastic Securityには他にも様々な機能があります。主要な機能を理解したい場合は、Elastic社が公開しているガイド [2]を確認して下さい。

検証環境

今回の検証では、Elastic Cloud（v8.10.2）[3]の無料Trialを活用して、以下の環境を構築しました。

riht.comの各マシンにはElastic Agent [4]がインストールされており、データの収集やElastic Securityからの指示の実行を行います。
これらのElastic AgentのアクションはAgent Policyによって定義されています。また、Agent PolicyにはIntegrationを含めることができます。Integrationには、Elastic Agentをインストールしたマシンを観察する設定が製品やサービスごとに定義されています。今回はElastic Defend（v8.10.2）とSystem（v1.38.2）のIntegrationを含めたAgent PolicyをElastic Agentに適用しています。

Elastic Cloudのデプロイや、Elastic Agentのインストール方法などは、Elastic社が公開している動画 [6]が存在するため、本ブログでは割愛させていただきます。

攻撃シナリオ

検証環境に対して、以下の攻撃シナリオを実施しました。

本シナリオで登場する架空の人物「佐藤さん」は、クライアント端末「WS」の正規の利用者です。今回の攻撃シナリオでは、佐藤さんが内部不正を実施します。

3. 4.に関して、攻撃者はレジストリにキャッシュされている資格情報を窃取しています。
Windowsはデフォルトで最近ログオンした10個のドメインアカウントの資格情報をレジストリにキャッシュします。 そのため、過去ドメイン管理者等の特権アカウントでログインしていて、推測可能なパスワードを設定していた場合は、特権アカウントの平文パスワードが特定される可能性があります [8]。

初動対応

詳細な調査に入る前に、まずは関係者にヒアリングを行いつつ端末の隔離等の対応を行います。

AlertからCaseを作成

有効化されているRuleの条件にヒットした場合、以下の画像の様なAlertが確認できます。

タイムスタンプが最も新しいAlertのルール名の「Suspicious Access to LSA Secrets Registry」の部分や、process.nameフィールドの値から、Mimikatzが「WS」のレジストリにアクセスしていると推測できます。

このAlertを起点に調査を進めたいので「Add to new case」をクリック後、Name（名前）・Description（説明）・Severity（重大度）を入力してCaseを作成します。
そうすると、以下のようなCaseが作成されます。

「WS」を隔離する

「WS」の利用者である佐藤さんとその上司にヒアリングを実施しました。
佐藤さんとは連絡が取れず、上司によるとアラートが発生した当日、上司も佐藤さんと連絡が取れていないとのことです。また、Mimikatzのような資格情報窃取ツールを使用するような業務はないということなので今回のアラートを悪性と判断して「WS」のネットワークの隔離を実施します。

端末の隔離にはResponse console [9]を使用すると便利です。

以下の画像のConsoleに「isolate」コマンドを入力するだけで「WS」をネットワークから隔離できます。

隔離が完了すると、「WS」でも隔離されたという通知が表示されました。
（再度「WS」から「DC」へのリモートログオンを試みましたが、失敗しました）

「isolate」で隔離した端末は「release」コマンドを実行するとネットワークに復帰させることができます。
ここで紹介したコマンド以外にも、プロセスを列挙する「processes」コマンドや、特定のプロセスIDを指定してプロセスを終了させる「kill-process」コマンド等、様々なコマンドを使用できます。

調査

Mimikatzがレジストリの資格情報にアクセスした痕跡を確認

Caseを作成したAlertの「Analyze Event」をクリックします。

そうすると、以下のように検知対象のプロセスと他プロセスの関係を視覚的に表示してくれる画面へと遷移します。

mimikatz.exeの「3 registry」をクリックすると、今回mimikatz.exeがアクセスしている3つのレジストリキーを確認できます。その結果、ドメインアカウントの資格情報をキャッシュしているレジストリキー「HKLM\SECURITY\Cache」へのアクセスと、そのアクセス時刻を特定できました。

「WS」から「DC」へのアクセスを確認

「WS」でドメインアカウントの資格情報にアクセスした痕跡が見つかりました。もしここで佐藤さんが普段使用できる権限以上の資格情報（例えばドメイン管理者）がレジストリに保存されており、ハッシュ値から平文パスワードを特定された場合、当該アカウントを使用して、「DC」にアクセスされている可能性が考えられます。
今回はDiscover [10]から生のログを確認します。

DiscoverではKQL（Kibana Query Language）[11]でログを絞りこめます。
送信元IPアドレスが「WS」の192.168.234.149であり、AdministratorユーザーでDCにログオンしたログの有無を確認したいので、以下のようなKQLを実行しました。

KQLを実行後、結果は以下の様になりました。「WS」から「DC」に対して、ドメイン管理者の権限でリモートログオンされていることが確認できました。

タイムラインを作成

タイムラインに表示させるイベントは、フィルターやKQLで絞り込むことができます。今回はレジストリキーが「HKLM\SECURITY\Cache\NL$IterationCount」であるというフィルターに合致するイベントと、「WS」から「DC」へのアクセスを確認した際のKQLでヒットするイベントのみをタイムラインに表示しています。

作成したタイムラインは、以下の様にCaseに紐づけることができます。

また、Elastic SecurityのCaseは、Connectorという機能を用いてサードパーティのJira等のインシデントマネジメントシステムと連携することも可能です [12]。

最後に

本ブログでは、内部不正の攻撃のシナリオに沿ってElastic Securityの機能を紹介しました。
筆者は普段エージェントがインストールされていないマシンから抽出されたログを成形してElastic Searchに投入・解析を行っています。その環境を構築する際、Elastic Searchのフィールドのマッピングをマニュアルで実施して大変だった経験があるので、その辺を自動でやってくれるElastic Security・Elastic Agentの構成は非常に便利だなと感じました。
「Elastic Securityってどんな機能があるの？」という疑問を持っている方にとって、少しでも本ブログが参考になれば幸いです。

参考リンク

執筆者の他の記事を読む