エンジニアリング

教師ありおよび教師なしの機械学習を組み合わせてDGAを検知

Editor’s Note — December 21, 2020: This blog has been updated since its original release to include a use case that applies this workflow to the SUNBURST attack.

当社で初の教師あり機械学習とセキュリティの統合についてお知らせできることを、うれしく思います。Elasticは本日、ネットワークデータ内でのドメイン生成アルゴリズム(DGA)のアクティビティを検知する、教師あり機械学習ソリューションパッケージをリリースします。

今回のリリースには、完全トレーニング済みの検知モデルに加えて、インジェストパイプラインの構成、異常検知ジョブ、検知ルールが含まれており、設定からDGA検知までのプロセスをスムーズかつ簡単に進めていくことができます。Elasticの検知ルールリポジトリにアクセスし、教師あり機械学習を使用してネットワーク内でのDGAアクティビティの検知を開始する方法をご確認ください。また、今すぐElasticセキュリティの無料トライアルを開始していただくこともできます。 

DGA:その詳細

ドメイン生成アルゴリズム(DGA)は、多くのマルウェア作成者が、クライアントマシンの防御対策を回避するマルウェアを作成するために使用するテクニックです。このテクニックの目的は、ランダムに生成される何十万ものドメイン名を使用して、感染したクライアントマシンとコマンド&コントロール(C & CまたはC2)サーバーの間の通信を隠ぺいすることです。これは最終的にはC & CサーバーのIPアドレスに解決されます。

DGA攻撃では一体何が起きているのでしょうか。それをより簡単に理解するために、戦場の兵士を想像してみましょう。多くの兵士と同様、あなたも無線電波を使用して通信する通信装置を持っています。敵はあなたの無線電波を妨害することで、その通信を邪魔しようとするでしょう。これに対抗するための1つの方法として考えられるのは、周波数ホッピングです。つまり、送信中にきわめてすばやく周波数を変える無線システムを使用するのです。周波数を変えることで、敵にとってはランダムで予測不可能なものとなり、電波を妨害することが難しくなります。

DGAは、マルウェアにとってそのような周波数ホッピングの通信チャネルとなります。頻繁にドメインが変更されるため、DNSドメイン名ブロックという手段では、マルウェアによるC2との通信チャネルを遮断することは不可能になります。ランダムに生成されるDNS名が多すぎるので、それらを試行し、特定してブロックすることは困難です。 

このテクニックの使用は、「Conficker」ワームが、ランダムに生成されるきわめて多くのドメイン名を通信に使い始めた2009年から急速に増えました。セキュリティコンソーシアムの研究者が、このワームの通信用のDNSドメインをシャットダウンしてワームのC2チャネルを妨害しましたが、このワームの作成者はこれを受けて上記のような方法を開発しました。また、2017年にWannaCryランサムウェアが世界中で猛威を振るった際には、DNS緩和も実行されました。

紛れ込ませる

木を隠す最高の場所は森です。マルウェア操作者はかなり前から、検知されないようにする優れた方法の1つは通常のWebトラフィックに紛れ込ませることだと分かっていました。ランダムに生成されたドメイン名によるHTTPリクエストは、ネットワークセキュリティの監視と検知にとって難しい問題です。大量のHTTPトラフィックが行き交う現代のネットワークでは、手動での確認は不可能です。マルウェアやボットに不自然なユーザーエージェント文字列がある場合は、検索ルールによってアラートを発することができます。しかし、マルウェア作成者は簡単に、Webブラウザーとまったく見分けがつかないユーザーエージェント文字列を使用することができるのです。

モバイルやIoTの台頭に伴い、ユーザーエージェント文字列が非常に多くなり、疑わしいアクティビティを手動で確認することも不可能になっています。Webプロキシは長い間、疑わしいことが分かっているURLを探すために分類を使用していますが、DGAドメインはボリュームが多く、また存続時間も短いことから、多くの場合、分類されていません。脅威インテリジェンスフィードは、既知のマルウェアファミリーやキャンペーンと関連付けられているIPアドレスおよびHTTPリクエストを特定できますが、これらはマルウェア操作者によって簡単に変更できるため、多くの場合、そのようなリストを検索に使用する必要が生じたきには、その情報はすでに古いものとなっています。

多くの組織で収集されているネットワークトラフィックは膨大な量にのぼり、DGAによって生成されるドメインはランダムなため、ルールベースのテクニックでそのアクティビティを検知することは非常に難しい課題となります。この対処に最適なのが、Elasticの教師あり機械学習モデルです。ElasticのDGA検知MLは推定を使用して、 ElasticsearchクラスターにインジェストされているPacketbeat DNSデータを検査し、悪意があると思われるドメインを自動的に判断します。次のセクションの手順に従うことで、これを開始できます。 

開始する

Elasticは、セキュリティアプリ内でDGAの検知を開始できるようにするために、機械学習モデルをElastic Stackにインポートする機能セットを、一般公開しているルールリポジトリにリリースしました。このリポジトリは、脅威検知に関してコラボレーションできる場所をコミュニティに提供するだけでなく、ルールをテストおよび検証するために必要なツールを共有する場所としても機能します。

このイニシアティブの詳細については、以前のブログおよびウェビナーをご覧ください。Elastic Cloudのサブスクリプションをまだご利用でない場合は、14日間無料のElastic Cloudトライアルを利用して、DGAアクティビティを検知する教師あり機械学習ソリューションパッケージの試用を開始できます。

このルールツールキットにはCLI(コマンドラインインターフェース)が含まれており、ルールをテストするだけでなく、スタックの操作も可能です。たとえば、ElasticはKibana APIとやりとりできるさまざまなPythonライブラリをリリースしています。これは、モデルの依存関係のインポートプロセスをより簡単にして、ルールを運用できるようにするために重要です。DNSデータのエンリッチ化とDGAアクティビティに関するアラートの受領を開始するには、次の3つのステップを実行します。

ステップ1:モデルのインポート

まずは、DGAモデル、Painlessスクリプト、インジェストプロセッサーをスタックにインポートします。現在、DGAモデル、および異常検知(その他の機能も今後追加予定)のための教師なしモデルは、 githubリリースを使用してdetection-rulesリポジトリから入手することができます。アップロードするには次のCLIコマンドを実行します。

python -m detection_rules es <args_or_config> experimental setup-dga-model -t <release-tag>

アップロードした後は、Packetbeatの設定を更新する必要があります。モデルがPacketbeat DNSイベントのDGAスコアを判断できるようにエンリッチ化するためです。これは、Elasticsearch出力構成に設定を追加するだけなので簡単です。

output.elasticsearch:
hosts: ["your-hostname:your-port"]
pipeline: dns_enrich_pipeline

こうすることで、教師ありモデルはPacketbeat DNSイベントを分析し、それらをエンリッチ化します。これには次のECSフィールドが含まれます。

dns.question.name
dns.question.registered_domain

これにより、モデルは処理済みのDNSイベントに次のフィールドを追加します。

フィールド名 説明
ml_is_dga.malicious_prediction 値「1」は、DNSドメインが悪意のあるDGAアクティビティの結果として予測されていることを示します。値「0」は、DNSドメインが良性であると予測されていることを示します。 
ml_is_dga.malicious_probability DNSドメインが悪意のあるDGAアクティビティの結果であることが、0から1の間の確率スコアで示されます。

以下のスクリーンショットは、エンリッチ化されたDNSデータの例を示しています。

注:詳細情報については、detection-rulesのreadmeをご確認ください。

DGAルールについて

では、DGAアクティビティを検知しアラートを通知する条件検索ルールを見てみましょう。パッケージでは2つの検索ルールが提供されます。どちらもElasticセキュリティアプリの検知エンジンで有効化および実行できます。

  1. Machine Learning Detected a DNS Request Predicted to be a DGA Domain(DGAドメインであると予測されるDNSリクエストを機械学習で検知)
  2. Machine Learning Detected a DNS Request With a High DGA Probability Score(DGAである確率が高スコアとなるDNSリクエストを機械学習で検知)

1つ目のルールは、DGA予測値が1となる任意のDNSイベントに一致し、そのDNSドメイン名がおそらくドメイン生成アルゴリズムの結果であり、疑わしいものであることが示されます。こちらにあるこのルールは、単に次の条件に合致するかどうかを見るものです。

event.category:network and network.protocol:dns and ml_is_dga.malicious_prediction:1

2つ目のルールは、DGA予測値が0.98を超える任意のDNSイベントに一致し、そのDNSドメイン名がおそらくドメイン生成アルゴリズムの結果であり、疑わしいものであることが示されます。こちらにあるこのルールは、単に次の条件に合致するかどうかを見るものです。

event.category:network and network.protocol:dns and ml_is_dga.malicious_probability > 0.98

Elastic検知エンジンのすべてのルールと同様、これらは地域の条件に合うように分岐およびカスタマイズすることが可能です。2つ目のルールの確率スコアは、DNSイベントに関して別の確率スコアのほうが適切に機能することが分かった場合には、上下に調節することができます。どちらのルールでも、アラートキューの中でDGA検知の優先度を上げたい場合は、そのリスクスコアを高くすることが可能です。また、擬似ランダムドメイン名を使用する場合があるコンテンツ配信ネットワーク(CDN)などの誤検知を無視するために、例外をルールに追加することができます。

今後Elasticが検討する可能性があるのは、イベントクエリ言語(EQL)を使用し、多変量の相関付けを利用して、異常または検索ベースのアラートのクラスターを見つけることです。たとえば、DGAの可能性があるアクティビティに関係しているホストからアラートのクラスターが見つかった場合、注意が必要な重大なマルウェアを検知したという信憑性がさらに高まることになります。

そのようなクラスターは、DGAアラートとその他の異常検知アラート(まれなプロセス、ネットワークプロセス、ドメイン、またはURLなど)の組み合わせで構成される可能性があります。これらの追加の異常検知は、Elasticセキュリティアプリに含まれている機械学習パッケージのライブラリで提供されています。

ステップ2:ルールのインポート

DGAパッケージのルールは、detection-rules CLI(.toml形式)で利用できるKibanaのupload-rule機能を使用してインポートできます。detection-rulesリポジトリリリースで提供されるルールは.toml形式のため、単に次のコマンドを実行してリポジトリからルールをアップロードします。

python -m detection_rules kibana upload-rule -h
Kibana client:
Options:
--space TEXT Kibana space
-kp, --kibana-password TEXT
-ku, --kibana-user TEXT
--cloud-id TEXT
-k, --kibana-url TEXT
Usage: detection_rules kibana upload-rule [OPTIONS] TOML_FILES...
Upload a list of rule .toml files to Kibana.
Options:
-h, --help Show this message and exit.
-h, --help Show this message and exit.

ステップ3:ルールの有効化、あとは成果を得るだけ

これで、トレーニング済みの教師あり機械学習モデルがスタックにインポートされ、DNSイベントがエンリッチ化され、ルールを自由に調整できるようになりました。あとは、ルールを有効化してアラートを待つだけです。 

検知エンジンでルールを見ると、以下のように有効化されていることを確認できます。


あとはアラートを待つだけです。アラートが生成されたら、タイムライン機能を使用してDNSイベントを調査することで、自分で調査を開始できます。

ただし、完璧な機械学習モデルはありません。良性のドメインが誤検知されることもあります。次のセクションでは、今回のリリースに同梱されている事前構成済みの異常検知ジョブとそれに付随するルールを活用して、誤検出を調整する方法を見ていきます。

誤検知があるなら異常検知を調整

どの検知テクニックでも、必ず誤検知は発生します。その環境で実際には通常のものであっても、CDNトラフィックやカスタムドメインに悪意があるように見える場合があります。DGA検知が各ユーザーの環境に確実に適応できるようにするために、Elasticはexperimental-high-sum-dga-probabilityという名前の事前構築済みの異常検知ジョブを作成しました。このMLジョブは、有効化すると、教師ありDGAモデル(完全なML)によって提示されたDGAスコアを検査し、異常に高いスコアを示す特定のソースIPアドレスの異常パターンを見つけ出します。そのようなイベントには異常スコアが割り当てられます。

異常検知ジョブの利点を最大化するために、Elasticはそれを補完的なルールであるPotential DGA Activity(潜在的なDGAアクティビティ)とともにリリースしています。これにより、セキュリティアプリの検知ページに異常ベースのアラートが作成されます。

事前構築済みの異常検知ジョブおよび補完ルールは両方とも、Elasticの検知ルールリポジトリリリースで利用できます。 

環境に最適な構成を選択する方法

すべては教師ありDGAモデルから始まります。このモデルにより、Packetbeatを通じてインジェストされるすべてのDNSリクエストが分析され、そのリクエストに関与するドメインの悪意の可能性を示す確率スコアが割り当てられます。「開始する」のセクションで説明した条件論理ルールを使用して、教師ありモデルの出力をセキュリティアプリで直接使用することができます。または、それらをインポートして、事前構築済みの異常検知ジョブおよびルールを有効化し、環境の細かい側面に合わせて検出をさらにカスタマイズすることがきます。 

環境に最適な構成をどのようにして選べばよいのでしょうか?まずはシンプルに始めましょう。「開始する」のセクションで説明した、条件検索ルールを有効化します。これらのルールは教師ありモデルの出力に直接影響を与えるとともに、これらのルールによって環境でどれだけのバックグラウンドノイズ、つまり誤検知があるのかということをすぐに把握できます。教師ありモデルからの出力に直接適用される条件検索ルールによってあまりにも多くのアラートが生成される場合は、異常検知ジョブのインポートおよび有効化から利点を得られる可能性があります。 

特に、異常検知ジョブの結果に適用されるML検知ルールにより、個々のDGAスコアに関して1つずつアラートを生成するのではなく、DGAアクティビティが大量にあるソースを見つけるのに役立つ場合があります。MLモジュールを実行していない場合は、無料トライアルを開始するか、 Elastic Cloudでお試しください。

以下のスクリーンショットは、今回のリリースで提供される異常検知モデルおよび関連ルールの例です。

教師なしMLジョブのexperimental-high-sum-dga-probabilityによる出力

教師なしMLジョブからの出力に適用されるMLルール、Potential DGA Activityによる出力

検索ルールMachine Learning Detected a DNS Request With a High DGA Probability Scoreによって作成されたアラート

検索ルールMachine Learning Detected a DNS Request Predicted to be a DGA Domainによって作成されたアラート

ケーススタディ:SUNBURST攻撃での実際のDGAアクティビティを検知

この実験的なDGAワークフローを、最近発生したSUNBURSTキャンペーンに適用してみましょう。 

この攻撃に関する経緯を要約すると、SolarWindsが12月13日に、Orionネットワーク管理プラットフォームがサプライチェーン攻撃を受けたことに関するセキュリティアドバイザリをリリースしました。このブログの執筆時には、この攻撃は2020年3月から6月の間にリリースされたOrionバージョンに影響を与えます。同様に、FireEyeは12月13日に、 Orionソフトウェアのいくつかのバージョンに影響を与える.SolarWindsサプライチェーンへの侵害に関与するグローバルキャンペーンについての情報をリリースしました。

私たちは以前に、このSolarWindsの事例(一般的にSUNBURSTと呼ばれています)に関するブログ記事をElasticユーザー向けにリリースしました。この記事では、SolarWindsが公開した内容に記載されている攻撃を検知できるように、Elastic EndgameおよびElastic Endpoint Securityの両方で使用されているElasticセキュリティのマルウェア防御テクノロジーがアップデートされたことを主に取り上げています。

SUNBURSTは、マルウェアを繰り返しSolarWindsのOrion製品に挿入し、自動更新メカニズムを使用してそのマルウェアを分散させる高度なソフトウェアサプライチェーン攻撃です。このブログの執筆時には、そのインシデントのサイズ、範囲、規模はまだ評価中です。 

既存のElasticセキュリティによる検知

SUNBURSTマルウェアによって使用される1722のDGA生成ドメイン名のセットがセキュリティ研究家によって共有されました。Elasticセキュリティの機械学習ベースによる既存の検知ルールの1つであるDNS Tunneling(DNSトンネリング)は、このサンプルのDNS名に関して異常ベースの2つのアラートを生成します。DNS Tunnelingと同様、SUNBURST名のサンプルの親ドメインに対する子ドメインの比率はかなり高くなっています。このルールに関連付けられているこのMLジョブは、Packetbeatデータを分析するようにコーディングされていますが、その他のDNSイベントをElastic Common Schema(ECS)形式でインジェストするように複製および修正することができます。以下がDNS TunnelingのMLジョブです。

このMLジョブには、DNS Tunnelingという名前の検知ルールが関連付けられています。

適切なインシデントトリアージの実行や対応作業のキューに入れられるようにするために、下記に示されているこれらのElasticセキュリティルール、異常検知は、検知アラートおよびオプションの通知へと変換することができます。下記は、SUNBURSTの異常検知がElastic Machine Learningアプリでどのように表示されるかを示しています。

これは便利な検知機能ですが、このジョブで常にDGAアクティビティを検知できるとは限りません。DGA検知を強化するために、Elasticは実験的なDGA検知ワークフローを提供しています。

実験的なDGAワークフローの使用

実験的なDGA ML検知ワークフローで、このアクティビティのほとんどを検知できることが分かりました。これらのSUNBURST DGAドメインは、この記事で説明した(上記、このモデルとそのルールのダウンロードおよび実行方法の詳細を参照)教師ありDGA検知モデルを通じて実行されました。このモデルは、サンプル内の名前のうち82%をDGAとしてタグ付けしました。これは、サンプルセットに関して1420件のアラートが生成されることになります。下記は、教師ありモデルによってDGAアクティビティとしてタグ付けされたSUNBURST DNS名のスクリーンショットです。

これらのイベントは、検知ルールのMachine Learning Detected a DNS Request Predicted to be a DGA Domainを使用することで、検知アラートへと変換することができます。また、このルールのコピーを作成し、SUNBURSTなどの特定のマルウェアインスタンスによって使用される観察された親ドメインに一致するよう修正することもできます。以下のように、ルールのクエリにテストを追加することで、このSUNBURST DGAイベントのセットを一致させることができます。

network.protocol:dns and ml_is_dga.malicious_prediction: 1 and dns.question.registered_domain: "avsvmcloud.com"

その後、このルールに重大な深刻度レベルと99の高いリスクスコアを適用することで、それらのイベントをアラートおよび分析作業のキューで優先的に扱われるようにすることができます。以下のスクリーンショットは、SUNBURST DGAアクティビティの検知に特に注意が向けられるように修正されたルールによって生成されたアラートを示しています。

Elasticはこのルール、Machine Learning Detected DGA activity using a known SUNBURST DNS domain(既知のSUNBURST DNSドメインを使用して機械学習でDGAアクティビティを検知)をパッケージに含めました。実際の感染条件では、DGAを使用する高頻度のマルウェアインスタンスの集団によって、デフォルトで100に設定されているmax_signals回路ブレーカーをトリップさせるのに十分なアラートが引き起こされる可能性あります。その場合、検索で最初に一致したイベントに応じて、一部のマルウェアインスタンスに対してアラートが発せられ、その他のインスタンスに対してはアラートが発せられない可能性があります。 

DGAアクティビティに関わっているより多くの感染ホストを特定できるようにするために、ElasticはDGA検索ルールのmax_signalsの値を10,000に増やしています。注:この設定はルールエディターでは編集できません。外部のルールファイルで修正してからインポートする必要があります。この設定はエディターでルールファイルを参照することで確認できます。

DGAアクティビティが非常に頻繁にあり、アラートが大量に発生する場合は、下記のようなテーブルでホスト名またはソースIPをカウントして、DGAアラートまたはイベントを集計し、ふるいにかけることもできます。


また、Packetbeat DGAイベントのサンプルダッシュボード(ビジュアライゼーションと集計を含む)も 含めました。これには、source.ipによって集計されたこのデータテーブルのビジュアライゼーションが含まれています。または、DNSイベントにフィールドが含まれている場合はhost.nameで集計することもできます。このファイルの名前はdga-dashboard.ndjsonであり、 [Stack Management](スタック管理)を選択すると表示される[Saved Objects](保存されたオブジェクト)ページで[Import](インポート)を選択して、Kibanaにインポートすることができます。

下記のスクリーンショットは、packetbeat-*インデックスでレンダリングされたDGAイベントを示すダッシュボードです。

サポート

サポートを活用しましょう。このプロセスで何らかの問題に直面したり、または単に脅威検知や機械学習に関するElasticの考え方を詳しく知りたい場合には、ElasticのコミュニティSlackチャンネルまたはディスカッションフォーラムをご利用いただくか、あるいは検知に関するオープンリポジトリで私たちとともにじっくり取り組んでいただくこともできます。この記事がご参考になれば幸いです。