kevoreilly/capev2マルウェア設定とペイロード抽出
サンドボックスは、悪意のあるファイルを隔離された環境で実行し、 その動的挙動を計測しながらフォレンジックアーティファクトを収集するために使用されます。
CAPE は Cuckoo v1 から派生したもので、Windows プラットフォーム上で以下の 中核機能を備えています:
CAPE は Cuckoo の従来のサンドボックス出力に、いくつかの重要な追加機能を加えています:
誰でも利用できる無料のデモインスタンスがオンラインにあります:
https://capesandbox.com - アカウントの有効化については https://twitter.com/capesandbox までご連絡ください
Cuckoo Sandbox は 2010 年に The Honeynet Project 内の Google Summer of Code プロジェクトとして始まりました。当初は Claudio Guarnieri によって設計・開発され、 最初のベータ版は 2011 年に公開されました。2014 年 1 月には Cuckoo v1.0 が リリースされました。
2015 年は転換点となる年であり、Cuckoo の歴史における大きな分岐点となりました。
オリジナルのモニターと API フッキング手法の開発は、Cuckoo のメインプロジェクトでは
停止されました。それは Jurriaan Bremer によって作成された、Linux ツールチェーンで
コンパイルされる restructuredText ベースのシグネチャ形式を使用する
代替モニターに置き換えられました。
ほぼ同じ時期に、Brad 'Spender' Spengler によって Cuckoo-modified と呼ばれる フォークが作成され、オリジナルのモニターの開発が継続されました。これには 64 ビット サポートや、重要なことに Microsoft の Visual Studio コンパイラの導入など、 大幅な改善が含まれていました。
同じ年の間に、Context Information Security において Kevin O'Reilly によって、 動的なコマンドライン設定およびペイロード抽出ツールである CAPE の開発が始まりました。 この名前は「Config And Payload Extraction」の頭字語として作られ、当初の研究は Microsoft の Detours ライブラリが提供する API フックを使用して、アンパックされたマルウェアペイロードと設定をキャプチャすることに 焦点を当てていました。しかし、API フックだけでは、任意のマルウェアからペイロードや 設定をアンパックするのに十分な能力と精度を提供できないことが明らかになりました。
このため、Microsoft のデバッグインターフェースの使用を避けつつ、可能な限り ステルス性を保ちながらマルウェアを正確に制御・計測できる、新しいデバッガの概念の 研究が始まりました。このデバッガは Detours ベースの概念実証コマンドラインツールに 統合され、API フックと組み合わさることで、非常に強力な機能をもたらしました。
初期の作業により、Microsoft Detours を Cuckoo-modified の API フッキングエンジンで 置き換えることが可能であることが示されたとき、CAPE Sandbox のアイデアが生まれました。 デバッガ、自動アンパッキング、YARA ベースの分類、統合された設定抽出の追加により、 2016 年 9 月の 44con において、CAPE Sandbox が初めて公開リリースされました: CAPE バージョン 1 です。
2018 年の夏、このプロジェクトは長年の Cuckoo コントリビューターである Andriy 'doomedraven' Brukhovetskyy による多大な貢献の始まりという幸運に恵まれました。 2019 年には彼は CAPE を Python 3 に移植するという膨大な作業を開始し、その年の 10 月に CAPEv2 がリリースされました。
CAPE は、マルウェアとオペレーティングシステムの両方の能力の進歩に追いつくため、 継続的に開発・改善されてきました。2021 年には、動的な YARA スキャンを通じて デトネーション中に CAPE のデバッガをプログラムする機能が追加され、 アンチサンドボックス技術に対する動的なバイパスを作成できるようになりました。 Windows 10 がデフォルトのオペレーティングシステムとなり、その他の重要な追加機能には インタラクティブデスクトップ、AMSI (Anti-Malware Scan Interface) ペイロードキャプチャ、 Microsoft Nirvana に基づく「syscall フッキング」、デバッガベースの直接/間接 syscall 対抗手段などがあります。
2024 年には enzok が CAPEsolo を作成しました。 これは CAPE のインタラクティブな Windows デスクトップ版であり、グラフィカル インターフェースに wxPython を使用し、さらに 64 ビットゲスト Python 互換性を 導入しました。2026 年には、すべての Windows 10 バージョンと Windows 11 23H2 への サポートが追加されました。
CAPE では、マルウェアを 3 つのメカニズムで分類できます:
パースは CAPE 独自のフレームワークを使用して行えます。あるいは、以下の フレームワークがサポートされています: RATDecoders、DC3-MWCP、MalDuck、または MaCo
CAPE のコアおよびコミュニティの設定パーサーは、別の
CAPE-parsers リポジトリで
維持されており、CAPE-parsers 依存関係としてインストールされます。
これらのパーサーへの追加や修正はそちらに提出してください。その README に
期待される設定フィールドが記載されています。
def extract_config(data): を持ち、cape_utils.py から呼び出される CAPE のフレームワークを使用することをお勧めします。複雑な点は 0 です。
CAPE は、アンパックされたペイロードをキャプチャできるようにするために、 多くのマルウェア技術や挙動を活用しています:
これらの挙動により、さらなる分析のために、インジェクト、抽出、または展開された ペイロードがキャプチャされます。さらに CAPE は、各プロセスのプロセスダンプ、 または DLL の場合はメモリ内の DLL のモジュールイメージを自動的に作成します。 これは、単純なパッカーでパックされたサンプルに役立ちます。多くの場合、 モジュールイメージダンプは完全にアンパックされています。
CAPE のデフォルトの「パッシブ」アンパッキングメカニズムに加えて、
「アクティブ」アンパッキングを有効にすることが可能です。これはブレークポイントを
使用して、新しく割り当てられた、または保護されたメモリ領域への書き込みを検出し、
実行前にできるだけ早くアンパックされたペイロードをキャプチャします。これは
Web 送信のチェックボックス、またはオプション unpacker=2 を指定することで
有効になり、デトネーション品質に影響を与える可能性があるため、デフォルトでは
オフになっています。
CAPE は、特定のパッカーをアンパックするために YARA シグネチャ経由で プログラムできます。例えば、UPX タイプのパッカーは非常に一般的であり、 CAPE ではこれらはパッシブにアンパックされたペイロードのキャプチャにつながりますが、 デフォルトのキャプチャはアンパックされたペイロードが実行を開始した後に行われます。 したがって、カスタム YARA シグネチャによって UPX 由来のパッカーを動的に検出し、 最後のパッカー命令にブレークポイントを設定することで、ペイロードが実行を開始する前の 元のエントリポイント (OEP) でキャプチャすることが可能です。
dump-on-api オプションを使用すると、Web インターフェースで指定できる特定の
API 関数 (例: dump-on-api=DnsQuery_A) を呼び出したときにモジュールを
ダンプできます。
デバッガにより、CAPE は元の能力を超えて進化し続けることができ、現在では 動的なアンチ回避バイパスも含まれています。現代のマルウェアは一般に、例えば 仮想化のためのタイミングトラップや API フック検出を使用して、サンドボックス内での 分析を回避しようとするため、CAPE では YARA シグネチャ内のデバッガアクションを 組み合わせて、デトネーション中に回避型マルウェアを検出し、制御フロー操作を 実行してサンプルを完全にデトネートさせるか、回避アクションをスキップさせる 動的な対抗手段を開発できます。
デバッガへのクイックアクセスは、送信オプション bp0 から bp3 で可能になり、
ブレークポイントを設定するために RVA または VA 値を受け付けます。その際、
count および depth オプションによって制御される短い命令トレースが出力されます
(例: bp0=0x1234,depth=1,count=100)。
モジュールのエントリポイントにブレークポイントを設定するには、アドレスの代わりに
ep を使用します (例: bp0=ep)。あるいは break-on-return を使用すると、
フックされた API の戻りアドレスにブレークポイントを設定できます
(例: break-on-return=NtGetContextThread)。オプションの base-on-api パラメータ
を使用すると、RVA ブレークポイントのイメージベースを API 呼び出しによって設定できます
(例: base-on-api=NtReadFile,bp0=0x2345)。
オプション action0 - action3 を使用すると、ブレークポイントにヒットしたときに
実行するアクションを指定できます。例えば、メモリ領域のダンプ
(例: action0=dumpebx) や実行制御フローの変更 (例: action1=skip) などです。
CAPE のドキュメントには、そのようなアクションのさらなる例が含まれています。
CAPE のモニターのコードを含むリポジトリは別にあります。
CAPE コミュニティによって開発された数百のシグネチャを含む、コミュニティの シグネチャリポジトリがあります。すべての新しいコミュニティ機能はそのリポジトリに プッシュする必要があります。その後、開発者がそれらを維持できる場合はコアに 移動させることができます。
さらに多くのマルウェアファミリ向けの新しいシグネチャ、パーサー、またはバイパスの 作成を手伝うことで、このプロジェクトに貢献してください。現在多くのものが進行中です ので、このスペースにご注目ください。
CAPE を単独で Python 3 に移植してくれた @D00m3dR4v3n に多大な感謝を申し上げます。