Malware Debugs Itself to Prevent Analysis by Joe Darbyshire 2019年4月9日 より
最近、Twitterへの投稿を介してあるマルウェアに遭遇しましたが、特にそれが目を引いたのは、私たちの製品に関連したフォルダを検索しているように見えたからでした。解析を続けたところ、このマルウェアが、デバッガーを使ったリバースエンジニアリングを回避するという新しい手法を取り入れていることに気づきました。そして、他のマルウェアが同じような手口を使って脅威の解析や研究をする関係者の仕事の妨げとなることがないよう、これについて書いておかねばと思ったのです。
Procmon(訳注：MS社が提供するプロセス表示ツール)を用いた基本的な解析では、このマルウェアが大部分の動作を実行される、子プロセスとして自身を再起動させていることが示されます。しかし、私たちが詳細を見るためこの子プロセスにデバッガーを接続しようとすると、下のようなエラーが発生します。
“デバッガーは選択されたプロセスにアタッチすることができませんでした。プロセスが終了したか、必要な権限をもっていない可能性があります。”
これは、親プロセスによりCreateProcessに渡されるフラグで説明することができます。このマルウェアが子プロセスとして再起動される際には、指定されたDEBUG_ONLY_THIS_PROCESS フラグが指定されます。これにより、親プロセスは子プロセスのデバッガーとして動作することになり、解析者が自分自身のデバッガーを接続して実際に何が行われているかの詳細を見る妨げになります。
さらに、親プロセスはWaitForDebugEvent を使って子プロセスの動作を監視しながら巡回して、ContinueDebugEvent API が親プロセスと子プロセスの間に相互の依存関係を確立して他のデバッガーの入る余地をなくすよう要請します。
子プロセスに直接デバッガーを接続することが不可能であるため、次善の策は、子プロセスのメモリーダンプを実行し、これを代わりに解析することです。ですが、マルウェアはこのような手段に対しても用意周到で、これをさらに困難にする措置をとっているのです。
子プロセスを、そのデバッグを行うために設定された親プロセスと共に起動させた後、子プロセスは自身のメモリ領域に設定されたNO_ACCESSフラグでVirtualProtectExを呼び出します。つまり、この領域で行われる読み取り、書き込み、実行などあらゆる動作は、アクセス侵害の例外となるのです。
ただし、こうした例外が親プロセスに送られると、親プロセスがこれをデバグしているため、この例外は、EXECUTE_READWRITEに設定されているフラグのあるセクションで再びVirtualProtectExを呼び出すことにより親プロセスで処理され、一時的に実行可能となります。その後、ダンピングを避けるため、メモリは再びNO_ACCESSに設定し直されます。
幸いなことに、我々はIDAを使ってVirtualProtectEx に渡された変数にパッチを当ててNO_ACCESS フラグをEXECUTE_READWRITE フラグに変え、子プロセスのすべてのメモリーダンプが有効となるようにすることで、これを克服することができます。
新しいメモリーダンプを使えるようにすれば、マルウェアの動作に対応することがずっと容易になります。
お判りのように、マルウェアは侵入されたエンドポイントから暗号化ウォレットを盗み出そうと狙っています。さらに、APIコールを追跡することで、Bromium Secure Browserを含む多様なブラウザから、保存されたログインの資格情報とクッキーを検索していることもわかります。
Bromiumはすべての文書やブラウザセッションを安全な、隔離された環境で実行しているため、この種の攻撃は、Bromium で保護されたエンドポイントに対しては効果がありません。つまり、このマルウェアが検索している重要な情報はアクセス不能であり、しかもマルウェアは、セッションが閉じられてしまえば、存続することができなくなるのです。
本和訳文の著作権は株式会社ブロードに帰属します。