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 証明書が使用されます。

この状況では、オペレーターのドメインへのトラフィックをブロックするために、防御側はトラフィックを復号化して 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 への外部接続を表します。

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

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

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

各Cobaltstrike/logs/2024/04/20ディレクトリの下には、 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、ディフェンダーズガイド(DFIR レポート)
フルスペクトルのコバルトストライク検出(記録された未来)
メモリシグネチャを使用した Cobalt Strike の検出(Elastic)

分析リソース

オープンソースの Cobalt Strike パーサー(Sentinel One)
引退したコバルトストライクに逆襲（NCCグループ）
Cobalt Strike プロファイル(ZeroSec)について
Malleable C2 (Spectre Ops)の詳細

チュートリアルと例

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

Cobalt Strike のドキュメント(Raphael Mudge + ヘルプシステム)
可鍛性プロファイルの例(Raphael Mudge)
コミュニティキット(各種) – 「拡張機能の中央リポジトリ … を拡張… Cobalt Strike」
マスクをして寝る（アダム・スボボダ）
ドメインフロンティングリスト(Vincent Yiu)

謝辞

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

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