インシデントレスポンスサービスを支えるOSINT-DB

経営企画部 マネージドセキュリティサービス推進室の細谷です。私が所属するインシデントレスポンスチームでは、攻撃の被害に遭ってしまったお客様を対象としたインシデントレスポンスサービス（インシデント全容解明・再発防止策の提示）を提供しています。

今回は、インシデントレスポンスチームで構築したOSINT¹のデータベース（通称、OSINT-DB）を紹介します。

OSINT-DBとは？

OSINT-DBは、主にWeb上に公開されている悪性URLやハッシュ値などの脅威情報を予め収集し、インシデントレスポンスの案件対応時に検索できる弊社独自のデータベースです。OSINT-DBを活用することで、インシデントレスポンス時に見つけたURLやハッシュ値を最新の脅威情報と照らし合わせ、悪性かどうかを瞬時に判断することができます。その結果、既知のばらまき型マルウェアなどの早期発見や、解析時間の大幅な短縮につながります。
また、弊社のOSINT-DBでは、Web上に公開されている脅威情報だけでなく、NTTのセキュアプラットフォーム研究所による独自技術で作成した脅威情報も格納しています。

なぜOSINT-DBが必要なのか？

インシデントレスポンス時に見つけたURLやハッシュ値が悪性であるかを判断する上で、OSINTの情報を参照することがあります。OSINTは、調査効率を向上させる手法として知られています。しかし、OSINTの情報を参照するには、悪性URLを提供する脅威フィードや、ブログ、SNSなど多くの情報源を見に行く必要があり、目的の情報にたどり着くまでに時間がかかってしまう場合があります。
また、インシデントレスポンス時に発見するURLやハッシュ値は大量にあり、そのすべてを手動で調査するにはかなりの時間と労力が必要になります。

このような課題を解決するために、以下のようなデータベースが必要になりました。

• 調査に適した複数のOSINT情報源が一つにまとまっている
• 大量のURLやハッシュ値を高速に一斉検索できる

これらの要件を満たすOSINT-DBによって、以下の図のように、解析者が検索を行う回数を格段に減らすことができます。以降の節では、OSINT-DBの仕組みについてさらっと触れたいと思います。

どこから情報を収集している？

セキュリティの脅威情報は、様々な形で公開されています。悪性のURLやハッシュ値をリストとして提供している脅威フィードだけでなく、Twitterやブログで公開されているものもあります。
OSINT-DBは、大きく分けて以下５つの情報源からデータを収集しています。

• Twitter：Twitterで公開されている脅威情報を収集します。
  （例：UrsnifというマルウェアのIOCに関するツイート https://twitter.com/w3ndige/status/1183799724979249152 ）

• ブログ：ブログで公開されている脅威情報を収集します。
  （例：Kaspersky Labのブログに記載されている「IOCs」 https://securelist.com/ransomware-two-pieces-of-good-news/93355/ ）

• 脅威フィード：URLHausやMalshareといったサイトで公開されている脅威情報を収集します。
  （例：URLhausという悪性URL提供サイト https://urlhaus.abuse.ch/browse/ ）

• Github： Githubのリポジトリから脅威情報を収集します。
  （例：Fireeyeのiocs https://github.com/fireeye/iocs ）

• NTTのセキュアプラットフォーム研究所から提供されている悪性URL/ドメイン（非公開情報）：NTTの独自技術によって生成された脅威情報を収集します。

どうやって収集している？

収集対象の情報源に応じて、オリジナルのクローラを実装しています。例えば、Twitterに対するクローラは、TwitterのAPIを用いて#malwareや#ursnifなどのハッシュタグの検索結果を取得します。また、ブログに対するクローラは、RSSフィードの更新状況を確認して最新のブログの情報を取得しています。

クローラが収集した情報から悪性URLやハッシュ値を抽出する処理には、InQuestが提供しているThreatIngestorというツールを使用しています。このツールを用いることで、Defang²された文字列をRefang²した状態で抽出できます。ThreatIngestorには、本来クローリングの機能がありますが、カスタマイズ性を高めるためにその機能は使用せず、上述したオリジナルのクローラを実装しています。

こちらの収集方法については、次の機会に詳しく説明できればと思います。

どう使っている？

最後に、OSINT-DBの使用例を紹介します。
例として、2019年10月16日のFireEye社によるブログで紹介された、APT41³という攻撃者グループによるマルウェア感染のインシデントを想定します（こちらは我々が実際に対応した例ではなく、仮の例になります）。この時、フォレンジックやログ解析で見つかったドメインを、PythonのスクリプトでOSINT-DBから検索します。
以下の図は、checkin.travelsanignacio[.]comというドメインの検索結果になります。検索はコマンドラインで行うので、grepといったその他のコマンドと組み合わせて使用することができます。また、出力される結果はTSV形式で、それぞれの行が検索にヒットした悪性URL/ドメインの情報を示しています。
解析者は、各行に示される情報源のリンクから、検索にヒットしたURL/ドメインがFireEye社のブログに載っていることが判明します。結果的に、見つけたドメインがAPT41による攻撃の痕跡であることが判明します。

今回の例では、簡単のため1つのドメインのみを対象に検索しましたが、実際にはコマンドラインのオプションを変えることで、複数のドメインやURL、ハッシュ値を一斉検索することができます。

まとめ

本記事では、インシデントレスポンスチームで活用しているOSINT-DBを紹介しました。インシデントレスポンスにおいて、OSINT活用は調査効率を向上させる反面、様々な情報源を参照する必要があるため、調査にはかなりの時間と労力が必要になります。このOSINT-DBを使うことによって、短時間で、かつ複数の痕跡の情報源を突き止めることができます。インシデントレスポンスチームでは、このようなオリジナルの解析補助ツールを他にも多く作成しており、高品質で迅速なインシデント対応を実現しています。

最近では、ファストフォレンジックス（調査する痕跡情報を一部に絞ることで、より迅速な調査を行う手法）の必要性が高まっています。それに伴い、近年、システムから調査価値の高い痕跡を抽出するファストフォレンジックツールが多数登場しています。一方で、OSINT-DB等、調査自体を高速化するツールの整備も同様に必要と言えるでしょう。

最後までご覧いただき、ありがとうございました。インシデントレスポンスチームによる次回の投稿では、インシデントの対応事例を紹介したいと思います。