IIJ-SECT

IIJ

 

Security Diary

HOME > Security Diary > OpenIOCを使った脅威存在痕跡の定義と検出

OpenIOCを使った脅威存在痕跡の定義と検出

OpenIOCは、マルウェアなどの脅威によって侵害を受けたシステムにおいて、その脅威が存在することを示す痕跡(Indicator of Compromise)を定義するための規格です。

この規格は、脅威の持つ特徴やその脅威に起因するシステムの変化をXMLで定義しています。もともと、同規格は、Mandiant社の製品内部で使用されていたものでしたが、2011年の11月に同社はこれを公開しました[1]。また、Mandiant社は、同時にその規格に基づいて脅威が存在することを示す痕跡(以下、IOC)の定義と検出を行うツールもリリースしました[2]。 OpenIOCを使うと、たとえば標的型攻撃で使われるような、アンチウィルスソフトで検出できないマルウェア等の解析結果をIOCとして定義して共有することができます。それにより、脅威の影響が疑われる端末が多く存在する場合でも、効率的に調査することができます。 本エントリでは上記ツールを用いてどのようにIOCを定義、検出できるかについて解説いたします。

OpenIOCのツールには、IOC FinderとIOC Editorがあります。2つのツールを使ってIOCを定義・検出するフローは以下の通りです。

OpenIOC_flow

まず、フォレンジック解析、マルウェア解析により脅威の特徴となる痕跡をできるだけ詳細に抽出します。IOCはあくまで自分で定義するものなので、検体や悪意のあるコードを含むコンテンツが初めて目にするものの場合、それら自身の特徴とそれらがシステムに与える変化を明らかにする必要があります。たとえば、フォレンジック解析からは、ファイルのハッシュ値・インラインのタイムスタンプなどの特徴や、通信・ファイルシステム・レジストリ・イベントログなどのシステムの変化に関する情報を取得できます。一方、マルウェア解析では、フォレンジック解析によって得られた情報を検証しつつ、フックする関数名などより細かい情報を取得できます。

次にIOCを定義します。IOCの定義にはIOC Editorを使います。IOC EditorはGUIのプログラムで、脅威の影響のない安全な端末上で使用します。ユーザはIOC Editor上で、脅威の名前やそれに関する説明などのメタ情報と、上記の解析によって得られた情報の中からユニークだと判断する情報を入力していきます。何をユニークだと判断するかはケースバイケースです。たとえば、ファイル名やハッシュ値はマルウェアがpolymorphicなものであれば信頼できませんが、マルウェアが変更するレジストリのキーや値、もしくはオープンする特徴的なハンドル名などが解析から固定値で使われることが分かっていれば、それらはIOCとして定義します。

IOCを定義したら、IOC Finderを使って別の端末に同じ脅威が存在するかを簡単な操作でチェックすることができます。IOC Finderはコマンドラインのツールで、collectとreportという2つのコマンドがあります。collectコマンドは脅威が存在する可能性のある端末上で、USBメモリなどにコピーした実行ファイルから起動します。このコマンドは実行した端末の情報を収集します。具体的には、実行中のプロセスや接続中のTCPコネクションなどの揮発性の情報と、レジストリやイベントログなどの不揮発性の情報を収集していきます。 一方、reportコマンドはIOC Editorと同様、脅威の影響のない安全な端末上で使用します。このコマンドは、先ほど作成したIOCとcollectコマンドで収集した情報を元に、そのIOCが収集した情報の中に含まれるかを判定します。たとえば、その判定結果をHTMLで出力させた結果は以下のようになります[3]

OpenIOC_result

もし定義したIOCが誤検知を含むものであった場合は、適宜IOC Editorで変更を行い、再度reportコマンドでチェックします。IOC Finderによるreportコマンドは、あくまでIOCにマッチした個所のみを表示します。IOC Finderによって収集された情報を、IOCのマッチングにかかわらず閲覧したい時は、Mandiant社が別途提供するRedline[4]というツールを使うと、揮発性の情報に関しては参照することができます。 ところで、IOCFinderのcollectコマンドや、IOCEditor実行中にHTTP通信が発生することがありますが、これはツールがファイルの署名を検証する過程で発生するものなので、特に気にする必要はないと思われます[5]

OpenIOCには、IOC Finderの速度が遅い[6]などツール面の課題があり今後の改善が期待されますが、それを使うことで脅威を定型のフォーマットで定義して検出することができるので、効率的なインシデント調査ができるようになる可能性があります。 また、最近では標的型攻撃等の対策で情報共有の必要性が増しています。既にインシデントに関する情報を定義・共有するための規格はいくつかありますが[7]、それらの普及はそれほど進んでいません。OpenIOCは従来の規格に比べて、すぐに利用可能な実装を提供していることや、インシデント全体に関する情報(コンタクト情報や攻撃・侵入手法など)を省いて、具体的な脅威痕跡の定義のみに絞っているので、より実践的な規格になっていると考えられます。公式サイトにはStuxnetやDuquなど、過去に標的型攻撃で使われたマルウェアのIOCサンプルが配布されており、そのIOCの作り方についてもMandiant社のブログで紹介されているので[8]、興味があればチェックしてみてはいかがでしょうか。


  1. MANDIANT社によるOpenIOCに関するプレスリリースは以下。/ MANDIANT RELEASES OPENIOC STANDARD FOR SHARING THREAT INTELLIGENCE http://www.mandiant.com/news_events/article/mandiant_releases_openioc_standard_for_sharing_threat_intelligence/ また、OpenIOCの公式サイトは以下。/The OpenIOC Framework http://openioc.org/ ↩

  2. ツールはMandiant社のwebサイトで配布されている。/ IOC Editor http://www.mandiant.com/products/free_software/ioceditor/ IOC Finder http://www.mandiant.com/products/free_software/iocfinder/ ↩

  3. 現時点ではGoogle Chrome(バージョン16.0.912.77)で結果を確認することができない。 ↩

  4. RedlineはメモリフォレンジックのツールであるMemoryzeのフロントエンドとして使われることが多いが、IOC Finderの出力結果を参照するツールとして使うこともできる。/ Redline http://www.mandiant.com/products/free_software/redline/ ↩

  5. たとえば、IOC Finderは、ファイルの署名検証の為にWINTRUST.dllのWinVerifyTrust関数を呼び出すが、そこから最終的にcryptnet.dllのCryptRetrieveObjectByUrl関数が呼び出され、そこでcrl.microsoft.comやcrl.verisign.comへのHTTPアクセスが発生する。 ↩

  6. Mandiant社のフォーラムでは、IOC Finderで収集する情報を必要最低限に絞ることで速度を改善するスクリプトも配布されている。スクリプトのダウンロードにはアカウントの登録が必要。/ Alternate collection script (faster) https://forums.mandiant.com/topic/alternate-collection-script-faster ↩

  7. たとえばIETFのRFC5070で規定されているIncident Object Description Exchange Format (IODEF)がある。/ The Incident Object Description Exchange Format http://www.ietf.org/rfc/rfc5070.txt ↩

  8. 以下のブログエントリではDuquのIOCの作成プロセスを解説している。 / Creating an IOC to Spot the Duqu Family https://blog.mandiant.com/archives/2074 ↩

-
 
カテゴリー :
技術解説   セキュリティ事件  
タグ :
Malware   Forensics   Targeted Attack  
この記事のURL :
https://sect.iij.ad.jp/d/2012/02/278431.html