Splunk Attack Range v2.0のご紹介

Splunk脅威調査チーム(STRT)は、Splunk Attack Rangeプロジェクトで意欲的に開発を続けています。そしてこのたびついに、多数の新機能を追加したv2.0を正式にリリースしました。v1.0をリリースして以来、チームはAttack Rangeを、すぐに使えてより充実した機能を持つテストベッドへと進化させるべく懸命に取り組んでまいりました。このブログでは、これらの新機能とプロジェクトの今後の展望をご紹介します。

Splunk Attack Rangeの概要

Splunk Attack Rangeは、STRTが管理するオープンソースプロジェクトです。Attack Rangeを使用すれば、インストルメントされたクラウド/ローカル環境を構築し、攻撃をシミュレートして、データをSplunkインスタンスに送信できます。さらに、その環境を使って検出機能を開発し、効果を検証できます。v2.0では、Splunk SOARを使って対応をより簡単に検証できるようになりました。

v1.0のリリースノートをまだお読みでない場合は、こちらを参照してください。Attack Rangeを開発したきっかけと、Splunkで現在どのように活用されているかがわかります。Attack Rangeの今日の活躍ぶりを一部ご紹介します。

• SplunkのGitHubリポジトリで長期間にわたって最高評価(星)を獲得している



• Splunk .conf、RSA、Black Hat、DEF CON、Purple Team Summitなど、30以上の講演でメインに取り上げられている
• hakin9、KitPloit、tl;dr secなど、多くのメディアで特集されている
• Splunkの検出の90%以上でテストに使用されている

v2.0の注目点

すぐに使える新機能の開発に1年間取り組んだ結果、v2.0には数々の有意義な変更が加えられました。特に注目すべきが、開発プロセスでコミットにタグ付けし、対応するリリースパッケージを生成する、CIジョブの追加です。これは、Attack Rangeをより包括的な検出開発プラットフォームにするために追加された、以下を含む一連の主要機能で構成されます。

図：新機能が表示された新しいAttack Rangeの設定の最新イメージ

• 更新されたDockerインストール
• PurpleSharpの統合
• Nginx Plus 
• Linux Sysmon 
• Splunk SOARのデフォルトサポート
• BadBloodによるActive Directoryの事前入力
• Preludeのサポート(Calderaの代替)
• インストール済みですぐに使えるレッドチームツール

下の最新のアーキテクチャ図に、サポートされるコンポーネントの変更点の概要を示します。

以下では、これらの新機能について順に説明します。

Dockerインストール

Attack Rangeの内部は、ansible、terraform、bcryptをはじめとする90以上のサードパーティライブラリを使用するPythonスクリプトで構成されます。Pythonライブラリセットを隔離するには仮想環境を使用するのも良い方法ですが、最新のAttack Rangeでは、プラットフォームを使用するための別の方法を検討しました。

その結果、Attack Range v2.0では、Docker版のAttack Rangeを作成しました。Docker環境を使用することで、コンテナ化のメリットが得られるとともに、攻撃のシミュレーションと検出機能の開発に使用する複数のラボ環境のデプロイが容易になります。Dockerコンテナを使用するための詳しいガイドラインについては、こちらを参照してください。

PurpleSharpでのシミュレーション

PurpleSharpは、C#で書かれたオープンソースの攻撃シミュレーションツールで、Windows Active Directory環境で使われるさまざまな攻撃手法を実行できます。結果のテレメトリを活用すれば、検出の効果を測定して、改善につなげることができます。Attack Range v2.0は、PurpleSharpと統合し、複数のステップで構成される複雑な攻撃をコマンドラインから直接シミュレートできます。

次の例は、PurpleSharpを使って、範囲内のWindowsホストに対して単一のATT&CK技法を実行する方法を示します。

python attack_range.py simulate -e PurpleSharp -st T1003.001 -t ar-win-dc

Attack RangeでPurpleSharpの機能を使って、複数のステップで構成される複雑な攻撃に対応するためのJSONファイル形式のプレイブックを実行することもできます。 

python attack_range.py simulate -e PurpleSharp -sp AD_Discovery.json -t ar-win-dc

Nginx

STRTは、Log4jを独自に解析および調査する中で、Attack RangeでWebベースのログの収集と分析をサポートする必要があると実感しました。その結果、v2.0には、新しい設定スタンザを通じてSplunkのログ機能にすぐに使える設定済みのNginx Webプロキシを組み込む機能が追加されました。この新機能を使えば、独自のWebアプリケーションでNginxプロキシを経由するように設定して、Webベースの攻撃に対するセキュリティコンテンツを調査、作成、テストできます。

Linux Sysmonのサポート

Sysmonは、エンドポイントのアクティビティに関する幅広い情報を提供するツールで、検出機能の開発者やブルーチームの間でよく使われています。Sysinternalsの25周年記念では、Sysmon for Linuxが公開されました。これにより、Windows環境でしか利用できなかったSysinternalsの監視および検出機能をLinuxでも利用できるようになりました。

Cedric Hien氏がリリースしたSplunk Add-On (Splunkbaseからダウンロード可能)を使用すれば、Sysmonが生成するイベントをSplunkに取り込んで、Linuxエンドポイントに対する攻撃を調査できます。新しい設定スタンザを使用することで、Attack RangeでSysmon for Linuxの機能をテストできます。たとえば、Rod Sotoはブログで、Linuxホストへの攻撃でエクスプロイト後によく使われるツールを対象とした検出機能を開発したことを報告しています。

Splunk SOAR

Splunk SOARは、かなり前からAttack Rangeプロジェクトの一部になっています。前回のリリース以後、STRTはAttack Rangeに、独自のSplunk SOARインスタンスを使用する機能を追加しました。これにより、ユーザー環境で利用されているSplunk SOARインスタンスをAttack Rangeに接続して利用できます。その結果、ビルドのたびにSOARインスタンスをゼロから立ち上げる必要がなくなりました。

さらに、STRTは、SOAR用のデフォルトAppを再構成しました。現在は、AD LDAP Appがプリインストールされ、Attack Range内蔵のWindowsドメインコントローラーを使用するように事前設定されています。Splunk App、WinRM App、DNS App、MaxMind App、WhoIs RDAP Appも同様です。これらのAppはいずれも、Attack Range設定に新しいSOARインスタンスを追加したときにすぐに使えるように事前設定されています。

BadBloodの統合

最初のバージョンのAttack Rangeでは、プロビジョニングプロセスの一部としてWindows Active Directory環境を構築しました。しかし、ユーザー、コンピューター、サービスプリンシパル名などのディレクトリオブジェクトが事前入力されないクリーンインストールでは、パスワードスプレーやKerberoastingのようなActive Directory攻撃のシミュレーションと調査に利用できるオプションが制限されます。 

David Rowe氏が公開しているBadBloodは、Active Directoryの構造や多数のオブジェクトを入力するPowerShellスクリプトを備えた優れたツールです。このツールを使用すると、実行するたびに異なる結果を生成し、常に異なるドメイン、ユーザー、グループ、コンピューター、権限を入力できます。最新リリースのAttack Rangeでは、シンプルな設定スタンザでBadBloodを実行できます。これにより、Active Directoryに対する複雑な攻撃の検出方法を調査、開発、テストできます。

Preludeのサポート

Prelude Operatorは、パープルチームの間でよく使われる非常に便利なツールです。Attack Range v2.0では、Calderaに代わってPreludeが搭載されているため、Attack Range環境のシミュレーションや攻撃チェーンをわかりやすいUIから実行できます。Splunkサーバーと同じマシン上にリダイレクターを構築し、WindowsマシンやLinuxマシンにPneumaエージェントを展開する機能を追加しました。これにより、WindowsマシンやLinuxマシンはTCP 2323経由でリダイレクターに接続するようになります。次の図は、この機能のアーキテクチャを示します。

詳しくは、こちらのWikiページを参照してください。

レッドチームツール

Mimikatz、PowerSploit、UACMe、SharpGPOAbuseなど、Windowsベースの多数のレッドチームツールを自動的にダウンロードする新しい設定スタンザが追加されました。これにより、Attack Rangeで攻撃シナリオを実行して結果のログを分析できます。

ほかに追加を希望するツールがある場合は、こちらからリクエストをお送りください。

今後の展望 

STRTは、Attack Range v2.0のリリース準備とパッケージ化を進めながら、すでにAttack Range v3.0の構想も立てています。チームは、Splunkのお客様と幅広いコミュニティがより便利な検出機能を開発できるよう、Attack Rangeの進化と改善に日々取り組んでいます。その目標を念頭に、v3.0ではより幅広いユーザーがAttack Rangeを有効活用できるようにすることに力を入れ、すでにいくつかの案を検討しています。

ユーザーやSplunkのお客様からよく寄せられるリクエストの1つが、検出をテストするために、EDR (Aurora、Sysmon)、ネットワーク収集ツール(Zeek、Suricata、Bro)、その他のアプリケーション(AD、ツール)のログを追加/変更する機能です。現状では、そのためにさまざまなコードを変更する必要があり(こちらやこちらなど)、たいていの場合、大きな負担を強いられます。v3.0では、収集エージェントを追加し、それらを含むイメージを事前構築して、どのタイプのプロバイダー(実行環境)でも構築時間を短縮したいと考えています。

収集ポイントを追加したら、次に考えられるのが、独自のゴールデンイメージを使用する機能です。実際、ユーザーや大規模企業のお客様からリクエストが寄せられています。この機能があれば、特定の攻撃で具体的にどのログが有用であるかを簡単に検証したり、本番環境のデータを使用して検出を反復的に実行したりできます。この機能もAttack Rangeの今後のリリースに搭載する計画です。

最後に、STRTは1年ほど前、Attack Rangeを拡張するために、Azureやアマゾン ウェブ サービス(AWS)などのクラウドプロバイダーのサポートに力を入れることを決めました。VirtualBoxの使用をやめて、Attack Rangeプロジェクトをフォークし、ローカル実行環境を継続するAttack Range Localを立ち上げました。その時点では、このフォークに機能をバックポートせず、このフォークは将来的に廃止しようと考えていました。しかし、ローカルで検出機能の開発を続けたいという要望を数多く受け取ったため、次期バージョンではDockerやESXIをプロバイダーとするデプロイ機能を搭載することにしました。チームは、これがAttack Range Localの代わりとなり、Attack Range Localはいずれ廃止できることを期待しています。

同様に、Attack Range Cloudプロジェクトもいずれ廃止し、そのすべての機能をv3.0の一部としてSplunk Attack Rangeに移植する予定です。今後の展望は以上です。これからの展開にぜひご期待ください。

追記：STRTはMacOSエンドポイントの追加を忘れたわけではありません。ただ、思わぬ壁にぶつかっているだけです。詳しくは、こちらの個人ブログをご覧ください。これは決して「できない」のではなく、「まだできていない」だけです！ 

このプロジェクトを活用し、GitHubで星の評価をくださったすべての皆様に心より感謝申し上げます。STRTはこれからも、Splunkのお客様および幅広い業界とコミュニティの皆様に価値をお届けできるよう、このプロジェクトを守り、改善を続けていきたいと思います。

このブログは、Mauricio Velazco、Lou Stella、Jose Hernandezによって共同執筆されました。

このブログはこちらの英語ブログの翻訳、横田 聡によるレビューです。