Red Teamインフラストラクチャの堅牢化リソースを収集するためのWiki
このWikiは、堅牢なRed Teamインフラストラクチャを構築するためのリソースを提供することを目的としています。Steve Borosh（@424f424f）とJeff Dimmock（@bluscreenofjeff）によるBSides NoVa 2017の講演「Doomsday Preppers: Fortifying Your Red Team Infrastructure」（スライド）を補完するために作成されました。
追加したい内容がある場合は、Pull Requestを送信するか、リポジトリにIssueを登録してください。
このWikiで参照されているコンテンツのすべての著者と、貢献してくださったすべての方々に感謝します！
アクティブな対応に耐え、長期間（数週間、数ヶ月、数年間）のエンゲージメントに耐えるRed Teamインフラストラクチャを設計する際には、各アセットを機能に基づいて分離することが重要です。これにより、キャンペーンアセットが検出され始めたときに、Blue Teamに対する回復力と機動性が提供されます。たとえば、評価のフィッシングメールが特定された場合、Red Teamはチームサーバー全体をセットアップするのではなく、新しいSMTPサーバーとペイロードホスティングサーバーを作成するだけで済みます。
以下の機能を異なるアセットで分離することを検討してください：
これらの各機能は、各ソーシャルエンジニアリングキャンペーンで必要になる可能性があります。Red Team評価ではアクティブなインシデント対応が一般的であるため、各キャンペーンごとに新しいインフラストラクチャ一式を実装する必要があります。
回復力と秘匿性をさらに高めるために、すべてのバックエンドアセット（つまりチームサーバー）の前にリダイレクタを配置する必要があります。目標は、ターゲットとバックエンドサーバーの間に常にホストを置くことです。この方法でインフラストラクチャを設定すると、新しいインフラストラクチャを迅速かつ簡単に展開できます。新しいチームサーバーを立ち上げたり、セッションを移行したり、バックエンドで焼けていないアセットを再接続したりする必要はありません。
一般的なリダイレクタの種類：
各リダイレクタタイプには、さまざまなシナリオに最適な複数の実装オプションがあります。これらのオプションについては、Wikiのリダイレクタセクションで詳しく説明しています。リダイレクタは、VPSホスト、専用サーバー、またはPlatform-as-a-Serviceインスタンスで実行されるアプリにすることもできます。
機能的分離とリダイレクタの使用を考慮したサンプル設計は次のとおりです：
Digital OceanでC2インフラストラクチャを構築する方法 – パート1 - Lee Kagan（@invokethreatguy）
Terraformによる自動化されたRed Teamインフラストラクチャデプロイメント - パート1 - Rasta Mouse（@_RastaMouse）
認識されるドメインの評判は、ターゲットが使用している製品とその構成によって大きく異なります。そのため、ターゲットで機能するドメインを選択することは正確な科学ではありません。オープンソースインテリジェンス収集（OSINT）は、コントロールの状態を最善の推測を行い、ドメインを照合するリソースを決定する上で重要になります。幸いなことに、オンライン広告主も同じ問題に直面しており、活用できるソリューションをいくつか作成しています。
expireddomains.netは、最近失効または削除されたドメインの検索エンジンです。失効からの経過期間、バックリンク数、Archive.orgスナップショット数、SimilarWebスコアなどの検索と高度なフィルタリングを提供します。このサイトを使用すると、ドメイン年齢を持つ既使用ドメインを登録でき、ターゲットに似ているもの、なりすましに似ているもの、または単にターゲットのネットワークに溶け込む可能性が高いものを選択できます。
C2またはデータ流出用のドメインを選択する場合は、FinanceまたはHealthcareに分類されたドメインを選択することを検討してください。多くの組織は、法的またはデータ機密性の問題の可能性があるため、これらのカテゴリに対してSSLミドリングを実行しません。選択したドメインが以前のマルウェアやフィッシングキャンペーンに関連付けられていないことも確認することが重要です。
Charles Hamilton（@MrUn1k0d3r）によるツールCatMyFishは、expireddomains.netとBlueCoatを使用した検索とWebカテゴリ分類チェックを自動化します。検索にさらにフィルターを適用したり、登録したアセットの長期的な監視を実行したりするように変更できます。
Joe Vest（@joevest）とAndrew Chiles（@andrewchiles）による別のツールDomainHunterは、BlueCoat/WebPulse、IBM X-Force、Cisco Talosのカテゴリ分類、ドメイン年齢、代替利用可能TLD、Archive.orgリンク、HTMLレポートを返します。さらに、Malwaredomains.comとMXToolBoxを使用して、既知のマルウェアおよびフィッシングキャンペーンでの使用をチェックします。このツールには、BlueCoat/WebPulseのCAPTCHAをバイパスするためのOCRサポートも含まれています。ツールの初期リリースの詳細については、ブログ投稿を確認してください。
さらに別のツールとして、Max Harley（@Max_68）によるAIRMASTERは、expireddomains.netとBluecoatを使用して分類されたドメインを見つけます。このツールはOCRを使用してBlueCoatのCAPTCHAをバイパスし、検索速度を向上させます。
以前に登録されたドメインが利用できない場合、または自己登録ドメインを希望する場合は、ドメインを自分で分類することが可能です。以下の直接リンクまたはDominic Chell（@domchell）によるChameleonのようなツールを使用してください。ほとんどのカテゴリ分類製品は、ドメインのカテゴリ分類を決定する際にリダイレクトやクローンされたコンテンツを見落とします。Chameleonの使用法の詳細については、Dominicの投稿Categorisation is not a security boundaryを確認してください。
最後に、DNS設定が正しく伝播していることを確認してください。
「簡単」と「フィッシング」という言葉は、実際にはなかなか一緒にならないものです。適切なフィッシングインフラストラクチャをセットアップすることは、本当に面倒な場合があります。次のチュートリアルでは、現在の「ほとんどの」スパムフィルターを通過し、ターゲットとの双方向通信を含む簡単なフィッシング体験のためのRoundCubeインターフェースを提供するフィッシングサーバーを迅速にセットアップするための知識とツールを提供します。フィッシングに関するセットアップや投稿は数多くあります。これはそのうちの1つの方法にすぎません。
前のセクションでリストされた適切なチェックを通過するドメインを取得し、フィッシングサーバーを起動したら、図のようにドメイン用にいくつかの「A」レコードを作成する必要があります。
次に、フィッシングサーバーにsshで接続し、/etc/hostsに適切なFQDNホスト名がリストされていることを確認します。 例：「127.0.0.1 email.yourphishingserver.com email localhost」
次に、わずか数ステップでフィッシング用のWebフロントエンドをインストールします。まず、最新の「BETA」バージョンのiRedMailをフィッシングサーバーにダウンロードします。簡単な方法は、ダウンロードボタンを右クリックしてリンクアドレスをコピーし、wgetを使用してフィッシングサーバーに直接ダウンロードすることです。次に、「tar -xvf iRedMail-0.9.8-beta2.tar.bz2」で解凍します。解凍したフォルダーに移動し、iRedMail.shスクリプトを実行可能にします（chmod +x iRedMail.sh）。rootとしてスクリプトを実行し、プロンプトに従い、すべてを完了するには再起動が必要です。
メールサーバーを指す適切なDNSレコードがすべて揃っていることを確認してください。（https://docs.iredmail.org/setup.dns.html）。DKIMの場合、新しいコマンドは「amavisd-new showkeys」でDKIMキーを一覧表示します。
DMARCについては、（https://www.unlocktheinbox.com/dmarcwizard/）を使用してDMARCエントリを生成できます。
次に、フィッシングに使用するユーザーを作成します。
新しいユーザーでRoundCubeインターフェースにログインし、責任を持ってフィッシングを実行してください！
Cobalt Strikeは、ペンテストまたはRed Teamのメールフィッシングをサポートするカスタマイズ可能なスピアフィッシング機能を提供します。HTMLおよび/またはプレーンテキスト形式のテンプレート、添付ファイル、バウンスバックアドレス、URL埋め込み、リモートSMTPサーバーの使用、メッセージごとの送信遅延をサポートしています。もう1つの興味深い機能は、クリック追跡のために各ユーザーの埋め込みURLに一意のトークンを追加できることです。
詳細については、以下のリソースを確認してください：
クライアントの信頼とOPSECが重要となるRed Teamおよびフィッシング演習では、取得したクライアントデータと主要なインフラストラクチャを顧客自身のサーバー（オンプレミス）に保持することで、クラウドのみのソリューションに比べて大きな利点が得られます。このアプローチでは、クラウドアセットをシンリダイレクタとフロントにのみ使用し、機密性の高い運用は内部で維持します。
堅牢なオンプレミスEvilginxセットアップは、通常次のもので構成されます：
Cookieゲーティングは、フィッシングポータルにアクセスするために特定のCookieを要求することで、ボットヒットと自動スキャンを減らします：``` (http.host eq "portal.example.com") and (not http.cookie contains "session_token=abc123def456") and not (http.host eq "landing.example.com" and http.request.uri.path eq "/favicon.ico")
このルールは、必要なCookieを含まないポータルドメインへのリクエストをリダイレクトし、リダイレクトループを防ぐためにfaviconリクエストを除外します。
### Caddy設定のサンプル```caddyfile
# Redirect direct IP access to prevent fingerprinting
1.2.3.4 {
redir https://legitimate-site.com{uri} permanent
}
landing.example.com {
log {
output file /var/log/caddy/landing_access.log
format console
}
tls internal
encode gzip
reverse_proxy http://127.0.0.1:8000
}
portal.example.com {
log {
output file /var/log/caddy/portal_access.log
format console
}
tls internal
encode gzip
reverse_proxy https://evilginx:443 {
transport http {
versions 1.1
tls_insecure_skip_verify
tls_server_name portal.example.com
}
header_up Host portal.example.com
header_up X-Forwarded-Proto https
}
}
内部ノード上で適切なフラグを指定して Evilginx を実行します:```bash ./evilginx2 -p ./phishlets -t ./redirectors -developer -debug
**重要:** Evilginx はプライベートネットワーク内からのみ到達可能にすべきです。そのIPを公開DNSに公開しないでください。
### OPSECと堅牢化チェックリスト
1. **EvilginxのIPを公開DNSに公開しない** - プライベートネットワークのみを使用する
2. **機密データはクライアントサーバーにのみ保持する** - リダイレクタは取得した認証情報を保存してはならない
3. **リダイレクタを堅牢化する** - ドメインをローテーションし、短いTTLを使用し、複数の一時的なリダイレクタを展開する
4. **WAF/ファイアウォールルールを実装する** - クッキーチェック、IP許可リスト、またはUA検証を使用する
5. **ログと保持を分離する** - アクセスログはCaddyに、キャプチャログはEvilginxホストに保持する
6. **フィンガープリントを避ける** - 予測可能なパターンや同一のTLSフィンガープリントを使用しない
このハイブリッドアプローチ（公開リダイレクタ/プライベートキャプチャ）は、クラウドフロンティングの回復力を提供しながら、機密性の高い運用をオンプレミスに保つことでセキュリティと法的な利点を維持します。
## フィッシングフレームワーク
独自のフィッシング環境を構築したり、Cobalt Strikeのようなペンテストやレッドチーミングフレームワークを使用したりする以外にも、メールフィッシングに特化した多数のツールやフレームワークがあります。このWikiでは各フレームワークの詳細には触れませんが、それぞれのリソースを以下にまとめています：
### Gophish
* [Gophish公式サイト](https://getgophish.com/)
* [Gophish GitHubリポジトリ](https://github.com/gophish/gophish)
* [Gophishユーザーガイド](https://www.gitbook.com/book/gophish/user-guide/details)
### Phishing Frenzy
* [Phishing Frenzy公式サイト](https://www.phishingfrenzy.com/)
* [Phishing Frenzy GitHubリポジトリ](https://github.com/pentestgeek/phishing-frenzy)
* [Phishing Frenzyの紹介 - Brandon McCann (@zeknox)](https://www.pentestgeek.com/phishing/introducing-phishing-frenzy)
### Social-Engineer Toolkit
* [Social-Engineer Toolkit GitHubリポジトリ](https://github.com/trustedsec/social-engineer-toolkit)
* [Social-Engineer Toolkitユーザーマニュアル](https://github.com/trustedsec/social-engineer-toolkit/raw/master/readme/User_Manual.pdf)
### FiercePhish (旧FirePhish)
* [FiercePhish GitHubリポジトリ](https://github.com/Raikia/FiercePhish)
* [FiercePhish Wiki](https://github.com/Raikia/FiercePhish/wiki)
# リダイレクタ
## SMTP
「リダイレクタ」という言葉は、これから達成しようとすることの最適な表現ではないかもしれませんが、他のリダイレクションと同様の目標です。最終的なメールヘッダーからフィッシングの発信元の痕跡をすべて取り除き、被害者とバックエンドサーバーの間にバッファを提供したいのです。理想的には、SMTPリダイレクタは迅速にセットアップでき、簡単に廃止できることが望ましいです。
SMTPリダイレクタに実行させたい主要なアクションは2つあります：
### Sendmail
#### 以前のサーバーヘッダーを削除する
`/etc/mail/sendmail.mc` の末尾に次の行を追加します：```bash
define(`confRECEIVED_HEADER',`by $j ($v/$Z)$?r with $r$. id $i; $b')dnl
/etc/mail/access` の末尾に追加します:```bash IP-to-Team-Server TAB RELAY Phish-Domain TAB RELAY
[Removing Sender’s IP Address From Email’s Received From Header](https://www.devside.net/wamp-server/removing-senders-ip-address-from-emails-received-from-header)
[Removing Headers from Postfix setup](https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/)
#### キャッチオールアドレスの設定
これにより、*@phishdomain.com 宛に受信したすべてのメールが、選択したメールアドレスにリレーされます。これは、フィッシングメールへの応答やバウンスバックを受信する際に非常に役立ちます。```bash
echo PHISH-DOMAIN >> /etc/mail/local-host-names
//Mailer Definitions//（末尾付近）の直前に、/etc/mail/sendmail.mc へ次の行を追加します。```bash
FEATURE(virtusertable', hash -o /etc/mail/virtusertable.db')dnl
`/etc/mail/virtusertable` の末尾に次の行を追加します:```bash
@phishdomain.com external-relay-address
注：2つのフィールドはタブ区切りにする必要があります
Postfixは、sendmailよりも互換性が広く、より簡単な代替手段を提供します。PostfixはDovecotによる完全なIMAPサポートも提供します。これにより、テスターはキャッチオールアドレスに依存してフィッシングツールで新しいメッセージを作成する代わりに、元のメッセージに返信したフィッシングターゲットとリアルタイムでやり取りできます。
フィッシング用のPostfixメールサーバーのセットアップに関する完全なガイドは、Julian Catrambone（@n0pe_sled）の投稿Mail Servers Made Easyにあります。
注：C2リダイレクタを使用する場合、ステージングトラフィックがリダイレクタドメインを経由するように、ポストエクスプロイテーションフレームワークに外部リスナーを設定する必要があります。これにより、侵害されたホストはC2トラフィック自体と同様にリダイレクタを経由してステージングされます。
socatを使用して、ポート53の受信DNSパケットをチームサーバーにリダイレクトできます。この方法は機能しますが、一部のユーザーはCobalt Strikeでのステージングの問題や、この方法を使用した場合のレイテンシの問題を報告しています。 2017年4月21日編集： 以下のsocatコマンドは、@xorriorによるテストのおかげでうまく機能するようです：``` socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto::53; echo -ne
[Redirecting Cobalt Strike DNS Beacons - Steve Borosh](https://medium.com/rvrsh3ll/redirecting-cobalt-strike-dns-beacons-e3dcdb5a8b9b)
### DNS用iptables
iptablesのDNS転送ルールは、Cobalt Strikeでうまく機能することが確認されています。socatがこの種のトラフィックを処理する際に発生する問題は、ここでは見られないようです。
DNSリダイレクタのルールセットの例を以下に示します。```bash
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <IP-GOES-HERE>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
また、"FORWARD"チェーンのポリシーを"ACCEPT"に変更します
内部ネットワーク上にC2サーバーをホストする必要がある場合や要件がある場合もあります。IPTABLES、SOCAT、リバースSSHトンネルを組み合わせることで、以下の方法で確実にこれを実現できます。
このシナリオでは、揮発性リダイレクタがIPTablesを使用して、このセクションの前半で説明したルール例を用いてすべてのDNSトラフィックを転送します。次に、内部C2サーバーからメインリダイレクタへのSSHリバースポートフォワードトンネルを作成します。これにより、メインリダイレクタがポート6667で受信したすべてのトラフィックが、内部C2サーバーのポート6667に転送されます。次に、チームサーバー上でsocatを起動し、ポート6667で受信したすべての着信TCPトラフィックを、DNS C2がリッスンする必要があるUDPポート53にフォークします。最後に、メインリダイレクタ上でも同様にsocatインスタンスをセットアップし、ポート53で受信したすべての着信UDPトラフィックをポート6667のSSHトンネルにリダイレクトします。
注：C2リダイレクタを使用する場合、ステージングトラフィックをリダイレクタのドメイン経由で送信するように、ポストエクスプロイテーションフレームワーク上で外部リスナーを設定する必要があります。これにより、侵害されたホストはC2トラフィック自体と同様にリダイレクタ経由でステージングされます。
socatは「ダムパイプ」リダイレクションを提供します。socatが指定されたソースインターフェース/ポートで受信したすべてのリクエストは、宛先IP/ポートにリダイレクトされます。フィルタリングや条件付きリダイレクトはありません。一方、Apache mod_rewriteは、フィッシングを強化し、テストインフラストラクチャの耐障害性を高めるための多数の方法を提供します。mod_rewriteには、URI、ユーザーエージェント、クエリ文字列、オペレーティングシステム、IPなどのリクエスト属性に基づく条件付きリダイレクトを実行する機能があります。Apache mod_rewriteはhtaccessファイルを使用して、Apacheが各着信リクエストをどのように処理するかのルールセットを設定します。これらのルールを使用すると、たとえば、デフォルトのwgetユーザーエージェントを持つサーバーへのリクエストを、ターゲットのWebサイト上の正当なページにリダイレクトできます。
要するに、リダイレクタが条件付きリダイレクトや高度なフィルタリングを実行する必要がある場合は、Apache mod_rewriteを使用してください。それ以外の場合は、オプションのiptablesフィルタリングを備えたsocatリダイレクションで十分です。
socatを使用して、指定されたポートで受信したすべての着信TCPパケットをチームサーバーにリダイレクトできます。
ローカルホストのTCPポート80を別のホストのポート80にリダイレクトする基本構文は次のとおりです。``` socat TCP4-LISTEN:80,fork TCP4::80
If your redirector is configured with more than one network interface, socat can be bound to a specific interface, by IP address, with the following syntax:```
socat TCP4-LISTEN:80,bind=10.0.0.2,fork TCP4:1.2.3.4:80
この例では、10.0.0.2はリダイレクタのローカルIPアドレスの1つであり、1.2.3.4はリモートのチームサーバーのIPアドレスです。
socatに加えて、iptablesはNATを介した「ダムパイプ」リダイレクションを実行できます。リダイレクタのローカルポート80をリモートホストに転送するには、次の構文を使用します：``` iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
### HTTP用SSH
以前、DNSトンネルにSSHを使用する方法を説明しました。SSHは、NATを突破し、インプラントがリダイレクタ経由でサーバー環境に接続する手段を確保するための、堅牢で信頼性の高い方法として機能します。SSHリダイレクタを設定する前に、`/etc/ssh/sshd_config`に以下の行を追加する必要があります。```text
# Allow the SSH client to specify which hosts may connect
GatewayPorts yes
# Allow both local and remote port forwards
AllowTcpForwarding yes
内部サーバー上で、リダイレクタのローカルポート80を内部チームサーバーに転送するには、次の構文を使用します。``` tmux new -S redir80 ssh -R *:80:localhost:80 Ctrl+B, D
複数のポートを同時に転送することもできます。たとえば、443と80を同時に開放したい場合は次のようにします:```
tmux new -S redir80443
ssh <redirector> -R *:80:localhost:80 -R *:443:localhost:443
Ctrl+B, D
ペイロードとWebリソースを配信する際には、インシデントレスポンダーがファイルを調査する能力を最小限に抑え、C2の確立や情報収集のいずれにおいてもペイロードの実行成功の可能性を高めたいと考えています。
Jeff DimmockによるApache Mod_Rewriteの使用法と例:
その他のApache mod_rewriteの使用法と例:
リダイレクタサーバー上でApache Mod_Rewriteを自動的にセットアップするには、Julain Catrambone（@n0pe_sled）のブログ記事Mod_Rewriteの自動セットアップと付属ツールを確認してください。
C2トラフィックをリダイレクトする意図は2つあります。バックエンドのチームサーバーを隠蔽することと、インシデントレスポンダーがブラウズした場合に正規のWebサイトに見えるようにすることです。Apache mod_rewriteとカスタマイズされたC2プロファイル、または他のプロキシ手法（Flaskなど）を使用することで、実際のC2トラフィックを調査トラフィックから確実にフィルタリングできます。
上記の「C2リダイレクション」に基づき、別の方法として、リダイレクタサーバーにApacheのSSL Proxy Engineを使用させ、受信したSSLリクエストを受け入れ、それらのリクエストをリバースHTTPSリスナーにプロキシする方法があります。すべての段階で暗号化が使用され、必要に応じてリダイレクタ上のSSL証明書をローテーションできます。
これをmod_rewriteルールで機能させるには、LetsEncrypt（別名CertBot）を使用して証明書をインストールしたと仮定して、ルールを**「/etc/apache2/sites-available/000-default-le-ssl.conf」**に配置する必要があります。また、SSL ProxyPassエンジンを有効にするには、同じ設定ファイルに次の行が必要です。```bash
SSLProxyEngine On
ProxyPass / https://DESTINATION_C2_URL:443/ ProxyPassReverse / https://DESTINATION_C2_URL:443/
SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
### その他のApache mod_rewriteリソース
* [Automating Apache mod_rewrite and Cobalt Strike Profiles](https://posts.specterops.io/automating-apache-mod-rewrite-and-cobalt-strike-malleable-c2-profiles-d45266ca642)
* [mod-rewrite-cheatsheet.com](http://mod-rewrite-cheatsheet.com/)
* [Official Apache 2.4 mod_rewrite Documentation](http://httpd.apache.org/docs/current/rewrite/)
* [Apache mod_rewrite Introduction](https://httpd.apache.org/docs/2.4/en/rewrite/intro.html)
* [An In-Depth Guide to mod_rewrite for Apache](http://code.tutsplus.com/tutorials/an-in-depth-guide-to-mod-rewrite-for-apache--net-6708)
* [Mod_Rewrite/.htaccess Syntax Checker](http://www.htaccesscheck.com/)
# C2トラフィックの変更
## Cobalt Strike
Cobalt Strikeは、Malleable C2プロファイルを使用してトラフィックを変更します。プロファイルは、サーバーのC2トラフィックがネットワーク上でどのように見えるかを変更するための高度にカスタマイズ可能なオプションを提供します。Malleable C2プロファイルは、インシデントレスポンスの回避を強化したり、既知の敵対者を偽装したり、標的が使用する正規の内部アプリケーションになりすましたりするために使用できます。
* [Official Malleable C2 Profiles - GitHub](https://github.com/rsmudge/Malleable-C2-Profiles)
* [Malleable Command and Control Documentation - cobaltstrike.com](https://www.cobaltstrike.com/help-malleable-c2)
* [Cobalt Strike 2.0 - Malleable Command and Control - Raphael Mudge](http://blog.cobaltstrike.com/2014/07/16/malleable-command-and-control/)
* [Cobalt Strike 3.6 - A Path for Privilege Escalation - Raphael Mudge](http://blog.cobaltstrike.com/2016/12/08/cobalt-strike-3-6-a-path-for-privilege-escalation/)
* [A Brave New World: Malleable C2 - Will Schroeder (@harmj0y)](http://www.harmj0y.net/blog/redteaming/a-brave-new-world-malleable-c2/)
* [How to Write Malleable C2 Profiles for Cobalt Strike - Jeff Dimmock](https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/)
* [In-Memory Evasion (Video series) - Raphael Mudge](https://www.youtube.com/watch?v=lz2ARbZ_5tE&list=PL9HO6M_MU2nc5Q31qd2CwpZ8J4KFMhgnK)
Malleable C2プロファイルの作成や変更を始める際には、Beacon情報の配置に関するデータサイズの制限を考慮することが重要です。例えば、URLパラメータに大量のデータを送信するようにプロファイルを設定すると、多くのリクエストが必要になります。詳細については、Raphael Mudgeのブログ記事[Beware of Slow Downloads](https://blog.cobaltstrike.com/2018/03/09/beware-of-slow-downloads/)を参照してください。
Malleable C2プロファイルで問題が発生し、teamserverコンソールにエラーが出力される場合は、トラブルシューティングのヒントとしてRaphael Mudgeのブログ記事[Broken Promises and Malleable C2 Profiles](https://blog.cobaltstrike.com/2018/06/04/broken-promises-and-malleable-c2-profiles/)を参照してください。
## Empire
EmpireはCommunication Profilesを使用します。これにより、GETリクエストのURI、ユーザーエージェント、ヘッダーのカスタマイズオプションが提供されます。プロファイルは、各要素をパイプ文字で区切り、`listeners`コンテキストメニューの`set DefaultProfile`オプションで設定します。
以下はデフォルトプロファイルのサンプルです。```bash
"/CWoNaJLBo/VTNeWw11212/|Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)|Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*|Accept-Language:en-en"
別の方法として、/setup/setup_database.py ファイルを Empire の初期セットアップ前に変更することで、DefaultProfile 値を設定できます。これにより、Empire が使用するデフォルトの Communication Profile が変更されます。
Communication Profile に加えて、Joe Vest（@joevest）の投稿 Empire - Modifying Server C2 Indicators で紹介されている手順に従って、Empire サーバーのステージング URI、サーバーヘッダー、およびデフォルトのウェブページコンテンツのカスタマイズを検討してください。
C2 に信頼できる正当な Web サービスを活用することは、自分で設定したドメインやインフラストラクチャを使用するよりも価値のある優位性をもたらします。設定にかかる時間と複雑さは、使用する手法とサービスによって異なります。C2 リダイレクションにサードパーティサービスを活用する一般的な例として、Domain Fronting があります。
Domain Fronting は、検閲回避サービスやアプリが使用する手法で、正当で信頼性の高いドメインを経由してトラフィックをルーティングします。Domain Fronting をサポートする一般的なサービスには、Google App Engine、Amazon CloudFront、Microsoft Azure などがあります。Google や Amazon など、多くのプロバイダーが Domain Fronting に対する緩和策を実装していることに注意することが重要です。そのため、この wiki で提供されているリンク先のリソースや情報の一部は、使用時に古くなっている可能性があります。
簡単に言うと、トラフィックは信頼できるサービスプロバイダーの DNS および SNI 名を使用します。以下の例では Google が使用されています。トラフィックがエッジサーバー（例：gmail.com に配置）で受信されると、パケットはパケットの Host ヘッダーで指定されたオリジンサーバー（例：phish.appspot.com）に転送されます。サービスプロバイダーによっては、オリジンサーバーが指定されたドメイン（これをチームサーバーに向けます）にトラフィックを直接転送するか、最終ホップの転送を実行するためにプロキシアプリが必要になります。
Domain Fronting の仕組みの詳細については、ホワイトペーパー Blocking-resistant communication through domain fronting と TOR Project の meek ドキュメント を参照してください。
任意の google.com ドメインなどの標準的な frontable ドメインに加えて、他の正当なドメインを fronting に活用することも可能です。
frontable ドメインの探索の詳細については、以下を確認してください：
多くの PaaS および SaaS プロバイダーは、プロビジョニングされたインスタンスで使用するための静的サブドメインまたは URL を提供します。関連するドメインが一般的に信頼性が高い場合、インスタンスは購入したドメインと VPS よりも C2 インフラストラクチャに追加の信頼をもたらす可能性があります。
リダイレクションを設定するには、インスタンスの一部として静的サブドメインまたは URL を発行するサービスを特定する必要があります。次に、インスタンスにネットワークベースまたはアプリケーションベースのリダイレクションを設定する必要があります。インスタンスは、この wiki で説明されている他のリダイレクタと同様に、プロキシとして機能します。
さらに調査する価値のあるもう 1 つの興味深い手法は、過度に寛容な Amazon S3 バケットを C2 に使用することです。Andrew Luke (@Sw4mp_f0x) による投稿 S3 Buckets for Good and Evil で、S3 バケットを C2 に使用する方法の詳細を確認してください。この手法は、Empire のサードパーティ C2 機能と組み合わせて、ターゲットの正当な S3 バケットを彼らに対して使用することができます。
PaaS を C2 に使用する別の例については、Scott Sutherland（@_nullbind）による Databases and Clouds: SQL Server as a C2 を確認してください。
過去には、他のサードパーティサービスも C2 に実際に使用されてきました。ユーザー生成コンテンツの迅速な投稿や変更を可能にするサードパーティの Web サイトを活用すると、特にそのサイトが一般的に信頼されている場合、レピュテーションベースの制御を回避するのに役立ちます。
他のサードパーティ C2 オプションについては、以下のリソースを確認してください：
攻撃インフラストラクチャは、正当なサーバーの殻のように見えることが多く、識別されやすいです。ターゲット組織またはターゲットが使用する可能性のあるサービスの中で、実際のサーバーに溶け込む可能性を高めるために、インフラストラクチャに追加の手順を講じる必要があります。
リダイレクタ は、無効な URI のリダイレクション、フィッシングペイロードリンクの有効期限設定、または一般的なインシデントレスポンダー手法のブロック によって溶け込むのに役立ちます。ただし、基盤となるホストとその指標にも注意を払う必要があります。
たとえば、Fall of an Empire という投稿で、John Menerick（@Lord_SQL）は、インターネット上の Empire サーバーを検出する方法を説明しています。
これらの指標や類似の指標に対抗するには、C2 トラフィックパターンの変更、サーバーのランディングページの変更、オープンポートの制限、デフォルトのレスポンスヘッダーの変更を行うことをお勧めします。
複数の攻撃フレームワークに対してこれらの方法やその他の戦術を実行する方法の詳細については、以下の投稿を確認してください：
攻撃インフラストラクチャは、他のインターネット接続ホストと同様に攻撃される可能性があり、使用中のデータとターゲット環境への接続のため、非常に機密性が高いと見なすべきです。
2016 年には、最も一般的な攻撃ツールでリモートコード実行の脆弱性が公開されました：
iptables を使用して、不要なトラフィックをフィルタリングし、必要なインフラストラクチャ要素間のトラフィックを制限する必要があります。たとえば、Cobalt Strike チームサーバーが Apache リダイレクタにのみアセットを提供する場合、iptables ルールはリダイレクタの送信元 IP からのポート 80 のみを許可する必要があります。これは、SSH や Cobalt Strike のデフォルトポート 50050 などの管理インターフェースにとって特に重要です。また、非ターゲット国の IP をブロックすることも検討してください。別の方法として、VPS プロバイダーが提供するハイパーバイザーファイアウォールの使用を検討してください。たとえば、Digital Ocean は、1 つまたは複数のドロップレットを保護できる Cloud Firewalls を提供しています。
chattr は、cron ディレクトリが変更されるのを防ぐためにチームサーバーで使用できます。chattr を使用すると、chattr 属性が削除されるまで、root を含むすべてのユーザーがファイルを変更することを制限できます。
SSH は公開鍵認証のみに制限し、初期ログインには権限が制限されたユーザーを使用するように設定する必要があります。セキュリティを強化するには、SSH に多要素認証を追加することを検討してください。
更新！ セキュリティ対策のリストには、システムを定期的に更新し、脆弱性を修正するために必要に応じてホットフィックスを適用するという注意事項が必ず含まれるべきです。
もちろん、このリストはチームサーバーを保護するためにできることのすべてを網羅しているわけではありません。すべてのインフラストラクチャに一般的なハードニングプラクティスを適用してください：
インフラストラクチャの安全なセットアップと設計について説明しているオンラインリソースは多数あります。すべての設計上の考慮事項がすべての攻撃インフラストラクチャに適しているわけではありませんが、どのようなオプションが利用可能で、他のテスターが何を行っているかを知っておくことは役立ちます。
これらのリソースの一部を以下に示します：
この wiki で説明されているトピックは攻撃インフラストラクチャを強化しますが、一般的に設計と実装にかなりの時間を要します。自動化を使用すると、デプロイメント時間を大幅に短縮でき、より複雑なセットアップをより短時間でデプロイできます。
攻撃インフラストラクチャの自動化に関する以下のリソースを確認してください：
すべてを文書化する - 複雑な Red Team インフラストラクチャを運用することは、多くの可動部分があることを意味します。各アセットの機能と、そのトラフィックが送信される場所を必ず文書化してください。
アセットを異なるサービスプロバイダーとリージョンに分散する - インフラストラクチャアセットは、複数のサービスプロバイダーと地理的リージョンに分散する必要があります。Blue Team は、攻撃を積極的に実行していると特定されたプロバイダーに対して監視しきい値を引き上げたり、特定のサービスプロバイダーを完全にブロックしたりする可能性があります。注：暗号化されたデータや機密データを国境を越えて送信する場合は、国際的なプライバシー法に留意してください。
やりすぎない - 高度なテクニックに興奮して、ターゲットにありとあらゆるものを投げつけたくなるのは簡単です。特定の敵対的脅威をエミュレートしている場合は、実際の脅威アクターが使用したテクニック、または脅威アクターのスキルセット内のテクニックのみを活用してください。レッドチームテストが同じターゲットを長期間攻撃する場合は、「簡単な」ものから始めて、評価が進むにつれてより高度なトレードクラフトに取り組むことを検討してください。レッドチームのテクニックをブルーチームと並行して進化させることで、組織を一貫して前進させることができます。一方、ブルーチームに一度にすべてをぶつけると、ブルーチームを圧倒し、学習プロセスを遅らせる可能性があります。
ログを監視する - エンゲージメント全体を通じてすべてのログを監視する必要があります：SMTP ログ、Apache ログ、socat リダイレクタ上の tcpdump、iptables ログ（トラフィック転送またはターゲットフィルタリングに固有）、Web ログ、Cobalt Strike/Empire/MSF ログ。監視を容易にするために、rsyslog などを使用して、ログを中央の場所に転送してください。オペレーターのターミナルデータの保持は、操作中の過去のコマンド使用状況を確認するのに役立ちます。@Killswitch_GUI は、すべての bash ターミナルコマンドを中央の場所にログ記録する、lTerm という使いやすいプログラムを作成しました。lTerm で全てのターミナル出力をログに記録する。高度なインフラストラクチャ監視と分析のために Cobalt Strike ログを Splunk に送信する方法の例については、Vincent Yiu の投稿 CobaltSplunk を確認してください。* 高価値イベントのアラートを実装する - 攻撃インフラを構成して、新しいC2セッションや資格情報の取得ヒットなどの高価値イベントに対してアラートを生成します。アラートを実装する一般的な方法の1つは、SlackなどのチャットプラットフォームのAPIを介するものです。Slackアラートに関する以下の投稿を確認してください: Slack Shell Bot - Russel Van Tuyl (@Ne0nd0g)、Slack Notifications for Cobalt Strike - Andrew Chiles (@AndrewChiles)、Slack Bots for Trolls and Work - Jeff Dimmock (@bluscreenfojeff)
インシデントレスポンスのフィンガープリント - 可能であれば、評価が始まる前にIRアクションを受動的または能動的にフィンガープリントしてみてください。例えば、ターゲットに（無関係なインフラを使用して）平凡なフィッシングメールを送信し、そのインフラが受信するトラフィックを監視します。IRチームの調査により、チームがどのように運用しているか、どのインフラを使用しているかについて多くの情報が明らかになる可能性があります。これを評価前に特定できれば、フィルタリングしたり、完全にリダイレクトしたりできます。
このwikiに含めるツール、ヒント、リンクを提供してくださった以下のすべての方々（アルファベット順）に心から感謝します。また、このwikiで参照されているツールや投稿を執筆されたすべての方にも感謝します！