GOADとLive Malware Labsの自動化

はじめに：スケーラブルで自動化されたシミュレーション範囲の必要性

現代のセキュリティ運用において、検出エンジニアリングはもはや「設定して忘れる」ような分野ではありません。あらゆるセキュリティ チームにとっての中心的な課題、そしてパープル チーム アプローチ全体の根底にある疑問はシンプルです。検出ルールが本当に機能しているかどうかをどうやって確認するかということです。絶えず変化する敵対者のツールキットに対する検出ロジックを継続的に検証することが、今や基本的な要件となっています。

おそらく、この取り組みにおける最大のハードルは常にラボの設置でした。マルチドメイン Active Directory フォレストを手動でプロビジョニングし、特定の脆弱性に合わせて構成し、独立したマルウェア分析環境を展開することは、複雑で時間のかかるプロセスです。この反復的なセットアップ作業は、組織の最も貴重なリソースである上級セキュリティアナリストの時間を大幅に浪費します。コミュニティの議論でもこの不満が反映されており、1 つのテストを実行する前に手動セットアップに費やす時間が強調されています。

このブログでは、迅速なインフラストラクチャ自動化と統合セキュリティ分析プラットフォームを組み合わせることでこのボトルネックを解消する最新のソリューションについて詳しく説明します。このソリューションは、次の 2 つの主要コンポーネントを活用します。

1. ルダス:単一のコマンドから複雑なマルチ VM サイバー レンジを展開および構成するオープン ソースの自動化オーバーレイ。
2. Elastic Security:セキュリティ情報イベント管理 (SIEM)、eXtended Detection and Response (XDR)、クラウド セキュリティを統合し、脅威の取り込み、検出、対応を行う統合ソリューションを提供するプラットフォームです。シミュレートされた環境内でのあらゆるアクションを観察するために必要な「無制限の可視性」を提供します。

このガイドの目的は、この統合システムを構築するための明確な段階的な青写真を提供することです。遅くて手動で一貫性のないラボテストから、 Elastic Cortadoが提供するものを超えた継続的かつ自動化されたスケーラブルな検出エンジニアリング ワークフローに移行する方法を説明します。

ソリューションアーキテクチャ：Ludus + Elastic

このアーキテクチャは、現代のハイブリッド エンタープライズの高忠実度シミュレーションを表します。Ludus シリーズは「オンプレミス」または IaaS データ センターとして機能し、Elastic Cloud デプロイメントは「SaaS」セキュリティ スタックを表します。このモデルは、Elastic Security が保護するように設計されているハイブリッドおよびマルチクラウド環境を完全に反映しており、テストのアーキテクチャは攻撃自体と同じくらい価値のあるものになります。

ビルドは次のコア コンポーネントで構成されます。

コンポーネント 1: 財団 (Ludus)

Ludus は、Infrastructure-as-a-Service (IaaS) レイヤーとして機能します。Proxmox 8/9 または Debian 12/13 で実行するように構築されており、YAML 構成ファイルを使用して複雑な仮想ネットワークを定義し、最大 255 の異なる VLAN をサポートします。舞台裏では、Ludus は Packer と Ansible を簡単に活用して、単一のファイルから仮想マシン テンプレートを構築、構成、展開します。
Ludusクイックスタートのインストール手順とハードウェア要件を確認し、それに従います。

コンポーネント2: ターゲット（ラボ）

このガイドでは、2 つの異なる Ludus 環境を 1 つの包括的な範囲に統合し、より広範囲の脅威をテストします。

• アクティブ ディレクトリのゲーム (GOAD): Orange Cyberdefenseのセキュリティ研究者によって設計された専用の Active Directory ラボ。Kerberoasting、NTLM リレー、Active Directory 証明書サービス (ADCS) の悪用など、一般的な ID ベースの攻撃パスをシミュレートするために必要な特定の誤った構成と脆弱性が事前に構成されています。
• XZbot マルウェアラボ:高リスク、高忠実度のマルウェア環境。このラボには、実際に機能するCVE-2024-3094 バックドアが含まれています。これは、高度なソフトウェア サプライ チェーン攻撃に対する完璧な最新のテスト ケースを提供します。

重要な免責事項

研究目的であっても、ライブマルウェアを扱うことは、ISP またはクラウド プロバイダーの許容使用ポリシー (AUP) に違反する可能性があります。インフラストラクチャを所有していることを確認し（Ludus はオンプレミス）、上流の ISP がそのような調査を許可していることを確認するか、トラフィックを VPN 経由でルーティングします。

コンポーネント3: センサーグリッド（Elastic AgentとDefend）

可視性を高めるために、GOAD ラボと XZbot ラボの両方にわたる Ludus 範囲のすべての仮想マシンに、データ収集と保護 (Elastic Defend 経由) のための単一の統合エージェントであるElastic Agentが実装されます。

このインストルメンテーションは、 badsectorlabs/ludus_elastic_agent Ansible ロールによって自動化されます。この役割は、インフラストラクチャ プロビジョニング フェーズ (Ludus/Ansible) とセキュリティ インストルメンテーション フェーズ (Elastic) をプログラム的に橋渡しし、真の「インフラストラクチャ アズ コード」ワークフローを実現する重要な要です。

重要なのは、Elastic Agent ポリシーがElastic Defend統合で構成されます。これにより、エージェントは単純なログ コレクターから、フル機能のエンドポイント検出および対応 (EDR)/拡張検出および対応 (XDR) ソリューションへと昇格し、ホストベースの検出 (機械学習 (ML) によるマルウェアおよびランサムウェアの検出を含む) と、検出に不可欠な詳細なカーネル レベルのテレメトリが提供されます。

注: このブログで説明されているパープル チームのアプローチでは、ポリシーを検出モードに設定してください。

コンポーネント 4: 脳 (Elastic Cloud Hosted / Elastic Serverless)

Ludus シリーズの Elastic Agent からのすべてのセキュリティ テレメトリとアラートは、集中管理されたElastic Cloud Hosted (ECH)またはElastic Serverlessデプロイメントにストリーミングされます。ここで、統合プラットフォームの分析力が発揮されます。クラウド ネイティブ プラットフォームを使用するのは、ホスティングのためだけではありません。Attack DiscoveryやAI アシスタントなど、Elastic の最も高度で強力な機能を利用できるようになるためです。Elastic Cloud のトライアルを開始するには、ここをクリックしてください。

以下の図は、 GOAD ラボに基づいたビルドの概要を示しています。

フェーズ1：レンジの構築と計装

このセクションでは、自動化範囲の構成と展開に関する技術的なステップバイステップ ガイドを提供します。このプロセスは明確な「コードとしてのインフラストラクチャ」(IaC) モデルに従っており、セキュリティ計測がインフラストラクチャ自体と並行して定義され、すべての展開で一貫性のある繰り返し可能な監視体制が確保されます。Elastic Cloud インスタンスとその構成は、範囲と SIEM の完全な IaC モデル用のElastic CloudおよびElastic Stack Terraform プロバイダーを使用して管理できます。

3.1 Elastic Agentポリシーの設定（Kibana）

Ludus 範囲のデプロイメントを実行する前に、Elastic Cloud インスタンスにエージェント ポリシーを作成する必要があります。このポリシーにより、強力な EDR/XDR テレメトリが可能になります。

操作フローは以下のとおりです。

1. Elastic Cloud (ECH) または Elastic Serverless Kibana インスタンスにログインします。
2. [管理] > [フリート]に移動します。
3. 新しいエージェント ポリシー(例: 「ludus-range-policy」) を作成します。ludus_elastic_agent ロールは、VM レベルのカスタマイズで指定したポリシー、またはグローバル変数にリンクされたデフォルト ポリシーにエージェントを登録します。
4. このポリシーにElastic Defend統合を追加します。
5. Elastic Defend 統合を検出モードで実行するように設定します。これにより、EDR テレメトリの完全なスイートがアクティブになります。
6. ポリシーを保存し、「エージェントを追加」をクリックします。これにより、ludus.yml ファイルに必要な登録トークン(ludus_elastic_enrollment_token 用) とフリート サーバー URL (ludus_elastic_fleet_server 用) が提供されます。
7. (オプション) 手順 3 ～ 6 を繰り返して、ホストの機能と VM レベルのポリシーのカスタマイズ機能に合わせてカスタマイズされたポリシーを作成します。

このポリシーが作成され、トークンが ludus.yml ファイルに貼り付けられると、Ludus range deploy を実行すると、完全な自動化されたワークフローが実行されます。Ludus が VM をプロビジョニングし、Ansible が Elastic Agent をインストールします。Elastic Agent はその後 Fleet に登録され、Elastic Defend 統合を含むポリシーが自動的にプルダウンされます。これにより、ラボが作成された瞬間から、カーネル レベルのプロセス、ファイル、ネットワーク、レジストリ イベントなどの豊富な EDR テレメトリが提供されます。

3.2 Ludus YAML 構成 (ludus.yml)

Ludus は、GOAD 範囲を展開するための手順をここで提供しています。範囲の設定は、ludus.yml 設定ファイルに保存されます。GOAD 範囲の場合、 ad/GOAD/providers/ludus/config.yml .
にあります。付録の完全な設定は、完全な GOAD ラボ (VLAN 10 上) と XZbot ラボ (VLAN 20 上) をマージするサンプル実行設定に基づく例です。

インストール中にカスタマイズされたバージョンを展開するには、手順 2でgoad.shスクリプトを実行する前にad/GOAD/providers/ludus/config.ymlファイルを更新します。

git clone https://github.com/Orange-Cyberdefense/GOAD.git
cd GOAD
sudo apt install python3.11-venv
export LUDUS_API_KEY='myapikey'  # put your Ludus admin api key here nano ad/GOAD/providers/ludus/config.yml # customize the configuration here
./goad.sh -p ludus
GOAD/ludus/local > check
GOAD/ludus/local > set_lab GOAD # GOAD/GOAD-Light/NHA/SCCM
GOAD/ludus/local > install

範囲をカスタマイズするには、次の 2 つの主要な構成オプションを使用できます。

1. グローバル変数:構成を簡素化し、繰り返しを回避するために、Elastic Agent 変数はグローバル Ansible.vars ブロックの最上位レベルで1 回定義され、すべての VM に継承されます。

   登録トークンによって、使用される Elastic Agent ポリシーが決まります。

# ludus.yml
---
# --- GLOBAL ANSIBLE VARS (Simplification) ---
# Define Elastic agent vars once and apply globally
global_role_vars:
  ludus_elastic_fleet_server: "<your-fleet.example.com:443>" # Use 443 for cloud
  ludus_elastic_enrollment_token: "<your_enrollment_token>"
  ludus_elastic_agent_version: "9.2.1"

2. VM レベルの変数: Elastic Agent 変数を VM レベルで構成して、適用されるポリシーをカスタマイズできます。これらはグローバル変数と組み合わせることができます。たとえば、エージェント バージョンと fleet_server はグローバル変数を介して設定され、登録トークンは VM レベルで設定され、VM に異なるポリシーが適用されます。

# --- VM DEFINITIONS ---
vms:
  # --- GOAD LAB (VLAN 10) ---
  - name: "{{ range_id }}-GOAD-DC01"
    hostname: "{{ range_id }}-DC01"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 10
    ram_gb: 4
    cpus: 2
    windows: { sysprep: true }
    ansible:
      roles:
        - badsectorlabs.ludus_elastic_agent
      role_vars:
        ludus_elastic_enrollment_token: "<your_enrollment_token>" # different token for different policies
  # (Definitions for GOAD-DC02, GOAD-DC03, GOAD-SRV02, GOAD-SRV03 
  #  would follow, all inheriting the global ansible vars)

Elastic Agentのデプロイメントの自動化

上記の ludus.yml スニペットは自動化を示しています。各 VM 定義の ansible.roles セクションにbadsectorlabs.ludus_elastic_agentロールを追加すると、Ludus はデプロイメント中にエージェントを自動的にインストールして構成します。

この単一の Ansible ロールは、Windows (GOAD 用)、Kali、Debian (XZbot 用) など、異機種混在ラボ内のすべてのオペレーティング システムと互換性があります。

簡略化された YAML に示されているように、最上位レベルの ansible.vars ブロックは重要なパラメータをロールに渡します。

• ludus_elastic_fleet_server: Elastic Cloud デプロイメントの Fleet サーバー URL とポート (例: your-fleet.example.com:443)。
• ludus_elastic_enrollment_token: エージェントを登録するトークン。
  完全な例では、さまざまなポリシーを使用できることを示すために、VM レベルで ludus_elastic_enrollment_token を設定します。
• ludus_elastic_agent_version: インストールする特定のエージェント バージョン (例: 9.2.1)。

注意: Kali ホストには、攻撃者の行動を監視するために Elastic Defend も導入されますが、実際のシナリオではこれは不可能です。

安全第一: 隔離、OPSEC、そしてライブマルウェア

このセクションには、重大な安全性と運用セキュリティ (OPSEC) に関する警告が含まれています。この構成には、専門家による管理が必要な重大かつ重大なリスクが伴います。

4.1 脅威：これはシミュレーションではない

はっきり言っておかなければなりません: Ludus XZbot ラボ ガイドとそれに関連する Ansible ロールは、実際の機能的な CVE-2024-3094 バックドアをインストールします。これは無害なシミュレートされたコードではありません。ラボ独自のドキュメントには、「危険: このロールにはマルウェアが含まれています (意図的に)」と記載されています。

これは「パッシブ バックドア」(攻撃者が能動的に起動する必要がある) と説明されていますが、インターネット接続が開かれた状態でこのコードを実行する仮想マシンは壊滅的なリスクを伴います。未知の攻撃者によってスキャンされ、悪用されたり、他のネットワークを攻撃するための拠点として利用されたりする可能性があります。

4.2 矛盾: 分離 vs. クラウド接続

このアーキテクチャは、直接的かつ重大な運用上の競合を生み出します。

1. 要件 1 (安全性):侵害や侵入を防ぐために、マルウェア ラボはパブリック インターネットから分離されている必要があります。
2. 要件 2 (関数): Elastic Agent には、登録とデータ ストリーミングのために Elastic Cloud Hosted / Elastic Serverless エンドポイントに到達するためのアウトバウンド インターネット接続が必要です。

初心者のユーザーは、感染したラボを世界に公開するか、セキュリティ テレメトリを収集できないほど完全に隔離するかのいずれかの方法で、ここで失敗します。

4.3 解決策: Ludusテストモードによるピンホール出力

この競合は、ネットワーク出力を細かく制御できる Ludus の組み込み「テスト」モードを使用して解決されます。この機能は、エージェント制御、テレメトリ、およびログ出力を可能にするピンホール出力に使用されます。

# 1. Start the isolated testing session
ludus testing start # Note external DNS resolvers may also need to be added # ludus testing allow -i 1.1.1.1,8.8.8.8

# 2. Allow Elastic Fleet Server (Control Plane)
# Replace <id> with your specific deployment ID # Note the endpoint will differ based on the cloud providers
ludus testing allow -d <your-deployment-id>.fleet.us-central1.gcp.cloud.es.io

# 3. Allow Elasticsearch Ingest (Data Plane) # Note the endpoint will differ based on the cloud providers
ludus testing allow -d <your-deployment-id>.es.us-central1.gcp.cloud.es.io

この構成は、エキスパート レベルのソリューションを提供します。マルウェアは安全に封じ込められ、Elastic Agent には、ポリシーの更新 ( fleetエンドポイントとの通信経由) とデータの取り込み ( ESエンドポイントとの通信経由) に必要な最小限の接続のみが許可されます。

4.4 テストモードでの範囲へのアクセス（WireGuard）

テスト モードがアクティブになると、標準ルーティングは失敗します。ルータがトラフィックをドロップするため、ローカル LAN から Kali VM に SSH で接続することはできません。Ludus は、WireGuard を使用して帯域外管理チャネルを提供します。

Ludus は、ルータ VM (198.51.100.1) 上に WireGuard インターフェイス (wg0) を設定し、静的クライアント IP (例: 198.51.100.2) を割り当てます。

• 永続的な許可ルール:ルーターのファイアウォール構成には、LUDUS_DEFAULTS チェーン内の特定のルールが含まれています。これらのルールは、WireGuard サブネット (198.51.100.0/24) から発信されたトラフィック、または WireGuard サブネットを宛先とするトラフィックを明示的に受け入れます。
• 優先度:これらのルールは LUDUS_DEFAULTS チェーンに存在するため、テスト モードによって適用された DROP ルールをオーバーライドします。

接続方法:

1. 設定を生成します: ludus user wireguard > ludus.conf
2. これをローカルの WireGuard クライアントにインポートし、トンネルをアクティブ化します。
3. トンネル経由で VM のプライベート IP (例: 10.10.10.11) に直接接続します。

フェーズ2: 攻撃の実行

高精度で完全に計測可能な範囲が展開されると、「レッド チーム」フェーズを開始できます。これには、専用の攻撃者 VM (付属の Kali VM や remnux-analyzer VM など) にログインして攻撃を実行することが含まれます。このアクティビティにより、Elastic Defend がキャプチャする、豊富な悪意のあるテレメトリが生成されます。

この組み合わせ範囲により、アイデンティティベースの「Living Off-The-Land」（LotL）攻撃と脆弱性ベースのサプライチェーン侵入という 2 つの主要なマクロレベルの脅威ベクトルに対する防御をテストできます。

5.1 アクティブ ディレクトリ シミュレーション (GOAD)

• 初期アクセス（クレデンシャルスタッフィング）
  1. 攻撃者は外部境界をターゲットにします。侵害された資格情報のリストを使用して、Essos.local ドメインに対してパスワード スタッフィング攻撃を実行します。ユーザー khal.drogo の資格情報を正常に検証しました。
  2. サンプルツール: kerbrute または smartbrute
  3. 結果: 権限の低いドメイン ユーザーの有効な資格情報。
• 権限昇格（PrintNightmare）
  1. khal.drogo には制限付きの権利があります。CastelBlack サーバーに足場を築くには、PrintNightmare (CVE-2021-34527) を悪用します。Windows 印刷スプーラー サービスのこの脆弱性により、認証されたユーザーが悪意のあるプリンター ドライバーをインストールできるようになります。新しいローカル管理者ユーザーをボックスに追加するドライバーをアップロードします。
  2. サンプルツール: CVE-2021-34527.py エクスプロイトスクリプト
  3. 結果: CastelBlack でのローカル SYSTEM アクセス。
• 資格情報ダンプ（DCSyncの準備）
  1. ここで、CastelBlack で SYSTEM/Admin として実行し、キャッシュされた資格情報がないかマシンを検査します。Impacket の secretsdump を実行して、SAM データベースと LSASS メモリからハッシュを取得します。以前のサポート セッションからメモリに残っていた、組み込みの管理者アカウントの NTLM ハッシュを発見します。
  2. サンプルツール: impacket-secretsdump
  3. 結果: ドメイン管理者または高い権限を持つアカウントの NTLM ハッシュ。
• ケルベロースティング
  1. 有効なドメイン資格情報を使用して、内部ネットワークに移動します。環境内のサービス プリンシパル名 (SPN) に対して Kerberos サービス チケット (TGS) を要求します。MSSQLSvc アカウントをターゲットにします。暗号化されたチケットをオフラインで取得し、それを解読して、SQL サービス アカウントのプレーンテキスト パスワードを明らかにします。
  2. サンプルツール: Rubeus または GetUserSPNs.py
  3. 結果: MSSQL サービス アカウントのプレーンテキスト パスワード。
• MSSQL攻撃
  1. クラックされた SQL 資格情報を使用して、Braavos SQL Server に直接認証します。サービス アカウントには sysadmin 権限があるため、xp_cmdshell ストアド プロシージャを悪用します。この機能を使用すると、SQL クエリから直接 Windows コマンド シェルを起動できるため、データベース サーバー上でリモート コード実行 (RCE) が可能になります。
  2. サンプルツール: mssqlclient.py
  3. 結果: データベース サーバーで RCE が発生しました。
• 永続性（スケジュールされたタスク）
  1. SQL パスワードが変更されてもアクセスが失われないようにするには、永続性を確立します。侵害された SQL サーバー上に Windows のスケジュールされたタスクを作成します。このタスクは、SYSTEM として実行され、ビーコン バイナリを毎日実行するように構成されています。
  2. サンプルツール: schtasks.exe または PowerShell
  3. 結果: 長期にわたる持続。

5.2 マルウェアラボシミュレーション（XZbot）

• ステップ7：サプライチェーンのピボット（XZバックドア）
• 同時に、DMZ 内の Linux インフラストラクチャをターゲットにします。xz-backdoor-dect VM に事前に埋め込まれた XZ バックドア (CVE-2024-3094) をトリガーします。特定の暗号化キーを使用して SSH ハンドシェイクを操作することで、認証を完全にバイパスし、標準の SSH ログを残さずに root としてコマンドを実行できます。
• ツール: xzbot
• 結果: サプライ チェーンの侵害により Linux インフラストラクチャへのルート アクセスが取得されました。
• 攻撃者は、Ludus ラボで提供されている xzbot クライアントを使用します。
• 攻撃者の VM から次のコマンドが実行され、脆弱な Debian ホスト上のバックドアがトリガーされます:
  xzbot --ssh-addr '10.XXX:22' -cmd 'setsid sh -c "エコーテスト"' 2>&1
• このアクションにより、ターゲット上の sshd プロセスが異常にシェルを生成し、コマンドを root として実行し、実行の決定的な証拠が作成されます。

フェーズ3: Elastic Securityによる統合検出と調査

これは「ブルーチーム」の報酬です。フェーズ 2 で生成されたテレメトリとアラートは、統合された Elastic Security プラットフォーム内で分析できるようになりました。

6.1 「強力なSIEM」：集中化された可視性と事前構築された検出機能

Elastic SIEM の強みは、ログを受動的に収集する機能だけではありません。そのパワーは、Elastic Defend によって提供される詳細なコンテキストデータに対して実行されるアクティブな分析から生まれます。Defend の「完全なエンドポイントの可視性」は、基本的なログだけでなく、プロセスの作成、ファイルの変更、ネットワーク接続、レジストリの変更など、カーネル レベルのテレメトリも提供します。

この豊富なデータはすべて Elastic Common Schema (ECS) に正規化されており、Elastic の広範なライブラリ(構築済みで MITRE にマップされた約 1500 以上の検出ルール)にフィードされます。これらのルールは Elastic Security Labs チームによって調査、開発、保守されており、すぐに使用できる検出価値を提供します。

Ludus シリーズは、この価値を検証するのに最適なプラットフォームとして機能します。フェーズ 2 で実行される攻撃は理論的なものではなく、特定の予測されるアーティファクト (「決定的な証拠」) に直接マッピングされます。この例では、特定の動作を警告するために、事前に構築されたルールとカスタム ルールの組み合わせが意図的に使用されています。

注: Elastic 検出ルールはオープンかつ透過的です。( https://github.com/elastic/detection-rules ) でロジックを表示したり、貢献したり、問題を直接提起したりできます。

6.2 詳細: イベントアナライザーによるプロセスチェーンの追跡

2 つのラボ (GOAD と XZbot) は、Elastic の特殊な調査ツールを使用する絶好の機会を提供します。イベント アナライザーのユーザー インターフェイスは、JSON ログの複雑さを、セキュリティ アナリストの考え方 (プロセス チェーン) と一致する認知モデルに抽象化するように設計されています。インターフェースは、グラフィカル キャンバス、詳細パネル、タイムライン統合という 3 つの主要なインタラクション ゾーンで構成されています。

何を見ているのでしょうか?

グラフィカルキャンバス（プロセスツリー）

中心的なビューは、次の条件を満たす有向非巡回グラフです。

• ノード (キューブ):各キューブは個別のプロセス実行を表します。視覚化では、「アンカー」イベント (青いハローで強調表示) と周囲のコンテキストが区別されます。
• エッジ (線):線は親子関係を表します。方向性は暗黙的 (上から下または左から右) であり、実行の流れを示します。
• ビジュアルバッジ:ノードは静的なアイコンではなく、動的なインジケーターです。
  • アラート バッジ:特定のプロセスが検出ルール (「マルウェアが検出されました」など) をトリガーした場合、キューブに色付きのバッジが表示されます。これにより、アナリストは、チェーン内のどのステップが検出エンジンによってフラグ付けされたかを即座に特定できます。
  • ユーザー コンテキスト:視覚的なキューにより、プロセスがユーザー コンテキスト (ローカル ユーザーから SYSTEM など) を変更したかどうかが示され、権限の昇格が通知されます。

詳細パネル（フォレンジックメタデータ）

任意のノードをクリックすると、通常は右からスライドして詳細パネルが起動します。このパネルは、詳細なレベルで「何を見ることができるか」を示す主要な情報源です。検証に重要なフィールドを公開します。

• コマンドライン引数:これはおそらく最も価値のあるフォレンジック アーティファクトです。アナライザーは完全な文字列を表示し、フラグ、スクリプト、エンコードされたペイロードを公開します (例: powershell.exe -w hidden -enc Base64)。
• プロセスパスとハッシュ：完全なファイルパスは、なりすましの特定に役立ちます（例：svchost.exe が C:\Windows\System32 ではなく C:\Temp から実行されている場合）。脅威インテリジェンスとの相互参照のために、ファイルハッシュ（MD5、SHA-1、SHA-256）も表示されます。
• 署名者情報:バイナリのデジタル署名に関する情報は、信頼できる Microsoft バイナリと署名されていないマルウェアを区別するのに役立ちます。
• 関連イベント数:何千ものファイル変更でグラフが乱雑になる代わりに、ノードには概要統計 (例: 「15 件のファイル イベント」、「3 件のネットワーク接続」) が表示されます。通常、これらの統計をクリックすると、特定のアクションのリスト ビューまたはタイムラインが表示されます。

時間的次元（時間フィルター）

アナライザーの重要でありながら見落とされがちな側面は、時間の処理です。攻撃には長い「滞留時間」が伴う場合があります。親プロセスは数週間前に開始された可能性があります (正当なサービスなど)。一方、悪意のある子プロセスは今日生成された可能性があります。アナライザーには、アナリストがクエリ ウィンドウを拡張できるようにするタイム スライダーが含まれています。デフォルトでは、アラートの周囲の狭いウィンドウが調査されますが、これを拡張すると、グラフはウォームまたはコールド データ層に「戻って」、長時間実行されている親プロセスを見つけることができます。

これは次のように機能します。

イベント アナライザーの運用機能は、Elastic Common Schema (ECS)を活用します。異機種混在のセキュリティ環境では、ログは Windows エンドポイント、Linux サーバー、ネットワーク ファイアウォール、クラウド サービス プロバイダーなど、それぞれ独自の分類を持つさまざまなソースから生成されます。CrowdStrike エージェントはプロセス ID を TargetProcessId としてラベル付けする場合がありますが、Sysmon イベントは ProcessId を使用します。正規化を行わないと、これらのイベントを単一のチェーンに関連付けることはアルゴリズム的に不可能です。
ECS は、厳密なフィールド階層を適用することでこの問題を解決します。イベント アナライザーは、特定の高忠実度の ECS フィールドを利用して視覚的なグラフを構築します。

• プロセス.エンティティID :これはアナライザーのロジックの基礎となります。オペレーティング システムはプロセス ID (PID) をリサイクルします。PID 1234 は、 09 : 00の svchost.exe と14 : 00の malware.exe に属している可能性があります。長期の履歴分析に PID に依存すると、無関係なイベントがリンクされ、視覚的なグラフが破損する衝突が発生します。process.entity_id は、Elastic Agent (または ECS 準拠の beats) によって生成される一意の文字列であり、インデックス内で一意に保持されるため、PID の再利用に関係なく、グラフが個別の実行インスタンスを表すことが保証されます。
• プロセス.親.エンティティ_id :このフィールドは、ノード間の有向エッジを確立します。あるイベントの process.entity_id が別のイベントの process.parent.entity_id と一致するイベントを再帰的にクエリすることで、アナライザーは系統を再構築します。

イベントシーケンス:高速環境では、イベントの順序 (ファイルの変更はネットワーク接続の前に発生したか、後に発生したかなど) が重要になります。ECS タイムスタンプとシーケンス番号により、アナライザーはビジュアル ノードの詳細内でイベントを時系列に並べることができます。

6.3 詳細: セッションビューアによるユーザーアクティビティの再構築

XZbot (Linux) 攻撃の場合、セッション ビューアーが優れたツールです。これは、「Linux インフラストラクチャ上のセッション アクティビティの監視と調査」用に特別に設計されています。

XZBackdoor による潜在的な実行アラートが発生すると、アナリストは関連する sshd プロセスを調査します。セッション ビューアーは、「ターミナルにヒントを得た、非常に読みやすい形式」で表示されます。攻撃者のセッションを再構築し、sshd プロセスとその異常な子プロセス (sh) を表示します。

さらに、実行された正確なコマンド( sh -c setsid sh -c "usermod -aG sudo sysadmin_backup" ) が表示され、そのコマンドの出力も表示できます。これは決定的な「決定的証拠」であり、アナリストに平易な人間が読めるテキストで提示され、事実上、事後に攻撃者の TTY セッションを監視できるようになります。

何を見ているのでしょうか?

セッション ビューアーのユーザー インターフェイスは、抽象的なログ分析と Linux 管理者のネイティブ ターミナル エクスペリエンスの間のギャップを埋めることを明確に目的として設計されています。マルウェアのプロセス チェーンに重点を置くイベント アナライザーとは異なり、セッション ビューアーは、シェル セッションの線形ナラティブを再構築する、時間順のツリーベースの視覚化を提供します。

プロセスツリーとタイムライン

ビューの中心的なコンポーネントは、階層リストとして表示される有向非巡回グラフ (DAG)です。

• 垂直フロー:セッション ビューアーは、ターミナル履歴ファイルのフローを模倣しながら階層を維持しながらプロセスを垂直に配置します。子プロセスは親プロセスに対してインデントされます。これにより、アナリストは、ユーザーが直接実行したコマンド (curl など) と、スクリプト実行によって生成されたプロセス (setup.sh スクリプト内で実行される curl など) をすぐに区別できるようになります。
• 詳細モード:トグルを使用すると、アナリストはフィルターされたビュー (重要なユーザー アクティビティを表示) と「詳細モード」を切り替えることができます。このモードを有効にすると、シェルの起動スクリプト (.bashrc 実行)、シェル補完ヘルパー、組み込みコマンドによって発生したフォークなど、通常はノイズの多いイベントが表示されます。これは、プロファイル スクリプトに隠された永続化メカニズムを検出するために重要です。

視覚的なバッジとインジケーター

UI はバッジとアイコンの洗練されたシステムを採用しており、アナリストがすべてのノードをドリルダウンしなくても即座にコンテキストを提供します。これらの視覚的な手がかりは迅速なトリアージに不可欠です。

Elastic Session Viewerのビジュアルインジケーター

ターミナル出力ビュー

プロセス ノードのターミナル出力ボタンにマウスを移動すると、キャプチャされた出力のサイズを示すバッジが表示されます。このボタンをクリックすると、ターミナル出力ビューが開き、process.io.text データがレンダリングされます。これは Linux 調査における「決定的な証拠」となる機能です。

• リプレイ機能:アナリストはユーザーが見たものを正確に確認できます。攻撃者が cat /etc/passwd を実行した場合、プロセス ツリーに実行が表示され、ターミナル出力ビューには攻撃者に表示された passwd ファイルの内容が表示されます。
• 入力の再構築:ビューアは TTY I/O をキャプチャするため、コマンドの実行だけでなく、入力もキャプチャします。これにより、バックスペース、タイプミス、修正 (例: sdo [バックスペース] sudo と入力) が明らかになります。これらは、自動化されたスクリプトではなく、人間の敵対者の強力な行動指標です。

Elasticの優位性：AIを活用した自動ハンティング

フェーズ 3 で説明されているプロセスは、アナリスト主導の強力な調査を示しています。ただし、 Elastic Cloud Hosted (ECH)またはElastic Serverlessを使用する主な利点は、統合された Generative AI スタックへのプログラムによるアクセスです。このスタックは、プロセスを手動による相関関係からAI 駆動型の自動ハンティングへと高めます。

注: Elastic の AI 機能は、すぐに使用できる Elastic マネージド LLM または利用可能なコネクタのいずれかを使用して構成されたサードパーティの LLMで動作します。

7.1 アラートから攻撃へ: 攻撃検出による自動相関分析

GOAD + XZbot ラボは、上記の表に示すように、複数の個別のアラートを生成します。ジュニアアナリストは、潜在的な Kerberoasting、疑わしい証明書要求、潜在的な XZBackdoor などの一連のアラートに直面し、この複雑なクロスドメイン攻撃を手動で「つなぎ合わせる」必要があります。

これはAttack Discoveryによって解決される問題です。この GenAI 機能は、エンタープライズ レベルとサーバーレス レベルで利用可能で、 「大規模な脅威ハンティングを完全に自動化」します。このシステムは「AIがあらゆるアラートを分析して隠れた脅威を発見」し、Ludusラボからのさまざまな信号を自動的に相関させて、単一の高精度な「攻撃」調査を作成します。

フォレンジックアナリストにとって、Attack Discovery の主な価値は時間の短縮です。これは、第 1 層および第 2 層の分析を定義する「メンタル ステッチング」を自動化します。

「メンタルステッチング」を解体する

攻撃検出を使用しない調査の例を考えてみましょう。

1. トリガー: 「疑わしい PowerShell 実行」というアラートが表示されます。
2. クエリ:ホストのタイムラインにピボットします。
3. スキャン: 15 分前までスクロールします。「ファイルのダウンロード」イベントが表示されます。
4. 仮説: 「ユーザーが不正なファイルをダウンロードし、PowerShell を起動した可能性があります。」
5. 検証:ファイル名を確認します。invoice.js です。
6. 結論: 「マルウェアのダウンロードが確認されました。」

このプロセスには、アナリストのスキルと環境の習熟度に応じて、 10 ～ 30 分かかります。Attack Discovery は、このシーケンス全体を数秒で実行します。PowerShell アラートを確認し、関連するコンテキストでファイルのダウンロード イベントを確認し、 「ユーザーが、ダウンロードしたファイル 'invoice.js' から発生した可能性のある疑わしい PowerShell スクリプトを実行しました」という検出結果を表示します。

この機能には、データの永続性（結果は履歴追跡のために保存されます）とスケジュールとアクション（自動的に実行され、応答または後続の Elastic ワークフローをトリガーできます）が含まれており、SOC をリアクティブからプロアクティブの姿勢に移行します。

例

この例では、攻撃が発生するとアラートが表示され始めます。アラートを個別にトリアージするのではなく、Attack Discovery を活用してトリアージを行います。
平均トリアージ時間を数秒に短縮し、 2 攻撃を迅速に識別します。

7.2 AIアシスタントによるトリアージの高速化

Elastic Security Assistant は生成 AI を使用して、セキュリティの脅威の検出、修正、理解を支援します。Elastic Security 内で直接動作します。チャット インターフェースを介して対話し、アラートを調査したりコードを記述したりします。

この例では、Attack Discovery が相関する攻撃を特定すると、 AI アシスタントを使用して調査します。アシスタントは、次の 2 つの主要な機能を提供します。

1. 自然言語調査:アナリストは、「この攻撃を要約してください」、「このプロセスに対するMITRE戦術は何ですか？」などの平易な英語の質問をすることができます。「印刷スプーラーとは何ですか？」または「修復の提案をいくつか提供してください。」

2. エージェントクエリ検証ワークフロー:この高度な機能により、AI は「カスタマイズされた検証済みの ES|QL クエリを生成」できるようになります。アナリストは「XZbot アラートに関係するホストからのすべてのネットワーク接続を見つける」ように依頼すると、アシスタントがクエリを記述、検証、自己修正してから提示するため、高度な脅威ハンティングのスキル障壁が大幅に下がります。
   

仕組み

アシスタントは、Elastic Stack を任意の LLM (GPT-5、Claude、Gemini など) に接続します。Retrieval Augmented Generation (RAG) を使用して、環境から関連データ (ログ、アラート、内部ドキュメント) を取得します。プロンプトをモデルに送信する前に機密フィールド (PII またはホスト/IP メタデータ) を匿名化するように構成できるため、モデルが動作パターンを推論している間、データがプライベートのままであることが保証されます。

7.3 エラスティックワークフローによるインテリジェントオートメーション

上記の攻撃は、複雑で多段階のアラートを生成します。これらを手動で処理すると時間がかかります。Elastic は、オープンソースの AIOps およびアラート管理プラットフォームであるKeepを買収することでこの問題に対処しました。Elastic 9.3では、このテクノロジーはElastic Workflowsとしてテクニカル プレビューで Kibana に直接統合されています。

ワークフローとは何ですか?

Elastic Workflows は、Elasticsearch プラットフォームに組み込まれた自動化エンジンです。YAML でワークフロー（何がワークフローをトリガーするか、ワークフローが実行する手順、ワークフローが実行するアクション）を定義し、プラットフォームが実行を処理します。ワークフローでは、環境を照会したり、セキュリティ データを変換および強化したり、条件に基づいて分岐したり、外部 API を呼び出したり、すでに構成済みのコネクタを介して Slack、Jira、PagerDuty などのサービスと統合したりできます。ワークフローでは、AI エージェントを呼び出して複雑な調査を推論し、エージェントが発見した内容に基づいて対応アクションを続行することもできます。Elastic Workflows は、セキュリティ データがすでに存在する SIEM 内で、スクリプト化された自動化と AI 推論をネイティブに組み合わせます。

仕組み：「アラートアグリゲータ＆ワークフローエンジン」

ワークフローは、検出と修復の間のミドルウェア層となり、次の 3 つの主なメカニズムを通じて機能します。

• マルチソース取り込み:ワークフローは Elastic を超えて拡張されます。強化、分析、または初期トリアージのために追加データを取得します。
• ワークフロー アズ コード (YAML):ワークフローは YAML ファイルで定義されます。これにより、チームはインシデント対応手順をコードとしてバージョン管理できます。
• ワークフロー エンジン: Elastic (または外部ツール) でアラートがトリガーされると、ワークフロー エンジンは一連のステップを実行します。
  1. エンリッチメント: API (VirusTotal や Active Directory など) をクエリしてコンテキストを追加します。
  2. ロジック: if/else ステートメントを使用して重大度を決定します。
  3. アクション: Slack メッセージの送信、Jira チケットの作成、Elastic Defend 応答アクションのトリガー。

アラートとアクションのフローの例を考えてみましょう。

• トリガー:ワークフローを「悪意のある検出アラート」などの特定のルールに接続します。
• 手順:一連のアクションを定義します。
  1. トリアージ (エージェント):アラートを AI アシスタントに渡します。「以下のアラートに対して、どのように修復し、対応すればよいでしょうか？」と質問します。
  2. 強化: AI アシスタントの応答をアラートのメモとして添付します。
  3. 対応:アラート ノートへのリンクを含むケースを作成します。

例

この例では、ワークフロー (アラートの強化とケースの作成) をトリガーするアラートがあります。
また、ワークフロー UI から直接トリガーして、さまざまな手順を紹介します。

• アラートコンテキストは、セキュリティAIアシスタントへの入力として提供されます。
• 応答はセキュリティアラートにメモとして追加されます
• アラートのメタデータ (タイムスタンプ、重大度、ルール名、アラートの理由) を使用してケースが作成されます。
• ケースへのリンクがコメントとしてケースに追加されます。注: これは GIF では表示されません。

結論: 手動セットアップから継続的なエミュレーションへ

このブログでは、高度でスケーラブル、そして最も重要なことに、安全なシミュレーション範囲の完全な青写真を提供しました。

1. 私たちが構築したのは、 Ludus を使用して 1 つのコマンドで複雑なマルチラボ レンジ (GOAD + XZbot) を展開したことです。
2. インストルメント化: ludus_elastic_agent Ansible ロールを使用して、自動デプロイメントの一部として、範囲全体が Elastic Agent と Defend でシームレスにインストルメント化されました。
3. 保護された点:マルウェア分離とクラウド エージェント接続間の重大な競合は、Ludus のきめ細かな「OPSEC」ネットワーク制御を使用して解決されました。
4. 検証済み: Elastic の事前構築済みですぐに使用できる検出ルールを実際の既知の攻撃に対して検証することで、プラットフォームの強力な SIEM 機能が実証されました。
5. 調査内容:特殊な調査ツールであるイベント アナライザーとセッション ビューアーを使用して、Windows ホストと Linux ホストの両方で正確な攻撃パスを追跡しました。
6. 自動化: Elastic の GenAI スタックの「力の増幅」が実証され、Attack Discovery がさまざまなアラートを 1 つの攻撃に自動的に関連付け、AI Assistant が最終的な調査を加速しました。
7. 私たちは次のように対応しました。Elastic Workflows のパワーにより、複雑な対応アクションと修復フローの頭脳と自動化が提供されます。

このアーキテクチャは一度限りのビルドではありません。これは、継続的な検出エンジニアリング パイプラインの青写真です。これは、パープルチームがオンデマンドで防御を解体、再構築、再テストできるようにすることで「セキュリティ運用を近代化」し、脅威と同じ速さで検出体制を進化させることを保証します。

次のステップ: セキュリティチームを活性化する

このブログのアーキテクチャは単なる技術的な演習ではなく、継続的なセキュリティ検証の青写真です。この自動化範囲を Elastic の統合 SIEM および XDR プラットフォームと組み合わせることで、定期的なテストから常時対応の状態に移行できます。

ぜひご自身でトライアルを開始し、このガイドを活用して現実世界の脅威に対してプラットフォームをテストおよび評価し、セキュリティ チームが敵の一歩先を行くツールを活用できるようにしてください。

別の SIEM を使用していますか?

問題ない。Elastic Serverless を活用して既存の SIEM を拡張し、ネイティブ SIEM の基盤となるデータを使用しながら上記のすべての分析情報を得ることができます。今すぐ Elastic Serverless のデプロイメントを開始しましょう。Elastic AI SOC Engine (EASE)パッケージは、これらの AI 駆動型機能を提供するため、組織は完全な移行を行う前に、既存のツール上に強力な分析機能と AI レイヤーを迅速に追加できます。

付記

例の全範囲

注: Kali VM VLAN は、セグメント化されたネットワークまたはリモート攻撃者をシミュレートするために、GOAD および XZ バックドア ホストの外部にあります。Kali VM VLAN を 10/20 に変更して、「想定される侵害」または内部攻撃のシナリオをシミュレートできます。

global_role_vars:
  ludus_elastic_fleet_server: "https://<fleet_domain>:<fleet_port>" #443 by default for cloud   ## Note on prem fleet server defaults to 8220
  ludus_elastic_agent_version: "9.2.1"
ludus:
  - vm_name: "{{ range_id }}-GOAD-DC01"
    hostname: "{{ range_id }}-DC01"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 10
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:           # Any values in this array will be added to DNS for the range and return an A record for this VM's IP
      - sevenkingdoms.local
      - kingslanding.sevenkingdoms.local
      - kingslanding
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-DC02"
    hostname: "{{ range_id }}-DC02"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 11
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - winterfell.north.sevenkingdoms.local
      - north.sevenkingdoms.local
      - winterfell
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-DC03"
    hostname: "{{ range_id }}-DC03"
    template: win2016-server-x64-template
    vlan: 10
    ip_last_octet: 12
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - essos.local
      - meereen.essos.local
      - meereen
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-SRV02"
    hostname: "{{ range_id }}-SRV02"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 22
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - castelblack.north.sevenkingdoms.local
      - castelblack
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<goad_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-GOAD-SRV03"
    hostname: "{{ range_id }}-SRV03"
    template: win2019-server-x64-template
    vlan: 10
    ip_last_octet: 23
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true
    dns_rewrites:
      - braavos.essos.local
      - braavos
    roles:
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_elastic_enrollment_token: "<your_enrollment>"
  - vm_name: "{{ range_id }}-xz-backdoor-dect"
    hostname: "{{ range_id }}-xz-backdoor-dect"
    template: debian-12-x64-server-template
    vlan: 20
    ip_last_octet: 1
    ram_gb: 2
    cpus: 2
    linux:
      packages: # You can define packages to install on Linux hosts
        - ca-certificates
        - netcat-openbsd
        - net-tools
    roles:
      - badsectorlabs.ludus_xz_backdoor
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_xz_backdoor_install_xzbot: true
      ludus_xz_backdoor_install_backdoor: true
      ludus_elastic_enrollment_token: "<linux_policy_enrollment_token>"
  - vm_name: "{{ range_id }}-kali"
    hostname: "{{ range_id }}-kali"
    template: kali-x64-desktop-template
    vlan: 50
    ip_last_octet: 99
    ram_gb: 8
    cpus: 4
    linux: true
    testing:
      snapshot: false # Snapshot this VM going into testing, and revert it coming out of testing. Default: true
      block_internet: false # Allow internet access for Kali, default is true
    roles:
      - badsectorlabs.ludus_xz_backdoor
      - badsectorlabs.ludus_elastic_agent
    role_vars:
      ludus_xz_backdoor_install_xzbot: true
      ludus_elastic_enrollment_token: "<linux_policy_enrollment_token>"

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。