MITRE ATT&CK Evaluations (APT29)の個人的な結果検証 その２

MITRE ATT&CK Evaluations (APT29)のシナリオ

APT29を模擬した Evaluation のシナリオと環境は以下に掲載されています。

APT29 Evaluation: Operational Flow

https://attackevals.mitre.org/APT29/operational-flow.html

ATT&CK Arsenal（詳細な計画および手順）

https://github.com/mitre-attack/attack-arsenal/tree/master/adversary_emulation/APT29

APT29 Evaluation: Environment

https://attackevals.mitre.org/APT29/environment.html

この原文のシナリオ読んでしまえば、私書くことなにもないんですがねｗ

簡単に意訳したものを以下に書いておきます。

（もっといい訳し方や説明があると思うので、書いた人や見つけた人は教えておくれプリーズｗ）

APT29を模したシナリオは2つ用意されました。

１つ目のシナリオは、比較的広範囲に対して行われたスピアフィッシングメールから始まり、スマッシュアンドグラブで最初に感染した端末から情報を得てターゲットを認識し、次のツールを配布しつつ情報窃盗に及ぶものです。

２つ目のシナリオは、標的にされた組織に対して行われ、比較的ゆっくりとした侵害をしつつ、最終的には情報窃盗に及ぶものです。

１つめのシナリオ：

• ステップ１：初期侵害
  • ユーザが偽装されたマルウェアを実行し、RC4暗号通信を用いてC2接続する。
  • cmd.exeとpowershell.exeを起動する。


• ステップ２：速やかな情報収集および流出
  • 攻撃者が smash-and-grab で最初の情報窃盗を行う。


• ステップ３：ステルスなツールキットの配布
  • 攻撃者が新たなマルウェアをドロップする。
  • 攻撃者が権限昇格したうえで新たなマルウェアを実行する。
  • 新たなマルウェアはHTTPSプロトコルを利用したC2接続を確立する。
  • 攻撃者が権限昇格の痕跡を消去する。


• ステップ４：防衛の回避および環境調査
  • 攻撃者が新たなツールをドロップし、解凍する。
  • ステップ１でのアクセスに用いたプロセスを終了してからそのアクセスに関連したファイルを削除する。
  • Powershellスクリプトで環境調査する。


• ステップ５：永続化
  • サービス登録、スタートアップへの登録という2種類の方法で永続化する。


• ステップ６：認証情報へのアクセス
  • Webブラウザの記録情報、秘密鍵、パスワードハッシュを取得する。


• ステップ７：情報収集（ローカル）および流出
  • スクリーンショット、クリップボード、キー入力から情報を収集する。
  • 圧縮・暗号化してWebDAVを用いて攻撃者へ流出する。


• ステップ８：水平展開
  • ドメイン内のホストを列挙し、二次被害者とのリモートPowershellセッションを確立する。
  • 新たなペイロードを二次被害者の端末へアップロードし、二次被害者端末上で実行する。


• ステップ９：情報収集（リモート）
  • 二次被害者の端末に新たなツールをドロップし、情報収集してC2接続を経て流出させる。
  • アクセスに関するファイルを削除する。


• ステップ１０：永続化処理の実行
  • 最初の被害端末が再起動されると、永続化に使われた仕組みによりマルウェアを実行する。

２つめのシナリオ：

• ステップ１１：初期侵害
  • ユーザが偽装されたマルウェアを実行し、別のダミーファイルに隠されたコードを実行する。
  • 永続化のためにレジストリに書き込みする。
  • HTTPSプロトコルを経由したC2接続を確立する。


• ステップ１２：アクセスの強靭化のための細工
  • タイムスタンプを変更する。
  • アンチウィルスやインストールされたソフトウェアを列挙する。


• ステップ１３：ローカルマシン情報の列挙
  • ローカルコンピュータ名、ドメイン名、現在のユーザ、実行中のプロセスを列挙する。


• ステップ１４：権限昇格
  • 権限昇格し、認証情報を盗む。


• ステップ１５：永続化の確立
  • ステップ１１とは異なる、WMIを用いた第２の永続化を行う。


• ステップ１６：水平展開
  • ドメインコントローラとドメインのSID（セキュリティ識別子）を列挙する。
  • ドメインコントローラへのリモートアクセスを確立する。
  • ステップ１４で使ったツールをドメインコントローラで実行し認証情報を盗む。


• ステップ１７：情報収集
  • ローカルの電子メール情報を収集する。
  • ファイルは圧縮され、難読化のためにGIFに偽装される。


• ステップ１８：情報流出
  • ステップ１７の情報をオンラインWebサービスアカウントへ流出。


• ステップ１９：クリーンアップ
  • アクセスに関するファイルを消去する。


• ステップ２０：永続化処理の実行
  • 最初の被害端末が再起動されると、永続化に使われた仕組みによりマルウェアを実行する。


 

MITRE ATT&CK Evaluations (APT29)の検出カテゴリー

シナリオを仮想環境で実行し、製品ベンダーやMSSPサービスはそれを検知していきます。

その検知の状況が Result に出ていますが、その評価の定義が以下に書かれています。

この検知の用語の定義が分からないと評価ができないので、意味をきちんと把握しておく必要があります。

APT29 Evaluation: Detection Categories

https://attackevals.mitre.org/APT29/detection-categories.html

簡単に意訳すると以下のとおりです。

検出タイプ（メイン）

• None
  • 今回のEvalietionのシナリオの中で利用可能なデータは得られなかった。
  • 要は未検知かつ情報未収集。
• Telemetry
  • 今回のEvalietionのシナリオの中でイベントが発生したことを示す最小処理データ。
  • データ出力につながる複雑なロジックや高度なルールの証拠はなく、単純なフィールドのラベル付けのみ。
  • 要は収集はされたがアラートとは判定されず、アラートとしては未検知。後で検証する際に証跡が残っている程度の模様。
• MSSP
  • MSSPや監視サービスから、人間による分析結果として得られる。
  • 人間が手動で解析するため、原理的には（機械的に即時にアラートができる仕組みに比べると）遅延(deley)となる。遅延幅は定かではないが、数時間～数日程度とみられる。
  • 要は人が分析した結果、発生時ではないものの侵害の有無や内容が人によって分析されて見つかる。遅延はあるものの検知。
• General
  • 今回のEvalietionのシナリオの中で、悪意がある、または異常と判定されたイベントが発生したことを示す。
  • 要は収集はされたデータで自動でアラート検知等ができた。
• Tactic
  • 今回のEvalietionのシナリオの中で、収集されたデータからATT&CK戦術または同等の判定ができたもの。
  • 単純なアラートだけではなく、収集はされたデータが詳細に分析され、アナリストに対し「なぜ」それが行われたかが分かる情報まで示す。
• Technique
  • 今回のEvalietionのシナリオの中で、収集されたデータからATT&CKテクニックまたは同等の判定ができたもの。
  • 単純なアラートだけではなく、収集はされたデータが詳細に分析され、アナリストに対し「どのようにして」それが行われたかが分かる情報まで示す。

検出の修飾子

• Alert
  • 不審または悪意のあるイベントとして、アナリストに優先的に通知される。
• Correlated
  • 以前に疑わしい/悪意のあるものとして識別されたイベントに関連づくものとして表示される。
• Delayed
  • 発見、分析結果の表示に時間が要するもの。
  • システムの処理に必要な最小限度の時間や通信の遅延が原因の場合はこのカテゴリに含まれない。
  • Manual：処理は自動ではなく、人間が実行するように指示した場合。または、MSSPは人間のアナリストの分析結果として出力される。
  • Processing：イベントに複雑なロジックを適用するため、追加のデータ処理で遅延した場合。
• Host Interrogation
  • データがシステムの機能を利用して手動で抽出される場合。
  • エビデンスは自動では取り込まれないが、手動分析であれば情報が取得可能な場合を示す。
  • セキュリティ調査をするSOCやCSIRTといった一部のセキュリティエンジニアやチームには有用であるものの、使いこなすには相応の能力を要する。
• Residual Artifact
  • 攻撃に使用されている可能性のある機能や動作を特定するために、追加の分析が必要なバイナリメモリやプロセスメモリなどのデータ。
  • エビデンスは自動では取り込まれないが、手動分析であれば情報が取得可能な場合を示す。
  • セキュリティ調査をするSOCやCSIRTといった一部のセキュリティエンジニアやチームには有用であるものの、使いこなすには相応の能力を要する。
• Configuration Change
  • テスト開始後に機能の設定が変更された。テストでは追加のデータを収集や処理をするために機能の設定の変更は可能としている。
  • UX：ユーザーエクスペリエンスの変更。検出する機能の変更ではないが、収集されていてもユーザに表示されていない情報の表示が関係する可能性がある。
  • Detection：攻撃を検出する機能に影響を与える情報を収集・処理する機能の機能に対する変更の場合。
• Innovative
  • 攻撃を検出するために革新的で有用な方法に適用される指定。
  • 収集されたデータ、検出方法、検出の正確さ、エンドユーザーに提供される情報などを考慮して評価チームの裁量で適用（要は、検証者の「これSUGEEEEEEE !」指定）。

検証結果の参照に関する留意事項

テストのシナリオとResult画面の検出に対する評価の意味は、以上で大体分かったと思います。

（分からなかったら、掲載しているHPのリンクから原文の説明を読んでクレメンス）

これらの意味が理解できたところで、テスト結果について分析し、自分のポリシーに合わせて評価していくわけですが。

評価するにあたり、私が個人的に気になった点がいくつかあったので、留意事項として挙げておきます。

コストについては触れていない

前の記事でも「コスト（価格）」について触れたので、内容的には再掲になります。

テスト結果と、以上の検出のカテゴリー確認していくことで、自分の価値観と照らし合わせて高評価、低評価ができると思います。

それにより、検知がよい、アラートが多く出てくれるソリューションが見えてきます。

単純に考えると、検知がよい、アラートが多いソリューションが良いものと考えられます。

しかし、そのシステムやサービスが、設備ワンセット＋年間コストで数千万円ということもあります。

コストパフォーマンスの判断は、導入する会社・組織によって考え方が異なるため、コストは別途考慮する必要があります。

重要視するパラメータの違い

テスト結果を分析、評価する上で、注意しなければならないのが検出カテゴリーのパラメータの重みづけでしょう。

これは、評価する人の立場や考え方によって、どのカテゴリーの値を重視するか、その重みづけをどうするか、が変わってくると思います。

つまり、テスト結果を分析、評価するには、前提として「評価のポリシー」を決める必要があるということです。

例えば、私も今回の後続の記事で、「私なりの評価結果（さきえる的オススメソリューション？）」を書こうかなと思っています。

その評価方法として、以下のように考えています。

• とにかく検知しないと意味がないんだから、MSSP、General、Tactic、Techniqueを〇としよう。
• でも、後で検証するときにエビデンスはあった方がいいので、Telemetryは△にしよう。
• Noneは情報収集すらできていないから×ね。
• 一項目毎に検知（〇）、Telemetryのみ（△）、未検知（×）とし、一項目で複数検知しても、「その項目を見つけた」ということで１カウントとしよう。
• サイバー攻撃が１日以内に終わるようなことは無いのだから、Delayedは問題にはしない。

私もサイバー攻撃対応のフォレンジック屋（まあ普通のフォレンジックもやるんだけどね）なので、「検知」できることに重みを置いた評価です。

ただし、データがあれば後の調査・検証で使えるかもしれないので、Telemetryもあったほうがよい、としています。

一方で、Alertについては今回は重みを付けず、Delayedも極端でない限り不問でよいと思っています（というか、これがダメならMSSPのサービスは全滅な気がする）。

一方で、もし私が運用監視担当者ならどうでしょうか？

• Alertが出てくれなければ担当者は気づけないのだから、Alertの有無が最重要項目。
• Telemetryなんて見ても分からないから、評価に値しない。
• MSSPは導入も考慮したいから、Delayedは問題にせず、実際どれくらい遅れるかは後日ベンダーに確認。

となるかもしれません。そうすると、Alertの有無で〇×が付くことになります。

重要インフラの監視システムに入れるのであれば、「重要インフラが止まってはいけないから、Alert最重要、かつ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（Proof of Concept）などで検証しないと結局は分かりません。

このシナリオ結果だけで導入して、後でアラート祭りにならないように留意は必要です。

最後に思いつくままに留意点を書きましたが、実際の攻撃を模したシナリオでこれだけのセキュリティソリューションを横並びで検証できる機会は中々無いので、「評価のポリシー」を定めて判断したり、どのそれぞれのソリューションの強み弱みを把握して、製品選定の一助にするのには非常によい情報だと思います。

幾つか選定した後は、十分な情報交換をし、PoCなどで目的達成に資するかしっかり見極めることは以前と同様重要です。

それでは、次回以降に私の個人的な基準による評価をやってみます。

「こういう評価の仕方もあるかな」とか、「もっとこういう評価の仕方の方がよい」と考えるのに役立てば幸いです。

まあ、私の趣味レベルでやるので、ちょっと時間かかると思いますが・・・。