Hide and seek――Citadelの解析から見る近年のマルウェア動向：セキュリティ業界、1440度（8）（2/2 ページ）

[株式会社FFRI，＠IT]

Citadelマルウェアが利用する端末固有情報

　PCに感染したCitadelマルウェアは、起動する際に端末の固有情報を確認します。確認の結果、感染したPCとは別のPCで動作していることが判明した場合にはプロセスを終了させ、その後の動作を行いません。これにより、検体を回収してもそのままでは実行することができず、解析が困難になっているという現状があります。

　Citadelマルウェアが利用する固有情報は以下の2種類となっています。

• Citadelマルウェアが感染するファイルパス
• ドライブのボリュームGUID

　Citadelマルウェアは感染すると自分自身を以下のパスに格納します。

C:\Users\<ユーザー名>\AppData\Roaming\<ランダム文字列>\<ランダム文字列>.exe

　Citadelマルウェアは起動すると、自分自身が起動したファイルのパスをチェックし、上記のパスと同一かどうかのチェックを行います。チェックに用いるパスの情報は、感染時にCitadelマルウェア本体中に埋め込まれていますので、その内容と起動時に取得した情報とを比較します。この結果、パスが異なる場合には起動しないという挙動となっています。

　またWindowsでは、接続されているハードディスクドライブごとに以下のようなボリューム名が付けられています。

\\?\Volume{aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee}\

　上記の“{”と“}”の間の部分に設定されているGUIDを取得し、端末固有の情報として利用しています。GUIDは「グローバル一意識別子」と呼ばれ、一意の値となるため、対象の端末固有の情報として使用することができます。

　Citadelマルウェアは、感染時に、感染先のファイルパスとGUID値をあらかじめマルウェアの中に埋め込みます。マルウェアは、起動時に取得した情報と格納された情報を比較することで、動作している端末が感染PCかどうかの判断を行っています。

解析環境の検出機能

　Citadelマルウェアには、解析を困難にさせる目的で、解析環境を検出する機能が搭載されています。解析環境を検出する機能にも追加が行われているようで、入手経路A、Bで入手したCitadelマルウェアと入手経路Cで入手したCitadelマルウェアとでは、解析環境検出機能に違いがありました。

　入手経路A、Bに実装されている解析環境検出機能では、動作中のプロセス一覧を取得し、特定のプロセスが動作していないかどうかをチェックをする機能が実装されています。チェック対象となっているプロセスは、VMwareやVirtualBox、BufferZoneやJoeSandboxのような仮想化関連、サンドボックス関連製品のプロセスとなります。

　入手経路Cに実装されている解析環境検出機能では、入手経路A、Bに実装されているものに加えて、特定ファイル、レジストリ、ミューテックス、DLLなどの存在確認が行われています。

　確認処理部分は下図のようになっています。実際のチェック関数自体は、関数ポインターの形式で保持されており、0x045A16D9のcall命令でチェック関数を順次呼び出す形式になっています。この実装形式の場合、チェック関数は個別に実装可能ですので、チェック関数の追加が容易です。今後、チェック処理がさらに強化されたマルウェアが出てくると想定できます。

図4　入手経路のCitadelマルウェアの確認処理部分

　これらの解析環境検出によってマルウェアが解析されていると判断した場合、その時点で処理を終了するのではなく、ダミーのURLへアクセスするようになっています。ダミーのURLは環境固有の情報を元に生成しています。そのため、解析側としては通信が発生していると勘違いして解析を続けてしまう可能性があります。

まとめ〜解析機能とのいたちごっこ

　今回は、Citadelマルウェアに実装されている解析を困難にする対策について説明しました。近年サンドボックス製品などのように自動解析を行う製品が増えてきていることから、マルウェア側としても自動解析環境を検出する機能が実装されてきていることが分かりました。

　また、感染対象のPCにカスタマイズした形で感染することから、パターンベースでの検知も困難になってきています。ユーザーが感染しないように対策する場合、OSやアプリケーションを最新バージョンにしておくことや、振る舞い検知ロジックを搭載したアンチウイルス製品などの導入などが必要になってくるかと思います。

「セキュリティ業界、1440度」バックナンバー

• 初のiPhone個人Jailbreaker、ホッツ氏が語る「OSSによる自動車の自動運転化」――CODE BLUE 2017レポート
• 20年以上前のネットワーク規格が自動車や人命をセキュリティリスクにさらす
• 日本初の自動車セキュリティハッカソンも――「escar Asia 2016」レポート
• 「車載セキュリティ」研究の最前線――「2016年 暗号と情報セキュリティシンポジウム（SCIS2016）」レポート
• 著名バグハンターが明かした「脆弱性の見つけ方」――「CODE BLUE 2015」リポート
• クルマのハッキング対策カンファレンス「escar Asia 2015」リポート
• 「CSS／MWS 2015」に向けた3000件のマルウエア解析から得られた発見とは？
• エンジニアよ、一次情報の発信者たれ――Black Hat Asia 2015リポート
• 自動車、ホームルーター、チケット発券機――脅威からどう守る？
• 高度なマルウェアを解析するには“触診”が一番？ 「PacSec 2014」リポート
• マルウェア捕獲後、フリーズドライに？「Black Hat Europe 2014」に参加してきた
• セキュリティ・キャンプ卒業後に何をしたいか、してほしいか
• 講師も悩む――セキュリティ・キャンプ「選考」のやり方
• Hide and seek――Citadelの解析から見る近年のマルウェア動向
• 自動車の守り方を考える「escar Asia 2014」レポート
• CODE BLUE――日本発のサイバーセキュリティカンファレンスの価値
• 自動車もサイバー攻撃の対象に？「Automotive World 2014」レポート
• 機械学習時代がやってくる――いいソフトウェアとマルウェアの違いは？
• 沖縄の地でセキュリティを学ぶ「セキュリティ・ミニキャンプ in 沖縄」レポート
• PacSec 2013 レポート 2日目〜Chromeの守り方、マルウェアの見つけ方
• PacSec 2013 レポート 1日目〜任意のコードをBIOSに

株式会社FFRI

FFRIは日本においてトップレベルのセキュリティリサーチチームを作り、IT社会に貢献すべく2007年に設立。日々進化しているサイバー攻撃技術を独自の視点で分析し、日本国内で対策技術の研究開発に取り組んでいる。その研究内容は国際的なセキュリティカンファレンスで継続的に発表し、海外でも高い評価を受けており、これらの研究から得た知見やノウハウを製品やサービスとして提供している。