流出した内部チャットログによると、Black Basta のアフィリエイトは、悪意のあるファイルに拡張検証(EV)証明書を使用して署名するという、組織的な戦略をとっていることが明らかになりました。この手法は、EV署名付きアプリケーションに対して一般的に抱かれる信頼を悪用するものです。署名ベースの信頼のみに依存する組織は、こうしたEV署名済みバイナリが従来のスキャン機構をすり抜けやすいため、脆弱になります。チャット内容には、攻撃者がマルウェアをEV証明書で署名して検知を回避する方法を、どのように取得・管理・自動化しているかが詳細に記されており、ランサムウェアグループの作戦における組織的な緻密さが浮き彫りになっています。

EV証明書とは?そしてBlack Bastaはどうやって入手したのか

拡張検証(Extended Validation、EV)証明書とは、アプリケーションやWebサイトに対して高い信頼性を示す特別なデジタル証明書です。証明書を発行する認証局(CA)は、申請者が実在する正当な企業または個人であるかを厳格に確認します。そのため、ユーザーや多くのセキュリティソリューションは、 EV署名されたソフトウェアを「正式に検証された」ものとして信頼しやすくなります。

Global Sign が提供する拡張検証証明書の例

一部の脅威アクターは、既に閉鎖された企業を偽装してEV証明書を取得したことも確認されていますが、今回のログではBlack Bastaが以下のいずれかの方法で証明書を入手していたことが示唆されています。

1. EV証明書を直接購入

Black Bastaは、アンダーグラウンドフォーラムやブローカーから、1件あたり4,000~4,500ドルでEV証明書を購入していました。

"по $4000 каждый" (“$4000 each”)
"таких у нас еще не было" (“we’ve never had ones like these before”)
"сейчас возьму пару штук про запас" (“I’ll grab a couple more just in case”)
"скидоссссс)))" (“got a discount haha”)

これらのメッセージは通常、EV証明書を含む.rarファイルと対になっており、多くの場合、会社名でラベル付けされていました(例:EV56wallfort[SSL.com].rarEV4Avikser-llc2023-10-27[GlobalSign].rar)。

また、https://send[.]exploit[.]in/download/... https://transfer[.]sh/... のようなホスティング・プラットフォームにもリンクしていました。これらは、実際に盗まれた/不正に入手された証明書パッケージをホストしていました。

2.侵害されたリモート署名基盤

Black Bastaは、VirtualHereやYubiKey Minidriverツールを使って、物理的に接続されたEVトークンへリモートアクセスしていました。

**"You need Token17, double click to connect. Password: ******. Token PIN is 123456" "Run certmgr.msc and check if the cert was added" "Sign your files with signtool.exe"

Yubikey Minidriver

ある重要なチャットでは、以下のように述べられています。

"я переезжаю с той рдп – она в блеках" "I’m moving off that RDP – it’s blacklisted."

これは、署名インフラ(おそらくEVトークン)を設置していたRDPサーバーのことです。今はブラックリストに入っているが、以前は使えていました。通常、EVトークンはYubiKeyのようなハードウェア上に保管されますが、VirtualHereやsigntool.exeなどのツールを使って遠隔操作されていたと考えられます。つまり、この証明書は匿名で購入されたものではなく、RDPを通じて実在の企業や開発者から盗まれたものである可能性が高いということです。

ログでは、Black Bastaが悪用したEV証明書発行元としてSSL.comグローバルサインの2社が特定されています。

Black BastaによるEV証明書の運用ワークフロー

攻撃者は、Windows Installerファイル(MSI)やVisual Basicスクリプト(VBS)を初期感染の手段として使用していました。これらのローダーが実際のマルウェア(例:ランサムウェア、PikaBot、Cobalt Strike)をドロップまたは起動します。EV証明書で署名することで、メールフィルター、アンチウイルス、Windows SmartScreenによるブロックの可能性が大幅に下がります。

EV証明書を入手した後、攻撃者は以下のように運用していました。

  • 暗号化後にのみペイロードへ署名し、ハッシュ不一致を防止
  • 署名後のファイル変更は禁止(EV署名が無効になるため)
  • これらの証明書を使用して、再パックされた PikaBotインストーラー、MSIおよび VBSローダー、およびその他のマルウェア スタブに署名しました。会話から、Black Basta の関連組織が EV 証明書を使用してマルウェアに署名するために使用した詳細な手順が明らかになりました。これには、.pfxベースの証明書とハードウェアトークンベース (YubiKeyなど) のEV証明書の両方が含まれます。以下は、抜粋した正確な署名手順とコマンドラインの使用法です。

.pfxベースのEV証明書による署名

ツール条件:

  • Microsoft Windows SDK (signtool.exeを提供)
  • 有効な .pfx 証明書ファイルとパスワード 署名スクリプトの例 (sign.cmd)

サインスクリプトの例 (sign.cmd)

@echo off
set SIGNTOOL="C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x64\signtool.exe"
set CERT=cert.pfx
set PASSWORD=********
set FILE=calc.exe
set TIMESTAMP=http://timestamp.digicert.com

%SIGNTOOL% sign /f %CERT% /p %PASSWORD% /fd SHA256 /tr %TIMESTAMP% %FILE%

このスクリプトは、バイナリにタイムスタンプが付けられ、証明書の有効期限が切れた後に署名が無効になることを防ぎます。攻撃者は、署名の整合性を維持するために暗号化した後にのみ署名します。署名後のバイナリの変更は、EVマークを無効にします。

ハードウェアトークンベースのEV証明書(YubiKey & VirtualHere)

リモートアクセスの設定

  • 攻撃者は、クライアント側とサーバー側の両方にVirtualHereをインストールし、RDPセッション全体でUSBトークン接続を転送する。
  • YubiKey Smartcard Minidriverがリモートマシンにロードされ、Windowsがcertmgr.mscで証明書を認識できるようになる。

署名コマンド

signtool.exe sign /sha1 <certificate_thumbprint> /tr http://timestamp.digicert.com /td SHA256 /fd SHA256 <payload.exe>

証明書のサムプリントは、Windowsの証明書プロパティやcertmgr.mscから取得します。チャット内では、署名後のバイナリ編集がEV署名を破壊するため、署名は最後に行うよう厳守されていました。

Black Basta EVプロセスにおけるその他の洞察

  • 一部のアフィリエイトは、事前定義されたsign.cmdテンプレートを用いて複数ファイルに一括署名する自動化スクリプトを構築
  • チャットログでは、複数のEV証明書がセントラルリポジトリに保存されていたことが明らかにされており、「ストレージ障害」により「すべての鍵」が1つのVDSに保管されていたため混乱が発生
  • .rar形式で保存されたEV証明書アーカイブ(例:EV56wallfort[SSL.com].rar)の言及から、複数の証明書を必要に応じて使い分けていた実態が判明
  • 証明書が失効された際には、即座に新しいEV証明書へ切り替えて対応するなど、検知後の迅速なローテーションを行っていた

貴社にどう関係してくるのか?

EV証明書を使って「信頼された企業のふりをする」マルウェアは、まるで警察の制服を着た犯罪者のようなものです。多くの自動チェックをすり抜け、システム内部への侵入を許す可能性があります。これにより、デジタル証明書の信頼性が損なわれ、マルウェアの検知が難しくなり、最悪の場合、ランサムウェアによる暗号化や情報窃取といった実害へとつながります。

もし貴社のシステムが、署名ベースの許可リストやEV署名済みコードのみに依存している場合、大きなリスクがあります。EV署名されたマルウェアは、初期段階ではほとんどの従来の検知やユーザーの警戒をすり抜けてしまいます。

また、攻撃者が使用する「socks bot」戦略により、IPベースの検知・遮断も困難になります。一部のノードが遮断されても、新しいプロキシノードへと即座に切り替え、攻撃の配信を継続できるためです。

EV証明書の悪用にどう対抗すべきか?

脅威アクターが保有する盗まれたEV証明書は、非常に強力なカモフラージュ手段となり、感染成功率を高めています。Black Bastaのチャットログは、明確なパターンを示しています。すなわち、検知の閾値が上がると、マルウェアを変更して新しいEV証明書で再署名し、悪意あるファイル配布を大量に継続するというサイクルです。このような手法は、多くのセキュリティコントロールが署名コードをどう解釈するかという盲点を突いており、より高度で挙動に注目する防御戦略が重要です。

ファイルの署名情報だけでなく、疑わしい挙動を監視できるツールこそが最適な防御手段です。たとえファイルが正規の署名を持っていても、Vectra AIプラットフォーム のような製品であれば、ネットワーク内で異常行動を検知し、アラートを上げることができます。 既存のEDR(エンドポイント検知とレスポンス)ソリューションと組み合わせることで、EV署名済みの疑わしい実行ファイルであっても、迅速に隔離・封じ込めが可能となり、拡散を防ぐことができます。

Vectra AIの実力を体験してみませんか?今すぐデモをリクエストください

よくあるご質問(FAQ)