Mitre Engenuity Att&ck Evaluations (Carbanak+FIN7) のシナリオ
シナリオ１：「Carbanak」による金融機関に対する攻撃を模擬
- ステップ１：初期侵入
- ユーザの操作で .rtf ファイルをWordで開くことにより、wscript.exeが不正なコードを実行。
- 攻撃者のサーバと通信を実施。
- ステップ２：ローカル端末の探索と収集
- wscript.exeを利用してローカル端末の情報を収集。
- powershellを利用してローカル端末の情報を収集。
- ステップ３：新たなRAT感染
- 攻撃者のサーバから新たなマルウェアをダウンロード。
- powershellを利用してシェルコードを実行。
- ステップ４：ドメインの探索と資格情報のダンプ
- ドメインサーバへ不正ログオン。
- 攻撃者のサーバから新たなpowershellスクリプトファイル、マルウェアをダウンロード。
- 権限昇格。
- ステップ５：水平展開
- 攻撃者のサーバから新たなマルウェアをダウンロード。
- ＳCP経由でLinux端末に不正アクセスし、コマンドラインにより情報を入手。
- ドメインサーバ上に不正な実行ファイルを作成。
- ステップ６：探索
- powershellで端末情報を取得。
- ステップ７：水平展開（CFO）
- ドメインサーバにＲDP経由でアクセス。
- 攻撃者のサーバから新たなマルウェアをダウンロード。
- ステップ８：実行
- マルウェアを実行し、攻撃者のサーバと通信。
- ステップ９：ユーザ情報の収集
- 入力キャプチャ、画像キャプチャ、パスワードストア等から情報を収集。
- ステップ１０：VNCの永続性
- VNCからの接続をできるよう、VNCのサービスの永続化およびTCPポート5900のネットワーク設定変更。
シナリオ２：「FIN7」によるクレジットカード情報窃盗を模擬
- ステップ１：初期侵入
- ユーザの操作で .rtf ファイルをWordで開くことにより、mshta.exeが不正なコードを実行。
- ステップ２：遅延させたマルウェアの実行
- スケジュール機能を利用してマルウェアを実行。
- マルウェアは攻撃者のサーバと通信し、新たなpowershellスクリプトをダウンロード。
- ステップ３：ターゲットの評価
- マルウェアは端末内から環境情報を収集。
- マルウェアは攻撃者のサーバと通信し、新たなpowershellスクリプトをダウンロードおよびデータのアップロード。
- ステップ４：インタラクティブツールキットの設置
- powershellにより、不正なプログラムの実行、攻撃者のサーバと通信などを実施。
- ステップ５：権限昇格
- powershellにより攻撃者のサーバと通信し、不正なプログラムのダウンロード。
- 権限昇格。
- ステップ６：アクセス拡大
- powershellにより攻撃者のサーバと通信し、不正なプログラムのダウンロード。
- SMBセッションを用いて他の端末にアクセス。
- ステップ７：ユーザーのモニタリングを設定
- マルウェアを実行。
- マルウェアは攻撃者のサーバと通信し、データをアップロード。
- ステップ８：ユーザーのモニタリング
- プロセスインジェクションを行い、ユーザのスクリーンをキャプチャ。
- ステップ９：Shimの永続性を設定
- RDPを用いた不正通信の確立。
- powershellにより追加マルウェアをダウンロードした後、永続化のための設定を実施。
- ステップ１０：支払い情報の窃盗
- 収集したデータを圧縮・アーカイブ。
- マルウェアは攻撃者のサーバと通信し、データをアップロード。
Mitre Engenuity Att&ck Evaluations の検出カテゴリー
検出タイプ（メイン）
- Not Applicable
- ベンダーがセンサーを配布しなかった等により、評価対象外。
- 今回のケースでは、主にLinux対応していない製品がLinuxを対象外とした。
- None
- 今回のEvalietionのシナリオの中で利用可能なデータは得られなかった。
- 要は未検知かつ情報未収集。
- Telemetry
- 今回のEvalietionのシナリオの中でイベントが発生したことを示す最小処理データ。
- データ出力につながる複雑なロジックや高度なルールの証拠はなく、単純なフィールドのラベル付けのみ。
- 要は収集はされたがアラートとは判定されず、アラートとしては未検知。後で検証する際に証跡が残っている程度の模様。
- General
- 今回のEvalietionのシナリオの中で、悪意がある、または異常と判定されたイベントが発生したことを示す。
- 要は収集はされたデータで自動でアラート検知等ができた。
- Tactic
- 今回のEvalietionのシナリオの中で、収集されたデータからATT&CK戦術または同等の判定ができたもの。
- 単純なアラートだけではなく、収集はされたデータが詳細に分析され、アナリストに対し「なぜ」それが行われたかが分かる情報まで示す。
- Technique
- 今回のEvalietionのシナリオの中で、収集されたデータからATT&CKテクニックまたは同等の判定ができたもの。
- 単純なアラートだけではなく、収集はされたデータが詳細に分析され、アナリストに対し「どのようにして」それが行われたかが分かる情報まで示す。
検出の修飾子
- Configuration Change
- テスト開始後に機能の設定が変更された。テストでは追加のデータを収集や処理をするために機能の設定の変更は可能としている。
- Data Source：センサーによって新しい情報を収集するために行われた変更の場合。
- Detection Logic：データ処理ロジックに変更を行った場合。
- UX：ユーザーエクスペリエンスの変更。収集されていてもユーザに表示されていない情報の表示に関する変更の場合。
- Delayed
- 発見、分析結果の表示に時間が要するもの。
- システムの処理に必要な最小限度の時間や通信の遅延が原因の場合はこのカテゴリに含まれない。
検証結果の参照に関する留意事項
重要視するパラメータの違い
テスト結果を分析、評価する上で、注意しなければならないのが検出カテゴリーのパラメータの重みづけでしょう。
これは、評価する人の立場や考え方によって、どのカテゴリーの値を重視するか、その重みづけをどうするか、が変わってくると思います。
つまり、テスト結果を分析、評価するには、前提として「評価のポリシー」を決める必要があるということです。
例えば、検知能力を重視するなら Technique、Tactic、Generalを重視するでしょうし、攻撃の手法を自動で可能な限り正確に分析したいならば Technique を重視するでしょう。また、自分達で分析するための情報がなるべく欲しい場合は、Telemetly も含めた総数（=Noneが少ない）ことに重点を置くかもしれません。
それは、ユーザが求めている機能により変わる、ということです。
今回は、昨年同様以下の観点で分析してみます。
- とにかく検知しないと意味がないんだから、General、Tactic、Techniqueを〇としよう。
- でも、後で検証するときにエビデンスはあった方がいいので、Telemetryは△にしよう。
- Noneは情報収集すらできていないから×ね。
- 一項目毎に検知（〇）、Telemetryのみ（△）、未検知（×）とし、一項目で複数検知しても、「その項目を見つけた」ということで１カウントとしよう（一項目の中で多数の検知があっても、それほどうれしくないケース）。
- サイバー攻撃が１日以内に終わるようなことは無いのだから、Delayedは問題にはしない。
もちろん、利用する目的によって評価が変わるかもしれません。
もし、この基準の評価では満足いかないのであれば、自身の定義した評価基準で結果を整理すると良いでしょう。
NoneよりTelemetryが多ければいいというものではない
評価では、「None」は情報を得られていないか、ジャンクデータとして埋もれてしまっています。
Telemetryは、検知には至っていないものの、最低限のラベル付け分類くらいはされており、情報としては存在するため、少なくとも後で検証するのに必要な情報が残っているといえます。
こうしてみると、NoneよりTelemetryのほうが良い、というのが一般的な判断になりがちです。
問題は、「データの量との兼ね合い」は考慮すべき、という点です。
例えば、システムAが None 20%、Telemetry以上が 80%、 システムBがNone 5%、Telemetry以上が 95%だとします。
当然、セキュリティの調査する人には、システムBのほうが優秀と考えられます。
しかし、システムAがPC1台あたりの収集データが10MBだったのに対し、システムBがPC1台あたりの収集データが1万倍の100GBもあったとしたらどうでしょうか？
運用する側としては、ストレージの容量、データの量に応じた処理に対応するサーバの確保、通信量増加に伴うインフラ増強、それらの維持管理コストなどがのしかかってくることになります。
これに耐えられない場合、選択肢はシステムAということになるでしょう。
極端な話、全てのPCデータと通信データを集めておけばTelemetry以上は増えるかもしれませんが、運用やそれに伴うコストには見合わないということになるでしょう。
つまり、Noneが少なくTelemetry以上が多くても、それに伴うデータ収集量は別途確認、考慮する必要があるといえます。
実際に、収集データの量が多いために、通信のトラフィック量のひっ迫や分析処理が追いつかないのが課題、ということを相談されたこともあります。
今回のEvaluationsには収集データ量等は書かれていないようなので、こういった点も一応念頭に入れておいた方が良いでしょう。
False positiveはカウントされていないとみられる点
地味なツッコミなのですが、今回のEvaluationsでは誤検知(False positive)は評価に入ってないと思います。
同じ検知エラーでも、検知漏れ（False negative)は「None」で出るのですが。
運用を経験されている方はご承知でしょうが、いくらアラートが出るといっても、誤検知が多いと運用には耐え難いといえます。
アラートが出ると確認が必要になりますが、誤検知が多いと運用に負荷がかかるうえ、「また誤検知か」と担当者の士気も下がります。さらに、「またどうせ誤検知だろう」という、アラート不感症になってしまい、いざ本物のアラートを見落としてしまうということもあります。
これも極端な話、「外部（インターネット）との通信を全てアラートにしてしまえば、そりゃその中にC2通信も含まれるだろうが、それって意味ないでしょう？」って話ですね。
ノイズが少ない環境でのテスト
今回のテストは検証環境で行っているため、当然それぞれの端末にはユーザがいません。
しかし、現実の環境では、ユーザは色々な操作をし、度々インターネットにアクセスします。
今回のテストで検知を高めるためにセンサーの感度を高く設定した場合、先に挙げた誤検知の発生割合が高くなったり、端末やトラフィックの負荷が大きくなる可能性はあります。
実際に使う環境はよりダーティーであることは念頭に置いておく必要があります。
これは、製品のPoCを行う際にも留意しておき、チェック項目に入れた方がいいでしょう。
設定変更に関する情報が不明確
情報の抽出や検知のため、環境設定を変更することは今回のテストでも認められています。
その場合、評価に「Configuration Change」が付与されます。
しかし、多いものでは50以上ついているものも見られます。
この設定変更が、項目毎に行われたのか、全体のテストを通じて１～数回だけ行われたが複数の項目に影響を及ぼしたかは、よくわかりません（私が見落としてるのかもしれませんが）。
いくらなんでも、一項目毎に検知できるうように設定変更、なんてことはないと思いますが。
とはいえ、前記事の運用の話でも触れましたが、この設定変更を、どういった条件のときに、どのように変更するか、その頻度はどれほどか、ということは分かりません。
運用面を気にする方は、「Configuration Change」にも注意が必要かもしれません。
私見を色々書きましたが、実際の攻撃を模したシナリオでこれだけのセキュリティソリューションを横並びで検証できる機会はなかなか無いので、「評価のポリシー」を定めて判断したり、どのそれぞれのソリューションの強み弱みを把握して、製品選定の一助にするのには非常によい情報だと思います。
幾つか選定した後は、十分な情報交換をし、PoCなどで目的達成に資するかしっかり見極めることは以前と同様重要です。
次以降の記事で、去年同様、自分の決めた評価基準で評価していきたいと思います。