はじめに
サイバーセキュリティ推進部の吉田です。普段は、CSIRTメンバーとしてAWS環境や各種端末のモニタリング、セキュリティインシデント対応、社内からのサイバーセキュリティに関する相談対応などの業務を行っています。
概要
この記事では、コインチェックにおけるEDR（エンドポイントセキュリティ製品）の乗り換えにあたって、選定の際に考慮したことを掲載しています。私自身、EDR選定に先立つ情報収集のステップにおいて、様々なベンダーの提示する基準や事例は見つけることができましたが、EDRを選定する事業会社のセキュリティエンジニアの立場で掲載された生の情報を見かけることはありませんでした。こういった情報について、インターネット上の公開情報としてアクセス可能とすることで、事業会社のセキュリティエンジニア業務の一助となれば良いと考え、この記事を執筆しています。
おことわり
この記事では具体的な製品名などは記載していません。コインチェックのネットワーク構成などについては以下の記事に記載されていますので、併せて参照していただくと、本記事についての理解が深まると考えますので、もし良ければご参考になさってください。
前提 （今までの製品の何が問題で入れ替えることにしたのか）
まずは、コインチェックでなぜEDRの乗り換え検討を開始したのかについて、２点理由を説明します。１点目は、既存のEDR製品（以降は製品Aとします）について、新しく公開されたロードマップとコインチェックのIT環境の変化に解離があった点です。製品Aを採用した当初は、製品AのロードマップとコインチェックのIT環境がマッチしていたのですが、採用から２年が経過したことで、コインチェックを取り巻く様々な環境が変化し、この二つに乖離が生まれました。２点目の理由は、製品Aの過検知及び誤遮断の発生が多かったことです。コインチェックでは、お客様の暗号資産を取り扱う暗号資産の販売所及び取引所業務の特性上、内部端末の不審な振る舞いを見逃すことはあってはなりません。しかしながら、検知、遮断の水準をより厳しく設定した場合に過検知や誤遮断が多くなると、それらを調査し確認しなければならないため、運用負荷が増大します。これによって、製品のアラートに対する信頼度が下がり、本当に対応しなければならないアラートが発生した際に、初動が遅れてしまう可能性があります。こういった運用上の悩みについては、事業会社のサイバーセキュリティに携わる方ならば、常について回るものなので、ご理解いただけるのではないでしょうか。製品Aについて、２年間の実運用を通して、こういった課題が見つかってきた中、製品Aの契約期間の期限が近付いていました。これらの課題についてサイバーセキュリティ推進部内で議論した結果、製品Aの契約をただ更新するよりも、よりコインチェックのIT環境にマッチした製品を選定し直すことが重要であると結論されました。このことから、製品Aから新しいEDRへの乗り換え検討を開始しました。
要件定義
コインチェックにおけるEDRの採用要件について整理した結果、以下の要件を必須としました。
- 製品Aと比較して検知能力が優れていること
- コインチェックで利用しているSIEMとの連携が可能であること
- 過検知が少なく、運用上の負荷が少ないこと
- 端末への負荷が高くないこと
- 製品のロードマップがコインチェックのIT環境とマッチしていること
これらの要件を満たし、暗号資産の取引所に採用する製品として最もマッチした製品を選定することを目的としました。このことから、仮に既存の製品Aが当社にマッチしていると結論された場合には、契約を更新することも選択肢として持つこととしました。
机上選定作業
今回、机上選定の対象とした製品は４つでした。過去、私の入社以前にEDRの選定を行った際のドキュメントが残っていたため、それらを参照しつつ、まずは机上での製品選定に進みます。机上選定時に行ったことは、主に公開ドキュメントの調査です。机上調査を行う観点としては、先に挙げた要件を満たしているかどうかを確認していきました。各製品の公式サイトに記載されているドキュメントの他に、代理店を挟む場合はそちらに掲載されている情報も確認します。この際に注意した点としては、掲載されている情報を検証しないまま鵜呑みにしないことでした。各製品とも、素晴らしいスペックや、謳い文句が掲載されていますが、実際に検証してみた事実と公開されている情報が異なることは往々にして起こり得るからです。前回のEDR選定ドキュメントを確認したところ、ベンダーの公開資料では、とある事項について対応可能と記載されていても、実際に検証してみると前提条件があったり、我々の期待値を満たすのレベルではないことがあった旨が記載されていました。こういった点を考慮しつつ机上調査を行った結果、製品Dは必要な要件を満たしていないと判断し、実機検証の対象外としました。ここまでの机上調査で残った製品は、製品Aを含む３つです。
実機検証作業
さて、いよいよ実機検証作業に着手していきます。先に行った机上選定においては、公開情報から調査を行ってきましたが、ここからは実際に検証端末にEDRのエージェントをインストールして調査を行なっていきます。今回検証を行う端末は、社内で実際に利用している端末と同等のものを準備して利用することとしました。仮想環境であることを検知して、振る舞いを変えるマルウェアも存在しますので、検証作業は出来る限り実機を用いた方が良いと考えたため、仮想環境ではなく実際に検証端末を準備しました。この点は、専用の検証端末を準備できるかどうか、仮想環境のみで良しとするか、リソースと天秤にかけて決定すれば良いと考えます。コインチェックでは、端末をすぐに準備することが可能でしたので、検証用端末を準備することとしました。こうして、実機による検証の準備が整いましたので、実際の検証開始前に大まかにテスト項目と評価基準を以下のとおり設定しました。
これらの大まかな評価項目と評価基準をベースに、実際に行う検証作業を設定していきます。まずは、一番重要なマルウェアに対する検知率です。マルウェアの検知テストについては、実際の検体を取得可能なWebサイトが存在していますので、そちらから取得すれば検知検証は可能です。しかしながら、検証端末とはいえ社用端末にマルウェアをダウンロードし実行するのはセキュリティ上リスクがありますので、C2フレームワークを用いて検証を行うこととしました。この点については後述します。先に挙げた評価項目の内、以下の点についてはEDR管理コンソールなどから確認可能でした。
-
SIEMへのログ転送可否
-
検知除外設定の可否
-
管理コンソールによる端末操作可否
-
ログの保存期間が十分か
-
管理コンソールによる検体取得可否
管理コンソールから確認可能な点については特に触れるべき点はありませんが、操作に関する確認事項については、管理コンソールを実際に操作し、目的の操作が正しく行えるかまで検証を行いました。カタログには対応できる旨が記載されていても、実際に操作してみて目的の操作が行えなければ、確認として不十分であると考えたためです。その他の確認事項だと端末の負荷については、エージェントを稼働させている端末のCPU使用率や、メモリ使用率をモニタリングすることで確認可能です。次に、シグネチャベースのアンチウイルスとしての検知ではなく、EDR特有の不審な挙動の検知能力について調査を行っていきました。マルウェアそのものを検知するかどうかではなく、マルウェアの挙動を端末上で再現してみることで、各製品がその挙動を不審であると検知するかどうかを調査します。具体的な手法としては、以下をピックアップしました。各攻撃手法については、「MITRE ATT&CK」 の名称を用いていますので、詳細はそちらをご参照ください。
-
Defense Evation Masquerading （検知回避の振る舞い）
-
Credentials from Password Stores（認証情報へのアクセス）
-
Exfiltration Over Alternative Protocol（DNSリクエストを装ったデータ持ち出し）
-
Command and Scripting Interpreter（リバースシェルによるC2の待ち受け動作）
-
OS Credential Dumping （ハッシュ値からのパスワード調査ツールの利用）
それぞれの検証方法について概要を記載していきます。
1. Defense Evation Masquerading（検知回避の振る舞い）
マルウェア の動作の一つである”検知回避の振る舞い”をEDRが検知するかを調査しました。実行ファイル名を書き換えた上で実行する振る舞い（何のコマンドを実行したかを隠蔽するための行為）をシェルスクリプトを実際に作成し実行することで、セキュリティソフトの検知を回避する振る舞い（Defense Evation）を再現します。これによって、この振る舞いを、EDRが不審と判断するのかどうかを確認することができます。whoamiコマンドなどは侵入後の情報収集のステップにおいて利用されることがありますので、調査用のコマンドとしては十分と考えました。
2. Credentials from Password Stores（認証情報へのアクセス）
端末に保存された認証情報へのアクセスを、不審な振る舞いとして検知するかどうかを調査します。マルウェアは端末への侵入完了後にさらに感染を展開させるため、感染端末に保存された認証情報の取得を試みることがあります。具体的には、OSに応じたコマンドを実行することで、端末上に保存された認証情報（パスワードハッシュ）へのアクセスが可能です。スクリプトに記述して実行しても構いませんが、CLIなどで直接コマンドを実行しても検知テストは可能です。いずれにしても、通常の業務で使われないコマンドであることから、不審な動作であることは間違いありません。EDRの設定によっては当該プロセスがKillされることもあるので、実際にはコマンド実行が失敗することがありますが、何らかの形で検知できていれば問題ないと考えました。
3. Exfiltration Over Alternative Protocol（DNSリクエストを装ったデータ持ち出し）
マルウェアが内部に侵入した後に、DNS通信を装い内部のデータを外部に持ち出すための振る舞いを検知するかどうかを調査します。一部のマルウェアでは、様々なプロトコルを用いて C2サーバと通信をすることで、セキュリティ製品による検知を回避するように設計されています。これらのマルウェアの通信を検知できれば、より幅広いマルウェアへの対応可否を評価することが可能と考えました。
4. Command and Scripting Interpreter（リバースシェルによるC2の待ち受け動作）
リバースシェルは、感染端末とC2サーバ間で接続を確立させる際に利用される方法です。C2サーバ側で、感染端末からの指定ポートの接続通信を待機し、接続後には任意の操作を感染端末上で実行できます。C2サーバからのインバウンド通信ではなく、感染端末側からC2サーバ方向に接続を試行します。こういったC2通信もマルウェアでは一般的に利用されるため、EDRにおける検知可否を確認することは重要であると考えました。
5. OS Credential Dumping （ハッシュ値からのパスワード調査ツール）
攻撃者が内部に侵入した際に悪用することのあるソフトウェア（いわゆるリスクウェア）の検知可否を調査します。ここではパスワード調査ツールの一つであるHashcatを用いています。Hashcatは、ハッシュ値を基にパスワードを推測することのできるツールですが、Hashcat それ自体はマルウェアではなく、内部侵入後の攻撃者が用いることのあるツールの一つですので、端末にインストールして実行すれば検知可否を確認可能でした。
C2フレームワークを用いた検知テスト
ここまで、マルウェアの振る舞いの検知可否の観点から検証を進めてきましたが、社内でマルウェア感染のインシデントが発生した場合に、本当にマルウェアを検知できるのか疑問を感じることがありました。これまでの検証では、実際に悪意を持った攻撃者が作成したマルウェアを稼働させているわけではなかったため、このような疑問が残りました。この点について部内で協議したところ、実際に攻撃に用いられた実績もあるC2フレームワークを利用した検知テストを実施すれば良いと結論しました。私自身C2フレームワークを用いた検知テストを実施した経験がなかったため、手探りではありましたが、メンバーの協力も仰ぎつつ、テストを実施することとなりました。このテストに必要な要件としては、クライアント端末でファイルを実行、端末の感染後に、C2サーバへのビーコンを送信し任意のコマンドを受け付けて、その結果をC2サーバに送信するものとしました。これは、内部社員を対象とした標的型攻撃が発生し、社員が実行ファイル形式のマルウェアを実行してしまったというシナリオを想定しています。今回は検知テスト用マルウェアとしてオープンソースのC2フレームワーク「PoshC2」を利用することとしました。PoshC2はペネトレーションテストの利用を目的としたC2フレームワークですが、実際にマルウェアとして攻撃者に利用されることもあり、検知テストに用いるには十分であると判断しました。
https://poshc2.readthedocs.io/en/latest/#
事前の想定
事前の想定では、PoshC2のDropperをダウンロード後に、C2サーバ側から任意のコマンドを実行した段階で、いずれのEDRでも検知できると考えていました。なぜならば、PoshC2自体は普遍的なC2フレームワークであり、最初から検知を回避するために特別に難読化などのチューニングを実施しようと考えていたわけではなく、検知状況を確認しながら進めていこうと考えていたためです。
PoshC2で実際に行ったこと（※ MITRE ATT&CK 表記に準拠）
PoshC2のサーバ及びDropperの準備が完了したため、以下のステップに則って検証端末への侵入を実施していき、どの段階でEDRが検知できるのかを検証していきました。
- Initial Access（初期アクセス）
- Phishing（フィッシング）
- HTTP経由でDropperのダウンロード
- Execution（実行）
- User ExecutionPersistence（永続化）
- 検証端末でのDropperの実行
- Persistence（永続化）、Privilege Escalation（権限昇格）
- Boot or Logon Autostart Execution（自動起動登録）
- ペイロードのダウンロード
- マルウェアの自動起動登録
- Defense Evasion（防御回避）
- Masquerading（なりすまし）
- マルウェアの無害なファイルへのなりすまし
- Credential Access（クレデンシャルへのアクセス）
- Exploitation for Credential Access
- 暗号化されたクレデンシャルへのアクセス
- Discovery（探索）、Lateral Movement（横展開）
- Data from Local System（ローカルファイルの取得）
- 任意のファイルの取得
- ネットワーク情報の探索及び取得
- Collection（データ窃取）
- Input Capture（入力のキャプチャ）
- キーロガーの実行
- Command and Control（コマンドと制御）
- Data Encoding（データエンコーディング）
- 窃取したデータの難読化
- Exfiltration（データ持ち出し）
- Exfiltration Over C2 Channel（C2チャネルを介した持ち出し）
- 任意のファイルのアップロード/ダウンロード
- Impact（破壊）
- System Shutdown/Reboot（システムのシャットダウン/再起動）
- 端末のシャットダウン
実際の検知結果
実際にC2サーバを準備し、クライアント側でDropperをダウンロード、実行してみたところ、その検知結果に大きな違いがあることがわかりました。結論としては、検証対象としていた３製品の内、侵害ステップ「3. Persistence（永続化）、Privilege Escalation（権限昇格）」の段階で、PoshC2を検知できたのは製品Bのみでした。製品Aについては、「9. Exfiltration（データ持ち出し）」まで、１度も検知されずに、端末に存在する機密情報を窃取することが可能でした。前項にて検証したマルウェアの振る舞い単体については、検知能力に大きな違いはありませんでしたが、実際に動作するマルウェアの検知に関しては大きく結果が異なることとなりました。この点については、実際に手を動かして検証しなければ確認できない事実でしたので、PoshC2を用いた検証を行って良かったと改めて感じました。
採用製品の決定
こうして一通りの検証作業が完了した後、正式採用を決定したのは製品Bです。不審な振る舞いやマルウェアに用いられるソフトウェアの検知などについては、製品Aと製品Bに大きな差はありませんでした。また、どちらの製品も必要とされる技術的要件を満たしており、どちらを正式採用する製品とすべきか悩んでいました。しかしながら、PoshC2を用いたマルウェアに対する検知能力の差が、大きな決め手となりました。もしかしたら、検証に用いたC2フレームワークや、コマンドによっても違いがあったのかもしれませんが、今回の検証では、製品BがコインチェックのEDR採用に最も適していると結論しました。こうして、製品Bを契約し導入する運びとなり、その後の社内端末への全体展開後にも過検知や誤遮断は発生しておらず、５月末日時点において、問題なく稼働していますので、製品Bの採用は正しかったと考えています。
最後に
ここまで読んでいただいてありがとうございました。自社のEDRを選定するように業務命令が下ったけど、何から着手すればいいかわからない…といった、事業会社のセキュリティエンジニアの方の参考になれば、とても嬉しく思います。
さて、コインチェックでは、サイバーセキュリティ推進部で一緒に働くメンバーを募集しています。当社では、暗号資産販売所におけるセキュリティ対策の推進に携わることができ、個人に与えられる裁量が大きいことから、自身で手を挙げてプロジェクトを推進していける方であれば、より成長できる機会を得ることができます。少しでも気になった方は応募していただけると嬉しいです。
