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対策などがあります。
CAPEでは、以下の3つのメカニズムでマルウェアを分類できます。
解析はCAPE独自のフレームワークを使用して行うことができます。または、以下のフレームワークもサポートされています：RATDecoders、DC3-MWCP、MalDuck、MaCo
def extract_config(data): を持つ純粋なPythonであり、cape_utils.py によって呼び出され、複雑さがゼロのCAPEのフレームワークを使用することをお勧めします。
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 パラメータを使用すると、API呼び出しによってRVAブレークポイントのイメージベースを設定できます（例：base-on-api=NtReadFile,bp0=0x2345）。
action0 から action3 のオプションを使用すると、ブレークポイントがヒットしたときにアクションを実行できます。例えば、メモリ領域のダンプ（例：action0=dumpebx）や実行制御フローの変更（例：action1=skip）などです。CAPEのドキュメントには、このようなアクションのさらなる例が含まれています。
CAPEのモニターのコードを含むリポジトリは別途あります。
CAPEコミュニティによって開発された数百のシグネチャを含むコミュニティリポジトリがあります。新しいコミュニティ機能はすべてそのリポジトリにプッシュする必要があります。その後、開発者がメンテナンス可能で意欲があればコアに移動できます。
シグネチャ、パーサー、またはさらなるマルウェアファミリーのバイパスの作成を支援して、このプロジェクトに貢献してください。現在も多くの作業が進行中ですので、ご注目ください。
Python 3へのCAPEの移植を一手に引き受けてくださった @D00m3dR4v3n に心から感謝します。
Python3
rooter のみを root として実行し、残りは cape ユーザーとして実行してください。rootで実行するとパーミッションが乱れます。
conf フォルダ内の すべての 設定ファイルを 必ず読んでください。kvm-qemu.sh と cape2.sh は、ssh 接続が切れた場合のOSの問題を防ぐために tmux セッションから実行する 必要があります。<username> を実際のパターンに置き換えてください。<WOOT> を内部で置き換える必要があります！sudo ./kvm-qemu.sh all <username> 2>&1 | tee kvm-qemu.logsudo ./cape2.sh base 2>&1 | tee cape.logconf フォルダ内の設定ファイルを変更してCAPEを設定します。systemctl restart <サービス名> を使用しますjournalctl -u <サービス名> を使用します-h で確認してください。デバッグモード（-d）でサービスを実行することも役立ちます。-h が含まれていますが、スクリプトを確認して 理解 してください。git pullpython3 utils/community.py -waf 実行前に -h を確認して理解してくださいgit add --all
git commit -m '[STASH]'
git pull --rebase origin master
# 必要に応じて競合を修正（rebase）
git reset HEAD~1
# kevoreillyリポジトリがリモートとして追加されていることを確認（一度だけ必要）
git remote add kevoreilly https://github.com/kevoreilly/CAPEv2.git
# マージ予定のブランチにすべての変更がコミットされていることを確認
git commit -a -m '<コミットメッセージをここに記入>'
# kevoreillyリポジトリから変更を取得
git fetch kevoreilly
# kevoreilly masterブランチを現在のブランチにマージ
git merge kevoreilly/master
# 必要に応じてマージ競合を修正
# 必要に応じてリポジトリにプッシュ
git push
CAPEv2を研究で使用する場合は、GitHubメニューの「Cite this repository」で指定されている方法で引用してください。
pefile を使用するものは、各バージョンが固定されているため頭痛の種になります。
pefile の依存関係を削除することをお勧めします。すでにインストール済みです。これで問題はなくなります。