Cobalt Strike のコンポーネントを定義して、分析に確信を持てるようにする

Cobalt Strikeは、レッド チーム向けに販売されている商用の敵対者シミュレーション ソフトウェアですが、ランサムウェア オペレーターからスパイ活動に重点を置いた Advanced Persistent Threat (APT) まで、幅広い脅威アクターによって盗まれ、積極的に使用されています。多くのネットワーク防御担当者は、Cobalt Strike ペイロードが侵入に使用されるのを見てきましたが、Cobalt Strike をオペレーターとして使用する機会がなかった人にとっては、このフレームワークに含まれる多くのコンポーネントと機能を理解するのは難しい場合があります.

このブログ投稿では、防御側が Cobalt Strike を理解するのに役立つ重要な定義と概念について説明し、うまくいけば、このツールを使用して悪意のある攻撃者を探し、対応し、特定する新しい方法を特定します。

このコンテンツは、公式文書、公的調査、および脅威アクターが Cobalt Strike を使用している場合に、レッド チーム評価の実行と侵入への対応の両方における Mandiant 自身の経験を組み合わせて情報を得ています。 Cobalt Strike は正当なテストと侵入の両方に使用されるため、この投稿では、単純化のために動機に関係なく、すべての Cobalt Strike ユーザーを「オペレーター」と呼びます。

このブログ投稿は、防御側の分析を支援するために Cobalt Strike と BEACON アーティファクトの説明に重点を置いていますが、Cobalt Strike の詳細と、攻撃ライフサイクルのさまざまな段階で一般的な BEACON アクティビティを検出する方法について学ぶためのいくつかのリソースへの参照も含めました。

重要なコンポーネント

Cobalt Strike、BEACON、Team Server。オーマイ!

Cobalt Strike、BEACON、さらにはチーム サーバーという名前が同じ意味で使われているのを耳にするかもしれませんが、それらすべての間にはいくつかの重要な違いがあります。

Cobalt Strikeは、コマンド アンド コントロール( C2) アプリケーションそのものです。これには、チーム サーバーとクライアントという 2 つの主要コンポーネントがあります。これらは両方とも同じ Java 実行可能ファイル (JAR ファイル) に含まれており、唯一の違いは、オペレーターがそれを実行するために使用する引数です。

  • チーム サーバーは、Cobalt Strike の C2 サーバー部分です。クライアント接続、BEACON コールバック、および一般的な Web 要求を受け入れることができます。
    • デフォルトでは、TCP ポート 50050 でクライアント接続を受け入れます。
    • チーム サーバーは、Linux システムでの実行のみをサポートします。
  • クライアントは、オペレーターがチーム サーバーに接続する方法です。
    • クライアントは、チーム サーバーと同じシステムで実行することも、リモートで接続することもできます。
    • クライアントは、Windows、macOS、または Linux システムで実行できます。

BEACONは、チーム サーバーへの接続を作成するために使用される Cobalt Strike のデフォルトのマルウェア ペイロードの名前です。ターゲットからのアクティブなコールバック セッションは「ビーコン」とも呼ばれます。 (これがマルウェア ファミリの名前の由来です。) BEACON には次の 2 種類があります。

  • Stagerはオプションの BEACON ペイロードです。オペレーターは、いくつかの基本的なチェックのみを行う最初の小さな BEACON シェルコード ペイロードを送信することで、マルウェアを「ステージング」し、構成済みの C2 にフル機能のバックドアを問い合わせることができます。
  • フルバックドアは、BEACON ステージャー、「ローダー」マルウェア ファミリ、またはデフォルトの DLL エクスポート「ReflectiveLoader」を直接実行することによって実行できます。このバックドアはメモリ内で実行され、いくつかの方法でチーム サーバーへの接続を確立できます。

ローダーは BEACON ではありません。 BEACON はバックドア自体であり、通常、ステージングされたバックドアであるか完全なバックドアであるかにかかわらず、他のローダーで実行されます。 Cobalt Strike にはデフォルトのローダーが付属していますが、オペレーターは、PowerShell、.NET、C++、GoLang、またはシェルコードを実行できるものなら何でも使用して、独自のローダーを作成することもできます。

すべてがつながっている

リスナーは、BEACON などのペイロードがチーム サーバーに接続するために使用する Cobalt Strike コンポーネントです。 Cobalt Strike は複数のプロトコルをサポートし、各リスナー タイプ内で幅広い変更をサポートします。リスナーへの一部の変更には、「リスナーの再起動」と新しいペイロードの生成が必要です。一部の変更には、チーム サーバーの完全な再起動が必要です。

  • HTTP/HTTPSは、最も一般的なリスナー タイプです。
    • Cobalt Strike にはデフォルトの TLS 証明書が含まれていますが、これは防御側にはよく知られており、多くのエンタープライズ製品 (「署名済み」) によってブロックされています。通常、オペレーターは、LetsEncrypt などを使用して、C2 ドメインが溶け込む有効な証明書を生成します。
    • Malleable Profiles (投稿の後半で説明) のおかげで、オペレータは BEACON ネットワーク トラフィックがどのように見えるかを細かく設定し、正当な HTTP 接続として偽装することができます。
    • オペレーターは、リスナーを構成するときにドメイン/IP のリストを提供できます。チーム サーバーは、それらすべてからの BEACON 接続を受け入れます (「リダイレクター」を参照)。オペレーターは、ホスト ヘッダー値を指定することもできます (「ドメイン フロント」を参照)。
  • DNSリスナーは、チーム サーバーが権限を持つドメインの DNS 要求を使用して、チーム サーバーへのセッションを確立します。 DNS リスナーは2 つのモードをサポートしています
    • ハイブリッド (DNS+HTTP)がデフォルトで、ビーコン チャネルに DNS を使用し、データ チャネルに HTTP を使用します。
    • 純粋な DNSを有効にして、ビーコンとデータ チャネルの両方に DNS を使用することもできます。これは、通常の A レコード リクエストを利用して、HTTPS の使用を回避し、速度は遅くなりますが、よりステルスな通信方法を提供します。
  • SMBはバインド スタイルのリスナーであり、ビーコンの連鎖に最もよく使用されます。バインド リスナーは、ターゲット システムのローカル ポートを開き、オペレーターからの着信接続を待ちます。詳細については、「重要な概念 > ビーコンの連鎖」を参照してください。
  • Raw TCPは (新しい) バインド スタイルのリスナーであり、ビーコンの連鎖にも使用できます。詳細については、「重要な概念 > ビーコンの連鎖」を参照してください。

最後の 2 つのリスナーはあまり一般的ではありませんが、他のペイロード タイプとの互換性を提供します。

  • 外部リスナーは、Metasploit のMeterpreterバックドアからの接続を許可し、Metasploit フレームワークと Cobalt Strike フレームワークの間のセッションの受け渡しを簡素化します。
  • 外部 C2リスナーは、オペレーターがリバース TCP リスナーを使用してチーム サーバーに接続するために使用できる仕様を提供します。リバース リスナーは、「バインド」リスナーのように着信接続を待機する代わりに、オペレーターに接続して外部接続を確立します。

それは(ほぼ)すべてカスタマイズ可能です

アーセナル キットは、有効なライセンスがあればダウンロードでき、ライセンスが付与された (またはクラックされた) インストールでのみ使用できます。アーセナルのキットは、Cobalt Strike のひびの入ったコピーと一緒に配布されることがあります。キットの完全なリスト (2021 年 10 月現在) は次のとおりです。

  • Applet/PowerApplet Kitを使用すると、オペレータは Cobalt Strike の組み込み Java アプレット ペイロードを変更できます。このキットはアーセナルに最初に追加されたもので、現在ではあまり使用されていません。
  • Artifact Kitを使用すると、オペレーターはすべての Cobalt Strike 実行可能ファイル、DLL、およびシェルコードのテンプレートを変更できます。このキットは 2014 年 1 月に追加され、現在も使用されています。
  • Elevate Kitを使用すると、オペレーターは特権エスカレーション エクスプロイトを Cobalt Strike コマンドとして統合できます。このキットは 2016 年 12 月にリリースされました。他のキットとは異なり、これは公開れており、基本的には、独自の PowerShell スクリプト、バイナリなどを BEACON セッションにロードすることを効率化するためのアグレッサー スクリプトにすぎません (「アグレッサー スクリプト」を参照)。
  • Mimikatz Kitを使用すると、オペレータは Cobalt Strike ソフトウェアの更新を待たずに Mimikatz のバージョンを更新できます。このキットは 2021 年 7 月に追加されました。
  • リソース キットを使用すると、オペレーターは Cobalt Strike が使用するスクリプト テンプレートを (ほとんどの場合ローダーとして) 変更できます。このキットは 2017 年 5 月に追加され、現在も使用されています。
  • Sleep Mask Kitを使用すると、オペレータは BEACON が使用するメモリ内の難読化を変更して、 これらのような検出方法を回避できます。このキットは 2021 年 8 月に追加されました。このキットを使用してインメモリ BEACON 検出に影響を与える方法のチュートリアルについては、このブログ投稿をご覧ください
  • User Defined Reflective Loaders Kitを使用すると、オペレータは BEACON が使用する反射ローダー機能をカスタマイズできます。このキットは 2021 年 8 月に追加されました。

可鍛性プロファイル アーセナル キットの最後の部分であり、オペレーターは Cobalt Strike のインストール方法を大幅に変更できます。これは、オペレータが Cobalt Strike をカスタマイズする最も一般的な方法であり、そのため多くドキュメントが作成されています

  • 順応性プロファイルを変更するには、チーム サーバーを再起動する必要があり、変更によっては、ペイロードの再生成とビーコン セッションの再生成が必要になる場合があります。
  • ランダム化されたプロファイルを生成する堅牢なオープンソース プロジェクトがいくつかあるため、検出が困難になる可能性があります。それでも、オペレーターはプロファイルを再利用する (またはわずかに変更するだけ) ことが多く、検出が容易になり、アトリビューション クラスタリングが可能になる可能性があります。
  • サンプルを分析するときは、GitHub やその他の公開ソースをチェックして、プロファイルがオープン ソースかどうかを確認してください。

アグレッサー スクリプトは、オペレーターがワークフローを合理化するために作成してクライアントにロードできるマクロです。これらはクライアント コンテキスト内でロードおよび実行され、新しい BEACON 機能を作成せず、既存のコマンドを自動化します。それらは、Raphael Mudge (Cobalt Strike の作成者) が書いた “Sleep” と呼ばれる Perl ベースの言語で書かれています。例として、「オペレーターの視点」セクションをチェックしてください。

アグレッサー スクリプトは、オペレーターのローカル クライアントにのみロードされます。それらは、他のオペレーターのクライアント、チーム サーバー、または BEACON セッション (犠牲ホスト) にはロードされません。の これらのスクリプトの主な検出機会は、検出ルールまたはハンティング ルールで使用できる静的なデフォルトを確認することです。

アセンブリ実行 オペレータがターゲット ホストのメモリ内で .NET 実行可能ファイルを実行できるようにする BEACON コマンドです。 BEACON は、一時プロセスを生成してアセンブリを挿入することにより、これらの実行可能ファイルを実行します。アグレッサー スクリプトとは対照的に、execute-assembly では、オペレータは BEACON 機能を拡張できます。この方法で実行されるアセンブリは、Microsoft のAMSIが有効になっている場合、引き続きスキャンされます。

ビーコン オブジェクト ファイル(BOF)は、かなり最近の Cobalt Strike 機能であり、オペレータが BEACON ポストエクスプロイト機能を拡張できるようにします。 BOF は、ターゲット ホストのメモリ内で実行されるコンパイル済みの C プログラムです。アグレッサー スクリプトとは対照的に、BOF は BEACON セッション内にロードされ、新しい BEACON 機能を作成できます。さらに、execute-assembly などの他の BEACON ポストエクスプロイト コマンドと比較して、BOF は BEACON セッション内で実行され、プロセスの作成や挿入を必要としないため、比較的ステルスです。

オペレーターの見解

前述のコンポーネントのうち 4 つ (クライアント、アグレッサー スクリプト、ビーコン オブジェクト ファイル、順応性プロファイル) は、オペレーターがチーム サーバーとやり取りしてカスタマイズする主な方法です。オペレーターの観点からこれらのコンポーネントを示すために、それぞれの例がここに含まれています。

Cobalt Strikeクライアントを介してチーム サーバーにアクセスするオペレーターには、次のようなビューが表示されます。上部のペインには、アクティブなビーコン セッションのリストと、現在のユーザー、プロセス ID、内部および外部 IP アドレス、ホストがチーム サーバーに最後にチェックインした時刻などの基本的なメタデータが表示されます。下部ペインには、オペレーターが被害ホストにコマンドを送信し、過去のコマンドと出力のログを表示できる各セッションのタブが含まれています。クライアント インターフェイスにより、オペレーターはペイロードの構築、プラグインの実行、およびレポートの生成も行うことができます。

Cobalt Strike 3.10 client view
図 1: Cobalt Strike 3.10 クライアント ビュー (ソース)

クライアント内で、オペレーターはアグレッサー スクリプトをインポートして、コマンド、メニュー オプション、およびインターフェイスをカスタマイズできます。アグレッサー スクリプトの複雑さは、新しいメニュー ショートカットの追加から複数の攻撃ステップの連鎖までさまざまです。以下は credpocalypse.cna からの抜粋です。 これはアクティブなビーコン セッションをスケジュールに従ってチェックし、新しいユーザーがログインした場合にオープンソースの資格情報ダンパーである Mimikatz を実行するアグレッサー スクリプトです。

これは Cobalt Strike に機能を追加するものではないことに注意してください。この場合、スクリプトは組み込みの BEACON 機能を使用してプロセスを一覧表示し、Mimikatz を実行し、Cobalt Strike API を使用してスケジュールに従って実行します。つまり、BEACON の Mimikatz モジュールの既存の検出もこれを検出します。

コード1

ビーコン オブジェクト ファイルは、BEACON セッション内で実行される単一ファイルの C プログラムです。 BOF は小規模であり、短期間で実行されることが期待されます。 BEACON セッションはシングル スレッドであるため、BOF は実行中に他の BEACON コマンドをブロックします。以下は、動的関数解決を使用して現在のドメインを検索するCobalt Strike ドキュメントの例です。

コード 2

最後に、 Malleable Profilesを使用すると、オペレーターはチーム サーバーを初めて起動するときに、さまざまな設定をカスタマイズできます。 パブリック プロファイルに続くスニペットは、オペレーターが BEACON トラフィックを Amazon に関連しているように見せる方法の例です。青色の部分 (set uri 行と client ブロック) は、BEACON ペイロードの動作を定義します。これらの値の一部は、BEACON サンプルから抽出できます。詳細については、「アーティファクトの解釈 > GET および POST リクエスト」を参照してください。

コード3

重要な概念

ステージャー

先ほど「BEACONには2種類ある」と書きましたが、そのうちの1つがステージャーです。オペレーターは、複数のリスナー タイプ (DNS ステージャー、SMB ステージャー、HTTPS ステージャーなど) のステージャーを持つことができます。そのような場合、ステージャー シェルコードが実行されると、関連するプロトコルを介して最終的な BEACON ペイロードをプルして実行し、定義されたリスナー メソッドを使用して接続を確立します。

防御側にとって重要な注意事項は、デフォルトでは、オペレーターが操作でステージングされたペイロードを使用していない場合でも、防御側はチーム サーバーから Cobalt Strike HTTP/S ステージャー ペイロードをダウンロードできるということです。これにより、防御側は 1. そのポートでリスナーを使用して何かがチーム サーバーをホストしていることを確認し、2. ペイロードから追加の構成アーティファクトを抽出できます。

これが機能するのは、Cobalt Strike が Metasploit の Meterpreter ペイロードと互換性を持つように設計されているためです。 Metasploit (および Cobalt Strike) は、有効な URL 要求が受信されると、HTTPS ステージャーを提供します。有効な URL は、4 文字の ASCII 値を加算して計算された有効な 8 ビットチェックサムを持つ任意の 4 文字の英数字値です

オペレーターは、host_stage Malleable Profile の値を「false」に設定することで、防御側がステージャーを取得するのを防ぐことができます。より一般的には、リバース プロキシを使用して、ステージャー リクエストなどの不要なトラフィックを除外することがあります。保護機能として、Cobalt Strike は、curl や wget などのブラックリストに登録されたユーザー エージェントを含む Web リクエストを無視します。 Cobalt Strike 4.4以降、オペレーターは .http-config.allow_useragents 可鍛性プロファイル オプションを使用してユーザー エージェントをホワイトリストに登録することもできます。チーム サーバーは、ステージャ リクエストを自動化するスキャナによって常に期待どおりに機能するとは限らないため、これらの警告は覚えておくことが重要です。

運用上のセキュリティ上の注意として、オペレーターはチーム サーバーへの Web リクエストを検出することもできます。これは、オペレーターがログで確認できるためですまた、ソース IP などのすべての HTTP 要求の詳細とともに、ステージャーがプルされたかどうかを「Web ログ」ビューで確認することもできます。

試用版 vs ライセンス版 vs クラック版

Cobalt Strike は合法的に無料で利用できるわけではありません。チーム サーバー/クライアントのコピーは、オペレーターが申請して承認されない限り、ヘルプ システム (Cobalt Strike を所有する会社) から試用版またはライセンス版としてダウンロードすることはできません。残念ながら、ほぼすべての最近のバージョンについて、試用版やクラックされたコピー (すべてではないにしてもほとんどのライセンス機能を含む) がリークされ、公開され続けています。

  • Cobalt Strike の試用版には多くの署名が付けられており、本番環境で使用できるように意図された多くの明らかなデフォルトが含まれています。 (たとえば、EICAR 文字列をすべてのペイロードに埋め込みます。) これは、オペレーターが実際に試用として使用していることを確認するためであり、最終的には業務目的で使用する場合は料金が発生します。
  • Cobalt Strike のライセンスバージョンには、より多くの機能 (アーセナル キットなど) が含まれ、組み込みアーティファクトは少なくなります (EICAR はもうありません!)。関連する Cobalt Strike ライセンスに関連する透かしはペイロードに埋め込まれており、ほとんどの BEACON 構成パーサーを使用して抽出できます。その値には多くの注意事項があるため、この投稿の後半にある「アーティファクトの解釈 > 透かし」を参照してください。
    • ライセンスは盗まれる可能性がありますが、ライセンスが取り消された場合、オペレーターはそれを使用してインストールを更新することができなくなります。オペレーターが「認証ファイル」を保持している場合 (「アーティファクトの解釈 > 透かし」を参照)、既存のインストールは有効期限が切れるまで機能します。
  • Cobalt Strike のクラックバージョンは、さまざまなフォーラムで配布されています。通常、これらは、誰かがトライアル JAR ファイルを変更してライセンス チェックをバイパスし、JAR を再構築した結果、または偽のライセンス ID を使用して認証ファイルを作成し、それを JAR と共に配布した結果です。

Cobalt Strike のクラック バージョンと正規にライセンスされたバージョンを区別することは困難な場合があります。透かしがクラッキング プロセスの一部として静的に定義された場合、それを共有/分散コピーに関連付けることができる可能性があります。 Cobalt Strike の一部のクラックされたコピーには、チーム サーバーへのサードパーティ アクセスを提供するバックドアも含まれています。このような場合、マルウェア アナリストは、静的分析を通じて違法なコピーを特定できる場合があります。

リダイレクター

ビーコンをチーム サーバーに直接接続する代わりに、オペレーターは、接続を受け入れてチーム サーバーに転送するリダイレクター (または複数) を使用することがあります。これには、次のことができるなど、オペレーターにとっていくつかの利点があります。

  • 1 つの BEACON 接続で複数のドメインを循環
  • 基盤となるチーム サーバーを置き換えることなく、検出/ブロックされたリダイレクターを置き換えます
  • BEACON トラフィックが溶け込み、検出を回避するのに役立つ、より高い (より) 評判の高いドメインを使用する

オペレーターは、リダイレクターを使用してスキャナーやハンティング ツールなどの「疑わしい」トラフィックを除外し、チーム サーバーを保護することもできますが、通常は、チーム サーバーとリダイレクターを追跡する簡単な方法があります。詳細については、「チーム サーバーのハンティング」セクションを参照してください。

ドメインフロンティングはどうですか?

「リダイレクター」は、nginx プロキシを使用したクラウド インスタンスと同じくらい単純な場合もありますが、別の非常に効果的なリダイレクター方式は「ドメイン フロンティング」です。ドメイン フロンティングは、オペレーターがコンテンツ配信ネットワーク (CDN) のインフラストラクチャを介してリダイレクトすることにより、ネットワーク接続の真の宛先を隠すことができる手法です。この手法は、インターネットの検閲を回避する手段として最初に文書化され、 C2 トラフィックを偽装するためにAPT 29などの攻撃者によって使用されてきました

HTTPS 要求が前面に出されると、CDN によってホストされている信頼できるドメインとの接続が直接確立されます。これが「フロント」ドメインです。暗号化されたリクエストには一意の識別子が含まれており、多くの場合、HTTP の「ホスト」ヘッダーに含まれており、CDN はこれを使用してオペレータが制御するサーバーにリクエストをルーティングします。ドメインに面したトラフィックは最初に CDN に送信されるため、防御者によって監視されると、CDN の正当な SSL/TLS 証明書が使用されます。

ドメインフロント C2 接続
図 2: ドメイン フロント C2 接続 (source )

この状況では、オペレーターのドメインへのトラフィックをブロックするために、防御側はトラフィックを復号化して HTTPS 接続内の真の宛先を発見する必要がありますが、これは常に実用的ではありません。リソースを集中的に使用するだけでなく、一部の CDN のトラフィックを復号化できない場合があります。たとえば、一部の CDN は、組織が提供する信頼されたルート証明書を使用してトラフィックの傍受と復号化を防ぐために、SSL/TLS 証明書に証明書のピン留めを強制します。

ドメイン フロンティングとマスカレード

マスカレード トラフィックは正規のサービスに見えるように設計されていますが、実際には通信事業者のサーバーに直接接続されていますが、フロント トラフィック正規のサービス (CDN) に送信され、そこから通信事業者に転送されます。

Host ヘッダー値と宛先ドメインが同じ場合、これは通常の直接 HTTP 接続です。

Host ヘッダーと宛先ドメインが異なり、Host ヘッダーが

  • 正当なドメイン (Alexa トップ 1M など)、ドメイン マスカレードである可能性が高い
  • CDN エンドポイントに使用されるドメイン (*.azureedge.net など)。ドメイン フロンティングである可能性があります。

ドメインがフロント可能かどうかをテストするための公開ガイドが複数あります。このリポジトリには、CDN プロバイダーによるフロント可能ドメインのコンパイル済みリストも含まれています。公開リストは古くなっている可能性があり、手動による検証が引き続き必要になる可能性があることに注意してください。

ビーコンの連鎖

オペレーターが接続を確立できるもう 1 つの方法は、ビーコンを連鎖させることです。オペレータは、HTTPS リスナーにビーコンを返すなど、侵害されたシステムを 1 つ取得すると、内部で他のシステムにピボットできます。

オペレーターがビーコンを連鎖させる最も一般的な理由は、ネットワークのセグメンテーションと制限を回避することです。アウトバウンド インターネット アクセスを持たないサーバーを対象とする場合、対象システムへのネットワーク接続を備えた別のビーコンを介して接続をプロキシし、チーム サーバーでコールバックを受信できます。オペレーターが親システムへのアクセスを失うと、連鎖ビーコンへのアクセスも失われます。

SMB リスナーと SMB ステージ ビーコンは、連鎖の元の方法でした。 Cobalt Strike は生の TCP リスナーもサポートするようになりました。 SMB ステージャーが検出される環境 (Endpoint Detection and Response 製品でますます一般的になっています) では、オペレーターはポート 445 経由で生の TCP チェーンを使用できます。より厳密に署名された SMB リスナーを使用します。

「オペレーターの視点」セクションのスクリーンショットでは、最初のセッションの外部 IP がセッション 2 の内部 IP と一致しています。これは、2 番目のセッションでチェーンされていることを示しています。 IP の横にある二重無限/チェーン アイコンも、チェーンされていることを示します。システムが親ホストへの接続を失った場合、そのチェーン アイコンは切断されます。

次のスクリーンショットは、Cobalt Strike クライアントからの「ピボット グラフ」ビューを示しています。この図では、各 BEACON がコンピュータのアイコンで表されています。チェーンされたセッションは子セッションへの矢印で識別され、ファイアウォール アイコンはオペレーターの C2 への外部接続を表します。

チェーンされた BEACON のクライアント「グラフ ビュー」
図 3: チェーンされた BEACON のクライアント「グラフ ビュー」 (ソース)

SMB または TCP のステージングされた BEACON ペイロードによる侵入に応答する場合は、ステージングされたペイロードの「C2」として構成された IP アドレスで始まる、侵害された他のホストを探します。

チーム サーバーのハンティング

Mandiant の Advanced Practices チームは、定期的にインターネットをスキャンして、Cobalt Strike チーム サーバーを含む C2 を探しています。オペレーターがチーム サーバーを適切に保護していない場合、アナリストは悪意のあるインフラストラクチャが使用されているかどうか、またはどこで使用されているかを事前に知らなくても特定し、顧客に事前の警告とカバレッジを提供できます。 Cobalt Strike のような C2 を識別する方法の詳細については、ブログ記事 SCANdalous! (ネットワーク スキャン データと自動化を使用した外部検出) .」

アーティファクトの解釈

チーム サーバーとクライアントのログ

Cobalt Strike のログは、チーム サーバーを使用して行われたアクティビティを理解するのに非常に役立ちます。防御側がこのログ データに頻繁にアクセスできるわけではありませんが、ログが利用可能な場合は、ログから抽出できるデータを理解しておくと役立ちます。

Cobalt Strike は、ログを 2 つの主要な形式で保存します。完全なプレーンテキスト ビーコン ログと、シリアル化された Java ビンです。これらはチーム サーバーの作業ディレクトリに保存され、クライアントがチーム サーバーに接続されたときにクライアントの作業ディレクトリに複製されます。また、新しい認証情報が取得されるなど、アイテムが変更されたときにも更新されます。

Cobaltstrike /logs/ディレクトリには、 2023/02/09/[beaconed host の内部 ip]/[beacon id].logという形式のディレクトリ構造が含まれています。各ファイルは、すべてのビーコン コマンドと関連する出力のプレーンテキスト ログです。これは、オペレータが Cobalt Strike ビーコン コンソールで見る内容を反映しています。

コバルトストライク/スクリーンショット/ Cobaltstrike/downloads/フォルダーはそれぞれ、オペレーターがビーコンからダウンロードしたすべてのスクリーンショットまたはファイルが含まれています。

  • 個々のオペレーター/クライアントの作業ディレクトリには、そのオペレーターがローカル システムに同期したダウンロードのみが含まれ、これらは複数のチーム サーバー接続からのものである可能性があります。
  • チーム サーバーの作業ディレクトリには、そのチーム サーバー上の任意のオペレーターからのスクリーンショット/ダウンロードが含まれます。

Cobaltstrike/logs/2023/02/09ディレクトリの下にはevents.logファイルweb.logファイルもあります。

  • Events.log は、チーム サーバーの「イベント」コンソールのミラーであり、少なくとも、サーバーに接続している各オペレーターの日付/時刻と、各初期ビーコン コールバックが含まれます。
  • Web.log は、ステージングされたペイロードやチーム サーバーでホストされるファイルの要求を含む、チーム サーバーへのすべての Web 要求のログを表示します。

チーム サーバーでホストされ、Cobalt Strike の Web 機能を通じて提供されるファイルは、 cobaltstrike/uploads/ディレクトリに保存されます。個々のオペレーター/クライアントの作業ディレクトリには、そのオペレーターがアップロードしたファイルのみが含まれます。

Cobaltstrike /dataディレクトリには、Cobalt Strike がその状態を追跡するために使用するさまざまなデータ モデルのシリアル化された Java オブジェクトである .bin ファイルがいくつか含まれています。 Cobalt Strike のシリアル化された .bin ログからのデータは、 このスクリプトを使用して CSV として抽出できます

ほとんどのアナリストは、sessions.bin、listeners.bin、および credentials.bin に最も関心があります。 .bin ログには、特定のチーム サーバーを使用して侵害されたシステムとユーザーを特定するための、最も集中的で解析しやすいデータが含まれています。

  • Sessions.bin には、特定のチーム サーバーからのすべてのアクティブなビーコン セッションと履歴ビーコン セッションが、いくつかの基本的なメタデータ (ユーザー、内部および外部 IP、ホスト名、アーキテクチャなど) とともに一覧表示されます。
  • Listeners.bin は、指定されたチーム サーバーのすべてのアクティブなリスナーの詳細を示します。
  • Credentials.bin には、組み込みの資格情報モジュール (Mimikatz など) で自動的にダンプされるか、手動で追加された (オフラインでパスワードをクラックした後など) 資格情報 (クリアテキスト、ハッシュなど) が含まれます。

透かし

Cobalt Strike透かしは、特定の「CobaltStrike.auth」ファイルから生成され、関連付けられた一意の値です。この値は、すべての BEACON ステージャーの最後の 4 バイトとして埋め込まれ、 完全なバックドア BEACON サンプルの組み込み構成に組み込まれます。

CobaltStrike.authファイルは、Cobalt Strike がライセンス ID と有効期限を決定するために使用する構成ファイルです。起動すると、Cobalt Strike はライセンスが有効で期限切れでないことを確認します。 CobaltStrike.auth ファイルは、最新バージョンの Cobalt Strike を起動するために必要であり、Cobalt Strike を更新するとき、およびライセンスを入力するとき (初回または再エントリとして) 更新されます。

一致する透かしは、2 つのペイロードが同じ CobaltStrike.auth ファイルを使用してチーム サーバーから送信されたことを意味します。これは、必ずしも同じオペレーターからのものであるとは限りません。誰かが認証ファイルを含む Cobalt Strike ディレクトリ全体をコピーし、ライセンスが期限切れになるまで同じウォーターマークを持つ別のサーバーにインストールすることができます。

公開鍵

Cobalt Strike は、4 つの異なるタイプのキーストアを使用します。

  • リスナーは、順応性プロファイルで指定されたカスタム キーストアを持つことができます。
  • コード署名は、順応性プロファイルで指定されたカスタム キーストアを使用して構成できます。
  • クライアント接続は、cobaltstrike.store ファイルを使用してクライアント通信を暗号化します。
  • ビーコン接続は、チーム サーバーによって生成されたキーストアを使用して、ビーコン データを暗号化し、その他のセキュリティ機能を処理します。

BEACON キーとその他のセキュリティ機能については、Raphael Mudge のトレーニング Advanced Threat Tactics: Infrastructure 」で説明されています。これらのキーは、STAGER ではなく、完全な BEACON バックドアでのみ使用されます。 NCCGroup によって識別されるように、これらのキーは、チーム サーバーの作業ディレクトリにある「.cobaltstrike.beacon_keys」というシリアル化されたファイルに保存されます。

一致する公開鍵は、2 つのペイロードが同じ .cobaltstrike.beacon_keys キーストアを使用してチーム サーバーから送信されたことを意味します。これは、必ずしも同じチーム サーバーからのものであるとは限りません。この場合も、誰かが Cobalt Strike ディレクトリ全体 (キーストアを含む) をコピーする可能性があります。これは、配布されたコピーやクラックされたコピーで行われることがあります。

C2 IP と URL

BEACON パーサーは通常、C2 IP、ドメイン、および URL をサンプルから抽出します。これらの一部は、たとえば、オペレーターがドメイン フロンティングまたはマスカレードを使用している場合など、正当なドメインである可能性があります。

アトリビューションの目的でBEACONアクティビティをクラスター化しようとする場合、注意すべき点がいくつかあります。たとえば、次のケースは、必ずしも別のチーム サーバーを見ているという意味ではありません。

  • 2 つのサンプルが異なる IP に接続する– これは、リダイレクタが変更されたか、複数のドメイン/ホストがリスナーで定義された結果である可能性があります。
  • 2 つのサンプルは異なる URL パスを参照しています– オペレーターは、順応性プロファイルを定義するときに複数の URL パスを指定できます。オペレーターが BEACON シェルコードを生成するたびに、Cobalt Strike はこのリストからランダムな値を選択します。 2 つのサンプルの URL が異なる場合、同じサーバーを参照している可能性があります。

GET および POST リクエスト

BEACON 構成には、HTTP GET および POST 要求用のカスタム HTTP ヘッダー、Cookie などを含めることができます。これらのフィールドは、BEACON ネットワーク トラフィックを構築および偽装するために、オペレーターが (Malleable Profile またはデフォルト値を使用して) チーム サーバーをどのように構成したかを表しています。これは、ペイロードに含まれるものに対する直接の 1 対 1 ではありません。可鍛性プロファイルは、いくつかのフィールドに対して複数の値を受け入れ、指定されたペイロードに表示されるのはそのうちの 1 つだけです。 GET または POST 要求が正確に一致しない場合、それは必ずしも別のサーバーからのものであることを示しているわけではありません。

スポーン先

各 BEACON ペイロードは、32 ビット タスク用と 64 ビット タスク用の 2 つの「spawn to」プロセスで構成されます。これらの値は、さまざまなポストエクスプロイト コマンドの一時プロセスとして BEACON が生成するものです。 BEACON はプロセスを起動し、(オペレーターが指定した手法を使用して) プロセスに注入し、悪用後のタスクを実行して、プロセスを終了します。これが影響を与える可能性があるコマンドの例として、この古いガイドを確認してください: Opsec Considerations for Beacon Commands .処理する既定の spawn は rundll32.exe ですが、これは 2 つの方法で変更できます。

  • 可鍛性プロファイルにより、オペレーターはデフォルトの spawn_to プロセスを変更できます (ライセンスされたバージョンまたはクラックされたバージョンを使用している場合)。これらの値を変更するには、チーム サーバーを再起動し、新しい値を使用するために新しい BEACON ペイロードを再生成する必要があります。
  • クライアントは、BEACON セッションが確立されると、オペレーターが対話的に spawn_to プロセスを変更できるようにします。これらは必要に応じて何度でも変更でき、再起動は必要ありませんが、現在の BEACON セッションにのみ影響します。

名前付きパイプ

名前付きパイプは、プロセス間通信 (IPC) に使用される Windows の機能です。 Cobalt Strike は、いくつかの方法で名前付きパイプを使用します。

  • ペイロード– バックドアをメモリにロードするために使用され、Malleable プロファイルやアーティファクト キットを介して変更可能です。
  • 悪用後のジョブ– 生成してプロセスに挿入する必要があるさまざまな Cobalt Strike コマンドに使用されます。
  • ステージング– SSH/SMB BEACON のステージングとチェーンに使用

Raphael Mudge の投稿「 すべての攻撃プロジェクトでパイプのフィッティングを学ぶには、この機能に関する役立つ詳細がいくつか記載されています。

睡眠時間

BEACON 構成の「sleeptime」値は、コールバック間隔に使用される基本時間です。 BEACON は、「ジッター」パーセンテージによって決定される範囲内でコールバックをランダム化します。たとえば、スリープ時間が 10 秒でジッターが 50% の場合、5 ~ 15 秒ごとにコールバックが生成されます。この値は、ネットワーク検出をより困難にするために一定ではありません。

Malleable Profile では、オペレーターはスリープ時間をミリ秒単位で指定できます。セッションが作成された後、オペレーターはスリープ時間とジッターの値を対話的に変更できますが、どちらも整数である必要があり、スリープ時間は秒単位で定義する必要があります。

キルデート

BEACON サンプルの「killdate」値は、特定の日付の後にチーム サーバーに接続する必要があるかどうかを示します。これは、エンゲージメントの完了後にペイロードが誤って実行されないようにするために、レッド チームのオペレーターによって使用されます。また、攻撃者がサンドボックスの実行の成功を制限し、遡及的な分析の取り組みを妨害するために使用することもできます。

この値は、チーム サーバーの起動時にコマンド ライン引数によって定義され、Malleable Profile または対話型の BEACON コマンドを使用して変更することはできません。デフォルトでは、killdate は指定されていません。

結論

Cobalt Strike は、正当なセキュリティ テスターと脅威アクターの両方が選択する C2 フレームワークであり続けています。フレームワークの機能と一般的な使用法をより完全に理解することで、防御側がこのツールを使用して悪意のあるアクターを探し、対応し、特定する新しい方法を見つけることができるようになることを願っています。

参考文献

検出ガイド

分析リソース

チュートリアルと例

Cobalt Strike の作成者である Raphael Mudge は、9 部構成の YouTube コースRed Team Ops with Cobalt Strikeを作成し、Cobalt Strike の使用方法を示しています。これは、製品がどのようなものであるか、およびこのブログ投稿 (およびいくつか) で説明されているさまざまな機能の使用方法を確認するために見る価値があります。

謝辞

Tyler Dean、Jae Young Kim、Matthew Dunwoody、Chris King の技術的な専門知識とレビューに感謝します。

参照: https://www.mandiant.com/resources/blog/defining-cobalt-strike-components

コメント

タイトルとURLをコピーしました