プロアクティブ検出コンテンツ：CVE-2019-0708 対 ATT&CK、Sigma、Elastic、ArcSight
セキュリティコミュニティの大多数が、CVE-2019-0708の脆弱性は対処すべき重要な優先事項であると合意したと思います。「パッチを当てろ！」と言うのがまず最初に思い浮かぶことのように感じますが、WannaCryやNotPetyaの記憶がまだ鮮明に残っています。パッチの適用が必要なスピードと規模で行われないことは分かっています。それゆえ、再び検出ルールを構築しているのです！
小さくも重要な詳細：CVE-2019-0708の脆弱性はリモートデスクトップサービス（RDS）に関連しており、実際のMicrosoftによるWindows上のRDPの実装に関係しています。RDPプロトコル自体は問題ありません。このステートメントは、WannaCryの発生時に見られたような誇大宣伝を避けるためにここに必要だと感じています。
「BlueKeep」ハッシュタグは、最初にKevin Beaumountによって使用されました。私はこれを選んだ理由は2つあります：GoTの引用と、ツイッターで関連投稿を見つけるため、というのもCVEには簡単にハッシュタグを付けられないからです（ダッシュを除去しない限り）。BlueKeepは単にツイッターオペレーションを簡単にするためのものです;-)
https://twitter.com/GossiTheDog/status/1128348383704485895
防御側に有利な状況を作る。
検出理論を確立するために、2つの脅威モデルを考慮する必要があります：
- WannaCryのシナリオに似たワーム脅威。
- APTアクター、より洗練されたキャンペーンの一部として脆弱性を利用する、EternalBlueやSMBがNotPetya災害の一部であったように。
リスクのある資産を特定するために、Dragosが提供する以下の表を参照します：
source: https://dragos.com/blog/industry-news/ics-impact-from-microsoft-rdp-vulnerability/
CVE-2019-0708は、WannaCryのような大規模な初期アクセスに使用される可能性があるか？Shodanのデータを簡単に見ると、ポート3389が公開され、潜在的に脆弱なWindowsのバージョンを実行している多数のマシンがインターネット上にあることがわかります：
https://www.shodan.io/search?query=port:3389+os:”Windows+7+or+8″
https://www.shodan.io/search?query=port:3389+2003
https://www.shodan.io/search?query=port:3389+2008
https://www.shodan.io/search?query=port:3389+os:”Windows+XP”合計で、インターネットからアクセス可能なRDPを持つ2.375百万台のホストが見られますが、まだ結論を出さないでください！
https://www.shodan.io/search?query=Remote+Desktop+Protocol
Dan Tentlerによる2017年4月23日のツイート「すべてのホストがWindowsではなく、すべてのポートがsmbではない」を引用します。これを現在に適用すると「これらの230万ホストがすべてWindowsではなく、すべてのポートがCVE-2019-0708に脆弱なサービスではない」となります。WannaCryのタイムラインと比較すると、MS-17010が既に公開されており、EternalBlueはまだ出ていない段階で、次のDoublePulsarをスキャンできない状況です。そしてPoCが存在し、バックドアがないかスキャンされるまで、状況が悪化するかどうかを完全に確信することはできません。しかし、彼らはその段階に達しようとしており、私たちには防御を整えるための30日、おそらくそれ以下の時間があるかもしれません。
https://twitter.com/Viss/status/856227372785221632
それらのマシンが実際の組織によって使用されているかどうか、パッチの状況、ネットワークセグメンテーションなどを議論することは可能ですが、多くの企業が依然として脆弱なバージョンのWindowsを運用しており、それらのシステムにパッチを当てるサイクルは困難であることは常識です。また、Wannacryと比較すると、大まかに24K以上の潜在的に悪用可能なホスト対140K以上のDoublePulsarを正面に出したホストといった状況が見られます。
この段階での大きな危険は、CVE-2019-0708の悪用が組織内部で一度行われると、迅速にホストを侵害し、横方向移動を行うことです。そして、この記事の執筆時点でExploit PoCがまだ出ていないため（偽物は多数存在するが）、悪用が公開される前にあらゆるツールを駆使して検出を構築します。
上記を考慮し、ディフェンダーが行うべきトップ3のことは：
- 積極的な検出コンテンツを展開する。
- パッチの適用または脆弱性の緩和を厳格に促す。
- 信頼できる研究者からの入力に従って状況の進展を追跡する。
いくつかのポイントを強調するために、Florian Rothの2つのツイートについて言及したい：
 |
 |
シグマルール、最初に救援に。
最初のルールは、Lateral Movement技術T12010 / Remote ServicesのExploitに対処するため、Markus NeisのSigma githubリポジトリによって提供されるもので、Sigma #1としてさらに参照されています。 https://attack.mitre.org/techniques/T1210/ :
1時間以内に、Roman RanskyiがSOC Prime TDMで同様のルール（Sigma #2）を公開しました。これは、コミュニティ / 無料で使用できるもので、T1036 / Masqueradingへの検出ロジックの拡張を伴っています。 https://attack.mitre.org/techniques/T1036/ そしてT1046 / ネットワークサービススキャン https://attack.mitre.org/techniques/T1046/ .
基本的に、TLP:WHITEおよびTLP:GREENの検出がありましたが、これはフルスケール攻撃を検出するのに十分なのでしょうか？
機械学習の導入、一歩先へ。
機械学習の能力を探り、この問題に少しアドバンテージを得るためにElasticスタックのためのレシピを作成することから始めましょう。
MLレシピ：CVE-2019-0708に関連する可能性があるRDPの横方向移動を検出する
理論
限られた時間枠内に単一のホストから開始されたRDP接続におけるユニークな宛先IPアドレスの過剰数は、RDPプロトコルを伝播方法として使用するワームの横方向移動および拡散の兆候でありえます（RDSのエクスプロイトを使用しCVE-2019-0708の脆弱性に関連します）。
説明
このユースケースレシピは、RDPワームの伝播ポイントやRDP/T1076を介した横方向移動の潜在的なポイントである可能性のあるソースIPアドレスを特定します。
有効性
このユースケースレシピはまだ存在しないRDPワームに対するRemote Desktop Services Remote Code Execution Vulnerability（CVE-2019-0708）のための自動化された積極的な検出の一部として提供され、脆弱性を悪用し、内部LANセグメントを横方向に移動するためにRDPを使用することが期待されています。野外でその振る舞いを観察した後、RDPワームの動作に関する追加情報は、より効果的な検出結果を生むためのレシピ調整に使用できます。
ユースケースタイプ
基礎的攻撃行動（EAB） – このユースケースは基礎的攻撃行動に関連する異常を検出します。検出された各異常には正規化された異常スコアが割り当てられ、それに影響を与えるデータの他のフィールドの値が注釈として付加されます。共通の統計的な影響を受ける基礎的攻撃行動は、しばしば共通の攻撃進行に関連しています。
ユースケースデータソース
ECS形式で提供される同様のデータのNetflowイベント、VPCフローログ。これは内部LANセグメント内のWindowsホスト間のRDP接続のログを含みます。
ユースケースレシピ
| 対象: | RDP接続。 |
| モデル: | 各ソースIPアドレスのユニークな宛先IPアドレスの数ソースIPアドレス。 |
| 検出: | 特定のソースIPアドレスに対する宛先IPアドレスの数が異常に多い状態。特定のソースIPアドレス。 |
| 比較: | クエリ結果の最も多く記録されたソースIPアドレスの全体。クエリ結果におけるソースIPアドレスの総人口。 |
| パーティション基準: | なし |
| 除外: | なし |
| 期間: | 2週間以上の期間にわたるNetflowイベントの分析を実行します。または長期間。 |
| 関連レシピ: | なし |
| 結果: | 影響を受けるホストは、脆弱性スキャナ、ジャンプホスト、またはRDPワーム伝播のソースとして機能する侵害されたホストである可能性があります。影響を与えるホストは脆弱性スキャナー、ジャンプホスト、またはRDPワームの伝播ソースとして機能する侵害されたホストです。の伝播のソースとして機能する侵害されたホスト。 |
インプットフィーチャーと候補を影響を与える要因として
| 必須フィールド | 説明 | 例 |
| source.ip | RDPセッションの送信元 | 10.10.1.1 |
| destination.ip | RDPセッションの宛先 | 10.10.1.124 |
| destination.port | RDP接続を識別するTCPポート | 3389 |
Elasticsearchインデックスパターンの例：ecs-netflow*Elasticsearchクエリの例：“query”: {“term”: {“destination.port”: {“value”: 3389″,”boost”: 1}}}
機械学習分析/検出器構成：
検出器（s）：source.ip overの高いdistinct_count（destination.ip）
bucketspan：15m
影響を与える要因：source.ip
ElasticスタックにおけるML結果の探求。
単一のメトリックビューは、探していたドローンを見つけてくれます。したがって、より良いデータセットが整えば、より正確な異常検出が可能になります。
アノマリーエクスプローラは、通常のRDP接続対ワームのような動作または狡猾なAPT脅威アクターのために働いているかもしれない超級な働く管理者の物語を説明するのに役立ちます;-)
ArcSight相関エンジンの暖かいチューブサウンド。
この段階までに、検出ロジックは明確に定義されています。多くの企業がまだ主要なSIEMツールとして使用しているテクノロジーにこれを適用できるか確認しましょう。この脅威に関して解決しようとするいくつかのタスクがあります：
- 自動化されたベースでリスクにさらされている資産を特定する。
- 上記の資産で異常なRDP活動を追跡する。
- Sigmaと行動ベースのルールを活用して横移動を検出しようとする。
タスク#1：ArcSightでいくつかの関数に頼ることができる場所。
Qualys、NessusあるいはnmapがCE出力を提供する場合は、それを活用してAsset & NetworkモデルにタップしてCVE-2019-0708に対する脆弱性のある資産のリストを作成します。
スキャナーがない場合はどうすれば？Asset & Networkモデル基準に基づくか、またはこれらのバージョンが生成するWindowsイベントIDに基づいて、Windows XP、7、2003、および2008の資産で潜在的に脆弱なホストを追跡できます。
タスク#2：機械学習を代用するために、ファイアウォールおよびネットフローイベントをカテゴリー化に基づいて拾い、RDPソースおよび宛先IPをアクティブリストに保存するルールを作成します。これにより、潜在的/確認済みの脆弱性がある資産への/からの最初の接続を見つけることができます。さらに、RDP接続をプロファイルして接続数によるトラフィックスパイクを検出するトレンドを構築します。
タスク#3：Sigmaルール#1をクエリからリアルタイム相関に移植することで、横移動T1210の検出をカバーします。これを達成するために、Sigma#1ソースをUncoder.ioにコピーしてArcSightクエリを生成しました。ArcSightクエリの良いところは、言語の知識を持っていれば容易にコードをリアルタイム相関ルールのためのフィルタに変換できることです。
まとめてあなたのSOCに接続しよう！
ArcSightでは、上記のコンテンツピースが一つのダッシュボードに結びつけられ、通常の操作では空のままであるべきです。メインSOCチャンネルにイベントをロールするため、アクティブチャンネル「Correlation Event Details」から相関アラートを消費する軽量ルールを追加します。
ElasticベースのSOCでは、シンプルなKibanaダッシュボードを追加しました。それはRDPスパイクとネットフロー トラフィックに基づく異常の発見のための機械学習ビジュアル、およびSigmaルールのトリガー、影響を受けたホストなどの詳細を表示します。
すでにWatcher管理のためにSOC Primeのダッシュボードを使用している場合は、MITRE ATT&CKのプリズムを通してデータを探索し、戦術、技術、影響を受けたユーザ、コンピュータをピボットすることができ、攻撃タイムラインを観察し、ウォッチャーを管理し、Sigmaルールとケースにピボットすることができます。それ全部をKibanaインターフェイスから離れることなく行うことができます。
Elastic、ArcSight、またはSigma？
単にATT&CKをベンチマークとして使用する場合、Elasticは技術が1つ進んでいるため勝者です。
Elastic Stackの主な利点は、Sigmaに基づく機械学習と最新の脅威ハンティングクエリの両方を組み合わせる能力です。Sigmaルールのリアルタイム相関クエリへのリファクタリングがArcSightでMasquerading / T1036を発見しないことを忘れないでください。
しかし、脆弱性スキャナーからのデータを活用してデバイス間コリレーションを実行するようにArcSightを設定するのは、実際にはより容易です。すべての他のログソースと組み合わせた検出ルールパッケージは、多くの組織にとってより効果的です。
タスクを検出開発の速度とコストの観点から見ると、Sigmaは明らかにリードしています。あなたのSIEMまたはEDRがSigmaをサポートしている、またはあなたのすべてのマシンがXP、7、2003、2008を含むSysmonログを持っている場合、これはあなたにとって最適なソリューションです。もう一度、大規模な検出パッケージと単一ルールの利点は、実際の攻撃がRDPを横方向移動に使用するという私たちの仮定に大部分が基づいています。脅威検出では万能はありません。実際に動作するエクスプロイトが出て、非常に多くの場合はSigmaルールを使って検出を構築することができます。最終的には、ルールと機械学習に基づいた「既知の未知」向けのプロアクティブ検出コンテンツを構築しました。 https://blogs.gartner.com/anton-chuvakin/2019/04/30/rule-based-detection/ .
予防を忘れず、パッチを当てろ
他人の過ちから学び、これを事前にパッチすることは、Wannacryの発生時にSMBにすべてパッチを当てたかのように有益となるでしょう。パッチチームからこれに対して「ノー」が返ってきた場合は、検出を展開し、バックアップをテストし、リスクを委譲します。 https://blogs.technet.microsoft.com/msrc/2019/05/14/prevent-a-worm-by-updating-remote-desktop-services-cve-2019-0708/
MITRE ATT&CKへのリンクと無料の検出コンテンツ
- Sigma #1 Markus Neisによる https://github.com/Neo23x0/sigma/blob/master/rules/windows/sysmon/sysmon_susp_rdp.yml横方向移動；T1210；ログソース：microsoft sysmon。
- Sigma #2 Roman Ranskyiによる https://tdm.socprime.com/tdm/info/2159/横方向移動、防御エバージョン、発見；T1210、T1036、T1046；ログソース：microsoft sysmon。
- ArcSight .ARBルールパック https://tdm.socprime.com/tdm/info/2160/ ラテラルムーブメント、発見; T1210, T1046, T1076; ログソース: ファイアウォール、ネットフロー、脆弱性スキャナー、MS Active Directory ログ、Sysmon。
- Elasticスタックルールパック https://tdm.socprime.com/tdm/info/2160/ ラテラルムーブメント、防衛回避、発見; T1210, T1036, T1046, T1076; ログソース: ネットフロー、MS Active Directory ログ、Microsoft Sysmon。
SOC Workflow App コミュニティ版: https://github.com/socprime/soc_workflow_app_ce
/安全でいてください
